From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 00:24:19 2012 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 5DBEE106567C for ; Sun, 18 Mar 2012 00:24:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC6348FC19 for ; Sun, 18 Mar 2012 00:24:18 +0000 (UTC) Received: by lagv3 with SMTP id v3so5644287lag.13 for ; Sat, 17 Mar 2012 17:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n/9ein4eS2n8MFC2U/CJ5o8Pv1uwCwCKe0a8aeoH+xU=; b=eoTJsqv6m+NcnUjlun9Y3MlPFbXmB0kosyMkY2wVRY+kX1dvZ2E8llMuOVa2K02taX u3n1MUu+SdxfnkpDIxxEA11ZG3b9RwpxgGvqo55p4PxAYO5uYqUvmy7MCYwpycZRQRtm YYGxsgYEQNDvJKF0O7jIfYgMiq+adQfcegEagyvWIwFqDn4Eg1wlJf193eGcYb7g7Vjt wQAWg3qUso1JWbNuliySk4APj37/eFpFOMcjARLWiTm0vetN8qFSpRmXc1GHfNywbYTN prweJo+ber6oCLkXnnL6ZFeM8V0Vhn5RnjpSWiLlaLFnwIUO19fA5Eumby0tXxrSp83b y5/A== MIME-Version: 1.0 Received: by 10.112.27.164 with SMTP id u4mr2727767lbg.67.1332030257433; Sat, 17 Mar 2012 17:24:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.115.99 with HTTP; Sat, 17 Mar 2012 17:24:17 -0700 (PDT) In-Reply-To: <03c501cd02dc$f5af27d0$e10d7770$@fisglobal.com> References: <03c501cd02dc$f5af27d0$e10d7770$@fisglobal.com> Date: Sat, 17 Mar 2012 17:24:17 -0700 X-Google-Sender-Auth: 1nDbbeitbMVgzGRyc8BGvDa53Qw Message-ID: From: Adrian Chadd To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: [PATCHES] make buildworld -DWITHOUT_OPENSSL 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, 18 Mar 2012 00:24:19 -0000 Is the libarchive maintainer about, or is he very busy hiding away in Antarctica again? :) Adrian From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 01:53:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08599106564A for ; Sun, 18 Mar 2012 01:53:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id BD8F08FC16 for ; Sun, 18 Mar 2012 01:53:41 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q2I1reqf043262; Sat, 17 Mar 2012 21:53:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F65401B.303@sentex.net> Date: Sat, 17 Mar 2012 21:53:31 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F63A772.30406@sentex.net> <20120317225858.GA1660@michelle.cdnetworks.com> In-Reply-To: <20120317225858.GA1660@michelle.cdnetworks.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: FreeBSD-STABLE Mailing List Subject: Re: fxp entering promiscuous mode causing link to bounce 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, 18 Mar 2012 01:53:42 -0000 On 3/17/2012 6:58 PM, YongHyeon PYUN wrote: > On Fri, Mar 16, 2012 at 04:49:54PM -0400, Mike Tancsa wrote: >> >> tcpdump -ni fxp0 -c 20 >> >> fxp0: link state changed to DOWN >> fxp0: promiscuous mode enabled >> fxp0: link state changed to UP >> fxp0: link state changed to DOWN >> fxp0: promiscuous mode disabled >> fxp0: link state changed to UP >> >> I verified it on 2 different boxes. Is there a way to prevent this from happening ? >> > > It looks like a regression introduced in flow control support. Thanks very much, that indeed did fix it!! 0(smtp1)# patch < fxp.p Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/fxp/if_fxp.c |=================================================================== |--- sys/dev/fxp/if_fxp.c (revision 233076) |+++ sys/dev/fxp/if_fxp.c (working copy) -------------------------- Patching file sys/dev/fxp/if_fxp.c using Plan A... Hunk #1 succeeded at 900 (offset -2 lines). Hunk #2 succeeded at 2808 (offset -2 lines). Hunk #3 succeeded at 2914 (offset -2 lines). fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled ... and not bounced link/dropped packets. dev.fxp.0.%desc: Intel 82550 Pro/100 Ethernet dev.fxp.0.%driver: fxp dev.fxp.0.%location: slot=1 function=0 dev.fxp.0.%pnpinfo: vendor=0x8086 device=0x1229 subvendor=0x8086 subdevice=0x0040 class=0x020000 dev.fxp.0.%parent: pci2 dev.fxp.0.int_delay: 1000 dev.fxp.0.bundle_max: 6 dev.fxp.0.rnr: 0 dev.fxp.0.stats.rx.good_frames: 9265 dev.fxp.0.stats.rx.crc_errors: 0 dev.fxp.0.stats.rx.alignment_errors: 0 dev.fxp.0.stats.rx.rnr_errors: 0 dev.fxp.0.stats.rx.overrun_errors: 0 dev.fxp.0.stats.rx.cdt_errors: 0 dev.fxp.0.stats.rx.shortframes: 0 dev.fxp.0.stats.rx.pause: 0 dev.fxp.0.stats.rx.controls: 0 dev.fxp.0.stats.rx.tco: 0 dev.fxp.0.stats.tx.good_frames: 9978 dev.fxp.0.stats.tx.maxcols: 0 dev.fxp.0.stats.tx.latecols: 0 dev.fxp.0.stats.tx.underruns: 0 dev.fxp.0.stats.tx.lostcrs: 3 dev.fxp.0.stats.tx.deffered: 0 dev.fxp.0.stats.tx.single_collisions: 0 dev.fxp.0.stats.tx.multiple_collisions: 0 dev.fxp.0.stats.tx.total_collisions: 0 dev.fxp.0.stats.tx.pause: 0 dev.fxp.0.stats.tx.tco: 0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 16:10:59 2012 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 57BA01065676; Sun, 18 Mar 2012 16:10:59 +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 AC2568FC1B; Sun, 18 Mar 2012 16:10:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2IGAYws067000; Sun, 18 Mar 2012 20:10:34 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 18 Mar 2012 20:10:34 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: 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.7 (woozle.rinet.ru [0.0.0.0]); Sun, 18 Mar 2012 20:10:34 +0400 (MSK) Cc: mav@FreeBSD.org Subject: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 16:10:59 -0000 Dear colleagues, I've start testing SuperMicro MicroCloud[1] to have high-density routers cluster, and experiencing strange effects with disk subsystem: - on stable/8, it does detect AHCI controller, but detects disks as non-ahci ad* - on stable/9, disks are shown as ada*, but disk on second channel has constant read/write hangs, showing 100% load on few hundreds kBps in gstat. disk controller is Intel C204 PCH: ahci0: port 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 284 to local APIC 0 vector 81 ahci0: using IRQ 284 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 SATA 3.x device pass0: Serial Number WD-WCAYUFH26175 pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 pass1: ATA-8 SATA 3.x device pass1: Serial Number WD-WCAYUFH32290 pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass1: Command Queueing enabled ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number WD-WCAYUFH26175 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 GEOM: new disk ada0 GEOM: new disk ada1 ada1: ATA-8 SATA 3.x device ada1: Serial Number WD-WCAYUFH32290 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 Any hints? [1] http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm -- 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 Sun Mar 18 16:28:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF8D11065673 for ; Sun, 18 Mar 2012 16:28:23 +0000 (UTC) (envelope-from andrej@antiszoc.hu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3C88FC15 for ; Sun, 18 Mar 2012 16:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=antiszoc.hu; s=default; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=WnB5lZii+oGnyvi/sQPOt9a+uCOtQ7ub6abon1/0SC0=; b=JMYXekDW1wZ3NjoGUs0H9ECCpWA3RYmaCXO3Xjh7yP2PAMjbOPq3mx0jSaWeez/P1cUulFP0RL1hikxRPyF8za/azgo6po1HkaOL542SdQU+BPBHcAnSQkgIHjv+7DbE; Authentication-Results: mail.deployis.eu dkim=none Received: from localhost ([127.0.0.1]:36359 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.71 #1 (Debian)) id 1S9Ixr-0002sV-EH from for ; Sun, 18 Mar 2012 17:28:15 +0100 Received: from pool-232-213.ippark.hu ([31.223.232.213]) by mail.deployis.eu with HTTP (HTTP/1.1 POST); Sun, 18 Mar 2012 17:28:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 18 Mar 2012 17:28:15 +0100 From: =?UTF-8?Q?G=C3=B3t_Andr=C3=A1s?= To: In-Reply-To: References: Message-ID: <36b69f49aeb9bec1fc4b7e486023e494@antiszoc.hu> X-Sender: andrej@antiszoc.hu User-Agent: RoundCube Webmail/0.2.1 X-Mail-Status-postahivatal: trustedmail (from 127.0.0.1) X-Spam-Score-postahivatal: -46 Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 16:28:23 -0000 Hi, Did you check whether there's newer firmware for the microcloud mainboards? Does the integrated ctrls are in AHCI mode in the BIOS? You may also ask Supermicro if it turns out that it's not a FreeBSD problem, but be prepared that they'll ask for enterprise drives first. Regards, Andras On Sun, 18 Mar 2012 20:10:34 +0400 (MSK), Dmitry Morozovsky wrote: > Dear colleagues, > > I've start testing SuperMicro MicroCloud[1] to have high-density > routers > cluster, and experiencing strange effects with disk subsystem: > > - on stable/8, it does detect AHCI controller, but detects disks as > non-ahci > ad* > - on stable/9, disks are shown as ada*, but disk on second channel > has constant > read/write hangs, showing 100% load on few hundreds kBps in gstat. > > disk controller is Intel C204 PCH: > > ahci0: port > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f > mem > 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 > ahci0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 284 to local APIC 0 vector 81 > ahci0: using IRQ 284 for MSI > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM > 6ports > ahci0: Caps2: APST > ahci0: EM Caps: ALHD XMT SMB LED > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 3.x device > pass0: Serial Number WD-WCAYUFH26175 > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > pass1: ATA-8 SATA 3.x device > pass1: Serial Number WD-WCAYUFH32290 > pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass1: Command Queueing enabled > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: Serial Number WD-WCAYUFH26175 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > GEOM: new disk ada0 > GEOM: new disk ada1 > ada1: ATA-8 SATA 3.x device > ada1: Serial Number WD-WCAYUFH32290 > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > > Any hints? > > > [1] > http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 16:30:32 2012 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 27156106566C for ; Sun, 18 Mar 2012 16:30:32 +0000 (UTC) (envelope-from andrej@antiszoc.hu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB558FC14 for ; Sun, 18 Mar 2012 16:30:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=antiszoc.hu; s=default; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=UmtgsRa4+aXtT9L8ukkY/BmhP8qjCDYOoVmA7H3jP3w=; b=FBnnF9HQAn8Ch0r90GcCVIQQ1QnDsY8VY8GOqIs2gdSiKqc8ur0E372d4uJpg9QD8e29lT1Zcd9J4KvgNBHmHqeopa8zmF0ypLAVaHq30YuMy1zQxrEXR1cmsc+Xp5pi; Authentication-Results: mail.deployis.eu dkim=none Received: from localhost ([127.0.0.1]:36419 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.71 #1 (Debian)) id 1S9J02-000335-B5 from for ; Sun, 18 Mar 2012 17:30:30 +0100 Received: from pool-232-213.ippark.hu ([31.223.232.213]) by mail.deployis.eu with HTTP (HTTP/1.1 POST); Sun, 18 Mar 2012 17:30:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 18 Mar 2012 17:30:30 +0100 From: =?UTF-8?Q?G=C3=B3t_Andr=C3=A1s?= To: In-Reply-To: References: Message-ID: <4b2464e19deefa061c2194a3df55f02d@antiszoc.hu> X-Sender: andrej@antiszoc.hu User-Agent: RoundCube Webmail/0.2.1 X-Mail-Status-postahivatal: trustedmail (from 127.0.0.1) X-Spam-Score-postahivatal: -48 Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 16:30:32 -0000 Hi, And another question, have you tried with other type and vendor of disks? We saw some strange behavior with specific disks hanged onto a specific ctrl, but that was with Linux. :) Andras On Sun, 18 Mar 2012 20:10:34 +0400 (MSK), Dmitry Morozovsky wrote: > Dear colleagues, > > I've start testing SuperMicro MicroCloud[1] to have high-density > routers > cluster, and experiencing strange effects with disk subsystem: > > - on stable/8, it does detect AHCI controller, but detects disks as > non-ahci > ad* > - on stable/9, disks are shown as ada*, but disk on second channel > has constant > read/write hangs, showing 100% load on few hundreds kBps in gstat. > > disk controller is Intel C204 PCH: > > ahci0: port > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f > mem > 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 > ahci0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 284 to local APIC 0 vector 81 > ahci0: using IRQ 284 for MSI > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM > 6ports > ahci0: Caps2: APST > ahci0: EM Caps: ALHD XMT SMB LED > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 3.x device > pass0: Serial Number WD-WCAYUFH26175 > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > pass1: ATA-8 SATA 3.x device > pass1: Serial Number WD-WCAYUFH32290 > pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass1: Command Queueing enabled > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: Serial Number WD-WCAYUFH26175 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > GEOM: new disk ada0 > GEOM: new disk ada1 > ada1: ATA-8 SATA 3.x device > ada1: Serial Number WD-WCAYUFH32290 > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > > Any hints? > > > [1] > http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 16:43:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E1691065676 for ; Sun, 18 Mar 2012 16:43: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 D7A518FC12 for ; Sun, 18 Mar 2012 16:43:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2IGhl9h067643; Sun, 18 Mar 2012 20:43:47 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 18 Mar 2012 20:43:47 +0400 (MSK) From: Dmitry Morozovsky To: =?ISO-8859-15?Q?G=F3t_Andr=E1s?= In-Reply-To: <36b69f49aeb9bec1fc4b7e486023e494@antiszoc.hu> Message-ID: References: <36b69f49aeb9bec1fc4b7e486023e494@antiszoc.hu> 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.7 (woozle.rinet.ru [0.0.0.0]); Sun, 18 Mar 2012 20:43:47 +0400 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 16:43:50 -0000 On Sun, 18 Mar 2012, G?t Andr?s wrote: > Hi, > > Did you check whether there's newer firmware for the microcloud mainboards? > Does the integrated ctrls are in AHCI mode in the BIOS? Yes and yes, surely. > You may also ask Supermicro if it turns out that it's not a FreeBSD problem, > but be prepared that they'll ask for enterprise drives first. I can check with WD REs (have some spares for more disk-oriented servers, also SuperMicro), but let it be the latter phase. What puzzles me a bit is that it is not the first 1155 SuperMicro platform we use on 5017C-MTF it seems the same controller: ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfb121000-0xfb1217ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfb121000 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 0 vector 59 ahci0: using IRQ 266 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported and ahci with the same pair of WD Blues works flawlessly > > Regards, > Andras > > > On Sun, 18 Mar 2012 20:10:34 +0400 (MSK), Dmitry Morozovsky wrote: > > Dear colleagues, > > > > I've start testing SuperMicro MicroCloud[1] to have high-density routers > > cluster, and experiencing strange effects with disk subsystem: > > > > - on stable/8, it does detect AHCI controller, but detects disks as non-ahci > > ad* > > - on stable/9, disks are shown as ada*, but disk on second channel > > has constant > > read/write hangs, showing 100% load on few hundreds kBps in gstat. > > > > disk controller is Intel C204 PCH: > > > > ahci0: port > > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem > > 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 > > ahci0: attempting to allocate 1 MSI vectors (1 supported) > > msi: routing MSI IRQ 284 to local APIC 0 vector 81 > > ahci0: using IRQ 284 for MSI > > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > > ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports > > ahci0: Caps2: APST > > ahci0: EM Caps: ALHD XMT SMB LED > > ahcich0: at channel 0 on ahci0 > > ahcich0: Caps: > > ahcich1: at channel 1 on ahci0 > > ahcich1: Caps: > > > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > pass0: ATA-8 SATA 3.x device > > pass0: Serial Number WD-WCAYUFH26175 > > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > pass0: Command Queueing enabled > > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > pass1: ATA-8 SATA 3.x device > > pass1: Serial Number WD-WCAYUFH32290 > > pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > pass1: Command Queueing enabled > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-8 SATA 3.x device > > ada0: Serial Number WD-WCAYUFH26175 > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad4 > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > GEOM: new disk ada0 > > GEOM: new disk ada1 > > ada1: ATA-8 SATA 3.x device > > ada1: Serial Number WD-WCAYUFH32290 > > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada1: Command Queueing enabled > > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada1: Previously was known as ad6 > > > > Any hints? > > > > > > [1] http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm > > _______________________________________________ > 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" > -- 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 Sun Mar 18 16:53:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB9D4106566C; Sun, 18 Mar 2012 16:53:05 +0000 (UTC) (envelope-from prvs=142406e4fa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 19CA28FC0C; Sun, 18 Mar 2012 16:53:04 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Sun, 18 Mar 2012 16:52:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018885182.msg; Sun, 18 Mar 2012 16:52:17 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=142406e4fa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Dmitry Morozovsky" , References: Date: Sun, 18 Mar 2012 16:52:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: mav@FreeBSD.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 16:53:05 -0000 ----- Original Message ----- From: "Dmitry Morozovsky" To: Cc: Sent: Sunday, March 18, 2012 4:10 PM Subject: ahci hangs on Supermicro MicroCloud second channel > Dear colleagues, > > I've start testing SuperMicro MicroCloud[1] to have high-density routers > cluster, and experiencing strange effects with disk subsystem: > > - on stable/8, it does detect AHCI controller, but detects disks as non-ahci > ad* > - on stable/9, disks are shown as ada*, but disk on second channel has constant > read/write hangs, showing 100% load on few hundreds kBps in gstat. > > disk controller is Intel C204 PCH: > > ahci0: port > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem > 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 > ahci0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 284 to local APIC 0 vector 81 > ahci0: using IRQ 284 for MSI > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports > ahci0: Caps2: APST > ahci0: EM Caps: ALHD XMT SMB LED > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 3.x device > pass0: Serial Number WD-WCAYUFH26175 > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > pass1: ATA-8 SATA 3.x device > pass1: Serial Number WD-WCAYUFH32290 > pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > pass1: Command Queueing enabled > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: Serial Number WD-WCAYUFH26175 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > GEOM: new disk ada0 > GEOM: new disk ada1 > ada1: ATA-8 SATA 3.x device > ada1: Serial Number WD-WCAYUFH32290 > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > > Any hints? > > > [1] http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm We have quite a few of these running 8.2-RELEASE-p6 on AHCI with no problems (kernel compiled with:- device ahci) ahci0: port 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem 0xfbc01000-0xfbc017ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) 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: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) Given this might be worth seeing if 8.2 on AHCI fixes the hangs and hence its a regression in 9. If your running generic you should be able to just add the following to /boot/loader.conf ahci_load="YES" Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 17:06:24 2012 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 69666106564A for ; Sun, 18 Mar 2012 17:06:24 +0000 (UTC) (envelope-from luca.postregna@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB49A8FC17 for ; Sun, 18 Mar 2012 17:06:23 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so429377wgb.1 for ; Sun, 18 Mar 2012 10:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8yok0LQOw3LOa2cKYhh0+3V9d+NwOmBY0PsmbBwN6Bs=; b=d6GDVPcQZLxTfxplYhquWlGyFmjWnO8wtCgSpzGshau1ubdi0T9f1Tb2R1TNkgqLkV 2R1xRZFigqg8OBjuIVXPjY0AGAVJvftTnNqoWoyDT8dOZzVAOJKiQvLnJB3ZxA4mJOXL +IbK5CIgXy5T98lWZX2KzNw1tqipjBBYQZLRYYqDqkL6H/KrQm54B0Kqua+0QS2ZcP46 g/AcZ63BZuln+8OgxoSSzIab1crlDRm7SD/sp7czFriiNu9prqtLz9A2cQgx9FIH3OHr h9GfM8JW7DkdScNIq0IvGknIXucB/r02oFLv/ohCxHZ0ftwZjX6fBU/QwV+GaG2Ww3D2 ZTTQ== MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr13621727wix.5.1332090377404; Sun, 18 Mar 2012 10:06:17 -0700 (PDT) Received: by 10.180.101.42 with HTTP; Sun, 18 Mar 2012 10:06:17 -0700 (PDT) Date: Sun, 18 Mar 2012 18:06:17 +0100 Message-ID: From: Luca Postregna To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=f46d044287f2c1008004bb877596 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: freebsd 9 install fails on my old mini-itx 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, 18 Mar 2012 17:06:24 -0000 --f46d044287f2c1008004bb877596 Content-Type: text/plain; charset=UTF-8 I haven't success with freebsd 9 on my old mini-itx. In attachs you can find output of: * dd bs=64k count=100 /dev/null * dmesg * pciconf -lv no iusse on this disk with linux distros like debian, sysrescue, ecc. we think that this is driver iusse thanks, LP -- http://luca.postregna.name Luca Postregna --f46d044287f2c1008004bb877596 Content-Type: text/plain; charset=US-ASCII; name="dd.txt" Content-Disposition: attachment; filename="dd.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzyc2cvf0 ZGQ6IHN0ZGluOiBJbnB1dC9vdXRwdXQgZXJyb3IK --f46d044287f2c1008004bb877596 Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzyc2v091 KGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFdS SVRFX0RNQS4gQUNCOiBjYSAwMCAyMiAwMCAwMCA0MCAwMCAwMCAwMCAwMCAyMiAwMAooYWRhMDph dGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDow KTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCAp CihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDIyIDAwIDAwIDAwIDAwIDAwIDAwIDIyIDAw CihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBB VEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBXUklURV9ETUEuIEFDQjogY2EgMDAg MjIgMDAgMDAgNDAgMDAgMDAgMDAgMDAgMjIgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0 dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChE UkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTog UkVTOiA1MSA4NCAyMiAwMCAwMCAwMCAwMCAwMCAwMCAyMiAwMAooYWRhMDphdGEwOjA6MDowKTog UmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRh MDphdGEwOjA6MDowKTogV1JJVEVfRE1BLiBBQ0I6IGNhIDAwIDIyIDAwIDAwIDQwIDAwIDAwIDAw IDAwIDIyIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9y CihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9y OiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgMjIgMDAgMDAg MDAgMDAgMDAgMDAgMjIgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFk YTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFdSSVRF X0RNQS4gQUNCOiBjYSAwMCAyMiAwMCAwMCA0MCAwMCAwMCAwMCAwMCAyMiAwMAooYWRhMDphdGEw OjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTog QVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihh ZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDIyIDAwIDAwIDAwIDAwIDAwIDAwIDIyIDAwCihh ZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEg c3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBXUklURV9ETUEuIEFDQjogY2EgMDAgMjIg MDAgMDAgNDAgMDAgMDAgMDAgMDAgMjIgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6 IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZ IFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVT OiA1MSA4NCAyMiAwMCAwMCAwMCAwMCAwMCAwMCAyMiAwMAooYWRhMDphdGEwOjA6MDowKTogRXJy b3IgNSwgUmV0cmllcyBleGhhdXN0ZWQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJy b3IKKGFkYTA6YXRhMDowOjA6MCk6IFdSSVRFX0RNQS4gQUNCOiBjYSAwMCAwMCAwMCAwMCA0MCAw MCAwMCAwMCAwMCAwMSAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1 cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIp LCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAxIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21t YW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjAp OiBXUklURV9ETUEuIEFDQjogY2EgMDAgMDAgMDAgMDAgNDAgMDAgMDAgMDAgMDAgMDEgMDAKKGFk YTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDow OjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFC UlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MSAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDow KTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogV1JJVEVfRE1BLiBBQ0I6IGNh IDAwIDAwIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDAxIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0g c3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1 MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6 MCk6IFJFUzogNTEgODQgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDEgMDAKKGFkYTA6YXRhMDowOjA6 MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IK KGFkYTA6YXRhMDowOjA6MCk6IFdSSVRFX0RNQS4gQUNCOiBjYSAwMCAwMCAwMCAwMCA0MCAwMCAw MCAwMCAwMCAwMSAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBF cnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBl cnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAxIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5k CihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBX UklURV9ETUEuIEFDQjogY2EgMDAgMDAgMDAgMDAgNDAgMDAgMDAgMDAgMDAgMDEgMDAKKGFkYTA6 YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6 MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQg KQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMSAw MAooYWRhMDphdGEwOjA6MDowKTogRXJyb3IgNSwgUmV0cmllcyBleGhhdXN0ZWQKKGFkYTA6YXRh MDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFdSSVRFX0RNQS4g QUNCOiBjYSAwMCA2MiAwMSAwMCA0MCAwMCAwMCAwMCAwMCAwMCAwMAooYWRhMDphdGEwOjA6MDow KTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0 YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0 YTA6MDowOjApOiBSRVM6IDUxIDg0IDYyIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwCihhZGEwOmF0 YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVz IGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBXUklURV9ETUEuIEFDQjogY2EgMDAgNjIgMDEgMDAg NDAgMDAgMDAgMDAgMDAgMDAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBT dGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYg RVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4 NCA2MiAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcg Y29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6 MDowKTogV1JJVEVfRE1BLiBBQ0I6IGNhIDAwIDYyIDAxIDAwIDQwIDAwIDAwIDAwIDAwIDAwIDAw CihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0 YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNS QyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgNjIgMDEgMDAgMDAgMDAgMDAg MDAgMDAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDow OjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFdSSVRFX0RNQS4gQUNC OiBjYSAwMCA2MiAwMSAwMCA0MCAwMCAwMCAwMCAwMCAwMCAwMAooYWRhMDphdGEwOjA6MDowKTog Q0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1 czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6 MDowOjApOiBSRVM6IDUxIDg0IDYyIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwCihhZGEwOmF0YTA6 MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVy cm9yCihhZGEwOmF0YTA6MDowOjApOiBXUklURV9ETUEuIEFDQjogY2EgMDAgNjIgMDEgMDAgNDAg MDAgMDAgMDAgMDAgMDAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0 dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJS KSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCA2 MiAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMAooYWRhMDphdGEwOjA6MDowKTogRXJyb3IgNSwgUmV0 cmllcyBleGhhdXN0ZWQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6 YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDAwIDA2IDAwIDQwIDAwIDAwIDAwIDAw IDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihh ZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4 NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgMDAgMDYgMDAgMDAg MDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6 YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1B LiBBQ0I6IGM4IDAwIDAwIDA2IDAwIDQwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDow OjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEg c3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6 YXRhMDowOjA6MCk6IFJFUzogNTEgODQgMDAgMDYgMDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6 YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0 dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDAwIDA2IDAw IDQwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEg U3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJW IEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEg ODQgMDAgMDYgMDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5n IGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDow OjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDAwIDA2IDAwIDQwIDAwIDAwIDAwIDAwIDgwIDAw CihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0 YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNS QyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgMDAgMDYgMDAgMDAgMDAgMDAg MDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDow OjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6 IGM4IDAwIDAwIDA2IDAwIDQwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBD QU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVz OiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDow OjA6MCk6IFJFUzogNTEgODQgMDAgMDYgMDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDow OjA6MCk6IEVycm9yIDUsIFJldHJpZXMgZXhoYXVzdGVkCihhZGEwOmF0YTA6MDowOjApOiBBVEEg c3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAwMCAw NiAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czog QVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkg U0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6 IDUxIDg0IDAwIDA2IDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRy eWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0 YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAwMCAwNiAwMCA0MCAwMCAwMCAwMCAwMCA4 MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRh MDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQg KElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDAwIDA2IDAwIDAwIDAw IDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0 YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4g QUNCOiBjOCAwMCAwMCAwNiAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDow KTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0 YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0 YTA6MDowOjApOiBSRVM6IDUxIDg0IDAwIDA2IDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0 YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVz IGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAwMCAwNiAwMCA0 MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0 YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBF UlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0 IDAwIDA2IDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBj b21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDow OjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAwMCAwNiAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAoo YWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEw OjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMg QUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDAwIDA2IDAwIDAwIDAwIDAwIDAw IDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBFcnJvciA1LCBSZXRyaWVzIGV4aGF1c3RlZAooYWRh MDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9E TUEuIEFDQjogYzggMDAgMDAgMDYgMDAgNDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDow OjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFU QSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRh MDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAwMCAwNiAwMCAwMCAwMCAwMCAwMCA4MCAwMAooYWRh MDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0 YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgMDAgMDYg MDAgNDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFU QSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNF UlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1 MSA4NCAwMCAwNiAwMCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlp bmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEw OjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgMDAgMDYgMDAgNDAgMDAgMDAgMDAgMDAgODAg MDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6 YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJ Q1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAwMCAwNiAwMCAwMCAwMCAw MCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEw OjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFD QjogYzggMDAgMDAgMDYgMDAgNDAgMDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6 IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0 dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEw OjA6MDowKTogUkVTOiA1MSA4NCAwMCAwNiAwMCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEw OjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBl cnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgMDAgMDYgMDAgNDAg MDAgMDAgMDAgMDAgODAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0 dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJS KSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAw MCAwNiAwMCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogRXJyb3IgNSwgUmV0 cmllcyBleGhhdXN0ZWQK --f46d044287f2c1008004bb877596 Content-Type: text/plain; charset=US-ASCII; name="pciconf-lv.txt" Content-Disposition: attachment; filename="pciconf-lv.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzyc2zvz2 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4 MDYwNTExMDYgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xv Z2llcywgSW5jLicKICAgIGRldmljZSAgICAgPSAnVlQ4NjA1IFtQcm9TYXZhZ2UgUE0xMzNdJwog ICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnBjaWIxQHBj aTA6MDoxOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4ODYwNTExMDYg cmV2PTB4MDAgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcywgSW5j LicKICAgIGRldmljZSAgICAgPSAnVlQ4NjA1IFtQTTEzMyBBR1BdJwogICAgY2xhc3MgICAgICA9 IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKaXNhYjBAcGNpMDowOjc6MDoJY2xhc3M9 MHgwNjAxMDAgY2FyZD0weDAwMDAxMTA2IGNoaXA9MHgwNjg2MTEwNiByZXY9MHg0MCBoZHI9MHgw MAogICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVzLCBJbmMuJwogICAgZGV2aWNlICAg ICA9ICdWVDgyQzY4NiBbQXBvbGxvIFN1cGVyIFNvdXRoXScKICAgIGNsYXNzICAgICAgPSBicmlk Z2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmF0YXBjaTBAcGNpMDowOjc6MToJY2xhc3M9MHgw MTAxOGEgY2FyZD0weDA1NzExMTA2IGNoaXA9MHgwNTcxMTEwNiByZXY9MHgwNiBoZHI9MHgwMAog ICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVzLCBJbmMuJwogICAgZGV2aWNlICAgICA9 ICdWVDgyQzU4NkEvQi9WVDgyQzY4Ni9BL0IvVlQ4MjN4L0EvQyBQSVBDIEJ1cyBNYXN0ZXIgSURF JwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IEFUQQp1aGNp MEBwY2kwOjA6NzoyOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4MTIzNDA5MjUgY2hpcD0weDMwMzgx MTA2IHJldj0weDFhIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMs IEluYy4nCiAgICBkZXZpY2UgICAgID0gJ1ZUODJ4eHh4eCBVSENJIFVTQiAxLjEgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCnVoY2kx QHBjaTA6MDo3OjM6CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHgxMjM0MDkyNSBjaGlwPTB4MzAzODEx MDYgcmV2PTB4MWEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcywg SW5jLicKICAgIGRldmljZSAgICAgPSAnVlQ4Mnh4eHh4IFVIQ0kgVVNCIDEuMSBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKbm9uZTBA cGNpMDowOjc6NDoJY2xhc3M9MHgwNjgwMDAgY2FyZD0weDMwNTcxMTA2IGNoaXA9MHgzMDU3MTEw NiByZXY9MHg0MCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVzLCBJ bmMuJwogICAgZGV2aWNlICAgICA9ICdWVDgyQzY4NiBbQXBvbGxvIFN1cGVyIEFDUEldJwogICAg Y2xhc3MgICAgICA9IGJyaWRnZQpub25lMUBwY2kwOjA6Nzo1OgljbGFzcz0weDA0MDEwMCBjYXJk PTB4NDUxMTExMDYgY2hpcD0weDMwNTgxMTA2IHJldj0weDUwIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMsIEluYy4nCiAgICBkZXZpY2UgICAgID0gJ1ZUODJDNjg2 IEFDOTcgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBtdWx0aW1lZGlhCiAgICBz dWJjbGFzcyAgID0gYXVkaW8KcmwwQHBjaTA6MDoxMjowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4 ODEzOTEwZWMgY2hpcD0weDgxMzkxMGVjIHJldj0weDEwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAg ID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4nCiAgICBkZXZpY2UgICAgID0gJ1JU TC04MTM5LzgxMzlDLzgxMzlDKycKICAgIGNsYXNzICAgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFz cyAgID0gZXRoZXJuZXQKZndvaGNpMEBwY2kwOjA6MTU6MDoJY2xhc3M9MHgwYzAwMTAgY2FyZD0w eDU4MTExMWMxIGNoaXA9MHg1ODExMTFjMSByZXY9MHgwNCBoZHI9MHgwMAogICAgdmVuZG9yICAg ICA9ICdBZ2VyZSBTeXN0ZW1zJwogICAgZGV2aWNlICAgICA9ICdGVzMyMi8zMjMnCiAgICBjbGFz cyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IEZpcmVXaXJlCnZnYXBjaTBAcGNp MDoxOjA6MDoJY2xhc3M9MHgwMzAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg4YTI1NTMzMyBy ZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdTMyBJbmMuJwogICAgZGV2aWNlICAg ICA9ICdQcm9TYXZhZ2UgUE0xMzMnCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQogICAgc3ViY2xh c3MgICA9IFZHQQo= --f46d044287f2c1008004bb877596-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 17:08:17 2012 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 8DCE61065670; Sun, 18 Mar 2012 17:08:17 +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 E603F8FC1C; Sun, 18 Mar 2012 17:08:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2IH8FeJ068080; Sun, 18 Mar 2012 21:08:15 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 18 Mar 2012 21:08:15 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: Message-ID: References: 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.7 (woozle.rinet.ru [0.0.0.0]); Sun, 18 Mar 2012 21:08:15 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 17:08:17 -0000 Steven, On Sun, 18 Mar 2012, Steven Hartland wrote: [snip] > We have quite a few of these running 8.2-RELEASE-p6 on AHCI with no > problems (kernel compiled with:- device ahci) > > ahci0: port > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem > 0xfbc01000-0xfbc017ff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > 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: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) > > Given this might be worth seeing if 8.2 on AHCI fixes the > hangs and hence its a regression in 9. If your running > generic you should be able to just add the following to > /boot/loader.conf > ahci_load="YES" Yes, I did it, but all I have ... wait a bit... Yes, I missed ahci.ko module on my PXE server in amd64/8 tree :-/ [kernel reinstall] Well, ahci problem solved, but I still have much worse performance (and different on ada0 and ada1!): ada0, MC 50-60 MBps ada1, MC 13-25 MBps ada*, 5017 130+ MBps Could you please post SATA/AHCI BIOS settings from your machines? Thanks a lot! -- 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 Sun Mar 18 17:15:41 2012 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 0A44E106564A for ; Sun, 18 Mar 2012 17:15:41 +0000 (UTC) (envelope-from luca.postregna@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58A288FC0C for ; Sun, 18 Mar 2012 17:15:39 +0000 (UTC) Received: by wern13 with SMTP id n13so6933207wer.13 for ; Sun, 18 Mar 2012 10:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rCG+MDJrqL51pZEdeldFNYTjo/AHPdx5GP+qj26o6Ic=; b=wSvjQQYuJJp5fX5fx4BT2fAIwiibYwsKl8HQqxjabE8RGzCJmTAG+zbSRaKb8G0SZe cqxtcD2Ywto9XZPYqUGOhx//6UXSGSTfz922SlwJZVK33wBl9DrgCXFWoW847QxEAd+Q GfR/EH67n7jyMWuNDlzYdJyoWbUlfoagt9odqILbEJujxP6/aWg6HtRDu7Xj1PJFiOie ebbR7TjqDLm3mN5jwmFPtaFopJ3Jr8j10QmGsmKPGxvsOc7xlII2d8r9awIAyP3Ff/Jf kU/mP3EqI9YuFllNColH4Sl2VA84IrU+kT4HggdPClX1ZHV+5/puxe6Wl5OEOSfnJ+lb I5GQ== MIME-Version: 1.0 Received: by 10.216.131.78 with SMTP id l56mr5315889wei.94.1332090939243; Sun, 18 Mar 2012 10:15:39 -0700 (PDT) Received: by 10.180.101.42 with HTTP; Sun, 18 Mar 2012 10:15:39 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Mar 2012 18:15:39 +0100 Message-ID: From: Luca Postregna To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=0016e6d460a63dfeae04bb879734 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd 9 install fails on my old mini-itx 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, 18 Mar 2012 17:15:41 -0000 --0016e6d460a63dfeae04bb879734 Content-Type: text/plain; charset=UTF-8 here the full dmesg. sorry 2012/3/18 Luca Postregna > I haven't success with freebsd 9 on my old mini-itx. > In attachs you can find output of: > > * dd bs=64k count=100 /dev/null > * dmesg > * pciconf -lv > > no iusse on this disk with linux distros like debian, sysrescue, ecc. > we think that this is driver iusse > > thanks, > LP > > -- > > http://luca.postregna.name > Luca Postregna > > -- http://luca.postregna.name Luca Postregna --0016e6d460a63dfeae04bb879734 Content-Type: text/plain; charset=US-ASCII; name="dmesg-freebsd.txt" Content-Disposition: attachment; filename="dmesg-freebsd.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzycilfm3 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5LjAtUkVMRUFTRSAjMDogVHVlIEphbiAgMyAwNzox NToyNSBVVEMgMjAxMgogICAgcm9vdEBvYnJpYW4uY3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2JqL3Vz ci9zcmMvc3lzL0dFTkVSSUMgaTM4NgpUYWJsZSAnRkFDUCcgYXQgMHhmN2YzMDQwCkFDUEk6IE5v IFNSQVQgdGFibGUgZm91bmQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJu ZWwiIGF0IDB4YzEyYTAwMDAuCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiA5 OTc0Nzg3OTMgSHoKQ1BVOiBJbnRlbCBQZW50aXVtIElJSSAoOTk3LjQ4LU1IeiA2ODYtY2xhc3Mg Q1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjhhICBGYW1pbHkgPSA2ICBN b2RlbCA9IDggIFN0ZXBwaW5nID0gMTAKICBGZWF0dXJlcz0weDM4N2Y5ZmY8RlBVLFZNRSxERSxQ U0UsVFNDLE1TUixQQUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LFBO LE1NWCxGWFNSLFNTRT4KCkluc3RydWN0aW9uIFRMQjogNCBLQiBwYWdlcywgNC13YXkgc2V0IGFz c29jaWF0aXZlLCAzMiBlbnRyaWVzCkluc3RydWN0aW9uIFRMQjogNCBNQiBwYWdlcywgZnVsbHkg YXNzb2NpYXRpdmUsIDIgZW50cmllcwpEYXRhIFRMQjogNCBLQiBwYWdlcywgNC13YXkgc2V0IGFz c29jaWF0aXZlLCA2NCBlbnRyaWVzCjJuZC1sZXZlbCBjYWNoZTogMjU2IEtCLCA4LXdheSBzZXQg YXNzb2NpYXRpdmUsIDMyIGJ5dGUgbGluZSBzaXplCjFzdC1sZXZlbCBpbnN0cnVjdGlvbiBjYWNo ZTogMTYgS0IsIDQtd2F5IHNldCBhc3NvY2lhdGl2ZSwgMzIgYnl0ZSBsaW5lIHNpemUKRGF0YSBU TEI6IDQgTUIgUGFnZXMsIDQtd2F5IHNldCBhc3NvY2lhdGl2ZSwgOCBlbnRyaWVzCjFzdC1sZXZl bCBkYXRhIGNhY2hlOiAxNiBLQiwgNC13YXkgc2V0IGFzc29jaWF0aXZlLCAzMiBieXRlIGxpbmUg c2l6ZQpyZWFsIG1lbW9yeSAgPSA1MzY4NzA5MTIgKDUxMiBNQikKUGh5c2ljYWwgbWVtb3J5IGNo dW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWVmZmYsIDY0NzE2OCBi eXRlcyAoMTU4IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYs IDMxNDU3MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAxNDI2MDAwIC0gMHgwMDAwMDAw MDBmMzQwZmZmLCAyMzM5NDMwNDAgYnl0ZXMgKDU3MTE1IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAy MzUxNjc3NDQgKDIyNCBNQikKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3Rvcnkg aGVhZGVyIGF0IDB4YzAwZmFmNTAKYmlvczMyOiBFbnRyeSA9IDB4ZmIzYzAgKGMwMGZiM2MwKSAg UmV2ID0gMCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4YjQx MApwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmJlYjAKcG5wYmlvczogRW50 cnkgPSBmMDAwMDpiZWUwICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgpV TEU6IHNldHVwIGNwdSAwCnNuZF91bml0X2luaXQoKSB1PTB4MDBmZjgwMDAgWzUxMl0gZD0weDAw MDA3YzAwIFszMl0gYz0weDAwMDAwM2ZmIFsxMDI0XQpmZWVkZXJfcmVnaXN0ZXI6IHNuZF91bml0 PS0xIHNuZF9tYXhhdXRvdmNoYW5zPTE2IGxhdGVuY3k9NSBmZWVkZXJfcmF0ZV9taW49MSBmZWVk ZXJfcmF0ZV9tYXg9MjAxNjAwMCBmZWVkZXJfcmF0ZV9yb3VuZD0yNQp3bGFuOiA8ODAyLjExIExp bmsgTGF5ZXI+CnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgpuZnNs b2NrOiBwc2V1ZG8tZGV2aWNlCmtiZDogbmV3IGFycmF5IHNpemUgNAprYmQxIGF0IGtiZG11eDAK bWVtOiA8bWVtb3J5PgpQZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5hYmxlZAppbzogPEkvTz4K bnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KaHB0cnI6IFJvY2tldFJBSUQgMTd4eC8y eHh4IFNBVEEgY29udHJvbGxlciBkcml2ZXIgdjEuMgpBQ1BJOiBSU0RQIDB4ZjcxYzAgMDAwMTQg KHYwMCBWSUE2MDUpCkFDUEk6IFJTRFQgMHhmN2YzMDAwIDAwMDI4ICh2MDEgVklBNjA1IEFXUkRB Q1BJIDQyMzAyRTMxIEFXUkQgMDAwMDAwMDApCkFDUEk6IEZBQ1AgMHhmN2YzMDQwIDAwMDc0ICh2 MDEgVklBNjA1IEFXUkRBQ1BJIDQyMzAyRTMxIEFXUkQgMDAwMDAwMDApCkFDUEk6IERTRFQgMHhm N2YzMGMwIDAyM0E4ICh2MDEgVklBNjA1IEFXUkRBQ1BJIDAwMDAxMDAwIE1TRlQgMDEwMDAwMEMp CkFDUEk6IEZBQ1MgMHhmN2YwMDAwIDAwMDQwCmFjcGkwOiA8VklBNjA1IEFXUkRBQ1BJPiBvbiBt b3RoZXJib2FyZAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHdha2V1cCBjb2Rl IHZhIDB4YzIxODAwMDAgcGEgMHgxMDAwCnBjaV9vcGVuKDEpOgltb2RlIDEgYWRkciBwb3J0ICgw eDBjZjgpIGlzIDB4ODAwMDAwNjAKcGNpX29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAwMDAwICgw eDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAwMDBdIFtoZHI9MDBd IGlzIHRoZXJlIChpZD0wNjA1MTEwNikKcGNpYmlvczogQklPUyB2ZXJzaW9uIDIuMTAKYWNwaTA6 IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9m IDEwMDAwMCwgZjZmMDAwMCAoMykgZmFpbGVkCmFjcGlfdGltZXIwOiBjb3VsZG4ndCBhbGxvY2F0 ZSByZXNvdXJjZSAocG9ydCAweDQwMDgpCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MDog c3dpdGNoaW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQpwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAg MSAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAg IE4gICAgIDAgIDEgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAg ICAwICAyNTUgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE6 ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMSAx MiAxNCAxNQpwY2lfbGluazI6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTAgMTEgMTIg MTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgNSAgIE4gICAgIDAgIDEgMyA0IDUgNiA3 IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAx IDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMSAz IDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4g ICAgIDAgIDEgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQphY3BpX2J1dHRvbjA6 IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24g YWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiwweDQw MDAtMHg0MDdmLDB4NDA4MC0weDQwZmYsMHg1MDAwLTB4NTAwZiwweDYwMDAtMHg2MDdmIG9uIGFj cGkwCnBjaWIwOiBkZWNvZGluZyA0IHJhbmdlIDAtMHhjZjcKcGNpYjA6IGRlY29kaW5nIDQgcmFu Z2UgMHhkMDAtMHgzZmZmCnBjaWIwOiBMZW5ndGggbWlzbWF0Y2ggZm9yIDQgcmFuZ2U6IGYwMCB2 cyBlZmYKcGNpYjA6IGRlY29kaW5nIDQgcmFuZ2UgMHg0MTAwLTB4NGZmZgpwY2liMDogTGVuZ3Ro IG1pc21hdGNoIGZvciA0IHJhbmdlOiBmZjAgdnMgZmVmCnBjaWIwOiBkZWNvZGluZyA0IHJhbmdl IDB4NTAxMC0weDVmZmYKcGNpYjA6IExlbmd0aCBtaXNtYXRjaCBmb3IgNCByYW5nZTogOWY4MCB2 cyA5ZjdmCnBjaWIwOiBkZWNvZGluZyA0IHJhbmdlIDB4NjA4MC0weGZmZmYKcGNpYjA6IGRlY29k aW5nIDMgcmFuZ2UgMHhhMDAwMC0weGJmZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4YzAw MDAtMHhkZmZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGY4MDAwMDAtMHhmZmVmZmZmZgpB Q1BJOiBGb3VuZCBtYXRjaGluZyBwaW4gZm9yIDAuMTUuSU5UQSBhdCBmdW5jIDA6IDUKQUNQSTog Rm91bmQgbWF0Y2hpbmcgcGluIGZvciAwLjEyLklOVEEgYXQgZnVuYyAwOiAxMQpBQ1BJOiBGb3Vu ZCBtYXRjaGluZyBwaW4gZm9yIDAuNy5JTlRDIGF0IGZ1bmMgNTogNQpBQ1BJOiBGb3VuZCBtYXRj aGluZyBwaW4gZm9yIDAuNy5JTlREIGF0IGZ1bmMgMjogMTEKcGNpMDogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4 MTEwNiwgZGV2PTB4MDYwNSwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1 bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDIyMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBQcmVmZXRjaGFibGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGU4MDAwMDAwLCBzaXplIDI2LCBlbmFibGVkCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGU4MDAwMDAwLTB4ZWJmZmZmZmYpIGZvciByaWQgMTAgb2Yg cGNpMDowOjA6MApmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDg2MDUsIHJldmlkPTB4MDAK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBl PTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHhhMjMwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDBjICgzMDAwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDMgIGN1cnJl bnQgRDAKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgwNjg2LCByZXZpZD0weDQwCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMDg3LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCmZvdW5k LT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MDU3MSwgcmV2aWQ9MHgwNgoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTcsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJ Y21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0 aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweDFmMC0weDFmNykgZm9yIHJpZCAxMCBvZiBwY2kwOjA6NzoxCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSA0ICgweDNmNi0weDNmNikgZm9yIHJpZCAxNCBvZiBwY2kwOjA6NzoxCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDE3MC0weDE3NykgZm9yIHJpZCAxOCBvZiBwY2kwOjA6 NzoxCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDM3Ni0weDM3NikgZm9yIHJpZCAxYyBvZiBw Y2kwOjA6NzoxCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQwMDAs IHNpemUgIDQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZDAwMC0weGQwMGYp IGZvciByaWQgMjAgb2YgcGNpMDowOjc6MQpmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMw MzgsIHJldmlkPTB4MWEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTIKCWNsYXNzPTBj LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgw MjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzIwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhkNDAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweGQ0MDAtMHhkNDFmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDo3OjIKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlREIChzcmMgXFxfU0JfLlBDSTAuTE5LRDowKQpwY2li MDogc2xvdCA3IElOVEQgcm91dGVkIHRvIGlycSAxMSB2aWEgXFxfU0JfLlBDSTAuTE5LRApmb3Vu ZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMwMzgsIHJldmlkPTB4MWEKCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD03LCBmdW5jPTMKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkODAwLCBzaXpl ICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGQ4MDAtMHhkODFmKSBmb3Ig cmlkIDIwIG9mIHBjaTA6MDo3OjMKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlREIChz cmMgXFxfU0JfLlBDSTAuTE5LRDowKQpwY2liMDogc2xvdCA3IElOVEQgcm91dGVkIHRvIGlycSAx MSB2aWEgXFxfU0JfLlBDSTAuTE5LRApmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMwNTcs IHJldmlkPTB4NDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTQKCWNsYXNzPTA2LTgw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMjkw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDAKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMDU4LCByZXZpZD0weDUw Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9NywgZnVuYz01CgljbGFzcz0wNC0wMS0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAxLCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT01Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4ZGMwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhkYzAw LTB4ZGNmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Nzo1CgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweGUwMDAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDQgKDB4ZTAwMC0weGUwMDMpIGZvciByaWQgMTQgb2YgcGNpMDowOjc6NQoJbWFwWzE4 XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlNDAwLCBzaXplICAyLCBlbmFibGVk CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGU0MDAtMHhlNDAzKSBmb3IgcmlkIDE4IG9mIHBj aTA6MDo3OjUKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlRDIChzcmMgXFxfU0JfLlBD STAuTE5LQzowKQpwY2liMDogc2xvdCA3IElOVEMgcm91dGVkIHRvIGlycSA1IHZpYSBcXF9TQl8u UENJMC5MTktDCmZvdW5kLT4JdmVuZG9yPTB4MTBlYywgZGV2PTB4ODEzOSwgcmV2aWQ9MHgxMAoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEyLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MjAgKDgwMDAgbnMp LCBtYXhsYXQ9MHg0MCAoMTYwMDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4ZTgwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk IHR5cGUgNCAoMHhlODAwLTB4ZThmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6MTI6MAoJbWFwWzE0 XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZWUwMDAwMDAsIHNpemUgIDgsIGVuYWJs ZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZWUwMDAwMDAtMHhlZTAwMDBmZikgZm9yIHJp ZCAxNCBvZiBwY2kwOjA6MTI6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xMi5JTlRBIChz cmMgXFxfU0JfLlBDSTAuTE5LRDowKQpwY2liMDogc2xvdCAxMiBJTlRBIHJvdXRlZCB0byBpcnEg MTEgdmlhIFxcX1NCXy5QQ0kwLkxOS0QKZm91bmQtPgl2ZW5kb3I9MHgxMWMxLCBkZXY9MHg1ODEx LCByZXZpZD0weDA0Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTUsIGZ1bmM9MAoJY2xhc3M9MGMt MDAtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAy OTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9 MHgwYyAoMzAwMCBucyksIG1heGxhdD0weDE4ICg2MDAwIG5zKQoJaW50cGluPWEsIGlycT01Cglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGVlMDAxMDAwLCBzaXplIDEyLCBlbmFibGVkCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGVlMDAxMDAwLTB4ZWUwMDFmZmYpIGZvciByaWQgMTAg b2YgcGNpMDowOjE1OjAKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTUuSU5UQSAoc3JjIFxc X1NCXy5QQ0kwLkxOS0M6MCkKcGNpYjA6IHNsb3QgMTUgSU5UQSByb3V0ZWQgdG8gaXJxIDUgdmlh IFxcX1NCXy5QQ0kwLkxOS0MKYWdwMDogPFZJQSA4MkM2OTRYIChBcG9sbG8gUHJvIDEzM0EpIGhv c3QgdG8gUENJIGJyaWRnZT4gb24gaG9zdGIwCmFncDA6IGFsbG9jYXRpbmcgR0FUVCBmb3IgYXBl cnR1cmUgb2Ygc2l6ZSA2NE0KYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyA2NE0KcGNpYjE6IDxQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGVjMDAwMDAwLTB4ZWRmZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjEKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZTAwMDAwMDAtMHhlN2ZmZmZmZikgZm9yIHJpZCAyNCBvZiBwY2liMQpw Y2liMTogICBkb21haW4gICAgICAgICAgICAwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEK cGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBtZW1vcnkgZGVjb2RlICAgICAw eGVjMDAwMDAwLTB4ZWRmZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhlMDAwMDAw MC0weGU3ZmZmZmZmCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBkb21haW49MCwgcGh5 c2ljYWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHg1MzMzLCBkZXY9MHg4YTI1LCByZXZpZD0weDAy Cglkb21haW49MCwgYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6 PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4ZjggKDc0NDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBu cyksIG1heGxhdD0weGZmICg2Mzc1MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZWQwMDAwMDAsIHNpemUgMTksIGVuYWJsZWQKcGNpYjE6IGFsbG9j YXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZWQwMDAwMDAtMHhlZDA3ZmZmZikgZm9yIHJpZCAxMCBvZiBw Y2kwOjE6MDowCgltYXBbMTRdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDMyLCBi YXNlIDB4ZTAwMDAwMDAsIHNpemUgMjcsIGVuYWJsZWQKcGNpYjE6IGFsbG9jYXRlZCBwcmVmZXRj aCByYW5nZSAoMHhlMDAwMDAwMC0weGU3ZmZmZmZmKSBmb3IgcmlkIDE0IG9mIHBjaTA6MTowOjAK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LQTow KQpwY2liMDogc2xvdCAxIElOVEEgcm91dGVkIHRvIGlycSAxMCB2aWEgXFxfU0JfLlBDSTAuTE5L QQpwY2liMTogc2xvdCAwIElOVEEgaXMgcm91dGVkIHRvIGlycSAxMAp2Z2FwY2kwOiA8VkdBLWNv bXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZWQwMDAwMDAtMHhlZDA3ZmZmZiwweGUwMDAwMDAwLTB4 ZTdmZmZmZmYgaXJxIDEwIGF0IGRldmljZSAwLjAgb24gcGNpMQppc2FiMDogPFBDSS1JU0EgYnJp ZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBj aTA6IDxWSUEgODJDNjg2QiBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgz ZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhkMDAwLTB4ZDAwZiBhdCBkZXZpY2UgNy4xIG9uIHBjaTAK YXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9u IGF0YXBjaTAKdWhjaTA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZDQwMC0w eGQ0MWYgaXJxIDExIGF0IGRldmljZSA3LjIgb24gcGNpMAp1c2J1czA6IDxWSUEgODNDNTcyIFVT QiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2J1czA6IGJwZiBhdHRhY2hlZAp1aGNpMDogdXNicGY6 IEF0dGFjaGVkCnVoY2kxOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxlcj4gcG9ydCAweGQ4MDAt MHhkODFmIGlycSAxMSBhdCBkZXZpY2UgNy4zIG9uIHBjaTAKdXNidXMxOiA8VklBIDgzQzU3MiBV U0IgY29udHJvbGxlcj4gb24gdWhjaTEKdXNidXMxOiBicGYgYXR0YWNoZWQKdWhjaTE6IHVzYnBm OiBBdHRhY2hlZApwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNy40IChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQgZGV2aWNlIDcuNSAobm8gZHJpdmVyIGF0 dGFjaGVkKQpybDA6IDxSZWFsVGVrIDgxMzkgMTAvMTAwQmFzZVRYPiBwb3J0IDB4ZTgwMC0weGU4 ZmYgbWVtIDB4ZWUwMDAwMDAtMHhlZTAwMDBmZiBpcnEgMTEgYXQgZGV2aWNlIDEyLjAgb24gcGNp MAptaWlidXMwOiA8TUlJIGJ1cz4gb24gcmwwCnJscGh5MDogPFJlYWxUZWsgaW50ZXJuYWwgbWVk aWEgaW50ZXJmYWNlPiBQSFkgMCBvbiBtaWlidXMwCnJscGh5MDogT1VJIDB4MDAwMDAwLCBtb2Rl bCAweDAwMDAsIHJldi4gMApybHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRY LCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJsMDogYnBmIGF0dGFjaGVkCnJsMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MDY6OTM6MzA6MDM6MTcKZndvaGNpMDogPEx1Y2VudCBGVzMyMi8zMjM+IG1lbSAw eGVlMDAxMDAwLTB4ZWUwMDFmZmYgaXJxIDUgYXQgZGV2aWNlIDE1LjAgb24gcGNpMApmd29oY2kw OiBPSENJIHZlcnNpb24gMS4wIChST009MSkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNo YW5uZWxzIGlzIDguCmZ3b2hjaTA6IEVVSTY0IDAwOjYwOjFkOjAwOjAwOjMwOjAyOmVkCmZ3b2hj aTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMyBwb3J0cy4KZndvaGNpMDogTGluayBTNDAw LCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+ IG9uIGZ3b2hjaTAKZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24gZmly ZXdpcmUwCmRjb25zX2Nyb20wOiBidXNfYWRkciAweDE1MTQwMDAKZndlMDogPEV0aGVybmV0IG92 ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMAppZl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6 IDAyOjYwOjFkOjMwOjAyOmVkCmZ3ZTA6IGJwZiBhdHRhY2hlZApmd2UwOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMjo2MDoxZDozMDowMjplZApmd2lwMDogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3 aXJlMApmd2lwMDogYnBmIGF0dGFjaGVkCmZ3aXAwOiBGaXJld2lyZSBhZGRyZXNzOiAwMDo2MDox ZDowMDowMDozMDowMjplZCBAIDB4ZmZmZTAwMDAwMDAwLCBTNDAwLCBtYXhyZWMgMjA0OApmd29o Y2kwOiBJbml0aWF0ZSBidXMgcmVzZXQKZndvaGNpMDogZndvaGNpX2ludHJfY29yZTogQlVTIHJl c2V0CmZ3b2hjaTA6IGZ3b2hjaV9pbnRyX2NvcmU6IG5vZGVfaWQ9MHgwMDAwMDAwMCwgU2VsZklE IENvdW50PTEsIENZQ0xFTUFTVEVSIG1vZGUKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQw LTB4NDMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzMgaXJx IDggb24gYWNwaTAKYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2sgKHJl c29sdXRpb24gMTAwMDAwMHVzLCBhZGp1c3RtZW50IDAuNTAwMDAwMDAwcykKRXZlbnQgdGltZXIg IlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNv bnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRj MDogaWNfdHlwZSA5MCBwYXJ0X2lkIDgwCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9y dCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQwOiBmYXN0IGludGVy cnVwdAp1YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMg b24gYWNwaTAKdWFydDE6IGZhc3QgaW50ZXJydXB0CnBwYzA6IHVzaW5nIGV4dGVuZGVkIEkvTyBw b3J0IHJhbmdlCnBwYzA6IFNQUCBFUFAKcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgzNzgt MHgzN2YgaXJxIDcgb24gYWNwaTAKcHBjMDogR2VuZXJpYyBjaGlwc2V0IChFUFAvTklCQkxFKSBp biBDT01QQVRJQkxFIG1vZGUKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKcGxp cDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKcGxpcDA6IGJwZiBhdHRhY2hl ZApscHQwOiA8UHJpbnRlcj4gb24gcHBidXMwCmxwdDA6IEludGVycnVwdC1kcml2ZW4gcG9ydApw cGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xs ZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5 Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVy IGNvbW1hbmQgYnl0ZSAwMDQ3CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQg YXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4 M2QwMDAwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogdW5hYmxlIHRvIGFsbG9jYXRlIElS UQpleF9pc2FfaWRlbnRpZnkoKQpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBs ZXRlCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEwMDAwLTB4YTA3ZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEwODAwLTB4YTBmZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGExMDAwLTB4YTE3ZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGExODAwLTB4YTFmZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEyMDAwLTB4YTI3ZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEyODAwLTB4YTJm ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEzMDAwLTB4 YTM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEzODAw LTB4YTNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE0 MDAwLTB4YTQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGE0ODAwLTB4YTRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGE1MDAwLTB4YTU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGE1ODAwLTB4YTVmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGE2MDAwLTB4YTY3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGE2ODAwLTB4YTZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGE3MDAwLTB4YTc3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGE3ODAwLTB4YTdmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGE4MDAwLTB4YTg3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE4ODAwLTB4YThmZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE5MDAwLTB4YTk3ZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE5ODAwLTB4YTlmZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFhMDAwLTB4YWE3ZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFhODAwLTB4YWFmZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFiMDAwLTB4YWI3ZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFiODAwLTB4YWJmZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFjMDAwLTB4YWM3 ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFjODAwLTB4 YWNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFkMDAw LTB4YWQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFk ODAwLTB4YWRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGFlMDAwLTB4YWU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGFlODAwLTB4YWVmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGFmMDAwLTB4YWY3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGFmODAwLTB4YWZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGIwMDAwLTB4YjA3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGIwODAwLTB4YjBmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGIxMDAwLTB4YjE3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGIxODAwLTB4YjFmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIyMDAwLTB4YjI3ZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIyODAwLTB4YjJmZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIzMDAwLTB4YjM3ZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIzODAwLTB4YjNmZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI0MDAwLTB4YjQ3ZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI0ODAwLTB4YjRmZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI1MDAwLTB4YjU3ZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI1ODAwLTB4YjVm ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI2MDAwLTB4 YjY3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI2ODAw LTB4YjZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI3 MDAwLTB4Yjc3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGI3ODAwLTB4YjdmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGI4MDAwLTB4Yjg3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGI4ODAwLTB4YjhmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGI5MDAwLTB4Yjk3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGI5ODAwLTB4YjlmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGJhMDAwLTB4YmE3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGJhODAwLTB4YmFmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGJiMDAwLTB4YmI3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJiODAwLTB4YmJmZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJjMDAwLTB4YmM3ZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJjODAwLTB4YmNmZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJkMDAwLTB4YmQ3ZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJkODAwLTB4YmRmZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJlMDAwLTB4YmU3ZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJlODAwLTB4YmVmZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJmMDAwLTB4YmY3 ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJmODAwLTB4 YmZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGMwMDAw LTB4YzA3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGMw MDAwLTB4Y2JmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGNjMDAwLTB4Y2M3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGNjMDAwLTB4Y2ZmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGQwMDAwLTB4ZDA3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGQwODAwLTB4ZDBmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGQxMDAwLTB4ZDE3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGQxODAwLTB4ZDFmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGQyMDAwLTB4ZDI3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGQyODAwLTB4ZDJmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQzMDAwLTB4ZDM3ZmYpIGZvciByaWQgMiBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQzODAwLTB4ZDNmZmYpIGZvciByaWQgMiBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0MDAwLTB4ZDQ3ZmYpIGZvciByaWQgMiBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0ODAwLTB4ZDRmZmYpIGZvciByaWQg MiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ1MDAwLTB4ZDU3ZmYpIGZvciBy aWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ1ODAwLTB4ZDVmZmYpIGZv ciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ2MDAwLTB4ZDY3ZmYp IGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ2ODAwLTB4ZDZm ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ3MDAwLTB4 ZDc3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ3ODAw LTB4ZDdmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ4 MDAwLTB4ZDg3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGQ4ODAwLTB4ZDhmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGQ5MDAwLTB4ZDk3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGQ5ODAwLTB4ZDlmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGRhMDAwLTB4ZGE3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGRhODAwLTB4ZGFmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGRiMDAwLTB4ZGI3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGRiODAwLTB4ZGJmZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGRjMDAwLTB4ZGM3ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRjODAwLTB4ZGNmZmYpIGZvciByaWQgMiBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRkMDAwLTB4ZGQ3ZmYpIGZvciByaWQgMiBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRkODAwLTB4ZGRmZmYpIGZvciByaWQgMiBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRlMDAwLTB4ZGU3ZmYpIGZvciByaWQg MiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRlODAwLTB4ZGVmZmYpIGZvciBy aWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRmMDAwLTB4ZGY3ZmYpIGZv ciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRmODAwLTB4ZGZmZmYp IGZvciByaWQgMiBvZiBvcm0wCmFoY19pc2FfcHJvYmUgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZh aWxlZAphaGNfaXNhX3Byb2JlIDE6IGlvcG9ydCAweDFjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2Ff cHJvYmUgMjogaW9wb3J0IDB4MmMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSAzOiBpb3Bv cnQgMHgzYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDQ6IGlvcG9ydCAweDRjMDAgYWxs b2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgNTogaW9wb3J0IDB4NWMwMCBhbGxvYyBmYWlsZWQKYWhj X2lzYV9wcm9iZSA2OiBpb3BvcnQgMHg2YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDc6 IGlvcG9ydCAweDdjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgODogaW9wb3J0IDB4OGMw MCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSA5OiBpb3BvcnQgMHg5YzAwIGFsbG9jIGZhaWxl ZAphaGNfaXNhX3Byb2JlIDEwOiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3By b2JlIDExOiBpb3BvcnQgMHhiYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEyOiBpb3Bv cnQgMHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEzOiBpb3BvcnQgMHhkYzAwIGFs bG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDE0OiBpb3BvcnQgMHhlYzAwIGFsbG9jIGZhaWxlZApp c2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwpwbXRpbWVyMCBvbiBpc2Ew CmF0YTogYXRhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRhOiBhdGExIGFscmVhZHkg ZXhpc3RzOyBza2lwcGluZyBpdAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBw aW5nIGl0CmF0cnRjOiBhdHJ0YzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0dGltZXI6 IGF0dGltZXIwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApmZGM6IGZkYzAgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0CnBwYzogcHBjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK c2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKdWFydDogdWFydDAgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0CnVhcnQ6IHVhcnQxIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0Eg T3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYmZmZiwweGNjMDAwLTB4Y2ZmZmYgcG5w aWQgT1JNMDAwMCBvbiBpc2EwCmZiOiBuZXcgYXJyYXkgc2l6ZSA0CnNjMDogPFN5c3RlbSBjb25z b2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVz LCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzY3Rla2Vu ICh0ZWtlbiB0ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUg NCAoMHgzYzAtMHgzZGYpIGZvciByaWQgMCBvZiB2Z2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGEwMDAwLTB4YmZmZmYpIGZvciByaWQgMCBvZiB2Z2EwCmlzYV9wcm9iZV9jaGlsZHJlbjog cHJvYmluZyBQblAgZGV2aWNlcwphY3BpX3Rocm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxpbmc+ IG9uIGNwdTAKYWNwaV90aHJvdHRsZTA6IGZhaWxlZCB0byBhdHRhY2ggUF9DTlQKZGV2aWNlX2F0 dGFjaDogYWNwaV90aHJvdHRsZTAgYXR0YWNoIHJldHVybmVkIDYKRGV2aWNlIGNvbmZpZ3VyYXRp b24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEu MDAwIG1zZWMKdmxhbjogaW5pdGlhbGl6ZWQsIHVzaW5nIGhhc2ggdGFibGVzIHdpdGggY2hhaW5p bmcKbG8wOiBicGYgYXR0YWNoZWQKaHB0cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmZpcmV3 aXJlMDogMSBub2RlcywgbWF4aG9wIDw9IDAgY2FibGUgSVJNIGlybSgwKSAgKG1lKSAKZmlyZXdp cmUwOiBidXMgbWFuYWdlciAwIAp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdWdlbjAuMTogPFZJQT4gYXQgdXNidXMw CnVodWIwOiA8VklBIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPFZJQT4gYXQgdXNidXMxCnVodWIxOiA8VklBIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKZmRj MDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDog b3V0cHV0IHJlYWR5IHRpbWVvdXQKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApm ZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMw OiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dAphdGEwOiBy ZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTA6IHN0YXQwPTB4NTAgZXJy PTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgw MCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEK KGFwcm9iZTA6YXRhMDowOjA6MCk6IFNJR05BVFVSRTogMDAwMAphdGExOiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTE6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4 MTQgbXNiPTB4ZWIKYXRhMTogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHhmZiBtc2I9MHhmZgph dGExOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDEwMDAwCihhcHJvYmUx OmF0YTE6MDowOjApOiBTSUdOQVRVUkU6IGViMTQKYWRhMCBhdCBhdGEwIGJ1cyAwIHNjYnVzMCB0 YXJnZXQgMCBsdW4gMAphZGEwOiA8SElUQUNISSBESzIzQ0EtMjAgMDBIMUEwQTM+IEFUQS01IGRl dmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIDEyTEIzMwphZGEwOiAxMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFVETUE1LCBQSU8gODE5MmJ5dGVzKQphZGEwOiAxOTA3N01CICgzOTA3MDA4MCA1MTIgYnl0 ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBh cyBhZDAKR0VPTTogbmV3IGRpc2sgYWRhMApwYXNzMCBhdCBhdGEwIGJ1cyAwIHNjYnVzMCB0YXJn ZXQgMCBsdW4gMApwYXNzMDogPEhJVEFDSEkgREsyM0NBLTIwIDAwSDFBMEEzPiBBVEEtNSBkZXZp Y2UKcGFzczA6IFNlcmlhbCBOdW1iZXIgMTJMQjMzCnBhc3MwOiAxMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFVETUE1LCBQSU8gODE5MmJ5dGVzKQpwYXNzMSBhdCBhdGExIGJ1cyAwIHNjYnVzMSB0YXJn ZXQgMCBsdW4gMApwYXNzMTogPE9JUC1TRCAyNDAwQS9CIDUuMjA+IFJlbW92YWJsZSBDRC1ST00g U0NTSS0wIGRldmljZSAKcGFzczE6IDMzLjMwME1CL3MgdHJhbnNmZXJzIChVRE1BMiwgQVRBUEkg MTJieXRlcywgUElPIDY1NTM0Ynl0ZXMpCmNkMCBhdCBhdGExIGJ1cyAwIHNjYnVzMSB0YXJnZXQg MCBsdW4gMApjZDA6IDxPSVAtU0QgMjQwMEEvQiA1LjIwPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0kt MCBkZXZpY2UgCmNkMDogMzMuMzAwTUIvcyB0cmFuc2ZlcnMgKFVETUEyLCBBVEFQSSAxMmJ5dGVz LCBQSU8gNjU1MzRieXRlcykKY2QwOiBjZCBwcmVzZW50IFs2NTc5MyB4IDIwNDggYnl0ZSByZWNv cmRzXQpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgOTk3NDc4NzkzIEh6IHF1YWxpdHkgODAw CkdFT006IG5ldyBkaXNrIGNkMAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgoo YWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgM2YgMDAgMDAgNDAgMDAgMDAg MDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJy b3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJy b3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAzZiAwMCAw MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAoo YWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVB RF9ETUEuIEFDQjogYzggMDAgM2YgMDAgMDAgNDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRh MDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6 IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQoo YWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAzZiAwMCAwMCAwMCAwMCAwMCAwMCAxMCAwMAoo YWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZApHRU9NOiBhZGEwczE6IG1lZGlhIHNp emUgZG9lcyBub3QgbWF0Y2ggbGFiZWwuCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVy cm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMCAwMCA0MCAw MCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1 cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIp LCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNm IDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21t YW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjAp OiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMCAwMCA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRh MDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6 MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJS VCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNmIDAwIDAwIDAwIDAwIDAwIDAwIDEw IDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjAp OiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAw MCAzZiAwMCAwMCA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0 YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEg KERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjAp OiBSRVM6IDUxIDg0IDNmIDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjAp OiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihh ZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMCAwMCA0MCAwMCAwMCAw MCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJv cgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJv cjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNmIDAwIDAw IDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCmZk YzA6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVvdXQKZmRjMDog aW5wdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBpbnB1 dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJl YWR5IHRpbWVvdXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dApmZGMwOiBpbnB1dCByZWFkeSB0 aW1lb3V0CmZkYzA6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVv dXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dAooY2QwOmF0YTE6MDowOjApOiBTQ1NJIHN0YXR1 cyBlcnJvcgooY2QwOmF0YTE6MDowOjApOiBSRUFEKDEwKS4gQ0RCOiAyOCAwIDAgMSAxIDAgMCAw IDEgMCAKKGNkMDphdGExOjA6MDowKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKGNk MDphdGExOjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlvbgooY2QwOmF0YTE6MDow OjApOiBTQ1NJIHNlbnNlOiBJTExFR0FMIFJFUVVFU1QgYXNjOjY0LDAgKElsbGVnYWwgbW9kZSBm b3IgdGhpcyB0cmFjaykKKGNkMDphdGExOjA6MDowKTogRXJyb3IgNiwgVW5yZXRyeWFibGUgZXJy b3IKKGNkMDphdGExOjA6MDowKTogY2Rkb25lOiBnb3QgZXJyb3IgMHg2IGJhY2sKKGFkYTA6YXRh MDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBB Q0I6IGM4IDAwIDNmIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjAp OiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3Rh dHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRh MDowOjA6MCk6IFJFUzogNTEgODQgM2YgMDAgMDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRh MDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMg ZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDNmIDAwIDAwIDQw IDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3Rh dHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVS UiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQg M2YgMDAgMDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNv bW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6 MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDNmIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihh ZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6 MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBB QlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgM2YgMDAgMDAgMDAgMDAgMDAgMDAg MTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6 MCk6IEFUQSBzdGF0dXMgZXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4 IDAwIDNmIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0g c3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1 MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6 MCk6IFJFUzogNTEgODQgM2YgMDAgMDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6 MCk6IFJldHJ5aW5nIGNvbW1hbmQKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXMgZXJyb3IK KGFkYTA6YXRhMDowOjA6MCk6IFJFQURfRE1BLiBBQ0I6IGM4IDAwIDNmIDAwIDAwIDQwIDAwIDAw IDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVy cm9yCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVy cm9yOiA4NCAoSUNSQyBBQlJUICkKKGFkYTA6YXRhMDowOjA6MCk6IFJFUzogNTEgODQgM2YgMDAg MDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IEVycm9yIDUsIFJldHJpZXMg ZXhoYXVzdGVkCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6 MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMiA0MCA0MCAwMCAwMCAwMCAwMCAxMCAw MAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDph dGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElD UkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNmIDAyIDQwIDAwIDAwIDAw IDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6 MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNC OiBjOCAwMCAzZiAwMiA0MCA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTog Q0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1 czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6 MDowOjApOiBSRVM6IDUxIDg0IDNmIDAyIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6 MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVy cm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMiA0MCA0MCAw MCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1 cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIp LCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNm IDAyIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21t YW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjAp OiBSRUFEX0RNQS4gQUNCOiBjOCAwMCAzZiAwMiA0MCA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRh MDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6 MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJS VCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDNmIDAyIDQwIDAwIDAwIDAwIDAwIDEw IDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjAp OiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAw MCAzZiAwMiA0MCA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0 YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEg KERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjAp OiBSRVM6IDUxIDg0IDNmIDAyIDQwIDAwIDAwIDAwIDAwIDEwIDAwCihhZGEwOmF0YTA6MDowOjAp OiBFcnJvciA1LCBSZXRyaWVzIGV4aGF1c3RlZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1 cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgM2YgMDIgNDAg NDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBT dGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYg RVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4 NCAzZiAwMiA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcg Y29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6 MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgM2YgMDIgNDAgNDAgMDAgMDAgMDAgMDAgMTAgMDAK KGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRh MDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JD IEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAzZiAwMiA0MCAwMCAwMCAwMCAw MCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6 MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjog YzggMDAgM2YgMDIgNDAgNDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENB TSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6 IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6 MDowKTogUkVTOiA1MSA4NCAzZiAwMiA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6 MDowKTogUmV0cnlpbmcgY29tbWFuZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJv cgooYWRhMDphdGEwOjA6MDowKTogUkVBRF9ETUEuIEFDQjogYzggMDAgM2YgMDIgNDAgNDAgMDAg MDAgMDAgMDAgMTAgMDAKKGFkYTA6YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMg RXJyb3IKKGFkYTA6YXRhMDowOjA6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwg ZXJyb3I6IDg0IChJQ1JDIEFCUlQgKQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAzZiAw MiA0MCAwMCAwMCAwMCAwMCAxMCAwMAooYWRhMDphdGEwOjA6MDowKTogUmV0cnlpbmcgY29tbWFu ZAooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1cyBlcnJvcgooYWRhMDphdGEwOjA6MDowKTog UkVBRF9ETUEuIEFDQjogYzggMDAgM2YgMDIgNDAgNDAgMDAgMDAgMDAgMDAgMTAgMDAKKGFkYTA6 YXRhMDowOjA6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMgRXJyb3IKKGFkYTA6YXRhMDowOjA6 MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDg0IChJQ1JDIEFCUlQg KQooYWRhMDphdGEwOjA6MDowKTogUkVTOiA1MSA4NCAzZiAwMiA0MCAwMCAwMCAwMCAwMCAxMCAw MAooYWRhMDphdGEwOjA6MDowKTogRXJyb3IgNSwgUmV0cmllcyBleGhhdXN0ZWQKVHJ5aW5nIHRv IG1vdW50IHJvb3QgZnJvbSBjZDk2NjA6L2Rldi9pc285NjYwL0ZSRUVCU0RfSU5TVEFMTCBbcm9d Li4uCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0CihhZGEwOmF0YTA6MDowOjApOiBBVEEg c3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCA4MCAw MSAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czog QVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkg U0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6 IDUxIDg0IDgwIDAxIDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRy eWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0 YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCA4MCAwMSAwMCA0MCAwMCAwMCAwMCAwMCA4 MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRh MDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQg KElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDgwIDAxIDAwIDAwIDAw IDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0 YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4g QUNCOiBjOCAwMCA4MCAwMSAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDow KTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0 YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0 YTA6MDowOjApOiBSRVM6IDUxIDg0IDgwIDAxIDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0 YTA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVz IGVycm9yCihhZGEwOmF0YTA6MDowOjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCA4MCAwMSAwMCA0 MCAwMCAwMCAwMCAwMCA4MCAwMAooYWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0 YXR1cyBFcnJvcgooYWRhMDphdGEwOjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBF UlIpLCBlcnJvcjogODQgKElDUkMgQUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0 IDgwIDAxIDAwIDAwIDAwIDAwIDAwIDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBSZXRyeWluZyBj b21tYW5kCihhZGEwOmF0YTA6MDowOjApOiBBVEEgc3RhdHVzIGVycm9yCihhZGEwOmF0YTA6MDow OjApOiBSRUFEX0RNQS4gQUNCOiBjOCAwMCA4MCAwMSAwMCA0MCAwMCAwMCAwMCAwMCA4MCAwMAoo YWRhMDphdGEwOjA6MDowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgooYWRhMDphdGEw OjA6MDowKTogQVRBIHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogODQgKElDUkMg QUJSVCApCihhZGEwOmF0YTA6MDowOjApOiBSRVM6IDUxIDg0IDgwIDAxIDAwIDAwIDAwIDAwIDAw IDgwIDAwCihhZGEwOmF0YTA6MDowOjApOiBFcnJvciA1LCBSZXRyaWVzIGV4aGF1c3RlZAo= --0016e6d460a63dfeae04bb879734-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 17:37:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C6F7106566B for ; Sun, 18 Mar 2012 17:37:30 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id EB4C58FC08 for ; Sun, 18 Mar 2012 17:37:29 +0000 (UTC) Received: from [109.84.90.253] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1S9K1x-0007tb-22 for freebsd-stable@freebsd.org; Sun, 18 Mar 2012 18:36:33 +0100 Date: Sun, 18 Mar 2012 18:35:11 +0100 From: Fabian Keil To: freebsd-stable@freebsd.org Message-ID: <20120318183511.7eba9b07@fabiankeil.de> In-Reply-To: References: <20120307174850.746a6b0a@fabiankeil.de> <20120309152253.17a108c2@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/7/643+MIPnBei0zG2g1A_MD"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: FreeBSD root on a geli-encrypted ZFS pool 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, 18 Mar 2012 17:37:30 -0000 --Sig_/7/643+MIPnBei0zG2g1A_MD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Matthew X. Economou" wrote: > Fabian Keil writes: > > Anyway, it's a test without file system so the ZFS overhead isn't > > measured. I wasn't entirely clear about it, but my assumption was > > that the ZFS overhead might be big enough to make the difference > > between HMAC/MD5 and HMAC/SHA256 a lot less significant. >=20 > Got it. That also makes sense. I'll put this on my to-test list.=20 Great. =20 > > I'm currently using sector sizes between 512 and 8192 so I'm not > > actually expecting technical problems, it's just not clear to me > > how much the sector size matters and if 4096 is actually the best > > value when using ZFS. >=20 > The geli(8) manual page claims that larger sector sizes lower the > overhead of GEOM_ELI keying initialization and encryption/decryption > steps by requiring fewer of these compute-intensive setup operations > per block. I think the setup operations per block should stay the same, but the total number of setup operations decrease if(f) increasing the sector size decreases the number of sectors required to write the data. That however should depend on the data and I don't see why increasing the sector size should always be an improvement. Geli can't read or write less than a sector, so if the workload is randomly reading or writing a few hundred bytes, a sector size of 512 bytes should be superior to a sector size of 4 kB. Probably a sector size of 4 kB is good for some workloads, but clearly it can't be the best for all, and it's not obvious to me that it's the best for most. Fabian --Sig_/7/643+MIPnBei0zG2g1A_MD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9mHNMACgkQBYqIVf93VJ0PrwCfV4EpKP+Ax9/QfE7ThmR2vLfx KI0AniN8fRkPSvbnKKwykX0xdx9x+miA =Y3Kl -----END PGP SIGNATURE----- --Sig_/7/643+MIPnBei0zG2g1A_MD-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 18:18:48 2012 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 86F09106566C; Sun, 18 Mar 2012 18:18:48 +0000 (UTC) (envelope-from prvs=142406e4fa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id E16A78FC0C; Sun, 18 Mar 2012 18:18:47 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Sun, 18 Mar 2012 18:18:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018885984.msg; Sun, 18 Mar 2012 18:18:30 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=142406e4fa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> From: "Steven Hartland" To: "Dmitry Morozovsky" References: Date: Sun, 18 Mar 2012 18:18:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 18:18:48 -0000 ----- Original Message ----- From: "Dmitry Morozovsky" > Well, ahci problem solved, but I still have much worse performance (and > different on ada0 and ada1!): > ada0, MC 50-60 MBps > ada1, MC 13-25 MBps > ada*, 5017 130+ MBps > > Could you please post SATA/AHCI BIOS settings from your machines? Thanks a lot! Just AHCI configured as far as I remember. What you mean by MC vs 5017? How are you measuring disk speed? What value do you have for sysctl vfs.read_max? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 18:36:52 2012 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 A7BF31065670 for ; Sun, 18 Mar 2012 18:36:52 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (unknown [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 617178FC0A for ; Sun, 18 Mar 2012 18:36:52 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id q2IIalon061752 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 18 Mar 2012 14:36:48 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4F662B38.4030700@FreeBSD.org> Date: Sun, 18 Mar 2012 14:36:40 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120302 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adam Strohl References: <4F5B0BB5.5010406@ateamsystems.com> <6D0B99CE-AE11-4250-A8D9-EF66E03E19BB@lists.zabbadoz.net> <4F5B5DAB.3010905@ateamsystems.com> In-Reply-To: <4F5B5DAB.3010905@ateamsystems.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Sun, 18 Mar 2012 14:36:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: "Bjoern A. Zeeb" , FreeBSD-Stable ML Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 18 Mar 2012 18:36:52 -0000 On 03/10/12 08:56, Adam Strohl wrote: > On 3/10/2012 17:10, Bjoern A. Zeeb wrote: >> On 10. Mar 2012, at 08:07 , Adam Strohl wrote: >> >>> I've now seen this on two different VMs on two different ESXi servers >>> (Xeon based hosts but different hardware otherwise and at different >>> facilities): >>> >>> Everything runs fine for weeks then (seemingly) suddenly/randomly the >>> clock STOPS. >> >> Apart from the ntp vs. openvm-tools thing, do you have an idea what >> "for weeks" means in more detail? Can you check based on last/daily >> mails/.. how many days it was since last reboot to a) see if it's >> close to a integer wrap-around or b) to give anyone who wants to >> reproduce this maybe a clue on how long they'll have to wait? For >> that matter, is it a stock 9.0 or your own kernel? What other modules >> are loaded? > > Uptime was 31 days on the first incident / server (occurred 5 days ago) > Uptime was 4 days on the second incident / server (occurred last night) > I've experienced something similar once or twice with ESXi 5.0. The second time it happened, I found that kern.timecounter.tc.HPET.counter stopped changing. I was told on IRC that this indicated a "hardware" problem, which I took to indicate a possible bug in ESXi. I haven't upgraded to ESXi 5.0 Update 1 yet to see if that changes anything. Rebooting of course fixed it, it has been a while since this happened and it hasn't happened again since so I haven't pursued it. Just another data point, hope it hopes. Steve From owner-freebsd-stable@FreeBSD.ORG Sun Mar 18 20:45:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A1301065670; Sun, 18 Mar 2012 20:45:04 +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 B575E8FC0C; Sun, 18 Mar 2012 20:45:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2IKj2JB074609; Mon, 19 Mar 2012 00:45:02 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 19 Mar 2012 00:45:02 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (woozle.rinet.ru [0.0.0.0]); Mon, 19 Mar 2012 00:45:02 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 20:45:04 -0000 On Sun, 18 Mar 2012, Steven Hartland wrote: > > different on ada0 and ada1!): > > ada0, MC 50-60 MBps ada1, MC 13-25 MBps > > ada*, 5017 130+ MBps > > > > Could you please post SATA/AHCI BIOS settings from your machines? Thanks a > > lot! > > Just AHCI configured as far as I remember. Microcloud has AFAIR additional settings for delaying disk spin and enablink/disabling hotswap, but mangling these options does not change anything for me > What you mean by MC vs 5017? platform name: MicroCloud vs 5017C-MTF, both based on the same chipset > How are you measuring disk speed? the simplest: dd if=/dev/ada0 of=/dev/null bs=1m count=16k (linear read 16g at the beginning of disk) > What value do you have for sysctl vfs.read_max? default for both cases, 8 -- 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 Sun Mar 18 21:49:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 310A8106566B; Sun, 18 Mar 2012 21:49:10 +0000 (UTC) (envelope-from prvs=142406e4fa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 907178FC0A; Sun, 18 Mar 2012 21:49:09 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Sun, 18 Mar 2012 21:48:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018888167.msg; Sun, 18 Mar 2012 21:48:10 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=142406e4fa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Dmitry Morozovsky" References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> Date: Sun, 18 Mar 2012 21:48:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 18 Mar 2012 21:49:10 -0000 ----- Original Message ----- From: "Dmitry Morozovsky" To: "Steven Hartland" Cc: ; Sent: Sunday, March 18, 2012 8:45 PM Subject: Re: ahci hangs on Supermicro MicroCloud second channel > On Sun, 18 Mar 2012, Steven Hartland wrote: > >> > different on ada0 and ada1!): >> > ada0, MC 50-60 MBps ada1, MC 13-25 MBps >> > ada*, 5017 130+ MBps >> > >> > Could you please post SATA/AHCI BIOS settings from your machines? Thanks a >> > lot! >> >> Just AHCI configured as far as I remember. > > Microcloud has AFAIR additional settings for delaying disk spin and > enablink/disabling hotswap, but mangling these options does not change anything > for me > >> What you mean by MC vs 5017? > > platform name: MicroCloud vs 5017C-MTF, both based on the same chipset > >> How are you measuring disk speed? > > the simplest: dd if=/dev/ada0 of=/dev/null bs=1m count=16k (linear read > 16g at the beginning of disk) I'm seeing the following here:- * ada0: ATA-8 SATA 2.x device: gives 109MB/s * ada1: ATA-8 SATA 3.x device: gives 114MB/s So both pretty reasonable although not fantastic. >> What value do you have for sysctl vfs.read_max? > > default for both cases, 8 Try 32 that's what we have here set here. Not sure its been released yet but we where running a pre-release BIOS which added the ability to disabled C1E, which caused us CPU performance issue in are particular environment. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 19 02:20:39 2012 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 5F0F3106564A for ; Mon, 19 Mar 2012 02:20:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4678FC17 for ; Mon, 19 Mar 2012 02:20:38 +0000 (UTC) Received: by dald2 with SMTP id d2so9829047dal.13 for ; Sun, 18 Mar 2012 19:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HJo45CwYzk2rACUO/XTmygDhqHkdAv4aXW7aV6Ubqk0=; b=1C47swghnQC4R5ccmAcgir7ohMJO9QPloGA91WRmrLuCoEX4xRoaijq/VjAPqXxjQa pYoxX1UQM8TqliOBltnrKEXRGidNdeLrJxpIMsu2Wer3XRqLHDV1znWn6KCEpQXFQ5Yg 6wjEYY+a7ychlvAZSK5zcCXBb18MtR+R0Idj2utbwHaJWN8Fh4qutQ0KE57OXzU5BDh6 A3RnofRYpm8o2+iRZ6nFYT+OTIxoSegxZSo5/QXyzUFfvQdc/JwTThtOu5prrwORoYHu TOVEsxhjXQGYB3ohRC6G8A6sx1pRdTEShkFzD9nKZ72j0XIRi2UpWdk+Qo/FtxWCnKRa ZBwA== Received: by 10.68.241.226 with SMTP id wl2mr30380640pbc.139.1332123638756; Sun, 18 Mar 2012 19:20:38 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id j3sm10143189pbb.29.2012.03.18.19.20.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 19:20:38 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 19 Mar 2012 11:20:32 -0700 From: YongHyeon PYUN Date: Mon, 19 Mar 2012 11:20:32 -0700 To: Mike Tancsa Message-ID: <20120319182032.GA7518@michelle.cdnetworks.com> References: <4F63A772.30406@sentex.net> <20120317225858.GA1660@michelle.cdnetworks.com> <4F65401B.303@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F65401B.303@sentex.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-STABLE Mailing List Subject: Re: fxp entering promiscuous mode causing link to bounce X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 02:20:39 -0000 On Sat, Mar 17, 2012 at 09:53:31PM -0400, Mike Tancsa wrote: > On 3/17/2012 6:58 PM, YongHyeon PYUN wrote: > > On Fri, Mar 16, 2012 at 04:49:54PM -0400, Mike Tancsa wrote: > >> > >> tcpdump -ni fxp0 -c 20 > >> > >> fxp0: link state changed to DOWN > >> fxp0: promiscuous mode enabled > >> fxp0: link state changed to UP > >> fxp0: link state changed to DOWN > >> fxp0: promiscuous mode disabled > >> fxp0: link state changed to UP > >> > >> I verified it on 2 different boxes. Is there a way to prevent this from happening ? > >> > > > > It looks like a regression introduced in flow control support. > > > Thanks very much, that indeed did fix it!! > > > 0(smtp1)# patch < fxp.p > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/dev/fxp/if_fxp.c > |=================================================================== > |--- sys/dev/fxp/if_fxp.c (revision 233076) > |+++ sys/dev/fxp/if_fxp.c (working copy) > -------------------------- > Patching file sys/dev/fxp/if_fxp.c using Plan A... > Hunk #1 succeeded at 900 (offset -2 lines). > Hunk #2 succeeded at 2808 (offset -2 lines). > Hunk #3 succeeded at 2914 (offset -2 lines). > > > fxp0: promiscuous mode enabled > fxp0: promiscuous mode disabled > > ... and not bounced link/dropped packets. Thanks for testing. Committed in r233158. fxp(4) controllers require controller reinitialization for promiscuous mode change so it's normal to miss packets during that transition. fxp(4) controllers have many limitation and this is one of them. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 19 06:26:39 2012 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 8480A106566C; Mon, 19 Mar 2012 06:26:39 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 656228FC0A; Mon, 19 Mar 2012 06:26:39 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 9F639B9066; Mon, 19 Mar 2012 02:20:31 -0400 (EDT) Message-ID: <4F66D033.9050103@ateamsystems.com> Date: Mon, 19 Mar 2012 13:20:35 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Steve Wills References: <4F5B0BB5.5010406@ateamsystems.com> <6D0B99CE-AE11-4250-A8D9-EF66E03E19BB@lists.zabbadoz.net> <4F5B5DAB.3010905@ateamsystems.com> <4F662B38.4030700@FreeBSD.org> In-Reply-To: <4F662B38.4030700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD-Stable ML Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 19 Mar 2012 06:26:39 -0000 On 3/12/2012 0:01, Ian Lepore wrote: > It seems unlikely to me that ntpd and the vm tools would be fighting in > a way that caused this symptom. The way ntpd affects timing is to step > the clock (which gets logged), or to numerically steer the kernel's > timekeeping routines. The steering is clamped at 500 ppm; to make the > clock appear to stop it would have to steer at 1e6 ppm. I've always > assumed that VM guest services daemons that handle timekeeping use the > same ntp_adjtime() interface to the kernel timekeeping that ntpd itself > uses, so the same steering limits would apply. An excellent point. > > If it happens again, interesting data might be found in the output of: > > sysctl kern.timecounter > sysctl kern.eventtimer > vmstat -i > ntpdc -c kerninfo > Will do, I know there was nothing in dmesg, I will definitely check all of this though if/when it happens again. I just brought up another ESXi 5.0 host with FreeBSD 9.0 VMs (created from dump/restore from the existing ones), so there is an increased chance of me seeing this hopefully and getting to the bottom of it. Or it never happens again :P On 3/19/2012 1:36, Steve Wills wrote: > I've experienced something similar once or twice with ESXi 5.0. The > second time it happened, I found that kern.timecounter.tc.HPET.counter > stopped changing. I was told on IRC that this indicated a "hardware" > problem, which I took to indicate a possible bug in ESXi. I haven't > upgraded to ESXi 5.0 Update 1 yet to see if that changes anything. > Rebooting of course fixed it, it has been a while since this happened > and it hasn't happened again since so I haven't pursued it. Just another > data point, hope it hopes. Thanks for the info! I didn't realize there was an update out already for 5.0 (I don't see it on VMWare's site). From owner-freebsd-stable@FreeBSD.ORG Mon Mar 19 08:42:18 2012 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 2ABB4106566B; Mon, 19 Mar 2012 08:42:18 +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 A19FE8FC16; Mon, 19 Mar 2012 08:42:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2J8g9Yf054125; Mon, 19 Mar 2012 12:42:10 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 19 Mar 2012 12:42:09 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (woozle.rinet.ru [0.0.0.0]); Mon, 19 Mar 2012 12:42:10 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 19 Mar 2012 08:42:18 -0000 On Sun, 18 Mar 2012, Steven Hartland wrote: [snip] > Not sure its been released yet but we where running a pre-release BIOS which > added the ability to disabled C1E, which caused us CPU performance issue in > are particular environment. This sounds interesting. Could you please share some links? Our MicroCloud blades have BIOS 1.0a, which is the latest mentioned at SuperMicro site. Thanks! -- 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 Mon Mar 19 10:01:15 2012 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 19D0B106564A; Mon, 19 Mar 2012 10:01:15 +0000 (UTC) (envelope-from prvs=1425ebc7df=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8E16D8FC12; Mon, 19 Mar 2012 10:01:10 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 19 Mar 2012 10:01:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018892455.msg; Mon, 19 Mar 2012 10:01:04 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1425ebc7df=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> From: "Steven Hartland" To: "Dmitry Morozovsky" References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> Date: Mon, 19 Mar 2012 10:01:07 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_077E_01CD05B7.3416DCC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 19 Mar 2012 10:01:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_077E_01CD05B7.3416DCC0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dmitry Morozovsky" To: "Steven Hartland" Cc: ; Sent: Monday, March 19, 2012 8:42 AM Subject: Re: ahci hangs on Supermicro MicroCloud second channel > On Sun, 18 Mar 2012, Steven Hartland wrote: > > > [snip] > >> Not sure its been released yet but we where running a pre-release BIOS which >> added the ability to disabled C1E, which caused us CPU performance issue in >> are particular environment. > > This sounds interesting. Could you please share some links? Our MicroCloud > blades have BIOS 1.0a, which is the latest mentioned at SuperMicro site. Its 1.0b, I'm sure if you ask Supermicro for it they will provide otherwise I'll fire it to you on private email. Attached are screenshots of the relevant bios pages in case you want to check those too. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_077E_01CD05B7.3416DCC0-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 19 10:06:28 2012 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 EA4721065678 for ; Mon, 19 Mar 2012 10:06:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4C98FC0C for ; Mon, 19 Mar 2012 10:06:27 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S9ZUJ-00057P-Qu; Mon, 19 Mar 2012 14:06:51 +0400 Date: Mon, 19 Mar 2012 14:06:51 +0400 From: Slawa Olhovchenkov To: "Patrick M. Hausen" Message-ID: <20120319100651.GA61230@zxy.spb.ru> References: <20120316172006.GM97848@zxy.spb.ru> <20120316174233.GN52973@zxy.spb.ru> <114CC851-7F85-470D-B203-5B2E9E35B7BD@punkt.de> <20120316201332.GN97848@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120316201332.GN97848@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: ZFS & NFS 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, 19 Mar 2012 10:06:28 -0000 On Sat, Mar 17, 2012 at 12:13:32AM +0400, Slawa Olhovchenkov wrote: > On Fri, Mar 16, 2012 at 07:34:56PM +0100, Patrick M. Hausen wrote: > > > Hello, > > > > Am 16.03.2012 um 18:42 schrieb Slawa Olhovchenkov: > > > On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote: > > > > > >> Hello, > > >> > > >> Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: > > >>> I do NFSv3 export of ZFS. > > >>> root from remote host create files on ZFS witch uid 2^32-2: > > >>> > > >>> # ls -l /usr/ports/packages32/ > > >>> total 6 > > >>> drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All > > >>> drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest > > >>> drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers > > >>> drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang > > >> > > >> > > >> Yes? This is expected behaviour of NFS. If you don't want that, try > > >> > > >> -maproot=root > > >> > > >> either in sharenfs option to zfs or /etc/exports, whichever it is you are using. > > > > > > hmm... > > > nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin > > > > > > 65534 != 4294967294 (2^16-2 != 2^32-2) > > > > > > Also, I am think ZFS+NFS will be wrong for UID>2^15. > > > > I admit I overlooked that one (16 vs 32 bits). But if I'm not mistaken, NFS does not care > > a bit about the name of the user "nobody" or the UID in /etc/passwd or what-have-you. > > It simply sets the UID of remote root (UID 0) to the value -1. > > https://blogs.oracle.com/taylor22/entry/nfs_root_access_on_sun > > === > In a default configuration, a Solaris NFS server maps "root" access to > "nobody". > === > > http://pubs.opengroup.org/onlinepubs/9629799/chap12.htm#tagcjh_13_03_03 > > === > In some operating systems, a particular user (on UNIX systems, the > user ID 0) has access to all files, no matter what permission and > ownership they have. This super-user permission might not be allowed > on the server, since anyone who can become super-user on their client > could gain access to all remote files. A UNIX server by default maps > user ID 0 to a distinguished value (UID_NOBODY), as well as mapping > the groups list, before doing its access checking. A server > implementation may provide a mechanism to change this mapping. This > works except for NFS Version 3 protocol root file systems (required > for diskless NFS Version 3 protocol client support), where super-user > access cannot be avoided. Export options are used, on the server, to > restrict the set of clients allowed super-user access. > === > > /usr/include/sys/_types.h:typedef __uint32_t __uid_t; > > > And 4294967294 happens to be -1 in 32 bits signed. So - possibly this is built into > > ZFS this way. I would at least give the sharenfs="..." options a try ... > > 4294967294 happens to be -2 in 32 bits signed. > And I see type of UID (uid_t) is unsigned. And also, /usr/include/sys/conf.h:#define UID_NOBODY 65534 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 05:26:53 2012 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 7C394106566C for ; Tue, 20 Mar 2012 05:26:53 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 107858FC17 for ; Tue, 20 Mar 2012 05:26:52 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so3746522wib.13 for ; Mon, 19 Mar 2012 22:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=18p9rfDwXVml3/GBfqxe4kj10e3/P+IdvfUd8+QluHs=; b=oRO8pAhtLwMSUb0SGK+hb36SSWlCt39wihkguN2wBtBysbiLxuPyFWchRk2Zduy5Nt Btd8qwD6HZivF9RkrP2eBn19q/0aen6xlLB0cBS8LefDgdPDIF3Wwp/Dp4ReEJxhvgIs 8MrYJ3v1YN1Wn774mlv5sjzxdUi6WEa42PBUeG4kKnFFOda1INB4FgWhujSVPKpy2SP+ enc6KOu5acW1vDQI7C2uARL/V7dAIlCMnvQuDTUFae5I1QYWre3hKsDXG1rRLb9lxNlg rvm4myH7eu6vn7LiPzrzYQVjJDTRwBedZV1kp3i8OEuAlPeqWDwivnUcxpfyIaFch16q kLDA== MIME-Version: 1.0 Received: by 10.216.132.8 with SMTP id n8mr8397445wei.36.1332221212275; Mon, 19 Mar 2012 22:26:52 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Mon, 19 Mar 2012 22:26:52 -0700 (PDT) Date: Tue, 20 Mar 2012 15:56:52 +1030 Message-ID: From: Matt Thyer To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 05:26:53 -0000 I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to r232477 (4th Mar 2012) and am finding that a system process called "intr" is now constantly using about 60% of 1 CPU starting a short time after reboot (possibly triggered by use of the samba server). When this starts, systat -vm 1 says that the system is 85% idle and 14% interrupt handling. It says that there's around 157k interrupts per second. After a reboot the system is back to it's normal state doing between 3 and 250 or so interrupts per second. The hardware is an Intel Core i3-530 (dual core @ 2.93 GHz with Hyperthreading) with 8 GB RAM (2x4GB) on a Gigabyte H55M-D2H rev 1.3 motherboard running the latest BIOS (F4). The system runs a GENERIC kernel with the following significant items in /boot/loader.conf: zfs_load="YES" aio_load="YES" ahci_load="YES" geom_mirror_load="YES" vfs.root.mountfrom="zfs:zroot" vboxdrv_load="YES" It has 2 x 300 GB disks for the system with GPT partitioning and zmirror for the OS ala http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror I have swap on a gmirror as I want swap to survive the loss of one system disk. The NAS data is on a raidz2 pool of 8 disks connected to a SuperMicro AOC-USAS2-L8i (flashed to behave as an AOC-USAS2-L8e). The system is basically a CIFS NAS with ports/net/samba36 built with AIO_SUPPORT and configured like: socket options = SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY min receivefile size=16384 use sendfile=true aio read size = 16384 aio write size = 16384 aio write behind = true The only other interesting workload on the box is a java Minecraft server using ports/java/jdk16. I'm going to try to reproduce the problem in a VM and binary search down to the revision where it started as soon as I can work out a reliable way to trigger the behaviour (as it doesn't start at boot time). Any idea what could be the cause ? From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 10:37:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5F4E106566C for ; Tue, 20 Mar 2012 10:37:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 775DB8FC15 for ; Tue, 20 Mar 2012 10:37:50 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S9wRj-0002MS-2P for freebsd-stable@freebsd.org; Tue, 20 Mar 2012 11:37:43 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 11:37:43 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 11:37:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 20 Mar 2012 11:37:33 +0100 Lines: 39 Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig093485B6452826891A3962FF" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 20 Mar 2012 10:37:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig093485B6452826891A3962FF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18/03/2012 22:48, Steven Hartland wrote: >=20 > ----- Original Message ----- From: "Dmitry Morozovsky" = >> the simplest: dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m count=3D16k (li= near >> read 16g at the beginning of disk) >>> What value do you have for sysctl vfs.read_max? >> >> default for both cases, 8 >=20 > Try 32 that's what we have here set here. vfs.read_max will only affect file system reads, not raw device reads. --------------enig093485B6452826891A3962FF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9oXe0ACgkQldnAQVacBcj3xQCgguP5SgJoStbzFnCvSU+RG9F/ Z7kAnAycqTJDMO2awTRSAPVZh2KPznnA =krXy -----END PGP SIGNATURE----- --------------enig093485B6452826891A3962FF-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 10:43:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A86B106564A for ; Tue, 20 Mar 2012 10:43:00 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id F2F118FC0A for ; Tue, 20 Mar 2012 10:42:59 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S9wWj-000568-VA for freebsd-stable@freebsd.org; Tue, 20 Mar 2012 11:42:53 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 11:42:53 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 11:42:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 20 Mar 2012 11:42:43 +0100 Lines: 38 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig598A5D2DAC2144895726025A" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 10:43:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig598A5D2DAC2144895726025A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20/03/2012 06:26, Matt Thyer wrote: > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > r232477 (4th Mar 2012) and am finding that a system process called "int= r" > is now constantly using about 60% of 1 CPU starting a short time after > reboot (possibly triggered by use of the samba server). >=20 > When this starts, systat -vm 1 says that the system is 85% idle and 14%= > interrupt handling. > It says that there's around 157k interrupts per second. >=20 Ok, but *which* interrupt is getting triggered? Please send the output of "vmstat -i". --------------enig598A5D2DAC2144895726025A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9oXyMACgkQldnAQVacBcgtMACgtDzmxiilfMi5MEeFMZLlA2Ht fqgAnRXsLd9qziwaOfi+aSmqsOOAmYl5 =zwhq -----END PGP SIGNATURE----- --------------enig598A5D2DAC2144895726025A-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 11:52:37 2012 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 4C64B106564A; Tue, 20 Mar 2012 11:52:37 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id A63EC8FC0A; Tue, 20 Mar 2012 11:52:36 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so4040050wib.13 for ; Tue, 20 Mar 2012 04:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uTJv0SMOSOwZY0a47ffeiVqBOgVS08JERrWGyFrl7jo=; b=A1li8xWX+zVYgHLmxltjaEscbSRWL68ia2xjl7tdEwQ4XgKOLqr/cuObQCdfq4Str7 THJdW2s4/+G8EV+Tnf+wyW0Xxm+/w8x+2xk75LxVJtBbAZyn/RkuS5/GxnJHnSDAujBx v4ptlBZhZ/nCdKSzW9sSDsrEo9xQ5euUJJCVvl8HmymDJmDecV2vEO12iuU1W7Q0P3rF SkD/lDDcvpgHFvb/ymc1arkbxqCyLLEnpqI1T5SVtgKBAPzQfa0rxqFiLMr6ObvUVGRV 4eekzJScf0jJ7WuBMPCJU70+ID/eRZ65G6tZx/w32w0NJqAtBFPP1XPfO15KFcakpSKp JGVw== MIME-Version: 1.0 Received: by 10.180.73.143 with SMTP id l15mr28012395wiv.11.1332244355623; Tue, 20 Mar 2012 04:52:35 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Tue, 20 Mar 2012 04:52:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 22:22:35 +1030 Message-ID: From: Matt Thyer To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 11:52:37 -0000 On 20 March 2012 21:12, Ivan Voras wrote: > On 20/03/2012 06:26, Matt Thyer wrote: > > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > > r232477 (4th Mar 2012) and am finding that a system process called "intr" > > is now constantly using about 60% of 1 CPU starting a short time after > > reboot (possibly triggered by use of the samba server). > > > > When this starts, systat -vm 1 says that the system is 85% idle and 14% > > interrupt handling. > > It says that there's around 157k interrupts per second. > > > > Ok, but *which* interrupt is getting triggered? Please send the output > of "vmstat -i". > > > interrupt total rate irq16: uhci0+ 3392184862 126692 cpu0: timer 53549677 1999 irq256: mps0 2643187 98 irq257: re0 5508108 205 irq258: ahci0 160717 6 cpu1: timer 53525300 1999 cpu2: timer 53525300 1999 cpu3: timer 53525296 1999 Total 3614622447 134999 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 11:55:08 2012 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 7DC55106564A for ; Tue, 20 Mar 2012 11:55:08 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 342748FC15 for ; Tue, 20 Mar 2012 11:55:07 +0000 (UTC) Received: by ggnk4 with SMTP id k4so7440905ggn.13 for ; Tue, 20 Mar 2012 04:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=jK24KJdhR7PUhzDGdGR/xhT6/NNCyYcJPkTu1pd6CZQ=; b=XbHHkYuvBptUP+VI5EVctg3F35yHM7UTiZCIo4rYOZoiX11g73IMMkSV6RCZS4ivK7 6IqIhfqvBdf7UJRTlLL94g+Cy4sEuf56lrNEp+W+w+PoALym6MMVtn7NF30YD2rCC6SR gsElowhsLvan/wDTJW2XKuQu9aBJo4KhMcNTicDZB24sD3nnZtqV+lWvgl3rYDYmk6Uh DrQUB1uItRiOKZW9x78ZtF0pfa+HyE0by2Cx+L4bSd7PndrcIxZROSVfJ+I0nErfwao9 s0eUbuzLBbpHNnfccrs7ZAMDmSytMCijAvEi2Af14TXeK2Otl30aFc4Av9FAaHRbQLPm fuHA== Received: by 10.236.195.38 with SMTP id o26mr16024563yhn.100.1332244507497; Tue, 20 Mar 2012 04:55:07 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.101.85.16 with HTTP; Tue, 20 Mar 2012 04:54:27 -0700 (PDT) In-Reply-To: References: From: Ivan Voras Date: Tue, 20 Mar 2012 12:54:27 +0100 X-Google-Sender-Auth: UMdOOzWuWwMeXL5JSwQJDB3oIg4 Message-ID: To: Matt Thyer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 11:55:08 -0000 T24gMjAgTWFyY2ggMjAxMiAxMjo1MiwgTWF0dCBUaHllciA8bWF0dC50aHllckBnbWFpbC5jb20+ IHdyb3RlOgo+IE9uIDIwIE1hcmNoIDIwMTIgMjE6MTIsIEl2YW4gVm9yYXMgPGl2b3Jhc0BmcmVl YnNkLm9yZz4gd3JvdGU6Cj4+Cj4+IE9uIDIwLzAzLzIwMTIgMDY6MjYsIE1hdHQgVGh5ZXIgd3Jv dGU6Cj4+ID4gSSd2ZSB1cGdyYWRlZCBteSBGcmVlQlNELVNUQUJMRSBOQVMgZnJvbSByMjI1NzIz ICgyMm5kIFNlcHQgMjAxMSkgdG8KPj4gPiByMjMyNDc3ICg0dGggTWFyIDIwMTIpIGFuZCBhbSBm aW5kaW5nIHRoYXQgYSBzeXN0ZW0gcHJvY2VzcyBjYWxsZWQKPj4gPiAiaW50ciIKPj4gPiBpcyBu b3cgY29uc3RhbnRseSB1c2luZyBhYm91dCA2MCUgb2YgMSBDUFUgc3RhcnRpbmcgYSBzaG9ydCB0 aW1lIGFmdGVyCj4+ID4gcmVib290IChwb3NzaWJseSB0cmlnZ2VyZWQgYnkgdXNlIG9mIHRoZSBz YW1iYSBzZXJ2ZXIpLgo+PiA+Cj4+ID4gV2hlbiB0aGlzIHN0YXJ0cywgc3lzdGF0IC12bSAxIHNh eXMgdGhhdCB0aGUgc3lzdGVtIGlzIDg1JSBpZGxlIGFuZCAxNCUKPj4gPiBpbnRlcnJ1cHQgaGFu ZGxpbmcuCj4+ID4gSXQgc2F5cyB0aGF0IHRoZXJlJ3MgYXJvdW5kIDE1N2sgaW50ZXJydXB0cyBw ZXIgc2Vjb25kLgo+PiA+Cj4+Cj4+IE9rLCBidXQgKndoaWNoKiBpbnRlcnJ1cHQgaXMgZ2V0dGlu ZyB0cmlnZ2VyZWQ/IFBsZWFzZSBzZW5kIHRoZSBvdXRwdXQKPj4gb2YgInZtc3RhdCAtaSIuCj4+ Cj4+Cj4gaW50ZXJydXB0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgdG90YWzCoMKgwqDCoMKgwqAgcmF0ZQo+IGlycTE2OiB1aGNpMCvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAzMzkyMTg0ODYywqDCoMKgwqAgMTI2NjkyCgpPaywgc29t ZXRoaW5nJ3MgcHJvYmFibHkgd3Jvbmcgd2l0aCBVU0IuIENhbiB5b3UgZGlzYWJsZSBpdCBpbiBC SU9TPwoKCj4gY3B1MDogdGltZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDUzNTQ5Njc3wqDCoMKgwqDCoMKgIDE5OTkKPiBpcnEyNTY6IG1wczDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDI2NDMxODfCoMKgwqDCoMKgwqDCoMKgIDk4Cj4g aXJxMjU3OiByZTDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNTUw ODEwOMKgwqDCoMKgwqDCoMKgIDIwNQo+IGlycTI1ODogYWhjaTDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE2MDcxN8KgwqDCoMKgwqDCoMKgwqDCoCA2Cj4gY3B1MTog dGltZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDUzNTI1MzAwwqDC oMKgwqDCoMKgIDE5OTkKPiBjcHUyOiB0aW1lcsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgNTM1MjUzMDDCoMKgwqDCoMKgwqAgMTk5OQo+IGNwdTM6IHRpbWVywqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA1MzUyNTI5NsKgwqDCoMKgwqDCoCAx OTk5Cj4gVG90YWzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgMzYxNDYyMjQ0N8KgwqDCoMKgIDEzNDk5OQo+Cg== From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 12:40:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DA111065676; Tue, 20 Mar 2012 12:40:12 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id EA21C8FC14; Tue, 20 Mar 2012 12:40:11 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so4039217wib.13 for ; Tue, 20 Mar 2012 05:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/iOAy8RETBmW/dbEMHyBWoat4djhJodnakcW/vESRdQ=; b=nfYEry7lOijvwHP1alZSO1yMs2PvEL/EEeUfBEsR+glWP1VMYkldvv1Kamhvp3CUFO bvog0QhrDOqsi3PMuKn4ZBO6G+kS36w9ZAuDwDI3Uwn7YTdCdBY0xOVc+cCq9j2htWh5 1j5V60ULJyPV3gE7OtXr9jT4sp7lXxZJXMZLf6xdtLDyDDRMkm4tjr9SwDPkSgPbZ5tN 0xT+mqZZKA634jof+CP3v5aCatBz6bkXpUpoce6N7HeG6zkT7cnwPpsL2x3jDFRsBDci 2jLdr8/DX60L6Dcd/D8jT20dU42SjwZ/h/yg2cp80t96KWleGGkQco6x1Tt8uUZ9EDBw K/KA== MIME-Version: 1.0 Received: by 10.180.83.198 with SMTP id s6mr28414165wiy.8.1332247211069; Tue, 20 Mar 2012 05:40:11 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Tue, 20 Mar 2012 05:40:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 23:10:10 +1030 Message-ID: From: Matt Thyer To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 12:40:12 -0000 On 20 March 2012 22:24, Ivan Voras wrote: > On 20 March 2012 12:52, Matt Thyer wrote: > > On 20 March 2012 21:12, Ivan Voras wrote: > >> > >> On 20/03/2012 06:26, Matt Thyer wrote: > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > >> > r232477 (4th Mar 2012) and am finding that a system process called > >> > "intr" > >> > is now constantly using about 60% of 1 CPU starting a short time after > >> > reboot (possibly triggered by use of the samba server). > >> > > >> > When this starts, systat -vm 1 says that the system is 85% idle and > 14% > >> > interrupt handling. > >> > It says that there's around 157k interrupts per second. > >> > > >> > >> Ok, but *which* interrupt is getting triggered? Please send the output > >> of "vmstat -i". > >> > >> > > interrupt total rate > > irq16: uhci0+ 3392184862 126692 > > Ok, something's probably wrong with USB. Can you disable it in BIOS? > > > > cpu0: timer 53549677 1999 > > irq256: mps0 2643187 98 > > irq257: re0 5508108 205 > > irq258: ahci0 160717 6 > > cpu1: timer 53525300 1999 > > cpu2: timer 53525300 1999 > > cpu3: timer 53525296 1999 > > Total 3614622447 134999 > > > I did just update the BIOS at about the same time so the difference may be due to that change. I'll try a few things such as: - Unplugging any USB things (I've only got a keyboard plugged in). - Downgrade BIOS. I'll get back to you all soon. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 13:33:31 2012 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 1DE391065670; Tue, 20 Mar 2012 13:33:31 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id DB2A98FC0C; Tue, 20 Mar 2012 13:33:30 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9zBS-000FUE-RY; Tue, 20 Mar 2012 09:33:06 -0400 Date: Tue, 20 Mar 2012 09:33:06 -0400 From: Gary Palmer To: Matt Thyer Message-ID: <20120320133306.GA5044@in-addr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 13:33:31 -0000 On Tue, Mar 20, 2012 at 11:10:10PM +1030, Matt Thyer wrote: > On 20 March 2012 22:24, Ivan Voras wrote: > > > On 20 March 2012 12:52, Matt Thyer wrote: > > > On 20 March 2012 21:12, Ivan Voras wrote: > > >> > > >> On 20/03/2012 06:26, Matt Thyer wrote: > > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > > >> > r232477 (4th Mar 2012) and am finding that a system process called > > >> > "intr" > > >> > is now constantly using about 60% of 1 CPU starting a short time after > > >> > reboot (possibly triggered by use of the samba server). > > >> > > > >> > When this starts, systat -vm 1 says that the system is 85% idle and > > 14% > > >> > interrupt handling. > > >> > It says that there's around 157k interrupts per second. > > >> > > > >> > > >> Ok, but *which* interrupt is getting triggered? Please send the output > > >> of "vmstat -i". > > >> > > >> > > > interrupt total rate > > > irq16: uhci0+ 3392184862 126692 > > > > Ok, something's probably wrong with USB. Can you disable it in BIOS? > > > > > > > cpu0: timer 53549677 1999 > > > irq256: mps0 2643187 98 > > > irq257: re0 5508108 205 > > > irq258: ahci0 160717 6 > > > cpu1: timer 53525300 1999 > > > cpu2: timer 53525300 1999 > > > cpu3: timer 53525296 1999 > > > Total 3614622447 134999 > > > > > > > I did just update the BIOS at about the same time so the difference may be > due to that change. > > I'll try a few things such as: > > - Unplugging any USB things (I've only got a keyboard plugged in). > - Downgrade BIOS. > > I'll get back to you all soon. It would be interesting to know if there are other devices on irq16 also. grep 'irq 16' /var/run/dmesg.boot I think the '+' on the irq16 line from vmstat means the interrupt is shared, but the man page doesn't mention it so I'm not 100% sure Thanks, Gary From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 13:41:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECBE71065670; Tue, 20 Mar 2012 13:41:01 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 262CA8FC12; Tue, 20 Mar 2012 13:41:00 +0000 (UTC) Received: by wern13 with SMTP id n13so49585wer.13 for ; Tue, 20 Mar 2012 06:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qVj2otUfIv30ezJAg4kqne3mBr+8w8sVdupLomiAXg0=; b=nIGbEyft5fPFPVX+mXLNX2S32hs+5amIPS/azhy7d80rLpFxLwJu13VzCoQ5pkRUGa HAJHhX9STyNP5yRCc8N1/088SZ8/efYnM8hsvXjiIvFmP2ZgTF7Mw3QptNoJvhJ+Doo7 IgV+YhQaOPwLwHL/O5gaLqj0EWx6mb4VnDVmW4NTlUBjG+mzCH0752zSWXqyTn8wFEm5 ZIo4mCds6tBrKpGn2XLrpJFNjFTJ+0+idcDYTBCTIw9f6mO9zYnTvTEFvfpuojqwAX1A DT46jIH2sxetv2vkric4PHAtqB3cgbMKkonCEujs1nMy5CHTCcW1JJsgMemEjeo1Id9w i6fg== MIME-Version: 1.0 Received: by 10.180.107.162 with SMTP id hd2mr28916823wib.8.1332250860133; Tue, 20 Mar 2012 06:41:00 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Tue, 20 Mar 2012 06:41:00 -0700 (PDT) In-Reply-To: <20120320133306.GA5044@in-addr.com> References: <20120320133306.GA5044@in-addr.com> Date: Wed, 21 Mar 2012 00:11:00 +1030 Message-ID: From: Matt Thyer To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 20 Mar 2012 13:41:02 -0000 On 21 March 2012 00:03, Gary Palmer wrote: > On Tue, Mar 20, 2012 at 11:10:10PM +1030, Matt Thyer wrote: > > On 20 March 2012 22:24, Ivan Voras wrote: > > > > > On 20 March 2012 12:52, Matt Thyer wrote: > > > > On 20 March 2012 21:12, Ivan Voras wrote: > > > >> > > > >> On 20/03/2012 06:26, Matt Thyer wrote: > > > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) > to > > > >> > r232477 (4th Mar 2012) and am finding that a system process called > > > >> > "intr" > > > >> > is now constantly using about 60% of 1 CPU starting a short time > after > > > >> > reboot (possibly triggered by use of the samba server). > > > >> > > > > >> > When this starts, systat -vm 1 says that the system is 85% idle > and > > > 14% > > > >> > interrupt handling. > > > >> > It says that there's around 157k interrupts per second. > > > >> > > > > >> > > > >> Ok, but *which* interrupt is getting triggered? Please send the > output > > > >> of "vmstat -i". > > > >> > > > >> > > > > interrupt total rate > > > > irq16: uhci0+ 3392184862 126692 > > > > > > Ok, something's probably wrong with USB. Can you disable it in BIOS? > > > > > > > > > > cpu0: timer 53549677 1999 > > > > irq256: mps0 2643187 98 > > > > irq257: re0 5508108 205 > > > > irq258: ahci0 160717 6 > > > > cpu1: timer 53525300 1999 > > > > cpu2: timer 53525300 1999 > > > > cpu3: timer 53525296 1999 > > > > Total 3614622447 134999 > > > > > > > > > > > I did just update the BIOS at about the same time so the difference may > be > > due to that change. > > > > I'll try a few things such as: > > > > - Unplugging any USB things (I've only got a keyboard plugged in). > > - Downgrade BIOS. > > > > I'll get back to you all soon. > > It would be interesting to know if there are other devices on irq16 also. > > grep 'irq 16' /var/run/dmesg.boot > > I think the '+' on the irq16 line from vmstat means the interrupt is > shared, but the man page doesn't mention it so I'm not 100% sure > > Thanks, > > Gary > Good point... pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb400000-0xfb7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 I'd suspect the SAS/SATA HBA using the mps0 driver as that's where I have the raidz2 on 8 drives. Is this still the old driver or has the new LSI authored driver been added to -STABLE yet ? From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 19:58:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA7E0106566C for ; Tue, 20 Mar 2012 19:58:36 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6C53C8FC08 for ; Tue, 20 Mar 2012 19:58:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 55F20446008 for ; Tue, 20 Mar 2012 16:01:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQyiSs57VFvo for ; Tue, 20 Mar 2012 16:01:43 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 04D78446005 for ; Tue, 20 Mar 2012 16:01:43 -0400 (EDT) From: Andrew Boyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Mar 2012 15:58:31 -0400 Message-Id: To: FreeBSD Stable Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Can someone do something about the extra svn mergeinfo? 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, 20 Mar 2012 19:58:36 -0000 For example: http://svnweb.freebsd.org/base/stable/8/sys/dev/e1000/?view=3Dlog This makes it very hard to figure out which changes are actually = relevant to e1000. Thank you, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 20:41:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80D4D1065675 for ; Tue, 20 Mar 2012 20:41:35 +0000 (UTC) (envelope-from mgamsjager@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 389198FC0A for ; Tue, 20 Mar 2012 20:41:34 +0000 (UTC) Received: by vcmm1 with SMTP id m1so623906vcm.13 for ; Tue, 20 Mar 2012 13:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=WkkwbAM84xGy/M96zVFVRAXXAzRqqgJbriRF9lJfNc4=; b=TnzAfnH2vF5RodFc/4GypWaQGFMU4lG1KcOFEHSH0hFj6BXf5ZyeqQGu76tC7s62Im PryFNXyx9JFFuipcKGiXioQAEBguVNz8gENtFox86W7L48Ti0ztzvE1inPnwS+zPyd6c xSBY6SHTYE75LWqn3MyYeMInYG6q25rHXxR3qomiMX+oZRnRvA9/fDrqA2l8wUD2qREw wWDmWtBkfkOykEf8aJDmVH4UJiD7689IyplVWpLI0zFPP0M+AsMJeP36DiL9PE+hi9Xw eOllU2jLj4h0fEwkXFCulU6mh9dI+BX48OQrA9AqiJYVBpLNDKiZ+oe1oG1NJC2V+APC A7tg== Received: by 10.220.153.13 with SMTP id i13mr628554vcw.21.1332276094581; Tue, 20 Mar 2012 13:41:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.157.76 with HTTP; Tue, 20 Mar 2012 13:41:04 -0700 (PDT) From: Matthias Gamsjager Date: Tue, 20 Mar 2012 21:41:04 +0100 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: powerd and increase in energy need 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, 20 Mar 2012 20:41:35 -0000 Hi, my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (quad core 2,5Ghz) processor with all the energy save setting enabled in the bios. Today I connected the power cord to a voltcraft energy meter to see how much energy the whole system needs in idle mode. I found out that with powerd running the cpu get clocked down to 499 mhz with is nice. The funny thing is that this doesn't decrease the amount of watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets even funnier. With powerd running the systems actually needs 4 watts more then without powerd running. Isn't the whole point of powerd to to decease the energy needs of a machine? or is it utterly broken with this cpu generation? From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 21:59:46 2012 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 BF0E9106564A for ; Tue, 20 Mar 2012 21:59:46 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 177AA8FC14 for ; Tue, 20 Mar 2012 21:59:45 +0000 (UTC) Received: (qmail 9856 invoked from network); 20 Mar 2012 21:53:03 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 20 Mar 2012 21:53:03 -0000 Received: (qmail 9847 invoked by uid 599); 20 Mar 2012 21:53:03 -0000 Received: from unknown (HELO hydrogen.icritical.com) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Tue, 20 Mar 2012 21:53:03 +0000 Message-ID: <4F68FC3E.2090401@icritical.com> Date: Tue, 20 Mar 2012 21:53:02 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120204 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 21:53:02.0223 (UTC) FILETIME=[D27AF9F0:01CD06E3] X-Virus-Scanned: by iCritical at mail1.icritical.com Subject: SAS Drive identification LEDs 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, 20 Mar 2012 21:59:46 -0000 Under 9.0-RELEASE I'm having trouble figuring out how to light up the drive identification/fault lights on my enclosure (SAS disks on Chenbro 80H10321513C0 backplanes attached to Areca ARC-1320 HBAs) Building+installing the tools in /usr/share/examples/ses gives me the following ability: # getencstat -V /dev/ses0 /dev/ses0: Enclosure Status Element 0x0: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x1: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x2: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x3: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x4: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x5: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x6: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x7: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x8: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x9: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xa: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xb: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xc: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xd: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xe: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xf: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x10: Enclosure OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x11: SAS Expander OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x12: SAS Connector, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x13: SAS Connector OK (Status=ok (bytes=0x01 0x3f 0x00 0x00)) Element 0x14: SAS Connector OK (Status=ok (bytes=0x01 0x02 0x00 0x00)) Element 0x15: SAS Connector, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) # setobjstat /dev/ses0 0xb 0x80 0x00 0x02 0x00 < light on drive bay 8 starts flashing > # setobjstat /dev/ses0 0xb 0x80 0x00 0x00 0x00 < light on drive bay 8 stops flashing > Which is great, but how can I work out how /dev/daNN maps to /dev/sesN element 0xNN? I've read mav@'s 2011 PDF on Enclosure Management (http://people.freebsd.org/~mav/Enclosure_Management_en.pdf) which shows a work-in-progress driver and getencstat which does what I need, but it looks like the project's not been committed yet. I've also tried playing around with Areca's SDK, however FreeBSDSCSIInterface()->init(i) causes the closed source driver to panic the kernel. AFAICT that class appears to be closed source too, so that's a dead end too. Is there any current way of mapping LED toggling with drive/serial numbers, or some sort of Areca HBA utility like mfiutil, or is it down to sticky labels on the front of the drive caddies? Thanks -- Sorry for the below... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Mar 20 23:47:24 2012 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 5289B106566C for ; Tue, 20 Mar 2012 23:47:24 +0000 (UTC) (envelope-from jamesbrandongooch@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 0F5268FC12 for ; Tue, 20 Mar 2012 23:47:23 +0000 (UTC) Received: by yhgm50 with SMTP id m50so722383yhg.13 for ; Tue, 20 Mar 2012 16:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tI+44yYY8xMaFpHb37yu9W//G99piwJWPoQpFI0WrOA=; b=dNKs9uYseRsudW/KGNBFGms6nGrxEw7uBK1re8xwtXhnMV4BZb6GsNa3pGyDEfbLIT CRQUBcooOHs5tukdhWAYKt0t0WP1T9MOvNcIO9emp48Lfd+wOEZn+XKngLoyRqs8hXE2 sVnJo+JbNs7QwBf8jlDn1GQoCP612/wfw3nPizf70jQXgC2NnrGhBjDc4VUt4JmrCU1z AtC3dl/48sP2nXKgd1bDUK2k8aKhyNeXNGevkAlfA4fPxpkyXZ3AmD9yCDcpt6CF2hKq cXoNoiFQPwvFWa9hB7F3MkIz8xpvTa01tmF6dQj+6jE1DDas4fHx6M2eE0JRJc65h8dC /fTA== MIME-Version: 1.0 Received: by 10.60.13.196 with SMTP id j4mr2371682oec.14.1332287243497; Tue, 20 Mar 2012 16:47:23 -0700 (PDT) Received: by 10.60.17.10 with HTTP; Tue, 20 Mar 2012 16:47:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 18:47:23 -0500 Message-ID: From: Brandon Gooch To: Matthias Gamsjager Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: powerd and increase in energy need 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, 20 Mar 2012 23:47:24 -0000 On Tue, Mar 20, 2012 at 3:41 PM, Matthias Gamsjager wrote: > Hi, > > my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (quad > core 2,5Ghz) processor with all the energy save setting enabled in the > bios. Today I connected the power cord to a voltcraft energy meter to see > how much energy the whole system needs in idle mode. > > I found out that with powerd running the cpu get clocked down to 499 mhz > with is nice. The funny thing is that this doesn't decrease the amount of > watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets even > funnier. With powerd running the systems actually needs 4 watts more then > without powerd running. > > Isn't the whole point of powerd to to decease the energy needs of a > machine? or is it utterly broken with this cpu generation? You probably want to check out the following article on the FreeBSD wiki: http://wiki.freebsd.org/TuningPowerConsumption The low-power states should be available to you after following the configuration guide. -Brandon From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 00:01:08 2012 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 129291065677 for ; Wed, 21 Mar 2012 00:01:08 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8F01E8FC1C for ; Wed, 21 Mar 2012 00:01:04 +0000 (UTC) To: Matthias Gamsjager In-reply-to: References: Comments: In-reply-to Matthias Gamsjager message dated "Tue, 20 Mar 2012 21:41:04 +0100." Date: Tue, 20 Mar 2012 17:00:57 -0700 From: John Message-Id: <20120321000058.177F8256@server.theusgroup.com> Cc: freebsd-stable@freebsd.org Subject: Re: powerd and increase in energy need 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, 21 Mar 2012 00:01:08 -0000 >my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (quad >core 2,5Ghz) processor with all the energy save setting enabled in the >bios. Today I connected the power cord to a voltcraft energy meter to see >how much energy the whole system needs in idle mode. > >I found out that with powerd running the cpu get clocked down to 499 mhz >with is nice. The funny thing is that this doesn't decrease the amount of >watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets even >funnier. With powerd running the systems actually needs 4 watts more then >without powerd running. > >Isn't the whole point of powerd to to decease the energy needs of a >machine? or is it utterly broken with this cpu generation? Powerd does decrease energy on my more modern hardware. This machine is used for backups and is idle much of the time. It runs Freebsd 8.3-Prerelease with the turbo-boost patch on an i5-650 in an intel DH55HC motherboard. The following power measurements were made with a Kill-A-Watt meter. 91w while doing a compile, dev.cpu.0.freq: 3193 (turbo boost enabled) 81w compile complete, disks quiet, top reports between 99.9 and 100% idle dev.cpu.0.freq: 3193 71w idle for several seconds, powerd running in hiadaptive mode, dev.cpu.0.freq: 1197 sysctl dev.cpu |grep cx dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 259us sysctl dev.cpu |grep freq ~ dev.cpu.0.freq: 1197 dev.cpu.0.freq_levels: 3193/9875 3192/9125 3059/8250 2926/7500 2793/6875 2660/6250 2527/5750 2394/5250 2261/4750 1197/2750 /etc/rc.conf powerd_flags="-n hadp" performance_cx_lowest="C2" economy_cx_lowest="C2" performance_cpu_freq="HIGH" John Theus TheUs Group TheUsGroup.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 07:42:07 2012 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 53AE1106564A for ; Wed, 21 Mar 2012 07:42:07 +0000 (UTC) (envelope-from mgamsjager@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 0971F8FC0C for ; Wed, 21 Mar 2012 07:42:06 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1124252vcm.13 for ; Wed, 21 Mar 2012 00:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y55EQtVDbUw86Td38esDWxdcCkBT/w3MDNdgLG/nPQg=; b=I1gu2T0JC+bUeyuhJlJsjCzmKZPFz7FKhys82uebXK8x2w1kV2eE/ln0rVpMx8n7pf l0OF/7ia2+ooJxHzXgN3rKXXRlf6t0u+QW/yJ5Bd0YCP1pY6L+X0Z8kgQFs1u3Ar7aHY vScLLziFxpkr2e64I6L5mYgP4xFnn1StGqB6jkke+mSF0iTWbCiLRS+OmWbyW6cLbfHS kq55Jd/baAZvkNIqqfljzN/9IRlcNAKbDkiO4zaVzGGEatnXRyGxBQqFnaSQyzUVq1aP L4WfDU0Jh7RDEPU5Gx8vo/hhq/LCaXlhzF6/b6vwc3B8yzuHsM78ykt+2ULVamCNVvMh KBqw== Received: by 10.52.67.115 with SMTP id m19mr1231200vdt.53.1332315726308; Wed, 21 Mar 2012 00:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.157.76 with HTTP; Wed, 21 Mar 2012 00:41:36 -0700 (PDT) In-Reply-To: <20120321000058.177F8256@server.theusgroup.com> References: <20120321000058.177F8256@server.theusgroup.com> From: Matthias Gamsjager Date: Wed, 21 Mar 2012 08:41:36 +0100 Message-ID: To: John Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: powerd and increase in energy need 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, 21 Mar 2012 07:42:07 -0000 On Wed, Mar 21, 2012 at 1:00 AM, John wrote: > >my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (quad > >core 2,5Ghz) processor with all the energy save setting enabled in the > >bios. Today I connected the power cord to a voltcraft energy meter to see > >how much energy the whole system needs in idle mode. > > > >I found out that with powerd running the cpu get clocked down to 499 mhz > >with is nice. The funny thing is that this doesn't decrease the amount of > >watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets > even > >funnier. With powerd running the systems actually needs 4 watts more then > >without powerd running. > > > >Isn't the whole point of powerd to to decease the energy needs of a > >machine? or is it utterly broken with this cpu generation? > > Powerd does decrease energy on my more modern hardware. This machine is > used > for backups and is idle much of the time. It runs Freebsd 8.3-Prerelease > with > the turbo-boost patch on an i5-650 in an intel DH55HC motherboard. > > The following power measurements were made with a Kill-A-Watt meter. > > 91w while doing a compile, dev.cpu.0.freq: 3193 (turbo boost enabled) > 81w compile complete, disks quiet, top reports between 99.9 and 100% idle > dev.cpu.0.freq: 3193 > 71w idle for several seconds, powerd running in hiadaptive mode, > dev.cpu.0.freq: 1197 > > > sysctl dev.cpu |grep cx > dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 > dev.cpu.0.cx_lowest: C2 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 259us > > sysctl dev.cpu |grep freq ~ > dev.cpu.0.freq: 1197 > dev.cpu.0.freq_levels: 3193/9875 3192/9125 3059/8250 2926/7500 2793/6875 > 2660/6250 2527/5750 2394/5250 2261/4750 1197/2750 > > /etc/rc.conf > powerd_flags="-n hadp" > performance_cx_lowest="C2" > economy_cx_lowest="C2" > performance_cpu_freq="HIGH" > > John Theus > TheUs Group > TheUsGroup.com > I will give these setting a try thx.. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 09:44:25 2012 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 C6A0D106566B for ; Wed, 21 Mar 2012 09:44:25 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0368FC16 for ; Wed, 21 Mar 2012 09:44:25 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so995912bkc.13 for ; Wed, 21 Mar 2012 02:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8WHldabFNV4gTTFapOaXby0bqT7zfj3Vq/BupISuhb0=; b=bC7WBWW+VT8xYi9XZY8u7EaXeUvb0i1TW8kxKdHS+8GXpiMo+wqHgwahPIWPh2tQ2M Y4NvIiNgcA5ULsPxJBNfQQdH1IEQzz3rNEWew50xPYdpt6aaqrF0YccKbZb9Bo+53A5T A8C2+VpHy3uihJ96yoOyH7yBFAi7eHCrKC/V0H1HRN/y1Az8de5GDpOe7hKD9mTdXBx+ O+j16Yv+M7BamZImu4eEFFX1HtHhGpGrsJgApLKAXZ80F7fEmhIczs7TH0/i02g3/bon /7Bhm7WcPyJIlMtFu5T3iwjfuHCDF5Vb1MY6yOSWtSwI9lfA9nqNL/y0Vdg045rWvfDC PcXg== Received: by 10.204.154.153 with SMTP id o25mr1212600bkw.138.1332323064253; Wed, 21 Mar 2012 02:44:24 -0700 (PDT) Received: from green.tandem.local (189-73-132-95.pool.ukrtel.net. [95.132.73.189]) by mx.google.com with ESMTPS id fh5sm2238757bkc.1.2012.03.21.02.44.22 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 02:44:23 -0700 (PDT) Message-ID: <4F69A2F5.6040304@gmail.com> Date: Wed, 21 Mar 2012 11:44:21 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: mutex problem: adding address to pf table results in uma_zallog_arg: zone "pfrktable" 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, 21 Mar 2012 09:44:25 -0000 Hi all. I have troubles running one server and recompiled kernel with DDB/WITNESS. I'll post some LOR's I can find. This one is highly reproducible as this happens each time sshguard adds address to the table. Mar 21 09:26:07 kohrah sshguard[5196]: Blocking 222.246.132.247:4 for >945secs: 40 danger in 4 attacks over 45 seconds (all: 80d in 2 abuses over 1079s). Mar 21 09:26:07 kohrah kernel: uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks held: Mar 21 09:26:07 kohrah kernel: exclusive sleep mutex pf task mtx (pf task mtx) r = 0 (0xffffffff81104bf0) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 Mar 21 09:26:07 kohrah kernel: KDB: stack backtrace: Mar 21 09:26:07 kohrah kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b Mar 21 09:26:07 kohrah kernel: kdb_backtrace() at kdb_backtrace+0x39 Mar 21 09:26:07 kohrah kernel: witness_warn() at witness_warn+0x434 Mar 21 09:26:07 kohrah kernel: uma_zalloc_arg() at uma_zalloc_arg+0x38 Mar 21 09:26:07 kohrah kernel: pfr_create_ktable() at pfr_create_ktable+0x33 Mar 21 09:26:07 kohrah kernel: pfr_add_addrs() at pfr_add_addrs+0x10b Mar 21 09:26:07 kohrah kernel: pfioctl() at pfioctl+0x34ad Mar 21 09:26:07 kohrah kernel: devfs_ioctl_f() at devfs_ioctl_f+0xf2 Mar 21 09:26:07 kohrah kernel: kern_ioctl() at kern_ioctl+0x1aa Mar 21 09:26:07 kohrah kernel: sys_ioctl() at sys_ioctl+0x146 Mar 21 09:26:07 kohrah kernel: amd64_syscall() at amd64_syscall+0x211 Mar 21 09:26:07 kohrah kernel: Xfast_syscall() at Xfast_syscall+0xfb Mar 21 09:26:07 kohrah kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800d9c82c, rsp = 0x7fffffffcd58, rbp = 0x7fffffffd1e0 --- Mar 21 09:26:07 kohrah kernel: uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks held: Mar 21 09:26:07 kohrah kernel: exclusive sleep mutex pf task mtx (pf task mtx) r = 0 (0xffffffff81104bf0) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 Mar 21 09:26:07 kohrah kernel: KDB: stack backtrace: Mar 21 09:26:07 kohrah kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b Mar 21 09:26:07 kohrah kernel: kdb_backtrace() at kdb_backtrace+0x39 Mar 21 09:26:07 kohrah kernel: witness_warn() at witness_warn+0x434 Mar 21 09:26:07 kohrah kernel: uma_zalloc_arg() at uma_zalloc_arg+0x38 Mar 21 09:26:07 kohrah kernel: pfr_add_addrs() at pfr_add_addrs+0x37c Mar 21 09:26:07 kohrah kernel: pfioctl() at pfioctl+0x34ad Mar 21 09:26:07 kohrah kernel: devfs_ioctl_f() at devfs_ioctl_f+0xf2 Mar 21 09:26:07 kohrah kernel: kern_ioctl() at kern_ioctl+0x1aa Mar 21 09:26:07 kohrah kernel: sys_ioctl() at sys_ioctl+0x146 Mar 21 09:26:07 kohrah kernel: amd64_syscall() at amd64_syscall+0x211 Mar 21 09:26:07 kohrah kernel: Xfast_syscall() at Xfast_syscall+0xfb Mar 21 09:26:07 kohrah kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800d9c82c, rsp = 0x7fffffffcd58, rbp = 0x7fffffffd1e0 --- Sample config: Install security/sshguard-pf. == /etc/pf.conf table sshguard persist == == /etc/syslog.conf auth.info;authpriv.info |exec /usr/local/sbin/sshguard == Try to ssh to the box typing garbage as password, after 4 fails client address is temporarily banned and pushed to the table. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 09:48:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25243106566B for ; Wed, 21 Mar 2012 09:48:11 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A08028FC0C for ; Wed, 21 Mar 2012 09:48:10 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so999291bkc.13 for ; Wed, 21 Mar 2012 02:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AxArsmAk+nzmlWBCW47UQrtLPqZGhz5BKZLQRPTqRWk=; b=Mz3MNMeMpth3bMTu5cH8xlF56uwPsdY4swWGOifpkWo3RF7Z7nGWy1dPkG6En5cP8E onph8Z5rB9X1zBlcDwmC2ywyxSjIRXRnSQ46+aP/ytZ09C2gwjYHzmmLlcLk+edxPU1a KIUrGWySkm3IowaT6uDDdsP0obT06EL5P9l1dEBVl/TnPS528s8uAcwyrK5jcgsYEHF0 ltfFFYOzrPdHm7qeWInBICa0XzZGoFn9KHBtenDI4xEU2SPfqaNV0jhy5zlXbBTT9J5H bGSittuhP2wYbRiWi+t9kvufVj70dm4gF5ZDrTnQG2qmuc+AvF/MNp2vleSkcMiVjhIS YUsg== Received: by 10.204.148.89 with SMTP id o25mr1270584bkv.52.1332323289582; Wed, 21 Mar 2012 02:48:09 -0700 (PDT) Received: from green.tandem.local (189-73-132-95.pool.ukrtel.net. [95.132.73.189]) by mx.google.com with ESMTPS id r14sm2215360bkv.11.2012.03.21.02.48.07 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 02:48:08 -0700 (PDT) Message-ID: <4F69A3D6.40207@gmail.com> Date: Wed, 21 Mar 2012 11:48:06 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F69A2F5.6040304@gmail.com> In-Reply-To: <4F69A2F5.6040304@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: mutex problem: adding address to pf table results in uma_zallog_arg: zone "pfrktable" 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, 21 Mar 2012 09:48:11 -0000 Volodymyr Kostyrko wrote: > Hi all. I have troubles running one server and recompiled kernel with > DDB/WITNESS. I'll post some LOR's I can find. Sorry, forgot to describe machine: FreeBSD kohrah.xim.bz 9.0-RELEASE FreeBSD 9.0-RELEASE #0 r229375: Tue Mar 20 17:48:58 EET 2012 arcade@kohrah.xim.bz:/usr/obj/usr/src/sys/MINIMAL amd64 -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 11:52:57 2012 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 2AE9F106566B for ; Wed, 21 Mar 2012 11:52:57 +0000 (UTC) (envelope-from QuickLife@Cover-My-Life.co.za) Received: from node-sl250.smtp.com (node-sl250.smtp.com [173.192.174.225]) by mx1.freebsd.org (Postfix) with ESMTP id E50AC8FC08 for ; Wed, 21 Mar 2012 11:52:56 +0000 (UTC) X-MSFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmdAMTczXzE5Ml8xNzRfMjI1QHNhY2Zz X2RlZGljYXRlZF9wb29sQA== DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1332330807; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=iIWl1Xwr7yM8OjyjA3WkZ2vva4s0hkXlRaRaEuudW0g=; b=LHuNo7ziu+pFIr3MmS+rmZnj2hWfG9wsAFXw+cgqVlKfOrEtFc9FUIXzcnOWpcDW QiUCPh5lfp/R6tsflYAiSfgBV5G7KWPkeWhO8XAFJu56JjAX4TPvD06nLEbEQyDI jZwXIiF6/tocGsWk7tea/Z/C+zyKvTSdLJGCNH1q07g=; Received: from [109.73.163.143] ([109.73.163.143:60806] helo=Sender) by sl-se-mta01 (envelope-from ) (ecelerity 3.3.2.44647 r(44647)) with ESMTPA id F9/FB-14112-631C96F4; Wed, 21 Mar 2012 11:53:27 +0000 Received: from cloned-VPS ([109.73.163.143]) by Sender ; Wed, 21 Mar 2012 13:53:22 +0200 Message-ID: MIME-Version: 1.0 From: "Cover-My-Life.co.za" To: freebsd-stable@freebsd.org Date: 21 Mar 2012 13:53:22 +0200 X-SMTPCOM-Tracking-Number: df9fb387-d4c5-4d9d-a57b-f652893ebe79 X-SMTPCOM-Sender-ID: 436308 X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FREEBSD STABLE, Get R3M in Life Cover for under R10 per day (No Medicals) - Cover-My-Life.co.za 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, 21 Mar 2012 11:52:57 -0000 SGkgRlJFRUJTRCBTVEFCTEUsDQoNCkxldCdzIGZhY2UgZmFjdHMgLSBPbmUgZGF5 IHlvdSAoYW5kIEkpIHdpbGwgZGllLiAgTWF5YmUgd2Ugd2lsbCBzZWUgaXQgY29t aW5nLiAgTWF5YmUgd2Ugd29uJ3QuDQoNCkJVVCwgaGF2ZSB5b3UgY29uc2lkZXJl ZCB3aGF0IHdpbGwgaGFwcGVuIHRvIHlvdXIgZmFtaWx5IGlmIHlvdSB3ZXJlIHRv IHBhc3MgYXdheT8NCg0KLURvIHlvdSBoYXZlIGEgd2lsbCBhbmQgaXMgaXQgdXAt dG8tZGF0ZT8NCi1EbyB5b3UgaGF2ZSBsb2FucyAobGlrZSBhIGhvbWUgbG9hbikg b3IgY3JlZGl0IHRoYXQgd291bGQgbmVlZCB0byBiZSBwYWlkIG9mZj8NCi1XaWxs IHlvdXIgbG92ZWQgb25lcyBiZSBhYmxlIHRvIGxpdmUgY29tZm9ydGFibHkgd2l0 aG91dCB5b3VyIGluY29tZT8NCi1EbyBoYXZlIGVub3VnaCBjYXNoIHNpdHRpbmcg aW4gdGhlIGJhbmsgdG8gY292ZXIgYW4gdW5mb3Jlc2VlbiBmdW5lcmFsPw0KDQpO byBvbmUgbGlrZXMgdG8gdGhpbmsgYWJvdXQgdGhpcyBzdHVmZiBidXQgZnJhbmts eSB3ZSBtdXN0LiAgQW5kIGlmIHlvdSBoYXZlIHJlYWQgdGhpcyBmYXIsIHlvdSBh cmUgcHJvYmFibHkganVzdCBhcyBjb25jZXJuZWQgYWJvdXQgdGhlc2UgaXNzdWVz IGFzIHlvdSBzaG91bGQgYmUuDQoNCldlbGwgbm90IHRvIHdvcnJ5LCBoZXJlIGlz IHRoZSBnb29kIG5ld3M6IENvdmVyLU15LUxpZmUuY28uemEgaXMgaGVyZSB0byBo ZWxwISAgTm90IG9ubHkgaGF2ZSB3ZSBtYWRlIHRoZSBwcm9jZXNzIG9mIGdldHRp bmcgdGhlIHJpZ2h0IExpZmUgQ292ZXIgZm9yIHlvdSBhcyBzaW1wbGUgYXMgYSBm ZXcgY2xpY2tzIGJ1dCB3ZSBoYXZlIGFsc28gc291cmNlZCBzb21lIG9mIHRoZSBi ZXN0IGRlYWxzIGluIHRoZSBtYXJrZXQuDQoNCkFzIGFuIGV4YW1wbGUgYSAzNSB5 ZWFyIG9sZCBTb3V0aCBBZnJpY2FuIGZlbWFsZSBjYW4gZ2V0IFIzIE1pbGxpb24g TGlmZSBDb3ZlciBmb3IgdW5kZXIgUjEwIHBlciBkYXkhDQoNClNvIHdoeSBub3Qg dHJ5IHVzIG91dCBhbmQgZ2V0IGEgcXVvdGUgZm9yIG9uZSBvZiB0aGUgZm9sbG93 aW5nIHByb2R1Y3RzIHdlIGhhdmUgYXZhaWxhYmxlOg0KDQpMaWZlIEluc3VyYW5j ZSAtIEdldCB1cHRvIFI2TSBjb3ZlciAobm8gbWVkaWNhbCk7IFF1b3RlIGluIG1p bnV0ZXM7IFNhdmUgdXB0byA1MCUNCkRpc2FiaWxpdHkgSW5zdXJhbmNlIC0gQ292 ZXIgZm9yIGlmIHlvdSBiZWNvbWUgZGlzYWJsZWQgKGVnIEZyb20gYW4gYWNjaWRl bnQpDQpTYWxhcnkgUHJvdGVjdGlvbiAtIENvdmVyIGZvciBpZiB5b3UgYXJlIHVu YWJsZSB0byBlYXJuIGFuIGluY29tZSAoZWcgUmV0cmVuY2htZW50LCBJbmp1cnkg ZXRjKQ0KQ3JpdGljYWwgSWxsbmVzcyBDb3ZlciAtIENvdmVyIGZvciBpZiB5b3Ug YmVjb21lIGNyaXRpY2FsbHkgaWxsIChlZyBDYW5jZXIpDQpDb3ZlciBmb3IgSElW IC0gTGlmZSBDb3ZlciBmb3IgdGhvc2Ugc3VmZmVyaW5nIGZyb20gSElWDQpGUkVF IEZpbmFuY2lhbCBQbGFuIC0gTGV0IHVzIHByb3ZpZGUgeW91IHdpdGggYSBGaW5h bmNpYWwgUGxhbiBhYnNvbHV0ZWx5IEZSRUUNCg0KVGhpcyB0YWtlcyBhbGwgdGhl IGhhc3NsZSBhbmQgaGFyZCB3b3JrIG91dCBvZiBmaW5kaW5nIHRoZSBiZXN0IGlu c3VyYW5jZSBmb3IgeW91IGFuZCB3aGF04oCZcyBtb3JlLCB5b3UgY2FuIGRvIGl0 IGZyb20gdGhlIHByaXZhY3kgb2YgeW91ciBvd24gaG9tZSAvIG9mZmljZSAvIHdo ZXJldmVyIHlvdSBhcmUgcmVhZGluZyB0aGlzLg0KDQpHaXZlIHVzIGEgdHJ5LCBn byB0byB3d3cuQ292ZXItTXktTGlmZS5jby56YSwgb3IgYXBwbHkgbm93DQoNClRo YW5rcw0KDQpUaGUgQ292ZXItTXktTGlmZS5jby56YSB0ZWFtDQoNCiANCg0KDQoN Ck91ciBTZXJ2aWNlcyBpbmNsdWRlOg0KMSkgT25saW5lIGF1dG9tYXRlZCBxdW90 ZSBtYW5hZ2VtZW50IHByb2Nlc3MNCjIpIFN0ZXAgYnkgc3RlcCBndWlkYW5jZSBh bmQgYWR2aWNlIGZyb20gcHJvZmVzc2lvbmFsbHkgdHJhaW5lZCBzdGFmZg0KMykg QmVzdCBxdW90ZSBwcm92aWRlZCB1c3VhbGx5IHdpdGhpbiB0aGUgc2FtZSBkYXkg YmFzZWQgb24geW91ciBwZXJzb25hbCBjaXJjdW1zdGFuY2UNCjQpIFRvdGFsbHkg c2VjdXJlIGFwcGxpY2F0aW9uIHByb2Nlc3MgdXNpbmcgU1NMIEVuY3J5cHRpb24N Cg0KDQpFbWFpbCBzZW50IGJ5IFNBIENvbnN1bWVyIEZvdW5kYXRpb24gDQpTQSBD b25zdW1lciBGb3VuZGF0aW9uIHwgMTIwIDFzdCBBdmVudWUgfCBIeWRlIFBhcmss IEpIQiwgR2F1dGVuZyAyMTk2DQoyMDEyIFNBIENvbnN1bWVyIEZvdW5kYXRpb24g QWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KSWYgeW91IGRpZCBub3Qgd2lzaCB0byBy ZWNlaXZlIHRoaXMsIHBsZWFzZSB1bnN1YnNjcmliZSBmcm9tIGZ1cnRoZXIgZW1h aWxzICBhdCBodHRwOi8vd3d3LmZvcm1zdGFjay5jb20vZm9ybXMvc2EtZW1haWx1 bnN1YnNjcmliZT9lbWFpbD1mcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZw0KDQpJ ZiB5b3UgY29uc2lkZXIgdGhpcyBlbWFpbCB1bnNvbGljaXRlZCBidWxrIG1haWws IHBsZWFzZSByZXBvcnQgU1BBTSBhdCBodHRwOi8vd3d3LmZvcm1zdGFjay5jb20v Zm9ybXMvc2EtcmVwb3J0c3BhbT9lbWFpbD1mcmVlYnNkLXN0YWJsZUBmcmVlYnNk Lm9yZyZlbWFpbF9mcm9tPVF1aWNrTGlmZUBDb3Zlci1NeS1MaWZlLmNvLnph From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 12:19:21 2012 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 87A14106564A for ; Wed, 21 Mar 2012 12:19:21 +0000 (UTC) (envelope-from jan@mail.kantarmedia.de) Received: from mail.kantarmedia.de (mail3.kantarmedia.de [212.72.165.136]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2CF8FC0C for ; Wed, 21 Mar 2012 12:19:20 +0000 (UTC) Received: from host81-102-109-114.not-set-yet.ntli.net ([81.102.109.114] helo=[192.168.0.13]) by mail.kantarmedia.de with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1SAKLp-000KpL-I3; Wed, 21 Mar 2012 13:09:19 +0100 Message-ID: <4F69C46A.9030100@kantarmedia.de> Date: Wed, 21 Mar 2012 12:07:06 +0000 From: Jan Winter User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com, stable@freebsd.org References: <4F5F46DE.5050608@kantarmedia.de> <20120314184047.GA8023@michelle.cdnetworks.com> <4F60AC6C.2060805@kantarmedia.de> <20120315172928.GB3295@michelle.cdnetworks.com> <4F61FA9A.5000805@kantarmedia.de> <20120316173215.GB6841@michelle.cdnetworks.com> <4F63613E.8040507@kantarmedia.de> <20120317234508.GB1660@michelle.cdnetworks.com> In-Reply-To: <20120317234508.GB1660@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: jan@mail.kantarmedia.de X-SA-Exim-Connect-IP: 81.102.109.114 X-SA-Exim-Mail-From: jan@mail.kantarmedia.de X-SA-Exim-Scanned: No (on mail.kantarmedia.de); SAEximRunCond expanded to false Cc: Subject: Re: bce: Device not configured 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, 21 Mar 2012 12:19:21 -0000 On 03/17/12 23:45, YongHyeon PYUN wrote: > On Fri, Mar 16, 2012 at 04:50:22PM +0100, Jan Winter wrote: >> On 03/16/12 18:32, YongHyeon PYUN wrote: >>> On Thu, Mar 15, 2012 at 03:20:10PM +0100, Jan Winter wrote: >>>> On 03/15/12 18:29, YongHyeon PYUN wrote: >>>>> On Wed, Mar 14, 2012 at 03:34:20PM +0100, Jan Winter wrote: >>>>>> On 03/14/12 19:40, YongHyeon PYUN wrote: >>>>>>> On Tue, Mar 13, 2012 at 02:08:46PM +0100, Jan Winter wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> on an Dell Blade m610 is not possible to change the network media >>>>>>>> option: >>>>>>>> >>>>>>>> ifconfig bce0 media 100baseTX mediaopt full-duplex up >>>>>>>> ifconfig: SIOCSIFMEDIA (media): Device not configured >>>>>>>> >>>>>>>> Setting the media option to "autoselect" and connecting the m610 to a >>>>>>>> 100 MBit switch, I always get "no carrier" >>>>>>>> only 1g full-duplex seems to be working. I have tested this on >>>>>>>> 8.3-prerelease and 9-stable >>>>>>>> >>>>>>>> any Ideas? >>>>>>>> >>>>>>>> cheers >>>>>>>> Jan >>>>>>>> >>>>>>>> pciconf -lv >>>>>>>> bce0@pci0:1:0:0: class=0x020000 card=0x02871028 chip=0x163a14e4 >>>>>>>> rev=0x20 hdr=0x00 >>>>>>>> vendor = 'Broadcom Corporation' >>>>>>>> device = 'NetXtreme II BCM5709S Gigabit Ethernet' >>>>>>>> class = network >>>>>>>> subclass = ethernet >>>>>>>> >>>>>>>> dmesg >>>>>>>> bce0: mem >>>>>>>> 0xda000000-0xdbffffff irq 36 at device 0.0 on pci1 >>>>>>>> miibus0: on bce0 >>>>>>>> brgphy0: PHY 2 on miibus0 >>>>>>>> brgphy0: 1000baseSX-FDX, auto >>>>>>>> bce0: Ethernet address: 00:26:b9:fb:04:0c >>>>>>>> bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C >>>>>>>> (5.0.11); >>>>>>>> Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.5) >>>>>>>> Coal (RX:6,6,18,18; TX:20,20,80,80) >>>>>>>> bce1: mem >>>>>>>> 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1 >>>>>>>> miibus1: on bce1 >>>>>>>> brgphy1: PHY 2 on miibus1 >>>>>>>> brgphy1: 1000baseSX-FDX, auto >>>>>>>> bce1: Ethernet address: 00:26:b9:fb:04:0e >>>>>>>> bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C >>>>>>>> (5.0.11); >>>>>>>> Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.5) >>>>>>>> Coal (RX:6,6,18,18; TX:20,20,80,80) >>>>>>>> >>>>>>> I'm not sure you're seeing one of long standing remote PHY issue of >>>>>>> blade box but would you try the patch at the following URL? >>>>>>> http://people.freebsd.org/~yongari/bce/bce.rphy.diff >>>>>>> >>>>>>> After applying the patch, show me the dmesg output(bce(4) and >>>>>>> brgphy(4) related ones) and 'ifconfig -m bce0'. >>>>>>> Note, the patch was not tested at all(lack of hardware). >>>>>> Hello, >>>>>> >>>>>> thank you very much, for your quick support >>>>>> Now its looking much better >>>>>> >>>>>> ifconfig -m bce0 >>>>>> bce0: flags=8843 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=c01bb >>>>>> >>>>>> capabilities=c01bb >>>>>> ether 00:26:b9:fb:04:0c >>>>>> inet 192.168.100.30 netmask 0xffffff00 broadcast >>>>>> 192.168.100.255 >>>>>> inet6 fe80::226:b9ff:fefb:40c%bce0 prefixlen 64 tentative >>>>>> scopeid 0x1 >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (1000baseT) >>>>>> status: active >>>>>> supported media: >>>>>> media autoselect >>>>>> media 1000baseT mediaopt full-duplex >>>>>> media 1000baseT >>>>>> media 100baseTX mediaopt full-duplex >>>>>> media 100baseTX >>>>>> media 10baseT/UTP mediaopt full-duplex >>>>>> media 10baseT/UTP >>>>>> >>>>>> dmesg: >>>>>> ..... >>>>>> bce0: mem >>>>>> 0xda000000-0xdbffffff irq 36 at device 0.0 on pci1 >>>>>> bce0: attempting to allocate 1 MSI vectors (16 supported) >>>>>> msi: routing MSI IRQ 256 to local APIC 16 vector 52 >>>>>> bce0: using IRQ 256 for MSI >>>>>> bce0: Remote PHY : TP >>>>>> bce0: bpf attached >>>>>> bce0: Ethernet address: 00:26:b9:fb:04:0c >>>>>> bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); >>>>>> Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|Remote PHY(TP)|MFW); MFW (NCSI >>>>>> 2.0.5) >>>>>> Coal (RX:6,6,18,18; TX:20,20,80,80) >>>>>> bce1: mem >>>>>> 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1 >>>>>> bce1: attempting to allocate 1 MSI vectors (16 supported) >>>>>> msi: routing MSI IRQ 257 to local APIC 16 vector 53 >>>>>> bce1: using IRQ 257 for MSI >>>>>> bce1: Remote PHY : TP >>>>>> bce1: bpf attached >>>>>> bce1: Ethernet address: 00:26:b9:fb:04:0e >>>>>> bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); >>>>>> Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|Remote PHY(TP)|MFW); MFW (NCSI >>>>>> 2.0.5) >>>>>> Coal (RX:6,6,18,18; TX:20,20,80,80) >>>>>> ..... >>>>>> >>>>>> I have done a quick test with 100 and 1000 MBit, both working very well. >>>>> Thanks a lot for testing. This patch was made long time ago but I >>>>> haven't had chance to commit it due to lack of access to hardware. >>>>> Because the patch bypasses mii(4) layer and makes it hard to read >>>>> code, I didn't like the patch but it seems the patch makes bce(4) >>>>> usable on blade boxes at least. >>>>> I'll commit the patch next week. >>>>> >>>>>> Its possible to get a Patch for 8 Stable? >>>>>> >>>>> I will do MFC to stable/[7-9]. And bce.rphy.diff should be applied >>>>> cleanly to stable/[7-9]. >>>> I getting erros with the 8-stable source >>>> >>> Oops, try this one for stable/8. >>> http://people.freebsd.org/~yongari/bce/bce.rphy.stable8.diff >> thank you for the 8-stable patch! but i am sorry this patch doesn't >> work. I getting a kernel trap on boot. >> The bce driver is compiled as module >> >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> bce0: mem >> 0xda000000-0xdbffffff irq 36 at device 0.0 on pci1 >> bce0: Remote PHY : TP >> bce0: Ethernet address: 00:26:b9:fa:f0:78 >> bce0: [ITHREAD] >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 10 >> fault virtual address = 0x88 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80626551 >> stack pointer = 0x28:0xffffffff80f8b3e0 >> frame pointer = 0x28:0xffffffff80f8b410 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (swapper) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff8062fe6e at kdb_backtrace+0x5e >> #1 0xffffffff805fd087 at panic+0x187 >> #2 0xffffffff808f3170 at trap_fatal+0x290 >> #3 0xffffffff808f34c1 at trap_pfault+0x201 >> #4 0xffffffff808f397f at trap+0x3df >> #5 0xffffffff808daed4 at calltrap+0x8 >> #6 0xffffffff80f352b8 at bce_attach+0x3268 >> #7 0xffffffff80629999 at device_attach+0x69 >> #8 0xffffffff8062b16a at bus_generic_attach+0x1a >> #9 0xffffffff802074af at acpi_pci_attach+0x14f >> #10 0xffffffff80629999 at device_attach+0x69 >> #11 0xffffffff8062b16a at bus_generic_attach+0x1a >> #12 0xffffffff80209217 at acpi_pcib_attach+0x1a7 >> #13 0xffffffff8020a125 at acpi_pcib_pci_attach+0x95 >> #14 0xffffffff80629999 at device_attach+0x69 >> #15 0xffffffff8062b16a at bus_generic_attach+0x1a >> #16 0xffffffff802074af at acpi_pci_attach+0x14f >> #17 0xffffffff80629999 at device_attach+0x69 >> Uptime: 1s >> Automatic reboot in 15 seconds - press a key on the console to abort >> > Sorry, there was a typo. I've uploaded updated one for stable/8(The > URL is the same). that patch seems to work great. thank you Jan From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 16:32:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A1081065670 for ; Wed, 21 Mar 2012 16:32:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF8958FC08 for ; Wed, 21 Mar 2012 16:32:47 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1063716pbc.13 for ; Wed, 21 Mar 2012 09:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MyZ1bpEStHHFjZ5JDHSE8gudvdDstKk+mMha8zVYwIY=; b=1E1df1WyLAYkLWRDjZXr75i2bJ5rWG5L7zC9m7xKM4155PxSqhbZxP1OrvtxK1riBC 3gZ8OnA+IE6aNPlWTa3eh+JV7ouHUf9W3S9cswyW2TcACFZkKTEwOWH0UAoXWmOShxyK nJLeqPK/zW3VjR3LBx7QZfpGR3zzZfMLMWaW4oSveg4KEjLjlbNgaGgkhKJQ/TLCnUbD qsCdTqu0EabjncUwCmiA819d7uG5kHm37sQc9gUddsQ5wm5xvwXkIvO1gJPEwPAKGJL3 yBy7Z08kVwPRjTqRm/cFevpVJB2lWQekJyItIZGRZeyYNqYNLQfQI681oxtIvHs/fm2s Y4Tg== MIME-Version: 1.0 Received: by 10.68.73.138 with SMTP id l10mr12850780pbv.22.1332347567463; Wed, 21 Mar 2012 09:32:47 -0700 (PDT) Received: by 10.68.129.106 with HTTP; Wed, 21 Mar 2012 09:32:47 -0700 (PDT) In-Reply-To: References: <20120321000058.177F8256@server.theusgroup.com> Date: Wed, 21 Mar 2012 09:32:47 -0700 Message-ID: From: Kevin Oberman To: Matthias Gamsjager Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 21 Mar 2012 16:32:48 -0000 On Wed, Mar 21, 2012 at 12:41 AM, Matthias Gamsjager wrote: > On Wed, Mar 21, 2012 at 1:00 AM, John wrote: > >> >my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (q= uad >> >core 2,5Ghz) processor with all the energy save setting enabled in the >> >bios. Today I connected the power cord to a voltcraft energy meter to s= ee >> >how much energy the whole system needs in idle mode. >> > >> >I found out that with powerd running the cpu get clocked down to 499 mh= z >> >with is nice. The funny thing is that this doesn't decrease the amount = of >> >watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets >> even >> >funnier. With powerd running the systems actually needs 4 watts more th= en >> >without powerd running. >> > >> >Isn't the whole point of powerd to to decease the energy needs of a >> >machine? or is it utterly broken with this cpu generation? >> >> Powerd does decrease energy on my more modern hardware. This machine is >> used >> for backups and is idle much of the time. It runs Freebsd 8.3-Prerelease >> with >> the turbo-boost patch on an i5-650 in an intel DH55HC motherboard. >> >> The following power measurements were made with a Kill-A-Watt meter. >> >> 91w while doing a compile, dev.cpu.0.freq: 3193 (turbo boost enabled) >> 81w compile complete, disks quiet, top reports between 99.9 and 100% idl= e >> =A0 =A0 =A0 =A0dev.cpu.0.freq: 3193 >> 71w idle for several seconds, powerd running in hiadaptive mode, >> =A0 =A0 =A0 =A0dev.cpu.0.freq: 1197 >> >> >> sysctl dev.cpu |grep cx >> dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 >> dev.cpu.0.cx_lowest: C2 >> dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 259us >> >> sysctl dev.cpu |grep freq =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~ >> dev.cpu.0.freq: 1197 >> dev.cpu.0.freq_levels: 3193/9875 3192/9125 3059/8250 2926/7500 2793/6875 >> 2660/6250 2527/5750 2394/5250 2261/4750 1197/2750 >> >> /etc/rc.conf >> powerd_flags=3D"-n hadp" >> performance_cx_lowest=3D"C2" >> economy_cx_lowest=3D"C2" >> performance_cpu_freq=3D"HIGH" >> >> John Theus >> TheUs Group >> TheUsGroup.com >> > > I will give these setting a try thx.. If you are trying to reduce power consumption, why are you limiting Cx states to C2 (which save little) and not C3 (which will save a LOT of power when the CPU is not heavily loaded). If it is due to the system hanging, it is almost certainly because you have throttling enabled. Throttling, either by the use of TCC (also called P4TCC) or the older, externally implemented throttling mechanism, is a BAD BAD THING! I have complained for years about it being the default. It is intended for thermal control, not power management. The power savings will be negligible and, in combination with deep sleep modes (Cx > 2) can and do result in the CPU going into deep sleep and never waking up. You can (and should) disable them in /boot/loader.conf with: # Disable CPU throttling hint.p4tcc.0.disabled=3D1 hint.acpi_throttle.0.disabled=3D1 This should greatly reduce the large number of "frequencies" available, but they will be the ones provided by EST.which really do reduce power consumption. (I put frequencies in quotation marks because throttling does not really change the clock speed. It simply skips 'N' of every 8 clock cycles. Still, compared to C3 and higher, EST is a minor power savings. Just following the recommendations on the power management web page is the way to go. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 16:55:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35DCB1065675 for ; Wed, 21 Mar 2012 16:55:37 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A67198FC1A for ; Wed, 21 Mar 2012 16:55:35 +0000 (UTC) Received: by lboi15 with SMTP id i15so1298607lbo.13 for ; Wed, 21 Mar 2012 09:55:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=kb964/ZZcUvDKqxhKKxOV0ZI7l3p6pXMbYLWx64Vfrg=; b=HqDgoucN3JesQgX4b7Pg+DxpOG+1BPk78irs9x7kyWENzr7hoTkI+QA4ACvYV6nwEf 15IqHANu5sQHrwbXBQrnk3yJd77VUXJmKBzZ5iaS6i5zQQ0c2c4RGps+ZBa0HYnDDqI0 ZpktLIneGU0Tx6WzWw1u4pQGh1nAwFF9G9Qn8CTdTSR905snhsIs31/Ha4OhfthcfIyW PdnnmobndnXHS7iRMkmvPztWf653J8bLeDKPR/x9PBJLfkHzMtoCBrc2ByLkajFlit/B WItK8nHuR2RS75UziOrsWcNVpRU7A0LSL3D/dDbs8utZ58I00dSHgRheXH3mhHxp+iu5 CKtw== MIME-Version: 1.0 Received: by 10.112.27.67 with SMTP id r3mr1601857lbg.68.1332348934528; Wed, 21 Mar 2012 09:55:34 -0700 (PDT) Received: by 10.112.144.106 with HTTP; Wed, 21 Mar 2012 09:55:34 -0700 (PDT) In-Reply-To: References: <20120321000058.177F8256@server.theusgroup.com> Date: Wed, 21 Mar 2012 17:55:34 +0100 Message-ID: From: Olivier Smedts To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2f9YvESQaZhXTzuuodwleUVUnO2Im91L+MZQE2L/pZ8bj8DjFcfu5UiPsmXb3DNKIRqFb Cc: Matthias Gamsjager , freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 21 Mar 2012 16:55:37 -0000 2012/3/21 Kevin Oberman : > If you are trying to reduce power consumption, why are you limiting Cx > states to C2 (which save little) and not C3 (which will save a LOT of > power when the CPU is not heavily loaded). Jumping up on this but I don't know if that's related to his reasons to not use C3. Mine are simple : # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 39,0C dev.cpu.1.temperature: 40,0C dev.cpu.2.temperature: 36,0C dev.cpu.3.temperature: 36,0C dev.cpu.4.temperature: 41,0C dev.cpu.5.temperature: 41,0C dev.cpu.6.temperature: 36,0C dev.cpu.7.temperature: 36,0C # sysctl hw.acpi.cpu.cx_lowest=3DC3 hw.acpi.cpu.cx_lowest: C2 -> C3 # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 44,0C dev.cpu.1.temperature: 44,0C dev.cpu.2.temperature: 40,0C dev.cpu.3.temperature: 40,0C dev.cpu.4.temperature: 46,0C dev.cpu.5.temperature: 46,0C dev.cpu.6.temperature: 41,0C dev.cpu.7.temperature: 41,0C # sysctl hw.acpi.cpu.cx_lowest=3DC2 hw.acpi.cpu.cx_lowest: C3 -> C2 # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 40,0C dev.cpu.1.temperature: 40,0C dev.cpu.2.temperature: 36,0C dev.cpu.3.temperature: 36,0C dev.cpu.4.temperature: 42,0C dev.cpu.5.temperature: 42,0C dev.cpu.6.temperature: 36,0C dev.cpu.7.temperature: 36,0C Only 1-2 seconds between each command, no current load. As you can see, when I engage C3 states, the CPU temperature increases by 4-5=B0C. I expected it to drop. This is with : # sysctl dev.cpu | grep freq dev.cpu.0.freq: 2933 dev.cpu.0.freq_levels: 2933/95 2799/95 2266/75 1733/56 1199/39 # grep perf /etc/rc.conf performance_cx_lowest=3D"C2" performance_cpu_freq=3D"HIGH" # grep hint /boot/loader.conf hint.p4tcc.0.disabled=3D1 hint.acpi_throttle.0.disabled=3D1 # dmesg | head -n 13 | tail -n 9 FreeBSD 9.0-STABLE #0 r233000M: Thu Mar 15 12:30:27 CET 2012 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2793.04-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x106e5 Family =3D 6 Model =3D 1e St= epping =3D 5 Features=3D0xbfebfbff Features2=3D0x98e3fd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics I tried with and without powerd and there's no noticeable difference, so I don't use it. I also tried with and without performance_cpu_freq=3D"HIGH" in /etc/rc.conf (without, dev.cpu.0.freq is 2799 so I don't think TurboBoost is enabled in this case). > If it is due to the system hanging, it is almost certainly because you > have throttling enabled. Throttling, either by the use of TCC (also > called P4TCC) or the older, externally implemented throttling > mechanism, is a BAD BAD THING! I have complained for years about it > being the default. It is intended for thermal control, not power > management. The power savings will be negligible and, in combination > with deep sleep modes (Cx > 2) can and do result in the CPU going into > deep sleep and never waking up. > > You can (and should) disable them in /boot/loader.conf with: > # Disable CPU throttling > hint.p4tcc.0.disabled=3D1 > hint.acpi_throttle.0.disabled=3D1 > > This should greatly reduce the large number of "frequencies" > available, but they will be the ones provided by EST.which really do > reduce power consumption. (I put frequencies in quotation marks > because throttling does not really change the clock speed. It simply > skips 'N' of every 8 clock cycles. Still, compared to C3 and higher, > EST is a minor power savings. > > Just following the recommendations on the power management web page is > the way to go. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > _______________________________________________ > 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" --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 17:18:42 2012 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 BE73A106566C for ; Wed, 21 Mar 2012 17:18:42 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC1F8FC18 for ; Wed, 21 Mar 2012 17:18:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F04E47300A; Wed, 21 Mar 2012 18:37:28 +0100 (CET) Date: Wed, 21 Mar 2012 18:37:28 +0100 From: Luigi Rizzo To: Kevin Oberman Message-ID: <20120321173728.GA41322@onelab2.iet.unipi.it> References: <20120321000058.177F8256@server.theusgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Matthias Gamsjager , freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 21 Mar 2012 17:18:42 -0000 On Wed, Mar 21, 2012 at 09:32:47AM -0700, Kevin Oberman wrote: ... > If you are trying to reduce power consumption, why are you limiting Cx > states to C2 (which save little) and not C3 (which will save a LOT of > power when the CPU is not heavily loaded). > > If it is due to the system hanging, it is almost certainly because you > have throttling enabled. Throttling, either by the use of TCC (also > called P4TCC) or the older, externally implemented throttling > mechanism, is a BAD BAD THING! I have complained for years about it > being the default. It is intended for thermal control, not power > management. The power savings will be negligible and, in combination > with deep sleep modes (Cx > 2) can and do result in the CPU going into > deep sleep and never waking up. > > You can (and should) disable them in /boot/loader.conf with: > # Disable CPU throttling > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > This should greatly reduce the large number of "frequencies" > available, but they will be the ones provided by EST.which really do > reduce power consumption. (I put frequencies in quotation marks > because throttling does not really change the clock speed. It simply > skips 'N' of every 8 clock cycles. Still, compared to C3 and higher, > EST is a minor power savings. interesting. Can you elaborate on that ? This is one of my new machines, hw.model: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P000 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 600 dev.cpu.0.freq_levels: 3401/255000 3300/245000 3200/236000 3100/227000 3000/218000 2900/209000 2800/200000 2700/192000 2600/183000 2500/175000 2400/167000 2300/159000 2200/151000 2100/143000 1837/125125 1600/87000 1400/76125 1200/65250 1000/54375 800/43500 600/32625 400/21750 200/10875 dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 210us Here using C1 or C3 does not seem to make any difference at all in terms of power (measured with a Kill-a-watt style wattmeter), and irrespective of the frequency setting the idle power does not change much (48..56W across the entire range). This is on FreeBSD 9 with HZ=1000, maybe some marginal savings can be achieved setting HZ=100 (at some point i will give it a try). Under heavy load (16 threads running infinite loops across the 4 cores) the power goes up as expected (up to 118W for 4 cores, 76W using just 1 core), and powerd seems to do a decent job in keeping the idle power low. I guess that the credit for power saving goes mostly to the CPU architects. Powerd only gives second-order savings, and C1 vs. C3 is ineffective, at least for HZ=1000 CPU Power (watts) freq idle 16 threads ----------------------- 200 48 51 2200 52 83 3200 54 115 3401 56 118 powerd 48 118 cheers luigi From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 17:33:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C37811065676; Wed, 21 Mar 2012 17:33:42 +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 411068FC18; Wed, 21 Mar 2012 17:33:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2LHXYSW067734; Wed, 21 Mar 2012 21:33:34 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 21 Mar 2012 21:33:34 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (woozle.rinet.ru [0.0.0.0]); Wed, 21 Mar 2012 21:33:35 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 21 Mar 2012 17:33:42 -0000 On Mon, 19 Mar 2012, Steven Hartland wrote: > > > Not sure its been released yet but we where running a pre-release BIOS > > > which > > > added the ability to disabled C1E, which caused us CPU performance issue > > > in > > > are particular environment. > > > > This sounds interesting. Could you please share some links? Our MicroCloud > > blades have BIOS 1.0a, which is the latest mentioned at SuperMicro site. > > Its 1.0b, I'm sure if you ask Supermicro for it they will provide otherwise > I'll fire it to you on private email. Quick update: I have received 1.0b from Mar 19, flashed it, but nothing changes regarding disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. Will investigate further. -- 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 Mar 21 17:50:38 2012 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 441FD106564A for ; Wed, 21 Mar 2012 17:50:38 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id EA6AB8FC12 for ; Wed, 21 Mar 2012 17:50:37 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q2LHo4lw071448 for ; Wed, 21 Mar 2012 18:50:18 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q2LHnMPJ039755 for ; Wed, 21 Mar 2012 18:49:22 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q2LHnL0s039752; Wed, 21 Mar 2012 18:49:21 +0100 (CET) (envelope-from arno) To: stable@freebsd.org From: "Arno J. Klaassen" Date: Wed, 21 Mar 2012 18:49:21 +0100 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F6A14CC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F6A14CC.002/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: Subject: 9-STABLE and Iphone modem (tethering), anyone succeed ? 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, 21 Mar 2012 17:50:38 -0000 Hello, does anyone succeed in using an Iphone as modem on 9-STABLE (sources as of March 16) ? I follow the instructions from 'http://forums.freebsd.org/showthread.php?t=19995' using 'usbmuxd' and 'libimobiledevice' from ports. When I start 'usbmuxd' I indeed see in dmesg(1) : ipheth0: on usbus1 ue0: on ipheth0 ue0: bpf attached ue0: Ethernet address: XXX I did not find 'ipheth-pair' (or something equiivalent) in ports, I build it from the sources as indicated in the forum-post, but it fails with : # ./ipheth-pair -v ./ipheth-pair: -14: cannot get lockdown The corresponsing log from 'usbmuxd -v -v ' says (stripped) : [16:29:20.490][3] usbmuxd v1.0.7 starting up [16:29:20.491][4] Creating socket [16:29:20.491][5] client_init [16:29:20.491][5] device_init [16:29:20.491][4] Initializing USB [16:29:20.491][5] usb_init for linux / libusb 1.0 [16:29:20.491][4] Found new device with v/p 05ac:1297 at 1-3 [16:29:20.491][4] Found interface 1 with endpoints 04/85 for device 1-3 [16:29:20.495][4] Using wMaxPacketSize=512 for device 1-3 [16:29:20.495][3] Connecting to new device on location 0x10003 as ID 1 [16:29:20.495][4] 1 device detected [16:29:20.495][3] Initialization complete [16:29:20.495][5] usb polling enable: 0 [16:29:20.496][3] Connected to v1.0 device 1 on location 0x10003 with serial number XXX [16:29:20.496][5] client_device_add: id 1, location 0x10003, serial XXX [16:29:46.428][4] New client on fd 9 [16:29:46.428][5] Client command in fd 9 len 16 ver 0 msg 3 tag 1 [16:29:46.428][5] send_pkt fd 9 tag 1 msg 1 payload_length 4 [16:29:46.428][5] Client 9 now LISTENING [16:29:46.428][5] Enlarging client 9 reply buffer 1024 -> 1308 to make space for device notifications [16:29:46.428][5] send_pkt fd 9 tag 0 msg 4 payload_length 268 [16:29:47.437][4] Client 9 connection closed [16:29:47.437][4] Disconnecting client fd 9 [16:29:47.437][4] New client on fd 9 [16:29:47.437][5] Client command in fd 9 len 24 ver 0 msg 2 tag 2 [16:29:47.437][5] Client 9 connection request to device 1 port 62078 [16:29:47.437][5] [OUT] dev=1 sport=1 dport=62078 seq=0 ack=0 flags=0x2 window=131072[512] len=0 [16:29:47.439][5] [IN] dev=1 sport=62078 dport=1 seq=0 ack=1 flags=0x12 window=131072[512] len=0 [16:29:47.439][5] [OUT] dev=1 sport=1 dport=62078 seq=1 ack=1 flags=0x10 window=131072[512] len=0 [16:29:47.440][5] send_pkt fd 9 tag 2 msg 1 payload_length 4 [16:29:47.440][5] Client 9 switching to CONNECTED state [16:29:47.442][5] [OUT] dev=1 sport=1 dport=62078 seq=1 ack=1 flags=0x10 window=131072[512] len=4 ... (all having 'flags=0x10') [16:29:47.499][5] [IN] dev=1 sport=62078 dport=1 seq=3502 ack=14410 flags=0x10 window=131072[512] len=279 [16:29:47.501][5] [IN] dev=1 sport=62078 dport=1 seq=3781 ack=14410 flags=0x4 window=0[0] len=32 [16:29:47.501][5] RST reason: [16:29:47.501][4] Connection reset by device 1 (1->62078) [16:29:47.501][5] connection_teardown dev 1 sport 1 dport 62078 [16:29:47.501][4] Disconnecting client fd 9 [16:29:47.501][4] client_process: fd 9 not found in client list I hope anyone reading this has had more succes ;-). Thanx, Arno NB 1, Iphone not 'jailbroken' NB 2, yes 'it works' under Windows From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 21:36:05 2012 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 371C6106564A; Wed, 21 Mar 2012 21:36:05 +0000 (UTC) (envelope-from prvs=142709aed4=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 987798FC12; Wed, 21 Mar 2012 21:36:04 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Wed, 21 Mar 2012 21:35:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018921975.msg; Wed, 21 Mar 2012 21:35:03 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=142709aed4=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <8C4E15FAFD134E0E82C0A8499D654E27@multiplay.co.uk> From: "Steven Hartland" To: "Dmitry Morozovsky" References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> Date: Wed, 21 Mar 2012 21:35:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 21 Mar 2012 21:36:05 -0000 ----- Original Message ----- From: "Dmitry Morozovsky" > Quick update: > > I have received 1.0b from Mar 19, flashed it, but nothing changes regarding > disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. > > Will investigate further. Which version of FreeBSD is this on Dmitry? Just checked our machines here and not seeing anything in /var/log/messages about this, so curious. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 21 23:44:18 2012 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 E2768106566C for ; Wed, 21 Mar 2012 23:44:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A5AB28FC14 for ; Wed, 21 Mar 2012 23:44:18 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q2LNiHGG030250; Wed, 21 Mar 2012 19:44:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F6A67C0.7000909@sentex.net> Date: Wed, 21 Mar 2012 19:44:00 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matt Thyer References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 21 Mar 2012 23:44:19 -0000 On 3/20/2012 1:26 AM, Matt Thyer wrote: > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > r232477 (4th Mar 2012) and am finding that a system process called "intr" > is now constantly using about 60% of 1 CPU starting a short time after > reboot (possibly triggered by use of the samba server). > > When this starts, systat -vm 1 says that the system is 85% idle and 14% > interrupt handling. > It says that there's around 157k interrupts per second. > > Any idea what could be the cause ? This sounds like the problem I had with my intel board. BIOS update fixed it. What chipset and MB vendor do you have ? /usr/ports/sysutils/dmidecode is handy for digging up BIOS and chipset info http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239394.html ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 07:24:29 2012 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 2876A106566C for ; Thu, 22 Mar 2012 07:24:29 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id 05D368FC14 for ; Thu, 22 Mar 2012 07:24:28 +0000 (UTC) To: Kevin Oberman In-reply-to: References: <20120321000058.177F8256@server.theusgroup.com> Comments: In-reply-to Kevin Oberman message dated "Wed, 21 Mar 2012 09:32:47 -0700." Date: Thu, 22 Mar 2012 00:24:22 -0700 From: John Message-Id: <20120322072422.5F4DD2B5@server.theusgroup.com> Cc: Matthias Gamsjager , freebsd-stable@freebsd.org Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 07:24:29 -0000 > >If you are trying to reduce power consumption, why are you limiting Cx >states to C2 (which save little) and not C3 (which will save a LOT of >power when the CPU is not heavily loaded). With my hardware, i5-650, using C3 does not result in lower power consumption versus C2. Both states draw exactly the same power. hw.acpi.cpu.cx_lowest: C3 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C3 dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C3 dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C3 dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C3 71w idle power hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C2 dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C2 dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C2 dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C2 71w idle power John Theus TheUs Group TheUsGroup.com From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 07:37:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 298F81065674 for ; Thu, 22 Mar 2012 07:37:21 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id F39378FC0C for ; Thu, 22 Mar 2012 07:37:20 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q2M7bKv4007750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2012 00:37:20 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q2M7bK9H007748; Thu, 22 Mar 2012 00:37:20 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA17567; Wed, 21 Mar 12 23:26:44 PST Date: Thu, 22 Mar 2012 07:26:04 -0700 From: perryh@pluto.rain.com To: kob6558@gmail.com Message-Id: <4f6b367c.iDW/lrO6B5MAYpoK%perryh@pluto.rain.com> References: <20120321000058.177F8256@server.theusgroup.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mgamsjager@gmail.com, freebsd-stable@freebsd.org, john@theusgroup.com Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 07:37:21 -0000 Kevin Oberman wrote: > Throttling ... is intended for thermal control, not power > management. The power savings will be negligible ... How can it possibly provide any thermal benefit, if it does not reduce power consumption? Is there some significant heat source, other than power consumed, that throttling reduces? From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 07:56:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDB88106566C for ; Thu, 22 Mar 2012 07:56:43 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id AB6E58FC12 for ; Thu, 22 Mar 2012 07:56:43 +0000 (UTC) To: Kevin Oberman In-reply-to: References: <20120321000058.177F8256@server.theusgroup.com> Comments: In-reply-to Kevin Oberman message dated "Wed, 21 Mar 2012 09:32:47 -0700." Date: Thu, 22 Mar 2012 00:56:43 -0700 From: John Message-Id: <20120322075643.5530E2C9@server.theusgroup.com> Cc: Matthias Gamsjager , freebsd-stable@freebsd.org Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 07:56:43 -0000 > >If you are trying to reduce power consumption, why are you limiting Cx >states to C2 (which save little) and not C3 (which will save a LOT of >power when the CPU is not heavily loaded). On my previous post I forgot to set kern.hz=100. This change does lower idle power from 71w to 62w. With my hardware, i5-650, using C3 does not result in lower power consumption versus C2. Both states draw exactly the same power. hw.acpi.cpu.cx_lowest: C3 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C3 dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C3 dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C3 dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C3 62w idle power hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C2 dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C2 dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C2 dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C2 62w idle power John Theus TheUs Group TheUsGroup.com From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 08:39:31 2012 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 31FA3106564A; Thu, 22 Mar 2012 08:39:31 +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 A39C98FC15; Thu, 22 Mar 2012 08:39:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2M8dTEa090851; Thu, 22 Mar 2012 12:39:29 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 22 Mar 2012 12:39:29 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: <8C4E15FAFD134E0E82C0A8499D654E27@multiplay.co.uk> Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> <8C4E15FAFD134E0E82C0A8499D654E27@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (woozle.rinet.ru [0.0.0.0]); Thu, 22 Mar 2012 12:39:29 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel 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, 22 Mar 2012 08:39:31 -0000 On Wed, 21 Mar 2012, Steven Hartland wrote: > > I have received 1.0b from Mar 19, flashed it, but nothing changes regarding > > disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. > > > > Will investigate further. > > Which version of FreeBSD is this on Dmitry? Just checked our machines here > and not seeing anything in /var/log/messages about this, so curious. I'm now testing two blades, one with releng/8, and second with releng/9. Same effect. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 09:51:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7CDF106564A for ; Thu, 22 Mar 2012 09:51:30 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5AA8FC14 for ; Thu, 22 Mar 2012 09:51:30 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4315E.dip.t-dialin.net [79.196.49.94]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E38BE844846; Thu, 22 Mar 2012 10:51:16 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 2FA09252C; Thu, 22 Mar 2012 10:51:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1332409874; bh=9BeMJRia13g+iB5310b4tq18b4Jsp2iSOD3PQjMtBVI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PMW2yOFNGA263dr13Gt9G7bsPZDmRKsYFu86DlNNDz4zmwgQ1oaAyMX+NDzngmtXj 4J+eMUlGZ4RjK1MSUEMqHPfvO9oq7LXvPH17F7AQ7qyvX3d2h3Os7cSxpYr2jV/JeF kkhexbpTL/BHCv4EX42rdzI7n/Q69OMZgs6+ayQ48cD4eo3uVJQAHVHniWcNelyNbk PrAGHR2nTx2t47ljUHPVzZXLxh7QMQC9aEH9PzZKTeWCyQSg5CU4r3JK3o78ocR6hZ tw89flTQ04gfR6DCOmCZbk/urnWgar7hRf5M75ArsYv206xX5S220HmrLNAKN7Uvg5 VJHgNWBPj6MFQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q2M9pCJs046311; Thu, 22 Mar 2012 10:51:12 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 195.46.238.194 ([195.46.238.194]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 22 Mar 2012 10:51:12 +0100 Date: Thu, 22 Mar 2012 10:51:09 +0100 Message-ID: <20120322105109.Horde.srohf5jmRSRPavYNP_frKBA@webmail.leidinger.net> From: Alexander Leidinger To: Luigi Rizzo References: <20120321000058.177F8256@server.theusgroup.com> <20120321173728.GA41322@onelab2.iet.unipi.it> In-Reply-To: <20120321173728.GA41322@onelab2.iet.unipi.it> User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E38BE844846.A2B44 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.806, required 6, autolearn=disabled, AWL -0.70, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1333014677.79888@E+RcCm+EkcXW9t2SPHYeiw X-EBL-Spam-Status: No Cc: Matthias Gamsjager , freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 09:51:30 -0000 Quoting Luigi Rizzo (from Wed, 21 Mar 2012 18:37:28 +0100): > I guess that the credit for power saving goes mostly to the CPU > architects. Powerd only gives second-order savings, and C1 vs. C3 > is ineffective, at least for HZ=1000 > > CPU Power (watts) > freq idle 16 threads > ----------------------- > 200 48 51 > 2200 52 83 > 3200 54 115 > 3401 56 118 > > powerd 48 118 I hope you all don't use a cheap PSU, but a _good_ high efficient one, which really draws less power when idle instead of generating heat. Some PSUs are only efficient in a sweet spot, instead of being efficient over a broad range, even when being idle. See http://en.wikipedia.org/wiki/80_PLUS for a quick and not so in-deep overview (and the reality may differ from manufacturer to manufacturer). Bye, Alexander. -- That does not compute. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 13:19:41 2012 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 179AF106564A for ; Thu, 22 Mar 2012 13:19:41 +0000 (UTC) (envelope-from mike@tkachuk.name) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 86B128FC1A for ; Thu, 22 Mar 2012 13:19:39 +0000 (UTC) Received: by eekd17 with SMTP id d17so735420eek.13 for ; Thu, 22 Mar 2012 06:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tkachuk.name; s=google; h=date:from:reply-to:x-priority:message-id:to:subject:mime-version :content-type:content-transfer-encoding; bh=DL7zrTXw0qhDcQCnJ1XuL4J9O2kDq3PG2mVU0ZdLPas=; b=QxnrWzd2RZMgqRlbHZTyk3BqmoOIjkd4/nIlx5FISdCqJPYaIKeEsm9PS0yMgP7D/7 wVpJ1tKwY744Z9Vb5wcTMFkhG8xuY7W3XrdH+wG2k9yw1QPo2m8I/9d08VekHYkZSn+a E75shXoeVJhykPI5zvop7XiqF5OFGgWI4JC5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:x-priority:message-id:to:subject:mime-version :content-type:content-transfer-encoding:x-gm-message-state; bh=DL7zrTXw0qhDcQCnJ1XuL4J9O2kDq3PG2mVU0ZdLPas=; b=FLWuvJYEjcWb1grZdZRcjT+kCQ7b68KVEtSIWj6UdLRTRCJggK4RcuvWpu+/RvYDrS 5UvgS5wJsNjj0g8wGjCvdvmY1eGsICR59y37M4oscRe0gEUGOhL1H/Nkn/8/aLJXX7mS aeF6Mho+nDZ2DR4NVE2y5gAwWFpWCa0hGo/WFZd1ssrbvYrh6QWfKWGYhSJ1F5fi1FUM yOYWMcRAKlRUeIy751Ch/DQL/aYs+sartw1ePKHUa6hCO9Ak1zDCScQ8W57e0VJEhpjA 4EuwYxVVbSSrVy7CUtjfjCaMAbHdNQUPYzh7F06qNaZJhatKq/waJbykXGIaNX8CMhue ROHw== Received: by 10.213.105.143 with SMTP id t15mr599521ebo.133.1332422378218; Thu, 22 Mar 2012 06:19:38 -0700 (PDT) Received: from [192.168.202.2] (nat64.yes.net.ua. [195.114.96.64]) by mx.google.com with ESMTPS id p57sm17018129eei.8.2012.03.22.06.19.36 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 06:19:37 -0700 (PDT) Date: Thu, 22 Mar 2012 15:19:34 +0200 From: Mike Tkachuk X-Priority: 3 (Normal) Message-ID: <1977769407.20120322151934@tkachuk.name> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktRZX6TriAVd4jz53efnMoYG3Qm+DAGzR1I/2RF6ixuIiN4bHLu/cMO/K4XLJLE1Bt/eL1 Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mike Tkachuk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:19:41 -0000 Hello Ian, I'm also facing same problem, just updated to esxi 5 update1, will see if it changes anything. It really looks like an esxi problem but I did not experienced it with FreeBSD 8 Here is the output of requested commands: sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) i8254(0) ACPI-fast(900) HPET(950) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1217640570 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 708780 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 14912 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1849391829 kern.timecounter.tc.TSC.frequency: 3411483000 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(600) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.et.LAPIC.frequency: 33000086 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 4 vmstat -i interrupt total rate irq1: atkbd0 192 0 irq15: ata1 17 0 irq18: em0 3519101 2 cpu0:timer 92428991 63 irq256: mpt0 1887875 1 cpu2:timer 29982105 20 cpu1:timer 46249642 31 cpu3:timer 15983874 10 cpu6:timer 4721414 3 cpu7:timer 4554357 3 cpu4:timer 8397088 5 cpu5:timer 6163947 4 Total 213888603 146 ----- near 10 sec later ----- sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) i8254(0) ACPI-fast(900) HPET(950) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1217640570 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 802778 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 24402 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 3853372129 kern.timecounter.tc.TSC.frequency: 3411483000 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(600) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.et.LAPIC.frequency: 33000086 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 4 vmstat -i interrupt total rate irq1: atkbd0 192 0 irq15: ata1 17 0 irq18: em0 3519133 2 cpu0:timer 92429487 63 irq256: mpt0 1887875 1 cpu2:timer 29983186 20 cpu1:timer 46250719 31 cpu3:timer 15983969 10 cpu6:timer 4721451 3 cpu7:timer 4554394 3 cpu4:timer 8397125 5 cpu5:timer 6164274 4 Total 213891822 146 -- Best regards, Mike mailto:mike@tkachuk.name From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 13:59:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9DAD1065674 for ; Thu, 22 Mar 2012 13:59:52 +0000 (UTC) (envelope-from rizzo.unipi@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 75D698FC0A for ; Thu, 22 Mar 2012 13:59:52 +0000 (UTC) Received: by iahk25 with SMTP id k25so4144514iah.13 for ; Thu, 22 Mar 2012 06:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=O3LqnwuD/uka9Lfz/MavMupC6MeLfZq2gfcMKQDPj2M=; b=TTgiCnWVUPqUQqbjzE/uh8+OqcSC66ozbzSP8gOzky2dOgEptTIcHGWM0KQ1cmxT6j FpK9q3r3Bx/EGNtDH/aK4HQx+Ubvr1EhPyyIzz+Z5Holh/XVVXziZ9v+Vb64rNPcGDl6 LXNMmbx8krPHYq0UFwOWVTLGLTttjWiEdbAcsxCYfARYMjkdnbYOQqZIClJfFWGxfxWy 0wld8OZnDvJM2olhVC/Vgra7ggwe7TFODj6I5E6B2ee77/TS2+IvKw2Nkr1WjSDPAGGu XKQxYUkVRmrQ4WzHaLbR10v4H6YKrvId42cQLKZJJHNTI1rPej4XcESSMwSgngKZVwQi 9cHg== MIME-Version: 1.0 Received: by 10.50.192.134 with SMTP id hg6mr1733155igc.59.1332424786247; Thu, 22 Mar 2012 06:59:46 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.42.197.134 with HTTP; Thu, 22 Mar 2012 06:59:46 -0700 (PDT) In-Reply-To: <20120322105109.Horde.srohf5jmRSRPavYNP_frKBA@webmail.leidinger.net> References: <20120321000058.177F8256@server.theusgroup.com> <20120321173728.GA41322@onelab2.iet.unipi.it> <20120322105109.Horde.srohf5jmRSRPavYNP_frKBA@webmail.leidinger.net> Date: Thu, 22 Mar 2012 14:59:46 +0100 X-Google-Sender-Auth: amHqUTdcSw5BLiUEpFpOycQ87jk Message-ID: From: Luigi Rizzo To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Matthias Gamsjager , freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 13:59:52 -0000 On Thu, Mar 22, 2012 at 10:51 AM, Alexander Leidinger < Alexander@leidinger.net> wrote: > Quoting Luigi Rizzo (from Wed, 21 Mar 2012 18:37:28 > +0100): > > I guess that the credit for power saving goes mostly to the CPU >> architects. Powerd only gives second-order savings, and C1 vs. C3 >> is ineffective, at least for HZ=1000 >> >> CPU Power (watts) >> freq idle 16 threads >> ----------------------- >> 200 48 51 >> 2200 52 83 >> 3200 54 115 >> 3401 56 118 >> >> powerd 48 118 >> > > I hope you all don't use a cheap PSU, but a _good_ high efficient one, > which really draws less power when idle instead of generating heat. Some > PSUs are only efficient in a sweet spot, instead of being efficient over a > broad range, even when being idle. See http://en.wikipedia.org/wiki/** > 80_PLUS for a quick and not so > in-deep overview (and the reality may differ from manufacturer to > manufacturer). > it isn't such a big deal in my opinion. The %efficiency at low levels is misleading if you don't factor out the 5-10W plateau for keeping the PSU alive (fan, ballast, etc.). See for instance http://www.techpowerup.com/reviews/Antec/HCG-520/5.html the table at the end of the page reports 6.73W of idle power. At 40W this PSU consumes 52.9W, so the apparent efficiency is 75%, but factoring out the idle power you go way up. cheers luigi -- > That does not compute. > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 14:33:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D52E1065675 for ; Thu, 22 Mar 2012 14:33:49 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B09878FC14 for ; Thu, 22 Mar 2012 14:33:48 +0000 (UTC) Received: by wern13 with SMTP id n13so2502784wer.13 for ; Thu, 22 Mar 2012 07:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mWBBbsWAa7ipIcsQw6Q5Dm9WQ+WrrCRuf+Pr5Eh8zxc=; b=MC9ZlYh+4vjeTZaLsAR8sbgOaiDLZRfAJGZ7qbul7hBFZ5OYR9XYzDmFgIOqEwXrGz P+k8it24OhkrEm1ggjGOF9x+tu0vlLFy85mT3iWSp3W/EXOq2EOfSpK2JiO+k3fgB6FD ZYFiJeoMdXFknInfDOOuEAJdouFYE5ZZszVFEiFY4h8vha4xTod/jYF/vRKxcGmIggbg SUXc62353Zo6/r150Mc0ceAopg6KqFBDTRjXhv9y8sLbRCNDLObmy3lkVmC0d69pjnc4 +5yjY97H/0Tcn2+/V4iatgjvaaqkkxDomVmyEu41OOwki/vbW3pqcWV0Va3lEL6ztvbY xv5w== MIME-Version: 1.0 Received: by 10.180.107.162 with SMTP id hd2mr5623529wib.8.1332426827582; Thu, 22 Mar 2012 07:33:47 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Thu, 22 Mar 2012 07:33:47 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Thu, 22 Mar 2012 07:33:47 -0700 (PDT) In-Reply-To: <4F6A67C0.7000909@sentex.net> References: <4F6A67C0.7000909@sentex.net> Date: Fri, 23 Mar 2012 01:03:47 +1030 Message-ID: From: Matt Thyer To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 22 Mar 2012 14:33:49 -0000 On Mar 22, 2012 10:14 AM, "Mike Tancsa" wrote: > > On 3/20/2012 1:26 AM, Matt Thyer wrote: > > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > > r232477 (4th Mar 2012) and am finding that a system process called "intr" > > is now constantly using about 60% of 1 CPU starting a short time after > > reboot (possibly triggered by use of the samba server). > > > > When this starts, systat -vm 1 says that the system is 85% idle and 14% > > interrupt handling. > > It says that there's around 157k interrupts per second. > > > > Any idea what could be the cause ? > > This sounds like the problem I had with my intel board. BIOS update > fixed it. What chipset and MB vendor do you have ? The original post tells you this. I've already updated to the latest BIOS and this could have caused the problem. I think I should try updating the firmware of the SAS/SATA HBA but not until I've confirmed if a BIOS downgrade works. Unfortunately it's very hard to get downtime on this system so it may be some time before I can report any news. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 14:46:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7BE4106566C for ; Thu, 22 Mar 2012 14:46:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 76C508FC08 for ; Thu, 22 Mar 2012 14:46:55 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q2MEkniK003846; Thu, 22 Mar 2012 10:46:49 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F6B3B46.4060105@sentex.net> Date: Thu, 22 Mar 2012 10:46:30 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matt Thyer References: <4F6A67C0.7000909@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 22 Mar 2012 14:46:55 -0000 On 3/22/2012 10:33 AM, Matt Thyer wrote: > > The original post tells you this. > I've already updated to the latest BIOS and this could have caused the > problem. Sorry, what I was getting at was that a bad bios (eg latest could have introduced a regression) can cause the symptoms you are seeing. The bios change sure seemed to fix my problem. In the mean time, try dmidecode to extract some of the versions of the BIOS and hardware you are using. Perhaps it might tweak someone's memory to a similar problem as yours. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:03:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930E6106566B for ; Thu, 22 Mar 2012 15:03:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E4B2B8FC18 for ; Thu, 22 Mar 2012 15:03:32 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4315E.dip.t-dialin.net [79.196.49.94]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 44F49844009; Thu, 22 Mar 2012 16:03:11 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 88846254E; Thu, 22 Mar 2012 16:03:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1332428588; bh=ZgHmnogn+lNsB+JsLcTzDSu8oTIJKJVC10JuuvDkm/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TmOBNowE+8IptLy5S9zhvipxoIS37iOTjePbmQVN75Vb/nSzyU6Y9Gp/xmQwa0TAG iLxiVtCp3q3JoGOu38lz9CtUdOOfSD3PDt+zFP8HVrusCTPkttjzipuCA+Dpc/iADa Q1sNZ3k7J6aJcgcn3LaGrVNGGfZfsTvDbibTgMeNq6krtb6ElOpZcEeuOl1wL8uJ9b A8E8SraXQlDKBdOyEq6ADccx4KCJeizOiAS75mjPHVdo8s/WP40Y7S5iNX0YcBfKx6 QqVkYuQ3uxna7L8y5nH87n1XyPEHKsSZj4GGt/Dse46BELapgjSuzBo7nQsIbX4QIc MfB1A5z3lAQYw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q2MF36ZR066200; Thu, 22 Mar 2012 16:03:06 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 195.46.238.194 ([195.46.238.194]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 22 Mar 2012 16:03:06 +0100 Date: Thu, 22 Mar 2012 16:03:04 +0100 Message-ID: <20120322160304.Horde.WUE3BZjmRSRPaz8oHUAxAog@webmail.leidinger.net> From: Alexander Leidinger To: Luigi Rizzo References: <20120321000058.177F8256@server.theusgroup.com> <20120321173728.GA41322@onelab2.iet.unipi.it> <20120322105109.Horde.srohf5jmRSRPavYNP_frKBA@webmail.leidinger.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 44F49844009.A085D X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.267, required 6, autolearn=disabled, AWL -1.92, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, MANGLED_LOW 2.30, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1333033391.84591@n7oIH2L2XMM2A/CWW8LKiQ X-EBL-Spam-Status: No Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Description: Textnachricht X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Matthias Gamsjager , freebsd-stable@freebsd.org, John Subject: Re: powerd and increase in energy need 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, 22 Mar 2012 15:03:33 -0000 Quoting Luigi Rizzo (from Thu, 22 Mar 2012 14:59:46 +0100): > it isn't such a big deal in my opinion. The %efficiency at low > levels is misleading if you don't factor out the=A05-10W plateau for > keeping the > PSU alive (fan, ballast, etc.). See for instance > > My point is: if you (plural) don't see the expected difference between the states or frequency levels, you first have to make sure your PSU is working in a way which allows to see a difference before you can tell that a C-state or a frequency change do not do what you want them to do. Bye, Alexander. -- Murray's Rule: Any country with "democratic" in the title isn't. http://www.Leidinger.net=A0 =A0 Alexander @ Leidinger.net: PGP ID =3D B0063= FE7 http://www.FreeBSD.org=A0 =A0 =A0 =A0netchild @ FreeBSD.org=A0 : PGP ID =3D= 72077137 From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:07:33 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87D201065675 for ; Thu, 22 Mar 2012 15:07:33 +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 B5B148FC0C for ; Thu, 22 Mar 2012 15:07:32 +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 RAA10344; Thu, 22 Mar 2012 17:07:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F6B4030.5090907@FreeBSD.org> Date: Thu, 22 Mar 2012 17:07:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Tkachuk References: <1977769407.20120322151934@tkachuk.name> In-Reply-To: <1977769407.20120322151934@tkachuk.name> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 15:07:33 -0000 on 22/03/2012 15:19 Mike Tkachuk said the following: > kern.eventtimer.periodic: 0 It might make sense to try 1 here. Also you could attempt to involve mav@ directly - here is an author of the code and an expert on it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:12:56 2012 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 735BB106566C for ; Thu, 22 Mar 2012 15:12:56 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC028FC08 for ; Thu, 22 Mar 2012 15:12:55 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 1AF525D44C for ; Thu, 22 Mar 2012 16:12:49 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id E5tbPnVPmMPq for ; Thu, 22 Mar 2012 16:12:48 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 7486D5D448 for ; Thu, 22 Mar 2012 16:12:48 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 68547450AB for ; Thu, 22 Mar 2012 16:12:48 +0100 (CET) Message-ID: <4F6B4170.4010804@incore.de> Date: Thu, 22 Mar 2012 16:12:48 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: FreeBSD 8 i386 don't boot from hd using gptboot 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, 22 Mar 2012 15:12:56 -0000 Hi, one of my FreeBSD 8 i386 server runs in a reboot loop after updating /sys/boot/i386/gptboot/Makefile from 1.62.63 to 1.62.6.4 (rev 230162). Several amd64 machines with the same Makefile for gptboot work fine. This issue was discussed for FreeBSD 9 some weeks ago in freebsd-current. Has anybody the same problem with FreeBSD 8 i386 ? -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:31:49 2012 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 2CC0E1065670 for ; Thu, 22 Mar 2012 15:31:49 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) 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 CE3298FC1F for ; Thu, 22 Mar 2012 15:31:47 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id ofBQ1i00G1uE5Es5EfWfar; Thu, 22 Mar 2012 15:30:39 +0000 Received: from hans3 ([66.30.197.229]) by omta16.westchester.pa.mail.comcast.net with comcast id ofWf1i00h4xSlmi3cfWfxJ; Thu, 22 Mar 2012 15:30:39 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAjyI-000Ned-1v for freebsd-stable@freebsd.org; Thu, 22 Mar 2012 11:30:38 -0400 From: Alex Goncharov To: freebsd-stable@freebsd.org Message-Id: Sender: Alex Goncharov Date: Thu, 22 Mar 2012 11:30:38 -0400 Subject: cdcontrol close: Invalid argument X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:31:49 -0000 On one of my FreeBSD 9 machines, 'cdcontrol eject' works fine but 'cdcontrol close' fails. Any ideas on the cause? (I have never seen anything like this on other machines, in any FreeBSD release.) Starting from the closed tray and seeing a successful physical eject: ---------------------------------------- dmesg > /tmp/d1; id -u; uname -r; for c in close eject close; do cmd="cdcontrol $c"; echo == $cmd; $cmd && echo 'OK' || echo 'not OK'; done; dmesg > /tmp/d2; diff /tmp/d1 /tmp/d2 0 9.0-STABLE == cdcontrol close cdcontrol: Invalid argument not OK == cdcontrol eject OK == cdcontrol close cdcontrol: Invalid argument not OK 618a619,626 > (cd0:ata0:0:0:0): START STOP UNIT. CDB: 1b 0 0 0 3 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) > (cd0:ata0:0:0:0): START STOP UNIT. CDB: 1b 0 0 0 3 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) ---------------------------------------- -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:33:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D67F8106566C; Thu, 22 Mar 2012 15:33:09 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECFD8FC08; Thu, 22 Mar 2012 15:33:08 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2527212bkc.13 for ; Thu, 22 Mar 2012 08:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BbMpH3wUVdAoSODn9vR4mvlXA4zlYJdQciBClNYmCGw=; b=KYbpdilmENPQc9OhvfnhLPOPAILledgB4gMLpSbI3n1bkeo0XUUQC5okwIFNpvUcSQ BtrPGo+Uo0bK8TFzyXBHuafO1Jt+M9xd8aO8P0eJZ1jBuRiTr08MZHF3s3L6bIC1ehY3 MOvQzJEHYPBu7I7NvRiHlJTVQTwGowMqHmcvsBULXtAv1fdN9tAeB/o2Dhkwyvzpu4c3 vfZkKYWQJ0MuKJCQC62erkSRJEKF7FZP8yo+1/UJN79tYb7KuZiE5Y2VhiwaD/8rul70 lnIvC+8+hkM+t5yDd1hiuRgFWKMQFSG7ksN/LIqwI2lDf3uU4F4K1XBB9Smo8vn6UQfP 0StQ== Received: by 10.204.154.66 with SMTP id n2mr3286868bkw.77.1332430388030; Thu, 22 Mar 2012 08:33:08 -0700 (PDT) Received: from green.tandem.local (132-186-132-95.pool.ukrtel.net. [95.132.186.132]) by mx.google.com with ESMTPS id fh5sm10646161bkc.1.2012.03.22.08.33.06 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 08:33:07 -0700 (PDT) Message-ID: <4F6B4631.8020006@gmail.com> Date: Thu, 22 Mar 2012 17:33:05 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Andriy Gapon References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> In-Reply-To: <4F6B4030.5090907@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Mike Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 15:33:09 -0000 Andriy Gapon wrote: > on 22/03/2012 15:19 Mike Tkachuk said the following: >> kern.eventtimer.periodic: 0 > > It might make sense to try 1 here. > Also you could attempt to involve mav@ directly - here is an author of the code > and an expert on it. Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with LAPIC) interrupt rate for me. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 15:56:08 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1601B106564A for ; Thu, 22 Mar 2012 15:56:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8D08FC08 for ; Thu, 22 Mar 2012 15:56:06 +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 RAA10697; Thu, 22 Mar 2012 17:56:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F6B4B93.7020309@FreeBSD.org> Date: Thu, 22 Mar 2012 17:56:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: Volodymyr Kostyrko References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> In-Reply-To: <4F6B4631.8020006@gmail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Mike Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 15:56:08 -0000 on 22/03/2012 17:33 Volodymyr Kostyrko said the following: > Andriy Gapon wrote: >> on 22/03/2012 15:19 Mike Tkachuk said the following: >>> kern.eventtimer.periodic: 0 >> >> It might make sense to try 1 here. >> Also you could attempt to involve mav@ directly - here is an author of the code >> and an expert on it. > > Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with > LAPIC) interrupt rate for me. Does it make your system unusable? Are you comparing with pre-eventtimers version of FreeBSD? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 16:13:37 2012 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 437C41065670; Thu, 22 Mar 2012 16:13:37 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7488FC12; Thu, 22 Mar 2012 16:13:36 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2574651bkc.13 for ; Thu, 22 Mar 2012 09:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HaGueAUbi/4e2EW925obY0+lpEePDtqUCBT1pmQoR8Q=; b=uNl75bn1WvgH6fxjCbtCJw2c+C9OvIxBucucoH/vi1lOg9q2pzmUO7EyNpjMMpAMwk SGkFuFD9V2zwdMvIGjYy1XLMNYxsoiku/oD9Ke9KLrXf1j+P32RQffXM5LG/JLGSTNdr DdsLV46F81h09KEyTt9SzdPsTi+HRLHXkHA9g055GsmaC6933KfaF04KiGL8SliFDutQ cMI0kfblUzE7lXC3ZgcwgAX/YE/eYxhGGMbztpVpIPRB/D4ZagiHBnu66f5RAtt3S34y xTo6cmgixmsu2JvdpG14bSZvp0aAS7PRZkUGcEKGrBMI0mAOpzMMSWEuTc0fB8gRWcly UZEw== Received: by 10.205.125.142 with SMTP id gs14mr3324994bkc.95.1332432815271; Thu, 22 Mar 2012 09:13:35 -0700 (PDT) Received: from green.tandem.local (132-186-132-95.pool.ukrtel.net. [95.132.186.132]) by mx.google.com with ESMTPS id u14sm10853799bkp.2.2012.03.22.09.13.33 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:13:34 -0700 (PDT) Message-ID: <4F6B4FAB.1020202@gmail.com> Date: Thu, 22 Mar 2012 18:13:31 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Andriy Gapon References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> In-Reply-To: <4F6B4B93.7020309@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Mike Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 16:13:37 -0000 Andriy Gapon wrote: > on 22/03/2012 17:33 Volodymyr Kostyrko said the following: >> Andriy Gapon wrote: >>> on 22/03/2012 15:19 Mike Tkachuk said the following: >>>> kern.eventtimer.periodic: 0 >>> >>> It might make sense to try 1 here. >>> Also you could attempt to involve mav@ directly - here is an author of the code >>> and an expert on it. >> >> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with >> LAPIC) interrupt rate for me. > > Does it make your system unusable? > Are you comparing with pre-eventtimers version of FreeBSD? In short term - no. Haven't tested it thoroughly. Results are the same (double interrupt rate according to `systat 1 -v`) for: * i386 and amd64 9-STABLE; * amd64 9.0. As everything related to timing/freq/acpi can be unpredictive I wouldn't recommend this to anyone. I own at least two Intel CPU's failing somewhere near timing/apic when loading cpufreq and enabling powerd. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 16:33:33 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51709106566C for ; Thu, 22 Mar 2012 16:33:33 +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 98C108FC0A for ; Thu, 22 Mar 2012 16:33:32 +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 SAA10991; Thu, 22 Mar 2012 18:33:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F6B5459.4090401@FreeBSD.org> Date: Thu, 22 Mar 2012 18:33:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: Volodymyr Kostyrko References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com> In-Reply-To: <4F6B4FAB.1020202@gmail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Mike Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 16:33:33 -0000 on 22/03/2012 18:13 Volodymyr Kostyrko said the following: > Andriy Gapon wrote: >> on 22/03/2012 17:33 Volodymyr Kostyrko said the following: >>> Andriy Gapon wrote: >>>> on 22/03/2012 15:19 Mike Tkachuk said the following: >>>>> kern.eventtimer.periodic: 0 >>>> >>>> It might make sense to try 1 here. >>>> Also you could attempt to involve mav@ directly - here is an author of the code >>>> and an expert on it. >>> >>> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with >>> LAPIC) interrupt rate for me. >> >> Does it make your system unusable? >> Are you comparing with pre-eventtimers version of FreeBSD? > > In short term - no. Haven't tested it thoroughly. Results are the same (double > interrupt rate according to `systat 1 -v`) for: > * i386 and amd64 9-STABLE; > * amd64 9.0. No comment. > As everything related to timing/freq/acpi can be unpredictive I wouldn't recommend > this to anyone. I own at least two Intel CPU's failing somewhere near timing/apic > when loading cpufreq and enabling powerd. > What exactly you wouldn't recommend? Let's not introduce unrelated topics and vague uncertainties. Setting kern.eventtimer.periodic to 1 makes eventtimer subsystem to behave less efficiently but more similar to the pre-eventtimer code. So this is #1 suggestion when people run into some new problems with eventtimers. Which is what this thread is about. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 16:34:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D6C7106567C for ; Thu, 22 Mar 2012 16:34:41 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1E58FC1D for ; Thu, 22 Mar 2012 16:34:41 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta11.emeryville.ca.mail.comcast.net with comcast id oeFD1i0051wfjNsABgabWq; Thu, 22 Mar 2012 16:34:35 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id ogaZ1i00F4NgCEG8jgaayH; Thu, 22 Mar 2012 16:34:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q2MGYWgY032729; Thu, 22 Mar 2012 10:34:32 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Volodymyr Kostyrko In-Reply-To: <4F6B4FAB.1020202@gmail.com> References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Mar 2012 10:34:32 -0600 Message-ID: <1332434072.8403.79.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Mike, freebsd-stable@freebsd.org, Andriy Gapon , Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 16:34:41 -0000 On Thu, 2012-03-22 at 18:13 +0200, Volodymyr Kostyrko wrote: > Andriy Gapon wrote: > > on 22/03/2012 17:33 Volodymyr Kostyrko said the following: > >> Andriy Gapon wrote: > >>> on 22/03/2012 15:19 Mike Tkachuk said the following: > >>>> kern.eventtimer.periodic: 0 > >>> > >>> It might make sense to try 1 here. > >>> Also you could attempt to involve mav@ directly - here is an author of the code > >>> and an expert on it. > >> > >> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with > >> LAPIC) interrupt rate for me. > > > > Does it make your system unusable? > > Are you comparing with pre-eventtimers version of FreeBSD? > > In short term - no. Haven't tested it thoroughly. Results are the same > (double interrupt rate according to `systat 1 -v`) for: > * i386 and amd64 9-STABLE; > * amd64 9.0. > > As everything related to timing/freq/acpi can be unpredictive I wouldn't > recommend this to anyone. I own at least two Intel CPU's failing > somewhere near timing/apic when loading cpufreq and enabling powerd. > I'm not sure I understand that advice. We have someone whose system is failing (time stops counting) when using the new event timer code. The recommendation is to set kern.eventtimer.periodic=1, which as I understand it makes the new code work more like it did before. That seems to be a reasonable attempt to work around the problem. If it works, the system becomes 100% more usable than it is now, even if that comes at the cost of timers interrupting twice as fast as they did in previous OS releases. It also generates another datapoint that might somehow help track down why the event timer code has trouble on some hardware. Enough such datapoints may eventually lead to an "aha -- it happens on all systems that have the xyz chipset." -- Ian From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 16:46:40 2012 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 CEAB5106566B; Thu, 22 Mar 2012 16:46:40 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5F58FC19; Thu, 22 Mar 2012 16:46:39 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2612562bkc.13 for ; Thu, 22 Mar 2012 09:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e13DKC8JUDL4zP4tn36KhDhlHcNuExTKMzpRxXdQ8MM=; b=NIjonGtxmOR6zN4L9JVVo5axXqQ+QQCC5pbpm3ZgjR9xkOedX++QJ+LnGYpTzToCBp KaTtShvXf1WO/sqP+Q1oOXT+H/JPl/5YKYmZt3UgnzhV87G0iWyb0eNozj6NFn/4Zvhi sDlB8Sukpl1qa+tPzkcsle2O9xgu5wg/bGASDUiN4KRQFRpadUMqWAq3PEp7QfW0rJxZ U4vfzDtMsldMu3U84fw5D9yUvQviw9TJncYWq7sl3EI3ZVt1zSY3z4i+U8Fqhu2AzzxE ohNO6bl9eqTs+dkqaLszVew5Bm7zgr925F2lWxWjL4dpdW8heqnZ6JB7MxwbtkZv7B3Y +3OQ== Received: by 10.204.132.80 with SMTP id a16mr3366588bkt.18.1332434798919; Thu, 22 Mar 2012 09:46:38 -0700 (PDT) Received: from green.tandem.local (132-186-132-95.pool.ukrtel.net. [95.132.186.132]) by mx.google.com with ESMTPS id v2sm10991488bki.7.2012.03.22.09.46.37 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:46:38 -0700 (PDT) Message-ID: <4F6B576B.7000803@gmail.com> Date: Thu, 22 Mar 2012 18:46:35 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Andriy Gapon References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com> <4F6B5459.4090401@FreeBSD.org> In-Reply-To: <4F6B5459.4090401@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Mike Tkachuk Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 22 Mar 2012 16:46:40 -0000 Andriy Gapon wrote: >> As everything related to timing/freq/acpi can be unpredictive I wouldn't recommend >> this to anyone. I own at least two Intel CPU's failing somewhere near timing/apic >> when loading cpufreq and enabling powerd. > What exactly you wouldn't recommend? > Let's not introduce unrelated topics and vague uncertainties. > > Setting kern.eventtimer.periodic to 1 makes eventtimer subsystem to behave less > efficiently but more similar to the pre-eventtimer code. So this is #1 suggestion > when people run into some new problems with eventtimers. Which is what this > thread is about. I'm sorry, I totally misunderstood the meaning of this tunable. Its unclear from man page which value enables or disables periodic code. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 16:57:28 2012 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 6D357106566C for ; Thu, 22 Mar 2012 16:57:28 +0000 (UTC) (envelope-from tevans.uk@googlemail.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 209AB8FC16 for ; Thu, 22 Mar 2012 16:57:27 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3090900vcm.13 for ; Thu, 22 Mar 2012 09:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rlTJRYo3eeBIjN1e/4XujoMkjYLnpzg1gmZzLHM7Nek=; b=EgfdjIaTcfVB1mGhVydMZau1LG8I4tbVWonrN+TQDj9tA3Ai52ExejDAvFDg+Vxhn0 dQUbkrPuLWtvx4MXKtuXR6o1AyC5NWgAEAFQfn+Ao+IiS2Tfp2Mn30h1lCUHc8x0flar K3fBZOj2i5jTT6QF2L+JqvEvoqccMtEAetdD+CBNqlbRxAt4Y7M5yBlsDanH4r1iMSjW UjtmgfNGo5lwC52vbvbMQLFtgsK8/L/0qrZttBV7DwX5pS8zSIxd/lbIDlr5ZNnHDO0l iJ9tP0NMMQGRV83TQw1U5Zq53hrIP69LgLlOrVhWaU+90K9SYAFRc7Iavw4sFWFw4Kfi IzeQ== MIME-Version: 1.0 Received: by 10.220.148.71 with SMTP id o7mr4082227vcv.34.1332435441204; Thu, 22 Mar 2012 09:57:21 -0700 (PDT) Received: by 10.52.161.71 with HTTP; Thu, 22 Mar 2012 09:57:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 16:57:21 +0000 Message-ID: From: Tom Evans To: =?UTF-8?B?RWZyYcOtbiBEw6ljdG9y?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 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, 22 Mar 2012 16:57:28 -0000 On Thu, Mar 22, 2012 at 4:02 PM, Efra=C3=ADn D=C3=A9ctor wrote: > Hello. I=E2=80=99m currently testing FreeBSD 9.0, I want to use it as a O= S for > a PostgreSQL Server. However, it is recommended to modified > some paramerts such as semaphores > (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): > > kern.ipc.semmap=3D256 > > But when I tried to change the value on FreeBSD this pops up: > > sysctl: unknown oid 'kern.ipc.semmap' > > What Can I do to resolve this issue?. > > Thank you. (9.0 discussions should go to stable@, not current@) I don't think that kern.ipc.semmap exists on 9.0 - at least, it is present on my 8-STABLE box, and not present on my 9-STABLE box (whilst other oids, eg kern.ipc.semmni exist on both) Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 17:36:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14B741065743 for ; Thu, 22 Mar 2012 17:36:44 +0000 (UTC) (envelope-from efraindector@motumweb.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 B24598FC1D for ; Thu, 22 Mar 2012 17:36:43 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2426416yhg.13 for ; Thu, 22 Mar 2012 10:36:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:organization :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole:x-gm-message-state; bh=4sHkG0BJu/M5QRFKaoE8BPhuiFVjrbKBZ/yNOwP/eLI=; b=o3REpoN+YLWoB/mIqCzX/LKad2f4qao5mq2klf3q0OIbyJNaGWwH++FLgVo1cKtyh5 9dg2naviTWm0X1YlniSNPE1JXeDQxSQUm4bDm2rT1WicZ1vvY/gY+q2ZZYro3JZlWQnJ vtR2jLHIiHHgMhXVdHN9fFmZBJaLkNlBc7i+C+WJPCueDWdRyi/lnYEeDRGu/dFfnLlc Yi7T5ojzCAmmpY1PcpaFMHIC482O+gVbkRH0W2nc4D/JC8F9F+vLX3VI7uEvcB8qt3tx 6sdrjuHpqvvrLP7fmVqN8hbg6WW3NXBBPcB83m2lZKpPBGS2U90qQf2/ZowatXZiMmEQ KKKw== Received: by 10.60.14.4 with SMTP id l4mr10913929oec.39.1332437802882; Thu, 22 Mar 2012 10:36:42 -0700 (PDT) Received: from CMOTUM25PC ([189.130.184.33]) by mx.google.com with ESMTPS id r7sm5270377obc.15.2012.03.22.10.36.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 10:36:41 -0700 (PDT) Message-ID: <2238A9A0B2934E1BA98E338483944B37@CMOTUM25PC> From: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= To: References: In-Reply-To: Date: Thu, 22 Mar 2012 11:36:39 -0600 Organization: =?UTF-8?Q?HESA_T=C3=A9cnica?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Gm-Message-State: ALoCoQmx5WHD9MA+hnA7svA+bxRtD5Txn+GEHJRAvizQBJhk/SnCaX3kAONy3f2s/DWtj2laO0t0 Subject: Re: About kern.ipc.semmap on FreeBSD 9 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, 22 Mar 2012 17:36:44 -0000 Sorry about posting to @current. Yep, kern.ipc.semmap does exists on FreeBSD 8.2 (I have configured it on sysctl.conf) but on FreeBSD 9.0 its gone, Volodymyr Kostyrko pointed out that this options need to be configured now on /boot/loader.conf (file that on 9.0 I had to create it manually unlike 8.2). Where can I find this type of changes that were made on 9.0?. Thank you. -----Mensaje original----- From: Tom Evans Sent: Thursday, March 22, 2012 10:57 AM To: Efraín Déctor Cc: freebsd-stable@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 On Thu, Mar 22, 2012 at 4:02 PM, Efraín Déctor wrote: > Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for > a PostgreSQL Server. However, it is recommended to modified > some paramerts such as semaphores > (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): > > kern.ipc.semmap=256 > > But when I tried to change the value on FreeBSD this pops up: > > sysctl: unknown oid 'kern.ipc.semmap' > > What Can I do to resolve this issue?. > > Thank you. (9.0 discussions should go to stable@, not current@) I don't think that kern.ipc.semmap exists on 9.0 - at least, it is present on my 8-STABLE box, and not present on my 9-STABLE box (whilst other oids, eg kern.ipc.semmni exist on both) Cheers Tom -----Mensaje original----- From: Volodymyr Kostyrko Sent: Thursday, March 22, 2012 10:15 AM To: Efraín Déctor Cc: freebsd-current@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 Efraín Déctor wrote: > Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a > PostgreSQL Server. However, it is recommended to modified some paramerts > such as semaphores > (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): > > kern.ipc.semmap=256 > > But when I tried to change the value on FreeBSD this pops up: > > sysctl: unknown oid 'kern.ipc.semmap' > > What Can I do to resolve this issue?. This one can be modified only in /boot/loader.conf -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 17:45:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2977B1065670 for ; Thu, 22 Mar 2012 17:45:14 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D42EA8FC15 for ; Thu, 22 Mar 2012 17:45:13 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1572600vbm.13 for ; Thu, 22 Mar 2012 10:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=j/QVTEHRQ8y4t4J7tMxjbMhMtUSSN3LrIC/vhiTX+v4=; b=tmQWw+45IKlHzaHUU+A/CWRtp2pOgdlVhdTrWowIKymL7VFNmLsbd4uHS98JlhcCSa iV18XFaKULl0kZwWTm1bF9GCsc7Iu2RkPfIvjtC0fdt8lfoWOgt1692miSaiJ3luEiZh ee59ksNYVqMvO2KDZKSBJ7jpwLxYhwEoaFkcNglQg4oqcOTZPV9Vqkqs9y8LUaPH0ucJ bZo2hPWunJKBX6I3tohFlS8KpCfIDzyMJu7zkbxjNI9HSBHw7ChiAfbCNq/y7YtaKogv uIlpFMbq4w/cjz51T8BuiJ0Ar244bKWN6/X2txfoc9Jzy1ztko9OW4TpcKqWHViaDC8S OoyQ== MIME-Version: 1.0 Received: by 10.220.147.198 with SMTP id m6mr4196456vcv.14.1332438312848; Thu, 22 Mar 2012 10:45:12 -0700 (PDT) Received: by 10.52.161.71 with HTTP; Thu, 22 Mar 2012 10:45:12 -0700 (PDT) In-Reply-To: <2238A9A0B2934E1BA98E338483944B37@CMOTUM25PC> References: <2238A9A0B2934E1BA98E338483944B37@CMOTUM25PC> Date: Thu, 22 Mar 2012 17:45:12 +0000 Message-ID: From: Tom Evans To: =?UTF-8?B?RWZyYcOtbiBEw6ljdG9y?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 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, 22 Mar 2012 17:45:14 -0000 On Thu, Mar 22, 2012 at 5:36 PM, Efra=C3=ADn D=C3=A9ctor wrote: > Sorry about posting to @current. > > Yep, kern.ipc.semmap does exists on FreeBSD 8.2 (I have configured it on > sysctl.conf) but on FreeBSD 9.0 its gone, Volodymyr Kostyrko pointed out > that this options need to be configured now on /boot/loader.conf (file th= at > on 9.0 I had to create it manually unlike 8.2). > > > Where can I find this type of changes that were made on 9.0?. > > Thank you. > http://www.freebsd.org/releases/9.0R/relnotes-detailed.html should have all changes in it; this seems to have been missed. This is the change: r224016 | bz | 2011-07-14 14:18:14 +0000 (Thu, 14 Jul 2011) | 10 lines Remove semaphore map entry count "semmap" field and its tuning option that is highly recommended to be adjusted in too much documentation while doing nothing in FreeBSD since r2729 (rev 1.1). ipcs(1) needs to be recompiled as it is accessing _KERNEL private variables. Reviewed by: jhb (before comment change on linux code) Sponsored by: Sandvine Incorporated which suggests that the option has not done anything for a very long time. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Mar 22 18:17:14 2012 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 ADC6F1065670 for ; Thu, 22 Mar 2012 18:17:14 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 666FB8FC0C for ; Thu, 22 Mar 2012 18:17:14 +0000 (UTC) Received: by obbuo13 with SMTP id uo13so2235567obb.13 for ; Thu, 22 Mar 2012 11:17:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:organization :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole:x-gm-message-state; bh=fsQOcuXDRBP3Wxkzcdtn9asN5ejN2mhkk0a5ECN/Iqk=; b=abONMj2QPPFbgbpZAMByGqERHKXU0x504rjyufUlZt4OoltjR5Pxo1OCtdcFUPXCCB ADoNoszUAzHzac5i9yDyTmFLJdDUuNjBv8BudRZKW82KEwDU7+4li2192ti6muVsMzSv zwEiYSUc0X9E0sxxTtjd06eAnwKVrqH1QglA+2lcOScS+jfIVbM3C+WCGH0aVVuLd7kv 6WGF79+wVj5moLWhgzg8tQ+xf5theJp12HhfIBPXpyNgQPEzI9EgTAiqBGRyW2eRsTmq n6WuzoOEJ6tKX7iZuutFCHKMFchxCwGb3C26II1VO+DZEgBsQkHeOpF4YJC2T1giUnL6 I7xw== Received: by 10.182.111.3 with SMTP id ie3mr11269583obb.14.1332440233882; Thu, 22 Mar 2012 11:17:13 -0700 (PDT) Received: from CMOTUM25PC ([189.130.184.33]) by mx.google.com with ESMTPS id f2sm4224823oef.6.2012.03.22.11.17.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 11:17:12 -0700 (PDT) Message-ID: <0B721D46BE094E2684FAE3D275996CBB@CMOTUM25PC> From: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= To: References: <2238A9A0B2934E1BA98E338483944B37@CMOTUM25PC> In-Reply-To: Date: Thu, 22 Mar 2012 12:17:11 -0600 Organization: =?UTF-8?Q?HESA_T=C3=A9cnica?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Gm-Message-State: ALoCoQmFzpPq42h/ZEiOpBiGZ+5ESWmc1Xezde5ji5Y2ut+b6erNahXxLh6Ilw6XvR4GpDzKpPzk Subject: Re: About kern.ipc.semmap on FreeBSD 9 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, 22 Mar 2012 18:17:14 -0000 Thank you for the information. -----Mensaje original----- From: Tom Evans Sent: Thursday, March 22, 2012 11:45 AM To: Efraín Déctor Cc: freebsd-stable@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 On Thu, Mar 22, 2012 at 5:36 PM, Efraín Déctor wrote: > Sorry about posting to @current. > > Yep, kern.ipc.semmap does exists on FreeBSD 8.2 (I have configured it on > sysctl.conf) but on FreeBSD 9.0 its gone, Volodymyr Kostyrko pointed out > that this options need to be configured now on /boot/loader.conf (file > that > on 9.0 I had to create it manually unlike 8.2). > > > Where can I find this type of changes that were made on 9.0?. > > Thank you. > http://www.freebsd.org/releases/9.0R/relnotes-detailed.html should have all changes in it; this seems to have been missed. This is the change: r224016 | bz | 2011-07-14 14:18:14 +0000 (Thu, 14 Jul 2011) | 10 lines Remove semaphore map entry count "semmap" field and its tuning option that is highly recommended to be adjusted in too much documentation while doing nothing in FreeBSD since r2729 (rev 1.1). ipcs(1) needs to be recompiled as it is accessing _KERNEL private variables. Reviewed by: jhb (before comment change on linux code) Sponsored by: Sandvine Incorporated which suggests that the option has not done anything for a very long time. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 06:43:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0056B106564A for ; Fri, 23 Mar 2012 06:43:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1CE8FC08 for ; Fri, 23 Mar 2012 06:43:19 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so1349698wib.13 for ; Thu, 22 Mar 2012 23:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DWX+HnKQsmlfrmhtMq6Jr7hSkH7jHR2fGXYMfKRZUTE=; b=029T1gJNtVDCoDmmjlBQN4UOSRpoKgCUPpq+f2//AgAOvsC+j6CmSOUCi3uGXbOcZ+ hSW+6dUvh7PV2FYgBp4bdLo0TU8QoE9p4H0jpiVKKcvWUkgvuBmUHOtMRgJe5Iki/J0s ieNTgHbo3Vlmh0ceIHUu3pxp2bbO6CIbHBH8aND4lWN9N1XjaahoMDjQDrXXow/AND+1 +ySWYUtUdUXc7ZB4PcNwSn04xOHDsaNbaeN6DnK/3yuvyFDZnVJwb17gWMxzCZryurVD rfBFh8XYfQdCcTKzZDGWqjT+KtqybLcDDzzZ32XkxKoQn/Ex5M3iEOzfF0u8aW0N2Kkb QYuw== MIME-Version: 1.0 Received: by 10.216.203.146 with SMTP id f18mr6267736weo.21.1332484998571; Thu, 22 Mar 2012 23:43:18 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Thu, 22 Mar 2012 23:43:18 -0700 (PDT) In-Reply-To: <4f6b367c.iDW/lrO6B5MAYpoK%perryh@pluto.rain.com> References: <20120321000058.177F8256@server.theusgroup.com> <4f6b367c.iDW/lrO6B5MAYpoK%perryh@pluto.rain.com> Date: Thu, 22 Mar 2012 23:43:18 -0700 Message-ID: From: Kevin Oberman To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mgamsjager@gmail.com, freebsd-stable@freebsd.org, john@theusgroup.com Subject: Re: powerd and increase in energy need 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, 23 Mar 2012 06:43:20 -0000 On Thu, Mar 22, 2012 at 7:26 AM, wrote: > Kevin Oberman wrote: > >> Throttling ... is intended for thermal control, not power >> management. The power savings will be negligible ... > > How can it possibly provide any thermal benefit, if it does not > reduce power consumption? =A0Is there some significant heat source, > other than power consumed, that throttling reduces? It does not provide reduced power because it was designed to control overheating. If hte CPU does not exceed the PSV temperature, it should not have any effect at all. That is its only purpose. If the system is idle, it makes no difference. If the CPU is loaded, it significantly lowers power consumption, but the operation takes longer to complete, so the total power consumed is often greater than it would have been with no throttling. Again, TCC is for thermal management, not power reduction. As to report I have seen that Cx states make things worse, I simply am baffled. I wonder if the power readings are really accurate. Theoretically the worst possible case is that there is no advantage to enabling Cx states. There should be no possible way to have it use more power. This is a real possibility, too, as it is very possible to have a system that simply would not use deeper sleep states. USB used to do exactly that, but it's been fixed with the new USB stack in 8. Other things like various forms of polling can also have this effect. You can check on whether your system is ever using deeper sleep by looking at dev.cpu.%d.cx_usage. Finally, all studies of power consumption agree that the lowest power usage is when CPU intensive code run as fast as possible when it is computing and then let deeper sleep modes sharply reduce power consumption when CPU is not needed. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 09:01:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEE0B1065677 for ; Fri, 23 Mar 2012 09:01:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by mx1.freebsd.org (Postfix) with ESMTP id 11FF78FC1A for ; Fri, 23 Mar 2012 09:01:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAKg7bE/LevdH/2dsb2JhbABEFrhxggkBAQMBAScRQQULCxgJEwMPCQMCAQIBRQYNAQcBAYgBBAy2BJEDBKYHgno Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail04.adl6.internode.on.net with ESMTP; 23 Mar 2012 19:31:00 +1030 Message-ID: <4F6C3B31.1060302@ShaneWare.Biz> Date: Fri, 23 Mar 2012 19:28:25 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120322 Thunderbird/10.0.3 MIME-Version: 1.0 To: Matt Burke References: <4F68FC3E.2090401@icritical.com> In-Reply-To: <4F68FC3E.2090401@icritical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: SAS Drive identification LEDs 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, 23 Mar 2012 09:01:11 -0000 On 21/03/2012 08:23, Matt Burke wrote: > Under 9.0-RELEASE I'm having trouble figuring out how to light up the drive > identification/fault lights on my enclosure (SAS disks on Chenbro > 80H10321513C0 backplanes attached to Areca ARC-1320 HBAs) > # setobjstat /dev/ses0 0xb 0x80 0x00 0x02 0x00 > < light on drive bay 8 starts flashing> > # setobjstat /dev/ses0 0xb 0x80 0x00 0x00 0x00 > < light on drive bay 8 stops flashing> > > Which is great, but how can I work out how /dev/daNN maps to /dev/sesN > element 0xNN? Not sure if I can help but I'll throw these thoughts at you - If I run dmesg | grep ada0 the first and last lines are - ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: Previously was known as ad4 or ls -l /dev | grep ada lrw-rw-rw- 1 root wheel - 4B 6 Mar 04:19 ad4@ -> ada0 lrw-rw-rw- 1 root wheel - 6B 6 Mar 04:19 ad4p1@ -> ada0p1 ... lrw-rw-rw- 1 root wheel - 4B 6 Mar 04:19 ad8@ -> ada1 lrw-rw-rw- 1 root wheel - 6B 6 Mar 16:19 ad8p1@ -> ada1p1 ... I think man glabel may give some ideas but man libgeom would be a starting place if your looking at drivers. > I've read mav@'s 2011 PDF on Enclosure Management > (http://people.freebsd.org/~mav/Enclosure_Management_en.pdf) which shows a > work-in-progress driver and getencstat which does what I need, but it looks > like the project's not been committed yet. Sounds like this is your best bet. Find out how close he is to release and offer to test, help push to be accepted in trunk. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 11:09:54 2012 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 68A0E106564A for ; Fri, 23 Mar 2012 11:09:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECEA8FC14 for ; Fri, 23 Mar 2012 11:09:54 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta07.emeryville.ca.mail.comcast.net with comcast id oz3L1i0040QkzPwA7z8oiG; Fri, 23 Mar 2012 11:08:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta02.emeryville.ca.mail.comcast.net with comcast id oz8n1i00L1t3BNj8Nz8oTg; Fri, 23 Mar 2012 11:08:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D4291102C1A; Fri, 23 Mar 2012 04:08:47 -0700 (PDT) Date: Fri, 23 Mar 2012 04:08:47 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20120323110847.GA12111@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Debugging periodic scripts 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, 23 Mar 2012 11:09:54 -0000 (Please keep me CC'd as I'm not subscribed) Hi folks, Does anyone know how to go about debugging periodic scripts, such as getting useful debug output from start to finish? Basically the situation is this: - We have 5 systems which are RELENG_8 (some 8.2-STABLE, and a couple 8.3-PRERELEASE). These are all bare metal boxes, not VMs. - All the machines have WITHOUT_IPFILTER=true defined in src.conf. - All the machines also have this in their /etc/periodic.conf : daily_status_security_ipfdenied_enable="no" - All the machines run ntpd and do not have clock skew problems or other odd anomalies (they all work great hardware-wise) or filesystem issues (all are using UFS2). On 2 of the systems, /etc/periodic/security/510.ipfdenied gets run during "periodic security" even though it's explicitly shut off in periodic.conf. Thus on these 2 systems, our security mails contain this line: ipfstat: not found I've checked permissions on everything I can think of (from / all the way down) but it all looks fine. I even wrote a small forloop to check all the systems' periodic.conf files and ensure the ipfdenied_enable line is proper (no weird trailing or preceding spaces, high-bit characters, DOS CRs, etc.) and they all check out (1 line, 44 characters long). One of the boxes was even recently rebuilt from scratch (full format + OS reinstall); it exhibited this problem prior to the rebuild, as well as after the rebuild. None of the systems have any unique changes to /root dotfiles nor the shell adjustments in things like /etc/profile, /etc/csh*, etc.. I've tried doing this: (sh -x /etc/periodic/security/510.ipfdenied >& /dev/stdout) | grep ipfdenied Which returns exactly what I would expect: + daily_status_security_ipfwdenied_enable=YES + daily_status_security_ipfdenied_enable=YES + daily_status_security_ipfwlimit_enable=YES + daily_status_security_ipf6denied_enable=YES + daily_status_security_ipfdenied_enable=no The first 4 come from /etc/defaults/periodic.conf, the last comes from /etc/periodic.conf. Running /etc/periodic/security/510.ipfdenied from a root shell results in no output. Editing /etc/periodic/security/510.ipfdenied's hashbang line to use -x doesn't change the behaviour either (maybe stderr gets sent to /dev/null?), whether I run it by hand as a script or via "periodic security". Other settings in periodic.conf are in fact honoured, such as daily_status_smart_enable and some others, so I'm inclined to believe periodic.conf is indeed being read. I don't know what's making this situation. I haven't resorted to using ktrace yet but will down the road assuming nobody has any other ideas. Otherwise something tells me I'm going to have to go look at the periodic source code to figure out what's going on under the hood. Thoughts/ideas? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 11:57:45 2012 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 D42D8106566C for ; Fri, 23 Mar 2012 11:57:45 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 391228FC08 for ; Fri, 23 Mar 2012 11:57:45 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q2NBvdxY006722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 23 Mar 2012 11:57:39 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.5.0 smtp.infracaninophile.co.uk q2NBvdxY006722 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1332503859; bh=Z+A2NhIOGMH+3zlv3qR4OBJxVVRFaAeY6wBa3melfDc=; h=Date:From:To:Subject:References:In-Reply-To:Cc:Content-Type: Message-ID:Mime-Version; b=GV0vwjb4Y/d82uQasDMFcXYAVqgdLDUMtVrJFBEKRftE7Q90ijcA9duIbVkDEjl30 R9T1vY15Axk6opcagB/6YDheUmhoBhLLXGcidU0FnF+AfKEHjXNbeNm48j3WUxvHCv SuCL/L/aZNgLhp4UBHgVmte9fVjIsZ/5eZlw9I3M= Message-ID: <4F6C6533.5050000@infracaninophile.co.uk> Date: Fri, 23 Mar 2012 11:57:39 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120323110847.GA12111@icarus.home.lan> In-Reply-To: <20120323110847.GA12111@icarus.home.lan> X-Enigmail-Version: 1.4 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC9944E7CE6DA868345CB5DC" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_ADSP_ALL,DKIM_SIGNED,T_DKIM_INVALID autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: Debugging periodic scripts 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, 23 Mar 2012 11:57:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC9944E7CE6DA868345CB5DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23/03/2012 11:08, Jeremy Chadwick wrote: > On 2 of the systems, /etc/periodic/security/510.ipfdenied gets run > during "periodic security" even though it's explicitly shut off in > periodic.conf. Thus on these 2 systems, our security mails contain thi= s > line: ipfstat: not found Are you sure that's not coming from 610.ipf6denied ? Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigAC9944E7CE6DA868345CB5DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9sZTMACgkQ8Mjk52CukIx1vgCgj2NC7nkYN8ALQtf+1EX1byY0 uEEAn3sLmDf2teKnalbGwV7hKq6oYeXB =7dCP -----END PGP SIGNATURE----- --------------enigAC9944E7CE6DA868345CB5DC-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 11:20:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B081065670; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) (envelope-from develloper.unix@hotmail.fr) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by mx1.freebsd.org (Postfix) with ESMTP id 82ADC8FC1E; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) Received: from BLU0-SMTP415 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:04 -0700 X-Originating-IP: [163.5.191.15] X-Originating-Email: [develloper.unix@hotmail.fr] Message-ID: Received: from [10.15.190.198] ([163.5.191.15]) by BLU0-SMTP415.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:02 -0700 Date: Fri, 23 Mar 2012 12:19:46 +0100 From: Quentin Schwerkolt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-wireless@freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2012 11:20:02.0479 (UTC) FILETIME=[E40733F0:01CD08E6] X-Mailman-Approved-At: Fri, 23 Mar 2012 16:16:15 +0000 Cc: Subject: Can't load many network kernel module in 8.3-PREREALEASE 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, 23 Mar 2012 11:20:10 -0000 Hi, I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. I have rebuild the system from the latest source. When I try a kldload /boot/kernel/if_*.ko I have error such as "file exist" or "exec format error". kldstat just after system start: Id Refs Address Size Name 1 1 0xffffffff80100000 e58280 kernel kldload -v /boot/kernel/if_*.ko: kldload: can't load /boot/kernel/if_ae.ko: File exists kldload: can't load /boot/kernel/if_age.ko: File exists kldload: can't load /boot/kernel/if_alc.ko: File exists kldload: can't load /boot/kernel/if_ale.ko: File exists kldload: can't load /boot/kernel/if_an.ko: File exists kldload: can't load /boot/kernel/if_ath.ko: Exec format error kldload: can't load /boot/kernel/if_aue.ko: Exec format error kldload: can't load /boot/kernel/if_axe.ko: Exec format error kldload: can't load /boot/kernel/if_bce.ko: File exists kldload: can't load /boot/kernel/if_bfe.ko: File exists kldload: can't load /boot/kernel/if_bge.ko: File exists kldload: can't load /boot/kernel/if_cdce.ko: Exec format error kldload: can't load /boot/kernel/if_cue.ko: Exec format error kldload: can't load /boot/kernel/if_dc.ko: File exists kldload: can't load /boot/kernel/if_de.ko: File exists kldload: can't load /boot/kernel/if_ed.ko: File exists kldload: can't load /boot/kernel/if_em.ko: File exists kldload: can't load /boot/kernel/if_en.ko: Exec format error kldload: can't load /boot/kernel/if_et.ko: File exists kldload: can't load /boot/kernel/if_faith.ko: Exec format error kldload: can't load /boot/kernel/if_fatm.ko: Exec format error kldload: can't load /boot/kernel/if_fwe.ko: Exec format error kldload: can't load /boot/kernel/if_fwip.ko: Exec format error kldload: can't load /boot/kernel/if_fxp.ko: File exists kldload: can't load /boot/kernel/if_gif.ko: Exec format error kldload: can't load /boot/kernel/if_hatm.ko: Exec format error kldload: can't load /boot/kernel/if_igb.ko: File exists kldload: can't load /boot/kernel/if_jme.ko: File exists kldload: can't load /boot/kernel/if_kue.ko: Exec format error kldload: can't load /boot/kernel/if_le.ko: File exists kldload: can't load /boot/kernel/if_lge.ko: File exists kldload: can't load /boot/kernel/if_msk.ko: File exists kldload: can't load /boot/kernel/if_nfe.ko: File exists kldload: can't load /boot/kernel/if_nge.ko: File exists kldload: can't load /boot/kernel/if_patm.ko: Exec format error kldload: can't load /boot/kernel/if_pcn.ko: File exists kldload: can't load /boot/kernel/if_ral.ko: File exists kldload: can't load /boot/kernel/if_re.ko: File exists kldload: can't load /boot/kernel/if_rl.ko: File exists kldload: can't load /boot/kernel/if_rue.ko: Exec format error kldload: can't load /boot/kernel/if_rum.ko: Exec format error kldload: can't load /boot/kernel/if_sf.ko: File exists kldload: can't load /boot/kernel/if_sge.ko: File exists kldload: can't load /boot/kernel/if_sis.ko: File exists kldload: can't load /boot/kernel/if_sk.ko: File exists kldload: can't load /boot/kernel/if_sn.ko: File exists kldload: can't load /boot/kernel/if_ste.ko: File exists kldload: can't load /boot/kernel/if_stge.ko: File exists kldload: can't load /boot/kernel/if_ti.ko: File exists kldload: can't load /boot/kernel/if_tl.ko: File exists kldload: can't load /boot/kernel/if_tun.ko: File exists kldload: can't load /boot/kernel/if_tx.ko: File exists kldload: can't load /boot/kernel/if_txp.ko: File exists kldload: can't load /boot/kernel/if_uath.ko: Exec format error kldload: can't load /boot/kernel/if_udav.ko: Exec format error kldload: can't load /boot/kernel/if_upgt.ko: Exec format error kldload: can't load /boot/kernel/if_ural.ko: Exec format error kldload: can't load /boot/kernel/if_vge.ko: File exists kldload: can't load /boot/kernel/if_vlan.ko: Exec format error kldload: can't load /boot/kernel/if_vr.ko: File exists kldload: can't load /boot/kernel/if_vx.ko: File exists kldload: can't load /boot/kernel/if_wb.ko: File exists kldload: can't load /boot/kernel/if_wi.ko: File exists kldload: can't load /boot/kernel/if_xl.ko: File exists kldload: can't load /boot/kernel/if_zyd.ko: Exec format error Loaded /boot/kernel/if_bridge.ko, id=2 Loaded /boot/kernel/if_bwi.ko, id=4 Loaded /boot/kernel/if_bwn.ko, id=5 Loaded /boot/kernel/if_carp.ko, id=7 Loaded /boot/kernel/if_cas.ko, id=8 Loaded /boot/kernel/if_cxgb.ko, id=9 Loaded /boot/kernel/if_cxgbe.ko, id=10 Loaded /boot/kernel/if_disc.ko, id=11 Loaded /boot/kernel/if_edsc.ko, id=12 Loaded /boot/kernel/if_ef.ko, id=13 Loaded /boot/kernel/if_epair.ko, id=15 Loaded /boot/kernel/if_gem.ko, id=17 Loaded /boot/kernel/if_gre.ko, id=18 Loaded /boot/kernel/if_hme.ko, id=19 Loaded /boot/kernel/if_ic.ko, id=20 Loaded /boot/kernel/if_ipheth.ko, id=22 Loaded /boot/kernel/if_ipw.ko, id=23 Loaded /boot/kernel/if_iwi.ko, id=24 Loaded /boot/kernel/if_iwn.ko, id=25 Loaded /boot/kernel/if_ixgb.ko, id=26 Loaded /boot/kernel/if_lagg.ko, id=27 Loaded /boot/kernel/if_lmc.ko, id=28 Loaded /boot/kernel/if_malo.ko, id=31 Loaded /boot/kernel/if_mwl.ko, id=32 Loaded /boot/kernel/if_mxge.ko, id=33 Loaded /boot/kernel/if_my.ko, id=35 Loaded /boot/kernel/if_ndis.ko, id=36 Loaded /boot/kernel/if_nve.ko, id=38 Loaded /boot/kernel/if_nxge.ko, id=39 Loaded /boot/kernel/if_run.ko, id=41 Loaded /boot/kernel/if_stf.ko, id=42 Loaded /boot/kernel/if_tap.ko, id=43 Loaded /boot/kernel/if_urtw.ko, id=44 Loaded /boot/kernel/if_vte.ko, id=45 Loaded /boot/kernel/if_wpi.ko, id=46 kldstat after run kldload: Id Refs Address Size Name 1 151 0xffffffff80100000 e58280 kernel 2 1 0xffffffff81012000 585a if_bridge.ko 3 1 0xffffffff81018000 3534 bridgestp.ko 4 1 0xffffffff8101c000 151d3 if_bwi.ko 5 1 0xffffffff81032000 298a5 if_bwn.ko 6 1 0xffffffff8105c000 61dc siba_bwn.ko 7 1 0xffffffff81063000 4d1a if_carp.ko 8 1 0xffffffff81068000 6fbb if_cas.ko 9 1 0xffffffff8106f000 2688f if_cxgb.ko 10 1 0xffffffff81096000 21f92 if_cxgbe.ko 11 1 0xffffffff810b8000 4e9 if_disc.ko 12 1 0xffffffff810b9000 56f if_edsc.ko 13 1 0xffffffff810ba000 a09 if_ef.ko 15 1 0xffffffff810bb000 17ae if_epair.ko 17 1 0xffffffff810bd000 5bdd if_gem.ko 18 1 0xffffffff810c3000 1d13 if_gre.ko 19 1 0xffffffff810c5000 4240 if_hme.ko 20 1 0xffffffff810ca000 c1a if_ic.ko 21 1 0xffffffff810cb000 12ff iicbus.ko 22 1 0xffffffff810cd000 10d8 if_ipheth.ko 23 1 0xffffffff810cf000 7104 if_ipw.ko 24 1 0xffffffff810d7000 93f5 if_iwi.ko 25 1 0xffffffff810e1000 10fef if_iwn.ko 26 1 0xffffffff810f2000 6ba7 if_ixgb.ko 27 1 0xffffffff810f9000 51d4 if_lagg.ko 28 1 0xffffffff810ff000 a73d if_lmc.ko 29 1 0xffffffff8110a000 c3a7 sppp.ko 30 1 0xffffffff81117000 8d32 netgraph.ko 31 1 0xffffffff81120000 7192 if_malo.ko 32 1 0xffffffff81128000 ee81 if_mwl.ko 33 1 0xffffffff81137000 b087 if_mxge.ko 34 1 0xffffffff81143000 a4d9 zlib.ko 35 1 0xffffffff8114e000 3a53 if_my.ko 36 1 0xffffffff81152000 7e13 if_ndis.ko 37 1 0xffffffff8115a000 143e2 ndis.ko 38 1 0xffffffff8116f000 b456 if_nve.ko 39 1 0xffffffff8117b000 23cd3 if_nxge.ko 41 1 0xffffffff8119f000 ba50 if_run.ko 42 1 0xffffffff811ab000 1305 if_stf.ko 43 1 0xffffffff811ad000 2655 if_tap.ko 44 1 0xffffffff811b0000 892c if_urtw.ko 45 1 0xffffffff811b9000 47fb if_vte.ko 46 1 0xffffffff811be000 8c55 if_wpi.ko Cordially Quentin SCHWERKOLT From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 16:26:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0988106564A for ; Fri, 23 Mar 2012 16:26:33 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id BF5F48FC0A for ; Fri, 23 Mar 2012 16:26:33 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta11.emeryville.ca.mail.comcast.net with comcast id p2C71i0011bwxycAB4SZoL; Fri, 23 Mar 2012 16:26:33 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id p4SY1i0024NgCEG8e4SYPc; Fri, 23 Mar 2012 16:26:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q2NGQUKX033853; Fri, 23 Mar 2012 10:26:30 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Quentin Schwerkolt In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Mar 2012 10:26:30 -0600 Message-ID: <1332519990.8403.93.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE 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, 23 Mar 2012 16:26:34 -0000 On Fri, 2012-03-23 at 12:19 +0100, Quentin Schwerkolt wrote: > Hi, > > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". > > kldstat just after system start: > Id Refs Address Size Name > 1 1 0xffffffff80100000 e58280 kernel > > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error > kldload: can't load /boot/kernel/if_bce.ko: File exists > kldload: can't load /boot/kernel/if_bfe.ko: File exists > kldload: can't load /boot/kernel/if_bge.ko: File exists > kldload: can't load /boot/kernel/if_cdce.ko: Exec format error > kldload: can't load /boot/kernel/if_cue.ko: Exec format error > kldload: can't load /boot/kernel/if_dc.ko: File exists > kldload: can't load /boot/kernel/if_de.ko: File exists > kldload: can't load /boot/kernel/if_ed.ko: File exists > kldload: can't load /boot/kernel/if_em.ko: File exists > kldload: can't load /boot/kernel/if_en.ko: Exec format error > kldload: can't load /boot/kernel/if_et.ko: File exists > kldload: can't load /boot/kernel/if_faith.ko: Exec format error > kldload: can't load /boot/kernel/if_fatm.ko: Exec format error > kldload: can't load /boot/kernel/if_fwe.ko: Exec format error > kldload: can't load /boot/kernel/if_fwip.ko: Exec format error > kldload: can't load /boot/kernel/if_fxp.ko: File exists > kldload: can't load /boot/kernel/if_gif.ko: Exec format error > kldload: can't load /boot/kernel/if_hatm.ko: Exec format error > kldload: can't load /boot/kernel/if_igb.ko: File exists > kldload: can't load /boot/kernel/if_jme.ko: File exists > kldload: can't load /boot/kernel/if_kue.ko: Exec format error > kldload: can't load /boot/kernel/if_le.ko: File exists > kldload: can't load /boot/kernel/if_lge.ko: File exists > kldload: can't load /boot/kernel/if_msk.ko: File exists > kldload: can't load /boot/kernel/if_nfe.ko: File exists > kldload: can't load /boot/kernel/if_nge.ko: File exists > kldload: can't load /boot/kernel/if_patm.ko: Exec format error > kldload: can't load /boot/kernel/if_pcn.ko: File exists > kldload: can't load /boot/kernel/if_ral.ko: File exists > kldload: can't load /boot/kernel/if_re.ko: File exists > kldload: can't load /boot/kernel/if_rl.ko: File exists > kldload: can't load /boot/kernel/if_rue.ko: Exec format error > kldload: can't load /boot/kernel/if_rum.ko: Exec format error > kldload: can't load /boot/kernel/if_sf.ko: File exists > kldload: can't load /boot/kernel/if_sge.ko: File exists > kldload: can't load /boot/kernel/if_sis.ko: File exists > kldload: can't load /boot/kernel/if_sk.ko: File exists > kldload: can't load /boot/kernel/if_sn.ko: File exists > kldload: can't load /boot/kernel/if_ste.ko: File exists > kldload: can't load /boot/kernel/if_stge.ko: File exists > kldload: can't load /boot/kernel/if_ti.ko: File exists > kldload: can't load /boot/kernel/if_tl.ko: File exists > kldload: can't load /boot/kernel/if_tun.ko: File exists > kldload: can't load /boot/kernel/if_tx.ko: File exists > kldload: can't load /boot/kernel/if_txp.ko: File exists > kldload: can't load /boot/kernel/if_uath.ko: Exec format error > kldload: can't load /boot/kernel/if_udav.ko: Exec format error > kldload: can't load /boot/kernel/if_upgt.ko: Exec format error > kldload: can't load /boot/kernel/if_ural.ko: Exec format error > kldload: can't load /boot/kernel/if_vge.ko: File exists > kldload: can't load /boot/kernel/if_vlan.ko: Exec format error > kldload: can't load /boot/kernel/if_vr.ko: File exists > kldload: can't load /boot/kernel/if_vx.ko: File exists > kldload: can't load /boot/kernel/if_wb.ko: File exists > kldload: can't load /boot/kernel/if_wi.ko: File exists > kldload: can't load /boot/kernel/if_xl.ko: File exists > kldload: can't load /boot/kernel/if_zyd.ko: Exec format error > Loaded /boot/kernel/if_bridge.ko, id=2 > Loaded /boot/kernel/if_bwi.ko, id=4 > Loaded /boot/kernel/if_bwn.ko, id=5 > Loaded /boot/kernel/if_carp.ko, id=7 > Loaded /boot/kernel/if_cas.ko, id=8 > Loaded /boot/kernel/if_cxgb.ko, id=9 > Loaded /boot/kernel/if_cxgbe.ko, id=10 > Loaded /boot/kernel/if_disc.ko, id=11 > Loaded /boot/kernel/if_edsc.ko, id=12 > Loaded /boot/kernel/if_ef.ko, id=13 > Loaded /boot/kernel/if_epair.ko, id=15 > Loaded /boot/kernel/if_gem.ko, id=17 > Loaded /boot/kernel/if_gre.ko, id=18 > Loaded /boot/kernel/if_hme.ko, id=19 > Loaded /boot/kernel/if_ic.ko, id=20 > Loaded /boot/kernel/if_ipheth.ko, id=22 > Loaded /boot/kernel/if_ipw.ko, id=23 > Loaded /boot/kernel/if_iwi.ko, id=24 > Loaded /boot/kernel/if_iwn.ko, id=25 > Loaded /boot/kernel/if_ixgb.ko, id=26 > Loaded /boot/kernel/if_lagg.ko, id=27 > Loaded /boot/kernel/if_lmc.ko, id=28 > Loaded /boot/kernel/if_malo.ko, id=31 > Loaded /boot/kernel/if_mwl.ko, id=32 > Loaded /boot/kernel/if_mxge.ko, id=33 > Loaded /boot/kernel/if_my.ko, id=35 > Loaded /boot/kernel/if_ndis.ko, id=36 > Loaded /boot/kernel/if_nve.ko, id=38 > Loaded /boot/kernel/if_nxge.ko, id=39 > Loaded /boot/kernel/if_run.ko, id=41 > Loaded /boot/kernel/if_stf.ko, id=42 > Loaded /boot/kernel/if_tap.ko, id=43 > Loaded /boot/kernel/if_urtw.ko, id=44 > Loaded /boot/kernel/if_vte.ko, id=45 > Loaded /boot/kernel/if_wpi.ko, id=46 > > kldstat after run kldload: > Id Refs Address Size Name > 1 151 0xffffffff80100000 e58280 kernel > 2 1 0xffffffff81012000 585a if_bridge.ko > 3 1 0xffffffff81018000 3534 bridgestp.ko > 4 1 0xffffffff8101c000 151d3 if_bwi.ko > 5 1 0xffffffff81032000 298a5 if_bwn.ko > 6 1 0xffffffff8105c000 61dc siba_bwn.ko > 7 1 0xffffffff81063000 4d1a if_carp.ko > 8 1 0xffffffff81068000 6fbb if_cas.ko > 9 1 0xffffffff8106f000 2688f if_cxgb.ko > 10 1 0xffffffff81096000 21f92 if_cxgbe.ko > 11 1 0xffffffff810b8000 4e9 if_disc.ko > 12 1 0xffffffff810b9000 56f if_edsc.ko > 13 1 0xffffffff810ba000 a09 if_ef.ko > 15 1 0xffffffff810bb000 17ae if_epair.ko > 17 1 0xffffffff810bd000 5bdd if_gem.ko > 18 1 0xffffffff810c3000 1d13 if_gre.ko > 19 1 0xffffffff810c5000 4240 if_hme.ko > 20 1 0xffffffff810ca000 c1a if_ic.ko > 21 1 0xffffffff810cb000 12ff iicbus.ko > 22 1 0xffffffff810cd000 10d8 if_ipheth.ko > 23 1 0xffffffff810cf000 7104 if_ipw.ko > 24 1 0xffffffff810d7000 93f5 if_iwi.ko > 25 1 0xffffffff810e1000 10fef if_iwn.ko > 26 1 0xffffffff810f2000 6ba7 if_ixgb.ko > 27 1 0xffffffff810f9000 51d4 if_lagg.ko > 28 1 0xffffffff810ff000 a73d if_lmc.ko > 29 1 0xffffffff8110a000 c3a7 sppp.ko > 30 1 0xffffffff81117000 8d32 netgraph.ko > 31 1 0xffffffff81120000 7192 if_malo.ko > 32 1 0xffffffff81128000 ee81 if_mwl.ko > 33 1 0xffffffff81137000 b087 if_mxge.ko > 34 1 0xffffffff81143000 a4d9 zlib.ko > 35 1 0xffffffff8114e000 3a53 if_my.ko > 36 1 0xffffffff81152000 7e13 if_ndis.ko > 37 1 0xffffffff8115a000 143e2 ndis.ko > 38 1 0xffffffff8116f000 b456 if_nve.ko > 39 1 0xffffffff8117b000 23cd3 if_nxge.ko > 41 1 0xffffffff8119f000 ba50 if_run.ko > 42 1 0xffffffff811ab000 1305 if_stf.ko > 43 1 0xffffffff811ad000 2655 if_tap.ko > 44 1 0xffffffff811b0000 892c if_urtw.ko > 45 1 0xffffffff811b9000 47fb if_vte.ko > 46 1 0xffffffff811be000 8c55 if_wpi.ko > > Cordially > > Quentin SCHWERKOLT If you use "kldstat -v" before the kldload commands, you'll probably find that all the modules that fail to load are already compiled into the kernel. kldstat shows compiled-in modules only if you add -v. -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 16:29:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41941106566B; Fri, 23 Mar 2012 16:29:02 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A12928FC0A; Fri, 23 Mar 2012 16:29:01 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2270082wgb.31 for ; Fri, 23 Mar 2012 09:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x0e6CvwVLqtY+Ezaim2bhavbf2NvjRbm8Owz/yy1sw0=; b=W2faE6Qh1KHwaN1699FQLBYhEyUbI8XRxIxsfT/4Yjbd4hZTv8f6DZnnb+wLYPZzg4 N9jUhu6dgQN2M3fFB4c6ydZYZvBOQxCC0lmqn7oUhHLb89J1P3f9Jy3DKdG6Dkj7rgHU 6foxrdjs6zNrGwx4unO4RAfkNSSUc6CwTFWSMJwMCzsKUBJ+gF8TLxWIGuT5Wu2aqh1Q bP5/ugPFTbCYGwDAqImht+B349kRnIwd4VnFbrjGnLa7D/mKlR8KQL8p9RIXqja3sB/3 Rt1DA/oGjm+xS3+R/rRi8wbCuEdGVQsAGPMGBgZSm3X741/rQAFAf0ZBw8TCVOSC2UsL 2l6Q== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr7864718wib.20.1332520134548; Fri, 23 Mar 2012 09:28:54 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Fri, 23 Mar 2012 09:28:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 09:28:54 -0700 Message-ID: From: Kevin Oberman To: Quentin Schwerkolt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE 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, 23 Mar 2012 16:29:02 -0000 On Fri, Mar 23, 2012 at 4:19 AM, Quentin Schwerkolt wrote: > Hi, > > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386= . > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". > > kldstat just after system start: > Id Refs Address =A0 =A0 =A0 =A0 =A0 =A0Size =A0 =A0 Name > =A01 =A0 =A01 0xffffffff80100000 e58280 =A0 kernel > > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error GENERIC already has all of these drivers. Did you buidt a kernel with no network interfaces? If the kernel is built with the drivers, you can't load them as they already exist. (And you can't unload drivers built into the kernel, either.) --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 18:50:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7475106564A for ; Fri, 23 Mar 2012 18:50:14 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8F48FC1B for ; Fri, 23 Mar 2012 18:50:13 +0000 (UTC) Received: by lboi15 with SMTP id i15so3591437lbo.13 for ; Fri, 23 Mar 2012 11:50:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Rw7oZG5bVXNppdee9Vu8JmxCpOzuc6HnDsrw0F9tOxg=; b=TqMiCwlzB7HhDZ1YfqUWXaVGztAF6XmjNgwb3zKpnOqmJVHh8QWrt1CVDR/DVszXka aMMUmN1Uu3VfGYkiWdbJlbuVsfyH0vrK4aXA0+w5FpPi+S3Pm8i9FUyVG4GbpYaz6xjK 06iunXZ8GanTTCFAHphdq8S09WanuBloRp9ggQc/ncD9NCQn2xumyh0T++NDOc9ijwV2 ZUhyuud66pd0bRYenV3c1lMiBEc5bQ2aNKpRbEnwSdnEvqFjluZqucAw6moIoXze3oW5 otOLr/Y1O6VaYd7PSevRJJ6vLf/TcK0Rv3aSRmBZZEh/TRk14hm+ZINSXupwzMLfyhcf iISQ== MIME-Version: 1.0 Received: by 10.112.23.38 with SMTP id j6mr4976849lbf.15.1332528612809; Fri, 23 Mar 2012 11:50:12 -0700 (PDT) Received: by 10.112.36.135 with HTTP; Fri, 23 Mar 2012 11:50:12 -0700 (PDT) X-Originating-IP: [216.223.13.128] Date: Fri, 23 Mar 2012 14:50:12 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlFXFsbYQzGY3jN4xAA+1x5mwMsl13fU9CRBy26ajTdeOIb7nZpIrMkVKNfyuZAPwJKNHVV Subject: FreeBSD 9-STABLE can not mount root from a glabled device 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, 23 Mar 2012 18:50:14 -0000 All I upgraded two of my 7-STABLE servers to 9-STABLE today and found two foot shooters. I believe they are bugs only when you upgrade from pre 8.0-RELEASE to 9.0-RELEASE or 9-STABLE 1. On 7.x I had been using glabel to label my root filesystem slice, swap slice , and var slice . Like this glabel label rootfs /dev/da0s1a glabel label var /dev/da0s1d glabel label SWAP /dev/da0s1b Then in fstab I would have entries like this. # Device Mountpoint FStype Options Dump Pass# /dev/label/rootfs / ufs rw 1 1 /dev/label/var /var ufs rw 2 2 /dev/label/SWAP none swap sw 0 0 This has worked for me in 6.x and 7.x however upon upgrading to 9-STABLE ( from yesterday ) or 9.0-RELEASE the boot loader could not find the labeled device. I had to manually set vfs.root.mountfrom=ufs:/dev/da0s1a" or key that in when the boot process bombed out. 2. After fixing the fstabs to use the real da names I wanted to see what the boot loader would do with ufs labels. I rebooted my box into single user mode and ran this tunefs -L rootfs /dev/da0s1a tunefs -L var /dev/da0s1d Then edited the fstab to use the labeled filesystems and rebooted, much to my surprise it failed in the same way. I compared this to a new 9.0-STABLE install i did which used gpt labels that did would # Device Mountpoint FStype Options Dump Pass# /dev/label/SWAP none swap sw 0 0 /dev/gpt/rootfs / ufs rw 1 1 /dev/gpt/var /var ufs rw 2 2 /dev/gpt/data /data ufs rw 2 2 So far as I can tell the only difference is that the fresh install uses the GPT partitioning scheme where as the upgraded boxes us the older mbr/fdisk setup. Any ideas on what I can try to get past this ? I liked using /dev/label as it made the devices sort of agnostic to what filesystem or partitioning scheme was on them. -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 20:46:47 2012 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 20BA51065673 for ; Fri, 23 Mar 2012 20:46:47 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id E78CC8FC27 for ; Fri, 23 Mar 2012 20:46:46 +0000 (UTC) Received: by dadz14 with SMTP id z14so84862dad.17 for ; Fri, 23 Mar 2012 13:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AnTrnFDvPlmFtboa1IMsDeHSTgsU0O4MrwM6N40bSts=; b=LH76QuSrPX8F0VHO8Eo7UicziqKAb4O2+CC9TOd1gqxFhqLMXSedprkkFA+KXQvY1L kL31bNG7ybX8bG+O8nfLBe5Ip8jQtO4x6RFlHxuRo2kx5DrzRE4cexmGRQtLtYG/UhO+ 3J4VPBNeN+OXX/thYglFKDxrEJSOwir+r5FdG+UnfgcLKBtYWZ1xGvy7miGyu0+ORVmS /l5R5d30YknMH71xWe5KuZ2PdIv+LOm3yDyi42YMfX/DKb+c9MDtIoAH0I2DBZEcG8ni ip/dktPGCn7au3/UnIVFA5u9ZNkrc+JoGtmJqsri4a8nLG/IuOG3vDQ+yivSEq5nIBVi N29w== MIME-Version: 1.0 Received: by 10.68.72.138 with SMTP id d10mr32748937pbv.15.1332535599968; Fri, 23 Mar 2012 13:46:39 -0700 (PDT) Received: by 10.142.116.2 with HTTP; Fri, 23 Mar 2012 13:46:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 16:46:39 -0400 Message-ID: From: "illoai@gmail.com" To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9-STABLE can not mount root from a glabled device 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, 23 Mar 2012 20:46:47 -0000 On 23 March 2012 14:50, Mark Saad wrote: > All > =A0I upgraded two of my 7-STABLE servers to 9-STABLE today and found > two foot shooters. I believe they are bugs only when you upgrade from > pre 8.0-RELEASE to 9.0-RELEASE or 9-STABLE > > 1. On 7.x I had been using glabel to label my root filesystem slice, > swap slice , and var slice . Like this > > glabel label rootfs /dev/da0s1a > glabel label var /dev/da0s1d > glabel label SWAP /dev/da0s1b > > Then in fstab I would have entries like this. > # Device =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountpoint =A0 =A0 =A0FStype =A0O= ptions =A0 =A0 =A0 =A0 Dump =A0 =A0Pass# > /dev/label/rootfs =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs =A0 =A0 r= w =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 > /dev/label/var =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0= rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > /dev/label/SWAP =A0 =A0 =A0 =A0 none =A0 =A0 =A0 =A0 =A0 =A0swap =A0 =A0s= w =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 > > This has worked for me in 6.x and 7.x however upon upgrading to > 9-STABLE ( from yesterday ) or 9.0-RELEASE the boot loader could not > find the labeled device. > I had to manually set vfs.root.mountfrom=3Dufs:/dev/da0s1a" or key that > in when the boot process bombed out. > > 2. After fixing the fstabs to use the real da names I wanted to see > what the boot loader would do with ufs labels. I rebooted my box into > single user mode and ran this > > tunefs -L rootfs /dev/da0s1a > tunefs -L var /dev/da0s1d > > Then edited the fstab to use the labeled filesystems and rebooted, > much to my surprise it failed in the same way. > > I compared this to a new 9.0-STABLE install i =A0did which used gpt > labels that did would > > # Device =A0 =A0 =A0 =A0Mountpoint =A0 =A0 =A0FStype =A0Options Dump =A0 = =A0Pass# > /dev/label/SWAP none =A0 =A0 =A0 =A0 =A0 =A0swap =A0 =A0sw =A0 =A0 =A00 = =A0 =A0 =A0 0 > /dev/gpt/rootfs / =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs =A0 =A0 rw =A0 =A0 =A01= =A0 =A0 =A0 1 > /dev/gpt/var =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0 rw =A0 =A0 = =A02 =A0 =A0 =A0 2 > /dev/gpt/data =A0 /data =A0 =A0 =A0 =A0 =A0 ufs =A0 =A0 rw =A0 =A0 =A02 = =A0 =A0 =A0 2 > > > So far as I can tell the only difference is that the fresh install > uses the GPT partitioning scheme where as the upgraded boxes us the > older mbr/fdisk setup. > > Any ideas on what I can try to get past this ? I liked using > /dev/label as it made the devices sort of agnostic to what filesystem > or partitioning scheme was on them. > tunefs should put your labels under /dev/ufs/ Though I've not had any problems under 9.0 with labels on root. Is GEOM_LABEL built into your kernel or is it a module? (though I have my doubts about that causing this problem) The boot loader should merely grab the first 512K of whatever partition is marked as bootable without worrying where / might eventually be mounted from. /dev/label/swap0 none swap sw 0 0 /dev/ufs/rootfs / ufs rw,noatime 1 1 /dev/ufs/homefs /home ufs rw,noatime 2 3 /dev/ufs/usrfs /usr ufs rw,noatime 2 2 /dev/ufs/varfs /var ufs rw,noatime,async 2 2 tmpfs /tmp tmpfs rw 0 0 &cet --=20 -- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 12:04:08 2012 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 6EE01106566B for ; Sat, 24 Mar 2012 12:04:08 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from www.lexa.ru (www.lexa.ru [213.59.0.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2225C8FC1F for ; Sat, 24 Mar 2012 12:04:07 +0000 (UTC) Received: by www.lexa.ru (Postfix, from userid 66) id 8763C114AB; Sat, 24 Mar 2012 15:56:06 +0400 (MSK) Received: from [127.0.0.1] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id EB97161F9A; Sat, 24 Mar 2012 15:52:11 +0400 (MSK) Message-ID: <4F6DB568.1060604@lexa.ru> Date: Sat, 24 Mar 2012 15:52:08 +0400 From: Alex Tutubalin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 9-STABLE + Infiniband - incorrect interface counters 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, 24 Mar 2012 12:04:08 -0000 Hi, I'm playing with two FreeBSD 9-STABLE boxes connected via 10Gbps Infiniband (more details below) in Infiniband connected mode. I see incorrect interface statistics (e.g. in netstat output), output counters are 2x more than expected. EXAMPLE, ftp transfer of 1 GiB file: ftp> put file /dev/null local: file remote: /dev/null 229 Entering Extended Passive Mode (|||57978|) 150 Opening BINARY mode data connection for '/dev/null'. 100% |***********************************| 953 MiB 390.43 MiB/s 00:00 ETA 226 Transfer complete. 1000000000 bytes sent in 00:02 (390.13 MiB/s) Netstat on receiving side, counters are correct (for input): lexa@home-gw:/home/lexa# netstat -I ib1 5 input (ib1) output packets errs idrops bytes packets errs bytes colls 0 0 0 0 0 0 0 0 13955 0 0 222688126 9027 0 1192796 0 48921 0 0 780832960 32129 0 4240596 0 0 0 0 0 0 0 80 0 Sum of bytes (input) is 1003521086, as expected. Netstat on sending size, output is 2x more: lexa@new-gw:/home/lexa# netstat -I ib0 5 input (ib0) output packets errs idrops bytes packets errs bytes colls 1 0 0 100 0 0 0 0 41162 0 0 2305210 62878 0 2008325984 0 1 0 0 100 0 0 0 0 It looks like packet count is correct (13955+48921=62876, two packets missed somewhere), while byte count is exact 2x more. ==== More details on my setup ==== FreeBSD 9-STABLE, cvsuped today. One box is Core 2 Quad (Q9300), second one Core i7-920 1) Device MELLANOX MHEA28-XTC 10GBPS INFINIBAND HCA CARD (two port) Boot message: ib_mthca0: mem 0xfe900000-0xfe9fffff,0xfd000000-0xfd7fffff irq 16 at device 0.0 on pci1 ib_mthca: Mellanox InfiniBand HCA driver v1.0-ofed1.5.2 (August 4, 2010) Two cards connected via cable, no Infiniband switch 2) Kernel config: include GENERIC options OFED options SDP device ipoib options IPOIB_CM device mthca 3) Regardles of MTU settings (tried 16000, 32000, 48000), actual packed size in tcp flow is about 16000. Have not investigated it in details 4) There is no packet loss: lexa@new-gw:/home/lexa# ping -s 32000 -c 10000 -f 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 32000 data bytes . --- 10.1.1.1 ping statistics --- 10000 packets transmitted, 10000 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.157/0.225/1.758/0.156 ms -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 16:32:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9FDF106566C for ; Sat, 24 Mar 2012 16:32:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A27CC8FC1B for ; Sat, 24 Mar 2012 16:32:53 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C545.dip.t-dialin.net [87.150.197.69]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 52A498443EA; Sat, 24 Mar 2012 17:32:33 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 8AB59271B; Sat, 24 Mar 2012 17:32:30 +0100 (CET) Date: Sat, 24 Mar 2012 17:32:30 +0100 From: Alexander Leidinger To: Jeremy Chadwick Message-ID: <20120324173230.000045f9@unknown> In-Reply-To: <20120323110847.GA12111@icarus.home.lan> References: <20120323110847.GA12111@icarus.home.lan> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 52A498443EA.AFE48 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.976, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.03, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1333211554.34532@uL57Vps5zyNSMaOooZYahQ X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: Debugging periodic scripts 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, 24 Mar 2012 16:32:54 -0000 On Fri, 23 Mar 2012 04:08:47 -0700 Jeremy Chadwick wrote: > Editing /etc/periodic/security/510.ipfdenied's hashbang line to use -x > doesn't change the behaviour either (maybe stderr gets sent to > /dev/null?), whether I run it by hand as a script or via "periodic > security". Use "set -x" instead of modifying the first line (I assume the script is already started with the correct shell, so the first line is ignored). I would also add "env" before and after the sourcing of the periodic.conf to see what is defined or not. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 17:26:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 094C9106564A for ; Sat, 24 Mar 2012 17:26:12 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id AF6E78FC14 for ; Sat, 24 Mar 2012 17:26:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan02.get.basefarm.net ([10.5.16.4]) by get-mta-out03.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0M1E007N9DNFCT90@get-mta-out03.get.basefarm.net> for freebsd-stable@freebsd.org; Sat, 24 Mar 2012 17:26:03 +0100 (MET) Received: from get-mta-scan02.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CC5C31EA55E5_F6DF59BB for ; Sat, 24 Mar 2012 16:26:03 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan02.get.basefarm.net (Sophos Email Appliance) with ESMTP id A43EC1EA3F7A_F6DF59BF for ; Sat, 24 Mar 2012 16:26:03 +0000 (GMT) Date: Sat, 24 Mar 2012 17:26:03 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Subject: FreeBSD 9.0 - GPT boot problems? 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, 24 Mar 2012 17:26:12 -0000 Hi, I just installed FreeBSD 9.0-release / amd64 on a new machine (Acer Aspire X1470). I installed from a usb memory stick (the default amd64 image), which I booted by pressing "F12" and selecting it from the boot menu on the machine. I installed on a SSD (which replaced the hard drive originally in the machine), using the default scheme for 9.0 (GPT). The installation was painless (many thanks to all who made it that way), but when I try to boot the machine from the SSD afterwards, I just get this message from the BIOS: "ERROR: No boot disk has been detected or the disk has failed." I tried selecting the SSD from the boot menu (via F12) instead (it shows up as "EFI: M4-CT128M4SSD2"), but got the same message. I upgraded the BIOS from version P01-A3 to version P01-A4 (the newest available), still no dice. If I use the usb stick I installed from, I can select the boot device, and actually boot from it, so there doesn't seem to be anything wrong with the SSD. I tried: kg-vm2# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 bootcode written to ada0 in case there was something wrong with the bootcode, but I still get the message "ERROR: No boot disk has been detected or the disk has failed." gpart shows this: root@kg-vm2# gpart show ada0 => 34 250069613 ada0 GPT (119G) 34 128 1 freebsd-boot (64k) 162 119537664 2 freebsd-ufs (57G) 119537826 8388608 3 freebsd-swap (4.0G) 127926434 121634816 4 freebsd-ufs (58G) 249561250 508397 - free - (248M) and root is on ada0p2, with swap on ada0p3: root@kg-vm2# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ada0p2 56G 2.3G 49G 4% / devfs 1.0k 1.0k 0B 100% /dev root@kg-vm2# swapinfo -h Device 1K-blocks Used Avail Capacity /dev/ada0p3 4194304 0B 4.0G 0% Has anyone seen anything like this before? Any hints on what I can do? References: 1) http://sites.google.com/site/tingox/aspire_x1470_fbsd -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 17:47:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E5071065670; Sat, 24 Mar 2012 17:47:55 +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 CACD98FC16; Sat, 24 Mar 2012 17:47:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q2OHlLSU049001; Sun, 25 Mar 2012 04:47:21 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 25 Mar 2012 04:47:21 +1100 (EST) From: Ian Smith To: Quentin Schwerkolt In-Reply-To: Message-ID: <20120325042722.S2060@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE 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, 24 Mar 2012 17:47:55 -0000 On Fri, 23 Mar 2012, Quentin Schwerkolt wrote: > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". I have no idea why you'd want to do that :) but you'll find that all the 'File exist' ones were already included in your kernel. > kldstat just after system start: > Id Refs Address Size Name > 1 1 0xffffffff80100000 e58280 kernel 'kldstat -v' will show all modules included in your (GENERIC?) kernel. > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error I'm not certain about the 'Exec format error' messages. Then below are listed the modules loaded that weren't in your kernel. > Loaded /boot/kernel/if_bridge.ko, id=2 > Loaded /boot/kernel/if_bwi.ko, id=4 [..] > Loaded /boot/kernel/if_vte.ko, id=45 > Loaded /boot/kernel/if_wpi.ko, id=46 > > kldstat after run kldload: > Id Refs Address Size Name > 1 151 0xffffffff80100000 e58280 kernel > 2 1 0xffffffff81012000 585a if_bridge.ko > 3 1 0xffffffff81018000 3534 bridgestp.ko > 4 1 0xffffffff8101c000 151d3 if_bwi.ko [..] Now showing all modules that were loaded in addition to those in kernel. Again, 'kldstat -v' will show all of them, with details of loaded ones. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 17:50:15 2012 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 674B31065686 for ; Sat, 24 Mar 2012 17:50:15 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id B393C8FC2A for ; Sat, 24 Mar 2012 17:50:14 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 9E1605C5F for ; Sat, 24 Mar 2012 18:50:13 +0100 (CET) Message-ID: <4F6E0955.8040807@borderworlds.dk> Date: Sat, 24 Mar 2012 18:50:13 +0100 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> In-Reply-To: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 9.0 - GPT boot problems? 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, 24 Mar 2012 17:50:15 -0000 On 03/24/12 17:26, Torfinn Ingolfsen wrote: > Hi, > I just installed FreeBSD 9.0-release / amd64 on a new machine (Acer Aspire X1470). > I installed from a usb memory stick (the default amd64 image), which I booted by pressing "F12" and selecting it from the boot menu on the machine. > I installed on a SSD (which replaced the hard drive originally in the machine), using the default scheme for 9.0 (GPT). > The installation was painless (many thanks to all who made it that way), but when I try to boot the machine from the SSD afterwards, I just get this message from the BIOS: > "ERROR: No boot disk has been detected or the disk has failed." > I tried selecting the SSD from the boot menu (via F12) instead (it shows up as "EFI: M4-CT128M4SSD2"), but got the same message. > I upgraded the BIOS from version P01-A3 to version P01-A4 (the newest available), still no dice. It sounds a bit like the BIOS thinks that since the disk uses GPT you want to EFI boot. As far as I know the default bootcode in the PMBR is meant for old style BIOS booting. Is it possible to disable EFI in your BIOS? If that is the case, that's probably the easiest solution. I'm unsure of the current state of EFI boot in FreeBSD but a little bit of searching did not look promising. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Sat Mar 24 19:04:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EF5B106566B for ; Sat, 24 Mar 2012 19:04:33 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id F27928FC19 for ; Sat, 24 Mar 2012 19:04:32 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan02.get.basefarm.net ([10.5.16.4]) by get-mta-out03.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0M1E00D7MKZK2K50@get-mta-out03.get.basefarm.net> for freebsd-stable@freebsd.org; Sat, 24 Mar 2012 20:04:32 +0100 (MET) Received: from get-mta-scan02.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 005EB1EA55C6_F6E1AC0B for ; Sat, 24 Mar 2012 19:04:32 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan02.get.basefarm.net (Sophos Email Appliance) with ESMTP id B33E61EA3FF7_F6E1ABFF for ; Sat, 24 Mar 2012 19:04:31 +0000 (GMT) Date: Sat, 24 Mar 2012 20:04:31 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120324200431.0f7de58f.torfinn.ingolfsen@getmail.no> In-reply-to: <4F6E0955.8040807@borderworlds.dk> References: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> <4F6E0955.8040807@borderworlds.dk> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Subject: Re: FreeBSD 9.0 - GPT boot problems? 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, 24 Mar 2012 19:04:33 -0000 On Sat, 24 Mar 2012 18:50:13 +0100 Christian Laursen wrote: > It sounds a bit like the BIOS thinks that since the disk uses GPT you > want to EFI boot. That could very well be the case. > As far as I know the default bootcode in the PMBR is > meant for old style BIOS booting. Hmm, I was hoping that the pmbr / gptboot would work "both ways". > Is it possible to disable EFI in your BIOS? If that is the case, that's > probably the easiest solution. No, I haven't found any place to do that. Before I installed FreeBSD on this SSD (before it was partitioned with gpart) it showed up in the BIOS under "hard drive". (Other choices are "removable drive" Now it shows up under "EFI device", and doesn't show up under "hard drive". > I'm unsure of the current state of EFI boot in FreeBSD but a little bit > of searching did not look promising. Yes, after a bit of searching I agree with you. If anyone knows of a EFI capable boot loader for FreeBSD, I'm willing to try it. Rather that, than having to deal with grub, elilo or the other stuff. -- Torfinn Ingolfsen