From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 06:03:37 2008 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 65729106568B; Sun, 28 Sep 2008 06:03:37 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 250EA8FC17; Sun, 28 Sep 2008 06:03:36 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 8A87A2218B9E; Sun, 28 Sep 2008 15:46:50 +1000 (EST) X-Viruscan-Id: <48DF1A4A00018362C033B1@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 1BCDA21B6463; Sun, 28 Sep 2008 15:46:50 +1000 (EST) Received: from k7.mavetju (ppp121-44-55-162.lns10.syd7.internode.on.net [121.44.55.162]) by mail5auth.barnet.com.au (Postfix) with ESMTP id B0D9F2218AF6; Sun, 28 Sep 2008 15:46:49 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id E889177F; Sun, 28 Sep 2008 15:46:20 +1000 (EST) Date: Sun, 28 Sep 2008 15:46:20 +1000 From: Edwin Groothuis To: current@freebsd.org, stable@freebsd.org Message-ID: <20080928054620.GA80250@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 06:03:37 -0000 I have made an update for the top(1) utility in the FreeBSD base system to get it from the 3.5b12 version to the 3.8b1 version. I have tried them on the amd64 architecture on FreeBSD -current and FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. The big new features are a line upper part with kernel statistics (context-switches, traps, interrupts, faults etc) and the FLG table (if you window is big enough) Some features specific to FreeBSD (dual display (press m)), threaded processes, and jails have been ported to 3.8b1. The biggest fix (AFAICT) is the TIME and CPU table for threaded processes, which are now calculated properly. The new code can be found on http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, then run it via "./top". Please report any issues with it (compile time, run time) and a way to reproduce it (if possible). Thanks for your help! Edwin -- Edwin Groothuis edwin@freebsd.org http://www.mavetju.org From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 08:23:36 2008 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 91D62106568F for ; Sun, 28 Sep 2008 08:23:36 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 21DE68FC21 for ; Sun, 28 Sep 2008 08:23:35 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8S8NWXB020471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2008 18:23:33 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8S8NV5H039936; Sun, 28 Sep 2008 18:23:31 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8S8NVHF039935; Sun, 28 Sep 2008 18:23:31 +1000 (EST) (envelope-from peter) Date: Sun, 28 Sep 2008 18:23:31 +1000 From: Peter Jeremy To: Aristedes Maniatis Message-ID: <20080928082331.GR15376@server.vk2pj.dyndns.org> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> <20080927221807.GE60230@in-addr.com> <51E08B08-167D-4787-BC91-11FB20B6E118@ish.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NqBeRcvybb6C9jMF" Content-Disposition: inline In-Reply-To: <51E08B08-167D-4787-BC91-11FB20B6E118@ish.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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, 28 Sep 2008 08:23:36 -0000 --NqBeRcvybb6C9jMF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-28 08:29:20 +1000, Aristedes Maniatis wrote: >I guess then I should ask the question a different way. How much =20 >memory does each fd use and which pool of memory does it come from? =20 72 bytes for i386, 120 bytes for amd64. It's a UMA zone 'Files'. You can check with 'vmstat -z|grep Files' --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --NqBeRcvybb6C9jMF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjfPwIACgkQ/opHv/APuIdZrwCgmXa6I/lcUkvYWlFtRxI6r5H/ +18AnRqC1WxiV3SLwKA48+UIiHLIAudu =z5wS -----END PGP SIGNATURE----- --NqBeRcvybb6C9jMF-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 08:31:32 2008 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 1D7F41065698; Sun, 28 Sep 2008 08:31:32 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id C57838FC1D; Sun, 28 Sep 2008 08:31:31 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.147.100] (port=64553 helo=acer.lissyara.int.otradno.ru) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KjrQc-000Ebv-KN; Sun, 28 Sep 2008 12:14:54 +0400 Message-ID: <48DF3CFE.7@lissyara.su> Date: Sun, 28 Sep 2008 12:14:54 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080731 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> In-Reply-To: <20080928054620.GA80250@k7.mavetju> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 08:31:32 -0000 Edwin Groothuis пишет: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin > Some strange. Count running processes not match with system top ========= system top ============= last pid: 30285; load averages: 0.99, 0.91, 0.91 up 0+21:08:49 12:10:40 45 processes: 2 running, 43 sleeping CPU: 24.3% user, 0.0% nice, 1.3% system, 0.0% interrupt, 74.4% idle Mem: 236M Active, 1693M Inact, 414M Wired, 137M Cache, 214M Buf, 5187M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 87008 root 1 8 0 58728K 43028K wait 0 0:05 0.00% ruby18 87002 root 1 44 0 5688K 1124K select 2 0:02 0.00% script 1168 root 1 44 0 22872K 4308K select 3 0:01 0.00% sshd 30284 root 1 97 0 97420K 90844K CPU1 1 0:01 0.00% cc1plus 721 root 1 44 0 10696K 4000K select 0 0:01 0.00% sendmail 86980 lissyara 1 44 0 33764K 4840K select 2 0:00 0.00% sshd 584 root 1 44 0 5688K 1364K select 2 0:00 0.00% syslogd 733 root 1 8 0 6744K 1436K nanslp 0 0:00 0.00% cron 52451 lissyara 1 44 0 33764K 4840K select 0 0:00 0.00% sshd ======== new top ========== last pid: 30280; load avg: 0.99, 0.91, 0.91; up 0+21:08:48 12:10:39 99 processes: 6 running, 76 sleeping, 17 waiting CPU: 23.6% user, 0.0% nice, 1.9% system, 0.0% interrupt, 74.5% idle Kernel: 4192 ctxsw, 21398 trap, 4 intr, 1000 soft, 4 fork, 21427 flt, 26140 fr Mem: 239M Active, 1693M Inact, 414M Wired, 137M Cache, 214M Buf, 5184M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE FLG C TIME CPU COMMAND 30279 root 1 98 0 97M 91M CPU1 + 1 0:01 48.94% cc1plus 30280 root 1 -8 0 2176K 1688K piperd + 0 0:00 0.14% as 30277 root 1 8 0 7060K 1884K wait + 1 0:00 0.06% sh 30278 root 1 8 0 4600K 1284K wait + 0 0:00 0.06% c++ 30245 root 1 44 0 8112K 2220K select + 0 0:00 0.04% top 30219 root 1 44 0 8112K 2284K CPU2 + 2 0:00 0.02% top 86980 lissyara 1 44 0 33M 4840K select 2 0:00 0.01% sshd 29472 root 1 8 0 3200K 1392K wait + 3 0:00 0.01% make 87008 root 1 8 0 57M 42M wait + 0 0:05 0.00% ruby18 87002 root 1 44 0 5688K 1124K select + 2 0:02 0.00% script 1168 root 1 44 0 22M 4308K select s 3 0:01 0.00% sshd ====================== FreeBSD serv2.hos-ting.ru 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Sep 27 14:50:59 MSD 2008 lissyara@serv2.hos-ting.ru:/usr/obj/usr/src/sys/HOSTING amd64 From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 09:21:50 2008 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 01E3C1065677; Sun, 28 Sep 2008 09:21:50 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 7C48B8FC27; Sun, 28 Sep 2008 09:21:49 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A401C.dip.t-dialin.net [84.154.64.28]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8S9Ljkm044087; Sun, 28 Sep 2008 11:21:46 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8S9LZIe016720; Sun, 28 Sep 2008 11:21:35 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8S9LJtA030248; Sun, 28 Sep 2008 11:21:24 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809280921.m8S9LJtA030248@fire.js.berklix.net> to: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Fri, 26 Sep 2008 19:54:04 +0200." <200809261754.m8QHs41D011762@fire.js.berklix.net> Date: Sun, 28 Sep 2008 11:21:19 +0200 Sender: jhs@berklix.org Cc: pyunyh@gmail.com, Jeremy Chadwick , Abdullah Ibn Hamad Al-Marri Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 28 Sep 2008 09:21:50 -0000 Hi, Reference: > From: "Julian Stacey" > Date: Fri, 26 Sep 2008 19:54:04 +0200 > Message-id: <200809261754.m8QHs41D011762@fire.js.berklix.net> "Julian Stacey" wrote: > Hi, > Reference: > > From: "Julian Stacey" > > Date: Fri, 26 Sep 2008 19:16:57 +0200 > > Message-id: <200809261717.m8QHGvmx011312@fire.js.berklix.net> > > "Julian Stacey" wrote: > > > > I'm remaking binaries, > > > > New generic kernel built & installed, & install of all src/ done too. > > No improvement. > > > > > Is there reliable way to reproduce the issue? > > > > Its continuous, the machine virtually never does a ping in less > > than 10 seconds. > > > > > Anyway, would you try attached patch and let me know result? > > > > Thanks > > Done, doesnt help. > > Seeing a new message now too: > > ping: sendto: No buffer space available. > > > > Output of vmstat -i and pciconf -lv look the same as before > > > > It's a small card. Weighs 46 gram. I was going to write > > I could simply post it to you, & you could keep it if you > > want. As I had quessed it might be some new kind of card > > unexperienced before, > > RTL8139D, card just says made in China > > > > But I just grabbed another card > > card says Level One. > > chip 8139B > > & with both patched kernel & original no improvement. > > So I tried a totaly different card xl0 fails too, > > I think that 3com xl0 card was OK before in another box, > > so I'd guess not an rl problem, Sorry. > > > > Probably not 7.1 either, but probably a BIOS config problem of some sort. > > > > IRQ 12 was listed in Award BIOS as Primary, options were also secondary or disabled, so Ive set it disabled. > > PNP OS Yes > > Resources: Auto > > "Reset config data" to Enabled (I forgot before after card changes) > > > > Did another restore BIOS factory defaults, no help. > > Moved xl0 to another slot (all other 3 slots never use I guess, as > > chassis plates not torn off on what I guess is original chassis. > > No luck with xl0 > > I'm out of ideas. > > Got it working on xl > interrupt problem, I turned off lpt com2 & something else > in bios. > Got to go out now > Ill go back to rl0 too & report back soon > thanks for help both ! I'm wrong it is Not working. (I typed my own own card address of 192.168.x.x by mistake, not the 192.168.x.x of another host on net. ) Ive fiddled more with BIOS IRQ to no good effect (not suprsing, dont understand some options in BIOS & no MOtherboard manual for this Award BIOS 2A6LGB09, on box: fujitsu siemens t-bird I was wondering if setting anything to polling might help a bit I went looking with syctl -a -d | grep hw.pci hw.pci.do_power_nodriver: 0 hw.pci.do_power_nodriver: Place a function into D3 state when no driver attaches to it. 0 means hw.pci.do_power_resume: 1 hw.pci.do_power_resume: Transition from D3 -> D0 on resume. hw.pci.enable_io_modes: 1 hw.pci.enable_io_modes: Enable I/O and memory bits in the config register. Some BIOSes do not hw.pci.enable_msi: 1 hw.pci.enable_msi: Enable support for MSI interrupts hw.pci.enable_msix: 1 hw.pci.enable_msix: Enable support for MSI-X interrupts hw.pci.honor_msi_blacklist: 1 hw.pci.honor_msi_blacklist: Honor chipset blacklist for MSI hw.pci.host_mem_start: 2147483648 hw.pci.host_mem_start: Limit the host bridge memory to being above this address. Must be hw.pci.irq_override_mask: 57080 hw.pci.irq_override_mask: Mask of allowed irqs to try to route when it has no good clue about hw.pcic.intr_mask: 57016 hw.pcic.intr_mask: Mask of allowable interrupts for this laptop. The default is generally hw.pcic.pd6722_vsense: 1 hw.pcic.pd6722_vsense: Select CL-PD6722's VSENSE method. VSENSE is used to determine the Abdullah wrote: > Do you have poll enabled for rl0 ? I didnt understand question but after "man 4 polling" & eg ifconfig xl0 192.168.100.64 polling I dont see ifconfig -a showing polling Still stuck not working, with BSD showing: xl0 on irq10 BIOS showing irq10 disabled Changed bios irq10 to "Secondary" rebooted. PC Manufacturer has no manual on line (to describe BIOS options) Ideas & comments welcome ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 09:33:59 2008 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 B430C106568F; Sun, 28 Sep 2008 09:33:59 +0000 (UTC) (envelope-from sec@42.org) Received: from ice.42.org (v6.42.org [IPv6:2001:608:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5125D8FC08; Sun, 28 Sep 2008 09:33:59 +0000 (UTC) (envelope-from sec@42.org) Received: by ice.42.org (Postfix, from userid 1000) id 61A4F2292E; Sun, 28 Sep 2008 11:33:57 +0200 (CEST) Date: Sun, 28 Sep 2008 11:33:57 +0200 From: Stefan `Sec` Zehl To: Edwin Groothuis Message-ID: <20080928093357.GA71582@ice.42.org> References: <20080928054620.GA80250@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928054620.GA80250@k7.mavetju> User-Agent: Mutt/1.4.2.3i I-love-doing-this: really X-Modeline: vim:set ts=8 sw=4 smarttab tw=72 si noic notitle: Accept-Languages: de, en X-URL: http://sec.42.org/ Cc: stable@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 09:33:59 -0000 Hi, On Sun, Sep 28, 2008 at 15:46 +1000, Edwin Groothuis wrote: > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". compiles and runs fine on my box: FreeBSD ice 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #17: Wed Sep 3 23:59:58 CEST 2008 root@ice:/usr/obj/usr/src/sys/ICE amd64 > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! The number of sleeping processes is much lower than system top: oldtop: 480 processes: 3 running, 450 sleeping, 2 stopped, 7 zombie, 18 waiting newtop: 190 processes: 3 running, 160 sleeping, 2 stopped, 7 zombie, 18 waiting Interestingly, the system top appears to be the one in error: ice:~>ps auxww|wc -l 194 Other than that, i could see no obvious problems. CU, Sec -- I think the IDE issue is a good point. People with IDE hardware in their machines should be punished by making them wait to boot... -- terry@lambert.org From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 09:35:52 2008 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 CCDEC1065692; Sun, 28 Sep 2008 09:35:52 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service2.sh.cvut.cz (unknown [IPv6:2001:718:2:0:217:a4ff:fe3f:b3d4]) by mx1.freebsd.org (Postfix) with ESMTP id 24FF98FC0A; Sun, 28 Sep 2008 09:35:52 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service2.sh.cvut.cz (Postfix) with ESMTP id 10B0C137A90; Sun, 28 Sep 2008 11:35:50 +0200 (CEST) Received: from service2.sh.cvut.cz ([127.0.0.1]) by localhost (service2.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09229-10; Sun, 28 Sep 2008 11:35:13 +0200 (CEST) Received: from [192.168.1.2] (35.201.broadband4.iol.cz [85.71.201.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service2.sh.cvut.cz (Postfix) with ESMTP id 58D30137919; Sun, 28 Sep 2008 11:35:13 +0200 (CEST) Message-ID: <48DF4FCA.4070403@sh.cvut.cz> Date: Sun, 28 Sep 2008 11:35:06 +0200 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> In-Reply-To: <20080928054620.GA80250@k7.mavetju> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8F5E7068E37DFE4212F9AC0D" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at service2.sh.cvut.cz X-Spam-Status: No, hits=2.4 tagged_above=-255.0 required=5.0 tests=AWL, BOTNET, CRM114_HAM_00, JR_RCVD_HOST_PROBS1, JR_RCVD_TOO_FEW_HOPS X-Spam-Level: ** Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 09:35:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F5E7068E37DFE4212F9AC0D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Edwin Groothuis wrote, On 28.9.2008 7:46: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. >=20 > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. >=20 > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) >=20 > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. >=20 > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. >=20 > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". >=20 > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! Is this 7.0+ only? I run 6.3 and I see the following when I start it: last pid: -1077944144; loa 0.52, 0.28, 0.26; up 11+15:31:33 1= 1:33:05 0 processes: CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle Kernel: 1 intr Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M Fre= e Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse sysctlnametomib: No such file or directory And no processes. >=20 > Edwin >=20 -- VH --------------enig8F5E7068E37DFE4212F9AC0D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iFUEAREIAAYFAkjfT9QACgkQhQBMvHf/WHk8rgDWMU0NT2m2ejKUkasI+6ltWuKo 5F0vAL18HSoNAN9jVPjYQLeK++hIc2SxKmt5Suldlv2L/bM1TBTW =mGb8 -----END PGP SIGNATURE----- --------------enig8F5E7068E37DFE4212F9AC0D-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 09:37:50 2008 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 A2A17106568A for ; Sun, 28 Sep 2008 09:37:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 28DE78FC15 for ; Sun, 28 Sep 2008 09:37:49 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so185918uge.39 for ; Sun, 28 Sep 2008 02:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lIhSu5/drYM6Nh64doZLvYveKiVppalR460JblBv00w=; b=J+XZgowk2CKE2UKRSlXSDUpgVoXsh2YqjXgicqYQJCoF+wzRx/Is12T1ylc62P7SLr b1B4P70kaKiPXlxw7FTYkpkwG/KdyBFbvk1a6EePlcLaEQgX/MwSciqGMeT3Y2+S6rGc Vuxg7O6TC5ugelEPOxd4pBPqTskXbJP5DSozE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ov1jsUfAF2932Jh8xy4cnUIdFTjFkpfbHlgCiyyMs16HxVrMwb6atQoF+fOoaGHNLh P5Mz+t3wk6P660hwYpwmWEN4kXXcwg2cIdT6e13l/WPO6oR8oxx0CqeeXJM/viBJAcJB 3UBD1FZTqQBD2YsZ4RTQyfvCUXZyA/cVdKiGc= Received: by 10.66.249.20 with SMTP id w20mr150836ugh.22.1222592940740; Sun, 28 Sep 2008 02:09:00 -0700 (PDT) Received: by 10.66.251.1 with HTTP; Sun, 28 Sep 2008 02:09:00 -0700 (PDT) Message-ID: <7d6fde3d0809280209i3003829bj23baa93f0b271163@mail.gmail.com> Date: Sun, 28 Sep 2008 02:09:00 -0700 From: "Garrett Cooper" To: "Alex Keda" In-Reply-To: <48DF3CFE.7@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080928054620.GA80250@k7.mavetju> <48DF3CFE.7@lissyara.su> Cc: stable@freebsd.org, current@freebsd.org, Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 09:37:50 -0000 T24gU3VuLCBTZXAgMjgsIDIwMDggYXQgMToxNCBBTSwgQWxleCBLZWRhIDxhZG1pbkBsaXNzeWFy YS5zdT4gd3JvdGU6Cj4gRWR3aW4gR3Jvb3RodWlzINDJ28XUOgo+Pgo+PiBJIGhhdmUgbWFkZSBh biB1cGRhdGUgZm9yIHRoZSB0b3AoMSkgdXRpbGl0eSBpbiB0aGUgRnJlZUJTRCBiYXNlCj4+IHN5 c3RlbSB0byBnZXQgaXQgZnJvbSB0aGUgMy41YjEyIHZlcnNpb24gdG8gdGhlIDMuOGIxIHZlcnNp b24uCj4+Cj4+IEkgaGF2ZSB0cmllZCB0aGVtIG9uIHRoZSBhbWQ2NCBhcmNoaXRlY3R1cmUgb24g RnJlZUJTRCAtY3VycmVudCBhbmQKPj4gRnJlZUJTRCA3LjAgYW5kIG9uIHRoZSBpMzg2IGFyY2hp dGVjdHVyZSBvbiBGcmVlQlNEIDcuMC4KPj4KPj4gVGhlIGJpZyBuZXcgZmVhdHVyZXMgYXJlIGEg bGluZSB1cHBlciBwYXJ0IHdpdGgga2VybmVsIHN0YXRpc3RpY3MKPj4gKGNvbnRleHQtc3dpdGNo ZXMsIHRyYXBzLCBpbnRlcnJ1cHRzLCBmYXVsdHMgZXRjKSBhbmQgdGhlIEZMRyB0YWJsZQo+PiAo aWYgeW91IHdpbmRvdyBpcyBiaWcgZW5vdWdoKQo+Pgo+PiBTb21lIGZlYXR1cmVzIHNwZWNpZmlj IHRvIEZyZWVCU0QgKGR1YWwgZGlzcGxheSAocHJlc3MgbSkpLCB0aHJlYWRlZAo+PiBwcm9jZXNz ZXMsIGFuZCBqYWlscyBoYXZlIGJlZW4gcG9ydGVkIHRvIDMuOGIxLgo+Pgo+PiBUaGUgYmlnZ2Vz dCBmaXggKEFGQUlDVCkgaXMgdGhlIFRJTUUgYW5kIENQVSB0YWJsZSBmb3IgdGhyZWFkZWQKPj4g cHJvY2Vzc2VzLCB3aGljaCBhcmUgbm93IGNhbGN1bGF0ZWQgcHJvcGVybHkuCj4+Cj4+IFRoZSBu ZXcgY29kZSBjYW4gYmUgZm91bmQgb24KPj4gICAgaHR0cDovL3d3dy5tYXZldGp1Lm9yZy9+ZWR3 aW4vZnJlZWJzZC10b3AtMy44YjEtQS50YXIuZ3oKPj4gR28gdG8gMy44YjEvdXNyLnNiaW4vdG9w IGFuZCBydW4gIm1ha2UiIHRoZXJlIHRvIHByb2R1Y2UgdGhlIGJpbmFyeSwKPj4gdGhlbiBydW4g aXQgdmlhICIuL3RvcCIuCj4+Cj4+IFBsZWFzZSByZXBvcnQgYW55IGlzc3VlcyB3aXRoIGl0IChj b21waWxlIHRpbWUsIHJ1biB0aW1lKSBhbmQgYSB3YXkKPj4gdG8gcmVwcm9kdWNlIGl0IChpZiBw b3NzaWJsZSkuIFRoYW5rcyBmb3IgeW91ciBoZWxwIQo+Pgo+PiBFZHdpbgo+Pgo+IFNvbWUgc3Ry YW5nZS4gQ291bnQgcnVubmluZyBwcm9jZXNzZXMgbm90IG1hdGNoIHdpdGggc3lzdGVtIHRvcAo+ ID09PT09PT09PSBzeXN0ZW0gdG9wID09PT09PT09PT09PT0KPiBsYXN0IHBpZDogMzAyODU7IGxv YWQgYXZlcmFnZXM6IDAuOTksIDAuOTEsIDAuOTEgdXAgMCsyMTowODo0OSAgMTI6MTA6NDAKPiA0 NSBwcm9jZXNzZXM6ICAyIHJ1bm5pbmcsIDQzIHNsZWVwaW5nCj4gQ1BVOiAyNC4zJSB1c2VyLCAg MC4wJSBuaWNlLCAgMS4zJSBzeXN0ZW0sICAwLjAlIGludGVycnVwdCwgNzQuNCUgaWRsZQo+IE1l bTogMjM2TSBBY3RpdmUsIDE2OTNNIEluYWN0LCA0MTRNIFdpcmVkLCAxMzdNIENhY2hlLCAyMTRN IEJ1ZiwgNTE4N00gRnJlZQo+IFN3YXA6IDQwOTZNIFRvdGFsLCA0MDk2TSBGcmVlCj4KPiAgUElE IFVTRVJOQU1FICAgVEhSIFBSSSBOSUNFICAgU0laRSAgICBSRVMgU1RBVEUgIEMgICBUSU1FICAg V0NQVSBDT01NQU5ECj4gODcwMDggcm9vdCAgICAgICAgIDEgICA4ICAgIDAgNTg3MjhLIDQzMDI4 SyB3YWl0ICAgMCAgIDA6MDUgIDAuMDAlIHJ1YnkxOAo+IDg3MDAyIHJvb3QgICAgICAgICAxICA0 NCAgICAwICA1Njg4SyAgMTEyNEsgc2VsZWN0IDIgICAwOjAyICAwLjAwJSBzY3JpcHQKPiAgMTE2 OCByb290ICAgICAgICAgMSAgNDQgICAgMCAyMjg3MksgIDQzMDhLIHNlbGVjdCAzICAgMDowMSAg MC4wMCUgc3NoZAo+IDMwMjg0IHJvb3QgICAgICAgICAxICA5NyAgICAwIDk3NDIwSyA5MDg0NEsg Q1BVMSAgIDEgICAwOjAxICAwLjAwJSBjYzFwbHVzCj4gIDcyMSByb290ICAgICAgICAgMSAgNDQg ICAgMCAxMDY5NksgIDQwMDBLIHNlbGVjdCAwICAgMDowMSAgMC4wMCUgc2VuZG1haWwKPiA4Njk4 MCBsaXNzeWFyYSAgICAgMSAgNDQgICAgMCAzMzc2NEsgIDQ4NDBLIHNlbGVjdCAyICAgMDowMCAg MC4wMCUgc3NoZAo+ICA1ODQgcm9vdCAgICAgICAgIDEgIDQ0ICAgIDAgIDU2ODhLICAxMzY0SyBz ZWxlY3QgMiAgIDA6MDAgIDAuMDAlIHN5c2xvZ2QKPiAgNzMzIHJvb3QgICAgICAgICAxICAgOCAg ICAwICA2NzQ0SyAgMTQzNksgbmFuc2xwIDAgICAwOjAwICAwLjAwJSBjcm9uCj4gNTI0NTEgbGlz c3lhcmEgICAgIDEgIDQ0ICAgIDAgMzM3NjRLICA0ODQwSyBzZWxlY3QgMCAgIDA6MDAgIDAuMDAl IHNzaGQKPgo+ID09PT09PT09IG5ldyB0b3AgPT09PT09PT09PQo+IGxhc3QgcGlkOiAzMDI4MDsg IGxvYWQgYXZnOiAgMC45OSwgIDAuOTEsICAwLjkxOwo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVwIDArMjE6MDg6NDggICAgMTI6MTA6MzkKPiA5OSBwcm9jZXNzZXM6IDYgcnVubmluZywg NzYgc2xlZXBpbmcsIDE3IHdhaXRpbmcKPiBDUFU6ICAyMy42JSB1c2VyLCAgMC4wJSBuaWNlLCAg MS45JSBzeXN0ZW0sICAwLjAlIGludGVycnVwdCwgNzQuNSUgaWRsZQo+IEtlcm5lbDogNDE5MiBj dHhzdywgMjEzOTggdHJhcCwgNCBpbnRyLCAxMDAwIHNvZnQsIDQgZm9yaywgMjE0MjcgZmx0LCAy NjE0MAo+IGZyCj4gTWVtOiAgICAyMzlNIEFjdGl2ZSwgMTY5M00gSW5hY3QsIDQxNE0gV2lyZWQs IDEzN00gQ2FjaGUsIDIxNE0gQnVmLCA1MTg0TQo+IEZyZWUKPiBTd2FwOiAgIDQwOTZNIFRvdGFs LCA0MDk2TSBGcmVlCj4KPiAgIFBJRCBVU0VSTkFNRSBUSFIgUFJJIE5JQ0UgIFNJWkUgICBSRVMg U1RBVEUgIEZMRyBDICAgVElNRSAgICBDUFUgQ09NTUFORAo+ICAzMDI3OSByb290ICAgICAgIDEg IDk4ICAgIDAgICA5N00gICA5MU0gQ1BVMSAgICsgICAxICAgMDowMSA0OC45NCUgY2MxcGx1cwo+ ICAzMDI4MCByb290ICAgICAgIDEgIC04ICAgIDAgMjE3NksgMTY4OEsgcGlwZXJkICsgICAwICAg MDowMCAgMC4xNCUgYXMKPiAgMzAyNzcgcm9vdCAgICAgICAxICAgOCAgICAwIDcwNjBLIDE4ODRL IHdhaXQgICArICAgMSAgIDA6MDAgIDAuMDYlIHNoCj4gIDMwMjc4IHJvb3QgICAgICAgMSAgIDgg ICAgMCA0NjAwSyAxMjg0SyB3YWl0ICAgKyAgIDAgICAwOjAwICAwLjA2JSBjKysKPiAgMzAyNDUg cm9vdCAgICAgICAxICA0NCAgICAwIDgxMTJLIDIyMjBLIHNlbGVjdCArICAgMCAgIDA6MDAgIDAu MDQlIHRvcAo+ICAzMDIxOSByb290ICAgICAgIDEgIDQ0ICAgIDAgODExMksgMjI4NEsgQ1BVMiAg ICsgICAyICAgMDowMCAgMC4wMiUgdG9wCj4gIDg2OTgwIGxpc3N5YXJhICAgMSAgNDQgICAgMCAg IDMzTSA0ODQwSyBzZWxlY3QgICAgIDIgICAwOjAwICAwLjAxJSBzc2hkCj4gIDI5NDcyIHJvb3Qg ICAgICAgMSAgIDggICAgMCAzMjAwSyAxMzkySyB3YWl0ICAgKyAgIDMgICAwOjAwICAwLjAxJSBt YWtlCj4gIDg3MDA4IHJvb3QgICAgICAgMSAgIDggICAgMCAgIDU3TSAgIDQyTSB3YWl0ICAgKyAg IDAgICAwOjA1ICAwLjAwJSBydWJ5MTgKPiAgODcwMDIgcm9vdCAgICAgICAxICA0NCAgICAwIDU2 ODhLIDExMjRLIHNlbGVjdCArICAgMiAgIDA6MDIgIDAuMDAlIHNjcmlwdAo+ICAxMTY4IHJvb3Qg ICAgICAgMSAgNDQgICAgMCAgIDIyTSA0MzA4SyBzZWxlY3QgcyAgIDMgICAwOjAxICAwLjAwJSBz c2hkCj4KPiA9PT09PT09PT09PT09PT09PT09PT09Cj4gRnJlZUJTRCBzZXJ2Mi5ob3MtdGluZy5y dSA3LjEtUFJFUkVMRUFTRSBGcmVlQlNEIDcuMS1QUkVSRUxFQVNFICMwOiBTYXQgU2VwCj4gMjcg MTQ6NTA6NTkgTVNEIDIwMDggbGlzc3lhcmFAc2VydjIuaG9zLXRpbmcucnU6L3Vzci9vYmovdXNy L3NyYy9zeXMvSE9TVElORwo+ICBhbWQ2NAoKSSdtIG5vdCBzdXJlIEknbSBmaW5kaW5nIGFuIGlz c3VlLCBidXQgSSBkbyBmaW5kIGl0IGludGVyZXN0aW5nIHRoYXQuLi4KMS4gSXQgdGFrZXMgYSBy ZWFzb25hYmx5IGxvbmcgYW1vdW50IG9mIHRpbWUgZm9yIHRvcCB0byBwbGF0ZWF1IHRoZQpXQ1BV IGZpZWxkIChhcHByb3hpbWF0ZWx5IDgtMTAgaXRlcmF0aW9ucyksIHdoZXJlYXMgcHMgcmVnaXN0 ZXJpbmcgdGhlCldDUFUgcGVyY2VudGFnZSB2YWx1ZSBpcyBhbG1vc3QgaW5zdGFudGFuZW91cy4K Mi4gdG9wIGFwcGVhcnMgdG8gYmUgZG9pbmcgc29tZSBpbnRlcmVzdGluZyByb3VuZGluZyB0aGF0 IHBzIGlzbid0CmRvaW5nIChwcyByZWdpc3RlcnMgYW55d2hlcmUgYmV0d2VlbiA4OC40IGFuZCA5 NyUgdmlhIHBzIHZzIDEwMCUgdmlhCnRvcCBmb3IgYSBzaW1wbGUgb3BlcmF0aW9uIGxpa2UgYHdo aWxlIFsgMSBdIDsgZG8gY2F0IC9kZXYvdXJhbmRvbSA+Ci9kZXYvbnVsbDsgZG9uZScpLgoKLUdh cnJldHQK From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 09:49:34 2008 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 BB45C1065692; Sun, 28 Sep 2008 09:49:34 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7818B8FC17; Sun, 28 Sep 2008 09:49:34 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 9C23B2218A41; Sun, 28 Sep 2008 19:49:33 +1000 (EST) X-Viruscan-Id: <48DF532D00014C7BFAA8D6@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 55A2F21B5A17; Sun, 28 Sep 2008 19:49:33 +1000 (EST) Received: from k7.mavetju (ppp121-44-55-162.lns10.syd7.internode.on.net [121.44.55.162]) by mail5auth.barnet.com.au (Postfix) with ESMTP id EFB1C221882A; Sun, 28 Sep 2008 19:49:32 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id C3F51798; Sun, 28 Sep 2008 19:49:03 +1000 (EST) Date: Sun, 28 Sep 2008 19:49:03 +1000 From: Edwin Groothuis To: Stefan `Sec` Zehl Message-ID: <20080928094903.GB13745@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <20080928093357.GA71582@ice.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928093357.GA71582@ice.42.org> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@Freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 09:49:34 -0000 On Sun, Sep 28, 2008 at 11:33:57AM +0200, Stefan `Sec` Zehl wrote: > Hi, > > On Sun, Sep 28, 2008 at 15:46 +1000, Edwin Groothuis wrote: > > The new code can be found on > > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > > then run it via "./top". > > compiles and runs fine on my box: > > FreeBSD ice 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #17: Wed Sep 3 23:59:58 CEST 2008 root@ice:/usr/obj/usr/src/sys/ICE amd64 > > > Please report any issues with it (compile time, run time) and a way > > to reproduce it (if possible). Thanks for your help! > > The number of sleeping processes is much lower than system top: > > oldtop: 480 processes: 3 running, 450 sleeping, 2 stopped, 7 zombie, 18 waiting > newtop: 190 processes: 3 running, 160 sleeping, 2 stopped, 7 zombie, 18 waiting Oh yes, I forgot about that: The old top(1) and new top(1) counts the processes different: - "ps xauw | wc" gives 265 - "ps xauwH | wc" gives 295 (expand threads) - old top gives 240 processes. - old top + "S" (system processes) gives 292 processes. - old top + "H" (threads) gives 240 "processes" - old top + "S" (system processes) + "H" (threads) gives 292 "processes" - new top gives 260 processes - new top + "S" (system processes) gives 260 processes - new top + "H" (threads) gives 292 *threads* - new top + "S" (system processes) + "H" (threads) gives 292 *threads* This is only for the summary menu, not for the process list. Thanks for your feedback, it is surely something which needs to be written down in the official announcement. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 10:20:35 2008 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 A3A42106568B for ; Sun, 28 Sep 2008 10:20:35 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id D16238FC33 for ; Sun, 28 Sep 2008 10:20:34 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 56837 invoked from network); 28 Sep 2008 09:53:51 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 28 Sep 2008 09:53:51 -0000 Date: Sun, 28 Sep 2008 11:53:51 +0200 (CEST) Message-Id: <20080928.115351.74700175.sthaug@nethelp.no> To: edwin@freebsd.org From: sthaug@nethelp.no In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 10:20:35 -0000 > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) Would it be possible to document the values in the FLG field? The meaning wasn't obvious to me... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 11:26:09 2008 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 7A8181065692; Sun, 28 Sep 2008 11:26:09 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3632F8FC0A; Sun, 28 Sep 2008 11:26:09 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id ED4672218A97; Sun, 28 Sep 2008 21:26:07 +1000 (EST) X-Viruscan-Id: <48DF69CF00003F4A78109C@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id A67D121B6458; Sun, 28 Sep 2008 21:26:07 +1000 (EST) Received: from k7.mavetju (ppp121-44-55-162.lns10.syd7.internode.on.net [121.44.55.162]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 58560221882A; Sun, 28 Sep 2008 21:26:07 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 861796A0; Sun, 28 Sep 2008 21:25:38 +1000 (EST) Date: Sun, 28 Sep 2008 21:25:38 +1000 From: Edwin Groothuis To: Garrett Cooper Message-ID: <20080928112538.GC13745@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <48DF3CFE.7@lissyara.su> <7d6fde3d0809280209i3003829bj23baa93f0b271163@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0809280209i3003829bj23baa93f0b271163@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Alex Keda , stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 11:26:09 -0000 On Sun, Sep 28, 2008 at 02:09:00AM -0700, Garrett Cooper wrote: > On Sun, Sep 28, 2008 at 1:14 AM, Alex Keda wrote: > > Some strange. Count running processes not match with system top That has been explained in an email before. > I'm not sure I'm finding an issue, but I do find it interesting that... > 1. It takes a reasonably long amount of time for top to plateau the > WCPU field (approximately 8-10 iterations), whereas ps registering the > WCPU percentage value is almost instantaneous. With ps it takes 10 2 second steps to get the WCPU from 0 to 100, with the new top (which doesn't have WCPU (See Changes file, and the m_freebsd.c file, I don't know of the real reason behind it) anymore) goes from 0 to 100 in 2 2 second steps. > 2. top appears to be doing some interesting rounding that ps isn't > doing (ps registers anywhere between 88.4 and 97% via ps vs 100% via > top for a simple operation like `while [ 1 ] ; do cat /dev/urandom > > /dev/null; done'). On my machine it is ps which rounds it up to 100% and top somewhere between 98.0% and 99.9%. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 11:32:01 2008 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 A5EEB1065678; Sun, 28 Sep 2008 11:32:01 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 63EDF8FC13; Sun, 28 Sep 2008 11:32:01 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id A37382218A97; Sun, 28 Sep 2008 21:32:00 +1000 (EST) X-Viruscan-Id: <48DF6B30000044BE00597D@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 42BF321B6463; Sun, 28 Sep 2008 21:32:00 +1000 (EST) Received: from k7.mavetju (ppp121-44-55-162.lns10.syd7.internode.on.net [121.44.55.162]) by mail5auth.barnet.com.au (Postfix) with ESMTP id F25B4221882A; Sun, 28 Sep 2008 21:31:59 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 3832977F; Sun, 28 Sep 2008 21:31:31 +1000 (EST) Date: Sun, 28 Sep 2008 21:31:31 +1000 From: Edwin Groothuis To: sthaug@nethelp.no Message-ID: <20080928113131.GD13745@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <20080928.115351.74700175.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928.115351.74700175.sthaug@nethelp.no> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 11:32:01 -0000 On Sun, Sep 28, 2008 at 11:53:51AM +0200, sthaug@nethelp.no wrote: > > The big new features are a line upper part with kernel statistics > > (context-switches, traps, interrupts, faults etc) and the FLG table > > (if you window is big enough) > > Would it be possible to document the values in the FLG field? The > meaning wasn't obvious to me... I will take care of it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 11:52:42 2008 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 AA7E21065688 for ; Sun, 28 Sep 2008 11:52:42 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 9212C8FC0A for ; Sun, 28 Sep 2008 11:52:42 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id CD74A7979C; Sun, 28 Sep 2008 04:52:32 -0700 (PDT) Date: Sun, 28 Sep 2008 04:52:32 -0700 From: Clint Olsen To: stable@freebsd.org Message-ID: <20080928115232.GA5621@0lsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: CD74A7979C.A967B X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: Subject: More diagnostics trying to dump filesystem 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, 28 Sep 2008 11:52:42 -0000 This is all /really/ helpful: mksnap_ffs: Cannot create /home/.snap/dump_snapshot: Resource temporarily unavailable dump: Cannot create /home/.snap/dump_snapshot: No such file or directory >From /var/log/messages: fsync: giving up on dirty 0xc524b330: tag devfs, type VCHR usecount 1, writecount 0, refcount 642 mountedhere 0xc5063a00 flags () v_object 0xc1432000 ref 0 pages 2556 lock type devfs: EXCL (count 1) by thread 0xc5e58600 (pid 5531) dev ad0s1d -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 11:54:31 2008 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 58A1E1065686; Sun, 28 Sep 2008 11:54:31 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 167168FC16; Sun, 28 Sep 2008 11:54:31 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 6FA312218BC0; Sun, 28 Sep 2008 21:54:30 +1000 (EST) X-Viruscan-Id: <48DF7076000071CB9A129D@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 2C71721B64CE; Sun, 28 Sep 2008 21:54:30 +1000 (EST) Received: from k7.mavetju (ppp121-44-55-162.lns10.syd7.internode.on.net [121.44.55.162]) by mail5auth.barnet.com.au (Postfix) with ESMTP id DB1182218AF3; Sun, 28 Sep 2008 21:54:29 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 252586BE; Sun, 28 Sep 2008 21:54:01 +1000 (EST) Date: Sun, 28 Sep 2008 21:54:01 +1000 From: Edwin Groothuis To: V??clav Haisman Message-ID: <20080928115401.GU3210@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DF4FCA.4070403@sh.cvut.cz> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 11:54:31 -0000 On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: > > to reproduce it (if possible). Thanks for your help! > Is this 7.0+ only? I run 6.3 and I see the following when I start it: > > last pid: -1077944144; loa 0.52, 0.28, 0.26; > up 11+15:31:33 11:33:05 > 0 processes: > CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle > Kernel: 1 intr > Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M Free > Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse > sysctlnametomib: No such file or directory > > And no processes. I didn't expect it not to work on 6.x, I will play around with it tomorrow to see if it makes sense. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 12:48:40 2008 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 575E31065695; Sun, 28 Sep 2008 12:48:40 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) Received: from anthesphoria.net (anthesphoria.net [200.46.204.219]) by mx1.freebsd.org (Postfix) with ESMTP id E632F8FC08; Sun, 28 Sep 2008 12:48:39 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) X-Bogosity: No, tests=bogofilter X-DKIM: Sendmail DKIM Filter v2.4.1 anthesphoria.net m8SCQYOV041466 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anthesphoria.net; s=phero; t=1222604800; bh=jUsk9puSVA6jTsKzMJTZhDEz2NskW2jGmXibS/TOQ Ig=; l=2936; h=X-Bogosity:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:X-Mailer:X-Face:X-Operating-System: X-OpenPGP-Fingerprint:X-OpenPGP-Preferred-Keyserver:Mime-Version: Content-Type:Content-Transfer-Encoding; b=p0UxHYzH4dYaDiyvgJonv8YQ VOyMI7F22JoewE48AiKBuQfrgmv86sPYuXob16QxcK7hnTlchJObG1TxFj9Pxw02Djd LhuwecHvK+7c4EtB2UnslefhBrsEDQlHFeUIEGv9DLyIdT2RCvfvzgoS8j3FFZsWqVU rKlhUGJm2yLwA= Received: from anthesphoria.net (adsl-200-199.eunet.yu [213.198.200.199]) (authenticated bits=0) by anthesphoria.net (8.14.2/8.14.2) with ESMTP id m8SCQYOV041466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2008 14:26:38 +0200 (CEST) (envelope-from nikola.lecic@anthesphoria.net) Date: Sun, 28 Sep 2008 14:24:09 +0200 From: Nikola =?UTF-8?B?TGXEjWnEhw==?= To: Edwin Groothuis Message-ID: <20080928142409.19f94e5b@anthesphoria.net> In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) X-Face: pbl6-.[$G'Fi(Ogs2xlXP-V6{3||$Y[LOYs&~GJoikj'cVjcFC[V7du;;0~6nO= [Vi2?uU1Pq~,=Adj@,T:|"`$AF~il]J.Nz#2pU',Y7.{B;m/?{#sO^Dvo$rnmY6] X-Operating-System: FreeBSD 7.0-RELEASE/i386 X-OpenPGP-Fingerprint: FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B X-OpenPGP-Preferred-Keyserver: x-hkp://pgpkeys.pca.dfn.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-current@FreeBSD.org, FreeBSD-stable@FreeBSD.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 12:48:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Sun, 28 Sep 2008 15:46:20 +1000 Edwin Groothuis wrote: =20 > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! FreeBSD black 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep 11 15:05:17 CEST 2008 nikola@black:/usr/obj/usr/src/sys/GENERIC i386 Core2Quad Q6600, 2G RAM, compiling mplayer, in H mode I got this: last pid: 70762; load avg: 1.22, 0.54, 0.33; up 0+16:48:11 14:08:= 01 177 threads: 11 running, 147 sleeping, 19 waiting CPU: 27.6% user, 0.0% nice, 3.3% system, 0.7% interrupt, 68.4% idle Kernel: 246626 ctxsw, 5063 trap, 362 intr, 354 soft, 5 fork, 4591 flt, 728 = fr Mem: 891M Active, 774M Inact, 233M Wired, 89M Cache, 112M Buf, 3668K Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE FLG C TIME CPU COMMAND 70729 root 104 0 74M 72M CPU2 + 2 0:05 100.64% cc1 47252 nikola 53 0 379M 84M RUN + 0 21:20 8.34% Xorg 47290 nikola 44 0 59M 46M CPU3 + 1 7:06 1.81% compiz 47972 nikola 44 0 112M 61M select s 3 11:09 1.15% amule 70730 root -8 0 2912K 1592K piperd + 0 0:00 0.92% as 47579 nikola 44 0 66M 23M CPU0 3 0:23 0.46% Terminal 47547 nikola 45 0 332M 251M RUN 1 6:58 0.39% firefox-bin 17027 nikola 96 0 26M 23M RUN + 3 1:30 0.38% conky 61107 nikola 4 0 47M 18M select s 1 0:01 0.28% mousepad 47284 nikola 44 0 14M 7844K select s 2 0:17 0.21% gnome-scre= ensaver 861 root 44 0 3268K 896K select s 0 0:12 0.21% moused 47263 nikola 44 0 21M 13M select s 0 0:12 0.21% scim-panel= -gtk 47296 nikola 44 0 45M 15M select + 3 0:15 0.17% xfce4-panel 47299 nikola 44 0 17M 11M select + 2 1:20 0.16% xfce4-netl= oad-plugi 47547 nikola 44 0 332M 251M ucond 0 0:54 0.11% firefox-bin 47310 nikola 44 0 27M 20M select s 2 0:32 0.07% emerald 986 haldaemon 44 0 6812K 4004K select s 3 0:27 0.07% hald 23567 nikola 44 0 6744K 3788K select s 0 0:18 0.06% scim-launc= her 67253 nikola 44 0 45M 33M select s 3 0:34 0.05% skype 53739 nikola 44 0 45M 35M select + 2 0:34 0.05% compiz 47263 nikola 44 0 21M 13M select s 0 0:20 0.05% scim-panel= -gtk Is it normal to have 100.64% for cc1? Btw, an aesthetic observation, in H mode the USERNAME column shrinks and expands if username has less or more than 9 characters. :-) Thanks. - --=20 Nikola Le=C4=8Di=C4=87 =3D =D0=9D=D0=B8=D0=BA=D0=BE=D0=BB=D0=B0 =D0=9B=D0= =B5=D1=87=D0=B8=D1=9B fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iJwEAQEDAAYFAkjfd24ACgkQ/MM/0rYIoZiGogP9EMyfOCVBJwTnZZapTN5RERN+ eJiDbb6ww6SOLZQDAt23Qq/ia2dIgtCq2a533CCGVAx2VjnHnivM19ireBTMP5sa 7+sRGWxjfa6L+cv2jQsHnZkBLPkDC4+iVFL57PMXvbsB4gQww62ZPrxWbgu46t78 g78gaqiGtbwmQNZiJyg=3D =3DyYdi -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 16:13:04 2008 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 C27E51065689; Sun, 28 Sep 2008 16:13:04 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5F25C8FC20; Sun, 28 Sep 2008 16:13:04 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SG2o5m012382; Sun, 28 Sep 2008 16:02:50 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SG2lhU053261; Sun, 28 Sep 2008 12:02:48 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFAAA2.6040201@lefebvre.org> Date: Sun, 28 Sep 2008 12:02:42 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> In-Reply-To: <20080928054620.GA80250@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 16:13:04 -0000 Yay I was hoping someone would pick this up. Edwin: I will pick up your changes and roll them back in to the source. Then I can distribute an official release of 3.8 and make it non-beta. I will respond to other comments in separate messages. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 16:16:41 2008 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 7E2B21065697; Sun, 28 Sep 2008 16:16:41 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id B8A398FC12; Sun, 28 Sep 2008 16:16:40 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (ppp251-132.adsl.forthnet.gr [77.49.30.132]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m8SG57od005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Sep 2008 19:05:13 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m8SG4jZs002583; Sun, 28 Sep 2008 19:04:45 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m8SG4YA1002582; Sun, 28 Sep 2008 19:04:34 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> Date: Sun, 28 Sep 2008 19:04:34 +0300 In-Reply-To: <20080928054620.GA80250@k7.mavetju> (Edwin Groothuis's message of "Sun, 28 Sep 2008 15:46:20 +1000") Message-ID: <87fxnkz27h.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m8SG57od005479 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.854, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.55, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 16:16:41 -0000 On Sun, 28 Sep 2008 15:46:20 +1000, Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. Thank you! :) From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 16:17:04 2008 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 9460E1065687; Sun, 28 Sep 2008 16:17:04 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5368B8FC13; Sun, 28 Sep 2008 16:17:04 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SGH2vM013083; Sun, 28 Sep 2008 16:17:03 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SGGx7Z053437; Sun, 28 Sep 2008 12:17:00 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFADF6.10504@lefebvre.org> Date: Sun, 28 Sep 2008 12:16:54 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> <48DF3CFE.7@lissyara.su> <7d6fde3d0809280209i3003829bj23baa93f0b271163@mail.gmail.com> <20080928112538.GC13745@k7.mavetju> In-Reply-To: <20080928112538.GC13745@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: Alex Keda , Garrett Cooper , stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 16:17:04 -0000 Edwin Groothuis wrote: > On Sun, Sep 28, 2008 at 02:09:00AM -0700, Garrett Cooper wrote: >> On Sun, Sep 28, 2008 at 1:14 AM, Alex Keda wrote: >>> Some strange. Count running processes not match with system top > > That has been explained in an email before. > >> I'm not sure I'm finding an issue, but I do find it interesting that... >> 1. It takes a reasonably long amount of time for top to plateau the >> WCPU field (approximately 8-10 iterations), whereas ps registering the >> WCPU percentage value is almost instantaneous. Top 3.8 doesn't display WCPU. It is an antequated measure that is only maintained by the kernel so that ps can display it. It no longer has any meaning to the scheduler, so why bother displaying it. > > With ps it takes 10 2 second steps to get the WCPU from 0 to 100, > with the new top (which doesn't have WCPU (See Changes file, and > the m_freebsd.c file, I don't know of the real reason behind it) > anymore) goes from 0 to 100 in 2 2 second steps. ps shows a decaying average as calculated by the kernel over the past minute and recorded in the proc structure. Top calculates its own average based on the difference in cpu time between the last measurement and the current measurement. The output from ps is fine when you want a single snapshot: you want it to show information averaged over a long period of time. Top is showing you only what's going on right now, since the last update. That's why percent CPU in top will climb to its final value so quickly. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 16:29:23 2008 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 8148C106569D; Sun, 28 Sep 2008 16:29:23 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3458FC12; Sun, 28 Sep 2008 16:29:23 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SGTMhw013795; Sun, 28 Sep 2008 16:29:22 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SGTKFc053547; Sun, 28 Sep 2008 12:29:20 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFB0DA.1000907@lefebvre.org> Date: Sun, 28 Sep 2008 12:29:14 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Edwin Groothuis , v.haisman@sh.cvut.cz References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> <20080928115401.GU3210@k7.mavetju> In-Reply-To: <20080928115401.GU3210@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 16:29:23 -0000 Edwin Groothuis wrote: > On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: >>> to reproduce it (if possible). Thanks for your help! >> Is this 7.0+ only? I run 6.3 and I see the following when I start it: >> >> last pid: -1077944144; loa 0.52, 0.28, 0.26; >> up 11+15:31:33 11:33:05 >> 0 processes: >> CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle >> Kernel: 1 intr >> Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M Free >> Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse >> sysctlnametomib: No such file or directory >> >> And no processes. > > I didn't expect it not to work on 6.x, I will play around with it > tomorrow to see if it makes sense. It worked on my 6.2 system. Was the binary compiled under 6.3? Unfortunately the error message didn't say *which* mib it couldn't find. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 16:53:10 2008 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 8C48F106564A; Sun, 28 Sep 2008 16:53:10 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id 4C74D8FC1A; Sun, 28 Sep 2008 16:53:10 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SGr8c9015055; Sun, 28 Sep 2008 16:53:08 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SGr6Mx053815; Sun, 28 Sep 2008 12:53:07 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFB66D.3090002@lefebvre.org> Date: Sun, 28 Sep 2008 12:53:01 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: sthaug@nethelp.no References: <20080928054620.GA80250@k7.mavetju> <20080928.115351.74700175.sthaug@nethelp.no> In-Reply-To: <20080928.115351.74700175.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: stable@freebsd.org, current@freebsd.org, edwin@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 16:53:10 -0000 sthaug@nethelp.no wrote: >> The big new features are a line upper part with kernel statistics >> (context-switches, traps, interrupts, faults etc) and the FLG table >> (if you window is big enough) > > Would it be possible to document the values in the FLG field? The > meaning wasn't obvious to me... The FLG field is essentially the same as the ps "STAT" column (or "state" field) without the first character (which indicates run state). Bill From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 17:05:40 2008 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 E010B106568B; Sun, 28 Sep 2008 17:05:40 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2EC8FC0C; Sun, 28 Sep 2008 17:05:40 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SG8SPT012715; Sun, 28 Sep 2008 16:08:28 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SG8PFN053326; Sun, 28 Sep 2008 12:08:26 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFABF4.6030907@lefebvre.org> Date: Sun, 28 Sep 2008 12:08:20 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Alex Keda References: <20080928054620.GA80250@k7.mavetju> <48DF3CFE.7@lissyara.su> In-Reply-To: <48DF3CFE.7@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 17:05:41 -0000 Alex Keda wrote: > Some strange. Count running processes not match with system top I went back and forth on this. Old top would only count system processes in the summary line if they were also being displayed below (i.e.: using the 'S' command or the -S switch). Yet other restrictions on the main display were not reflected in the count. For example if you restrict the view to a particular command or user the count would still include all user processes. This seemed inconsistent to me and in the end I decided to count all processes regardless of what was being displayed. In version 3.8 the process count is (almost) the same as "ps ax | wc -l". I will make sure the documentation reflects this. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 17:50:51 2008 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 B5A42106568B for ; Sun, 28 Sep 2008 17:50:51 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-120.sea1.dsl.speakeasy.net [64.81.163.120]) by mx1.freebsd.org (Postfix) with ESMTP id 727018FC08 for ; Sun, 28 Sep 2008 17:50:51 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8SHonAQ021556 for ; Sun, 28 Sep 2008 10:50:49 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48DFC3F9.1040909@highperformance.net> Date: Sun, 28 Sep 2008 10:50:49 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=2.5 tests=ALL_TRUSTED,BAYES_20 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Subject: Blacklisted ACPI Prevents Boot 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, 28 Sep 2008 17:50:51 -0000 I just installed a 6.4-PRERELEASE kernel and tried to boot. The boot failed with a message that my ACPI was blacklisted. I have had 'device acpi' in my kernel for some time now. The boot interruption is new behavior. Is this sort of change a good thing to put in UPDATING? Regards, Jason From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 18:06:15 2008 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 C42C21065689 for ; Sun, 28 Sep 2008 18:06:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 498318FC2D for ; Sun, 28 Sep 2008 18:06:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so225789uge.39 for ; Sun, 28 Sep 2008 11:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YJPf83HHyHv85x0XetZqqN+wS8qvI/2fdAG4mSWPXw8=; b=gnVgC+mQ0nKrTcCTBliI7eiFNYV5ryzC+p61d6AazzQES3xkHDum2uu/G+DoYehpPV nphYLFclfpTtWahtH0Qt2IyXNapxmxFbnlmTyssf6mDm9WkqBSxchayimB5NP/VrL8KG kgFbetL44nPVpeDUgfl6KjAnpeoBv0g2VnYsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=oYI0o+ktu5aof8sk9pGjJRsbDJh8lkRdd9s59fVzUhJCrYi4XPqrUwbOvdUMX6YkZo DqvJZb10OXhd7QZL0tdDZUv0nx+xqZdU3rUmmkS9+x7c0zX2fpLGXtpC5lqdUeCTuhnk 282hWUwT0D4d0KO1TNv2hWqqX3u8hoaVWn1rI= Received: by 10.66.250.1 with SMTP id x1mr517391ugh.4.1222625173134; Sun, 28 Sep 2008 11:06:13 -0700 (PDT) Received: by 10.66.251.1 with HTTP; Sun, 28 Sep 2008 11:06:13 -0700 (PDT) Message-ID: <7d6fde3d0809281106o331a495cg8d5c3c65c521af12@mail.gmail.com> Date: Sun, 28 Sep 2008 11:06:13 -0700 From: "Garrett Cooper" To: "William LeFebvre" In-Reply-To: <48DFADF6.10504@lefebvre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080928054620.GA80250@k7.mavetju> <48DF3CFE.7@lissyara.su> <7d6fde3d0809280209i3003829bj23baa93f0b271163@mail.gmail.com> <20080928112538.GC13745@k7.mavetju> <48DFADF6.10504@lefebvre.org> Cc: Alex Keda , Edwin Groothuis , stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 18:06:16 -0000 On Sun, Sep 28, 2008 at 9:16 AM, William LeFebvre wrote: > Edwin Groothuis wrote: >> >> On Sun, Sep 28, 2008 at 02:09:00AM -0700, Garrett Cooper wrote: >>> >>> On Sun, Sep 28, 2008 at 1:14 AM, Alex Keda wrote: >>>> >>>> Some strange. Count running processes not match with system top >> >> That has been explained in an email before. >> >>> I'm not sure I'm finding an issue, but I do find it interesting that... >>> 1. It takes a reasonably long amount of time for top to plateau the >>> WCPU field (approximately 8-10 iterations), whereas ps registering the >>> WCPU percentage value is almost instantaneous. > > Top 3.8 doesn't display WCPU. It is an antequated measure that is only > maintained by the kernel so that ps can display it. It no longer has any > meaning to the scheduler, so why bother displaying it. > >> >> With ps it takes 10 2 second steps to get the WCPU from 0 to 100, >> with the new top (which doesn't have WCPU (See Changes file, and >> the m_freebsd.c file, I don't know of the real reason behind it) >> anymore) goes from 0 to 100 in 2 2 second steps. > > ps shows a decaying average as calculated by the kernel over the past minute > and recorded in the proc structure. Top calculates its own average based on > the difference in cpu time between the last measurement and the current > measurement. The output from ps is fine when you want a single snapshot: > you want it to show information averaged over a long period of time. Top is > showing you only what's going on right now, since the last update. That's > why percent CPU in top will climb to its final value so quickly. > > Bill LeFebvre Actually, I was trying to say it was the other way around -- WCPU took a long time in top to climb to its final value where it took a short period of time with ps. Retrying that though, it appears that I was flip-flopping my statement and yes it aligns with Bill's. I still find the averaging discrepancy a bit interesting, but it's merely a function of how the average is being taken. -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 18:13:00 2008 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 A945C1065686 for ; Sun, 28 Sep 2008 18:13:00 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id D4D728FC23 for ; Sun, 28 Sep 2008 18:12:59 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1157640fgb.35 for ; Sun, 28 Sep 2008 11:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=noOWmJCax9gB5O+ojrhLnbWZ1dfvKEtKnZfz42WWl/4=; b=CYlyJr1XQAXUL9esvCX78GqmUZYOV/QBwlOB9gfYvv6AAsC3wFbX94S4ESPVtnEHdm bpcUIUayGaVG08C36gmW7TCJApHukJKHLYkLzy+mvogAptaY0CfexdR5niJ/QTt8Zt18 LEvN1ytPBUoi2ho12apKsqV9ytEgJELU7+zz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Fk8WjfeaVeV5KQYvaxyCtpHOUIzyCBs8sdlxHZq3zg6LsUluTr3pk/7PgAurGDSqMi k54Y6s5D9fe0pcG3PlOWqVxgoBIfgSdVn0+xK5e+gUpfjFOfwQKQ7a7ssx8MAbL1OU5a VIktMN/RvYMhWBN3H6nIgXq9Fhci0qEnGqQU8= Received: by 10.86.95.20 with SMTP id s20mr3366571fgb.65.1222623792923; Sun, 28 Sep 2008 10:43:12 -0700 (PDT) Received: by 10.86.82.4 with HTTP; Sun, 28 Sep 2008 10:43:12 -0700 (PDT) Message-ID: Date: Sun, 28 Sep 2008 13:43:12 -0400 From: "firmdog@gmail.com" To: "Arno J. Klaassen" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 18:13:00 -0000 I have the same problem on a Dell Poweredge SC440 when I transferred over 50GB from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable and the link was 1000 full duplex, but could only get about 10M/s. Very odd. Did a tcpdump and saw lots of bad checksum errors. What other troubleshooting steps can we take? What could be the problem? [root@gray ~]# uname -a FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Sep 2 02:27:56 EDT 2008 andy@gray.home:/usr/obj/usr/src/sys/GENERIC i386 pciconf showing the NIC: bge0@pci0:5:0:0: class=0x020000 card=0x01df1028 chip=0x167a14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5754 Broadcom NetXtreme Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint from sysctl dev.bge.0.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0xb002 dev.bge.0.%driver: bge dev.bge.0.%location: slot=0 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x167a subvendor=0x1028 subdevice=0x01df class=0x020000 dev.bge.0.%parent: pci5 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: bge0 dev.brgphy.0.%desc: BCM5787 10/100/1000baseTX PHY On Sat, Sep 27, 2008 at 5:21 PM, Arno J. Klaassen wrote: > > > Hello, > > I've serious network performance problems on a HP Turion X2 > based brand new notebook; I only used a 7-1Beta CD and > 7-STABLE on this thing. > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > # scp -p ports.tgz login@mv:/tmp/ > ports.tgz 100% 98MB 88.7KB/s 18:49 > > (doing the same thing by copy from an nfs-mounted disk even > takes mores than an hour ...) > > > Doing a top(1) aside, just shows the box 100% idle : > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > I tested : > > Update Bios > ULE /4BSD > PREEMPTION on/off > PREEMPTION + IPI_PREEMPTION > hw.nfe.msi[x]_disable=1 > > All don't seem to matter to the problem. > > I put two tcpdumps (server and client during another scp(1) ) on > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > lots of sequences like : > > TCP Previous segment lost > TCP Duplicate ACK 1 > TCP Window update > TCP Duplicate ACK 2 > TCP Duplicate ACK 3 > TCP Duplicate ACK 4 > TCP Duplicate ACK 5 > TCP Fast retransmission (suspected) > TCP ... > TCP Out-of-Order segment > TCP ... > > > As usual, feel free to contact me for further info/tests. > > Thanx, Arno > > ##### uname -a > FreeBSD mv 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 > CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON amd64 > > ##### pciconf -lcv (bits) > nfe0@pci0:0:6:0: class=0x020000 card=0x30cf103c chip=0x045010de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP65 Ethernet' > class = network > subclass = ethernet > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > ##### dmesg -a > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 > root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON > Timecounter "i8254" frequency 1193250 Hz quality 0 > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-62 (2109.70-MHz K8-class > CPU) > Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > usable memory = 3210813440 (3062 MB) > avail memory = 3104542720 (2960 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > ACPI Error (dsopcode-0671): Field [I9MN] at 544 exceeds Buffer [IORT] size > 464 (bits) [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT > ACPI Error (uteval-0309): Method execution failed > [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT > can't fetch resources for \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 25000000 Hz quality 900 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: port 0x1d00-0x1dff at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > pci0: at device 1.3 (no driver attached) > ohci0: mem 0xf2486000-0xf2486fff irq 18 at > device 2.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 10 ports with 10 removable, self powered > ehci0: mem 0xf2488000-0xf24880ff irq 17 > at device 2.1 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb1: EHCI version 1.0 > usb1: companion controller, 10 ports each: usb0 > usb1: on ehci0 > usb1: USB revision 2.0 > uhub1: on usb1 > uhub1: 10 ports with 10 removable, self powered > ugen0: on uhub1 > nfe0: port 0x30e0-0x30e7 mem > 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 > miibus0: on nfe0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: Ethernet address: 00:1e:68:5a:d2:e1 > nfe0: [FILTER] > pci0: at device 7.0 (no driver attached) > pcib1: at device 8.0 on pci0 > pci_link0: BIOS IRQ 15 for 7.5.INTA is invalid > pci_link1: BIOS IRQ 10 for 7.5.INTB is invalid > pci7: on pcib1 > fwohci0: <1394 Open Host Controller Interface> irq 9 at device 5.0 on pci7 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:24:1b:00:a1:b7:e8:00 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:24:1b:b7:e8:00 > fwe0: Ethernet address: 02:24:1b:b7:e8:00 > fwip0: on firewire0 > fwip0: Firewire address: 00:24:1b:00:a1:b7:e8:00 @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x2550000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > pci7: at device 5.1 (no driver attached) > pci7: at device 5.2 (no driver attached) > pci7: at device 5.3 (no driver attached) > pci7: at device 5.4 (no driver attached) > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 9.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x30f8-0x30ff,0x30ec-0x30ef,0x30f0-0x30f7,0x30e8-0x30eb,0x30d0-0x30df mem > 0xf2484000-0xf2485fff irq 23 at device 10.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pcib2: at device 11.0 on pci0 > pci1: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > ath0: mem 0xf2000000-0xf200ffff irq 16 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 13 > device_attach: ath0 attach returned 6 > pcib4: at device 13.0 on pci0 > pci5: on pcib4 > vgapci0: port 0x4000-0x407f mem > 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 19 at > device 0.0 on pci5 > pcib5: at device 14.0 on pci0 > pci9: on pcib5 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > acpi_tz0: _CRT value is absurd, ignored (-72.6C) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > powernow1: on cpu1 > orm0: at iomem 0xcd800-0xcefff,0xdf000-0xdffff on isa0 > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > acpi_tz0: _CRT value is absurd, ignored (-72.6C) > acd0: DVDR at ata0-master PIO4 > ad4: 305245MB at ata2-master UDMA33 > GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. > SMP: AP CPU #1 Launched! > GEOM_LABEL: Label for provider ad4s2 is ntfs/HP_RECOVERY. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 19:34:11 2008 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 5AF62106568E for ; Sun, 28 Sep 2008 19:34:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 3A94E8FC22 for ; Sun, 28 Sep 2008 19:34:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id LE5l1a0040cQ2SLAAKa9jn; Sun, 28 Sep 2008 19:34:09 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id LKa81a0074v8bD78WKa8nq; Sun, 28 Sep 2008 19:34:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=93IlrX9DObQA:10 a=a8CEgAfaXG8A:10 a=QycZ5dHgAAAA:8 a=bMJF0UsA7vhHUt_X8k8A:9 a=-G0fBKpj0NZvCUqWLukA:7 a=27OSlf4H3XoqHv79VGbPuVRILpYA:4 a=EoioJ0NPDVgA:10 a=uftxnXm4Q1MA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id B5721C9437; Sun, 28 Sep 2008 12:34:07 -0700 (PDT) Date: Sun, 28 Sep 2008 12:34:07 -0700 From: Jeremy Chadwick To: Julian Stacey Message-ID: <20080928193407.GA87069@icarus.home.lan> References: <200809261754.m8QHs41D011762@fire.js.berklix.net> <200809280921.m8S9LJtA030248@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809280921.m8S9LJtA030248@fire.js.berklix.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: pyunyh@gmail.com, stable@freebsd.org, Abdullah Ibn Hamad Al-Marri Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 28 Sep 2008 19:34:11 -0000 On Sun, Sep 28, 2008 at 11:21:19AM +0200, Julian Stacey wrote: > Hi, > Reference: > > From: "Julian Stacey" > > Date: Fri, 26 Sep 2008 19:54:04 +0200 > > Message-id: <200809261754.m8QHs41D011762@fire.js.berklix.net> > > "Julian Stacey" wrote: > > Hi, > > Reference: > > > From: "Julian Stacey" > > > Date: Fri, 26 Sep 2008 19:16:57 +0200 > > > Message-id: <200809261717.m8QHGvmx011312@fire.js.berklix.net> > > > > "Julian Stacey" wrote: > > > > > I'm remaking binaries, > > > > > > New generic kernel built & installed, & install of all src/ done too. > > > No improvement. > > > > > > > Is there reliable way to reproduce the issue? > > > > > > Its continuous, the machine virtually never does a ping in less > > > than 10 seconds. > > > > > > > Anyway, would you try attached patch and let me know result? > > > > > > Thanks > > > Done, doesnt help. > > > Seeing a new message now too: > > > ping: sendto: No buffer space available. > > > > > > Output of vmstat -i and pciconf -lv look the same as before > > > > > > It's a small card. Weighs 46 gram. I was going to write > > > I could simply post it to you, & you could keep it if you > > > want. As I had quessed it might be some new kind of card > > > unexperienced before, > > > RTL8139D, card just says made in China > > > > > > But I just grabbed another card > > > card says Level One. > > > chip 8139B > > > & with both patched kernel & original no improvement. > > > So I tried a totaly different card xl0 fails too, > > > I think that 3com xl0 card was OK before in another box, > > > so I'd guess not an rl problem, Sorry. > > > > > > Probably not 7.1 either, but probably a BIOS config problem of some sort. > > > > > > IRQ 12 was listed in Award BIOS as Primary, options were also secondary or disabled, so Ive set it disabled. > > > PNP OS Yes > > > Resources: Auto > > > "Reset config data" to Enabled (I forgot before after card changes) > > > > > > Did another restore BIOS factory defaults, no help. > > > Moved xl0 to another slot (all other 3 slots never use I guess, as > > > chassis plates not torn off on what I guess is original chassis. > > > No luck with xl0 > > > I'm out of ideas. > > > > Got it working on xl > > interrupt problem, I turned off lpt com2 & something else > > in bios. > > Got to go out now > > Ill go back to rl0 too & report back soon > > thanks for help both ! > > I'm wrong it is Not working. > (I typed my own own card address of 192.168.x.x by mistake, > not the 192.168.x.x of another host on net. ) > > Ive fiddled more with BIOS IRQ to no good effect > (not suprsing, dont understand some options in BIOS & no > MOtherboard manual for this Award BIOS 2A6LGB09, on box: > fujitsu siemens t-bird > > I was wondering if setting anything to polling might help a bit > I went looking with syctl -a -d | grep hw.pci > > hw.pci.enable_msi: 1 > hw.pci.enable_msi: Enable support for MSI interrupts > hw.pci.enable_msix: 1 > hw.pci.enable_msix: Enable support for MSI-X interrupts You could try disabling MSI and MSI-X in loader.conf to see if that makes a difference. hw.pci.enable_msi="0" hw.pci.enable_msix="0" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 19:35:12 2008 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 DA7391065749 for ; Sun, 28 Sep 2008 19:35:12 +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 BDD4F8FC27 for ; Sun, 28 Sep 2008 19:35:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id LGdo1a00e0lTkoCA7KbCWk; Sun, 28 Sep 2008 19:35:12 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id LKbB1a0074v8bD78QKbBSk; Sun, 28 Sep 2008 19:35:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=g3XWG8PL9CAA:10 a=qSlgtixbqsUA:10 a=QycZ5dHgAAAA:8 a=nNU62_RgrPhi-SKxFK4A:9 a=Op30DxwxTIN7Sr_AjyOAHlqssIMA:4 a=EoioJ0NPDVgA:10 a=MSl-tDqOz04A:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 3DF02C9437; Sun, 28 Sep 2008 12:35:11 -0700 (PDT) Date: Sun, 28 Sep 2008 12:35:11 -0700 From: Jeremy Chadwick To: "firmdog@gmail.com" Message-ID: <20080928193511.GB87069@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 19:35:12 -0000 On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > I have the same problem on a Dell Poweredge SC440 when I transferred over > 50GB > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable > and > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > Did a tcpdump and saw lots of bad checksum errors. This is probably because checksum offloading was being done on the NIC. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 19:38:26 2008 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 C0990106569E for ; Sun, 28 Sep 2008 19:38:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id A32508FC0C for ; Sun, 28 Sep 2008 19:38:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id LFv61a0040lTkoCA4KeS6P; Sun, 28 Sep 2008 19:38:26 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id LKeR1a0054v8bD78QKeRLR; Sun, 28 Sep 2008 19:38:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=wIrXrgXpJz8A:10 a=b5xO3WxKXmYA:10 a=QycZ5dHgAAAA:8 a=kRwEDuW2R94pCO7StkIA:9 a=UHiXciE0-6JnMd1ZOvkA:7 a=h1KXqEkK6E93fzXFo8jfdLYmc6UA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5BB67C9432; Sun, 28 Sep 2008 12:38:25 -0700 (PDT) Date: Sun, 28 Sep 2008 12:38:25 -0700 From: Jeremy Chadwick To: Nikola Le??i?? Message-ID: <20080928193825.GC87069@icarus.home.lan> References: <20080928054620.GA80250@k7.mavetju> <20080928142409.19f94e5b@anthesphoria.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928142409.19f94e5b@anthesphoria.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-current@FreeBSD.org, FreeBSD-stable@FreeBSD.org, Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 19:38:26 -0000 On Sun, Sep 28, 2008 at 02:24:09PM +0200, Nikola Le??i?? wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > On Sun, 28 Sep 2008 15:46:20 +1000 > Edwin Groothuis wrote: > > > Please report any issues with it (compile time, run time) and a way > > to reproduce it (if possible). Thanks for your help! > > FreeBSD black 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep 11 > 15:05:17 CEST 2008 nikola@black:/usr/obj/usr/src/sys/GENERIC i386 > > Core2Quad Q6600, 2G RAM, compiling mplayer, in H mode I got this: > > last pid: 70762; load avg: 1.22, 0.54, 0.33; up 0+16:48:11 14:08:01 > 177 threads: 11 running, 147 sleeping, 19 waiting > CPU: 27.6% user, 0.0% nice, 3.3% system, 0.7% interrupt, 68.4% idle > Kernel: 246626 ctxsw, 5063 trap, 362 intr, 354 soft, 5 fork, 4591 flt, 728 fr > Mem: 891M Active, 774M Inact, 233M Wired, 89M Cache, 112M Buf, 3668K Free > Swap: 4096M Total, 4096M Free > > PID USERNAME PRI NICE SIZE RES STATE FLG C TIME CPU COMMAND > 70729 root 104 0 74M 72M CPU2 + 2 0:05 100.64% cc1 > 47252 nikola 53 0 379M 84M RUN + 0 21:20 8.34% Xorg > 47290 nikola 44 0 59M 46M CPU3 + 1 7:06 1.81% compiz > 47972 nikola 44 0 112M 61M select s 3 11:09 1.15% amule > 70730 root -8 0 2912K 1592K piperd + 0 0:00 0.92% as > 47579 nikola 44 0 66M 23M CPU0 3 0:23 0.46% Terminal > 47547 nikola 45 0 332M 251M RUN 1 6:58 0.39% firefox-bin > 17027 nikola 96 0 26M 23M RUN + 3 1:30 0.38% conky > 61107 nikola 4 0 47M 18M select s 1 0:01 0.28% mousepad > 47284 nikola 44 0 14M 7844K select s 2 0:17 0.21% gnome-screensaver > 861 root 44 0 3268K 896K select s 0 0:12 0.21% moused > 47263 nikola 44 0 21M 13M select s 0 0:12 0.21% scim-panel-gtk > 47296 nikola 44 0 45M 15M select + 3 0:15 0.17% xfce4-panel > 47299 nikola 44 0 17M 11M select + 2 1:20 0.16% xfce4-netload-plugi > 47547 nikola 44 0 332M 251M ucond 0 0:54 0.11% firefox-bin > 47310 nikola 44 0 27M 20M select s 2 0:32 0.07% emerald > 986 haldaemon 44 0 6812K 4004K select s 3 0:27 0.07% hald > 23567 nikola 44 0 6744K 3788K select s 0 0:18 0.06% scim-launcher > 67253 nikola 44 0 45M 33M select s 3 0:34 0.05% skype > 53739 nikola 44 0 45M 35M select + 2 0:34 0.05% compiz > 47263 nikola 44 0 21M 13M select s 0 0:20 0.05% scim-panel-gtk > > Is it normal to have 100.64% for cc1? I would assume so, as your machine has more than one logical or physical processor. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 19:40:15 2008 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 81C44106568D for ; Sun, 28 Sep 2008 19:40:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD108FC0C for ; Sun, 28 Sep 2008 19:40:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA02.westchester.pa.mail.comcast.net with comcast id LDvF1a0011HzFnQ52KfuDq; Sun, 28 Sep 2008 19:39:54 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA14.westchester.pa.mail.comcast.net with comcast id LKgD1a00B4v8bD73aKgD5Z; Sun, 28 Sep 2008 19:40:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=74NTvyJymNFOJEXKzbsA:9 a=p3bug3tqHF2qleO9EKc_VGzz4X8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 3EB46C9432; Sun, 28 Sep 2008 12:40:13 -0700 (PDT) Date: Sun, 28 Sep 2008 12:40:13 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080928194013.GD87069@icarus.home.lan> References: <48DFC3F9.1040909@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DFC3F9.1040909@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: Blacklisted ACPI Prevents Boot 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, 28 Sep 2008 19:40:15 -0000 On Sun, Sep 28, 2008 at 10:50:49AM -0700, Jason C. Wells wrote: > I just installed a 6.4-PRERELEASE kernel and tried to boot. The boot > failed with a message that my ACPI was blacklisted. I have had 'device > acpi' in my kernel for some time now. The boot interruption is new > behavior. > > Is this sort of change a good thing to put in UPDATING? Please read the following thread, which includes a patch for the mistake. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45080 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045080.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 20:08:06 2008 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 275B91065689; Sun, 28 Sep 2008 20:08:06 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from photon.ws-e.net (photon.ws-e.com [64.34.164.166]) by mx1.freebsd.org (Postfix) with ESMTP id C66A68FC0A; Sun, 28 Sep 2008 20:08:05 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (adsl-074-166-023-150.sip.asm.bellsouth.net [74.166.23.150]) by photon.ws-e.net (8.13.8/8.13.8) with ESMTP id m8SJkqOj026424; Sun, 28 Sep 2008 19:46:52 GMT Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.14.2/8.14.2) with ESMTP id m8SJko4d055518; Sun, 28 Sep 2008 15:46:50 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <48DFDF25.2090905@lefebvre.org> Date: Sun, 28 Sep 2008 15:46:45 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jeremy Chadwick References: <20080928054620.GA80250@k7.mavetju> <20080928142409.19f94e5b@anthesphoria.net> <20080928193825.GC87069@icarus.home.lan> In-Reply-To: <20080928193825.GC87069@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.63 on 192.168.0.4 Cc: FreeBSD-stable@freebsd.org, FreeBSD-current@freebsd.org, Nikola Le??i?? , Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 20:08:06 -0000 Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 02:24:09PM +0200, Nikola Le??i?? wrote: >> Is it normal to have 100.64% for cc1? > > I would assume so, as your machine has more than one logical or > physical processor. > No, that was a per-thread display he posted. Altho undesirable I can come up with some plausible reasons why it is exceeding 100%, all related to the uncertainty of trying to perform accurate measurements on a moving target. I suppose I could cap the percentage at 100 just for aesthetic reasons, and to keep it from overflowing the column. Bill From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 20:40:13 2008 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 86D641065697 for ; Sun, 28 Sep 2008 20:40:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5C78FC0A for ; Sun, 28 Sep 2008 20:40:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA07.westchester.pa.mail.comcast.net with comcast id LCKn1a00A0mv7h057LgCc3; Sun, 28 Sep 2008 20:40:12 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.westchester.pa.mail.comcast.net with comcast id LLfq1a00A4v8bD73XLfqu8; Sun, 28 Sep 2008 20:39:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=wIrXrgXpJz8A:10 a=b5xO3WxKXmYA:10 a=QycZ5dHgAAAA:8 a=tJ3oSUeKtVL2c4irxikA:9 a=fSiy2mOVJCzVYT8KiTC_natzTbQA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 2060BC9432; Sun, 28 Sep 2008 13:40:04 -0700 (PDT) Date: Sun, 28 Sep 2008 13:40:04 -0700 From: Jeremy Chadwick To: William LeFebvre Message-ID: <20080928204004.GB87271@icarus.home.lan> References: <20080928054620.GA80250@k7.mavetju> <20080928142409.19f94e5b@anthesphoria.net> <20080928193825.GC87069@icarus.home.lan> <48DFDF25.2090905@lefebvre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DFDF25.2090905@lefebvre.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-stable@freebsd.org, FreeBSD-current@freebsd.org, Nikola Le??i?? , Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 20:40:13 -0000 On Sun, Sep 28, 2008 at 03:46:45PM -0400, William LeFebvre wrote: > Jeremy Chadwick wrote: >> On Sun, Sep 28, 2008 at 02:24:09PM +0200, Nikola Le??i?? wrote: > >>> Is it normal to have 100.64% for cc1? >> >> I would assume so, as your machine has more than one logical or >> physical processor. >> > > No, that was a per-thread display he posted. Altho undesirable I can > come up with some plausible reasons why it is exceeding 100%, all > related to the uncertainty of trying to perform accurate measurements on > a moving target. I suppose I could cap the percentage at 100 just for > aesthetic reasons, and to keep it from overflowing the column. Ah ha. That could also explain why gstat(8) has the same problem (%busy column occasionally being >100, sometimes 102-103%). A simple & 100 on the displayed value should suffice, yep. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 20:53:01 2008 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 BEDAE1065694; Sun, 28 Sep 2008 20:53:01 +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 9354E8FC1A; Sun, 28 Sep 2008 20:53:01 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Kk3GG-000Kju-Fn; Sun, 28 Sep 2008 16:53:00 -0400 Date: Sun, 28 Sep 2008 16:53:00 -0400 From: Gary Palmer To: "firmdog@gmail.com" Message-ID: <20080928205300.GF60230@in-addr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 20:53:01 -0000 On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > I have the same problem on a Dell Poweredge SC440 when I transferred over > 50GB > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable > and > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > Did a > tcpdump and saw lots of bad checksum errors. > > What other troubleshooting steps can we take? What could be the problem? Please post the first few lines of ifconfig for bge0. I'm suspecting you'll see something like em1: flags=8843 mtu 1500 options=1b (yes, I know thats an em, not bge, but I don't have any bge's around here) Note that the options line say that receive and transmit checksum offloading is enabled. This means that for packets transmitted by this system, tcpdump will show checksum errors as the kernel is not generating the checksums, the ethernet card will. Since tcpdump is seeting the packet before the ethernet card does its magic, you get the checksum errors on transmit. Received packets should be fine though. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 21:15:57 2008 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 2152A1065695; Sun, 28 Sep 2008 21:15:57 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id B487E8FC19; Sun, 28 Sep 2008 21:15:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 63BA030126; Sun, 28 Sep 2008 22:15:53 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from tau.draftnet (tau.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTP; Sun, 28 Sep 2008 22:15:53 +0100 (BST) Date: Sun, 28 Sep 2008 22:15:32 +0100 From: Bruce Cran To: Edwin Groothuis Message-ID: <20080928221532.0e692490@tau.draftnet> In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 21:15:57 -0000 On Sun, 28 Sep 2008 15:46:20 +1000 Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > [...] > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > There are some new warnings generated during compilation with WARNS=1 due to the use of -DSIGWINCH on the command line (since it has already been defined in signal.h). Though of course it doesn't have any effect on the functionality. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 21:37:05 2008 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 05110106564A; Sun, 28 Sep 2008 21:37:05 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service2.sh.cvut.cz (unknown [IPv6:2001:718:2:0:217:a4ff:fe3f:b3d4]) by mx1.freebsd.org (Postfix) with ESMTP id ECA6E8FC08; Sun, 28 Sep 2008 21:37:02 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service2.sh.cvut.cz (Postfix) with ESMTP id 6DEF23BE28; Sun, 28 Sep 2008 23:37:00 +0200 (CEST) Received: from service2.sh.cvut.cz ([127.0.0.1]) by localhost (service2.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24810-07; Sun, 28 Sep 2008 23:36:51 +0200 (CEST) Received: from [192.168.1.2] (35.201.broadband4.iol.cz [85.71.201.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service2.sh.cvut.cz (Postfix) with ESMTP id 4629B3BE27; Sun, 28 Sep 2008 23:36:49 +0200 (CEST) Message-ID: <48DFF8EC.1040307@sh.cvut.cz> Date: Sun, 28 Sep 2008 23:36:44 +0200 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: William LeFebvre References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> <20080928115401.GU3210@k7.mavetju> <48DFB0DA.1000907@lefebvre.org> In-Reply-To: <48DFB0DA.1000907@lefebvre.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig92A7C642745FCAF55FD30F86" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at service2.sh.cvut.cz X-Spam-Status: No, hits=2.4 tagged_above=-255.0 required=5.0 tests=AWL, BOTNET, CRM114_HAM_00, JR_RCVD_HOST_PROBS1, JR_RCVD_TOO_FEW_HOPS X-Spam-Level: ** Cc: stable@freebsd.org, current@freebsd.org, Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 21:37:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92A7C642745FCAF55FD30F86 Content-Type: multipart/mixed; boundary="------------090308020800020406020106" This is a multi-part message in MIME format. --------------090308020800020406020106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable William LeFebvre wrote, On 28.9.2008 18:29: > Edwin Groothuis wrote: >> On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: >>>> to reproduce it (if possible). Thanks for your help! >>> Is this 7.0+ only? I run 6.3 and I see the following when I start it:= >>> >>> last pid: -1077944144; loa 0.52, 0.28, 0.26; >>> up >>> 11+15:31:33 11:33:05 >>> 0 processes: >>> CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% id= le >>> Kernel: 1 intr >>> Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M= >>> Free >>> Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse >>> sysctlnametomib: No such file or directory >>> >>> And no processes. >> >> I didn't expect it not to work on 6.x, I will play around with it >> tomorrow to see if it makes sense. >=20 > It worked on my 6.2 system. Was the binary compiled under 6.3? Yes. FreeBSD shell.sh.cvut.cz 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Fri Ja= n 18 17:04:16 CET 2008 root@shell.sh.cvut.cz:/usr/obj/usr/src/sys/SHELL-SM= P i386 >=20 > Unfortunately the error message didn't say *which* mib it couldn't find= =2E >=20 > Bill LeFebvre I am attaching strace and truss trace of few seconds of execution. -- VH --------------090308020800020406020106 Content-Type: text/plain; name="top.trace.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="top.trace.txt" ZXhlY3ZlKDB4YmZiZmUyMDAsIFsweGJmYmZlNmQ0XSwgWy8qIDAgdmFycyAqL10pID0gMA0K bW1hcCgwLCAzOTUyLCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX0FOT04sIC0xLCAwKSA9 IDB4MjgwODIwMDANCm11bm1hcCgweDI4MDgyMDAwLCAzOTUyKSAgICAgICAgICAgICAgICA9 IDANCl9fc3lzY3RsKFsuLi5dLCAweDI4MDdlYjk4LCAweGJmYmZlNDk0LCBOVUxMLCAwKSA9 IDANCm1tYXAoMCwgMzI3NjgsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxN QVBfQU5PTiwgLTEsIDApID0gMHgyODA4MjAwMA0KaXNzZXR1Z2lkKDB4MjgwNzgwNDQpICAg ICAgICAgICAgICAgICAgID0gMA0Kb3BlbigiL2V0Yy9saWJtYXAuY29uZiIsIE9fUkRPTkxZ KSAgICAgID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KYWNjZXNz KCIvaG9tZS91c2Vycy93aWx4L2xpYi9saWJuY3Vyc2VzLnNvLjYiLCBGX09LKSA9IC0xIEVO T0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkNCmFjY2VzcygiL3Vzci9sb2NhbC9s aWIvbGlibmN1cnNlcy5zby42IiwgRl9PSykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkpDQpvcGVuKCIvdmFyL3J1bi9sZC1lbGYuc28uaGludHMiLCBPX1JET05M WSkgPSAzDQpyZWFkKDMsICJSQUNFX0xPQURFRF9PQkpFQ1RTX0ZNVDJcMFx0JW8gKCV4Ii4u LiwgMTI4KSA9IDEyOA0KbHNlZWsoMywgMTI4LCBTRUVLX1NFVCkgICAgICAgICAgICAgICAg ID0gMTI4DQpyZWFkKDMsICIvbGliOi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4s IDM4NykgPSAzODcNCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9 IDANCmFjY2VzcygiL2xpYi9saWJuY3Vyc2VzLnNvLjYiLCBGX09LKSAgICA9IDANCm9wZW4o Ii9saWIvbGlibmN1cnNlcy5zby42IiwgT19SRE9OTFkpICA9IDMNCmZzdGF0KDMsIHtzdF9t b2RlPTAsIHN0X3NpemU9MCwgLi4ufSkgICA9IDANCnN5c2NhbGxfMzk3KDB4MywgMHhiZmJm ZTJhMCkgICAgICAgICAgICA9IDANCnJlYWQoMywgIlwxNzdFTEZcMVwxXDFcdFwwXDBcMFww XDBcMFwwXDBcM1wwXDNcMFwxXDBcMFwwYFwzNDRcMCIuLi4sIDQwOTYpID0gNDA5Ng0KbW1h cCgwLCAyNzQ0MzIsIFBST1RfUkVBRHxQUk9UX0VYRUMsIE1BUF9QUklWQVRFfE1BUF9OT0NP UkUsIDMsIDApID0gMHgyODA4YTAwMA0KbXByb3RlY3QoMHgyODBjMzAwMCwgNDA5NiwgUFJP VF9SRUFEfFBST1RfV1JJVEV8UFJPVF9FWEVDKSA9IDANCm1wcm90ZWN0KDB4MjgwYzMwMDAs IDQwOTYsIFBST1RfUkVBRHxQUk9UX0VYRUMpID0gMA0KbW1hcCgweDI4MGM0MDAwLCAzMjc2 OCwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9GSVhFRCwgMywgMHgz YTAwMCkgPSAweDI4MGM0MDAwDQptbWFwKDB4MjgwY2MwMDAsIDQwOTYsIFBST1RfUkVBRHxQ Uk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0FOT04sIC0xLCAwKSA9IDB4 MjgwY2MwMDANCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAN CmFjY2VzcygiL2hvbWUvdXNlcnMvd2lseC9saWIvbGlibS5zby40IiwgRl9PSykgPSAtMSBF Tk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpDQphY2Nlc3MoIi91c3IvbG9jYWwv bGliL2xpYm0uc28uNCIsIEZfT0spID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5KQ0KYWNjZXNzKCIvbGliL2xpYm0uc28uNCIsIEZfT0spICAgICAgICAgID0gMA0K b3BlbigiL2xpYi9saWJtLnNvLjQiLCBPX1JET05MWSkgICAgICAgID0gMw0KZnN0YXQoMywg e3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAuLi59KSAgID0gMA0Kc3lzY2FsbF8zOTcoMHgzLCAw eGJmYmZlMmEwKSAgICAgICAgICAgID0gMA0KcmVhZCgzLCAiXDE3N0VMRlwxXDFcMVx0XDBc MFwwXDBcMFwwXDBcMFwzXDBcM1wwXDFcMFwwXDBcMzA0I1wwIi4uLiwgNDA5NikgPSA0MDk2 DQptbWFwKDAsIDkwMTEyLCBQUk9UX1JFQUR8UFJPVF9FWEVDLCBNQVBfUFJJVkFURXxNQVBf Tk9DT1JFLCAzLCAwKSA9IDB4MjgwY2QwMDANCm1wcm90ZWN0KDB4MjgwZTEwMDAsIDQwOTYs IFBST1RfUkVBRHxQUk9UX1dSSVRFfFBST1RfRVhFQykgPSAwDQptcHJvdGVjdCgweDI4MGUx MDAwLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9FWEVDKSA9IDANCm1tYXAoMHgyODBlMjAwMCwg NDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9GSVhFRCwgMywg MHgxNDAwMCkgPSAweDI4MGUyMDAwDQpjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPSAwDQphY2Nlc3MoIi9ob21lL3VzZXJzL3dpbHgvbGliL2xpYmt2bS5zby4z IiwgRl9PSykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpDQphY2Nl c3MoIi91c3IvbG9jYWwvbGliL2xpYmt2bS5zby4zIiwgRl9PSykgPSAtMSBFTk9FTlQgKE5v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpDQphY2Nlc3MoIi9saWIvbGlia3ZtLnNvLjMiLCBG X09LKSAgICAgICAgPSAwDQpvcGVuKCIvbGliL2xpYmt2bS5zby4zIiwgT19SRE9OTFkpICAg ICAgPSAzDQpmc3RhdCgzLCB7c3RfbW9kZT0wLCBzdF9zaXplPTAsIC4uLn0pICAgPSAwDQpz eXNjYWxsXzM5NygweDMsIDB4YmZiZmUyYTApICAgICAgICAgICAgPSAwDQpyZWFkKDMsICJc MTc3RUxGXDFcMVwxXHRcMFwwXDBcMFwwXDBcMFwwXDNcMFwzXDBcMVwwXDBcMFwzNFwyMVww Ii4uLiwgNDA5NikgPSA0MDk2DQptbWFwKDAsIDMyNzY4LCBQUk9UX1JFQUR8UFJPVF9FWEVD LCBNQVBfUFJJVkFURXxNQVBfTk9DT1JFLCAzLCAwKSA9IDB4MjgwZTMwMDANCm1wcm90ZWN0 KDB4MjgwZTkwMDAsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFfFBST1RfRVhFQykgPSAw DQptcHJvdGVjdCgweDI4MGU5MDAwLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9FWEVDKSA9IDAN Cm1tYXAoMHgyODBlYTAwMCwgNDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklW QVRFfE1BUF9GSVhFRCwgMywgMHg2MDAwKSA9IDB4MjgwZWEwMDANCmNsb3NlKDMpICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IDANCmFjY2VzcygiL2hvbWUvdXNlcnMvd2ls eC9saWIvbGliYy5zby42IiwgRl9PSykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnkpDQphY2Nlc3MoIi91c3IvbG9jYWwvbGliL2xpYmMuc28uNiIsIEZfT0spID0g LTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KYWNjZXNzKCIvbGliL2xp YmMuc28uNiIsIEZfT0spICAgICAgICAgID0gMA0Kb3BlbigiL2xpYi9saWJjLnNvLjYiLCBP X1JET05MWSkgICAgICAgID0gMw0KZnN0YXQoMywge3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAu Li59KSAgID0gMA0Kc3lzY2FsbF8zOTcoMHgzLCAweGJmYmZlMmEwKSAgICAgICAgICAgID0g MA0KcmVhZCgzLCAiXDE3N0VMRlwxXDFcMVx0XDBcMFwwXDBcMFwwXDBcMFwzXDBcM1wwXDFc MFwwXDBwXDM1M1wxIi4uLiwgNDA5NikgPSA0MDk2DQptbWFwKDAsIDk5NTMyOCwgUFJPVF9S RUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8TUFQX05PQ09SRSwgMywgMCkgPSAweDI4MGVi MDAwDQptcHJvdGVjdCgweDI4MWMxMDAwLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklURXxQ Uk9UX0VYRUMpID0gMA0KbXByb3RlY3QoMHgyODFjMTAwMCwgNDA5NiwgUFJPVF9SRUFEfFBS T1RfRVhFQykgPSAwDQptbWFwKDB4MjgxYzIwMDAsIDI0NTc2LCBQUk9UX1JFQUR8UFJPVF9X UklURSwgTUFQX1BSSVZBVEV8TUFQX0ZJWEVELCAzLCAweGQ2MDAwKSA9IDB4MjgxYzIwMDAN Cm1tYXAoMHgyODFjODAwMCwgOTAxMTIsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJ VkFURXxNQVBfRklYRUR8TUFQX0FOT04sIC0xLCAwKSA9IDB4MjgxYzgwMDANCmNsb3NlKDMp ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDANCnN5c2FyY2goMHhhLCAweGJm YmZlNTAwKSAgICAgICAgICAgICAgICA9IDANCm1tYXAoMCwgODA4LCBQUk9UX1JFQUR8UFJP VF9XUklURSwgTUFQX0FOT04sIC0xLCAwKSA9IDB4MjgxZGUwMDANCm11bm1hcCgweDI4MWRl MDAwLCA4MDgpICAgICAgICAgICAgICAgICA9IDANCm1tYXAoMCwgNDg2NCwgUFJPVF9SRUFE fFBST1RfV1JJVEUsIE1BUF9BTk9OLCAtMSwgMCkgPSAweDI4MWRlMDAwDQptdW5tYXAoMHgy ODFkZTAwMCwgNDg2NCkgICAgICAgICAgICAgICAgPSAwDQptbWFwKDAsIDE4NTYsIFBST1Rf UkVBRHxQUk9UX1dSSVRFLCBNQVBfQU5PTiwgLTEsIDApID0gMHgyODFkZTAwMA0KbXVubWFw KDB4MjgxZGUwMDAsIDE4NTYpICAgICAgICAgICAgICAgID0gMA0KbW1hcCgwLCA3MzYsIFBS T1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfQU5PTiwgLTEsIDApID0gMHgyODFkZTAwMA0KbXVu bWFwKDB4MjgxZGUwMDAsIDczNikgICAgICAgICAgICAgICAgID0gMA0KbW1hcCgwLCAyMjc4 NCwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9BTk9OLCAtMSwgMCkgPSAweDI4MWRlMDAw DQptdW5tYXAoMHgyODFkZTAwMCwgMjI3ODQpICAgICAgICAgICAgICAgPSAwDQpzaWdwcm9j bWFzayhTSUdfQkxPQ0ssIH5bSUxMIFRSQVAgQUJSVCBFTVQgRlBFIEJVUyBTRUdWIFNZU10s IFtdKSA9IDANCnNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLCBbXSwgTlVMTCkgICAgICA9IDAN Cl9fc3lzY3RsKFtzeXNjdGwuMF0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3N5c2N0bC4wXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbc3lz Y3RsLjBdLCAyLCAiUCIsIFsxXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbLTEyNzI0NDU0 Li02MzQ5MTEyM10sIDIsICJcMzc3XDUoXDIxMiIsIFszOTYyMDQ1OTUxXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbc3lzY3RsLjBdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCnJl YWRsaW5rKCIvZXRjL21hbGxvYy5jb25mIiwgMHhiZmJmZTA4MCwgNjMpID0gLTEgRU5PRU5U IChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KaXNzZXR1Z2lkKDB4MjgxYmEyNmYpICAg ICAgICAgICAgICAgICAgID0gMA0KbW1hcCgwLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklU RSwgTUFQX1BSSVZBVEV8TUFQX0FOT04sIC0xLCAwKSA9IDB4MjgxZGUwMDANCmJyZWFrKDB4 ODA1YzAwMCkgICAgICAgICAgICAgICAgICAgICAgICA9IDANCmJyZWFrKDB4ODA1ZDAwMCkg ICAgICAgICAgICAgICAgICAgICAgICA9IDANCmdldHRpbWVvZmRheSh7NDI5NDQ1MTU0Miwg NDI5NDQ1MTU0Mn0sIE5VTEwpID0gMA0KZnN0YXQoMSwge3N0X21vZGU9U19JRkNIUnwwNTI2 LCBzdF9yZGV2PW1ha2VkZXYoMzMsIDQyOTQ0NDMwOTQpLCAuLi59KSA9IDANCmJyZWFrKDB4 ODA1ZTAwMCkgICAgICAgICAgICAgICAgICAgICAgICA9IDANCl9fc3lzY3RsKFstNTE0ODMx Li01MTU3NTRdLCAyLCAiIiwgWzQyOTQ0NTI0NDddLCAia2Vybi5zbXAuY3B1cyIsIDEzKSA9 IDANCl9fc3lzY3RsKFsxOTE5MjQ5MTUuMTgzNjI2NTA3LjE2MzQ1NDUyNl0sIDMsICJzXDAv ZGV2L251bGxcMGtlcm4uYm9vdHRpbWVcMCBPdXQgbyIuLi4sIFsxOTcwMjk5NzY4XSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbMTcwMTY1MDUzLjIwMzc1NDI3Nl0sIDIsICJubm90IGhh cHBlblwwJSpzXDAlLSpzXDBURVJNXDAlczogY2EiLi4uLCBbMTYzMTc4MDg5N10sICJrZXJu LnNtcC5tYXhjcHVzIiwgMTYpID0gMA0KX19zeXNjdGwoWzE3MDEwNjQ0NC4xOTcwMTU1Mzgu MTc5NTE4OTg2XSwgMywgImJvb3R0aW1lXDAgT3V0IG9mIG1lbW9yeSFcMENhbm5vdCAiLi4u LCBbNzc4OTkwMTgxXSwgTlVMTCwgMCkgPSAwDQpicmVhaygweDgwNWYwMDApICAgICAgICAg ICAgICAgICAgICAgICAgPSAwDQpicmVhaygweDgwNjAwMDApICAgICAgICAgICAgICAgICAg ICAgICAgPSAwDQpfX3N5c2N0bChbMTg4NjQxMzE2LjYyMDc4NTI1M10sIDIsICIvYm9vdC9r ZXJuZWwva2VybmVsXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLCBbNjIwNzg2NDc0 XSwgTlVMTCwgMCkgPSAwDQpvcGVuKCIvZGV2L251bGwiLCBPX1JET05MWSkgICAgICAgICAg ICAgPSAzDQpmc3RhdCgzLCB7c3RfbW9kZT1TX0lGQkxLfFNfSVNVSUR8U19JU0dJRHwwMTU2 LCBzdF9yZGV2PW1ha2VkZXYoMTIxLCAxOTE0Njk5ODc0KSwgLi4ufSkgPSAwDQpmY250bCgz LCBGX1NFVEZELCBGRF9DTE9FWEVDKSAgICAgICAgICAgPSAwDQpvcGVuKCIvZGV2L251bGwi LCBPX1JET05MWSkgICAgICAgICAgICAgPSA0DQpfX3N5c2N0bChbMTg2OTQ4ODIyLjE4MzU2 MDYxM10sIDIsICJlbnRlZCBmb3IgZGVhZCBrZXJuZWxzXDAkRnJlZUJTRDoiLi4uLCBbMTgz NTM2MzQ0MF0sICJrZXJuLmJvb3R0aW1lIiwgMTMpID0gMA0KX19zeXNjdGwoWzE5NjgxMTk4 MC4xNzE4NTU4ODNdLCAyLCAib3J5IVwwQ2Fubm90IGhhcHBlblwwJSpzXDAlLSpzXDBURVJN Ii4uLiwgWzE4MzUzNjM2MTZdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFs5ODA2MjQ2NDAu MTg1MTg3NjEyXSwgMiwgIlwwXDIwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDAiLi4uLCBbMTg2NDM5Nzg2M10sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3N5c2N0bC4wXSwgMiwgIiIsIFswXSwgInZtLnN0YXRzLnN5cy52X3N3dGNoIiwg MjApID0gMA0KX19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAiXDJcMFwwXDBc MzIzXDNcMFwwXDMyNFwzXDBcMFwzMzBcM1wwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzIw Mzc1OTE2NjddLCAidm0uc3RhdHMuc3lzLnZfdHJhcCIsIDE5KSA9IDANCl9fc3lzY3RsKFs3 Nzg5MjU1NjguMTk1MjU0Mzg1XSwgMiwgIlwyXDBcMFwwXDMyM1wzXDBcMFwzMjRcM1wwXDBc MzMyXDNcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIFsyMDM3NTkxNjY3XSwgInZtLnN0YXRz LnN5cy52X2ludHIiLCAxOSkgPSAwDQpfX3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1NDM4NV0s IDIsICJcMlwwXDBcMFwzMjNcM1wwXDBcMzI0XDNcMFwwXDMzM1wzXDBcMFwwXDBcMFwwXDBc MFwwXDAiLi4uLCBbMjAzNzU5MTY2N10sICJ2bS5zdGF0cy5zeXMudl9zb2Z0IiwgMTkpID0g MA0KX19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAiXDJcMFwwXDBcMzIzXDNc MFwwXDMyNVwzXDBcMFwzNzdcM1wwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE4MzY0NjE2 ODNdLCAidm0uc3RhdHMudm0udl9mb3JrcyIsIDE5KSA9IDANCl9fc3lzY3RsKFs3Nzg5MjU1 NjguMTk1MjU0Mzg1XSwgMiwgIlwyXDBcMFwwXDMyM1wzXDBcMFwzMjVcM1wwXDBcMFw0XDBc MFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIFsxODM2NDYxNjgzXSwgInZtLnN0YXRzLnZtLnZf dmZvcmtzIiwgMjApID0gMA0KX19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAi XDJcMFwwXDBcMzIzXDNcMFwwXDMyNVwzXDBcMFwxXDRcMFwwXDBcMFwwXDBcMFwwXDBcMFww Ii4uLiwgWzE4MzY0NjE2ODNdLCAidm0uc3RhdHMudm0udl9yZm9ya3MiLCAyMCkgPSAwDQpf X3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1NDM4NV0sIDIsICJcMlwwXDBcMFwzMjNcM1wwXDBc MzI1XDNcMFwwXDMzNFwzXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLCBbMTgzNjQ2MTY4M10s ICJ2bS5zdGF0cy52bS52X3ZtX2ZhdWx0cyIsIDIzKSA9IDANCl9fc3lzY3RsKFs3Nzg5MjU1 NjguMTk1MjU0Mzg1XSwgMiwgIlwyXDBcMFwwXDMyM1wzXDBcMFwzMjVcM1wwXDBcMzQxXDNc MFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIFsxODM2NDYxNjgzXSwgInZtLnN0YXRzLnZtLnZf c3dhcGluIiwgMjApID0gMA0KX19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAi XDJcMFwwXDBcMzIzXDNcMFwwXDMyNVwzXDBcMFwzNDJcM1wwXDBcMFwwXDBcMFwwXDBcMFww Ii4uLiwgWzE4MzY0NjE2ODNdLCAidm0uc3RhdHMudm0udl9zd2Fwb3V0IiwgMjEpID0gMA0K X19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAiXDJcMFwwXDBcMzIzXDNcMFww XDMyNVwzXDBcMFwzNTdcM1wwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE4MzY0NjE2ODNd LCAidm0uc3RhdHMudm0udl90ZnJlZSIsIDE5KSA9IDANCl9fc3lzY3RsKFs3Nzg5MjU1Njgu MTk1MjU0Mzg1XSwgMiwgIlwyXDBcMFwwXDMyM1wzXDBcMFwzMjVcM1wwXDBcMzQ1XDNcMFww XDBcMFwwXDBcMFwwXDBcMCIuLi4sIFsxODM2NDYxNjgzXSwgInZtLnN0YXRzLnZtLnZfdm5v ZGVpbiIsIDIxKSA9IDANCl9fc3lzY3RsKFs3Nzg5MjU1NjguMTk1MjU0Mzg1XSwgMiwgIlwy XDBcMFwwXDMyM1wzXDBcMFwzMjVcM1wwXDBcMzQ2XDNcMFwwXDBcMFwwXDBcMFwwXDBcMCIu Li4sIFsxODM2NDYxNjgzXSwgInZtLnN0YXRzLnZtLnZfdm5vZGVvdXQiLCAyMikgPSAwDQpf X3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1NDM4NV0sIDIsICJcMlwwXDBcMFwzMjNcM1wwXDBc MzI1XDNcMFwwXDM2N1wzXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLCBbMTgzNjQ2MTY4M10s ICJ2bS5zdGF0cy52bS52X2FjdGl2ZV9jb3VudCIsIDI2KSA9IDANCl9fc3lzY3RsKFs3Nzg5 MjU1NjguMTk1MjU0Mzg1XSwgMiwgIlwyXDBcMFwwXDMyM1wzXDBcMFwzMjVcM1wwXDBcMzcx XDNcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIFsxODM2NDYxNjgzXSwgInZtLnN0YXRzLnZt LnZfaW5hY3RpdmVfY291bnQiLCAyOCkgPSAwDQpfX3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1 NDM4NV0sIDIsICJcMlwwXDBcMFwzMjNcM1wwXDBcMzI1XDNcMFwwXDM2NlwzXDBcMFwwXDBc MFwwXDBcMFwwXDAiLi4uLCBbMTgzNjQ2MTY4M10sICJ2bS5zdGF0cy52bS52X3dpcmVfY291 bnQiLCAyNCkgPSAwDQpfX3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1NDM4NV0sIDIsICJcMlww XDBcMFwzMjNcM1wwXDBcMzI1XDNcMFwwXDM3MlwzXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4u LCBbMTgzNjQ2MTY4M10sICJ2bS5zdGF0cy52bS52X2NhY2hlX2NvdW50IiwgMjUpID0gMA0K X19zeXNjdGwoWzc3ODkyNTU2OC4xOTUyNTQzODVdLCAyLCAiXDJcMFwwXDBcMzIzXDNcMFww XDMyNVwzXDBcMFwzNjVcM1wwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE4MzY0NjE2ODNd LCAidm0uc3RhdHMudm0udl9mcmVlX2NvdW50IiwgMjQpID0gMA0KX19zeXNjdGwoWzc3ODky NTU2OC4xOTUyNTQzODVdLCAyLCAiXDJcMFwwXDBcMzIzXDNcMFwwXDMyNVwzXDBcMFwzNDNc M1wwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE4MzY0NjE2ODNdLCAidm0uc3RhdHMudm0u dl9zd2FwcGdzaW4iLCAyMykgPSAwDQpfX3N5c2N0bChbNzc4OTI1NTY4LjE5NTI1NDM4NV0s IDIsICJcMlwwXDBcMFwzMjNcM1wwXDBcMzI1XDNcMFwwXDM0NFwzXDBcMFwwXDBcMFwwXDBc MFwwXDAiLi4uLCBbMTgzNjQ2MTY4M10sICJ2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXQiLCAy NCkgPSAwDQpfX3N5c2N0bChbMTkzNjA5NDcyLjE3MTg5Njg4N10sIDIsICJcM1wwXDBcMHlc MlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE2 NjczMzAxNjNdLCAidmZzLmJ1ZnNwYWNlIiwgMTIpID0gMA0KX19zeXNjdGwoWzE5MTkyNDkx NS4xODg1NTQ4MTRdLCAyLCAiXDFcMFwwXDBcMjMzXDFcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzE4MzU2Mjc2MTVdLCAia2Vybi5jcF90aW1lIiwg MTIpID0gMA0KX19zeXNjdGwoWzE5MTkyNDkxNS4xODg1NTQ4MTRdLCAyLCAweDgwNTc2OTQs IDB4YmZiZmUwYjAsICJrZXJuLmNwX3RpbWVzIiwgMTMpID0gLTEgRU5PRU5UIChObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5KQ0KYnJlYWsoMHg4MDYxMDAwKSAgICAgICAgICAgICAgICAg ICAgICAgID0gMA0KX19zeXNjdGwoWzE5MTkyNDkxNS4xOTE5OTU0NTRdLCAyLCAiXDJcMFww XDBcMzEwXDNcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwg WzE2MzA0MzAwNjNdLCAidm0uc3dhcF9pbmZvIiwgMTIpID0gMA0KYnJlYWsoMHg4MDY2MDAw KSAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYnJlYWsoMHg4MDY3MDAwKSAgICAgICAg ICAgICAgICAgICAgICAgID0gMA0KaW9jdGwoMSwgVElPQ0dFVEEsIHsweDZjNzQ2MzczIC8q IEI/Pz8gKi8gKGluKTB4NzMyNTIwM2EgLyogQj8/PyAqLyAob3V0KSAtb3Bvc3QgLWlzaWcg aWNhbm9uIC1lY2hvIC4uLn0pID0gMA0KYnJlYWsoMHg4MDY4MDAwKSAgICAgICAgICAgICAg ICAgICAgICAgID0gMA0KaXNzZXR1Z2lkKDB4YmZiZmQ3ZTEpICAgICAgICAgICAgICAgICAg ID0gMA0KYnJlYWsoMHg4MDY5MDAwKSAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYnJl YWsoMHg4MDZhMDAwKSAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYnJlYWsoMHg4MDZi MDAwKSAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYnJlYWsoMHg4MDZjMDAwKSAgICAg ICAgICAgICAgICAgICAgICAgID0gMA0KaW9jdGwoMSwgVElPQ0dFVEEsIHsweDI1MDA2NDM0 IC8qIEI/Pz8gKi8gKGluKTB4NDMwMDczMzUgLyogQj8/PyAqLyAob3V0KSBvcG9zdCAtaXNp ZyBpY2Fub24gZWNobyAuLi59KSA9IDANCmlvY3RsKDEsIFRJT0NHRVRBLCB7QjM4NDAwIG9w b3N0IGlzaWcgaWNhbm9uIGVjaG8gLi4ufSkgPSAwDQppb2N0bCgxLCBUSU9DR0VUQSwge0Iw IC1vcG9zdCAtaXNpZyAtaWNhbm9uIC1lY2hvIC4uLn0pID0gMA0KaW9jdGwoMSwgVElPQ0dX SU5TWiwge3dzX3Jvdz0wLCB3c19jb2w9MCwgd3NfeHBpeGVsPTAsIHdzX3lwaXhlbD0wfSkg PSAwDQppb2N0bCgxLCBUSU9DR1dJTlNaLCB7d3Nfcm93PTAsIHdzX2NvbD0wLCB3c194cGl4 ZWw9MCwgd3NfeXBpeGVsPTB9KSA9IDANCmlvY3RsKDEsIFRJT0NHRVRBLCB7QjM4NDAwIG9w b3N0IGlzaWcgaWNhbm9uIGVjaG8gLi4ufSkgPSAwDQpicmVhaygweDgwNzAwMDApICAgICAg ICAgICAgICAgICAgICAgICAgPSAwDQpicmVhaygweDgwNzQwMDApICAgICAgICAgICAgICAg ICAgICAgICAgPSAwDQpzaWdwcm9jbWFzayhTSUdfQkxPQ0ssIFtJTlQgUVVJVCBUU1RQIFdJ TkNIXSwgTlVMTCkgPSAwDQppb2N0bCgxLCBUSU9DR0VUQSwge0IzODQwMCBvcG9zdCBpc2ln IGljYW5vbiBlY2hvIC4uLn0pID0gMA0KaW9jdGwoMSwgVElPQ1NFVEFXLCB7QjM4NDAwIG9w b3N0IGlzaWcgLWljYW5vbiAtZWNobyAuLi59KSA9IDANCnN5c2NhbGxfNDE2KDB4MiwgMHhi ZmJmZTBjMCwgMCkgICAgICAgICA9IDANCnN5c2NhbGxfNDE2KDB4MywgMHhiZmJmZTBjMCwg MCkgICAgICAgICA9IDANCnN5c2NhbGxfNDE2KDB4MTIsIDB4YmZiZmUwYzAsIDApICAgICAg ICA9IDANCnN5c2NhbGxfNDE2KDB4MWMsIDB4YmZiZmUwYzAsIDApICAgICAgICA9IDANCnNp Z3Byb2NtYXNrKFNJR19CTE9DSywgTlVMTCwgW0lOVCBRVUlUIFRTVFAgV0lOQ0hdKSA9IDAN CnNpZ3Byb2NtYXNrKFNJR19VTkJMT0NLLCBbSU5UIFFVSVQgVFNUUCBXSU5DSF0sIE5VTEwp ID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDQ5LCAzOTI3MzZ9LCBOVUxMKSA9IDANCmdl dHRpbWVvZmRheSh7MCwgMH0sIE5VTEwpICAgICAgICAgICAgICA9IDANCl9fc3lzY3RsKFtr ZXJuLjUxXSwgMiwgIlwyXDBcMFwwXDM3N1wzNzdcMzc3XDM3N1wwXDBcMFwwXDFcMFwwXDBc MFwwXDBcMFwxXDBcMCIuLi4sIFs1MV0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW2tlcm4u Y3BfdGltZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnN5cy52X3N3dGNoXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0u c3RhdHMuc3lzLnZfdHJhcF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W3ZtLnN0YXRzLnN5cy52X2ludHJdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy5zeXMudl9zb2Z0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMudm0udl92Zm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9 IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9yZm9ya3NdLCA0LCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3ZtX2ZhdWx0c10sIDQsICIi LCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcGluXSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2Fw b3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0u dl90ZnJlZV0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfdm5vZGVpbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfdm5vZGVvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X2FjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnRdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3dpcmVfY291bnRd LCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2Nh Y2hlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3Rh dHMudm0udl9mcmVlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMudm0udl9zd2FwcGdzaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXRdLCA0LCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2ZnMuYnVmc3BhY2VdLCAyLCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zd2FwX2luZm8uMF0sIDMsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN3YXBfaW5mby4xXSwgMywgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbdm0uc3dhcF9pbmZvLjJdLCAzLCAweGJmYmZkZWMwLCAweGJmYmZk ZWY4LCBOVUxMLCAwKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkN Cl9fc3lzY3RsKFtdLCAwLCAweGJmYmZlMDkwLCAweGJmYmZkZjEwLCBOVUxMLCAwKSA9IC0x IEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCndyaXRlKDEsICJcMzNbPzEwNDloIiwgOCkg ICAgICAgICAgICAgICA9IDgNCl9fc3lzY3RsKFtdLCAwLCAwLCAweGJmYmZkZmI0LCBOVUxM LCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCmlzc2V0dWdpZCgwKSAgICAg ICAgICAgICAgICAgICAgICAgICAgICA9IDANCm9wZW4oIiIsIE9fUkRPTkxZKSAgICAgICAg ICAgICAgICAgICAgICA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkN Cmlzc2V0dWdpZCgwKSAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDANCm9wZW4oIudj BQjxYwUI+2MFCAVkBQhkBQgiLCBPX1JET05MWSkgID0gNQ0KZnN0YXQoNSwge3N0X21vZGU9 MDYsIHN0X3NpemU9NywgLi4ufSkgID0gMA0KcmVhZCg1LCAiXDBcMFwwXDBcMzU0XDM0MFw0 XDEwXDIwM2VcNVwxMFw2XDBcMFwwXDFcMFwwXDBcMFwwXDBcMCIuLi4sIDc5NDQpID0gMTI2 Nw0KY2xvc2UoNSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYWNjZXNz KCIvZXRjL2xvY2FsdGltZSIsIFJfT0spICAgICAgICAgID0gMA0Kb3BlbigiL2V0Yy9sb2Nh bHRpbWUiLCBPX1JET05MWSkgICAgICAgID0gNQ0KZnN0YXQoNSwge3N0X21vZGU9U19JRkJM S3xTX0lTVUlEfFNfSVNHSUR8U19JU1ZUWHwwNTYyLCBzdF9yZGV2PW1ha2VkZXYoMTA1LCAx ODUyNzY4MzcyKSwgLi4ufSkgPSAwDQpyZWFkKDUsICJ0ZW0gY2FsbFwwSW5wdXQvb3V0cHV0 IGVycm9yXDBEZXZpIi4uLiwgNzk0NCkgPSA4MDYNCmNsb3NlKDUpICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA9IDANCndyaXRlKDEsICJcMzNbSFwzM1tKbGFzdCBwaWQ6IC0x MDc3OTQ0MTI4OyAgbG8iLi4uLCA0NjgpID0gNDY4DQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc0 NDksIDQ2MTIwMH0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDUwLCA0NjEy MDB9LCBOVUxMKSA9IDANCnNlbGVjdCgyLCBbXSwgTlVMTCwgTlVMTCwgezAsIDB9KSAgICAg ICA9IDAgKFRpbWVvdXQpDQpnZXR0aW1lb2ZkYXkoezAsIDB9LCBOVUxMKSAgICAgICAgICAg ICAgPSAwDQpnZXR0aW1lb2ZkYXkoezAsIDB9LCBOVUxMKSAgICAgICAgICAgICAgPSAwDQpf X3N5c2N0bChbc3lzY3RsLjBdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3Rs KFtrZXJuLmNwX3RpbWVdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2 bS5zdGF0cy5zeXMudl9zd3RjaF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnN5cy52X3RyYXBdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9f c3lzY3RsKFt2bS5zdGF0cy5zeXMudl9pbnRyXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfc29mdF0sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdmZvcmtzXSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9mb3Jrc10sIDQsICIiLCBbMF0s IE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfcmZvcmtzXSwgNCwgIiIs IFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bV9mYXVsdHNd LCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3 YXBpbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZt LnZfc3dhcG91dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0 YXRzLnZtLnZfdGZyZWVdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2 bS5zdGF0cy52bS52X3Zub2RlaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X3Zub2Rlb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9hY3RpdmVfY291bnRdLCA0LCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50XSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl93aXJl X2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMu dm0udl9jYWNoZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W3ZtLnN0YXRzLnZtLnZfZnJlZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0K X19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcHBnc2luXSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwcGdzb3V0XSwgNCwgIiIsIFsw XSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdmZzLmJ1ZnNwYWNlXSwgMiwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbXSwgMCwgMHhiZmJmZTA5MCwgMHhiZmJmZGYyMCwg TlVMTCwgMCkgPSAtMSBFSU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQp3cml0ZSgxLCAiXDMz WzM7N0gxMi45XDMzWzM7MzFIODcuMVxuXG5cblxuIiwgMjUpID0gMjUNCmdldHRpbWVvZmRh eSh7NTQwNzUxOTIyLCAxNjM0NjkyMTI4fSwgTlVMTCkgPSAwDQpzZWxlY3QoMiwgW10sIE5V TEwsIE5VTEwsIHs4MDgyNjM3MjQsIDUzOTMwOTM1OH0pID0gMCAoVGltZW91dCkNCmdldHRp bWVvZmRheSh7MTcwMjEyOTI1NywgMTg4Njc0NTIwMn0sIE5VTEwpID0gMA0KZ2V0dGltZW9m ZGF5KHsxMjIyNjM3NDUxLCA0NjYwNDN9LCBOVUxMKSA9IDANCmdldHRpbWVvZmRheSh7MTIy MjYzNzQ1MSwgNDYxMjAwfSwgTlVMTCkgPSAwDQpfX3N5c2N0bChbc3lzY3RsLjUxXSwgMiwg IlwyXDBcMFwwXDM3N1wzNzdcMzc3XDM3N1wwXDBcMFwwXDFcMFwwXDBcMFwwXDBcMFwxXDBc MCIuLi4sIFs1MV0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW2tlcm4uY3BfdGltZV0sIDIs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X3N3dGNo XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZf dHJhcF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5 cy52X2ludHJdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0 cy5zeXMudl9zb2Z0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0u c3RhdHMudm0udl92Zm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3Rs KFt2bS5zdGF0cy52bS52X2ZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5 c2N0bChbdm0uc3RhdHMudm0udl9yZm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3ZtX2ZhdWx0c10sIDQsICIiLCBbMF0sIE5VTEws IDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcGluXSwgNCwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2Fwb3V0XSwgNCwgIiIs IFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl90ZnJlZV0sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVp bl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZf dm5vZGVvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0 cy52bS52X2FjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3dpcmVfY291bnRdLCA0LCAiIiwgWzBd LCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2NhY2hlX2NvdW50XSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9mcmVl X2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMu dm0udl9zd2FwcGdzaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2 bS5zdGF0cy52bS52X3N3YXBwZ3NvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9f c3lzY3RsKFt2ZnMuYnVmc3BhY2VdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFtdLCAwLCAweGJmYmZlMDkwLCAweGJmYmZkZjEwLCBOVUxMLCAwKSA9IC0xIEVJTlZB TCAoSW52YWxpZCBhcmd1bWVudCkNCl9fc3lzY3RsKFtdLCAwLCAwLCAweGJmYmZkZmI0LCBO VUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCndyaXRlKDEsICJcMzNb MTsxMUggICAgMFwzM1sxOzE1Nkg1MVwzM1sxOzE0NEg5XDMzIi4uLiwgMTMzKSA9IDEzMw0K Z2V0dGltZW9mZGF5KHs5MjY2MjY2NTEsIDc3NTQ5NTc1Mn0sIE5VTEwpID0gMA0Kc2VsZWN0 KDIsIFtdLCBOVUxMLCBOVUxMLCB7MTk1MzM5MjkyOCwgMTk3MDQzNDY2MX0pID0gMCAoVGlt ZW91dCkNCmdldHRpbWVvZmRheSh7NTM5Nzg0MzA0LCA4NDE4ODc3NzZ9LCBOVUxMKSA9IDAN CmdldHRpbWVvZmRheSh7MTIyMjYzNzQ1MywgNDcwMzY1fSwgTlVMTCkgPSAwDQpnZXR0aW1l b2ZkYXkoezEyMjI2Mzc0NTMsIDQ2NjA0M30sIE5VTEwpID0gMA0KX19zeXNjdGwoW3N5c2N0 bC41MV0sIDIsICJcMlwwXDBcMFwzNzdcMzc3XDM3N1wzNzdcMFwwXDBcMFwxXDBcMFwwXDBc MFwwXDBcMVwwXDAiLi4uLCBbNTFdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFtrZXJuLmNw X3RpbWVdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5z eXMudl9zd3RjaF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0 YXRzLnN5cy52X3RyYXBdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2 bS5zdGF0cy5zeXMudl9pbnRyXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMuc3lzLnZfc29mdF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3ZtLnN0YXRzLnZtLnZfdmZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9mb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfcmZvcmtzXSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bV9mYXVsdHNdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBpbl0sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcG91 dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZf dGZyZWVdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52 bS52X3Zub2RlaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X3Zub2Rlb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMudm0udl9hY3RpdmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9 IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50XSwgNCwgIiIsIFsw XSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl93aXJlX2NvdW50XSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9jYWNo ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfZnJlZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W3ZtLnN0YXRzLnZtLnZfc3dhcHBnc2luXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwcGdzb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdmZzLmJ1ZnNwYWNlXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbXSwgMCwgMHhiZmJmZTA5MCwgMHhiZmJmZGYxMCwgTlVMTCwgMCkg PSAtMSBFSU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQpfX3N5c2N0bChbXSwgMCwgMCwgMHhi ZmJmZGZiNCwgTlVMTCwgMCkgPSAtMSBFSU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQp3cml0 ZSgxLCAiXDMzWzE7MzJIMzcsICAwLjMzLCAgMC4zNVwzM1sxOzE1N0gzIi4uLiwgMTc1KSA9 IDE3NQ0KZ2V0dGltZW9mZGF5KHs5OTMwOTAzMzEsIDEyMTEzMTUyNDl9LCBOVUxMKSA9IDAN CnNlbGVjdCgyLCBbMV0sIE5VTEwsIE5VTEwsIHsxMjExNTc3OTE1LCAxOTYzNTkyMjQ2fSkg PSAwIChUaW1lb3V0KQ0KZ2V0dGltZW9mZGF5KHs1Mzk3ODQzMDQsIDg0MTg4Nzc3Nn0sIE5V TEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDU1LCA0NzM0MjR9LCBOVUxMKSA9IDAN CmdldHRpbWVvZmRheSh7MTIyMjYzNzQ1NSwgNDcwMzY1fSwgTlVMTCkgPSAwDQpfX3N5c2N0 bChbc3lzY3RsLjUxXSwgMiwgIlwyXDBcMFwwXDM3N1wzNzdcMzc3XDM3N1wwXDBcMFwwXDFc MFwwXDBcMFwwXDBcMFwxXDBcMCIuLi4sIFs1MV0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W2tlcm4uY3BfdGltZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnN5cy52X3N3dGNoXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMuc3lzLnZfdHJhcF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3ZtLnN0YXRzLnN5cy52X2ludHJdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl9zb2Z0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92Zm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZvcmtzXSwgNCwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9yZm9ya3NdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3ZtX2ZhdWx0c10s IDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dh cGluXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0u dl9zd2Fwb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3Rh dHMudm0udl90ZnJlZV0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfdm5vZGVpbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2FjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5V TEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnRdLCA0 LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3dpcmVf Y291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52 bS52X2NhY2hlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChb dm0uc3RhdHMudm0udl9mcmVlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwcGdzaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXRdLCA0LCAiIiwgWzBd LCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2ZnMuYnVmc3BhY2VdLCAyLCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFtdLCAwLCAweGJmYmZlMDkwLCAweGJmYmZkZjEwLCBO VUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCl9fc3lzY3RsKFtdLCAw LCAwLCAweGJmYmZkZmI0LCBOVUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVu dCkNCndyaXRlKDEsICJcMzNbMTsxNTdINVwzM1sxOzE0NEgzXDMzWzM7OEg0LjZcMzNbMzsz Ii4uLiwgMTgxKSA9IDE4MQ0KZ2V0dGltZW9mZGF5KHs5NTk5MjQyNzMsIDE1Mjg1MDk3NDJ9 LCBOVUxMKSA9IDANCnNlbGVjdCgyLCBbMCAxXSwgTlVMTCwgTlVMTCwgezE5NTMzOTE5ODEs IDg1ODkzODEzOX0pID0gMCAoVGltZW91dCkNCmdldHRpbWVvZmRheSh7MTI2NDI2MTk5Nywg ODQxODg3NzU3fSwgTlVMTCkgPSAwDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc0NTcsIDQ3NjQ5 MX0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDU3LCA0NzM0MjR9LCBOVUxM KSA9IDANCl9fc3lzY3RsKFtzeXNjdGwuNTFdLCAyLCAiXDJcMFwwXDBcMzc3XDM3N1wzNzdc Mzc3XDBcMFwwXDBcMVwwXDBcMFwwXDBcMFwwXDFcMFwwIi4uLiwgWzUxXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChba2Vybi5jcF90aW1lXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfc3d0Y2hdLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl90cmFwXSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfaW50cl0sIDQsICIiLCBbMF0s IE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X3NvZnRdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Zmb3Jrc10sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfZm9ya3Nd LCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Jm b3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZt LnZfdm1fZmF1bHRzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0u c3RhdHMudm0udl9zd2FwaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3Rs KFt2bS5zdGF0cy52bS52X3N3YXBvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9f c3lzY3RsKFt2bS5zdGF0cy52bS52X3RmcmVlXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bm9kZWluXSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bm9kZW91dF0sIDQsICIiLCBbMF0s IE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfYWN0aXZlX2NvdW50XSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9pbmFj dGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0 YXRzLnZtLnZfd2lyZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnZtLnZfY2FjaGVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9 IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZyZWVfY291bnRdLCA0LCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBwZ3Npbl0sIDQsICIi LCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcHBnc291 dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zmcy5idWZzcGFjZV0s IDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW10sIDAsIDB4YmZiZmUwOTAs IDB4YmZiZmRmMTAsIE5VTEwsIDApID0gLTEgRUlOVkFMIChJbnZhbGlkIGFyZ3VtZW50KQ0K X19zeXNjdGwoW10sIDAsIDAsIDB4YmZiZmRmYjQsIE5VTEwsIDApID0gLTEgRUlOVkFMIChJ bnZhbGlkIGFyZ3VtZW50KQ0Kd3JpdGUoMSwgIlwzM1sxOzMySDUwLCAgMC4zNiwgIDAuMzZc MzNbMTsxNTdINyIuLi4sIDE0MykgPSAxNDMNCmdldHRpbWVvZmRheSh7OTkzMDkwMzMxLCAx MjExMzgwNzg1fSwgTlVMTCkgPSAwDQpzZWxlY3QoMiwgWzBdLCBOVUxMLCBOVUxMLCB7MTk1 MzM5MTk4MSwgODU4OTM4MTM5fSkgPSAwIChUaW1lb3V0KQ0KZ2V0dGltZW9mZGF5KHsxMjY0 MjYxOTk3LCA4NDE4ODc3NTd9LCBOVUxMKSA9IDANCmdldHRpbWVvZmRheSh7MTIyMjYzNzQ1 OSwgNDc4NjExfSwgTlVMTCkgPSAwDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc0NTksIDQ3NjQ5 MX0sIE5VTEwpID0gMA0KX19zeXNjdGwoW3N5c2N0bC41MV0sIDIsICJcMlwwXDBcMFwzNzdc Mzc3XDM3N1wzNzdcMFwwXDBcMFwxXDBcMFwwXDBcMFwwXDBcMVwwXDAiLi4uLCBbNTFdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFtrZXJuLmNwX3RpbWVdLCAyLCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl9zd3RjaF0sIDQsICIiLCBbMF0s IE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X3RyYXBdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl9pbnRyXSwgNCwg IiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfc29mdF0s IDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdmZv cmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0u dl9mb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfcmZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0u c3RhdHMudm0udl92bV9mYXVsdHNdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X3N3YXBpbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0K X19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcG91dF0sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdGZyZWVdLCA0LCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Zub2RlaW5dLCA0LCAiIiwgWzBd LCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Zub2Rlb3V0XSwgNCwg IiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9hY3RpdmVf Y291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52 bS52X2luYWN0aXZlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMudm0udl93aXJlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9jYWNoZV9jb3VudF0sIDQsICIiLCBbMF0sIE5V TEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfZnJlZV9jb3VudF0sIDQsICIi LCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcHBnc2lu XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9z d2FwcGdzb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdmZzLmJ1 ZnNwYWNlXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbXSwgMCwgMHhi ZmJmZTA5MCwgMHhiZmJmZGYxMCwgTlVMTCwgMCkgPSAtMSBFSU5WQUwgKEludmFsaWQgYXJn dW1lbnQpDQpfX3N5c2N0bChbXSwgMCwgMCwgMHhiZmJmZGZiNCwgTlVMTCwgMCkgPSAtMSBF SU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQp3cml0ZSgxLCAiXDMzWzE7MTU3SDlcMzNbMTsx NDRIN1wzM1szOzEwSDRcMzNbMzszMSIuLi4sIDEzNCkgPSAxMzQNCmdldHRpbWVvZmRheSh7 Nzc1MzA1MDMyLCA4NjE2MDg3NTV9LCBOVUxMKSA9IDANCnNlbGVjdCgyLCBbMCAxXSwgTlVM TCwgTlVMTCwgezE5NTMzOTE5ODEsIDg1ODkzODEzOX0pID0gMCAoVGltZW91dCkNCmdldHRp bWVvZmRheSh7MTI2NDI2MTk5NywgODQxODg3NzU3fSwgTlVMTCkgPSAwDQpnZXR0aW1lb2Zk YXkoezEyMjI2Mzc0NjEsIDQ4MTQ5Nn0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIy NjM3NDYxLCA0Nzg2MTF9LCBOVUxMKSA9IDANCl9fc3lzY3RsKFtzeXNjdGwuNTFdLCAyLCAi XDJcMFwwXDBcMzc3XDM3N1wzNzdcMzc3XDBcMFwwXDBcMVwwXDBcMFwwXDBcMFwwXDFcMFww Ii4uLiwgWzUxXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChba2Vybi5jcF90aW1lXSwgMiwg IiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfc3d0Y2hd LCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl90 cmFwXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lz LnZfaW50cl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnN5cy52X3NvZnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X3Zmb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W3ZtLnN0YXRzLnZtLnZfZm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X3Jmb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0K X19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm1fZmF1bHRzXSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwaW5dLCA0LCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBvdXRdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3RmcmVlXSwgNCwg IiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bm9kZWlu XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92 bm9kZW91dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfYWN0aXZlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMudm0udl9pbmFjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfd2lyZV9jb3VudF0sIDQsICIiLCBbMF0s IE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfY2FjaGVfY291bnRdLCA0 LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZyZWVf Y291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52 bS52X3N3YXBwZ3Npbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfc3dhcHBnc291dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3Zmcy5idWZzcGFjZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW10sIDAsIDB4YmZiZmUwOTAsIDB4YmZiZmRmMTAsIE5VTEwsIDApID0gLTEgRUlOVkFM IChJbnZhbGlkIGFyZ3VtZW50KQ0KX19zeXNjdGwoW10sIDAsIDAsIDB4YmZiZmRmYjQsIE5V TEwsIDApID0gLTEgRUlOVkFMIChJbnZhbGlkIGFyZ3VtZW50KQ0Kd3JpdGUoMSwgIlwzM1sx OzMwSDEuMTgsICAwLjUwLCAgMC40MVwzM1sxOzE1NCIuLi4sIDE4OCkgPSAxODgNCmdldHRp bWVvZmRheSh7ODA5MTIwMDcyLCA4MjgwNTQzMjF9LCBOVUxMKSA9IDANCnNlbGVjdCgyLCBb MCAxXSwgTlVMTCwgTlVMTCwgezE3Njg3MTA1MTgsIDE5MTg5Njc5MDh9KSA9IDAgKFRpbWVv dXQpDQpnZXR0aW1lb2ZkYXkoezE3MDE2NzIyOTUsIDE1Mjg1MjU5MzR9LCBOVUxMKSA9IDAN CmdldHRpbWVvZmRheSh7MTIyMjYzNzQ2MywgNDg0NjIxfSwgTlVMTCkgPSAwDQpnZXR0aW1l b2ZkYXkoezEyMjI2Mzc0NjMsIDQ4MTQ5Nn0sIE5VTEwpID0gMA0KX19zeXNjdGwoW3N5c2N0 bC41MV0sIDIsICJcMlwwXDBcMFwzNzdcMzc3XDM3N1wzNzdcMFwwXDBcMFwxXDBcMFwwXDBc MFwwXDBcMVwwXDAiLi4uLCBbNTFdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFtrZXJuLmNw X3RpbWVdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5z eXMudl9zd3RjaF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0 YXRzLnN5cy52X3RyYXBdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2 bS5zdGF0cy5zeXMudl9pbnRyXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMuc3lzLnZfc29mdF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3ZtLnN0YXRzLnZtLnZfdmZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAw DQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9mb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfcmZvcmtzXSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bV9mYXVsdHNdLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBpbl0sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcG91 dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZf dGZyZWVdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52 bS52X3Zub2RlaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X3Zub2Rlb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0 bChbdm0uc3RhdHMudm0udl9hY3RpdmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9 IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50XSwgNCwgIiIsIFsw XSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl93aXJlX2NvdW50XSwg NCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9jYWNo ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfZnJlZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwo W3ZtLnN0YXRzLnZtLnZfc3dhcHBnc2luXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwcGdzb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdmZzLmJ1ZnNwYWNlXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbXSwgMCwgMHhiZmJmZTA5MCwgMHhiZmJmZGYxMCwgTlVMTCwgMCkg PSAtMSBFSU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQpfX3N5c2N0bChbXSwgMCwgMCwgMHhi ZmJmZGZiNCwgTlVMTCwgMCkgPSAtMSBFSU5WQUwgKEludmFsaWQgYXJndW1lbnQpDQp3cml0 ZSgxLCAiXDMzWzE7MTU3SDNcMzNbMTsxNDNIMzFcMzNbMzszMkgwLjhcMzNbMyIuLi4sIDk4 KSA9IDk4DQpnZXR0aW1lb2ZkYXkoezEyMTEzMTU3NzEsIDQ1NjI3MzQ2NX0sIE5VTEwpID0g MA0Kc2VsZWN0KDIsIFswIDFdLCBOVUxMLCBOVUxMLCB7MTc2ODcxMDUxOCwgMTkxODk2Nzkw OH0pID0gMCAoVGltZW91dCkNCmdldHRpbWVvZmRheSh7MTcwMTY3MjI5NSwgMTUyODUyNTkz NH0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDY1LCA0ODcyNzR9LCBOVUxM KSA9IDANCmdldHRpbWVvZmRheSh7MTIyMjYzNzQ2NSwgNDg0NjIxfSwgTlVMTCkgPSAwDQpf X3N5c2N0bChbc3lzY3RsLjUxXSwgMiwgIlwyXDBcMFwwXDM3N1wzNzdcMzc3XDM3N1wwXDBc MFwwXDFcMFwwXDBcMFwwXDBcMFwxXDBcMCIuLi4sIFs1MV0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW2tlcm4uY3BfdGltZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnN5cy52X3N3dGNoXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfdHJhcF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0g MA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X2ludHJdLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl9zb2Z0XSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92Zm9ya3NdLCA0LCAiIiwgWzBd LCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZvcmtzXSwgNCwgIiIs IFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9yZm9ya3NdLCA0 LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3ZtX2Zh dWx0c10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZt LnZfc3dhcGluXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3Rh dHMudm0udl9zd2Fwb3V0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChb dm0uc3RhdHMudm0udl90ZnJlZV0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVpbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0K X19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2FjdGl2ZV9jb3VudF0sIDQsICIiLCBb MF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291 bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52 X3dpcmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X2NhY2hlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5 c2N0bChbdm0uc3RhdHMudm0udl9mcmVlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwcGdzaW5dLCA0LCAiIiwgWzBdLCBO VUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXRdLCA0LCAi IiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2ZnMuYnVmc3BhY2VdLCAyLCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFtdLCAwLCAweGJmYmZlMDkwLCAweGJmYmZk ZjEwLCBOVUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCl9fc3lzY3Rs KFtdLCAwLCAwLCAweGJmYmZkZmI0LCBOVUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBh cmd1bWVudCkNCndyaXRlKDEsICJcMzNbMTsxNTdINVwzM1sxOzE0NEgzXDMzWzM7MzRINFwz M1szOzY1Ii4uLiwgODcpID0gODcNCmdldHRpbWVvZmRheSh7MTUyODUxMDAyNCwgODA4NTMy Nzg4fSwgTlVMTCkgPSAwDQpzZWxlY3QoMiwgW10sIE5VTEwsIE5VTEwsIHsxNzY4NzEwNTE4 LCAxOTE4OTY3OTA4fSkgPSAwIChUaW1lb3V0KQ0KZ2V0dGltZW9mZGF5KHsxNzAxNjcyMjk1 LCAxNTI4NTI1OTM0fSwgTlVMTCkgPSAwDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc0NjcsIDQ5 MDE1MX0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NDY3LCA0ODcyNzR9LCBO VUxMKSA9IDANCl9fc3lzY3RsKFtzeXNjdGwuNTFdLCAyLCAiXDJcMFwwXDBcMzc3XDM3N1wz NzdcMzc3XDBcMFwwXDBcMVwwXDBcMFwwXDBcMFwwXDFcMFwwIi4uLiwgWzUxXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChba2Vybi5jcF90aW1lXSwgMiwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfc3d0Y2hdLCA0LCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMudl90cmFwXSwgNCwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfaW50cl0sIDQsICIiLCBb MF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X3NvZnRdLCA0LCAi IiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Zmb3Jrc10s IDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfZm9y a3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52 X3Jmb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRz LnZtLnZfdm1fZmF1bHRzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChb dm0uc3RhdHMudm0udl9zd2FwaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X3N3YXBvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3RmcmVlXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkg PSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bm9kZWluXSwgNCwgIiIsIFswXSwgTlVM TCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92bm9kZW91dF0sIDQsICIiLCBb MF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfYWN0aXZlX2NvdW50 XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9p bmFjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfd2lyZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3ZtLnN0YXRzLnZtLnZfY2FjaGVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAw KSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2ZyZWVfY291bnRdLCA0LCAiIiwgWzBd LCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBwZ3Npbl0sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcHBn c291dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zmcy5idWZzcGFj ZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW10sIDAsIDB4YmZiZmUw OTAsIDB4YmZiZmRmMTAsIE5VTEwsIDApID0gLTEgRUlOVkFMIChJbnZhbGlkIGFyZ3VtZW50 KQ0KX19zeXNjdGwoW10sIDAsIDAsIDB4YmZiZmRmYjQsIE5VTEwsIDApID0gLTEgRUlOVkFM IChJbnZhbGlkIGFyZ3VtZW50KQ0Kd3JpdGUoMSwgIlwzM1sxOzMySDA5XDMzWzE7MTU3SDdc MzNbMTsxNDRINVwzM1szOzMiLi4uLCAxMjMpID0gMTIzDQpnZXR0aW1lb2ZkYXkoezQ1NjI4 MDExNiwgOTA5ODQ5NDM1fSwgTlVMTCkgPSAwDQpzZWxlY3QoMiwgWzBdLCBOVUxMLCBOVUxM LCB7MTc2ODcxMDUxOCwgMTkxODk2NzkwOH0pID0gMCAoVGltZW91dCkNCmdldHRpbWVvZmRh eSh7MTcwMTY3MjI5NSwgMTUyODUyNTkzNH0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5KHsx MjIyNjM3NDY5LCA0OTMwNDF9LCBOVUxMKSA9IDANCmdldHRpbWVvZmRheSh7MTIyMjYzNzQ2 OSwgNDkwMTUxfSwgTlVMTCkgPSAwDQpfX3N5c2N0bChbc3lzY3RsLjUxXSwgMiwgIlwyXDBc MFwwXDM3N1wzNzdcMzc3XDM3N1wwXDBcMFwwXDFcMFwwXDBcMFwwXDBcMFwxXDBcMCIuLi4s IFs1MV0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW2tlcm4uY3BfdGltZV0sIDIsICIiLCBb MF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X3N3dGNoXSwgNCwg IiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZfdHJhcF0s IDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnN5cy52X2lu dHJdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5zeXMu dl9zb2Z0XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMu dm0udl92Zm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X2ZvcmtzXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChb dm0uc3RhdHMudm0udl9yZm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lz Y3RsKFt2bS5zdGF0cy52bS52X3ZtX2ZhdWx0c10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0g MA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfc3dhcGluXSwgNCwgIiIsIFswXSwgTlVMTCwg MCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2Fwb3V0XSwgNCwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl90ZnJlZV0sIDQsICIiLCBb MF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVpbl0sIDQs ICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm5vZGVv dXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52 X2FjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3dpcmVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxM LCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X2NhY2hlX2NvdW50XSwgNCwgIiIs IFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9mcmVlX2NvdW50 XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9z d2FwcGdzaW5dLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0 cy52bS52X3N3YXBwZ3NvdXRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3Rs KFt2ZnMuYnVmc3BhY2VdLCAyLCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFtd LCAwLCAweGJmYmZlMDkwLCAweGJmYmZkZjEwLCBOVUxMLCAwKSA9IC0xIEVJTlZBTCAoSW52 YWxpZCBhcmd1bWVudCkNCl9fc3lzY3RsKFtdLCAwLCAwLCAweGJmYmZkZmI0LCBOVUxMLCAw KSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkNCndyaXRlKDEsICJcMzNbMTsxNTdI OVwzM1sxOzE0NEg3XDMzWzM7MzRINlwzM1szOzY1Ii4uLiwgNzgpID0gNzgNCmdldHRpbWVv ZmRheSh7MTUyODUwOTUxMiwgODI1MzEwMDA0fSwgTlVMTCkgPSAwDQpzZWxlY3QoMiwgW10s IE5VTEwsIE5VTEwsIHsxNzY4NzEwNTE4LCAxOTE4OTY3OTA4fSkgPSAwIChUaW1lb3V0KQ0K Z2V0dGltZW9mZGF5KHsxNzAxNjcyMjk1LCAxNTI4NTI1OTM0fSwgTlVMTCkgPSAwDQpnZXR0 aW1lb2ZkYXkoezEyMjI2Mzc0NzEsIDQ5NTkyMn0sIE5VTEwpID0gMA0KZ2V0dGltZW9mZGF5 KHsxMjIyNjM3NDcxLCA0OTMwNDF9LCBOVUxMKSA9IDANCl9fc3lzY3RsKFtzeXNjdGwuNTFd LCAyLCAiXDJcMFwwXDBcMzc3XDM3N1wzNzdcMzc3XDBcMFwwXDBcMVwwXDBcMFwwXDBcMFww XDFcMFwwIi4uLiwgWzUxXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChba2Vybi5jcF90aW1l XSwgMiwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMuc3lzLnZf c3d0Y2hdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy5z eXMudl90cmFwXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3Rh dHMuc3lzLnZfaW50cl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnN5cy52X3NvZnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3Rs KFt2bS5zdGF0cy52bS52X3Zmb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19z eXNjdGwoW3ZtLnN0YXRzLnZtLnZfZm9ya3NdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDAN Cl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3Jmb3Jrc10sIDQsICIiLCBbMF0sIE5VTEwsIDAp ID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfdm1fZmF1bHRzXSwgNCwgIiIsIFswXSwg TlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl9zd2FwaW5dLCA0LCAiIiwg WzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3N3YXBvdXRdLCA0 LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52X3RmcmVl XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMudm0udl92 bm9kZWluXSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpfX3N5c2N0bChbdm0uc3RhdHMu dm0udl92bm9kZW91dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3Zt LnN0YXRzLnZtLnZfYWN0aXZlX2NvdW50XSwgNCwgIiIsIFswXSwgTlVMTCwgMCkgPSAwDQpf X3N5c2N0bChbdm0uc3RhdHMudm0udl9pbmFjdGl2ZV9jb3VudF0sIDQsICIiLCBbMF0sIE5V TEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfd2lyZV9jb3VudF0sIDQsICIi LCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNjdGwoW3ZtLnN0YXRzLnZtLnZfY2FjaGVfY291 bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5zdGF0cy52bS52 X2ZyZWVfY291bnRdLCA0LCAiIiwgWzBdLCBOVUxMLCAwKSA9IDANCl9fc3lzY3RsKFt2bS5z dGF0cy52bS52X3N3YXBwZ3Npbl0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0gMA0KX19zeXNj dGwoW3ZtLnN0YXRzLnZtLnZfc3dhcHBnc291dF0sIDQsICIiLCBbMF0sIE5VTEwsIDApID0g MA0KX19zeXNjdGwoW3Zmcy5idWZzcGFjZV0sIDIsICIiLCBbMF0sIE5VTEwsIDApID0gMA0K X19zeXNjdGwoW10sIDAsIDB4YmZiZmUwOTAsIDB4YmZiZmRmMTAsIE5VTEwsIDApID0gLTEg RUlOVkFMIChJbnZhbGlkIGFyZ3VtZW50KQ0KX19zeXNjdGwoW10sIDAsIDAsIDB4YmZiZmRm YjQsIE5VTEwsIDApID0gLTEgRUlOVkFMIChJbnZhbGlkIGFyZ3VtZW50KQ0Kd3JpdGUoMSwg IlwzM1sxOzMzSDAsICAwLjQ5XDMzWzE7MTU2SDExXDMzWzE7MTQ0Ii4uLiwgMTAyKSA9IDEw Mg0KZ2V0dGltZW9mZGF5KHsxNTI4NTEwNzkyLCA4NzU3NzI3MjN9LCBOVUxMKSA9IDANCnNl bGVjdCgyLCBbXSwgTlVMTCwgTlVMTCwgezE3Njg3MTA1MTgsIDE5MTg5Njc5MDh9KSA9IDEg KGluIFswIDFdKQ0KcmVhZCgwLCAiTSIsIDEpICAgICAgICAgICAgICAgICAgICAgICAgID0g MQ0Kd3JpdGUoMSwgIlwzM1s1OTsxSFwzM1tLIiwgMTApICAgICAgICAgID0gMTANCmlvY3Rs KDEsIFRJT0NTRVRBVywge0IzODQwMCBvcG9zdCBpc2lnIGljYW5vbiBlY2hvIC4uLn0pID0g MA0KY2hkaXIoIi90bXAiKSAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0Kd3JpdGUo MSwgIlwzM1s/MTA0OWwiLCA4KSAgICAgICAgICAgICAgID0gOA0KZXhpdCgwKSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID0gPw0K --------------090308020800020406020106 Content-Type: text/plain; name="top.truss-trace.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="top.truss-trace.txt" bW1hcCgweDAsMzk1MixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfQU5PTiwtMSwweDApID0g NjcxNjIxMTIwICgweDI4MDgyMDAwKQ0KbXVubWFwKDB4MjgwODIwMDAsMzk1MikJCQkJID0g MCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTRhOCwweDIsMHgyODA3ZWI5OCwweGJmYmZlNGE0 LDB4MCwweDApID0gMCAoMHgwKQ0KbW1hcCgweDAsMzI3NjgsUFJPVF9SRUFEfFBST1RfV1JJ VEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDY3MTYyMTEyMCAoMHgyODA4MjAw MCkNCmlzc2V0dWdpZCgpCQkJCQkgPSAwICgweDApDQpvcGVuKCIvZXRjL2xpYm1hcC5jb25m IixPX1JET05MWSwwNjY2KQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0K YWNjZXNzKCIvaG9tZS91c2Vycy93aWx4L2xpYi9saWJuY3Vyc2VzLnNvLjYiLDApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0KYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9s aWJuY3Vyc2VzLnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScN Cm9wZW4oIi92YXIvcnVuL2xkLWVsZi5zby5oaW50cyIsT19SRE9OTFksMDUwMDE3NTI2MzAp ID0gNCAoMHg0KQ0KcmVhZCg0LCJFaG50XF5BXDBcMFwwXE1eQFwwXDBcMFxNXkNcXkFcMCIu Li4sMTI4KSA9IDEyOCAoMHg4MCkNCmxzZWVrKDQsMHg4MCxTRUVLX1NFVCkJCQkJID0gMTI4 ICgweDgwKQ0KcmVhZCg0LCIvbGliOi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4s Mzg3KSA9IDM4NyAoMHgxODMpDQpjbG9zZSg0KQkJCQkJID0gMCAoMHgwKQ0KYWNjZXNzKCIv bGliL2xpYm5jdXJzZXMuc28uNiIsMCkJCSA9IDAgKDB4MCkNCm9wZW4oIi9saWIvbGlibmN1 cnNlcy5zby42IixPX1JET05MWSwwMCkJID0gNCAoMHg0KQ0KZnN0YXQoNCx7bW9kZT0tci0t ci0tci0tICxpbm9kZT05Njgsc2l6ZT0yNzY1NDgsYmxrc2l6ZT00MDk2fSkgPSAwICgweDAp DQpmc3RhdGZzKDB4NCwweGJmYmZlMmIwKQkJCQkgPSAwICgweDApDQpyZWFkKDQsIlxeP0VM RlxeQVxeQVxeQVx0XDBcMFwwXDBcMFwwXDAiLi4uLDQwOTYpID0gNDA5NiAoMHgxMDAwKQ0K bW1hcCgweDAsMjc0NDMyLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX05P Q09SRSw0LDB4MCkgPSA2NzE2NTM4ODggKDB4MjgwOGEwMDApDQptcHJvdGVjdCgweDI4MGMz MDAwLDQwOTYsUFJPVF9SRUFEfFBST1RfV1JJVEV8UFJPVF9FWEVDKSA9IDAgKDB4MCkNCm1w cm90ZWN0KDB4MjgwYzMwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9FWEVDKQkgPSAwICgweDAp DQptbWFwKDB4MjgwYzQwMDAsMzI3NjgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZB VEV8TUFQX0ZJWEVELDQsMHgzYTAwMCkgPSA2NzE4OTE0NTYgKDB4MjgwYzQwMDApDQptbWFw KDB4MjgwY2MwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBf RklYRUR8TUFQX0FOT04sLTEsMHgwKSA9IDY3MTkyNDIyNCAoMHgyODBjYzAwMCkNCmNsb3Nl KDQpCQkJCQkgPSAwICgweDApDQphY2Nlc3MoIi9ob21lL3VzZXJzL3dpbHgvbGliL2xpYm0u c28uNCIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0KYWNjZXNzKCIv dXNyL2xvY2FsL2xpYi9saWJtLnNvLjQiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnknDQphY2Nlc3MoIi9saWIvbGlibS5zby40IiwwKQkJCSA9IDAgKDB4MCkNCm9w ZW4oIi9saWIvbGlibS5zby40IixPX1JET05MWSwwMjc3NTc3NjIyMjApCSA9IDQgKDB4NCkN CmZzdGF0KDQse21vZGU9LXItLXItLXItLSAsaW5vZGU9OTY1LHNpemU9OTQ1MDgsYmxrc2l6 ZT00MDk2fSkgPSAwICgweDApDQpmc3RhdGZzKDB4NCwweGJmYmZlMmIwKQkJCQkgPSAwICgw eDApDQpyZWFkKDQsIlxeP0VMRlxeQVxeQVxeQVx0XDBcMFwwXDBcMFwwXDAiLi4uLDQwOTYp ID0gNDA5NiAoMHgxMDAwKQ0KbW1hcCgweDAsOTAxMTIsUFJPVF9SRUFEfFBST1RfRVhFQyxN QVBfUFJJVkFURXxNQVBfTk9DT1JFLDQsMHgwKSA9IDY3MTkyODMyMCAoMHgyODBjZDAwMCkN Cm1wcm90ZWN0KDB4MjgwZTEwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURXxQUk9UX0VY RUMpID0gMCAoMHgwKQ0KbXByb3RlY3QoMHgyODBlMTAwMCw0MDk2LFBST1RfUkVBRHxQUk9U X0VYRUMpCSA9IDAgKDB4MCkNCm1tYXAoMHgyODBlMjAwMCw0MDk2LFBST1RfUkVBRHxQUk9U X1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCw0LDB4MTQwMDApID0gNjcyMDE0MzM2ICgw eDI4MGUyMDAwKQ0KY2xvc2UoNCkJCQkJCSA9IDAgKDB4MCkNCmFjY2VzcygiL2hvbWUvdXNl cnMvd2lseC9saWIvbGlia3ZtLnNvLjMiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScNCmFjY2VzcygiL3Vzci9sb2NhbC9saWIvbGlia3ZtLnNvLjMiLDApCQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknDQphY2Nlc3MoIi9saWIvbGlia3ZtLnNv LjMiLDApCQkJID0gMCAoMHgwKQ0Kb3BlbigiL2xpYi9saWJrdm0uc28uMyIsT19SRE9OTFks MDI3NzU3NzYyMjIwKQkgPSA0ICgweDQpDQpmc3RhdCg0LHttb2RlPS1yLS1yLS1yLS0gLGlu b2RlPTk1NSxzaXplPTI4MTYwLGJsa3NpemU9NDA5Nn0pID0gMCAoMHgwKQ0KZnN0YXRmcygw eDQsMHhiZmJmZTJiMCkJCQkJID0gMCAoMHgwKQ0KcmVhZCg0LCJcXj9FTEZcXkFcXkFcXkFc dFwwXDBcMFwwXDBcMFwwIi4uLiw0MDk2KSA9IDQwOTYgKDB4MTAwMCkNCm1tYXAoMHgwLDMy NzY4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX05PQ09SRSw0LDB4MCkg PSA2NzIwMTg0MzIgKDB4MjgwZTMwMDApDQptcHJvdGVjdCgweDI4MGU5MDAwLDQwOTYsUFJP VF9SRUFEfFBST1RfV1JJVEV8UFJPVF9FWEVDKSA9IDAgKDB4MCkNCm1wcm90ZWN0KDB4Mjgw ZTkwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9FWEVDKQkgPSAwICgweDApDQptbWFwKDB4Mjgw ZWEwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQs NCwweDYwMDApID0gNjcyMDQ3MTA0ICgweDI4MGVhMDAwKQ0KY2xvc2UoNCkJCQkJCSA9IDAg KDB4MCkNCmFjY2VzcygiL2hvbWUvdXNlcnMvd2lseC9saWIvbGliYy5zby42IiwwKQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknDQphY2Nlc3MoIi91c3IvbG9jYWwvbGli L2xpYmMuc28uNiIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScNCmFj Y2VzcygiL2xpYi9saWJjLnNvLjYiLDApCQkJID0gMCAoMHgwKQ0Kb3BlbigiL2xpYi9saWJj LnNvLjYiLE9fUkRPTkxZLDAyNzc1Nzc2MjIyMCkJID0gNCAoMHg0KQ0KZnN0YXQoNCx7bW9k ZT0tci0tci0tci0tICxpbm9kZT05NzIsc2l6ZT05Nzc2MDQsYmxrc2l6ZT00MDk2fSkgPSAw ICgweDApDQpmc3RhdGZzKDB4NCwweGJmYmZlMmIwKQkJCQkgPSAwICgweDApDQpyZWFkKDQs IlxeP0VMRlxeQVxeQVxeQVx0XDBcMFwwXDBcMFwwXDAiLi4uLDQwOTYpID0gNDA5NiAoMHgx MDAwKQ0KbW1hcCgweDAsOTk1MzI4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8 TUFQX05PQ09SRSw0LDB4MCkgPSA2NzIwNTEyMDAgKDB4MjgwZWIwMDApDQptcHJvdGVjdCgw eDI4MWMxMDAwLDQwOTYsUFJPVF9SRUFEfFBST1RfV1JJVEV8UFJPVF9FWEVDKSA9IDAgKDB4 MCkNCm1wcm90ZWN0KDB4MjgxYzEwMDAsNDA5NixQUk9UX1JFQUR8UFJPVF9FWEVDKQkgPSAw ICgweDApDQptbWFwKDB4MjgxYzIwMDAsMjQ1NzYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVELDQsMHhkNjAwMCkgPSA2NzI5MzE4NDAgKDB4MjgxYzIwMDAp DQptbWFwKDB4MjgxYzgwMDAsOTAxMTIsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9BTk9OLC0xLDB4MCkgPSA2NzI5NTY0MTYgKDB4MjgxYzgwMDAp DQpjbG9zZSg0KQkJCQkJID0gMCAoMHgwKQ0Kc3lzYXJjaCgweGEsMHhiZmJmZTUxMCkJCQkJ ID0gMCAoMHgwKQ0KbW1hcCgweDAsODA4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9BTk9O LC0xLDB4MCkgPSA2NzMwNDY1MjggKDB4MjgxZGUwMDApDQptdW5tYXAoMHgyODFkZTAwMCw4 MDgpCQkJCSA9IDAgKDB4MCkNCm1tYXAoMHgwLDQ4NjQsUFJPVF9SRUFEfFBST1RfV1JJVEUs TUFQX0FOT04sLTEsMHgwKSA9IDY3MzA0NjUyOCAoMHgyODFkZTAwMCkNCm11bm1hcCgweDI4 MWRlMDAwLDQ4NjQpCQkJCSA9IDAgKDB4MCkNCm1tYXAoMHgwLDE4NTYsUFJPVF9SRUFEfFBS T1RfV1JJVEUsTUFQX0FOT04sLTEsMHgwKSA9IDY3MzA0NjUyOCAoMHgyODFkZTAwMCkNCm11 bm1hcCgweDI4MWRlMDAwLDE4NTYpCQkJCSA9IDAgKDB4MCkNCm1tYXAoMHgwLDczNixQUk9U X1JFQUR8UFJPVF9XUklURSxNQVBfQU5PTiwtMSwweDApID0gNjczMDQ2NTI4ICgweDI4MWRl MDAwKQ0KbXVubWFwKDB4MjgxZGUwMDAsNzM2KQkJCQkgPSAwICgweDApDQptbWFwKDB4MCwy Mjc4NCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfQU5PTiwtMSwweDApID0gNjczMDQ2NTI4 ICgweDI4MWRlMDAwKQ0KbXVubWFwKDB4MjgxZGUwMDAsMjI3ODQpCQkJID0gMCAoMHgwKQ0K c2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJ R1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJN fFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4 MCkNCnNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApDQpfX3N5 c2N0bCgweGJmYmZlMGUwLDB4MiwweGJmYmZlMTYwLDB4YmZiZmUwZGMsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweGJmYmZlMGUwLDB4MiwweGJmYmZlMjYwLDB4YmZiZmUwZGMs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZlMGUwLDB4MiwweGJmYmZlMzYw LDB4YmZiZmUwZGMsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZlMGUwLDB4 MiwweGJmYmZlNDYwLDB4YmZiZmUwZGMsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eGJmYmZlMGUwLDB4MiwweGJmYmZlNTYwLDB4YmZiZmUwZGMsMHgwLDB4MCkgPSAwICgweDAp DQpyZWFkbGluaygiL2V0Yy9tYWxsb2MuY29uZiIsMHhiZmJmZTA5MCw2MykJIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0KaXNzZXR1Z2lkKCkJCQkJCSA9IDAgKDB4MCkN Cm1tYXAoMHgwLDQwOTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FO T04sLTEsMHgwKSA9IDY3MzA0NjUyOCAoMHgyODFkZTAwMCkNCmJyZWFrKDB4ODA1YzAwMCkJ CQkJID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDVkMDAwKQkJCQkgPSAwICgweDApDQpnZXR0aW1l b2ZkYXkoezEyMjI2Mzc1MzEuNTcxNjM5fSwweDApCQkgPSAwICgweDApDQpmc3RhdCgxLHtt b2RlPWNydy0tdy0tLS0gLGlub2RlPTExNCxzaXplPTAsYmxrc2l6ZT00MDk2fSkgPSAwICgw eDApDQpicmVhaygweDgwNWUwMDApCQkJCSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZiZmUw NDgsMHgyLDB4YmZiZmUwNTAsMHhiZmJmZTA0NCwweDgwNTY1YTIsMHhkKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4YmZiZmUwNTAsMHgzLDB4YmZiZmU2OTQsMHhiZmJmZTEwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZiZmUwNDgsMHgyLDB4YmZiZmUwNTAsMHhiZmJm ZTA0NCwweDgwNTY1YjAsMHgxMCkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZlMDUwLDB4 MywweGJmYmZlNjk4LDB4YmZiZmUxMDAsMHgwLDB4MCkgPSAwICgweDApDQpicmVhaygweDgw NWYwMDApCQkJCSA9IDAgKDB4MCkNCmJyZWFrKDB4ODA2MDAwMCkJCQkJID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTAxOCwweDIsMHgyODFjYWEwMCwweGJmYmZlMDE0LDB4MCwweDAp ID0gMCAoMHgwKQ0Kb3BlbigiL2Rldi9udWxsIixPX1JET05MWSwwMCkJCQkgPSA0ICgweDQp DQpmc3RhdCg0LHttb2RlPWNydy1ydy1ydy0gLGlub2RlPTIxLHNpemU9MCxibGtzaXplPTQw OTZ9KSA9IDAgKDB4MCkNCmZjbnRsKDQsRl9TRVRGRCxGRF9DTE9FWEVDKQkJCSA9IDAgKDB4 MCkNCm9wZW4oIi9kZXYvbnVsbCIsT19SRE9OTFksMDEpCQkJID0gNSAoMHg1KQ0KX19zeXNj dGwoMHhiZmJmZTA0OCwweDIsMHhiZmJmZTA1MCwweGJmYmZlMDQ0LDB4ODA1NjVjYiwweGQp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA1MCwweDIsMHhiZmJmZTBmMCwweGJmYmZl MTAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTBiOCwweDIsMHgyODFk YWQ5YywweGJmYmZlMGI0LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3MzI0LDB4YmZiZmUwYzAsMHg4MDU2MTFlLDB4MTQpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3MzRjLDB4YmZiZmUwYzAsMHg4MDU2MTMz LDB4MTMpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3Mzc0LDB4 YmZiZmUwYzAsMHg4MDU2MTQ3LDB4MTMpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3MzljLDB4YmZiZmUwYzAsMHg4MDU2MTViLDB4MTMpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3M2M0LDB4YmZiZmUwYzAsMHg4MDU2MTZm LDB4MTMpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3M2VjLDB4 YmZiZmUwYzAsMHg4MDU2MTgzLDB4MTQpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3NDE0LDB4YmZiZmUwYzAsMHg4MDU2MTk4LDB4MTQpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NDNjLDB4YmZiZmUwYzAsMHg4MDU2MWFk LDB4MTcpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NDY0LDB4 YmZiZmUwYzAsMHg4MDU2MWM1LDB4MTQpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3NDhjLDB4YmZiZmUwYzAsMHg4MDU2MWRhLDB4MTUpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NGI0LDB4YmZiZmUwYzAsMHg4MDU2MWYw LDB4MTMpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NGRjLDB4 YmZiZmUwYzAsMHg4MDU2MjA0LDB4MTUpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3NTA0LDB4YmZiZmUwYzAsMHg4MDU2MjFhLDB4MTYpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NTJjLDB4YmZiZmUwYzAsMHg4MDU2MjMx LDB4MWEpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NTU0LDB4 YmZiZmUwYzAsMHg4MDU2MjRjLDB4MWMpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3NTdjLDB4YmZiZmUwYzAsMHg4MDU2MjY5LDB4MTgpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NWE0LDB4YmZiZmUwYzAsMHg4MDU2Mjgy LDB4MTkpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NWNjLDB4 YmZiZmUwYzAsMHg4MDU2MjljLDB4MTgpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5 MCwweDIsMHg4MDU3NWY0LDB4YmZiZmUwYzAsMHg4MDU2MmI1LDB4MTcpID0gMCAoMHgwKQ0K X19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NjFjLDB4YmZiZmUwYzAsMHg4MDU2MmNk LDB4MTgpID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZTA5MCwweDIsMHg4MDU3NjQ0LDB4 YmZiZmUwYzAsMHg4MDU2MmU2LDB4YykgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZlMDkw LDB4MiwweDgwNTc2NmMsMHhiZmJmZTBjMCwweDgwNTYyZjMsMHhjKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4YmZiZmUwOTAsMHgyLDB4ODA1NzY5NCwweGJmYmZlMGMwLDB4ODA1NjMwMCww eGQpIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0KYnJlYWsoMHg4MDYxMDAw KQkJCQkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZlMDkwLDB4MiwweDgwNThlYTAsMHhi ZmJmZTBjNCwweDgwNTY0NjgsMHhjKSA9IDAgKDB4MCkNCmJyZWFrKDB4ODA2NjAwMCkJCQkJ ID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDY3MDAwKQkJCQkgPSAwICgweDApDQppb2N0bCgxLFRJ T0NHRVRBLDB4YmZiZmRjMDApCQkJID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDY4MDAwKQkJCQkg PSAwICgweDApDQppc3NldHVnaWQoKQkJCQkJID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDY5MDAw KQkJCQkgPSAwICgweDApDQpicmVhaygweDgwNmEwMDApCQkJCSA9IDAgKDB4MCkNCmJyZWFr KDB4ODA2YjAwMCkJCQkJID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDZjMDAwKQkJCQkgPSAwICgw eDApDQppb2N0bCgxLFRJT0NHRVRBLDB4YmZiZmRjMDApCQkJID0gMCAoMHgwKQ0KaW9jdGwo MSxUSU9DR0VUQSwweDgwNjcwNTgpCQkJID0gMCAoMHgwKQ0KaW9jdGwoMSxUSU9DR0VUQSww eGJmYmZkYmMwKQkJCSA9IDAgKDB4MCkNCmlvY3RsKDEsVElPQ0dXSU5TWiwweGJmYmZkYzIw KQkJCSA9IDAgKDB4MCkNCmlvY3RsKDEsVElPQ0dXSU5TWiwweGJmYmZlMGQwKQkJCSA9IDAg KDB4MCkNCmlvY3RsKDEsVElPQ0dFVEEsMHg4MDU5YTYwKQkJCSA9IDAgKDB4MCkNCmJyZWFr KDB4ODA3MDAwMCkJCQkJID0gMCAoMHgwKQ0KYnJlYWsoMHg4MDc0MDAwKQkJCQkgPSAwICgw eDApDQpzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSU5UfFNJR1FVSVR8U0lHVFNUUHxTSUdX SU5DSCwweDApID0gMCAoMHgwKQ0KaW9jdGwoMSxUSU9DR0VUQSwweDgwNTlhNjApCQkJID0g MCAoMHgwKQ0KaW9jdGwoMSxUSU9DU0VUQVcsMHg4MDU5YWEwKQkJCSA9IDAgKDB4MCkNCnNp Z2FjdGlvbihTSUdJTlQseyAweDgwNTEwOTEgMHgwIHNzX3QgfSwweDApCSA9IDAgKDB4MCkN CnNpZ2FjdGlvbihTSUdRVUlULHsgMHg4MDUxMDkxIDB4MCBzc190IH0sMHgwKQkgPSAwICgw eDApDQpzaWdhY3Rpb24oU0lHVFNUUCx7IDB4ODA1MTBhOCAweDAgc3NfdCB9LDB4MCkJID0g MCAoMHgwKQ0Kc2lnYWN0aW9uKFNJR1dJTkNILHsgMHg4MDUxMTIxIDB4MCBzc190IH0sMHgw KQkgPSAwICgweDApDQpzaWdwcm9jbWFzayhTSUdfQkxPQ0ssMHgwLFNJR0lOVHxTSUdRVUlU fFNJR1RTVFB8U0lHV0lOQ0gpID0gMCAoMHgwKQ0Kc2lncHJvY21hc2soU0lHX1VOQkxPQ0ss U0lHSU5UfFNJR1FVSVR8U0lHVFNUUHxTSUdXSU5DSCwweDApID0gMCAoMHgwKQ0KZ2V0dGlt ZW9mZGF5KHsxMjIyNjM3NTMxLjYwODMyMn0sMHgwKQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9m ZGF5KHsxMjIyNjM3NTMxLjYwODg1NH0sMHgwKQkJID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhi ZmJmZGVmOCwweDIsMHhiZmJmZGYwMCwweGJmYmZkZWY0LDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3NjZjLDB4MiwweDgwNWUwMDAsMHhiZmJmZGYyMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzMyNCwweDQsMHhiZmJmZGY3MCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzRjLDB4NCwweGJmYmZkZjc0 LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczNzQsMHg0 LDB4YmZiZmRmN2MsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzM5YywweDQsMHhiZmJmZGY4MCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3M2VjLDB4NCwweGJmYmZlMDE4LDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczYzQsMHg0LDB4YmZiZmUwMTQsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQxNCwweDQsMHhiZmJmZTAx YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDNjLDB4 NCwweGJmYmZkZjg0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc0NjQsMHg0LDB4YmZiZmRmOTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzQ4YywweDQsMHhiZmJmZGY5YywweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGI0LDB4NCwweGJmYmZkZmQwLDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0ZGMsMHg0LDB4YmZiZmRm YTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzUwNCww eDQsMHhiZmJmZGZhYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3NTJjLDB4NCwweGJmYmZkZmYwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc1NTQsMHg0LDB4YmZiZmRmZjgsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU3YywweDQsMHhiZmJmZGZlYywweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWE0LDB4NCwweGJmYmZk ZmZjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1Y2Ms MHg0LDB4YmZiZmRmZTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzVmNCwweDQsMHhiZmJmZGZhMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NjFjLDB4NCwweGJmYmZkZmE0LDB4YmZiZmRmMDAsMHgwLDB4 MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2NDQsMHgyLDB4ODA1OGUyOCwweGJmYmZk ZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU4ZWEwLDB4MywweGJmYmZk ZWQwLDB4YmZiZmRmMDgsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNThlYTAs MHgzLDB4YmZiZmRlZDAsMHhiZmJmZGYwOCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1OGVhMCwweDMsMHhiZmJmZGVkMCwweGJmYmZkZjA4LDB4MCwweDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jw0KX19zeXNjdGwoMHg4MDU3NmU0LDB4MCwweGJm YmZlMGEwLDB4YmZiZmRmMjAsMHgwLDB4MCkgRVJSIzIyICdJbnZhbGlkIGFyZ3VtZW50Jw0K d3JpdGUoMSwiXF5bWz8xMDQ5aCIsOCkJCQkJID0gOCAoMHg4KQ0KX19zeXNjdGwoMHg4MDU3 NmJjLDB4MCwweDAsMHhiZmJmZGZjNCwweDAsMHgwKQkgRVJSIzIyICdJbnZhbGlkIGFyZ3Vt ZW50Jw0KaXNzZXR1Z2lkKCkJCQkJCSA9IDAgKDB4MCkNCm9wZW4oIi91c3Ivc2hhcmUvem9u ZWluZm8vVVRDIixPX1JET05MWSwwMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5Jw0KaXNzZXR1Z2lkKCkJCQkJCSA9IDAgKDB4MCkNCm9wZW4oIi91c3Ivc2hhcmUvem9u ZWluZm8vcG9zaXhydWxlcyIsT19SRE9OTFksMDUwMDIwNDIwMDApID0gNiAoMHg2KQ0KZnN0 YXQoNix7bW9kZT0tci0tci0tci0tICxpbm9kZT0zMzYwMTcsc2l6ZT0xMjY3LGJsa3NpemU9 NDA5Nn0pID0gMCAoMHgwKQ0KcmVhZCg2LCJUWmlmXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMCIuLi4sNzk0NCkgPSAxMjY3ICgweDRmMykNCmNsb3NlKDYpCQkJCQkgPSAwICgweDAp DQphY2Nlc3MoIi9ldGMvbG9jYWx0aW1lIiw0KQkJCSA9IDAgKDB4MCkNCm9wZW4oIi9ldGMv bG9jYWx0aW1lIixPX1JET05MWSwwMTQwNzQwMDMyNzApCSA9IDYgKDB4NikNCmZzdGF0KDYs e21vZGU9LXItLXItLXItLSAsaW5vZGU9NTAyODgsc2l6ZT04MDYsYmxrc2l6ZT00MDk2fSkg PSAwICgweDApDQpyZWFkKDYsIlRaaWZcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4u Liw3OTQ0KSA9IDgwNiAoMHgzMjYpDQpjbG9zZSg2KQkJCQkJID0gMCAoMHgwKQ0Kd3JpdGUo MSwiXF5bW0hcXltbSmxhc3QgcGlkOiAtMTA3Nzk0NDExMjsiLi4uLDQ2OCkgPSA0NjggKDB4 MWQ0KQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTMxLjYzMjczN30sMHgwKQkJID0gMCAoMHgw KQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTMxLjYzMzcyOH0sMHgwKQkJID0gMCAoMHgwKQ0K c2VsZWN0KDIsezB9LDB4MCwweDAsezAuOTk5MDA5fSkJCSA9IDAgKDB4MCkNCmdldHRpbWVv ZmRheSh7MTIyMjYzNzUzMi42MzQ5ODR9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRh eSh7MTIyMjYzNzUzMi42MzUzOTZ9LDB4MCkJCSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZi ZmRmMDgsMHgyLDB4YmZiZmRmMTAsMHhiZmJmZGYwNCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzY2YywweDIsMHg4MDVlMDAwLDB4YmZiZmRmMzAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTczMjQsMHg0LDB4YmZiZmRmODAsMHhiZmJmZGYxMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM0YywweDQsMHhiZmJmZGY4NCww eGJmYmZkZjEwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3Mzc0LDB4NCww eGJmYmZkZjhjLDB4YmZiZmRmMTAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTczOWMsMHg0LDB4YmZiZmRmOTAsMHhiZmJmZGYxMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzNlYywweDQsMHhiZmJmZTAyOCwweGJmYmZkZjEwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2M0LDB4NCwweGJmYmZlMDI0LDB4YmZiZmRmMTAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0MTQsMHg0LDB4YmZiZmUwMmMs MHhiZmJmZGYxMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQzYywweDQs MHhiZmJmZGY5NCwweGJmYmZkZjEwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3NDY0LDB4NCwweGJmYmZkZmE4LDB4YmZiZmRmMTAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc0OGMsMHg0LDB4YmZiZmRmYWMsMHhiZmJmZGYxMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRiNCwweDQsMHhiZmJmZGZlMCwweGJmYmZkZjEw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGRjLDB4NCwweGJmYmZkZmI4 LDB4YmZiZmRmMTAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MDQsMHg0 LDB4YmZiZmRmYmMsMHhiZmJmZGYxMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzUyYywweDQsMHhiZmJmZTAwMCwweGJmYmZkZjEwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3NTU0LDB4NCwweGJmYmZlMDA4LDB4YmZiZmRmMTAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1N2MsMHg0LDB4YmZiZmRmZmMsMHhiZmJmZGYx MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVhNCwweDQsMHhiZmJmZTAw YywweGJmYmZkZjEwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWNjLDB4 NCwweGJmYmZkZmY4LDB4YmZiZmRmMTAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc1ZjQsMHg0LDB4YmZiZmRmYjAsMHhiZmJmZGYxMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzYxYywweDQsMHhiZmJmZGZiNCwweGJmYmZkZjEwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjQ0LDB4MiwweDgwNThlMjgsMHhiZmJmZGYz MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzZlNCwweDAsMHhiZmJmZTBh MCwweGJmYmZkZjMwLDB4MCwweDApIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCndyaXRl KDEsIlxeW1szOzhIOC40XF5bWzM7MzFINDQuMFxeW1szOzYyIi4uLiwzNSkgPSAzNSAoMHgy MykNCmdldHRpbWVvZmRheSh7MTIyMjYzNzUzMi42NDg5Mjd9LDB4MCkJCSA9IDAgKDB4MCkN CnNlbGVjdCgyLHswfSwweDAsMHgwLHswLjk4MzgxMH0pCQkgPSAwICgweDApDQpnZXR0aW1l b2ZkYXkoezEyMjI2Mzc1MzMuNjM0ODk1fSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2Zk YXkoezEyMjI2Mzc1MzMuNjM1MTQ1fSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXko ezEyMjI2Mzc1MzMuNjM1Mzk2fSwweDApCQkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZk ZWY4LDB4MiwweGJmYmZkZjAwLDB4YmZiZmRlZjQsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc2NmMsMHgyLDB4ODA1ZTAwMCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3MzI0LDB4NCwweGJmYmZkZjcwLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczNGMsMHg0LDB4YmZiZmRmNzQsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM3NCwweDQsMHhi ZmJmZGY3YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 MzljLDB4NCwweGJmYmZkZjgwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTczZWMsMHg0LDB4YmZiZmUwMTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNjNCwweDQsMHhiZmJmZTAxNCwweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDE0LDB4NCwweGJmYmZlMDFjLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0M2MsMHg0LDB4 YmZiZmRmODQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzQ2NCwweDQsMHhiZmJmZGY5OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NDhjLDB4NCwweGJmYmZkZjljLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc0YjQsMHg0LDB4YmZiZmRmZDAsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRkYywweDQsMHhiZmJmZGZhOCww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTA0LDB4NCww eGJmYmZkZmFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc1MmMsMHg0LDB4YmZiZmRmZjAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzU1NCwweDQsMHhiZmJmZGZmOCwweGJmYmZkZjAwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTdjLDB4NCwweGJmYmZkZmVjLDB4YmZiZmRmMDAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1YTQsMHg0LDB4YmZiZmRmZmMs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVjYywweDQs MHhiZmJmZGZlOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3NWY0LDB4NCwweGJmYmZkZmEwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc2MWMsMHg0LDB4YmZiZmRmYTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY0NCwweDIsMHg4MDU4ZTI4LDB4YmZiZmRmMjAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2ZTQsMHgwLDB4YmZiZmUwYTAs MHhiZmJmZGYyMCwweDAsMHgwKSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQpfX3N5c2N0 bCgweDgwNTc2YmMsMHgwLDB4MCwweGJmYmZkZmM0LDB4MCwweDApCSBFUlIjMjIgJ0ludmFs aWQgYXJndW1lbnQnDQp3cml0ZSgxLCJcXltbMTsxMUggICAgMFxeW1sxOzMySDA5XF5bWzE7 NCIuLi4sMTU3KSA9IDE1NyAoMHg5ZCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzUzMy42NDE5 NzV9LDB4MCkJCSA9IDAgKDB4MCkNCnNlbGVjdCgyLHswfSwweDAsMHgwLHsxLjk5MzE3MH0p CQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1MzUuNjM3ODQxfSwweDApCQkg PSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1MzUuNjM4MDk0fSwweDApCQkgPSAw ICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1MzUuNjM4MzQ0fSwweDApCQkgPSAwICgw eDApDQpfX3N5c2N0bCgweGJmYmZkZWY4LDB4MiwweGJmYmZkZjAwLDB4YmZiZmRlZjQsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2NmMsMHgyLDB4ODA1ZTAwMCwweGJm YmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzI0LDB4NCwweGJm YmZkZjcwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTcz NGMsMHg0LDB4YmZiZmRmNzQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lz Y3RsKDB4ODA1NzM3NCwweDQsMHhiZmJmZGY3YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3MzljLDB4NCwweGJmYmZkZjgwLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczZWMsMHg0LDB4YmZiZmUwMTgsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNjNCwweDQsMHhi ZmJmZTAxNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NDE0LDB4NCwweGJmYmZlMDFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc0M2MsMHg0LDB4YmZiZmRmODQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ2NCwweDQsMHhiZmJmZGY5OCwweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDhjLDB4NCwweGJmYmZkZjljLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0YjQsMHg0LDB4 YmZiZmRmZDAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzRkYywweDQsMHhiZmJmZGZhOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NTA0LDB4NCwweGJmYmZkZmFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc1MmMsMHg0LDB4YmZiZmRmZjAsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU1NCwweDQsMHhiZmJmZGZmOCww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTdjLDB4NCww eGJmYmZkZmVjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc1YTQsMHg0LDB4YmZiZmRmZmMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzVjYywweDQsMHhiZmJmZGZlOCwweGJmYmZkZjAwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWY0LDB4NCwweGJmYmZkZmEwLDB4YmZiZmRmMDAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2MWMsMHg0LDB4YmZiZmRmYTQs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY0NCwweDIs MHg4MDU4ZTI4LDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc2ZTQsMHgwLDB4YmZiZmUwYTAsMHhiZmJmZGYyMCwweDAsMHgwKSBFUlIjMjIgJ0ludmFs aWQgYXJndW1lbnQnDQpfX3N5c2N0bCgweDgwNTc2YmMsMHgwLDB4MCwweGJmYmZkZmM0LDB4 MCwweDApCSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQp3cml0ZSgxLCJcXltbMTsxNTdI NVxeW1sxOzE0NEgzXF5bWzM7OEgwLiIuLi4sMTE4KSA9IDExOCAoMHg3NikNCmdldHRpbWVv ZmRheSh7MTIyMjYzNzUzNS42NDUyMDV9LDB4MCkJCSA9IDAgKDB4MCkNCnNlbGVjdCgyLHsw fSwweDAsMHgwLHsxLjk5Mjg4OX0pCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2 Mzc1MzcuNjM5NjU5fSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1 MzcuNjM5OTExfSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1Mzcu NjQwMTY0fSwweDApCQkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZkZWY4LDB4MiwweGJm YmZkZjAwLDB4YmZiZmRlZjQsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2 NmMsMHgyLDB4ODA1ZTAwMCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3MzI0LDB4NCwweGJmYmZkZjcwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTczNGMsMHg0LDB4YmZiZmRmNzQsMHhiZmJmZGYwMCwweDAs MHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM3NCwweDQsMHhiZmJmZGY3YywweGJm YmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzljLDB4NCwweGJm YmZkZjgwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTcz ZWMsMHg0LDB4YmZiZmUwMTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lz Y3RsKDB4ODA1NzNjNCwweDQsMHhiZmJmZTAxNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3NDE0LDB4NCwweGJmYmZlMDFjLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0M2MsMHg0LDB4YmZiZmRmODQsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ2NCwweDQsMHhi ZmJmZGY5OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NDhjLDB4NCwweGJmYmZkZjljLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc0YjQsMHg0LDB4YmZiZmRmZDAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRkYywweDQsMHhiZmJmZGZhOCwweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTA0LDB4NCwweGJmYmZkZmFjLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MmMsMHg0LDB4 YmZiZmRmZjAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzU1NCwweDQsMHhiZmJmZGZmOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NTdjLDB4NCwweGJmYmZkZmVjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc1YTQsMHg0LDB4YmZiZmRmZmMsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVjYywweDQsMHhiZmJmZGZlOCww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWY0LDB4NCww eGJmYmZkZmEwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc2MWMsMHg0LDB4YmZiZmRmYTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzY0NCwweDIsMHg4MDU4ZTI4LDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc2ZTQsMHgwLDB4YmZiZmUwYTAsMHhiZmJmZGYyMCww eDAsMHgwKSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQpfX3N5c2N0bCgweDgwNTc2YmMs MHgwLDB4MCwweGJmYmZkZmM0LDB4MCwweDApCSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQn DQp3cml0ZSgxLCJcXltbMTszM0gwLCAgMC41OSwgIDAuNDVcXltbMTsxNSIuLi4sMTUzKSA9 IDE1MyAoMHg5OSkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzUzNy42NDY3MjZ9LDB4MCkJCSA9 IDAgKDB4MCkNCnNlbGVjdCgyLHswfSwweDAsMHgwLHsxLjk5MzE4NX0pCQkgPSAwICgweDAp DQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1MzkuNjQyNTM5fSwweDApCQkgPSAwICgweDApDQpn ZXR0aW1lb2ZkYXkoezEyMjI2Mzc1MzkuNjQyNzg4fSwweDApCQkgPSAwICgweDApDQpnZXR0 aW1lb2ZkYXkoezEyMjI2Mzc1MzkuNjQzMDM5fSwweDApCQkgPSAwICgweDApDQpfX3N5c2N0 bCgweGJmYmZkZWY4LDB4MiwweGJmYmZkZjAwLDB4YmZiZmRlZjQsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTc2NmMsMHgyLDB4ODA1ZTAwMCwweGJmYmZkZjIwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzI0LDB4NCwweGJmYmZkZjcwLDB4YmZi ZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczNGMsMHg0LDB4YmZi ZmRmNzQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM3 NCwweDQsMHhiZmJmZGY3YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3MzljLDB4NCwweGJmYmZkZjgwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTczZWMsMHg0LDB4YmZiZmUwMTgsMHhiZmJmZGYwMCwweDAs MHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNjNCwweDQsMHhiZmJmZTAxNCwweGJm YmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDE0LDB4NCwweGJm YmZlMDFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0 M2MsMHg0LDB4YmZiZmRmODQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lz Y3RsKDB4ODA1NzQ2NCwweDQsMHhiZmJmZGY5OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3NDhjLDB4NCwweGJmYmZkZjljLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0YjQsMHg0LDB4YmZiZmRmZDAsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRkYywweDQsMHhi ZmJmZGZhOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NTA0LDB4NCwweGJmYmZkZmFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc1MmMsMHg0LDB4YmZiZmRmZjAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU1NCwweDQsMHhiZmJmZGZmOCwweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTdjLDB4NCwweGJmYmZkZmVjLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1YTQsMHg0LDB4 YmZiZmRmZmMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzVjYywweDQsMHhiZmJmZGZlOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NWY0LDB4NCwweGJmYmZkZmEwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc2MWMsMHg0LDB4YmZiZmRmYTQsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY0NCwweDIsMHg4MDU4ZTI4LDB4 YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2ZTQsMHgwLDB4 YmZiZmUwYTAsMHhiZmJmZGYyMCwweDAsMHgwKSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQn DQpfX3N5c2N0bCgweDgwNTc2YmMsMHgwLDB4MCwweGJmYmZkZmM0LDB4MCwweDApCSBFUlIj MjIgJ0ludmFsaWQgYXJndW1lbnQnDQp3cml0ZSgxLCJcXltbMTsxNTdIOVxeW1sxOzE0NEg3 XF5bWzM7MTBIMiIuLi4sOTgpID0gOTggKDB4NjIpDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1 MzkuNjQ5ODYwfSwweDApCQkgPSAwICgweDApDQpzZWxlY3QoMix7MH0sMHgwLDB4MCx7MS45 OTI5Mjh9KQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTQxLjY0NDQxOH0s MHgwKQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTQxLjY0NDY2N30sMHgw KQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTQxLjY0NDkxOH0sMHgwKQkJ ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZGVmOCwweDIsMHhiZmJmZGYwMCwweGJmYmZk ZWY0LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjZjLDB4MiwweDgwNWUw MDAsMHhiZmJmZGYyMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzMyNCww eDQsMHhiZmJmZGY3MCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3MzRjLDB4NCwweGJmYmZkZjc0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTczNzQsMHg0LDB4YmZiZmRmN2MsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM5YywweDQsMHhiZmJmZGY4MCwweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2VjLDB4NCwweGJmYmZl MDE4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczYzQs MHg0LDB4YmZiZmUwMTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzQxNCwweDQsMHhiZmJmZTAxYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NDNjLDB4NCwweGJmYmZkZjg0LDB4YmZiZmRmMDAsMHgwLDB4 MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0NjQsMHg0LDB4YmZiZmRmOTgsMHhiZmJm ZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ4YywweDQsMHhiZmJm ZGY5YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGI0 LDB4NCwweGJmYmZkZmQwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0 bCgweDgwNTc0ZGMsMHg0LDB4YmZiZmRmYTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzUwNCwweDQsMHhiZmJmZGZhYywweGJmYmZkZjAwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTJjLDB4NCwweGJmYmZkZmYwLDB4YmZi ZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1NTQsMHg0LDB4YmZi ZmRmZjgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU3 YywweDQsMHhiZmJmZGZlYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3NWE0LDB4NCwweGJmYmZkZmZjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTc1Y2MsMHg0LDB4YmZiZmRmZTgsMHhiZmJmZGYwMCwweDAs MHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVmNCwweDQsMHhiZmJmZGZhMCwweGJm YmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjFjLDB4NCwweGJm YmZkZmE0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2 NDQsMHgyLDB4ODA1OGUyOCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3NmU0LDB4MCwweGJmYmZlMGEwLDB4YmZiZmRmMjAsMHgwLDB4MCkgRVJSIzIy ICdJbnZhbGlkIGFyZ3VtZW50Jw0KX19zeXNjdGwoMHg4MDU3NmJjLDB4MCwweDAsMHhiZmJm ZGZjNCwweDAsMHgwKQkgRVJSIzIyICdJbnZhbGlkIGFyZ3VtZW50Jw0Kd3JpdGUoMSwiXF5b WzE7MzBIMC45MiwgIDAuNThcXltbMTsxNTZIMjEiLi4uLDc1KSA9IDc1ICgweDRiKQ0KZ2V0 dGltZW9mZGF5KHsxMjIyNjM3NTQxLjY1MTQ4MX0sMHgwKQkJID0gMCAoMHgwKQ0Kc2VsZWN0 KDIsezB9LDB4MCwweDAsezEuOTkzMTg2fSkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7 MTIyMjYzNzU0My42NDcyOTR9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIy MjYzNzU0My42NDc1NDN9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYz NzU0My42NDc3OTR9LDB4MCkJCSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZiZmRlZjgsMHgy LDB4YmZiZmRmMDAsMHhiZmJmZGVmNCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzY2YywweDIsMHg4MDVlMDAwLDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTczMjQsMHg0LDB4YmZiZmRmNzAsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM0YywweDQsMHhiZmJmZGY3NCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3Mzc0LDB4NCwweGJmYmZkZjdj LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczOWMsMHg0 LDB4YmZiZmRmODAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzNlYywweDQsMHhiZmJmZTAxOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3M2M0LDB4NCwweGJmYmZlMDE0LDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0MTQsMHg0LDB4YmZiZmUwMWMsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQzYywweDQsMHhiZmJmZGY4 NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDY0LDB4 NCwweGJmYmZkZjk4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc0OGMsMHg0LDB4YmZiZmRmOWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzRiNCwweDQsMHhiZmJmZGZkMCwweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGRjLDB4NCwweGJmYmZkZmE4LDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MDQsMHg0LDB4YmZiZmRm YWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzUyYyww eDQsMHhiZmJmZGZmMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3NTU0LDB4NCwweGJmYmZkZmY4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc1N2MsMHg0LDB4YmZiZmRmZWMsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVhNCwweDQsMHhiZmJmZGZmYywweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWNjLDB4NCwweGJmYmZk ZmU4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1ZjQs MHg0LDB4YmZiZmRmYTAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzYxYywweDQsMHhiZmJmZGZhNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NjQ0LDB4MiwweDgwNThlMjgsMHhiZmJmZGYyMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzZlNCwweDAsMHhiZmJmZTBhMCwweGJmYmZk ZjIwLDB4MCwweDApIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCl9fc3lzY3RsKDB4ODA1 NzZiYywweDAsMHgwLDB4YmZiZmRmYzQsMHgwLDB4MCkJIEVSUiMyMiAnSW52YWxpZCBhcmd1 bWVudCcNCndyaXRlKDEsIlxeW1sxOzE1N0gzXF5bWzE7MTQzSDUxXF5bWzM7MTBIIi4uLiwx MTUpID0gMTE1ICgweDczKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTQzLjY1NDM4OX0sMHgw KQkJID0gMCAoMHgwKQ0Kc2VsZWN0KDIsezB9LDB4MCwweDAsezEuOTkzMTU0fSkJCSA9IDAg KDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU0NS42NTAxNzR9LDB4MCkJCSA9IDAgKDB4 MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU0NS42NTA0MjR9LDB4MCkJCSA9IDAgKDB4MCkN CmdldHRpbWVvZmRheSh7MTIyMjYzNzU0NS42NTA2Nzd9LDB4MCkJCSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4YmZiZmRlZjgsMHgyLDB4YmZiZmRmMDAsMHhiZmJmZGVmNCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY2YywweDIsMHg4MDVlMDAwLDB4YmZiZmRmMjAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczMjQsMHg0LDB4YmZiZmRmNzAs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM0YywweDQs MHhiZmJmZGY3NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3Mzc0LDB4NCwweGJmYmZkZjdjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTczOWMsMHg0LDB4YmZiZmRmODAsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNlYywweDQsMHhiZmJmZTAxOCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2M0LDB4NCwweGJmYmZlMDE0 LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0MTQsMHg0 LDB4YmZiZmUwMWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzQzYywweDQsMHhiZmJmZGY4NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3NDY0LDB4NCwweGJmYmZkZjk4LDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0OGMsMHg0LDB4YmZiZmRmOWMsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRiNCwweDQsMHhiZmJmZGZk MCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGRjLDB4 NCwweGJmYmZkZmE4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc1MDQsMHg0LDB4YmZiZmRmYWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzUyYywweDQsMHhiZmJmZGZmMCwweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTU0LDB4NCwweGJmYmZkZmY4LDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1N2MsMHg0LDB4YmZiZmRm ZWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVhNCww eDQsMHhiZmJmZGZmYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3NWNjLDB4NCwweGJmYmZkZmU4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc1ZjQsMHg0LDB4YmZiZmRmYTAsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzYxYywweDQsMHhiZmJmZGZhNCwweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjQ0LDB4MiwweDgwNThl MjgsMHhiZmJmZGYyMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzZlNCww eDAsMHhiZmJmZTBhMCwweGJmYmZkZjIwLDB4MCwweDApIEVSUiMyMiAnSW52YWxpZCBhcmd1 bWVudCcNCl9fc3lzY3RsKDB4ODA1NzZiYywweDAsMHgwLDB4YmZiZmRmYzQsMHgwLDB4MCkJ IEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCndyaXRlKDEsIlxeW1sxOzE1N0g1XF5bWzE7 MTQ0SDNcXltbNDs5SDkwIi4uLiw1NikgPSA1NiAoMHgzOCkNCmdldHRpbWVvZmRheSh7MTIy MjYzNzU0NS42NTcyNjZ9LDB4MCkJCSA9IDAgKDB4MCkNCnNlbGVjdCgyLHswfSwweDAsMHgw LHsxLjk5MzE1OH0pCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NDcuNjUz MDQ2fSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NDcuNjUzMjk3 fSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NDcuNjUzNTQ4fSww eDApCQkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZkZWY4LDB4MiwweGJmYmZkZjAwLDB4 YmZiZmRlZjQsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2NmMsMHgyLDB4 ODA1ZTAwMCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 MzI0LDB4NCwweGJmYmZkZjcwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTczNGMsMHg0LDB4YmZiZmRmNzQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM3NCwweDQsMHhiZmJmZGY3YywweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzljLDB4NCwweGJmYmZkZjgwLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczZWMsMHg0LDB4 YmZiZmUwMTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzNjNCwweDQsMHhiZmJmZTAxNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NDE0LDB4NCwweGJmYmZlMDFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc0M2MsMHg0LDB4YmZiZmRmODQsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ2NCwweDQsMHhiZmJmZGY5OCww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDhjLDB4NCww eGJmYmZkZjljLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc0YjQsMHg0LDB4YmZiZmRmZDAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzRkYywweDQsMHhiZmJmZGZhOCwweGJmYmZkZjAwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTA0LDB4NCwweGJmYmZkZmFjLDB4YmZiZmRmMDAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MmMsMHg0LDB4YmZiZmRmZjAs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU1NCwweDQs MHhiZmJmZGZmOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3NTdjLDB4NCwweGJmYmZkZmVjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc1YTQsMHg0LDB4YmZiZmRmZmMsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVjYywweDQsMHhiZmJmZGZlOCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWY0LDB4NCwweGJmYmZkZmEw LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2MWMsMHg0 LDB4YmZiZmRmYTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzY0NCwweDIsMHg4MDU4ZTI4LDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc2ZTQsMHgwLDB4YmZiZmUwYTAsMHhiZmJmZGYyMCwweDAsMHgwKSBF UlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQpfX3N5c2N0bCgweDgwNTc2YmMsMHgwLDB4MCww eGJmYmZkZmM0LDB4MCwweDApCSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQp3cml0ZSgx LCJcXltbMTszMkg4NSwgIDAuNTdcXltbMTsxNTdIN1xeWyIuLi4sODgpID0gODggKDB4NTgp DQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NDcuNjYwMTQwfSwweDApCQkgPSAwICgweDApDQpz ZWxlY3QoMix7MH0sMHgwLDB4MCx7MS45OTMxNTd9KQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9m ZGF5KHsxMjIyNjM3NTQ5LjY1NTkyMH0sMHgwKQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5 KHsxMjIyNjM3NTQ5LjY1NjE3MH0sMHgwKQkJID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsx MjIyNjM3NTQ5LjY1NjQyMn0sMHgwKQkJID0gMCAoMHgwKQ0KX19zeXNjdGwoMHhiZmJmZGVm OCwweDIsMHhiZmJmZGYwMCwweGJmYmZkZWY0LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3NjZjLDB4MiwweDgwNWUwMDAsMHhiZmJmZGYyMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzMyNCwweDQsMHhiZmJmZGY3MCwweGJmYmZkZjAwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzRjLDB4NCwweGJmYmZkZjc0LDB4YmZi ZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczNzQsMHg0LDB4YmZi ZmRmN2MsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM5 YywweDQsMHhiZmJmZGY4MCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3M2VjLDB4NCwweGJmYmZlMDE4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTczYzQsMHg0LDB4YmZiZmUwMTQsMHhiZmJmZGYwMCwweDAs MHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQxNCwweDQsMHhiZmJmZTAxYywweGJm YmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDNjLDB4NCwweGJm YmZkZjg0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0 NjQsMHg0LDB4YmZiZmRmOTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lz Y3RsKDB4ODA1NzQ4YywweDQsMHhiZmJmZGY5YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3NGI0LDB4NCwweGJmYmZkZmQwLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0ZGMsMHg0LDB4YmZiZmRmYTgsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzUwNCwweDQsMHhi ZmJmZGZhYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NTJjLDB4NCwweGJmYmZkZmYwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc1NTQsMHg0LDB4YmZiZmRmZjgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU3YywweDQsMHhiZmJmZGZlYywweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWE0LDB4NCwweGJmYmZkZmZjLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1Y2MsMHg0LDB4 YmZiZmRmZTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzVmNCwweDQsMHhiZmJmZGZhMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3NjFjLDB4NCwweGJmYmZkZmE0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc2NDQsMHgyLDB4ODA1OGUyOCwweGJmYmZkZjIwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NmU0LDB4MCwweGJmYmZlMGEwLDB4 YmZiZmRmMjAsMHgwLDB4MCkgRVJSIzIyICdJbnZhbGlkIGFyZ3VtZW50Jw0KX19zeXNjdGwo MHg4MDU3NmJjLDB4MCwweDAsMHhiZmJmZGZjNCwweDAsMHgwKQkgRVJSIzIyICdJbnZhbGlk IGFyZ3VtZW50Jw0Kd3JpdGUoMSwiXF5bWzE7MTU3SDlcXltbMTsxNDRIN1xeW1szOzM0SDAi Li4uLDEwNCkgPSAxMDQgKDB4NjgpDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NDkuNjYzMDky fSwweDApCQkgPSAwICgweDApDQpzZWxlY3QoMix7MH0sMHgwLDB4MCx7MS45OTMwNzh9KQkJ ID0gMCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTUxLjY1ODc5N30sMHgwKQkJID0g MCAoMHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTUxLjY1OTA0OH0sMHgwKQkJID0gMCAo MHgwKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTUxLjY1OTMwMH0sMHgwKQkJID0gMCAoMHgw KQ0KX19zeXNjdGwoMHhiZmJmZGVmOCwweDIsMHhiZmJmZGYwMCwweGJmYmZkZWY0LDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjZjLDB4MiwweDgwNWUwMDAsMHhiZmJm ZGYyMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzMyNCwweDQsMHhiZmJm ZGY3MCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzRj LDB4NCwweGJmYmZkZjc0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0 bCgweDgwNTczNzQsMHg0LDB4YmZiZmRmN2MsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzM5YywweDQsMHhiZmJmZGY4MCwweGJmYmZkZjAwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2VjLDB4NCwweGJmYmZlMDE4LDB4YmZi ZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczYzQsMHg0LDB4YmZi ZmUwMTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQx NCwweDQsMHhiZmJmZTAxYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3NDNjLDB4NCwweGJmYmZkZjg0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgw eDApDQpfX3N5c2N0bCgweDgwNTc0NjQsMHg0LDB4YmZiZmRmOTgsMHhiZmJmZGYwMCwweDAs MHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ4YywweDQsMHhiZmJmZGY5YywweGJm YmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGI0LDB4NCwweGJm YmZkZmQwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0 ZGMsMHg0LDB4YmZiZmRmYTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lz Y3RsKDB4ODA1NzUwNCwweDQsMHhiZmJmZGZhYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAo MHgwKQ0KX19zeXNjdGwoMHg4MDU3NTJjLDB4NCwweGJmYmZkZmYwLDB4YmZiZmRmMDAsMHgw LDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1NTQsMHg0LDB4YmZiZmRmZjgsMHhi ZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU3YywweDQsMHhi ZmJmZGZlYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NWE0LDB4NCwweGJmYmZkZmZjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5 c2N0bCgweDgwNTc1Y2MsMHg0LDB4YmZiZmRmZTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAg KDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVmNCwweDQsMHhiZmJmZGZhMCwweGJmYmZkZjAwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjFjLDB4NCwweGJmYmZkZmE0LDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2NDQsMHgyLDB4 ODA1OGUyOCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3 NmU0LDB4MCwweGJmYmZlMGEwLDB4YmZiZmRmMjAsMHgwLDB4MCkgRVJSIzIyICdJbnZhbGlk IGFyZ3VtZW50Jw0KX19zeXNjdGwoMHg4MDU3NmJjLDB4MCwweDAsMHhiZmJmZGZjNCwweDAs MHgwKQkgRVJSIzIyICdJbnZhbGlkIGFyZ3VtZW50Jw0Kd3JpdGUoMSwiXF5bWzE7MTU2SDMx XF5bWzE7MTQ0SDlcXltbMzszNEgiLi4uLDU4KSA9IDU4ICgweDNhKQ0KZ2V0dGltZW9mZGF5 KHsxMjIyNjM3NTUxLjY2NTkwNH0sMHgwKQkJID0gMCAoMHgwKQ0Kc2VsZWN0KDIsezB9LDB4 MCwweDAsezEuOTkzMTQ0fSkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1 My42NjE2Nzh9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1My42 NjE5Mjh9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1My42NjIx Nzl9LDB4MCkJCSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZiZmRlZjgsMHgyLDB4YmZiZmRm MDAsMHhiZmJmZGVmNCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY2Yyww eDIsMHg4MDVlMDAwLDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTczMjQsMHg0LDB4YmZiZmRmNzAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzM0YywweDQsMHhiZmJmZGY3NCwweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3Mzc0LDB4NCwweGJmYmZkZjdjLDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczOWMsMHg0LDB4YmZiZmRm ODAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNlYyww eDQsMHhiZmJmZTAxOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3M2M0LDB4NCwweGJmYmZlMDE0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc0MTQsMHg0LDB4YmZiZmUwMWMsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQzYywweDQsMHhiZmJmZGY4NCwweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDY0LDB4NCwweGJmYmZk Zjk4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0OGMs MHg0LDB4YmZiZmRmOWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzRiNCwweDQsMHhiZmJmZGZkMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NGRjLDB4NCwweGJmYmZkZmE4LDB4YmZiZmRmMDAsMHgwLDB4 MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MDQsMHg0LDB4YmZiZmRmYWMsMHhiZmJm ZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzUyYywweDQsMHhiZmJm ZGZmMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTU0 LDB4NCwweGJmYmZkZmY4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0 bCgweDgwNTc1N2MsMHg0LDB4YmZiZmRmZWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzVhNCwweDQsMHhiZmJmZGZmYywweGJmYmZkZjAwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWNjLDB4NCwweGJmYmZkZmU4LDB4YmZi ZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1ZjQsMHg0LDB4YmZi ZmRmYTAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzYx YywweDQsMHhiZmJmZGZhNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNj dGwoMHg4MDU3NjQ0LDB4MiwweDgwNThlMjgsMHhiZmJmZGYyMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzZlNCwweDAsMHhiZmJmZTBhMCwweGJmYmZkZjIwLDB4MCww eDApIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCl9fc3lzY3RsKDB4ODA1NzZiYywweDAs MHgwLDB4YmZiZmRmYzQsMHgwLDB4MCkJIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCndy aXRlKDEsIlxeW1sxOzMySDc4LCAgMC41NiwgIDAuNDRcXltbMTsxIi4uLiwxMDApID0gMTAw ICgweDY0KQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTUzLjY2ODY3Nn0sMHgwKQkJID0gMCAo MHgwKQ0Kc2VsZWN0KDIsezB9LDB4MCwweDAsezEuOTkzMjUyfSkJCSA9IDAgKDB4MCkNCmdl dHRpbWVvZmRheSh7MTIyMjYzNzU1NS42NjM1NTB9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRp bWVvZmRheSh7MTIyMjYzNzU1NS42NjM3OTl9LDB4MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVv ZmRheSh7MTIyMjYzNzU1NS42NjQwNDl9LDB4MCkJCSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 YmZiZmRlZjgsMHgyLDB4YmZiZmRmMDAsMHhiZmJmZGVmNCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzY2YywweDIsMHg4MDVlMDAwLDB4YmZiZmRmMjAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczMjQsMHg0LDB4YmZiZmRmNzAsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM0YywweDQsMHhiZmJmZGY3 NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3Mzc0LDB4 NCwweGJmYmZkZjdjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTczOWMsMHg0LDB4YmZiZmRmODAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzNlYywweDQsMHhiZmJmZTAxOCwweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2M0LDB4NCwweGJmYmZlMDE0LDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0MTQsMHg0LDB4YmZiZmUw MWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQzYyww eDQsMHhiZmJmZGY4NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3NDY0LDB4NCwweGJmYmZkZjk4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc0OGMsMHg0LDB4YmZiZmRmOWMsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRiNCwweDQsMHhiZmJmZGZkMCwweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NGRjLDB4NCwweGJmYmZk ZmE4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MDQs MHg0LDB4YmZiZmRmYWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzUyYywweDQsMHhiZmJmZGZmMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NTU0LDB4NCwweGJmYmZkZmY4LDB4YmZiZmRmMDAsMHgwLDB4 MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1N2MsMHg0LDB4YmZiZmRmZWMsMHhiZmJm ZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVhNCwweDQsMHhiZmJm ZGZmYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWNj LDB4NCwweGJmYmZkZmU4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0 bCgweDgwNTc1ZjQsMHg0LDB4YmZiZmRmYTAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4 MCkNCl9fc3lzY3RsKDB4ODA1NzYxYywweDQsMHhiZmJmZGZhNCwweGJmYmZkZjAwLDB4MCww eDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjQ0LDB4MiwweDgwNThlMjgsMHhiZmJm ZGYyMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzZlNCwweDAsMHhiZmJm ZTBhMCwweGJmYmZkZjIwLDB4MCwweDApIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCl9f c3lzY3RsKDB4ODA1NzZiYywweDAsMHgwLDB4YmZiZmRmYzQsMHgwLDB4MCkJIEVSUiMyMiAn SW52YWxpZCBhcmd1bWVudCcNCndyaXRlKDEsIlxeW1sxOzE1N0g1XF5bWzE7MTQ0SDNcXltb MzszMkgwIi4uLiwxMTEpID0gMTExICgweDZmKQ0KZ2V0dGltZW9mZGF5KHsxMjIyNjM3NTU1 LjY3MDYzOX0sMHgwKQkJID0gMCAoMHgwKQ0Kc2VsZWN0KDIsezB9LDB4MCwweDAsezEuOTkz MTYwfSkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1Ny42NjY0Mjh9LDB4 MCkJCSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1Ny42NjY2Nzl9LDB4MCkJ CSA9IDAgKDB4MCkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1Ny42NjY5MzB9LDB4MCkJCSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4YmZiZmRlZjgsMHgyLDB4YmZiZmRmMDAsMHhiZmJmZGVm NCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY2YywweDIsMHg4MDVlMDAw LDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczMjQsMHg0 LDB4YmZiZmRmNzAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzM0YywweDQsMHhiZmJmZGY3NCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3Mzc0LDB4NCwweGJmYmZkZjdjLDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczOWMsMHg0LDB4YmZiZmRmODAsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNlYywweDQsMHhiZmJmZTAx OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3M2M0LDB4 NCwweGJmYmZlMDE0LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc0MTQsMHg0LDB4YmZiZmUwMWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzQzYywweDQsMHhiZmJmZGY4NCwweGJmYmZkZjAwLDB4MCwweDAp ID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDY0LDB4NCwweGJmYmZkZjk4LDB4YmZiZmRm MDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0OGMsMHg0LDB4YmZiZmRm OWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRiNCww eDQsMHhiZmJmZGZkMCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwo MHg4MDU3NGRjLDB4NCwweGJmYmZkZmE4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDAp DQpfX3N5c2N0bCgweDgwNTc1MDQsMHg0LDB4YmZiZmRmYWMsMHhiZmJmZGYwMCwweDAsMHgw KSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzUyYywweDQsMHhiZmJmZGZmMCwweGJmYmZk ZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTU0LDB4NCwweGJmYmZk ZmY4LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1N2Ms MHg0LDB4YmZiZmRmZWMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzVhNCwweDQsMHhiZmJmZGZmYywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgw KQ0KX19zeXNjdGwoMHg4MDU3NWNjLDB4NCwweGJmYmZkZmU4LDB4YmZiZmRmMDAsMHgwLDB4 MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1ZjQsMHg0LDB4YmZiZmRmYTAsMHhiZmJm ZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzYxYywweDQsMHhiZmJm ZGZhNCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NjQ0 LDB4MiwweDgwNThlMjgsMHhiZmJmZGYyMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3Rs KDB4ODA1NzZlNCwweDAsMHhiZmJmZTBhMCwweGJmYmZkZjIwLDB4MCwweDApIEVSUiMyMiAn SW52YWxpZCBhcmd1bWVudCcNCl9fc3lzY3RsKDB4ODA1NzZiYywweDAsMHgwLDB4YmZiZmRm YzQsMHgwLDB4MCkJIEVSUiMyMiAnSW52YWxpZCBhcmd1bWVudCcNCndyaXRlKDEsIlxeW1sx OzMzSDIsICAwLjU1XF5bWzE7MTU3SDdcXltbIi4uLiw3MCkgPSA3MCAoMHg0NikNCmdldHRp bWVvZmRheSh7MTIyMjYzNzU1Ny42NzM0NjV9LDB4MCkJCSA9IDAgKDB4MCkNCnNlbGVjdCgy LHswfSwweDAsMHgwLHsxLjk5MzIxNH0pCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEy MjI2Mzc1NTkuNjY5MzQwfSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2 Mzc1NTkuNjY5NTkyfSwweDApCQkgPSAwICgweDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1 NTkuNjY5ODQ0fSwweDApCQkgPSAwICgweDApDQpfX3N5c2N0bCgweGJmYmZkZWY4LDB4Miww eGJmYmZkZjAwLDB4YmZiZmRlZjQsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc2NmMsMHgyLDB4ODA1ZTAwMCwweGJmYmZkZjIwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3MzI0LDB4NCwweGJmYmZkZjcwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTczNGMsMHg0LDB4YmZiZmRmNzQsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzM3NCwweDQsMHhiZmJmZGY3Yyww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzljLDB4NCww eGJmYmZkZjgwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTczZWMsMHg0LDB4YmZiZmUwMTgsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzNjNCwweDQsMHhiZmJmZTAxNCwweGJmYmZkZjAwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDE0LDB4NCwweGJmYmZlMDFjLDB4YmZiZmRmMDAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0M2MsMHg0LDB4YmZiZmRmODQs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzQ2NCwweDQs MHhiZmJmZGY5OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3NDhjLDB4NCwweGJmYmZkZjljLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc0YjQsMHg0LDB4YmZiZmRmZDAsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRkYywweDQsMHhiZmJmZGZhOCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTA0LDB4NCwweGJmYmZkZmFj LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1MmMsMHg0 LDB4YmZiZmRmZjAsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzU1NCwweDQsMHhiZmJmZGZmOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3NTdjLDB4NCwweGJmYmZkZmVjLDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1YTQsMHg0LDB4YmZiZmRmZmMsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzVjYywweDQsMHhiZmJmZGZl OCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NWY0LDB4 NCwweGJmYmZkZmEwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgw eDgwNTc2MWMsMHg0LDB4YmZiZmRmYTQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkN Cl9fc3lzY3RsKDB4ODA1NzY0NCwweDIsMHg4MDU4ZTI4LDB4YmZiZmRmMjAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2ZTQsMHgwLDB4YmZiZmUwYTAsMHhiZmJmZGYy MCwweDAsMHgwKSBFUlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQpfX3N5c2N0bCgweDgwNTc2 YmMsMHgwLDB4MCwweGJmYmZkZmM0LDB4MCwweDApCSBFUlIjMjIgJ0ludmFsaWQgYXJndW1l bnQnDQp3cml0ZSgxLCJcXltbMTsxNTdIOVxeW1sxOzE0NEg3XF5bWzM7OEg1LiIuLi4sMTEw KSA9IDExMCAoMHg2ZSkNCmdldHRpbWVvZmRheSh7MTIyMjYzNzU1OS42NzYzNjN9LDB4MCkJ CSA9IDAgKDB4MCkNCnNlbGVjdCgyLHswfSwweDAsMHgwLHsxLjk5MzIyOX0pCQkgPSAwICgw eDApDQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NjEuNjcyMzU5fSwweDApCQkgPSAwICgweDAp DQpnZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NjEuNjcyODUzfSwweDApCQkgPSAwICgweDApDQpn ZXR0aW1lb2ZkYXkoezEyMjI2Mzc1NjEuNjczMzI4fSwweDApCQkgPSAwICgweDApDQpfX3N5 c2N0bCgweGJmYmZkZWY4LDB4MiwweGJmYmZkZjAwLDB4YmZiZmRlZjQsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTc2NmMsMHgyLDB4ODA1ZTAwMCwweGJmYmZkZjIwLDB4 MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3MzI0LDB4NCwweGJmYmZkZjcwLDB4 YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTczNGMsMHg0LDB4 YmZiZmRmNzQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1 NzM3NCwweDQsMHhiZmJmZGY3YywweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19z eXNjdGwoMHg4MDU3MzljLDB4NCwweGJmYmZkZjgwLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAw ICgweDApDQpfX3N5c2N0bCgweDgwNTczZWMsMHg0LDB4YmZiZmUwMTgsMHhiZmJmZGYwMCww eDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzNjNCwweDQsMHhiZmJmZTAxNCww eGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDE0LDB4NCww eGJmYmZlMDFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgw NTc0M2MsMHg0LDB4YmZiZmRmODQsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9f c3lzY3RsKDB4ODA1NzQ2NCwweDQsMHhiZmJmZGY5OCwweGJmYmZkZjAwLDB4MCwweDApID0g MCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NDhjLDB4NCwweGJmYmZkZjljLDB4YmZiZmRmMDAs MHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc0YjQsMHg0LDB4YmZiZmRmZDAs MHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzRkYywweDQs MHhiZmJmZGZhOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4 MDU3NTA0LDB4NCwweGJmYmZkZmFjLDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpf X3N5c2N0bCgweDgwNTc1MmMsMHg0LDB4YmZiZmRmZjAsMHhiZmJmZGYwMCwweDAsMHgwKSA9 IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzU1NCwweDQsMHhiZmJmZGZmOCwweGJmYmZkZjAw LDB4MCwweDApID0gMCAoMHgwKQ0KX19zeXNjdGwoMHg4MDU3NTdjLDB4NCwweGJmYmZkZmVj LDB4YmZiZmRmMDAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc1YTQsMHg0 LDB4YmZiZmRmZmMsMHhiZmJmZGYwMCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4 ODA1NzVjYywweDQsMHhiZmJmZGZlOCwweGJmYmZkZjAwLDB4MCwweDApID0gMCAoMHgwKQ0K X19zeXNjdGwoMHg4MDU3NWY0LDB4NCwweGJmYmZkZmEwLDB4YmZiZmRmMDAsMHgwLDB4MCkg PSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2MWMsMHg0LDB4YmZiZmRmYTQsMHhiZmJmZGYw MCwweDAsMHgwKSA9IDAgKDB4MCkNCl9fc3lzY3RsKDB4ODA1NzY0NCwweDIsMHg4MDU4ZTI4 LDB4YmZiZmRmMjAsMHgwLDB4MCkgPSAwICgweDApDQpfX3N5c2N0bCgweDgwNTc2ZTQsMHgw LDB4YmZiZmUwYTAsMHhiZmJmZGYyMCwweDAsMHgwKSBFUlIjMjIgJ0ludmFsaWQgYXJndW1l bnQnDQpfX3N5c2N0bCgweDgwNTc2YmMsMHgwLDB4MCwweGJmYmZkZmM0LDB4MCwweDApCSBF UlIjMjIgJ0ludmFsaWQgYXJndW1lbnQnDQp3cml0ZSgxLCJcXltbMTsxNTZINDFcXltbMTsx NDRIOVxeW1szOzdIMSIuLi4sMTgzKSA9IDE4MyAoMHhiNykNCmdldHRpbWVvZmRheSh7MTIy MjYzNzU2MS42ODcwNTd9LDB4MCkJCSA9IDAgKDB4MCkNCnNlbGVjdCgyLHswfSwweDAsMHgw LHsxLjk4NTc5Nn0pCQkgPSAxICgweDEpDQpyZWFkKDAsInEiLDEpCQkJCQkgPSAxICgweDEp DQp3cml0ZSgxLCJcXltbNTk7MUhcXltbSyIsMTApCQkJID0gMTAgKDB4YSkNCmlvY3RsKDEs VElPQ1NFVEFXLDB4ODA1OWE2MCkJCQkgPSAwICgweDApDQpjaGRpcigiL3RtcCIpCQkJCQkg PSAwICgweDApDQp3cml0ZSgxLCJcXltbPzEwNDlsIiw4KQkJCQkgPSA4ICgweDgpDQpleGl0 KDB4MCkJCQkJCQ0KcHJvY2VzcyBleGl0LCBydmFsID0gMA0K --------------090308020800020406020106-- --------------enig92A7C642745FCAF55FD30F86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iFYEAREIAAYFAkjf+PQACgkQhQBMvHf/WHn1TADfZs8nWNB27VbdMVGEEvbNDfrv 72SLdphG/hqrMgDfXBW4HJW5qBB1kKSTIVxCzYeU/oF3h8GIy+rpBw== =iVXy -----END PGP SIGNATURE----- --------------enig92A7C642745FCAF55FD30F86-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 22:15:45 2008 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 1DCFB106568A for ; Sun, 28 Sep 2008 22:15:45 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 94FE68FC12 for ; Sun, 28 Sep 2008 22:15:44 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1204854fgb.35 for ; Sun, 28 Sep 2008 15:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=bFwDIMAFTWkrm4BD2n4hUZfKLZ2xppr0l0fHaWVTQx8=; b=j/igaZVUHfT25Upa1TwNkJnJLp78IaM4qBnPRnpLyXTCxc266lm3uEEBZy7nP49n7K P2tuvtqVba3X9PjdK8mYLPNS6yxH42b0vrPTreelHb1ohenwMS5atCq0BVuzRMQJPtD1 CsuZtx+h31RVGIykO5yKf6Rrp0Ed8RGYLS9uM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=WGXf3BmNndi518X3h0AvcZrKRiIOjJpW8eLN8Fia53qD7j/Oz/yV/infINAuwEVImJ V2wP/Z3PTHJFiR+NnQUL3aVWgc+bLKoHngTw+lDQd32tLzzt/gmA9ZT1HMee+rK9o8i7 YSO9SIqIrS1B84d88xso7HyfiMyGtZKBv9p/U= Received: by 10.86.74.15 with SMTP id w15mr3601064fga.42.1222640143170; Sun, 28 Sep 2008 15:15:43 -0700 (PDT) Received: by 10.86.82.4 with HTTP; Sun, 28 Sep 2008 15:15:43 -0700 (PDT) Message-ID: Date: Sun, 28 Sep 2008 18:15:43 -0400 From: "firmdog@gmail.com" To: "Gary Palmer" In-Reply-To: <20080928205300.GF60230@in-addr.com> MIME-Version: 1.0 References: <20080928205300.GF60230@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 22:15:45 -0000 On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer wrote: > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > I have the same problem on a Dell Poweredge SC440 when I transferred over > > 50GB > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > cable > > and > > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > > Did a > > tcpdump and saw lots of bad checksum errors. > > > > What other troubleshooting steps can we take? What could be the problem? > > Please post the first few lines of ifconfig for bge0. I'm suspecting > you'll see something like > > em1: flags=8843 mtu 1500 > options=1b > > (yes, I know thats an em, not bge, but I don't have any bge's around > here) > > Note that the options line say that receive and transmit checksum > offloading is enabled. This means that for packets transmitted > by this system, tcpdump will show checksum errors as the kernel > is not generating the checksums, the ethernet card will. Since > tcpdump is seeting the packet before the ethernet card does its > magic, you get the checksum errors on transmit. Received packets > should be fine though. > > Regards, > > Gary > Pasted below. When I was doing the transfer, it was 1000 full duplex and was very slow. This is a web/email/database server and I don't see any performance problems yet, but I would like to know what the problem is/was. What else can I provide? bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1a:a0:23:c0:03 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 22:24:17 2008 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 F328A1065699 for ; Sun, 28 Sep 2008 22:24:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 99A208FC17 for ; Sun, 28 Sep 2008 22:24:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id LG7c1a00D0SCNGk59NQFbK; Sun, 28 Sep 2008 22:24:15 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.westchester.pa.mail.comcast.net with comcast id LNQE1a0084v8bD73VNQFsX; Sun, 28 Sep 2008 22:24:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=g3XWG8PL9CAA:10 a=qSlgtixbqsUA:10 a=QycZ5dHgAAAA:8 a=GdMVtckzp1B5kRWKAfkA:9 a=FMILXAL5VWvrbrjttcIA:7 a=z2GBRmGH9N5NSgHwbvdG02DJY2IA:4 a=EoioJ0NPDVgA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 47B47C9432; Sun, 28 Sep 2008 15:24:14 -0700 (PDT) Date: Sun, 28 Sep 2008 15:24:14 -0700 From: Jeremy Chadwick To: "firmdog@gmail.com" Message-ID: <20080928222414.GA90269@icarus.home.lan> References: <20080928205300.GF60230@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 22:24:17 -0000 On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer wrote: > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > I have the same problem on a Dell Poweredge SC440 when I transferred over > > > 50GB > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > cable > > > and > > > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > > > Did a > > > tcpdump and saw lots of bad checksum errors. > > > > > > What other troubleshooting steps can we take? What could be the problem? > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > you'll see something like > > > > em1: flags=8843 mtu 1500 > > options=1b > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > here) > > > > Note that the options line say that receive and transmit checksum > > offloading is enabled. This means that for packets transmitted > > by this system, tcpdump will show checksum errors as the kernel > > is not generating the checksums, the ethernet card will. Since > > tcpdump is seeting the packet before the ethernet card does its > > magic, you get the checksum errors on transmit. Received packets > > should be fine though. > > > > Regards, > > > > Gary > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > was very slow. > This is a web/email/database server and I don't see any performance problems > yet, but > I would like to know what the problem is/was. What else can I provide? > > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:1a:a0:23:c0:03 > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active I see 100baseTX there, not 1000baseTX. This speed is being selected via autoneg (auto speed/duplex negotiation). Whatever switch you're connected to is not properly negotiating the speed. What brand and model of switch is this host connected to, and are you *absolutely certain* it supports (and is configured for) gigE? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 22:30:04 2008 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 D233B106568C for ; Sun, 28 Sep 2008 22:30:04 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 52CBF8FC1B for ; Sun, 28 Sep 2008 22:30:04 +0000 (UTC) (envelope-from firmdog@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1207585fgb.35 for ; Sun, 28 Sep 2008 15:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=w/Rnd0RTtMEuVA1oiUo6t2VmWxMypXnn+SYAfPgK8eY=; b=RbhsLjY7ZeI+4wjWFkEzitD4hF1dRA3CFFIjtA6qqXYF+Y37PEPUmAiRRLSWUgRnWP wpGyXv+cljv+GltwokCBoeeOjMHS7Zv4Yt7LPaSxPnSo4s3aqf2Sv3a5V3iuiHgH0u0w ejfaG+j0Tuy19CpUumKadMSWYptwat5h7yGkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=mM4e5DnW1jVVjRIZieWPpr56fMoZhX2gDfuLthdhQYg7tFyqfm9M/qkFxsM+/8H2qm 78OWg6iGo4xBVfu34lrJYT4gir0Uhc95qILRmcY/7dR/Az890ReIOsTq2iJdimKL03M3 m+Wiw2gm/wbABSoyPZCIG8taqbtT/OkiiHSAY= Received: by 10.86.66.19 with SMTP id o19mr3578016fga.68.1222641003202; Sun, 28 Sep 2008 15:30:03 -0700 (PDT) Received: by 10.86.82.4 with HTTP; Sun, 28 Sep 2008 15:30:03 -0700 (PDT) Message-ID: Date: Sun, 28 Sep 2008 18:30:03 -0400 From: "firmdog@gmail.com" To: "Jeremy Chadwick" In-Reply-To: <20080928222414.GA90269@icarus.home.lan> MIME-Version: 1.0 References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 22:30:04 -0000 On Sun, Sep 28, 2008 at 6:24 PM, Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer > wrote: > > > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > > I have the same problem on a Dell Poweredge SC440 when I transferred > over > > > > 50GB > > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > > cable > > > > and > > > > the link was 1000 full duplex, but could only get about 10M/s. Very > odd. > > > > Did a > > > > tcpdump and saw lots of bad checksum errors. > > > > > > > > What other troubleshooting steps can we take? What could be the > problem? > > > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > > you'll see something like > > > > > > em1: flags=8843 mtu 1500 > > > options=1b > > > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > > here) > > > > > > Note that the options line say that receive and transmit checksum > > > offloading is enabled. This means that for packets transmitted > > > by this system, tcpdump will show checksum errors as the kernel > > > is not generating the checksums, the ethernet card will. Since > > > tcpdump is seeting the packet before the ethernet card does its > > > magic, you get the checksum errors on transmit. Received packets > > > should be fine though. > > > > > > Regards, > > > > > > Gary > > > > > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > > was very slow. > > This is a web/email/database server and I don't see any performance > problems > > yet, but > > I would like to know what the problem is/was. What else can I provide? > > > > bge0: flags=8843 metric 0 mtu > 1500 > > options=9b > > ether 00:1a:a0:23:c0:03 > > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > I see 100baseTX there, not 1000baseTX. This speed is being selected via > autoneg (auto speed/duplex negotiation). > > Whatever switch you're connected to is not properly negotiating the > speed. > > What brand and model of switch is this host connected to, and are you > *absolutely certain* it supports (and is configured for) gigE? No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. The speed performance was terrible and I could only get up to 10 Mb/s and there was NO switch involved. I believe there is a problem or bug involved with the driver. Have the drivers or stack been updated in 7.1? What else can I provide? From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 22:33:49 2008 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 58B071065686; Sun, 28 Sep 2008 22:33:49 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 1400C8FC16; Sun, 28 Sep 2008 22:33:48 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1Kk4So-000POA-77; Mon, 29 Sep 2008 02:10:02 +0400 Message-ID: <48E0002C.2020803@FreeBSD.org> Date: Mon, 29 Sep 2008 02:07:40 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Edwin Groothuis References: <20080928054620.GA80250@k7.mavetju> <20080928093357.GA71582@ice.42.org> <20080928094903.GB13745@k7.mavetju> In-Reply-To: <20080928094903.GB13745@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan `Sec` Zehl , stable@freebsd.org, current@Freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 22:33:49 -0000 Edwin Groothuis wrote: > Oh yes, I forgot about that: > > The old top(1) and new top(1) counts the processes different: > > - "ps xauw | wc" gives 265 > - "ps xauwH | wc" gives 295 (expand threads) But what about running processes? I have quad core processor with the summary lines: new top: 127 processes: 5 running, 104 sleeping, 18 waiting old top: 90 processes: 1 running, 89 sleeping Let's see what process is running: % ps axuwH | awk '{if(index($8,"R")) print}' root 12 100.0 0.0 0 8 ?? RL 14Sep08 20648:50.71 [idle: cpu2] root 13 100.0 0.0 0 8 ?? RL 14Sep08 20647:09.32 [idle: cpu1] root 14 100.0 0.0 0 8 ?? RL 14Sep08 20640:25.87 [idle: cpu0] root 11 86.1 0.0 0 8 ?? RL 14Sep08 20650:27.95 [idle: cpu3] sem 71228 0.0 0.0 3204 996 p7 R+ 1:59AM 0:00.00 ps axuwH Is it correct idle cpu pseudo processes are counted? Anyway new top looks much better. Thanks, Edwin! PS. 7.1-PRERELEASE from May 10. -- Dixi. Sem. From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 22:44:05 2008 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 8BB6C106568A for ; Sun, 28 Sep 2008 22:44:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5698FC12 for ; Sun, 28 Sep 2008 22:44:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id LMSE1a00D0vp7WLAANk5jR; Sun, 28 Sep 2008 22:44:05 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id LNk41a0014v8bD78RNk4WX; Sun, 28 Sep 2008 22:44:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=g3XWG8PL9CAA:10 a=qSlgtixbqsUA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=TaBqLT28euFuzUbQHJoA:9 a=zhPr7A6TN5_47Hu89_EA:7 a=fm7W4BaQJn0i24lrmi-ymYvEC50A:4 a=EoioJ0NPDVgA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id F0791C9432; Sun, 28 Sep 2008 15:44:03 -0700 (PDT) Date: Sun, 28 Sep 2008 15:44:03 -0700 From: Jeremy Chadwick To: "firmdog@gmail.com" Message-ID: <20080928224403.GA90609@icarus.home.lan> References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 28 Sep 2008 22:44:05 -0000 On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > On Sun, Sep 28, 2008 at 6:24 PM, Jeremy Chadwick wrote: > > > On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > > > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer > > wrote: > > > > > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > > > I have the same problem on a Dell Poweredge SC440 when I transferred > > over > > > > > 50GB > > > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > > > cable > > > > > and > > > > > the link was 1000 full duplex, but could only get about 10M/s. Very > > odd. > > > > > Did a > > > > > tcpdump and saw lots of bad checksum errors. > > > > > > > > > > What other troubleshooting steps can we take? What could be the > > problem? > > > > > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > > > you'll see something like > > > > > > > > em1: flags=8843 mtu 1500 > > > > options=1b > > > > > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > > > here) > > > > > > > > Note that the options line say that receive and transmit checksum > > > > offloading is enabled. This means that for packets transmitted > > > > by this system, tcpdump will show checksum errors as the kernel > > > > is not generating the checksums, the ethernet card will. Since > > > > tcpdump is seeting the packet before the ethernet card does its > > > > magic, you get the checksum errors on transmit. Received packets > > > > should be fine though. > > > > > > > > Regards, > > > > > > > > Gary > > > > > > > > > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > > > was very slow. > > > This is a web/email/database server and I don't see any performance > > problems > > > yet, but > > > I would like to know what the problem is/was. What else can I provide? > > > > > > bge0: flags=8843 metric 0 mtu > > 1500 > > > options=9b > > > ether 00:1a:a0:23:c0:03 > > > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > I see 100baseTX there, not 1000baseTX. This speed is being selected via > > autoneg (auto speed/duplex negotiation). > > > > Whatever switch you're connected to is not properly negotiating the > > speed. > > > > What brand and model of switch is this host connected to, and are you > > *absolutely certain* it supports (and is configured for) gigE? > No....you misunderstood. The 7.1 box was connected to a 5.4 box doing > a 50GB data transfer over rsync. Both nics were 1000 full duplex with > a crossover cable. The speed performance was terrible and I could > only get up to 10 Mb/s and there was NO switch involved. > > I believe there is a problem or bug involved with the driver. This is "after the fact" evidence. The problem is that there are numerous other factors here which could explain a 10MByte/sec cap, such as small TCP window sizes or limited disk bandwidth. Your systems are no longer in this configuration, is that correct? > Have the drivers or stack been updated in 7.1? What else can I > provide? you're asking me to give you a run-down of the changes in a driver across **two** major versions of FreeBSD (from 5 to 6 to 7). There have been changes not just to the driver, but everything the driver relies on. I don't think there's necessarily any hard evidence the "driver" is the problem -- it could be one of a hundred things. If you want to review the changes to the bge(4) driver, they are below. You'll want to look at all of the commit messages between May 9th 2005 and present. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 28 23:34:53 2008 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 E4A791065699; Sun, 28 Sep 2008 23:34:53 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id A235B8FC21; Sun, 28 Sep 2008 23:34:53 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 7EA862218ADC; Mon, 29 Sep 2008 09:34:52 +1000 (EST) X-Viruscan-Id: <48E0149B000163AAC8969D@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 875FC21B6463; Mon, 29 Sep 2008 09:34:51 +1000 (EST) Received: from k7.mavetju (unknown [121.44.153.110]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 36EC62218991; Mon, 29 Sep 2008 09:34:51 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 79B696A0; Mon, 29 Sep 2008 09:34:22 +1000 (EST) Date: Mon, 29 Sep 2008 09:34:22 +1000 From: Edwin Groothuis To: Bruce Cran Message-ID: <20080928233422.GB3211@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <20080928221532.0e692490@tau.draftnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928221532.0e692490@tau.draftnet> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Sun, 28 Sep 2008 23:34:54 -0000 On Sun, Sep 28, 2008 at 10:15:32PM +0100, Bruce Cran wrote: > On Sun, 28 Sep 2008 15:46:20 +1000 > Edwin Groothuis wrote: > > > I have made an update for the top(1) utility in the FreeBSD base > > system to get it from the 3.5b12 version to the 3.8b1 version. > > [...] > > Please report any issues with it (compile time, run time) and a way > > to reproduce it (if possible). Thanks for your help! > > There are some new warnings generated during compilation with WARNS=1 > due to the use of -DSIGWINCH on the command line (since it has already > been defined in signal.h). Though of course it doesn't have any effect > on the functionality. I have renamed it to TOPSIGWINCH to overcome this, but that's only a silly patch to make it quiet :-) Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 00:46:17 2008 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 D2E171065686 for ; Mon, 29 Sep 2008 00:46:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A9CAD8FC1E for ; Mon, 29 Sep 2008 00:46:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4C81916E998 for ; Sun, 28 Sep 2008 20:46:17 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 28 Sep 2008 20:46:17 -0400 X-Sasl-enc: z4NPWx5dP+yXxEqaxRadCgsqUCfFCfnI2HuGa/xTDs08 1222649177 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E17053B140 for ; Sun, 28 Sep 2008 20:46:16 -0400 (EDT) Message-ID: <48E02557.2020303@incunabulum.net> Date: Mon, 29 Sep 2008 01:46:15 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: FreeBSD stable X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE 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, 29 Sep 2008 00:46:17 -0000 Hi, I've noticed some general instability with plugging in or removing USB devices with FreeBSD 7.x, even when the devices are not actively in use. I had this happen with umass and ucom devices 3 times today. The machine hangs solid, there are no obvious signs of a panic or trap to DDB. I can't provide backtraces unfortunately -- these hangs happen on both my laptop and desktop, and I usually have X running -- if I had more specific information, I'd open a PR. Again, there seems to be no reason why this should happen, the devices are off-the-shelf consumer items known to work with existing drivers, and have been repeatedly used in other OSes without these hangs happening; consider this an "anecdotal report". [For some reason my IBM laptop will often not allow me to break into DDB on a driver related panic, and will just immediately reboot -- I lack free time to track down exactly why this could be. My desktop has a USB keyboard and this appears not to be supported by DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another story.] thanks BMS From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 00:57:32 2008 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 ADE811065678 for ; Mon, 29 Sep 2008 00:57:32 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (s8.stradamotorsports.com [64.81.163.126]) by mx1.freebsd.org (Postfix) with ESMTP id 7041E8FC14 for ; Mon, 29 Sep 2008 00:57:32 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.14.3/8.13.8) with ESMTP id m8T0vSpV007186 for ; Sun, 28 Sep 2008 17:57:28 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48E027F8.6050702@highperformance.net> Date: Sun, 28 Sep 2008 17:57:28 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Old Libraries After 6.4 Upgrade 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, 29 Sep 2008 00:57:32 -0000 I noticed that a bunch of libraries "lib*_p.a" and "lib*.a" were not updated with my latest installworld. I do not disabled compilation of profiled libaries. Can these be safely deleted? Regards, Jason From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 01:02:18 2008 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 496031065687 for ; Mon, 29 Sep 2008 01:02:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id EE2D38FC1B for ; Mon, 29 Sep 2008 01:02:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id LFGn1a00E1GXsucA5R2Grb; Mon, 29 Sep 2008 01:02:16 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id LR2F1a00E4v8bD78TR2Glt; Mon, 29 Sep 2008 01:02:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=_qnPb3lbwpznpEivS4UA:9 a=FmWAapdQwjKSIObpDxCxFRcahTYA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 9223CC9432; Sun, 28 Sep 2008 18:02:15 -0700 (PDT) Date: Sun, 28 Sep 2008 18:02:15 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080929010215.GA93629@icarus.home.lan> References: <48E027F8.6050702@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E027F8.6050702@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: Old Libraries After 6.4 Upgrade 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, 29 Sep 2008 01:02:18 -0000 On Sun, Sep 28, 2008 at 05:57:28PM -0700, Jason C. Wells wrote: > I noticed that a bunch of libraries "lib*_p.a" and "lib*.a" were not > updated with my latest installworld. I do not disabled compilation of > profiled libaries. I believe to get profiled libraries, you have to explicitly enable building of such. > Can these be safely deleted? Probably. Those are library archives (.a) and not shared libraries (.so), so removing them will not impact any software during run-time. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 03:30:03 2008 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 13CA010656A1 for ; Mon, 29 Sep 2008 03:30:03 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2058FC08 for ; Mon, 29 Sep 2008 03:30:02 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by gxk10 with SMTP id 10so9965674gxk.19 for ; Sun, 28 Sep 2008 20:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=PguGgXCPzQfoeIqVIq6yRozDJD+0q60dxx55+rUR9e0=; b=dfahtjEC6qOe4xbaOqx5HaVlJuL7npa31e3aPExywXLbUrLPNOEvk7SomLgjgIwBJF YnwoCkf3bwR3RTZT27s5C6vgflbw6kihQObMU0KxvrXSHYTEY+Ue3nyJ92Bgm9C7tyv3 R6rF+57Kwpl0ZQF6FWlCEH2PegpNXnJvRRCQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=nsVoqCpeVgPYRGOR57I/6/F5lmiSG0PuIkDJNFM6VN9TPcLbx7MvWh5kxMJPl209lD 0QeQ03I1UOBYHyaZZ6wxrDA1BsRIWZ9WsxYGGgK0VWhxMnRBwHdPq8k4FWfVqBtummZj RlrdH2nMaeI8AuGcA8+MDHLiyI0NzaBMIoPnM= Received: by 10.150.92.11 with SMTP id p11mr7010562ybb.85.1222659001630; Sun, 28 Sep 2008 20:30:01 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Sun, 28 Sep 2008 20:30:01 -0700 (PDT) Message-ID: <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> Date: Sun, 28 Sep 2008 23:30:01 -0400 From: "Zaphod Beeblebrox" To: "=?ISO-8859-2?Q?Derek_Kuli=F1ski?=" In-Reply-To: <588787159.20080927003750@takeda.tk> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 03:30:03 -0000 T24gU2F0LCBTZXAgMjcsIDIwMDggYXQgMzozNyBBTSwgRGVyZWsgS3VsafFza2kgPHRha2VkYUB0 YWtlZGEudGs+IHdyb3RlOgoKPgo+ID4gWkZTIGlzIHRoZSBmaXJzdCBmaWxlc3lzdGVtLCB0byBt eSBrbm93bGVkZ2UsIHdoaWNoIHByb3ZpZGVzIDEpIGEKPiA+IHJlbGlhYmxlIGZpbGVzeXN0ZW0s IDIpIGRldGVjdGlvbiBvZiBmaWxlc3lzdGVtIHByb2JsZW1zIGluIHJlYWwtdGltZSBvcgo+ID4g ZHVyaW5nIHNjcnViYmluZywgMykgcmVwYWlyIG9mIHByb2JsZW1zIGluIHJlYWwtdGltZSAoYXNz dW1pbmcgcmFpZHoxIG9yCj4gPiByYWlkejIgYXJlIHVzZWQpLCBhbmQgNCkgZG9lcyBub3QgbmVl ZCBmc2NrLiAgVGhpcyBtYWtlcyBaRlMgcG93ZXJmdWwuCj4KCldoaWxlIEkgYW0gdmVyeSBlbnRo dXNpYXN0aWMgYWJvdXQgWkZTIChhbmQgdXNlIGl0IGZvciBjZXJ0YWluIHRhc2tzKSwgdGhlcmUK YXJlIHNldmVyYWwgdGhpbmdzIHByZXZlbnRpbmcgbWUgZnJvbSByZWNvbW1lbmRpbmcgaXQgYXMg YSBnZW5lcmFsLXB1cnBvc2UKZmlsZXN5c3RlbSAoYW5kIG5vbmUgb2YgdGhlbSBhcmUgc3BlY2lm aWMgdG8gRnJlZUJTRCdzIHBvcnQgb2YgaXQpLgoKQXMgYSBsYXJnZSBOQVMgZmlsZXN0b3JlLCBa RlMgc2VlbXMgdmVyeSB3ZWxsIGRlc2lnbmVkLiAgVGhhdCBpcywgaWYgdGhlCmdvYWwgaXMgdG8g c3RvcmUgYSB2ZXJ5IGxhcmdlIGFtb3VudCBvZiBmaWxlcyB3aXRoIGRhdGEgaW50ZWdyaXR5IGFu ZCBzZXJ2ZQp0aGVtIHVwIG92ZXIgdGhlIG5ldHdvcmssIFpGUyBhY2hpZXZlcyBpdCB3aXRoIGFw bG9tYi4KCkhvd2V2ZXIsIGFzIGEgY29yZSBnZW5lcmFsIHB1cnBvc2UgZmlsZXN5c3RlbSwgaXQg c2VlbXMgdG8gaGF2ZSBmbGF3cywgbm90CnRoZSBsZWFzdCBvZiB3aGljaCBpcyBhIHJlLXNlcGFy YXRpb24gb2YgZmlsZSBjYWNoZSBhbmQgbWVtb3J5IGNhY2hlLiAgVGhpcwp2aXJ0dWFsbHkgZG9l c24ndCBtYXR0ZXIgZm9yIGEgZmlsZXNlcnZlciwgYnV0IGlzIGdlbmVyYWxseSBpbXBvcnRhbnQg aW4gYQpnZW5lcmFsIHB1cnBvc2UgbG9jYWwgZmlsZXN5c3RlbS4gIFpGUyBhbHNvIGhhcyBhIHRy YW5zYWN0aW9uYWwgbmF0dXJlIC0tLQp3aGljaCBwcm9iYWJseSwgYWdhaW4sIHdvcmtzIHdlbGwg aW4gYSBmaWxlc2VydmVyLCBidXQgSSBmaW5kIChhcyBhIGxvY2FsCmZpbGVzeXN0ZW0pIGl0IGlu dHJvZHVjZXMgdW5wcmVkaWNhYmxlIGRlbGF5cyBhcyB0aGUgYnVmZmVyIGZpbGxzIHVwIGFuZAp0 aGVuIGdldHMgZmx1c2hlZCBlbiBtYXNzZS4KClRoaXMgaXMgbm90IHRvIHNheSB0aGF0IGdlbmVy YWwgcHVycG9zZSBmaWxlc3lzdGVtcyBjb3VsZG4ndCBoZWFkIGluIHRoZSBaRlMKZGlyZWN0aW9u LCBvciB0aGF0IFpGUyBpcyBhbnRoaW5nIGJ1dCBhbiBhbWF6aW5nIHBpZWNlIG9mIHRlY2hub2xv Z3ksIGJ1dApVRlMgYW5kIFVGUytTVSBoYXZlIG5vdCBvdXRsaXZlZCB0aGVpciB1c2VmdWxuZXNz IHlldC4KCk1heWJlIHN1cHBvcnQgZm9yIG9kZCBibG9jayBzaXplcyBpbiBVRlMgd291bGQgYWxs b3cgZ2VvbSB0byBtYW51ZmFjdHVyZQpjaGVja3N1bXMgKGJ5IHN1YnRyYWN0aW5nIHRoZWlyIHNp emUgZnJvbSB0aGUgc291cmNlIGJsb2NrKS4gIFRoaXMgd291bGQgYmUKdGhlIGxhc3QgbGluayBp biB0aGUgY2hhaW4gdG8gcHJvdmlkZSBnam91cm5hbCArIGdtaXJyb3IgKyBnY2hlY2tzdW0KKGFk ZHJlc3NpbmcgcG9pbnRzIDEsIDIsIDMgYW5kIDQpLiBFcXVhbGx5LCBtYXliZSBnY2hlY2tzdW0g Y291bGQgd29yayBsaWtlCmdqb3VybmFsLiAgRHVubm8gLS0tIHRoYXQgd291bGQgcHJvYmFibHkg YmUgZXhwZW5zaXZlIGluIGlvIG9wcy4K From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 04:00:29 2008 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 CE91D1065692 for ; Mon, 29 Sep 2008 04:00:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 72F998FC23 for ; Mon, 29 Sep 2008 04:00:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id LSNX1a00E16LCl052U06nJ; Mon, 29 Sep 2008 04:00:06 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id LU0R1a0044v8bD73SU0Si7; Mon, 29 Sep 2008 04:00:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=COaGVwIvTU2Pl52jQzUA:9 a=J5xvyeqAWYfK_SmOJXgFz2UJhGYA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6BEE4C9437; Sun, 28 Sep 2008 21:00:25 -0700 (PDT) Date: Sun, 28 Sep 2008 21:00:25 -0700 From: Jeremy Chadwick To: Zaphod Beeblebrox Message-ID: <20080929040025.GA97332@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Derek Kuli?ski , freebsd-stable@freebsd.org, Clint Olsen , pjd@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 04:00:29 -0000 On Sun, Sep 28, 2008 at 11:30:01PM -0400, Zaphod Beeblebrox wrote: > On Sat, Sep 27, 2008 at 3:37 AM, Derek Kuli?ski wrote: > > > > > > ZFS is the first filesystem, to my knowledge, which provides 1) a > > > reliable filesystem, 2) detection of filesystem problems in real-time or > > > during scrubbing, 3) repair of problems in real-time (assuming raidz1 or > > > raidz2 are used), and 4) does not need fsck. This makes ZFS powerful. > > > > While I am very enthusiastic about ZFS (and use it for certain tasks), there > are several things preventing me from recommending it as a general-purpose > filesystem (and none of them are specific to FreeBSD's port of it). > > As a large NAS filestore, ZFS seems very well designed. That is, if the > goal is to store a very large amount of files with data integrity and serve > them up over the network, ZFS achieves it with aplomb. > > However, as a core general purpose filesystem, it seems to have flaws, not > the least of which is a re-separation of file cache and memory cache. This > virtually doesn't matter for a fileserver, but is generally important in a > general purpose local filesystem. ZFS also has a transactional nature --- > which probably, again, works well in a fileserver, but I find (as a local > filesystem) it introduces unpredicable delays as the buffer fills up and > then gets flushed en masse. I'm curious to know how Solaris deals with these problems, since the default filesystem (AFAIK) in OpenSolaris is now ZFS. CC'ing pjd@ who might have some insight there. > This is not to say that general purpose filesystems couldn't head in the ZFS > direction, or that ZFS is anthing but an amazing piece of technology, but > UFS and UFS+SU have not outlived their usefulness yet. > > Maybe support for odd block sizes in UFS would allow geom to manufacture > checksums (by subtracting their size from the source block). This would be > the last link in the chain to provide gjournal + gmirror + gchecksum > (addressing points 1, 2, 3 and 4). Equally, maybe gchecksum could work like > gjournal. Dunno --- that would probably be expensive in io ops. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 04:33:39 2008 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 72A7C106568C for ; Mon, 29 Sep 2008 04:33:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id E2C878FC1F for ; Mon, 29 Sep 2008 04:33:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1143071tid.3 for ; Sun, 28 Sep 2008 21:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aTqtI0jx64aN/aRvKaK2+OKeOdUVqqmoUZ30lEtNczI=; b=dJ37jp9b3DnxodqOfYsnRhD6bZuAN3oEiW4qv2OLxLPXai1Pmq1TLZ2HFN60YEckiT VyPDyIc8t/SjktQ1O97WBzjbQ03eTa5D3EcSQtOVdpAH2I5OqLOYNLfn8ydcTtAdasFE aO8u5RxhrKv3cR9agfbJYUq+sar5ShUlGaj7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=yGqDPGsO7trEq+50IDEe7Qu9Rym5JURZfu682rp6w8IP2T6EB2P5e0P+8p2Kzm9PF3 WZu1WOTUm5V3XwqAl5o2FfWkWeFGzMdVxAHFzLZThafFRWVyfFgCiGRQ7VrMJLnwQr+m WWqwkMEAuX59Z5cd4P6jSd5wR+ZvDu9QBdUsg= Received: by 10.110.11.1 with SMTP id 1mr6490762tik.24.1222662817218; Sun, 28 Sep 2008 21:33:37 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id 22sm6351337tim.16.2008.09.28.21.33.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Sep 2008 21:33:35 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8T4Va73055761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 13:31:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8T4VYhQ055760; Mon, 29 Sep 2008 13:31:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 29 Sep 2008 13:31:34 +0900 From: Pyun YongHyeon To: "Arno J. Klaassen" Message-ID: <20080929043134.GD54819@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 04:33:39 -0000 On Sat, Sep 27, 2008 at 11:21:00PM +0200, Arno J. Klaassen wrote: > > > Hello, > > I've serious network performance problems on a HP Turion X2 > based brand new notebook; I only used a 7-1Beta CD and > 7-STABLE on this thing. > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > # scp -p ports.tgz login@mv:/tmp/ > ports.tgz 100% 98MB 88.7KB/s 18:49 > > (doing the same thing by copy from an nfs-mounted disk even > takes mores than an hour ...) > > > Doing a top(1) aside, just shows the box 100% idle : > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > I tested : > > Update Bios > ULE /4BSD > PREEMPTION on/off > PREEMPTION + IPI_PREEMPTION > hw.nfe.msi[x]_disable=1 ^^^^^^^^^^^^^^^^^^^^^^^ This has no effect as MCP65 lacks MSI/MSI-X capability. > > All don't seem to matter to the problem. > > I put two tcpdumps (server and client during another scp(1) ) on > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > lots of sequences like : > > TCP Previous segment lost > TCP Duplicate ACK 1 > TCP Window update > TCP Duplicate ACK 2 > TCP Duplicate ACK 3 > TCP Duplicate ACK 4 > TCP Duplicate ACK 5 > TCP Fast retransmission (suspected) > TCP ... > TCP Out-of-Order segment > TCP ... > > > As usual, feel free to contact me for further info/tests. > AFAIK it seems that you're the first one that reports poor performance issue of MCP65. MCP65 has no checksum offload/TSO capability so nfe(4) never try to take advantage of the hardware capability. So you should have no checksum offload/TSO related issue here. Also note, checking network performance with scp(1) wouldn't show real numbers as scp(1) may involve other system activities. Use one of network benchmark programs in ports(e.g. benchmarks/netperf) to measure network performance. Other possible cause of issue could be link speed/duplex mismatch or excessive MAC control frames(e.g. pause frames). Does nfe(4) agree on resolved speed/duplex with link partner? If they all agree on resolved speed/duplex, would you check number of pause frames sent/received from link partner? Even though MCP65 supports hardware MAC statistics for pause frames nfe(4) has no support code yet so you may have to resort to managed switch that can show Tx/Rx statistics of each port. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 05:04:29 2008 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 4BF56106568B for ; Mon, 29 Sep 2008 05:04:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 147A18FC1F for ; Mon, 29 Sep 2008 05:04:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1761547rvf.43 for ; Sun, 28 Sep 2008 22:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ShFPNKJAH0pqrXXOqzoipbXVSNQDN7VsEIpQdG9aEBM=; b=mcHsEmrl3WoReicrhhC9//Ac/uBZQh81jCTReXaYEFYWMQQ6dfG/LhR3FSQWN10rSv qzc6K6iwPCks1eUrI2PRXe6721pAx4za0LyBvyijCIfF4JwD6b41a0rW3RI720h8+anB nT2FA1EshyTkp5d+EixvX1Xr8AXTKape4JrOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RVzQHU7RawUlTx5c8IAM5djVr2VEpajLIA3It1EHpF5SzF7M4MaoEtjk5b/29Es9BW E4HqgktqUsmV8YADP2/Ij9hGCHDqnvCkG4U2nfEEBSuWEJt1iTm+b9NVL8lQGa7xsvLP dKptW9ZlxqyzIcMe9wrScd1sCZhUeHShZDe6c= Received: by 10.141.197.14 with SMTP id z14mr2174231rvp.283.1222664668604; Sun, 28 Sep 2008 22:04:28 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f21sm2559491rvb.5.2008.09.28.22.04.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Sep 2008 22:04:27 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8T52RpZ055882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 14:02:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8T52OYc055881; Mon, 29 Sep 2008 14:02:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 29 Sep 2008 14:02:24 +0900 From: Pyun YongHyeon To: Julian Stacey Message-ID: <20080929050224.GF54819@cdnetworks.co.kr> References: <20080926013346.GA43015@cdnetworks.co.kr> <200809261717.m8QHGvmx011312@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809261717.m8QHGvmx011312@fire.js.berklix.net> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 29 Sep 2008 05:04:29 -0000 On Fri, Sep 26, 2008 at 07:16:57PM +0200, Julian Stacey wrote: > > > I'm remaking binaries, > > New generic kernel built & installed, & install of all src/ done too. > No improvement. > > > Is there reliable way to reproduce the issue? > > Its continuous, the machine virtually never does a ping in less > than 10 seconds. > > > Anyway, would you try attached patch and let me know result? > > Thanks > Done, doesnt help. > Seeing a new message now too: > ping: sendto: No buffer space available. Can you see 'rl0: link state changed to UP' message in dmesg after you assign an IP address to rl0? Would you show me the 'ifconfig rl0' output? -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 05:12:09 2008 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 DA86B1065690 for ; Mon, 29 Sep 2008 05:12:09 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 741CC8FC17 for ; Mon, 29 Sep 2008 05:12:09 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by gxk10 with SMTP id 10so10006816gxk.19 for ; Sun, 28 Sep 2008 22:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ZQrQrJI4dQr0UxgoDw8CJBQrasV2KiIY14rMEymg9To=; b=HIEgq2bQQcZBBkHMN1US9gYBjmOeLmgRvB1vpA5iryXt2r5D86Qhx+14q3RXBokGIW 8LUljCz6kT9nMUvL8aJ1JeVkj8KcoKuEgAP6cBR6Kxvk9l6Lv2EaXen6/4i10a2gZo/E l6gcFfhCPMjAYI2nC78wl7FqPL+UqAijKjzQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=i3VhCrODqPws/bsQtnzwVtJSX0prbEeTqzdi/TLHIxP78gggXRDDpj1ZchATgjxvcO jeSpFV6BY52AV21nU+O1pn8p7imFH4mUxjd2Dd289h0hLhWi0bDBj9dW/sFwW+IBkdP7 tZKSpaPe0xlvBW1r85Xne00yBwI5M81/f7VyY= Received: by 10.151.112.19 with SMTP id p19mr7172184ybm.30.1222665128663; Sun, 28 Sep 2008 22:12:08 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Sun, 28 Sep 2008 22:12:08 -0700 (PDT) Message-ID: <5f67a8c40809282212s27298b52p50935ae1976d5df4@mail.gmail.com> Date: Mon, 29 Sep 2008 01:12:08 -0400 From: "Zaphod Beeblebrox" To: "Jeremy Chadwick" In-Reply-To: <20080929040025.GA97332@icarus.home.lan> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Derek Kuli?ski , freebsd-stable@freebsd.org, Clint Olsen , pjd@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 05:12:09 -0000 On Mon, Sep 29, 2008 at 12:00 AM, Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 11:30:01PM -0400, Zaphod Beeblebrox wrote: > > > However, as a core general purpose filesystem, it seems to have flaws, > not > > the least of which is a re-separation of file cache and memory cache. > This > > virtually doesn't matter for a fileserver, but is generally important in > a > > general purpose local filesystem. ZFS also has a transactional nature > --- > > which probably, again, works well in a fileserver, but I find (as a local > > filesystem) it introduces unpredicable delays as the buffer fills up and > > then gets flushed en masse. > > I'm curious to know how Solaris deals with these problems, since the > default filesystem (AFAIK) in OpenSolaris is now ZFS. CC'ing pjd@ who > might have some insight there. I certainly am not implying that it won't work as a local filesystem, simply that this design choice may not be ideal for completely generalized local workloads --- those same workloads that drove UN*X in general to unified buffer caches... which appears to be implemented independently by every major UN*X vendor... solaris may have even been the first. The ARC is separate from the general VM cache in solaris, too, IIRC. Solaris' UFS still uses a unified cache. Most of the problems where ZFS runs the machine out of kernel memory (or fights with other filesystems for memory, etc) are due to the effects of it's non-unified cache. Solaris and new patches to FreeBSD seem to make this play better, but the fundamental reason for unifying the filesystem and memory cache was the payoff that local applications memory and file usage would balance out better if the buffering of files and memory was not just from the same pool of memory, but in fact the "same thing". Historically, you had file cache being a percentage of memory (say 10%). The next innovation (I seem to remember my HpUX 9 workstation doing this) was to have the division of memory between file and memory caches move dynamically. This was better but non-optimal. This is the state of affairs now with ZFS too. The unified caches sprung up in UN*X derivatives shortly thereafter ... where caching a file and caching memory were one in the same. This is where UFS sits. Expanding on my post, if the job is to serve network disk, the dynamic division or unified cache strategies probably don't make too much difference. The "thumper" offering from sun gives you 48 SATA disks, two dual core opterons and 16G of memory. The obvious intention is that most of that 16G is, in the end, cache for the files (all in 4U and all externally accessible --- very cool, BTW). But a general purpose machine is executing many of those libraries and binaries and mmap()ing many of those files... both operations where the unified strategy was designed to win. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 06:20:00 2008 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 C2F021065689 for ; Mon, 29 Sep 2008 06:20:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AD6E18FC0A for ; Mon, 29 Sep 2008 06:20:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 917491A3C38; Sun, 28 Sep 2008 23:20:00 -0700 (PDT) Date: Sun, 28 Sep 2008 23:20:00 -0700 From: Alfred Perlstein To: Edwin Groothuis Message-ID: <20080929062000.GF36572@elvis.mu.org> References: <20080928054620.GA80250@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928054620.GA80250@k7.mavetju> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Mon, 29 Sep 2008 06:20:00 -0000 * Edwin Groothuis [080927 23:04] wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. Hey Edwin, any chance you have the time to add to top(1) a flag that will restrict top(1) to only view a certain pid or list of pids? This would be really helpful in the threaded view to watch a single process. -Alfred From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 06:31:00 2008 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 303C9106568B; Mon, 29 Sep 2008 06:31:00 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id AB3F78FC21; Mon, 29 Sep 2008 06:30:59 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 86E782218A62; Mon, 29 Sep 2008 16:30:58 +1000 (EST) X-Viruscan-Id: <48E07620000167FB9DC8E2@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 8B35421B6631; Mon, 29 Sep 2008 16:30:51 +1000 (EST) Received: from k7.mavetju (ppp121-44-153-110.lns10.syd7.internode.on.net [121.44.153.110]) by mail5auth.barnet.com.au (Postfix) with ESMTP id A6D362218BFD; Mon, 29 Sep 2008 16:30:50 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 97A946BE; Mon, 29 Sep 2008 16:30:19 +1000 (EST) Date: Mon, 29 Sep 2008 16:30:19 +1000 From: Edwin Groothuis To: Alfred Perlstein Message-ID: <20080929063019.GC3211@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <20080929062000.GF36572@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080929062000.GF36572@elvis.mu.org> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Mon, 29 Sep 2008 06:31:00 -0000 On Sun, Sep 28, 2008 at 11:20:00PM -0700, Alfred Perlstein wrote: > * Edwin Groothuis [080927 23:04] wrote: > > I have made an update for the top(1) utility in the FreeBSD base > > system to get it from the 3.5b12 version to the 3.8b1 version. > > Hey Edwin, any chance you have the time to add to top(1) a flag > that will restrict top(1) to only view a certain pid or list > of pids? This would be really helpful in the threaded view > to watch a single process. The out-of-the-box option I can give you is to use the "c" command and to type the name of the command to filter that one out. And then press H. But it's not possible from the commandline yet. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 07:16:35 2008 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 71F8D106568B for ; Mon, 29 Sep 2008 07:16:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCDA8FC17 for ; Mon, 29 Sep 2008 07:16:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 9093417D92; Mon, 29 Sep 2008 17:16:34 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.100] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id AACDF17D91 for ; Mon, 29 Sep 2008 17:16:28 +1000 (EST) Message-ID: <48E080C0.9070103@modulus.org> Date: Mon, 29 Sep 2008 17:16:16 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> In-Reply-To: <20080929040025.GA97332@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 07:16:35 -0000 > However, as a core general purpose filesystem, it seems to have flaws, not > the least of which is a re-separation of file cache and memory cache. For me, this doesn't matter because ZFS is so much faster than UFS overall. Even if you don't use any of its features, the latest version does sequential I/O and heavy random I/O faster than UFS on the same hardware for me. Cases where UFS is faster are proving to be the exception rather than the rule. However, I cannot recommend its use until it is stable, which it currently still is not, under very heavy load. - Andrew From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 07:53:16 2008 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 6D2EE10656A1 for ; Mon, 29 Sep 2008 07:53:16 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id C8C9F8FC15 for ; Mon, 29 Sep 2008 07:53:15 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [10.0.1.101] (gw1.sofiasoftsolutions.com [195.34.104.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id 15C0E1522CCD for ; Mon, 29 Sep 2008 10:53:11 +0300 (EEST) Message-ID: <48E08962.2010107@lozenetz.org> Date: Mon, 29 Sep 2008 10:53:06 +0300 From: Anton - Valqk User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: stable@freebsd.org References: <48DCB57E.8000001@lozenetz.org> <48DCD1DF.6010203@lozenetz.org> In-Reply-To: <48DCD1DF.6010203@lozenetz.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-HostIT-MailScanner-From: lists@lozenetz.org Cc: Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 29 Sep 2008 07:53:16 -0000 Moring and have a nice week! The problems continues. It appears that this has somethind to do with the xl,fxp,atapci cards. On friday evening when I had hw access to the machine I've pulled out the power of one of the disks and remove rl0. The situation was absolutely the same! timeouts and timeouts again.... After seeing this isn't helping I've patched my kernel with http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-patches/ata/files/patch-ata.diff?view=markup this patch and tried increasing the timeout to 10 then to 15 then to 25 - nothing helped. I got crazy and pulled of my home movie station (PIII 1ghz, 384ram, via(I think chipser) - I'll post new dmesg here). I've moved the disks (only 4 of the as I wasn't using the fitfth) and plugged xl0, fxp0 and promise card in the new machine. It started just fine and seemed to work while.... I've started to get the *bad* timeouts again! F***!!! I saw that the timeout of the tunable sysctl is 5 and increased it to 15 but still on heavy (read mythtv scan about 300G media files and other stuff) and 3-4 fetches fetching online radios) ... so I think is has something to do with the promise card. Oh yes, I've also got Sep 28 21:32:47 azimud kernel: xl0: transmission error: 90 Sep 28 21:32:47 azimud kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes because these problems drives me tooo mad! I simply want a working machine, I'm going to pull of the xl0 and promise card from this machine (use integrated ide controllers) and another fxp because seems that fbsd now has problems and with xl's (Which reminds me for the 4.X - it used to work perfectly with xls rls fxps... but that's another topic...anyways). If that doesn't help I'll be forced to migrate to linux :(... Because I'll have free machine with the problematic promise ultra133 controller and two disks in it, I can provide a serial console to this machine is anyone is interested in debugging this issue.... anyone? here are the new info: http://valqk.ath.cx/tmp/dmesg.new http://valqk.ath.cx/tmp/vmstat.new (oh I have no usbs connected to this machine [yet]). cheers, valqk. Anton - Valqk wrote: > Thanks Jeremy and Peter, > you are right that the machine has *lots* ot hardware in it, > I was thinking of the power supply as a reason and measured the 5 and 12 > volts - seemd to be ok 11.8 and 5.2 with all hardware in it. > The shared irq is the one I've thought of and that's why I've posted > vmstat -i to hear your opinion. > [forgot to mention that I've read the wiki and next step is to patch the > kernel with > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-patches/ata/files/patch-ata.diff?view=markup > this patch (any bad words for this patch or could just run - nothing bad > can happen?)] > > Yes, I have 3 nics(2 on pci) + pci ide promise, I'll get a smart switch > with vlans and I'll leave just the integrated xl0 and fxp0 with both > external ips on it these days, > but first I'll patch the kernel if Jeremy says it won't hurt (as far as > I saw just a timeout is moved from hardcoded value to a sysctl?)... > I have another promise card that is a raid controller, but when I've > started loking for one I've asked here and there were answers for > PROMISE ULTRA ATA133 for being a good card for my freebsd ( > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=290848+0+archive/2008/freebsd-stable/20080316.freebsd-stable > ) > (hmm, just saw that Jeremy pointed out promise card: 'Their Ultra133 > TX2 card works fine on 33MHz PCI bus machines; don't worry about the > card being 66MHz, it will downthrottle correctly.') so maybe the problem > will be solved if I leave just two nics and no rl0... > Actually I'm using 6.3 here because I didn't wanted this to happen and I > was ware of such problems happening on 7-current.... > > So test must be done... pls just answer about the patch will it be > helpful or I should try: > > 1. remove rl0 and run only one isp for the test. > 2. replace the ultra 133 card with another one. > 3. try to replace the ATA100 cables (the one with 80 wires) with an > older ones with only 40 cabels? > 4. ? anything else? > > > Anton - Valqk wrote: > >> Hello, >> I have a VERY strange behaving 6-3p3 with DMA tmieouts and network cards >> 'dropping traffic'. >> Following is the explanation of hardware and the thinga that are happening. >> The machine is DELL optiplex PII 300mHZ with 512RAM. >> It has 3 NICs: >> fxp0: flags=8843 mtu 1500 >> options=8 >> inet 7.8.9.10 netmask 0xfffff000 broadcast 7.8.9.255 >> ether 00:91:21:16:14:bf >> media: Ethernet autoselect (100baseTX ) >> status: active >> rl0: flags=8843 mtu 1500 >> options=8 >> inet 8.9.10.11 netmask 0xffffffe0 broadcast 8.9.10.255 >> ether 00:02:44:73:2a:fa >> media: Ethernet autoselect (100baseTX ) >> status: active >> xl0: flags=8843 mtu 1500 >> options=9 >> inet 192.168.123.2 netmask 0xffffff00 broadcast 192.168.123.255 >> inet 192.168.123.5 netmask 0xffffff00 broadcast 192.168.123.255 >> inet 192.168.123.6 netmask 0xffffff00 broadcast 192.168.123.255 >> ether 00:c0:4f:20:66:a3 >> media: Ethernet autoselect (100baseTX ) >> status: active >> fxp0 and rl0 are external links to the world and are plugged into pci slots >> xl0 is the internal interface and is integrated on motherboard. >> It also has 1 PROMISE ULTRA133 ATA pci IDE controller plugged into the >> pci slot. >> It has 5 disks in it - 4 connected to the PROMISE card and 1 to the >> motherboard ide. >> >> they are as follows: >> ad0 and ad6 are two identical hitachi disks in gmirror for the system >> and a partition that I keep backups on. >> >> ad4, ad5 and ad7 are storage disks - seagates 500GB 8mb cache that I >> keep isos etc files on and are the problematic (maybe because of high >> traffic operations compared to the other two?). >> >> What is the problem: >> Actually there are two problems: >> 1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep >> files over 4-5MBs and write/read very often with 3-6-8MB/s from the >> disk. I don't use ad4 so I can not tell if there's gona be timeous but I >> suppose there will (currently has linux partitions on it and is not >> mounted). I get these errors: >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5554848 >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5914112 >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=14924096 >> dmesg.today:ad7: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=374303456 >> dmesg.today:ad7: FAILURE - WRITE_DMA48 status=51 >> error=10 LBA=374303456 >> dmesg.today:g_vfs_done():ad7[WRITE(offset=191643369472, >> length=131072)]error = 5 >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50757760 >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50760192 >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12032 >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50769792 >> >> strange thing is that I'm seeing the g_vfs_done just recently and this >> problem is from the very start of this hardware setup of the machine. >> The machine used to work with two hitachi disks connected to the ad0 and >> ad1 (integrated ide) and only one - xl0 - nic perfectly. >> The problems started when I plugged in the PROMISE and other nic cards >> and started using it as router, fileserver and backup server (each in >> separate jail, except the pf firewall). >> 2. The other strange issue is that when (I guess) it starts timeouting >> *sometimes* not everytime I'm loosing connection to xl0 or fxp0 >> (sometimes the rl0 works and accepts connections from the outside, >> sometimes - not). When I go to the machine and plug a monitor - there >> are no messages from kernel, no logs in /var/log/messages or debug - >> noting. Stange thing is that I ping host from the local net and it time >> outs, ifconfig shows that interface is connected at fd 100mbit and >> everyting seems ok. I've tried ifconfig xl0 down up but doesn't help, >> tried plugging out the cable and it got connected but not packets passed >> - timeout again! >> I've rebooted and nic came up. These 'drops' became more and more common >> recently and last night I wasn't able to login for about an hour and >> after that the machine came back up again by itself!!!that's in the lan >> - but it wasn't accessible at all from the outside - strange thins is >> that it replied to ping but I wasn't able to even open the ssh port >> connection and the nat wasn't working?! After that I've remembered that >> at this time I have a cronjob started for about an hour that fetches >> into a file a online radio cast for an hour.... wired!!! it also have >> rtorrent, apache22, samba (in a jail) runing. >> >> some output from it can be found here: >> http://valqk.ath.cx/tmp/dmesg >> http://valqk.ath.cx/tmp/vmstat >> http://valqk.ath.cx/tmp/smartctl >> >> >> please give any ideas/hints/solutions! >> >> thanks a lot to everyone! >> cheers, >> valqk. >> _______________________________________________ >> 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" >> >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 07:56:33 2008 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 E21291065696; Mon, 29 Sep 2008 07:56:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91EE48FC14; Mon, 29 Sep 2008 07:56:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KkDcO-000971-Co; Mon, 29 Sep 2008 10:56:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Danny Braniss message dated "Sat, 27 Sep 2008 14:32:55 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 2008 10:56:32 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 29 Sep 2008 07:56:34 -0000 > > On Fri, 26 Sep 2008, Danny Braniss wrote: > > > > > after more testing, it seems it's related to changes made between Aug 4 and > > > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > > > and close the gap. > > > > I think this is the best way forward -- skimming August changes, there are a > > number of candidate commits, including retuning of UDP hashes by mav, my > > rwlock changes, changes to mbuf chain handling, etc. > > it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the key, so > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > give the same throughput, which seem to point to UDP changes ... > > danny Grr, there goes binary search theory out of the window, So far I have managed to pinpoint the day that the changes affect the throughput: 18/08/08 00:00:00 19/08/08 00:00:00 (I assume cvs's date is GMT). now would be a good time for some help, specially how to undo changes, my knowledge of csup/cvs are close to zero. danny From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 08:13:31 2008 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 B110B106569B for ; Mon, 29 Sep 2008 08:13:31 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2478FC2D for ; Mon, 29 Sep 2008 08:13:31 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KkDsl-000OvE-Aj; Mon, 29 Sep 2008 10:13:29 +0200 Message-ID: <48E08E28.90009@kkip.pl> Date: Mon, 29 Sep 2008 10:13:28 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ben Kelly , freebsd-stable@freebsd.org References: <48DB6772.1060400@kkip.pl> <20080925130227.GA13497@icarus.home.lan> <48DB9CAA.9060807@kkip.pl> <20080925145154.GA15486@icarus.home.lan> <48DCA0AF.5050000@kkip.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-09-29 10:13:29 X-Connected-IP: 192.168.0.10:2823 X-Message-Linecount: 68 X-Body-Linecount: 55 X-Message-Size: 2404 X-Body-Size: 1668 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 29 Sep 2008 08:13:31 -0000 Ben Kelly wrote: > On Sep 26, 2008, at 4:43 AM, Bartosz Stec wrote: >> Jeremy Chadwick wrote: >>> >>> These are the tuning settings I use: >>> >>> vm.kmem_size="1536M" >>> vm.kmem_size_max="1536M" >>> vfs.zfs.arc_min="16M" >>> vfs.zfs.arc_max="64M" >>> >> Yesterday I've added 512 MB memory to box (sum 1,5GB), and set >> vm.kmem_size and vm.kmem_size to "1024M". With pieces of 1024MB, >> 512MB, 256MB, 256MB available and 3 memory slots it is hard to have >> 2GB RAM ;) >> Until now it survived world cleaning/building/installing/bonnie++ >> benchmarkink/fs scrubing and general usage. Memory usage seems >> stable. If unfortunately kmem exhaustion will happen again I will >> experiment with ARC settings. >> IMHO you've explained gently a lot of zfs tuning concerns in this >> thread and they should be added to tuning guide - espacially >> explanation of ARC and prefetch settings. Thanks again! > > Did you increase KVA_PAGES in your kernel config as well? > > The default of 256 only allows 1GB of kernel memory total. Setting > KVA_PAGES to 384 would probably be good for a kmem_size of 1GB. This > would give leave you with 512MB of space for other things in the > kernel. In your kernel config: > > options KVA_PAGES=384 > > Sorry if you already knew this. I know its in the zfs tuning guide. > I just hadn't seen it mentioned in the thread yet and wanted to make > sure it wasn't missed. > > Hope that helps. > > - Ben > Indeed I know that. options KVA_PAGES=512 is included in my kernel config. Until now: # uptime 10:12 up 3 days, 10:32, 1 user, load averages: 0,00 0,03 0,00 Thanks :) -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 08:40:07 2008 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 0DF6D1065691 for ; Mon, 29 Sep 2008 08:40:07 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7608FC22 for ; Mon, 29 Sep 2008 08:40:06 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1326101fgb.35 for ; Mon, 29 Sep 2008 01:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=czEJRw8AWEwVzkYLna9kZrdncRWFWcU6muMJ23MwCbs=; b=GSpBMw4OOz13QGVZJXSlnznfhd0e8ACzZegUyXD7173gv2Y0IUtG5g7Nvz9GkhdgB9 eJdczPKhRC1rtw9vQkQp2DjrCUUxtkzvcpERHucYzQGwzsj5dySvccgZKz7ElejqJ0MU NENW6NA7dsqtmB+00nbvWzOLopTdWqtd4KcyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LXbHoeEzKpj+/PbbIw8QJQGHucirR9Mtdjt/uplCkJuaRHLl+hvRYQum1U8Sh0gZ2n z4ML+vpvewUUQUj1bpTYMF//EnLxS3wY5esY9fSuMvsUJhI3HfHEfvVuMWvFfhdznAVZ P/uyY/kFJIHfH08z9CbXZ4CVQuGGQumeqFvcI= Received: by 10.86.23.17 with SMTP id 17mr4002438fgw.32.1222677605133; Mon, 29 Sep 2008 01:40:05 -0700 (PDT) Received: by 10.86.54.10 with HTTP; Mon, 29 Sep 2008 01:40:05 -0700 (PDT) Message-ID: Date: Mon, 29 Sep 2008 10:40:05 +0200 From: "Claus Guttesen" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , Robert Watson , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 29 Sep 2008 08:40:07 -0000 > it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the key, so > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 08:53:46 2008 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 9D5BF1065686 for ; Mon, 29 Sep 2008 08:53:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 801C88FC1F for ; Mon, 29 Sep 2008 08:53:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id LYpd1a0030x6nqcAAYtlMV; Mon, 29 Sep 2008 08:53:45 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id LYtk1a0044v8bD78YYtkBd; Mon, 29 Sep 2008 08:53:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=E3qIknzw5VgA:10 a=s03-oqJxaoQA:10 a=FP58Ms26AAAA:8 a=XscjgUWWAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=FDyoCYNekKkKW_6PDUoA:9 a=xx_zudO3Ub6nrtTeYXkA:7 a=IQF2M_XQpwybEv8l6marDb35cM4A:4 a=EoioJ0NPDVgA:10 a=HRJsq0TPXRMA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 0BC91C9432; Mon, 29 Sep 2008 01:53:44 -0700 (PDT) Date: Mon, 29 Sep 2008 01:53:43 -0700 From: Jeremy Chadwick To: Anton - Valqk Message-ID: <20080929085343.GA2510@icarus.home.lan> References: <48DCB57E.8000001@lozenetz.org> <48DCD1DF.6010203@lozenetz.org> <48E08962.2010107@lozenetz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E08962.2010107@lozenetz.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 29 Sep 2008 08:53:46 -0000 On Mon, Sep 29, 2008 at 10:53:06AM +0300, Anton - Valqk wrote: > Moring and have a nice week! > The problems continues. > It appears that this has somethind to do with the xl,fxp,atapci cards. > On friday evening when I had hw access to the machine I've pulled out > the power of one of the disks > and remove rl0. The situation was absolutely the same! timeouts and > timeouts again.... > After seeing this isn't helping I've patched my kernel with > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-patches/ata/files/patch-ata.diff?view=markup > this patch and tried increasing the timeout to 10 then to 15 then to 25 > - nothing helped. > I got crazy and pulled of my home movie station (PIII 1ghz, 384ram, > via(I think chipser) - I'll post new dmesg here). > I've moved the disks (only 4 of the as I wasn't using the fitfth) and > plugged xl0, fxp0 and promise card in the new machine. > It started just fine and seemed to work while.... I've started to get > the *bad* timeouts again! > F***!!! I saw that the timeout of the tunable sysctl is 5 and increased > it to 15 but still on heavy (read mythtv scan about 300G media files and > other stuff) and 3-4 fetches fetching online radios) ... so I think is > has something to do with the promise card. The patch you're trying for FreeNAS does not guarantee success (I thought I outlined this in my Wiki, but maybe I should put it in bold). It helps for some people, which indicates that their disks are taking longer than 5 seconds to perform some internal operations. Your problem is of quite a different nature. You're being plagued with a multitude of problems. > Oh yes, I've also got > Sep 28 21:32:47 azimud kernel: xl0: transmission error: 90 > Sep 28 21:32:47 azimud kernel: xl0: tx underrun, increasing tx start > threshold to 120 bytes This is a completely different issue, and is commonly seen on xl(4) cards. I know because I used to deal with this caveat on my xl-based servers many years ago. You might see this message a few times as it increases the RX and TX byte buffers accordingly. > because these problems drives me tooo mad! I simply want a working machine, Your motherboard lacks an APIC for starters, which means lots of devices are going to share a single IRQ. There's no guarantee your motherboard is at all stable/reliable either; so far the evidence points to it being too overloaded, or flaky. There's also the issue of bus mastering, although I'm not sure if this could cause the problems seen with the Promise card. Additionally, you're using rl(4) and xl(4). The rl(4) man page is indicative of engineering mistakes by Realtek, and xl(4) is older, but should still work. fxp(4) (e.g. Pro/100 S) is reliable and still occasionally used, but has been superseded by em(4) -- Intel, AFAIK, does not sell fxp-based chips any longer. In fact, I think the Pro/1000 PT cards cost less than what you might find a Pro/100 S card for. You might start by disabling features in your BIOS (specifically any on-board chips which you don't use, e.g. USB, unused PATA ports, etc). This can free up IRQs, and depending upon how your motherboard shares IRQs with certain PCI levels (e.g. PCI-A through PCI-D), you might be able to find a good configuration where each card is on a separate IRQ. > I'm going to pull of the xl0 and promise card from this machine (use > integrated ide controllers) and another fxp because seems that fbsd now > has problems and with xl's (Which reminds me for the 4.X - it used to > work perfectly with xls rls fxps... but that's another topic...anyways). I'm sorry to tell you, but 4.x had the same issues with xl(4) as you're reporting. It's dependent upon the amount of network I/O you put through the card. > If that doesn't help I'll be forced to migrate to linux :(... And what's wrong with that? There is absolutely no shame in using a different operating system. I do not know why people seem to think that FreeBSD "does everything and does it better than ". This is flat out untrue. I often wonder what makes people think that in the first place. I remind people of this quite often: use whatever tool/OS gets the job done for you. If you run into problems with one, and the amount of effort it's taking to work around or solve the problems isn't worth it, go with something else. > Because I'll have free machine with the problematic promise ultra133 > controller and two disks in it, I can provide a serial console to this > machine is anyone is interested in debugging this issue.... anyone? Regarding the ATA errors specifically (not your other problems) -- if they are easily reproducible, set up remote serial console and immediately contact Scott Long . He has offered to help track these issues down, but absolutely requires *reliable* test cases. > here are the new info: > http://valqk.ath.cx/tmp/dmesg.new > http://valqk.ath.cx/tmp/vmstat.new > > (oh I have no usbs connected to this machine [yet]). > > cheers, > valqk. > > Anton - Valqk wrote: > > Thanks Jeremy and Peter, > > you are right that the machine has *lots* ot hardware in it, > > I was thinking of the power supply as a reason and measured the 5 and 12 > > volts - seemd to be ok 11.8 and 5.2 with all hardware in it. > > The shared irq is the one I've thought of and that's why I've posted > > vmstat -i to hear your opinion. > > [forgot to mention that I've read the wiki and next step is to patch the > > kernel with > > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-patches/ata/files/patch-ata.diff?view=markup > > this patch (any bad words for this patch or could just run - nothing bad > > can happen?)] > > > > Yes, I have 3 nics(2 on pci) + pci ide promise, I'll get a smart switch > > with vlans and I'll leave just the integrated xl0 and fxp0 with both > > external ips on it these days, > > but first I'll patch the kernel if Jeremy says it won't hurt (as far as > > I saw just a timeout is moved from hardcoded value to a sysctl?)... > > I have another promise card that is a raid controller, but when I've > > started loking for one I've asked here and there were answers for > > PROMISE ULTRA ATA133 for being a good card for my freebsd ( > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=290848+0+archive/2008/freebsd-stable/20080316.freebsd-stable > > ) > > (hmm, just saw that Jeremy pointed out promise card: 'Their Ultra133 > > TX2 card works fine on 33MHz PCI bus machines; don't worry about the > > card being 66MHz, it will downthrottle correctly.') so maybe the problem > > will be solved if I leave just two nics and no rl0... > > Actually I'm using 6.3 here because I didn't wanted this to happen and I > > was ware of such problems happening on 7-current.... > > > > So test must be done... pls just answer about the patch will it be > > helpful or I should try: > > > > 1. remove rl0 and run only one isp for the test. > > 2. replace the ultra 133 card with another one. > > 3. try to replace the ATA100 cables (the one with 80 wires) with an > > older ones with only 40 cabels? > > 4. ? anything else? > > > > > > Anton - Valqk wrote: > > > >> Hello, > >> I have a VERY strange behaving 6-3p3 with DMA tmieouts and network cards > >> 'dropping traffic'. > >> Following is the explanation of hardware and the thinga that are happening. > >> The machine is DELL optiplex PII 300mHZ with 512RAM. > >> It has 3 NICs: > >> fxp0: flags=8843 mtu 1500 > >> options=8 > >> inet 7.8.9.10 netmask 0xfffff000 broadcast 7.8.9.255 > >> ether 00:91:21:16:14:bf > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> rl0: flags=8843 mtu 1500 > >> options=8 > >> inet 8.9.10.11 netmask 0xffffffe0 broadcast 8.9.10.255 > >> ether 00:02:44:73:2a:fa > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> xl0: flags=8843 mtu 1500 > >> options=9 > >> inet 192.168.123.2 netmask 0xffffff00 broadcast 192.168.123.255 > >> inet 192.168.123.5 netmask 0xffffff00 broadcast 192.168.123.255 > >> inet 192.168.123.6 netmask 0xffffff00 broadcast 192.168.123.255 > >> ether 00:c0:4f:20:66:a3 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> fxp0 and rl0 are external links to the world and are plugged into pci slots > >> xl0 is the internal interface and is integrated on motherboard. > >> It also has 1 PROMISE ULTRA133 ATA pci IDE controller plugged into the > >> pci slot. > >> It has 5 disks in it - 4 connected to the PROMISE card and 1 to the > >> motherboard ide. > >> > >> they are as follows: > >> ad0 and ad6 are two identical hitachi disks in gmirror for the system > >> and a partition that I keep backups on. > >> > >> ad4, ad5 and ad7 are storage disks - seagates 500GB 8mb cache that I > >> keep isos etc files on and are the problematic (maybe because of high > >> traffic operations compared to the other two?). > >> > >> What is the problem: > >> Actually there are two problems: > >> 1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep > >> files over 4-5MBs and write/read very often with 3-6-8MB/s from the > >> disk. I don't use ad4 so I can not tell if there's gona be timeous but I > >> suppose there will (currently has linux partitions on it and is not > >> mounted). I get these errors: > >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5554848 > >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5914112 > >> dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=14924096 > >> dmesg.today:ad7: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=374303456 > >> dmesg.today:ad7: FAILURE - WRITE_DMA48 status=51 > >> error=10 LBA=374303456 > >> dmesg.today:g_vfs_done():ad7[WRITE(offset=191643369472, > >> length=131072)]error = 5 > >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50757760 > >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50760192 > >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12032 > >> dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50769792 > >> > >> strange thing is that I'm seeing the g_vfs_done just recently and this > >> problem is from the very start of this hardware setup of the machine. > >> The machine used to work with two hitachi disks connected to the ad0 and > >> ad1 (integrated ide) and only one - xl0 - nic perfectly. > >> The problems started when I plugged in the PROMISE and other nic cards > >> and started using it as router, fileserver and backup server (each in > >> separate jail, except the pf firewall). > >> 2. The other strange issue is that when (I guess) it starts timeouting > >> *sometimes* not everytime I'm loosing connection to xl0 or fxp0 > >> (sometimes the rl0 works and accepts connections from the outside, > >> sometimes - not). When I go to the machine and plug a monitor - there > >> are no messages from kernel, no logs in /var/log/messages or debug - > >> noting. Stange thing is that I ping host from the local net and it time > >> outs, ifconfig shows that interface is connected at fd 100mbit and > >> everyting seems ok. I've tried ifconfig xl0 down up but doesn't help, > >> tried plugging out the cable and it got connected but not packets passed > >> - timeout again! > >> I've rebooted and nic came up. These 'drops' became more and more common > >> recently and last night I wasn't able to login for about an hour and > >> after that the machine came back up again by itself!!!that's in the lan > >> - but it wasn't accessible at all from the outside - strange thins is > >> that it replied to ping but I wasn't able to even open the ssh port > >> connection and the nat wasn't working?! After that I've remembered that > >> at this time I have a cronjob started for about an hour that fetches > >> into a file a online radio cast for an hour.... wired!!! it also have > >> rtorrent, apache22, samba (in a jail) runing. > >> > >> some output from it can be found here: > >> http://valqk.ath.cx/tmp/dmesg > >> http://valqk.ath.cx/tmp/vmstat > >> http://valqk.ath.cx/tmp/smartctl > >> > >> > >> please give any ideas/hints/solutions! > >> > >> thanks a lot to everyone! > >> cheers, > >> valqk. > >> _______________________________________________ > >> 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" > >> > >> > >> > > > > _______________________________________________ > > 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" > > > > > > _______________________________________________ > 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" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 09:13:29 2008 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 2E862106568B; Mon, 29 Sep 2008 09:13:29 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id B1B528FC25; Mon, 29 Sep 2008 09:13:28 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id m8T93Aba070781; Mon, 29 Sep 2008 11:03:10 +0200 (CEST) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id m8T93AN6070780; Mon, 29 Sep 2008 11:03:10 +0200 (CEST) (envelope-from hk) Date: Mon, 29 Sep 2008 11:03:10 +0200 From: Holger Kipp To: "firmdog@gmail.com" Message-ID: <20080929090310.GA70418@intserv.int1.b.intern> References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Jeremy Chadwick , stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 09:13:29 -0000 On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB > data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. > The speed performance was terrible and I could only get up to 10 Mb/s and there > was NO switch involved. I believe there is a problem or bug involved with the > driver. Have the drivers or stack been updated in 7.1? What else can I provide? Hi, I only flipped through the messages in this thread, faintly remembering someone writing something about ssh. Anyway, if you're copying using ssh (scp, sftp), then the transfer rate is much less than what you'd expect - due to the encryption/decryption overhead (unless you have hardware acceleration on both sideds). Just my two cents (Euro) on general reasons for slow data transfers. Regards, Holger Kipp From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 09:39:59 2008 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 18C8D1065699; Mon, 29 Sep 2008 09:39:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id BC1C08FC25; Mon, 29 Sep 2008 09:39:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KkFET-000A7V-CO; Mon, 29 Sep 2008 12:39:57 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Claus Guttesen" In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to "Claus Guttesen" message dated "Mon, 29 Sep 2008 10:40:05 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 2008 12:39:57 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , Robert Watson , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 29 Sep 2008 09:39:59 -0000 > > it more difficult than I expected. > > for one, the kernel date was missleading, the actual source update is the key, so > > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > > yet seems relevant. > > > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > > give the same throughput, which seem to point to UDP changes ... > > Can you post the network-numbers? [again :-] > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ should now read: /---- Aug 18 ------/ /--- Aug 19 ----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 10:00:13 2008 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 AF0FF106569F for ; Mon, 29 Sep 2008 10:00:13 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 356E08FC28 for ; Mon, 29 Sep 2008 10:00:12 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1346484fgb.35 for ; Mon, 29 Sep 2008 03:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bFjcSDPA5KcI7LXkoKMpc+bmc8mFrjNUJ7AhTt47FC4=; b=EtVW12jYdPQcb6MlO3rsFDj2Ahyzl+K9hHm8d/1EsXyYnnIx1RViXITqCFWpWqHUvX EzQetog8JTKbWg+oSWucQ0cdWm365ssjUl67Lp/MkC/kPonTGixR7nNyvHwfLjDp6pSd Isa8YmJdecjNmDB8hbvpvjKhupcM3GywWtlaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YN4o7BL5QnqQtGIeEEsZTtq/btX55F0ObgPH3495ZXfLf2i9qXQfLSmRqe14W816bk FJwj40SR91gAxRm/fqah038NmgGANYz0T8adh13ih4zIjP9EBavAKyKD76VVXx1ofbVO zE5wufSnw+DJqSol1w7OyvdgF2yGtUf63ry28= Received: by 10.86.26.11 with SMTP id 11mr4099623fgz.12.1222682411807; Mon, 29 Sep 2008 03:00:11 -0700 (PDT) Received: by 10.86.54.10 with HTTP; Mon, 29 Sep 2008 03:00:11 -0700 (PDT) Message-ID: Date: Mon, 29 Sep 2008 12:00:11 +0200 From: "Claus Guttesen" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Cc: freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 29 Sep 2008 10:00:13 -0000 On Mon, Sep 29, 2008 at 11:39 AM, Danny Braniss wrote: >> > it more difficult than I expected. >> > for one, the kernel date was missleading, the actual source update is the key, so >> > the window of changes is now 28/July to 19/August. I have the diffs, but nothing >> > yet seems relevant. >> > >> > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' >> > give the same throughput, which seem to point to UDP changes ... >> >> Can you post the network-numbers? > [again :-] Thank you. :-) Was not shure whether tcp gave you same performance compared to udp or tcp-performance was stable throughout the same period where udp would degrade. >> > Writing 16 MB file >> > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > > should now read: > /---- Aug 18 ------/ /--- Aug 19 ----/ >> > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s >> > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s >> > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s >> > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s >> > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s >> > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s >> > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s >> > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s >> > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s >> > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s >> > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s >> > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s >> > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s >> > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s >> > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s >> > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s >> > >> > Average: 75.86 33.00 -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 10:07:32 2008 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 BD057106568C; Mon, 29 Sep 2008 10:07:32 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by mx1.freebsd.org (Postfix) with ESMTP id 745878FC21; Mon, 29 Sep 2008 10:07:32 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id 7EC251B12D; Mon, 29 Sep 2008 12:49:24 +0300 (EEST) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A044D37A926; Mon, 29 Sep 2008 12:49:24 +0300 Received: from a91-153-122-179.elisa-laajakaista.fi (a91-153-122-179.elisa-laajakaista.fi [91.153.122.179]) by emh04.mail.saunalahti.fi (Postfix) with SMTP id E0AAF41C0A; Mon, 29 Sep 2008 12:49:19 +0300 (EEST) Date: Mon, 29 Sep 2008 12:49:19 +0300 From: Jaakko Heinonen To: Edwin Groothuis Message-ID: <20080929094919.GA6642@a91-153-122-179.elisa-laajakaista.fi> References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> <20080928115401.GU3210@k7.mavetju> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928115401.GU3210@k7.mavetju> User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: VAMS Cc: stable@freebsd.org, V??clav Haisman , current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Mon, 29 Sep 2008 10:07:32 -0000 On 2008-09-28, Edwin Groothuis wrote: > > Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse > > sysctlnametomib: No such file or directory > > > > And no processes. > > I didn't expect it not to work on 6.x, I will play around with it > tomorrow to see if it makes sense. According to svn log kern.cp_times sysctl was added in r174070 and MFCd after 6.3/7.0 release. -- Jaakko From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 11:59:17 2008 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 521D4106568D; Mon, 29 Sep 2008 11:59:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BFBD48FC16; Mon, 29 Sep 2008 11:59:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8TBwpFv076764; Mon, 29 Sep 2008 13:58:51 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8TBwped076763; Mon, 29 Sep 2008 13:58:51 +0200 (CEST) (envelope-from olli) Date: Mon, 29 Sep 2008 13:58:51 +0200 (CEST) Message-Id: <200809291158.m8TBwped076763@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, danny@cs.huji.ac.il, Robert Watson , Jeremy Chadwick In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 29 Sep 2008 13:58:51 +0200 (CEST) Cc: Subject: Re: bad NFS/UDP performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, danny@cs.huji.ac.il, Robert Watson , Jeremy Chadwick List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 11:59:17 -0000 Danny Braniss wrote: > Grr, there goes binary search theory out of the window, > So far I have managed to pinpoint the day that the changes affect the > throughput: > 18/08/08 00:00:00 19/08/08 00:00:00 > (I assume cvs's date is GMT). > now would be a good time for some help, specially how to undo changes, my > knowledge of csup/cvs are close to zero. So you've nailed to down to this 24-hour window: http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 I'm afraid that r181822 by rwatson is the most likely candidate that might be causing the regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 12:21:15 2008 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 3A692106568A; Mon, 29 Sep 2008 12:21:15 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id E78358FC22; Mon, 29 Sep 2008 12:21:14 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1KkHUX-000DP0-ET; Mon, 29 Sep 2008 13:04:41 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KkHUX-000Byr-6t; Mon, 29 Sep 2008 13:04:41 +0100 Date: Mon, 29 Sep 2008 13:04:41 +0100 From: Thomas Hurst To: Edwin Groothuis Message-ID: <20080929120441.GA43384@voi.aagh.net> Mail-Followup-To: Edwin Groothuis , current@freebsd.org, stable@freebsd.org References: <20080928054620.GA80250@k7.mavetju> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928054620.GA80250@k7.mavetju> Organization: Not much. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Thomas Hurst Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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: Mon, 29 Sep 2008 12:21:15 -0000 * Edwin Groothuis (edwin@freebsd.org) wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. Looks good, thanks! IO mode seems to have changed a bit, giving different values to 3.5, it seems while 3.5 gives you the count for the sample period, 3.8 always gives you a per-second rate, e.g. top -mio -s 20: 3.8: 44181 freaky 240 0 240 0 0 240 99.74% cat 3.5: 44181 freaky 4664 5 4667 0 0 4667 100.00% cat This might be confusing, since it means values from two different top -mio's are no longer directly comparable. 3.8 also seems to be lacking IO sorting options; "o vcsw" etc are missing. Will they be returning? Also, the [number] argument given to -m io has no effect: top -m io 10 Setting it after loading with "n 10" causes top to exit. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 12:22:34 2008 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 255611065687; Mon, 29 Sep 2008 12:22:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0055B8FC22; Mon, 29 Sep 2008 12:22:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 8A3B546B8C; Mon, 29 Sep 2008 08:22:33 -0400 (EDT) Date: Mon, 29 Sep 2008 13:22:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, danny@cs.huji.ac.il, Jeremy Chadwick , kris@FreeBSD.org In-Reply-To: <200809291158.m8TBwped076763@lurza.secnetix.de> Message-ID: References: <200809291158.m8TBwped076763@lurza.secnetix.de> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: bad NFS/UDP performance 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, 29 Sep 2008 12:22:34 -0000 On Mon, 29 Sep 2008, Oliver Fromme wrote: > Danny Braniss wrote: > > Grr, there goes binary search theory out of the window, > > So far I have managed to pinpoint the day that the changes affect the > > throughput: > > 18/08/08 00:00:00 19/08/08 00:00:00 > > (I assume cvs's date is GMT). > > now would be a good time for some help, specially how to undo changes, my > > knowledge of csup/cvs are close to zero. > > So you've nailed to down to this 24-hour window: > > http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 > > I'm afraid that r181822 by rwatson is the most likely candidate that might > be causing the regression. If we can confirm that it was that specific change, then I can create a patch to restore exclusive locking for UDP and we can see if it was the general move to rwlocking, or specifically the read-locking of certain data structures. Perhaps what we've done is moved contention from a mutex to a sleep lock, reducing the efficiency of handling contention? Adding Kris to the CC line because he often has useful insights on this sort of thing. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 13:31:05 2008 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 75A8F1065688 for ; Mon, 29 Sep 2008 13:31:05 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 337588FC08 for ; Mon, 29 Sep 2008 13:31:04 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 731A919E02A; Mon, 29 Sep 2008 15:31:03 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 658D019E027; Mon, 29 Sep 2008 15:31:01 +0200 (CEST) Message-ID: <48E0D8B7.4010502@quip.cz> Date: Mon, 29 Sep 2008 15:31:35 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: sthaug@nethelp.no References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <20080927.100458.74661341.sthaug@nethelp.no> In-Reply-To: <20080927.100458.74661341.sthaug@nethelp.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 13:31:05 -0000 sthaug@nethelp.no wrote: >>>IMHO, a dirty filesystem should not be mounted until it's been fully >>>analysed/scanned by fsck. So again, people are putting faith into >>>UFS2+SU despite actual evidence proving that it doesn't handle all >>>scenarios. >> >>Yes, I think the background fsck should be disabled by default, with a >>possibility to enable it if the user is sure that nothing will >>interfere with soft updates. > > > Having been bitten by problems in this area more than once, I now always > disable background fsck. Having it disabled by default has my vote too. Is there any possibility to selectively disable / enable background fsck on specified mount points? I can imagine system, where root, /usr, /var and /tmp will be checked by fsck in foreground, but waiting to foreground fsck on data partitions of about 500GB or more (it can take up tens of minutes or "hours") is scary. I need server with ssh running up "quickly" after the crash, so I can investigate what the problem was and not just sit and wait tens of minutes "if" machine gets online again or not... answering phone calls of clients in the meantime. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 13:42:56 2008 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 490C810656A0; Mon, 29 Sep 2008 13:42:56 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 016758FC19; Mon, 29 Sep 2008 13:42:55 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7EE5C19E02D; Mon, 29 Sep 2008 15:42:54 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6EF5819E02A; Mon, 29 Sep 2008 15:42:52 +0200 (CEST) Message-ID: <48E0DB7E.20804@quip.cz> Date: Mon, 29 Sep 2008 15:43:26 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Jeremy Chadwick References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <20080927202250.GA60980@icarus.home.lan> In-Reply-To: <20080927202250.GA60980@icarus.home.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Charles Sprickman , freebsd-stable@FreeBSD.org Subject: Re: Recommendations for servers running SATA drives 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, 29 Sep 2008 13:42:56 -0000 Jeremy Chadwick wrote: > On Sat, Sep 27, 2008 at 03:16:11PM -0400, Charles Sprickman wrote: > >>On Fri, 26 Sep 2008, Jeremy Chadwick wrote: [...] > This also leads me a little off-topic -- when it comes to disk > replacements, administrators want to be able to do this without taking > the system down. There are problems with this, but it often depends > greatly on hardware and BIOS configuration. > > I've successfully done a hot-swap (hardware: SATA hot-swap backplane, > AHCI in use, SATA2 disks), but it required me to issue "atacontrol > detach" first (I am very curious to know what would've happened had I > just yanked the disk). Upon inserting the new disk, one has to be > *very* careful about the order of atacontrol commands given -- there > are cases where "attach" will cause the system to panic or SATA bus to > lock up, but it seems to depend upon what commands were executed > previously (such as "reinit"). > > Sorry if this is off-topic, but I wanted to mention it. Hot-swapping is totally upredictable on FreeBSD (from my experiences). I tried it many times on Asus 1U servers and on Sun Fire X2100 / X2100 M2 with FreeBSD 6.2 and 7.0 (both i386). It sometimes panics on atacontrol detach, but never panics if disk was marked as failed by gmirror and detached by system it-self, then just removed from running machine. It sometimes panics immediately after the re-insertion of disk, sometimes after atacontrol attach. Sometimes it detects and attach disk without my intervention, so I can easily insert the disk in to gmirror. Then I stopped playing with hot-swapping and now always do power off before disk swapping. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 13:52:15 2008 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 5640D1065686 for ; Mon, 29 Sep 2008 13:52:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 36D0D8FC15 for ; Mon, 29 Sep 2008 13:52:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id Lay61a00J0b6N64A3dsEn6; Mon, 29 Sep 2008 13:52:14 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id LdsC1a00V4v8bD78PdsDek; Mon, 29 Sep 2008 13:52:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=qWPCJf9plI8tu1H20qwA:9 a=yXn4UqdH3LRhoTqbaqoA:7 a=n8r8LW2KJjAu1q9yVkT7t1me1PEA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C513DC9437; Mon, 29 Sep 2008 06:52:12 -0700 (PDT) Date: Mon, 29 Sep 2008 06:52:12 -0700 From: Jeremy Chadwick To: Peter Jeremy Message-ID: <20080929135212.GA9553@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <20080927073616.GP15376@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080927073616.GP15376@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Derek Kuli??ski , freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 13:52:15 -0000 On Sat, Sep 27, 2008 at 05:36:17PM +1000, Peter Jeremy wrote: > On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick wrote: > >On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: > >> As far as I know (at least ideally, when write caching is disabled) > ... > >FreeBSD atacontrol does not let you toggle such features (although "cap" > >will show you if feature is available and if it's enabled or not). > > True but it can be disabled via the loader tunable hw.ata.wc (at > least in theory - apparently some drives don't obey the cache disable > command to make them look better in benchmarks). Off-topic, but those who use it will be interested: hw.ata.wc has always been one of those "why was it done this way?!" features which has bothered me. It never made any sense to either disable or enable WC on all drives, since there's no guarantee the user will want that. With that kept in mind, I've submit a PR containing a small kernel patch, atacontrol patch, and update to the atacontrol man page that allows toggling of WC via "atacontrol wc on/off". http://www.freebsd.org/cgi/query-pr.cgi?pr=127717 Now users will have the ability to do "atacontrol wc on", enabling WC on drives of their choice. And yes, you can toggle on/off in real-time, regardless of what hw.ata.wc contains (that tunable just acts as a default). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 14:13:02 2008 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 61E081065687; Mon, 29 Sep 2008 14:13:02 +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 C4D5B8FC14; Mon, 29 Sep 2008 14:13:01 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id m8TECxbU034670 ; Mon, 29 Sep 2008 16:12:59 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m8TECvO8097951 ; Mon, 29 Sep 2008 16:12:57 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m8TECvkp097948; Mon, 29 Sep 2008 16:12:57 +0200 (MEST) (envelope-from arno) To: pyunyh@gmail.com References: <20080929043134.GD54819@cdnetworks.co.kr> From: "Arno J. Klaassen" Date: 29 Sep 2008 16:12:56 +0200 In-Reply-To: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: Lines: 184 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (shiva.jussieu.fr [134.157.0.168]); Mon, 29 Sep 2008 16:12:59 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8353/Mon Sep 29 11:57:09 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48E0E26B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48E0E26B.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 48E0E26B.000 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.006 -> S=0.006 X-j-chkmail-Status: Ham Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 14:13:02 -0000 Dear Pyun, thanx for your prompt answer (as usual). Pyun YongHyeon writes: > On Sat, Sep 27, 2008 at 11:21:00PM +0200, Arno J. Klaassen wrote: > > > > > > Hello, > > > > I've serious network performance problems on a HP Turion X2 > > based brand new notebook; I only used a 7-1Beta CD and > > 7-STABLE on this thing. > > > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > > > # scp -p ports.tgz login@mv:/tmp/ > > ports.tgz 100% 98MB 88.7KB/s 18:49 > > > > (doing the same thing by copy from an nfs-mounted disk even > > takes mores than an hour ...) > > > > > > Doing a top(1) aside, just shows the box 100% idle : > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > > > > I tested : > > > > Update Bios > > ULE /4BSD > > PREEMPTION on/off > > PREEMPTION + IPI_PREEMPTION > > hw.nfe.msi[x]_disable=1 > ^^^^^^^^^^^^^^^^^^^^^^^ > This has no effect as MCP65 lacks MSI/MSI-X capability. > > > > All don't seem to matter to the problem. > > > > I put two tcpdumps (server and client during another scp(1) ) on > > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > > lots of sequences like : > > > > TCP Previous segment lost > > TCP Duplicate ACK 1 > > TCP Window update > > TCP Duplicate ACK 2 > > TCP Duplicate ACK 3 > > TCP Duplicate ACK 4 > > TCP Duplicate ACK 5 > > TCP Fast retransmission (suspected) > > TCP ... > > TCP Out-of-Order segment > > TCP ... > > > > > > As usual, feel free to contact me for further info/tests. > > > > AFAIK it seems that you're the first one that reports poor > performance issue of MCP65. someone must be ;) no kiddin, I am not convinced this is (only) a driver issue (cf. "bad NFS/UDP performance" thread on -hackers). I just have no experience on this notebook, so I can't say " it worked great before" and my only other 7-stable-amd64 I have does not show the probs, having a cheap re0 *and* being UP. > MCP65 has no checksum offload/TSO > capability so nfe(4) never try to take advantage of the hardware > capability. So you should have no checksum offload/TSO related > issue here. > Also note, checking network performance with scp(1) wouldn't > show real numbers as scp(1) may involve other system activities. > Use one of network benchmark programs in ports(e.g. > benchmarks/netperf) to measure network performance. quite funny (even taken with lots of salt since the LAN is used for "normal work" as well in parallel, but differences are rather significant) : I test to same server (7-stable-amd64 from Jun 7 (using nfe0 as well btw, but another chip), either from a 6-stable-x86 (Jul 14, sk0) or the notebook (7-stable-x64 below), using for i in ; do echo $i; /usr/local/bin/netperf -H push -i 4,2 -I 95,10 -t $i; echo; done streaming results are OK for both : TCP_STREAM Throughput 10^6bits/sec 6-stable-x86 349.57 7-stable-x64 939.47 UDP_STREAM Throughput 10^6bits/sec 6-stable-x86 388.45 7-stable-x64 947.89 However, the "request/respones" tests are awfull for my notebook (test repeated on the notebook for the sake of conviction) : TCP_RR Trans. Rate per sec 6-stable-x86 9801.58 7-stable-x64 137.61 7-stable-x64 89.35 7-stable-x64 102.29 TCP_CRR Trans. Rate per sec 6-stable-x86 4520.98 7-stable-x64 7.00 7-stable-x64 8.10 7-stable-x64 18.49 UDP_RR Trans. Rate per sec 6-stable-x86 9473.20 7-stable-x64 9.60 7-stable-x64 0.90 7-stable-x64 0.10 I can send you complete results if wanted. > Other possible cause of issue could be link speed/duplex mismatch > or excessive MAC control frames(e.g. pause frames). Does nfe(4) > agree on resolved speed/duplex with link partner? yes (1000baseTX ) > If they all agree on resolved speed/duplex, would you check number > of pause frames sent/received from link partner? Even though MCP65 > supports hardware MAC statistics for pause frames nfe(4) has no > support code yet so you may have to resort to managed switch that > can show Tx/Rx statistics of each port. aargh; I do have a Netgear GS724TS around where I can connect it to. This thing should be manageable, but give me some time to find out how .... Thanx, Arno From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 14:47:32 2008 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 9BCCB1065690 for ; Mon, 29 Sep 2008 14:47:32 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7B48FC1F for ; Mon, 29 Sep 2008 14:47:31 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8TElOkU005408; Mon, 29 Sep 2008 15:47:24 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KkK20-0004Yz-1Q; Mon, 29 Sep 2008 15:47:24 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8TElNJ0025986; Mon, 29 Sep 2008 15:47:23 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8TElMPL025985; Mon, 29 Sep 2008 15:47:22 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <48E0DB7E.20804@quip.cz> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <20080927202250.GA60980@icarus.home.lan> <48E0DB7E.20804@quip.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 29 Sep 2008 15:47:22 +0100 Message-Id: <1222699642.24339.12.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Charles Sprickman , Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: Recommendations for servers running SATA drives 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, 29 Sep 2008 14:47:32 -0000 On Mon, 2008-09-29 at 15:43 +0200, Miroslav Lachman wrote: > Jeremy Chadwick wrote: > > > On Sat, Sep 27, 2008 at 03:16:11PM -0400, Charles Sprickman wrote: > > > > I've successfully done a hot-swap (hardware: SATA hot-swap backplane, > > AHCI in use, SATA2 disks), but it required me to issue "atacontrol > > detach" first (I am very curious to know what would've happened had I > > just yanked the disk). Upon inserting the new disk, one has to be > > *very* careful about the order of atacontrol commands given -- there > > are cases where "attach" will cause the system to panic or SATA bus to > > lock up, but it seems to depend upon what commands were executed > > previously (such as "reinit"). > > > > Sorry if this is off-topic, but I wanted to mention it. > > Hot-swapping is totally upredictable on FreeBSD (from my experiences). I > tried it many times on Asus 1U servers and on Sun Fire X2100 / X2100 M2 > with FreeBSD 6.2 and 7.0 (both i386). I can't speak for the Dell, but I can at least say that at least on the X2100, not even Solaris supports either hot-swapping or the built in software RAID. When they were first released the advertising said that they had these, but those claims was quietly removed from the website some weeks after release. Short answer: give up on hot-swap the X2100. As for the X2100 M2, that is supposed to support it, and I believe it works fine for us under Solaris. I'm not sure if I've got any spare M2's here, if so I'll have a play. Gavin From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:09:47 2008 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 E3AAF1065686 for ; Mon, 29 Sep 2008 15:09:46 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 97D598FC0C for ; Mon, 29 Sep 2008 15:09:46 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so421828wra.27 for ; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=VpQgeLpcnM8yTtb6CI1cY0OZUjnqfJ4XXez2OhJniDo=; b=I8nhFD5Cc+FALb0r5Urp/CupFe2CJ5EYbY9VT7dzMACiJigbHtUhUg7oyy6TUKlRGs hsGu5RNFXyhe0dPKLwbeyb7oCx7NpkcutwcDdlaPWkT0N67lNFJHEXsLm6T1E8m4Wvw7 6j7itY9dOnnpn32/ZfOGdFJjgbNE0HTDuYGbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=PRU+N+GJBIej5M2UZtKHCdyHnd5fueoLlZpR/dSW8igyBpT8X52TXF0C2WXW+nX+Dz Xi8Ir5Immbsi7rM9ciFoTkEM/NebIw65Rf1YeIxvRe4ZZqSxBewBhyuY4/V+S8JN4G0j OB8ophZcjVr3U2NmZJi9lZI1mXVc9sU8hi5nE= Received: by 10.151.47.7 with SMTP id z7mr8061912ybj.2.1222700985738; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) Message-ID: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> Date: Mon, 29 Sep 2008 11:09:45 -0400 From: "Zaphod Beeblebrox" To: "Andrew Snow" In-Reply-To: <48E080C0.9070103@modulus.org> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 15:09:47 -0000 On Mon, Sep 29, 2008 at 3:16 AM, Andrew Snow wrote: > However, as a core general purpose filesystem, it seems to have flaws, not >> the least of which is a re-separation of file cache and memory cache. >> > > For me, this doesn't matter because ZFS is so much faster than UFS > overall. Even if you don't use any of its features, the latest version > does sequential I/O and heavy random I/O faster than UFS on the same > hardware for me. > > Cases where UFS is faster are proving to be the exception rather than > the rule. > > However, I cannot recommend its use until it is stable, which it > currently still is not, under very heavy load. I certainly can't agree with this. I don't think you're measuring the performance of the machine --- only measuring the performance of the filesystem. When ZFS is active, memory is committed in the kernel to ZFS. That memory is then no longer available for paging. Also, there exists data within the ARC (I'm always tempted to say the ARC Cache, but that is redundant) that is also then in paging memory. You end up having to tune the size of the ARC to your workload, which is how UN*X did it upto 1992 or so. If you choose the wrong size for the ARC, you end up with very poor performance. In particular, the ARC fights for space with the nvidia binary driver (which really does need _real_ memory). To have the driver work at all, I have to keep the ARC from growing too large --- which is at odds with filesystem perofrmance. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:25:11 2008 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 1EB671065691; Mon, 29 Sep 2008 15:25:11 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id C09A88FC23; Mon, 29 Sep 2008 15:25:10 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B51CF19E02A; Mon, 29 Sep 2008 17:25:09 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3023C19E027; Mon, 29 Sep 2008 17:24:59 +0200 (CEST) Message-ID: <48E0F36C.1080400@quip.cz> Date: Mon, 29 Sep 2008 17:25:32 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Gavin Atkinson References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <20080927202250.GA60980@icarus.home.lan> <48E0DB7E.20804@quip.cz> <1222699642.24339.12.camel@buffy.york.ac.uk> In-Reply-To: <1222699642.24339.12.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: Recommendations for servers running SATA drives [hot-swap] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 15:25:11 -0000 Gavin Atkinson wrote: > On Mon, 2008-09-29 at 15:43 +0200, Miroslav Lachman wrote: > >>Jeremy Chadwick wrote: >> >> >>>On Sat, Sep 27, 2008 at 03:16:11PM -0400, Charles Sprickman wrote: >>> >>>I've successfully done a hot-swap (hardware: SATA hot-swap backplane, >>>AHCI in use, SATA2 disks), but it required me to issue "atacontrol >>>detach" first (I am very curious to know what would've happened had I >>>just yanked the disk). Upon inserting the new disk, one has to be >>>*very* careful about the order of atacontrol commands given -- there >>>are cases where "attach" will cause the system to panic or SATA bus to >>>lock up, but it seems to depend upon what commands were executed >>>previously (such as "reinit"). >>> >>>Sorry if this is off-topic, but I wanted to mention it. >> >>Hot-swapping is totally upredictable on FreeBSD (from my experiences). I >>tried it many times on Asus 1U servers and on Sun Fire X2100 / X2100 M2 >>with FreeBSD 6.2 and 7.0 (both i386). > > > I can't speak for the Dell, but I can at least say that at least on the > X2100, not even Solaris supports either hot-swapping or the built in > software RAID. When they were first released the advertising said that > they had these, but those claims was quietly removed from the website > some weeks after release. Short answer: give up on hot-swap the X2100. > > As for the X2100 M2, that is supposed to support it, and I believe it > works fine for us under Solaris. I'm not sure if I've got any spare > M2's here, if so I'll have a play. It was about year ago with Asus and Sun Fire X2100. I don't have Asus servers now (all returned as reclamation). Now I am running one X2100 and about ten X2100 M2. I have one spare X2100 M2, so if somebody have exact order of commands used to "hot-swap" the disk, I can test it in few days. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:26:56 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5EEBE1065691; Mon, 29 Sep 2008 15:26:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Mon, 29 Sep 2008 11:26:26 -0400 User-Agent: KMail/1.6.2 References: <48DFC3F9.1040909@highperformance.net> <20080928194013.GD87069@icarus.home.lan> In-Reply-To: <20080928194013.GD87069@icarus.home.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809291126.40671.jkim@FreeBSD.org> Cc: Jeremy Chadwick , "Jason C. Wells" Subject: Re: Blacklisted ACPI Prevents Boot 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, 29 Sep 2008 15:26:56 -0000 On Sunday 28 September 2008 03:40 pm, Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 10:50:49AM -0700, Jason C. Wells wrote: > > I just installed a 6.4-PRERELEASE kernel and tried to boot. The > > boot failed with a message that my ACPI was blacklisted. I have > > had 'device acpi' in my kernel for some time now. The boot > > interruption is new behavior. > > > > Is this sort of change a good thing to put in UPDATING? > > Please read the following thread, which includes a patch for the > mistake. > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/th >read.html#45080 > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/04 >5080.html No, we haven't touched the file for RELENG_6: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_quirk.c?only_with_tag=RELENG_6 It should be something else. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:32:23 2008 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 DCD1410656A3 for ; Mon, 29 Sep 2008 15:32:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 35F8F8FC16 for ; Mon, 29 Sep 2008 15:32:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Ld2D1a00M0xGWP856fYNg0; Mon, 29 Sep 2008 15:32:22 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA12.westchester.pa.mail.comcast.net with comcast id LfYM1a0044v8bD73YfYMCt; Mon, 29 Sep 2008 15:32:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=zWTp1yHTipkA:10 a=6gU17RteXIwA:10 a=QycZ5dHgAAAA:8 a=Qe9082PCmkl5Zm7JRmEA:9 a=R2NeaqguzN5PgmoUEx2_V3vK6sUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C3959C9437; Mon, 29 Sep 2008 08:32:20 -0700 (PDT) Date: Mon, 29 Sep 2008 08:32:20 -0700 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080929153220.GA11459@icarus.home.lan> References: <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <20080927202250.GA60980@icarus.home.lan> <48E0DB7E.20804@quip.cz> <1222699642.24339.12.camel@buffy.york.ac.uk> <48E0F36C.1080400@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E0F36C.1080400@quip.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Gavin Atkinson , freebsd-stable@FreeBSD.org Subject: Re: Recommendations for servers running SATA drives [hot-swap] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 15:32:24 -0000 On Mon, Sep 29, 2008 at 05:25:32PM +0200, Miroslav Lachman wrote: > It was about year ago with Asus and Sun Fire X2100. I don't have Asus > servers now (all returned as reclamation). Now I am running one X2100 > and about ten X2100 M2. I have one spare X2100 M2, so if somebody have > exact order of commands used to "hot-swap" the disk, I can test it in > few days. I believe the correct order of operation is to do a "detach" on the channel before physically removing the disk, insert the new disk, then do "attach" on the same channel. "list" should be done afterwards to ensure the new disk shows up. If you want me to verify for certain, I have a test box built in the other room which has a SATA hot-swap backplane on it. I've also seen cases where the "attach" works, but upon doing "list", the old disk ID/string is still shown. In this case I had to do a "detach", remove the disk, insert the new disk, "reinit", then an "attach" for things to work. Finally, I've also seen the kernel panic or hard-lock after running "reinit", but this may have had something to do with Intel MatrixRAID. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:38:47 2008 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 3FDF810656A6; Mon, 29 Sep 2008 15:38:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D55508FC2A; Mon, 29 Sep 2008 15:38:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8TFcMlh045541; Mon, 29 Sep 2008 11:38:39 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 29 Sep 2008 11:15:36 -0400 User-Agent: KMail/1.9.7 References: <48DE7D83.2070205@comcast.com> In-Reply-To: <48DE7D83.2070205@comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809291115.36776.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 29 Sep 2008 11:38:39 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8353/Mon Sep 29 05:57:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: "John L. Templer" , sos@freebsd.org Subject: Re: 7.1-PRELEASE sporadically panicking with fatal trap 12 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, 29 Sep 2008 15:38:47 -0000 On Saturday 27 September 2008 02:37:55 pm John L. Templer wrote: > I'm running 7.1-PRERELEASE, with /usr/src and /usr/ports last csup-ed > just a few days ago. After being up for about a day or so the system > will panic because of a page fault. I'm not completely sure, but it > seems that the system is more stable when gdm and gnome are disabled in > rc.conf. At least it stayed up for several days when I did that. > > I've run memtest several times, so I'm pretty confident it's not a > memory problem. Also the stack trace is always the same, so I'm > thinking it's not hardware related. > > I've attached a stack trace from kgdb, and the output from dmesg. I'd > appreciate any help you could give me with this. Generally when I see this panic (at this source line in mtx_lock() and with an offset of 0x188 or 0x18c), it is because the mutex is destroyed (mtx_lock == 6 (MTX_DESTROYED). In this case since you got it in a task, I'm guessing ata destroyed a structure w/o draining the task, so the task executed after the structure containing the mutex was destroyed. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:49:07 2008 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 4BC261065687 for ; Mon, 29 Sep 2008 15:49:07 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id F24B98FC0A for ; Mon, 29 Sep 2008 15:49:06 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so332986ywe.13 for ; Mon, 29 Sep 2008 08:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=dfV7c6oJkTI/mXmSDw5pGH7+GP0pSiICh/tsKmcmmuE=; b=sjeAuslrzM3CZ9aY40h63K+hKv9PSzOexFq/8NoXxmBRd2CqlvwSM45vVhLFpawL2+ 3+qHTXT9MUtBQgToX/mvNp1U4dXFsOfWB9koxcpV2kyvZWHbvYl5FmtmkYHReqrikVhc 3KKAG6TdFHdJcI+0buDEA/N8yIemHtMmwFgPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=kh+CXkgBW7iDEzRu0x8kqLDpaTffG2hmooHIT9pCHhhGvtLiyQoiR5eIlLaYuThCYZ 4scPtgIBDGf3PwdmnE1KBj5ewiTLQisYxLT6CicVNevi4jPrv1+qfqGnOBmnlgp0KUjJ BNfiRptCYjJApS9JY8oK/7ATO+jLYOiO7wOXs= Received: by 10.151.45.2 with SMTP id x2mr8073024ybj.114.1222703346231; Mon, 29 Sep 2008 08:49:06 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Mon, 29 Sep 2008 08:49:06 -0700 (PDT) Message-ID: <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> Date: Mon, 29 Sep 2008 11:49:06 -0400 From: "Zaphod Beeblebrox" To: "Andrew Snow" In-Reply-To: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 15:49:07 -0000 On Mon, Sep 29, 2008 at 11:09 AM, Zaphod Beeblebrox wrote: > > I certainly can't agree with this. I don't think you're measuring the > performance of the machine --- only measuring the performance of the > filesystem. When ZFS is active, memory is committed in the kernel to ZFS. > That memory is then no longer available for paging. Also, there exists data > within the ARC (I'm always tempted to say the ARC Cache, but that is > redundant) that is also then in paging memory. You end up having to tune > the size of the ARC to your workload, which is how UN*X did it upto 1992 or > so. If you choose the wrong size for the ARC, you end up with very poor > performance. > > In particular, the ARC fights for space with the nvidia binary driver > (which really does need _real_ memory). To have the driver work at all, I > have to keep the ARC from growing too large --- which is at odds with > filesystem perofrmance. > I thought about this statement a bit, and I believe it might be good to give a real world example. I use spamprobe. It's a dual-word basian spam filter. It runs from procmail as part of the local delivery process on my laptop for mail. It uses one of the berkley DB variants (I forget which at the moment and my binary is statically linked so it will run on AMD64 as well as I386, so I can't easily check). I strongly suspect that the basic operation of spamprobe involves mmap()ing the file (80 to 100 meg), performing a flurry of lookups (words in the message) followed by a flurry of updates, followed by closing the file. Now my current laptop has ZFS for my home directories and that ZFS is backed by two 320G laptop drives (RAID 1). My old laptop has UFS on a single 160G laptop drive. The old laptop would deliver 10 to 20 email messages per second through spamprobe. The new laptop deilvers a mail message every 2 to 5 seconds. In the UFS case, there would be little disk activity. Running spamprobe would only involved cached items and the disk activity would be the occaisional write to sync the new data and writes to deposit each email message. Now there's some things I don't know. Is the whole file rewritten to sync the changes? It seems like it is. Whatever the difference between UFS and ZFS here, it's triggering some pathological behavior. The needs of NAS are not the needs of a local filesystem. They are different beasts. If ZFS is optimized for being a NAS store, it does this well. Maybe UFS can become more ZFS like or vice-versa. ZFS is a comparatively young filesystem (and UFS is an equally old one). From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:05:49 2008 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 DCD99106569F for ; Mon, 29 Sep 2008 17:05:49 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id A4AE18FC23 for ; Mon, 29 Sep 2008 17:05:49 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 31230 invoked by uid 89); 29 Sep 2008 16:25:37 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 29 Sep 2008 16:25:37 -0000 Message-Id: From: Dan Allen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 11:05:46 -0600 X-Mailer: Apple Mail (2.929.2) Subject: Missing fstab 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, 29 Sep 2008 17:05:49 -0000 In messing around trying to get a bootable FreeBSD system on a memory stick I messed up and deleted my fstab file on my main FreeBSD STABLE machine. Actually a script I was writing overwrote it... arrggghh. I feel so stupid. Anyway, my system now boots and then dies midway in boot because there is no /etc/fstab. I get the mountroot prompt, I type in ufs:ad0s2a (my main root partition) and it begins booting fine. So far so good. It then goes into single user mode, which is fine, but it leaves my main root filesystem as readonly, which is not so fine. This is because of the missing /etc/fstab file. I have a backup of my fstab file on a USB memory stick. I can mount the stick on /mnt and then I type /sbin/mount -F /mnt/fstab -f -u -w / thinking that it will now update the drive to readwrite. It does not. The command appears to succeed but running mount again shows the file system is still read-only. It will not mount my main root file system readwrite. I believe my main file system is fine. I can see all of my files readonly. I cannot change my root file system in order to copy my backup fstab back to /etc/fstab because the file system refuses to be updated to readwrite. This is my core problem. fsck will not run because there is no /etc/fstab and there is no option that I can find that will allow a different fstab to be used, although running fsck is not my central problem. Any ideas on how to force the file system to be readwrite long enough for me to replace my /etc/fstab file? Dan From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:11:21 2008 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 D43B91065696 for ; Mon, 29 Sep 2008 17:11:21 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id A9CC48FC14 for ; Mon, 29 Sep 2008 17:11:21 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 808DB1A9136; Mon, 29 Sep 2008 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07fQQT7Xj1Gj; Mon, 29 Sep 2008 10:05:37 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 312211A90E3; Mon, 29 Sep 2008 10:05:37 -0700 (PDT) Message-ID: <48E10C39.9040907@miralink.com> Date: Mon, 29 Sep 2008 10:11:21 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Dan Allen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Missing fstab 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, 29 Sep 2008 17:11:21 -0000 Dan Allen wrote: > In messing around trying to get a bootable FreeBSD system on a memory > stick I messed up and deleted my fstab file on my main FreeBSD STABLE > machine. Actually a script I was writing overwrote it... arrggghh. > > I feel so stupid. > > Anyway, my system now boots and then dies midway in boot because there > is no /etc/fstab. I get the mountroot prompt, I type in ufs:ad0s2a > (my main root partition) and it begins booting fine. So far so good. > > It then goes into single user mode, which is fine, but it leaves my > main root filesystem as readonly, which is not so fine. This is > because of the missing /etc/fstab file. > > I have a backup of my fstab file on a USB memory stick. I can mount > the stick on /mnt and then I type > > /sbin/mount -F /mnt/fstab -f -u -w / > > thinking that it will now update the drive to readwrite. It does > not. The command appears to succeed but running mount again shows the > file system is still read-only. It will not mount my main root file > system readwrite. I believe my main file system is fine. I can see > all of my files readonly. > > I cannot change my root file system in order to copy my backup fstab > back to /etc/fstab because the file system refuses to be updated to > readwrite. This is my core problem. > > fsck will not run because there is no /etc/fstab and there is no > option that I can find that will allow a different fstab to be used, > although running fsck is not my central problem. > > Any ideas on how to force the file system to be readwrite long enough > for me to replace my /etc/fstab file? > > Dan > A "mount -o rw /dev/ad0s1a /" doesn't "just work" for you? Sean From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:12:36 2008 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 A15401065696; Mon, 29 Sep 2008 17:12:36 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 2483F8FC2C; Mon, 29 Sep 2008 17:12:35 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7482.dip.t-dialin.net [84.154.116.130]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8THCWfr064594; Mon, 29 Sep 2008 19:12:32 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8THCFkv026662; Mon, 29 Sep 2008 19:12:15 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8THC091049553; Mon, 29 Sep 2008 19:12:05 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809291712.m8THC091049553@fire.js.berklix.net> To: Jeremy Chadwick From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Sun, 28 Sep 2008 12:34:07 PDT." <20080928193407.GA87069@icarus.home.lan> Date: Mon, 29 Sep 2008 19:12:00 +0200 Sender: jhs@berklix.org Cc: pyunyh@gmail.com, stable@freebsd.org, Abdullah Ibn Hamad Al-Marri Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 29 Sep 2008 17:12:36 -0000 Hi, Reference: > From: Jeremy Chadwick > Date: Sun, 28 Sep 2008 12:34:07 -0700 > Message-id: <20080928193407.GA87069@icarus.home.lan> Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 11:21:19AM +0200, Julian Stacey wrote: > > Hi, > > Reference: > > > From: "Julian Stacey" > > > Date: Fri, 26 Sep 2008 19:54:04 +0200 > > > Message-id: <200809261754.m8QHs41D011762@fire.js.berklix.net> > > > > "Julian Stacey" wrote: > > > Hi, > > > Reference: > > > > From: "Julian Stacey" > > > > Date: Fri, 26 Sep 2008 19:16:57 +0200 > > > > Message-id: <200809261717.m8QHGvmx011312@fire.js.berklix.net> > > > > > > "Julian Stacey" wrote: > > > > > > I'm remaking binaries, > > > > > > > > New generic kernel built & installed, & install of all src/ done too. > > > > No improvement. > > > > > > > > > Is there reliable way to reproduce the issue? > > > > > > > > Its continuous, the machine virtually never does a ping in less > > > > than 10 seconds. > > > > > > > > > Anyway, would you try attached patch and let me know result? > > > > > > > > Thanks > > > > Done, doesnt help. > > > > Seeing a new message now too: > > > > ping: sendto: No buffer space available. > > > > > > > > Output of vmstat -i and pciconf -lv look the same as before > > > > > > > > It's a small card. Weighs 46 gram. I was going to write > > > > I could simply post it to you, & you could keep it if you > > > > want. As I had quessed it might be some new kind of card > > > > unexperienced before, > > > > RTL8139D, card just says made in China > > > > > > > > But I just grabbed another card > > > > card says Level One. > > > > chip 8139B > > > > & with both patched kernel & original no improvement. > > > > So I tried a totaly different card xl0 fails too, > > > > I think that 3com xl0 card was OK before in another box, > > > > so I'd guess not an rl problem, Sorry. > > > > > > > > Probably not 7.1 either, but probably a BIOS config problem of some sort. > > > > > > > > IRQ 12 was listed in Award BIOS as Primary, options were also secondary or disabled, so Ive set it disabled. > > > > PNP OS Yes > > > > Resources: Auto > > > > "Reset config data" to Enabled (I forgot before after card changes) > > > > > > > > Did another restore BIOS factory defaults, no help. > > > > Moved xl0 to another slot (all other 3 slots never use I guess, as > > > > chassis plates not torn off on what I guess is original chassis. > > > > No luck with xl0 > > > > I'm out of ideas. > > > > > > Got it working on xl > > > interrupt problem, I turned off lpt com2 & something else > > > in bios. > > > Got to go out now > > > Ill go back to rl0 too & report back soon > > > thanks for help both ! > > > > I'm wrong it is Not working. > > (I typed my own own card address of 192.168.x.x by mistake, > > not the 192.168.x.x of another host on net. ) > > > > Ive fiddled more with BIOS IRQ to no good effect > > (not suprsing, dont understand some options in BIOS & no > > MOtherboard manual for this Award BIOS 2A6LGB09, on box: > > fujitsu siemens t-bird > > > > I was wondering if setting anything to polling might help a bit > > I went looking with syctl -a -d | grep hw.pci > > > > hw.pci.enable_msi: 1 > > hw.pci.enable_msi: Enable support for MSI interrupts > > hw.pci.enable_msix: 1 > > hw.pci.enable_msix: Enable support for MSI-X interrupts > > You could try disabling MSI and MSI-X in loader.conf to see if that > makes a difference. > > hw.pci.enable_msi="0" > hw.pci.enable_msix="0" OK Thanks, I just switched back from an xl ro an rl card, I just tried above sysctl s, no help. BTW I dont know if ifconfig -a should show word polling, but it does not. Pyun YongHyeon wrote: > Can you see 'rl0: link state changed to UP' message in dmesg after > you assign an IP address to rl0? > Would you show me the 'ifconfig rl0' output? With an rc.conf of # media 10baseT/UTP # media 100baseTX # media full-duplex # media half-duplex ifconfig_rl0="inet 192.168.91.64 media 100baseTX polling" ifconfig_xl0="inet 192.168.91.64 polling" inetd_enable="YES" before enet cable plugged in I see rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:08:a1:6d:65:07 inet 192.168.91.64 netmask 0xffffff00 broadcast 192.168.91.255 media: Ethernet autoselect (none) status: no carrier & after plug in I see: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:08:a1:6d:65:07 inet 192.168.91.64 netmask 0xffffff00 broadcast 192.168.91.255 media: Ethernet 100baseTX status: active & I see in dmesg rl0: link state changed to UP I suspect I perhaps have something fundamental wrong with BIOS or PC or similar. May be nothing to do with 7.1-BETA ? I think Id better perhaps try with 7.0-RELEASE if you guys dont mind. Hmm I'll dig out a spare disc rather than erase 7.1BETA then I can test with either if you have any more ideas. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:37:33 2008 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 12F6F1065697 for ; Mon, 29 Sep 2008 17:37:33 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF118FC2B for ; Mon, 29 Sep 2008 17:37:32 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m8THbTdH091975; Tue, 30 Sep 2008 01:37:29 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m8THbStK091974; Tue, 30 Sep 2008 01:37:28 +0800 (KRAST) (envelope-from eugen) Date: Tue, 30 Sep 2008 01:37:28 +0800 From: Eugene Grosbein To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080929173728.GA91107@svzserv.kemerovo.su> References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <20080927.100458.74661341.sthaug@nethelp.no> <48E0D8B7.4010502@quip.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E0D8B7.4010502@quip.cz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, sthaug@nethelp.no Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 17:37:33 -0000 On Mon, Sep 29, 2008 at 03:31:35PM +0200, Miroslav Lachman wrote: > >Having been bitten by problems in this area more than once, I now always > >disable background fsck. Having it disabled by default has my vote too. > Is there any possibility to selectively disable / enable background fsck > on specified mount points? > > I can imagine system, where root, /usr, /var and /tmp will be checked by > fsck in foreground, but waiting to foreground fsck on data partitions of > about 500GB or more (it can take up tens of minutes or "hours") is scary. > I need server with ssh running up "quickly" after the crash, so I can > investigate what the problem was and not just sit and wait tens of > minutes "if" machine gets online again or not... answering phone calls > of clients in the meantime. I solve this problem this way: size of /usr is 300Mb or less and it is mounted read-only, so does not have any problem with fsck (it will always skip it as clean); write activity on root fs is minimized by moving objects being modified out of root (/tmp is symlink or other fs, ntp drift is located on /var, not /etc etc.), background fsck is enabled. And you always may use /etc/rc.early to force foreground check for /var even if fsck runs in background later: #!/bin/sh /sbin/fsck -p /var || /sbin/fsck -y /var || exit 1 So, if /var was clean then fsck -p skips it, else it checks it in foreground and marks clean if possible. For serious errors, check runs again trying its best to clean /var and continue. Later background fsck skips clean (possibly fixed already) filesystems. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:41:35 2008 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 91962106568A for ; Mon, 29 Sep 2008 17:41:35 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 564348FC1C for ; Mon, 29 Sep 2008 17:41:35 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 26589 invoked by uid 89); 29 Sep 2008 17:01:22 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 29 Sep 2008 17:01:22 -0000 Message-Id: From: Dan Allen To: Sean Bruno In-Reply-To: <48E10C39.9040907@miralink.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 11:41:33 -0600 References: <48E10C39.9040907@miralink.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable@freebsd.org Subject: Re: Missing fstab 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, 29 Sep 2008 17:41:35 -0000 On 29 Sep 2008, at 11:11 AM, Sean Bruno wrote: > A "mount -o rw /dev/ad0s1a /" doesn't "just work" for you? It didn't, but when you said this I tried something else. I went directly into single user mode myself (option 4 at boot) and THEN I tried this and IT WORKED! Apparently when the system dies in the middle of processing rc.d and then it puts you into single user mode, you are left in a weird state that these commands would not work in. Thanks! Dan From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 17:44:12 2008 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 7C5731065691 for ; Mon, 29 Sep 2008 17:44:12 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF628FC1B for ; Mon, 29 Sep 2008 17:44:11 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m8THiBJV034740 for ; Mon, 29 Sep 2008 10:44:11 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m8THiBlR034739; Mon, 29 Sep 2008 10:44:11 -0700 (PDT) Date: Mon, 29 Sep 2008 10:44:11 -0700 (PDT) From: Matthew Dillon Message-Id: <200809291744.m8THiBlR034739@apollo.backplane.com> To: freebsd-stable@freebsd.org References: <20080921213426.GA13923@0lsen.net> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 29 Sep 2008 17:44:12 -0000 A couple of things to note here. Well, many things actually. * Turning off write caching, assuming the drive even looks at the bit, will destroy write performance for any driver which does not support command queueing. So, for example, scsi typically has command queueing (as long as the underlying drive firmware actually implements it properly), 3Ware cards have it (underlying drives, if SATA, may not, but 3Ware's firmware itself might do the right thing). The FreeBSD ATA driver does not, not even in AHCI mode. The RAID code does not as far as I can tell. You don't want to turn this off. * Filesystems like ZFS and HAMMER make no assumptions on write ordering to disk for completed write I/O vs future write I/O and use BIO_FLUSH to enforce ordering on-disk. These filesystems are able to queue up large numbers of parallel writes inbetween each BIO_FLUSH, so the flush operation has only a very small effect on actual performance. Numerous Linux filesystems also use the flush command and do not make assumptions on BIO-completion/future-BIO ordering. * UFS + softupdates assumes write ordering between completed BIO's and future BIOs. This doesn't hold true on a modern drive (with write caching turned on). Unfortunately it is ALSO not really the cause behind most of the inconsistency reports. UFS was *never* designed to deal with disk flushing. Softupdates was never designed with a BIO_FLUSH command in mind. They were designed for formally ordered I/O (bowrite) which fell out of favor about a decade ago and has since been removed from most operating systems. * Don't get stuck in a rut and blame DMA/Drive/firmware for all the troubles. It just doesn't happen often enough to even come close to being responsible for the number of bug reports. With some work UFS can be modified to do it, but performance will probably degrade considerably because the only way to do it is to hold the completed write BIOs (not biodone() them) until something gets stuck, or enough build up, then issue a BIO_FLUSH and, after it returns, finish completing the BIOs (call the biodone()) for the prior write I/Os. This will cause softupdates to work properly. Softupdates orders I/O's based on BIO completions. Another option would be to complete the BIOs but do major surgery on softupdates itself to mark the dependancies as waiting for a flush, then flush proactively and re-sync. Unfortunately, this will not solve the whole problem. IF THE DRIVE DOESN'T LOOSE POWER IT WILL FLUSH THE BIOs IT SAID WERE COMPLETED. In otherwords, unless you have an actual power failure the assumptions softupdates will hold. A kernel crash does NOT prevent the actual drive from flushing the IOs in its cache. The disk can wind up with unexpected softupdates inconsistencies on reboot anyway. Thus the source of most of the inconsistency reports will not be fixed by adding this feature. So more work is needed on top of that. -- Nearly ALL of the unexpected softupdates inconsistencies you see *ARE* for the case where the drive DOES in fact get all the BIO data it returned as completed onto the disk media. This has happened to me many, many times with UFS. I'm repeating this: Short of an actual power failure, any I/O's sent to and acknowledged by the drive are flushed to the media before the drive resets. A FreeBSD crash does not magically prevent the drive from flushing out its internal queues. This means that there are bugs in softupdates & the kernel which can result in unexpected inconsistencies on reboot. Nobody has ever life-tested softupdates to try to locate and fix the issues. Though I do occassionally see commits that try to fix various issues, they tend to be more for live-side non-crash cases then for crash cases. Some easy areas which can be worked on: * Don't flush the buffer cache on a crash. Some of you already do this for other reasons (it makes it more likely that you can get a crash dump). The kernel's flushing of the buffer cache is likely a cause of a good chunk of the inconsitency reports by fsck, because unless someone worked on the buffer flushing code it likely bypasses softupdates. I know when working on HAMMER I had to add a bioop explicitly to allow the kernel flush-buffers-on-crash code to query whether it was actually ok to flush a dirty buffer or not. Until I did that DragonFly was flushing HAMMER buffers which on crash which it had absolutely no business flushing. * Implement active dependancy flushing in softupdates. Instead of having it just adjust the dependancies for later flushes softupdates needs to actively initiate I/O for the dependancies as they are resolved. To do this will require implementing a flush queue, you can't just recurse (you will blow out the kernel stack). If you dont do this then you have to sync about a dozen times, with short delays between each sync, to ensure that all the dependancies are flushed. The only time this is done automatically is during a nominal umount during shutdown. * Once the above two are fixed start testing within virtual environments by virtually pulling the plug, and virtually crashing the kernel. Then fscking to determine if an unexpected softupdates inconsistency occured. There are probably numerous cases that remain. Of course, what you guys decide to do with your background fsck is up to you, but it seems to be a thorn in the side of FreeBSD from the day it was introduced, along with snapshots. I very explicitly avoided porting both the background fsck and softupdates snapshot code to DFly due to their lack of stability. The simple fact of the matter is that UFS just does not recover well on a large disk. Anything over 30-40 million inodes and you risk not being able to fsck the drive at all, not even in 64-bit mode (you will run out of swap). You get one inconsistency and the filesystem is broken forever. Anything over 200GB and your background fsck can wind up taking hours, seriously degrading the performance of the system in the process. It can take 6 hours to fsck a full 1TB HD. It can take over a day to fsck larger setups. Putting in a few sleeps here and there just makes the run time even longer and perpetuates the pain. My recommendation? Default UFS back to a synchronous fsck and stop treating ZFS (your only real alternative) as being so ultra-alpha that it shouldn't be used. Start recommending it for any filesystem larger then 200GB. Clean up the various UI issues that can lead to self immolation and foot stomping. Fix the defaults so they don't blow out kernel malloc areas, etc etc. Fix whatever bugs pop up. UFS is already unsuitable for 'common' 1TB consumer drives even WITH the background fsck. ZFS is ALREADY far safer to use then UFS for large disks, given reasonable constraints on feature selection. -Matt From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 18:43:47 2008 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 737D21065699 for ; Mon, 29 Sep 2008 18:43:47 +0000 (UTC) (envelope-from henrik@50hz.ws) Received: from dsp.50hz.ws (50hz.ws [78.46.69.237]) by mx1.freebsd.org (Postfix) with ESMTP id 2D65B8FC1D for ; Mon, 29 Sep 2008 18:43:47 +0000 (UTC) (envelope-from henrik@50hz.ws) Received: by dsp (Postfix, from userid 1001) id 7BD399B4AA; Mon, 29 Sep 2008 20:13:39 +0200 (CEST) Date: Mon, 29 Sep 2008 20:13:39 +0200 From: Henrik Friedrichsen To: FreeBSD stable Message-ID: <20080929181339.GA12554@dsp.50hz.ws> Mail-Followup-To: FreeBSD stable References: <48E02557.2020303@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E02557.2020303@incunabulum.net> User-Agent: Mutt/1.4.2.3i Subject: Re: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE 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, 29 Sep 2008 18:43:47 -0000 On Mon, Sep 29, 2008 at 01:46:15AM +0100, Bruce M Simpson wrote: > Hi, > > I've noticed some general instability with plugging in or removing USB > devices with FreeBSD 7.x, even when the devices are not actively in use. > > I had this happen with umass and ucom devices 3 times today. The machine > hangs solid, there are no obvious signs of a panic or trap to DDB. I > can't provide backtraces unfortunately -- these hangs happen on both my > laptop and desktop, and I usually have X running -- if I had more > specific information, I'd open a PR. > > Again, there seems to be no reason why this should happen, the devices > are off-the-shelf consumer items known to work with existing drivers, > and have been repeatedly used in other OSes without these hangs > happening; consider this an "anecdotal report". > > [For some reason my IBM laptop will often not allow me to break into DDB > on a driver related panic, and will just immediately reboot -- I lack > free time to track down exactly why this could be. > My desktop has a USB keyboard and this appears not to be supported by > DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another > story.] > > thanks > BMS > _______________________________________________ > 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" Hey, I can confirm those problems, however I can't provide dumps either. I remember the kernel panicing with PAGE_FAULT errors though. Good to know, that I'm not the only one with those problems though. Henrik. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 20:05:20 2008 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 525911065688 for ; Mon, 29 Sep 2008 20:05:20 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3B98FC21 for ; Mon, 29 Sep 2008 20:05:19 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=guido.klop.ws) by smtp-out0.tiscali.nl with smtp id 1KkOze-0001GT-D7 for ; Mon, 29 Sep 2008 22:05:18 +0200 Received: (qmail 21861 invoked from network); 29 Sep 2008 20:05:03 -0000 Received: from localhost (HELO 82-170-177-25.ip.telfort.nl) (127.0.0.1) by localhost with SMTP; 29 Sep 2008 20:05:03 -0000 Date: Mon, 29 Sep 2008 22:05:02 +0200 To: "Bruce M Simpson" , "FreeBSD stable" From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <48E02557.2020303@incunabulum.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <48E02557.2020303@incunabulum.net> User-Agent: Opera Mail/9.52 (FreeBSD) Cc: Subject: Re: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE 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, 29 Sep 2008 20:05:20 -0000 On Mon, 29 Sep 2008 02:46:15 +0200, Bruce M Simpson wrote: > Hi, > > I've noticed some general instability with plugging in or removing USB > devices with FreeBSD 7.x, even when the devices are not actively in use. > > I had this happen with umass and ucom devices 3 times today. The machine > hangs solid, there are no obvious signs of a panic or trap to DDB. I > can't provide backtraces unfortunately -- these hangs happen on both my > laptop and desktop, and I usually have X running -- if I had more > specific information, I'd open a PR. > > Again, there seems to be no reason why this should happen, the devices > are off-the-shelf consumer items known to work with existing drivers, > and have been repeatedly used in other OSes without these hangs > happening; consider this an "anecdotal report". > > [For some reason my IBM laptop will often not allow me to break into DDB > on a driver related panic, and will just immediately reboot -- I lack > free time to track down exactly why this could be. > My desktop has a USB keyboard and this appears not to be supported by > DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another > story.] > > thanks > BMS On my computer I had to disable USB support in the BIOS because it 'conflicted' with USB support of FreeBSD. FreeBSD still detects USB and all connected devices. Maybe this helps on your computer also. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 20:07:53 2008 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 37BE9106568D for ; Mon, 29 Sep 2008 20:07:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1064D8FC25 for ; Mon, 29 Sep 2008 20:07:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id A0D4D46B53 for ; Mon, 29 Sep 2008 16:07:52 -0400 (EDT) Date: Mon, 29 Sep 2008 21:07:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: ipfw uid rules now believed fixed (was: Re: Warning: known instability using ipfw "uid" rules) 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, 29 Sep 2008 20:07:53 -0000 On Sat, 27 Sep 2008, Robert Watson wrote: > An FYI: In the past couple of days, presumably as testing of 7.x becomes > more widespread, I've seen several reports of instability resulting from > ipfw credential rules. For those unfamiliar with them, these allow the > matching of packets in ipfw rules based on the credentials of the socket > that generated them, or the credentials of the socket that likely will > receive them. > > These problems are a side effect of elimating support for lock recursion on > inpcbinfo locks as part of the UDP performance optimization work for 7.1. > There are two minor TCP fixes, and a more serious ipfw bug fix, in the queue > to be MFC'd in the next couple of days. Once they're fixed, please make > sure any further problems with deadlocks or panics involving ipfw rules are > brought to my attention. I've now MFC'd two fixes to TCP and one fix to IPFW that appear to have resolved known reports of panics or deadlocks with ipfw uid/gid/jail rules. If you are a user of uid/gid/jail rules and have been experiencing stability problems, please let me know if they persist (or if you want, let me know that they are resolved). If you're someone generally interested in testing out 7.1, more testing of this feature would, of course, be welcome. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 20:10:29 2008 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 AA2F7106568D; Mon, 29 Sep 2008 20:10:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 81E458FC15; Mon, 29 Sep 2008 20:10:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 1A60346B45; Mon, 29 Sep 2008 16:10:29 -0400 (EDT) Date: Mon, 29 Sep 2008 21:10:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Arno J. Klaassen" In-Reply-To: Message-ID: References: <20080929043134.GD54819@cdnetworks.co.kr> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 20:10:29 -0000 On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > However, the "request/respones" tests are awfull for my notebook (test > repeated on the notebook for the sake of conviction) : Is it possible to rerun these tests with a 7.0 kernel of the same general configuration? That would help us determine if it's a regression between 7.0 and 7.1, or perhaps a more general issue between 6.x and 7.x. I wouldn't reject a hardware, driver, or general stack issue at this point as things are still fairly unclear. If it's definitely between 7.0 and 7.1 that the problem arises, trying a series of kernels spaced at, say, one month intervals in that period would be quite helpful in narrowing down the source. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > TCP_RR > Trans. > Rate > per sec > > 6-stable-x86 9801.58 > 7-stable-x64 137.61 > 7-stable-x64 89.35 > 7-stable-x64 102.29 > > TCP_CRR > Trans. > Rate > per sec > > 6-stable-x86 4520.98 > 7-stable-x64 7.00 > 7-stable-x64 8.10 > 7-stable-x64 18.49 > > > UDP_RR > Trans. > Rate > per sec > > 6-stable-x86 9473.20 > 7-stable-x64 9.60 > 7-stable-x64 0.90 > 7-stable-x64 0.10 > > > I can send you complete results if wanted. > >> Other possible cause of issue could be link speed/duplex mismatch >> or excessive MAC control frames(e.g. pause frames). Does nfe(4) >> agree on resolved speed/duplex with link partner? > > > yes (1000baseTX ) > >> If they all agree on resolved speed/duplex, would you check number >> of pause frames sent/received from link partner? Even though MCP65 >> supports hardware MAC statistics for pause frames nfe(4) has no >> support code yet so you may have to resort to managed switch that >> can show Tx/Rx statistics of each port. > > aargh; I do have a Netgear GS724TS around where I can connect it to. > This thing should be manageable, but give me some time to > find out how .... > > Thanx, Arno > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 20:40:52 2008 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 BF27210656A3 for ; Mon, 29 Sep 2008 20:40:52 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 357638FC15 for ; Mon, 29 Sep 2008 20:40:51 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 27759 invoked by uid 89); 29 Sep 2008 20:14:08 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 29 Sep 2008 20:14:08 -0000 Date: Mon, 29 Sep 2008 22:14:08 +0200 From: Oliver Lehmann To: freebsd-stable@FreeBSD.org Message-Id: <20080929221408.54e6a03a.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: system hangup - I'm lost 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, 29 Sep 2008 20:40:52 -0000 Hi, My fileserver has sporadical hangups running 6.3: FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 olivleh1@nudel.salatschuessel.net:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL The exact release doesn't matter since it happened before. It always happens afer some time of having some load on the system (I'm building ports with tinderbox and during the build process it just hangs up). The system does nothing write out on the console, neither the CRT, nor the serial console. The system itself is: CPU: Intel Pentium III (845.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff real memory = 805240832 (767 MB) avail memory = 778481664 (742 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard while the diskspace is provided by an 3ware RAID: twa0: <3ware 9000 series Storage Controller> port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf4800000-0xf4ffffff irq 18 at device 11.0 on pci0 twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) I had - in the past - sometimes messages left which where indicating, that the system was not able to allocate swap space fast enough if I recall it correctly (_not_ out of swap space!) but the RAID is kinda fast imho. Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) Greetings, Oliver -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 21:24:27 2008 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 07989106568C for ; Mon, 29 Sep 2008 21:24:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id B88F88FC15 for ; Mon, 29 Sep 2008 21:24:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F2476730A8; Mon, 29 Sep 2008 23:12:18 +0200 (CEST) Date: Mon, 29 Sep 2008 23:12:18 +0200 From: Luigi Rizzo To: Robert Watson Message-ID: <20080929211218.GC69054@onelab2.iet.unipi.it> References: <20080929043134.GD54819@cdnetworks.co.kr> 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: pyunyh@gmail.com, stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 21:24:27 -0000 On Mon, Sep 29, 2008 at 09:10:29PM +0100, Robert Watson wrote: > > On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > > >However, the "request/respones" tests are awfull for my notebook (test > >repeated on the notebook for the sake of conviction) : > > Is it possible to rerun these tests with a 7.0 kernel of the same general > configuration? That would help us determine if it's a regression between > 7.0 and 7.1, or perhaps a more general issue between 6.x and 7.x. I > wouldn't reject a hardware, driver, or general stack issue at this point as > things are still fairly unclear. If it's definitely between 7.0 and 7.1 > that the problem arises, trying a series of kernels spaced at, say, one > month intervals in that period would be quite helpful in narrowing down the > source. two things: + the 'nfe' driver is not in 6.x so i wonder how these numbers were derived in 6.x -- perhaps using a backport, or using the nve driver instead ? In any case we cannot easily compare 6.x and 7.x behaviour with nfe. + with the nfe driver and the MCP67 chipset i have found a tendency of the card to stall at high data rates and with some system load (e.g. massive scp while some X applications is spinning). This was completely repeatable and caused the network card to become deaf (it could transmit though) and it required an ifconfig down/up to come back to life, watchdogs and timeouts did not fix it. Additionally i have found some bug in the polling implementation which may or may not relate to more generic interrupt handling. This was described in a thread in april. A patch to address the stalls is at http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080426.1044.diff (i have been running this on my home pc since late april) A related patch changes slightly the implementation of polling: http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080427.diff At the time when i raised the problem on the mailing list apparently others were not seeing the problem so i did not pursue the integration in the system - but if this is a significant problem in 7.1R then it is worth a try. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 21:41:47 2008 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 24B90106569F; Mon, 29 Sep 2008 21:41:47 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal2.es.net [198.128.3.206]) by mx1.freebsd.org (Postfix) with ESMTP id F2FA28FC16; Mon, 29 Sep 2008 21:41:46 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id JEI41122; Mon, 29 Sep 2008 14:31:22 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 204444500F; Mon, 29 Sep 2008 14:31:22 -0700 (PDT) To: Holger Kipp In-Reply-To: Your message of "Mon, 29 Sep 2008 11:03:10 +0200." <20080929090310.GA70418@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1222723882_61810P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 29 Sep 2008 14:31:22 -0700 From: "Kevin Oberman" Message-Id: <20080929213122.204444500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: Holger Kipp X-To_Domain: alogis.com X-To: Holger Kipp X-To_Email: hk@alogis.com X-To_Alias: hk Cc: "firmdog@gmail.com" , Jeremy Chadwick , stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 21:41:47 -0000 --==_Exmh_1222723882_61810P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 29 Sep 2008 11:03:10 +0200 > From: Holger Kipp > Sender: owner-freebsd-stable@freebsd.org > > On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > > No....you misunderstood. The 7.1 box was connected to a 5.4 box > doing a 50GB > data transfer over rsync. Both nics were 1000 full > duplex with a crossover cable. > The speed performance was terrible > and I could only get up to 10 Mb/s and there > was NO switch involved. > I believe there is a problem or bug involved with the > driver. Have > the drivers or stack been updated in 7.1? What else can I provide? > > Hi, I only flipped through the messages in this thread, faintly > remembering someone writing something about ssh. Anyway, if you're > copying using ssh (scp, sftp), then the transfer rate is much less > than what you'd expect - due to the encryption/decryption overhead > (unless you have hardware acceleration on both sideds). > > Just my two cents (Euro) on general reasons for slow data transfers. ssh(1) and it's kin, scp(1) and sftp(1), are not at all well designed for performance. There are several issues and if you want details, read . If you want to use ssh(1) for high-bandwidth TCP streams, especially scp/sftp, install openssh-portable from ports after selecting the "enable HPN-SSH patch" option. You may want to over-write the base install, but be sure to edit make.conf/src.conf so that a system upgrade won't re-overwrite it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1222723882_61810P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFI4Ukqkn3rs5h7N1ERAqIDAJwN37DIc7u0lsWCoPPEJtfHKZTVfQCggPCX yKD7F0uqvYJ+/QvbtgC1U/E= =wVqR -----END PGP SIGNATURE----- --==_Exmh_1222723882_61810P-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 22:00:54 2008 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 1322110656A0 for ; Mon, 29 Sep 2008 22:00:54 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id D44778FC14 for ; Mon, 29 Sep 2008 22:00:53 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2127557rvf.43 for ; Mon, 29 Sep 2008 15:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=q8B+i/Lwed+OhmhaToESOhtxSpLQoSc7MKN/qi1NLaA=; b=hCuTqByrJGT5ZJ8CQSpIBmdOcJfQU8UXBYlYfuFlrNyCY8rR9xCMQESRwE9vsv9dOy fzCEpSR59zuXeA5SSHEHZKe9u+nYyJumo6EnxZxUuxOxA3NbgZJhpUR2M/uZ4i4p1Axp Lg9inRx1hP6O8q/I9Z357vNhbXvpGHgPz8oSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Qc+Ew0dDcSgqMZ8/f4bIcKHl64xvZTw7X5nELX/9JYOJIPcgrlN06ERvHkXmP3CqpC GRy+2cYrrnmKk6EdvH09OzL/SpAo5YhdIk3U9A6jbx/F87sxSSQ38qaHYRNsz4+rZCde sHEXCvn3nywhKaEHwbY2gTITnEFqijP34FquI= Received: by 10.114.37.1 with SMTP id k1mr6583676wak.44.1222724029498; Mon, 29 Sep 2008 14:33:49 -0700 (PDT) Received: by 10.115.95.2 with HTTP; Mon, 29 Sep 2008 14:33:49 -0700 (PDT) Message-ID: <57d710000809291433n2d8f48ebv9e54f868a7422654@mail.gmail.com> Date: Mon, 29 Sep 2008 14:33:49 -0700 From: "pete wright" To: "Holger Kipp" In-Reply-To: <20080929090310.GA70418@intserv.int1.b.intern> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> <20080929090310.GA70418@intserv.int1.b.intern> Cc: "firmdog@gmail.com" , Jeremy Chadwick , stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 29 Sep 2008 22:00:54 -0000 On Mon, Sep 29, 2008 at 2:03 AM, Holger Kipp wrote: > On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: >> No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB >> data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. >> The speed performance was terrible and I could only get up to 10 Mb/s and there >> was NO switch involved. I believe there is a problem or bug involved with the >> driver. Have the drivers or stack been updated in 7.1? What else can I provide? > > Hi, I only flipped through the messages in this thread, faintly remembering someone > writing something about ssh. Anyway, if you're copying using ssh (scp, sftp), then > the transfer rate is much less than what you'd expect - due to the encryption/decryption > overhead (unless you have hardware acceleration on both sideds). > FWIW I think the general issue for the ssh suite of tools is the compiled in window size is not tuned for large transfers like this: http://www.psc.edu/networking/projects/hpn-ssh/theory.php we use a propritary tool called aspera to overcome these issues when moving large amounts of data b/w remote sites on our WAN: http://www.asperasoft.com/products/scp/index.html the encrytp/decrypt overhead should be pretty minimal on modern hardware, so i would not expect that to be the first bottle neck you run into. -pete -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 01:41:47 2008 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 0D3C71065689 for ; Tue, 30 Sep 2008 01:41:47 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id BB7298FC13 for ; Tue, 30 Sep 2008 01:41:46 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 2BF0017DA2; Tue, 30 Sep 2008 11:41:42 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (142.19.96.58.exetel.com.au [58.96.19.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 402E9171C8 for ; Tue, 30 Sep 2008 11:41:36 +1000 (EST) Message-ID: <48E1839E.3060006@modulus.org> Date: Tue, 30 Sep 2008 11:40:46 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080921213426.GA13923@0lsen.net> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> In-Reply-To: <200809291744.m8THiBlR034739@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 01:41:47 -0000 Matthew Dillon wrote: > It can take 6 hours to fsck a full 1TB HD. It can > take over a day to fsck larger setups. Putting in a few sleeps here > and there just makes the run time even longer and perpetuates the pain. We have a box with millions of files spread over 2TB, on a 16 disk RAID. Foreground fsck takes almost 8 hours, so background fsck, which takes almost 24 hours or more, is my only option when I want to bring the box back online quickly. And UFS Snapshots are so slow as to be completely useless. I've now converted the volume to ZFS, and am now enjoying instant boot time and higher speed I/O under heavy load, at the expense of memory consumption. > My recommendation? Default UFS back to a synchronous fsck and stop > treating ZFS (your only real alternative) as being so ultra-alpha that > it shouldn't be used. Completely agree. ZFS is the way of the future for FreeBSD. In my latest testing, the memory problems are now under control, there is just stability problems with random lockups after days of heavy load unless I turn off ZIL. So its nearly there. If only ZFS also supported a network distributed mode. Or can we convince you to port Hammer to FreeBSD? :-) - Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 01:41:47 2008 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 12875106568B for ; Tue, 30 Sep 2008 01:41:47 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id C1D908FC15 for ; Tue, 30 Sep 2008 01:41:46 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 3326A17DA3; Tue, 30 Sep 2008 11:41:44 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (142.19.96.58.exetel.com.au [58.96.19.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 02ECE1775E for ; Tue, 30 Sep 2008 11:41:39 +1000 (EST) Message-ID: <48E183A2.8000209@modulus.org> Date: Tue, 30 Sep 2008 11:40:50 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080921213426.GA13923@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> In-Reply-To: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 01:41:47 -0000 Zaphod Beeblebrox wrote: > Also, there > exists data within the ARC (I'm always tempted to say the ARC Cache, but > that is redundant) that is also then in paging memory. OK, but one advantage of ZFS memory consumption is under heavy write loads, where much of the memory is used to store and reorder writes. The heavy memory consumption under reading is a shame, but ZFS has to cache and use more metadata than UFS, so its a price you pay for the extra features and benefits. What I think we need is a way to turn off read-caching except for metadata. This allows ARC to only be used more efficiently. Currently you can turn all read-ahead on or off, with the provided sysctl tunables, but would be easy to implement a metadata-only option. I found that access speed suffers when metadata is not prefetched. If you are running an X workstation with 2GB or less memory, then I agree ZFS is a bad default choice. For my workstation I would still use ZFS, I would: * turn down ARC size, * turn off read-ahead except for metadata, * and even turn off ZIL and write cache flushing, which solves the annoyance of unpredictable delays when flushing buffers. Not a good choice for a server but perfect for a workstation. - Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 03:00:42 2008 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 075A81065696 for ; Tue, 30 Sep 2008 03:00:42 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id C38F18FC25 for ; Tue, 30 Sep 2008 03:00:41 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m8U30fsT040400; Mon, 29 Sep 2008 20:00:41 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m8U30eaF040399; Mon, 29 Sep 2008 20:00:40 -0700 (PDT) Date: Mon, 29 Sep 2008 20:00:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200809300300.m8U30eaF040399@apollo.backplane.com> To: Andrew Snow References: <20080921213426.GA13923@0lsen.net> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> <48E1839E.3060006@modulus.org> Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 03:00:42 -0000 :Completely agree. ZFS is the way of the future for FreeBSD. In my :latest testing, the memory problems are now under control, there is just :stability problems with random lockups after days of heavy load unless I :turn off ZIL. So its nearly there. : :If only ZFS also supported a network distributed mode. Or can we :convince you to port Hammer to FreeBSD? :-) : :- Andrew Heh. No, you guys would have to port it if you want it, though I would be happy to support it once ported. Issues are between minor and moderate but would still require a knowledgeable filesystem person to do. Biggest issues will be buffer cache and bioops differences, and differences in the namespace VOPs. -- But, IMHO, you guys should focus on ZFS since clearly a lot of work has gone into its port, it works now in FBSD, and it just needs to be made production-ready and a little more programming support from the community. It also has a different feature set then HAMMER. P.S. FreeBSD should issue a $$ grant or stipend to Pawel for that work, he's really saving your asses. UFS has clearly reached its end-of-life. Speaking of ZFS, you guys probably went through the same boot issues that we are going through with HAMMER. I came up with a solution which turned out to be quite non-invasive and very easy to implement. * Make a small /boot UFS partition. e.g. 256M ad0s1a. * Put HAMMER (or ZFS in your case) on the rest of the disk (ad0s1d). * Adjust the loader to search both / and /boot, so /boot can be its own partition or a sub-directory on root. * Add a simple line to /boot/loader.conf to direct the kernel to the proper root, e.g. vfs.root.mountfrom="hammer:ad0s1d" And poof, you're done. Then when the system boots it boots into a HAMMER (ZFS) root, and /boot is mounted as small UFS filesystem under it. Miscellanious other partitions would then be pseudo-fs's under the single HAMMER (or ZFS) root, removing the need to worry about reserving particular amounts of space, and providing the needed backup and snapshot separation domains. Well, you guys might have already solved it. There isn't much to it. I recall there was quite a discussion on trying to create redundant boot setup on FreeBSD, such as boot-to-RAID setups, and having trouble getting the BIOS to recognize it. There's an alternative solution... having a separate, small /boot means you can boot from a small solid state storage device whos MTBF is going to be the same as the PC hardware itself. No real storage redundancy is needed and if your root is somewhere else that gives you the option of putting more sophisticated code in /boot (it being the full kernel) to properly mount the root. I have 0 (ZERO) trust in BIOS-RAID or card-supported RAID-enabled (such as with 3Ware) boot support. ZERO. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:12:20 2008 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 C46BF106569D for ; Tue, 30 Sep 2008 04:12:20 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 80C5B8FC1E for ; Tue, 30 Sep 2008 04:12:20 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id m8U4CIEP083428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Sep 2008 23:12:18 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id m8U4CGHq083166; Mon, 29 Sep 2008 23:12:16 -0500 (CDT) (envelope-from dan) Date: Mon, 29 Sep 2008 23:12:16 -0500 From: Dan Nelson To: Andrew Snow Message-ID: <20080930041215.GH86326@dan.emsphone.com> References: <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <48E183A2.8000209@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E183A2.8000209@modulus.org> X-OS: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 04:12:20 -0000 In the last episode (Sep 30), Andrew Snow said: > Zaphod Beeblebrox wrote: > > Also, there exists data within the ARC (I'm always tempted to say > > the ARC Cache, but that is redundant) that is also then in paging > > memory. > > OK, but one advantage of ZFS memory consumption is under heavy write > loads, where much of the memory is used to store and reorder writes. > The heavy memory consumption under reading is a shame, but ZFS has to > cache and use more metadata than UFS, so its a price you pay for the > extra features and benefits. > > What I think we need is a way to turn off read-caching except for > metadata. This allows ARC to only be used more efficiently. > Currently you can turn all read-ahead on or off, with the provided > sysctl tunables, but would be easy to implement a metadata-only > option. I found that access speed suffers when metadata is not > prefetched. That'd be handy, but at least on my system the data prefetcher isn't really called often enough to make a difference either way (assuming the counts are accurate). Metadata prefetch is a big win, however. (dan@dan.15) /home/dan> uptime 11:00PM up 5 days, 13:47, 21 users, load averages: 1.52, 1.68, 1.69 (dan@dan.15) /home/dan> sysctl kstat [..] kstat.zfs.misc.arcstats.hits: 211130907 (95%) kstat.zfs.misc.arcstats.misses: 9808431 kstat.zfs.misc.arcstats.demand_data_hits: 116614377 (98%) kstat.zfs.misc.arcstats.demand_data_misses: 2477943 kstat.zfs.misc.arcstats.demand_metadata_hits: 55805261 (96%) kstat.zfs.misc.arcstats.demand_metadata_misses: 2310006 kstat.zfs.misc.arcstats.prefetch_data_hits: 79878 (53%) kstat.zfs.misc.arcstats.prefetch_data_misses: 71741 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 38556033 (88%) kstat.zfs.misc.arcstats.prefetch_metadata_misses: 4947270 kstat.zfs.misc.arcstats.mru_hits: 23702582 (95%) kstat.zfs.misc.arcstats.mru_ghost_hits: 1274189 kstat.zfs.misc.arcstats.mfu_hits: 149722171 (98%) kstat.zfs.misc.arcstats.mfu_ghost_hits: 2944572 [..] kstat.zfs.misc.arcstats.p: 235221504 kstat.zfs.misc.arcstats.c: 268435456 kstat.zfs.misc.arcstats.c_min: 67108864 kstat.zfs.misc.arcstats.c_max: 268435456 kstat.zfs.misc.arcstats.size: 263926784 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:20:12 2008 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 EE1E8106568C for ; Tue, 30 Sep 2008 04:20:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id 140418FC25 for ; Tue, 30 Sep 2008 04:20:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1458185tid.3 for ; Mon, 29 Sep 2008 21:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=s0ybi3lrq9FfpzKNuzOmGMgOCHTcZQVi1V/hYyHAubU=; b=oO565ce+0lH/dN0J3XYrTBkhzDVcz+Wt4D/kZPOyyWCo+gh+g/w3NNYb/CAfhizQov BWIHYU709PCG0JHsAsWKPYsb0d8WVu/96vPmXkf3aKwt9Rod4XzTe47jzfe8I8lO7ZRe 5XhAkMbydT86f2RHoBtlegYwVCuQAZalr0sJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=mM8kYZwb0fceP+7NJnN5lJgF1RTYinknTk8hI1emQkqr1U8w5X1Vjpo4rDe3f2Ad4C 4/TXVWWTtA4weYDvKe7whAIp81qW+TYeaCMlBZ4mb97tg3Sdq5HZUVKtQqg7tls2hFwJ D8Q2XwwKG+zVvNeL0Oes+Kdoq6EBf07UI52wk= Received: by 10.110.93.12 with SMTP id q12mr8825841tib.16.1222748410361; Mon, 29 Sep 2008 21:20:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id u8sm3484659tia.8.2008.09.29.21.20.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Sep 2008 21:20:07 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8U4I8hb059934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 13:18:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8U4I7SR059933; Tue, 30 Sep 2008 13:18:07 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 30 Sep 2008 13:18:07 +0900 From: Pyun YongHyeon To: "Arno J. Klaassen" Message-ID: <20080930041807.GC59136@cdnetworks.co.kr> References: <20080929043134.GD54819@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jho1yZJdad60DJr+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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: Tue, 30 Sep 2008 04:20:13 -0000 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 29, 2008 at 04:12:56PM +0200, Arno J. Klaassen wrote: [...] > > > > AFAIK it seems that you're the first one that reports poor > > performance issue of MCP65. > > > someone must be ;) no kiddin, I am not convinced this is (only) > a driver issue (cf. "bad NFS/UDP performance" thread on -hackers). > > I just have no experience on this notebook, so I can't say " it worked > great before" and my only other 7-stable-amd64 I have does not > show the probs, having a cheap re0 *and* being UP. > > > > MCP65 has no checksum offload/TSO > > capability so nfe(4) never try to take advantage of the hardware > > capability. So you should have no checksum offload/TSO related > > issue here. > > Also note, checking network performance with scp(1) wouldn't > > show real numbers as scp(1) may involve other system activities. > > Use one of network benchmark programs in ports(e.g. > > benchmarks/netperf) to measure network performance. > > quite funny (even taken with lots of salt since the LAN is used > for "normal work" as well in parallel, but differences are > rather significant) : > > I test to same server (7-stable-amd64 from Jun 7 (using > nfe0 as well btw, but another chip), either from a > 6-stable-x86 (Jul 14, sk0) or the notebook (7-stable-x64 below), using > > for i in ; do > echo $i; /usr/local/bin/netperf -H push -i 4,2 -I 95,10 -t $i; echo; > done > > streaming results are OK for both : > > TCP_STREAM > Throughput > 10^6bits/sec > > 6-stable-x86 349.57 > 7-stable-x64 939.47 > > UDP_STREAM > Throughput > 10^6bits/sec > > 6-stable-x86 388.45 > 7-stable-x64 947.89 > > > However, the "request/respones" tests are awfull for my notebook > (test repeated on the notebook for the sake of conviction) : > > TCP_RR > Trans. > Rate > per sec > > 6-stable-x86 9801.58 > 7-stable-x64 137.61 > 7-stable-x64 89.35 > 7-stable-x64 102.29 > > TCP_CRR > Trans. > Rate > per sec > > 6-stable-x86 4520.98 > 7-stable-x64 7.00 > 7-stable-x64 8.10 > 7-stable-x64 18.49 > > > UDP_RR > Trans. > Rate > per sec > > 6-stable-x86 9473.20 > 7-stable-x64 9.60 > 7-stable-x64 0.90 > 7-stable-x64 0.10 > > > I can send you complete results if wanted. > Based on poor TCP_RR numbers I wonder how you can get such a high TCP_STREAM numbers. > > Other possible cause of issue could be link speed/duplex mismatch > > or excessive MAC control frames(e.g. pause frames). Does nfe(4) > > agree on resolved speed/duplex with link partner? > > > yes (1000baseTX ) > > > If they all agree on resolved speed/duplex, would you check number > > of pause frames sent/received from link partner? Even though MCP65 > > supports hardware MAC statistics for pause frames nfe(4) has no > > support code yet so you may have to resort to managed switch that > > can show Tx/Rx statistics of each port. > > aargh; I do have a Netgear GS724TS around where I can connect it to. > This thing should be manageable, but give me some time to > find out how .... > Or try attached patch. Use "sysctl dev.nfe.0.stats" to get statistics. -- Regards, Pyun YongHyeon --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.mib.patch" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 183480) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -122,6 +122,9 @@ static int sysctl_int_range(SYSCTL_HANDLER_ARGS, int, int); static int sysctl_hw_nfe_proc_limit(SYSCTL_HANDLER_ARGS); +static void nfe_sysctl_node(struct nfe_softc *); +static void nfe_stats_clear(struct nfe_softc *); +static void nfe_stats_update(struct nfe_softc *); #ifdef NFE_DEBUG static int nfedebug = 0; @@ -245,6 +248,22 @@ "NVIDIA nForce MCP73 Networking Adapter"}, {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP73_LAN4, "NVIDIA nForce MCP73 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN1, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN2, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN3, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN4, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN1, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN2, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN3, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN4, + "NVIDIA nForce MCP79 Networking Adapter"}, {0, 0, NULL} }; @@ -438,18 +457,19 @@ break; case PCI_PRODUCT_NVIDIA_MCP51_LAN1: case PCI_PRODUCT_NVIDIA_MCP51_LAN2: - sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT; + sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | NFE_MIB_V1; break; case PCI_PRODUCT_NVIDIA_CK804_LAN1: case PCI_PRODUCT_NVIDIA_CK804_LAN2: case PCI_PRODUCT_NVIDIA_MCP04_LAN1: case PCI_PRODUCT_NVIDIA_MCP04_LAN2: - sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM; + sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM | + NFE_MIB_V1; break; case PCI_PRODUCT_NVIDIA_MCP55_LAN1: case PCI_PRODUCT_NVIDIA_MCP55_LAN2: sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM | - NFE_HW_VLAN | NFE_PWR_MGMT | NFE_TX_FLOW_CTRL; + NFE_HW_VLAN | NFE_PWR_MGMT | NFE_TX_FLOW_CTRL | NFE_MIB_V2; break; case PCI_PRODUCT_NVIDIA_MCP61_LAN1: @@ -465,14 +485,26 @@ case PCI_PRODUCT_NVIDIA_MCP73_LAN3: case PCI_PRODUCT_NVIDIA_MCP73_LAN4: sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | - NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL; + NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | NFE_MIB_V2; break; + case PCI_PRODUCT_NVIDIA_MCP77_LAN1: + case PCI_PRODUCT_NVIDIA_MCP77_LAN2: + case PCI_PRODUCT_NVIDIA_MCP77_LAN3: + case PCI_PRODUCT_NVIDIA_MCP77_LAN4: + case PCI_PRODUCT_NVIDIA_MCP79_LAN1: + case PCI_PRODUCT_NVIDIA_MCP79_LAN2: + case PCI_PRODUCT_NVIDIA_MCP79_LAN3: + case PCI_PRODUCT_NVIDIA_MCP79_LAN4: + sc->nfe_flags |= NFE_40BIT_ADDR | NFE_HW_CSUM | NFE_PWR_MGMT | + NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | NFE_MIB_V3; + break; case PCI_PRODUCT_NVIDIA_MCP65_LAN1: case PCI_PRODUCT_NVIDIA_MCP65_LAN2: case PCI_PRODUCT_NVIDIA_MCP65_LAN3: case PCI_PRODUCT_NVIDIA_MCP65_LAN4: sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | - NFE_PWR_MGMT | NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL; + NFE_PWR_MGMT | NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | + NFE_MIB_V2; break; } @@ -519,25 +551,9 @@ goto fail; nfe_alloc_jrx_ring(sc, &sc->jrxq); + /* Create sysctl node. */ + nfe_sysctl_node(sc); - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), - OID_AUTO, "process_limit", CTLTYPE_INT | CTLFLAG_RW, - &sc->nfe_process_limit, 0, sysctl_hw_nfe_proc_limit, "I", - "max number of Rx events to process"); - - sc->nfe_process_limit = NFE_PROC_DEFAULT; - error = resource_int_value(device_get_name(dev), device_get_unit(dev), - "process_limit", &sc->nfe_process_limit); - if (error == 0) { - if (sc->nfe_process_limit < NFE_PROC_MIN || - sc->nfe_process_limit > NFE_PROC_MAX) { - device_printf(dev, "process_limit value out of range; " - "using default: %d\n", NFE_PROC_DEFAULT); - sc->nfe_process_limit = NFE_PROC_DEFAULT; - } - } - ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); ifp->if_mtu = ETHERMTU; @@ -902,6 +918,8 @@ if (sc->nfe_link != 0 && (ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { txctl |= NFE_TX_START; rxctl |= NFE_RX_START; + /* Got a link, clear hardware stats. */ + nfe_stats_clear(sc); } else { txctl &= ~NFE_TX_START; rxctl &= ~NFE_RX_START; @@ -2823,6 +2841,8 @@ tdata->m = NULL; } } + /* Update hardware stats. */ + nfe_stats_update(sc); } @@ -2874,6 +2894,7 @@ mii = device_get_softc(sc->nfe_miibus); mii_tick(mii); + nfe_stats_update(sc); nfe_watchdog(ifp); callout_reset(&sc->nfe_stat_ch, hz, nfe_tick, sc); } @@ -2981,3 +3002,199 @@ return (sysctl_int_range(oidp, arg1, arg2, req, NFE_PROC_MIN, NFE_PROC_MAX)); } + + +#define NFE_SYSCTL_STAT_ADD32(c, h, n, p, d) \ + SYSCTL_ADD_UINT(c, h, OID_AUTO, n, CTLFLAG_RD, p, 0, d) +#define NFE_SYSCTL_STAT_ADD64(c, h, n, p, d) \ + SYSCTL_ADD_QUAD(c, h, OID_AUTO, n, CTLFLAG_RD, p, d) + +static void +nfe_sysctl_node(struct nfe_softc *sc) +{ + struct sysctl_ctx_list *ctx; + struct sysctl_oid_list *child, *parent; + struct sysctl_oid *tree; + struct nfe_hw_stats *stats; + int error; + + stats = &sc->nfe_stats; + ctx = device_get_sysctl_ctx(sc->nfe_dev); + child = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->nfe_dev)); + SYSCTL_ADD_PROC(ctx, child, + OID_AUTO, "process_limit", CTLTYPE_INT | CTLFLAG_RW, + &sc->nfe_process_limit, 0, sysctl_hw_nfe_proc_limit, "I", + "max number of Rx events to process"); + + sc->nfe_process_limit = NFE_PROC_DEFAULT; + error = resource_int_value(device_get_name(sc->nfe_dev), + device_get_unit(sc->nfe_dev), "process_limit", + &sc->nfe_process_limit); + if (error == 0) { + if (sc->nfe_process_limit < NFE_PROC_MIN || + sc->nfe_process_limit > NFE_PROC_MAX) { + device_printf(sc->nfe_dev, + "process_limit value out of range; " + "using default: %d\n", NFE_PROC_DEFAULT); + sc->nfe_process_limit = NFE_PROC_DEFAULT; + } + } + + if ((sc->nfe_flags & (NFE_MIB_V1 | NFE_MIB_V2 | NFE_MIB_V3)) == 0) + return; + + tree = SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "stats", CTLFLAG_RD, + NULL, "NFE statistics"); + parent = SYSCTL_CHILDREN(tree); + + /* Rx statistics. */ + tree = SYSCTL_ADD_NODE(ctx, parent, OID_AUTO, "tx", CTLFLAG_RD, + NULL, "Tx MAC statistics"); + child = SYSCTL_CHILDREN(tree); + NFE_SYSCTL_STAT_ADD64(ctx, child, "octets", + &stats->tx_octets, "Octets"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "zero_rexmits", + &stats->tx_zero_rexmits, "Zero Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "one_rexmits", + &stats->tx_one_rexmits, "One Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multi_rexmits", + &stats->tx_multi_rexmits, "Multiple Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "late_cols", + &stats->tx_late_cols, "Late Collisions"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fifo_underuns", + &stats->tx_fifo_underuns, "FIFO Underruns"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "carrier_losts", + &stats->tx_carrier_losts, "Carrier Losts"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "excess_deferrals", + &stats->tx_excess_deferals, "Excess Deferrals"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "retry_errors", + &stats->tx_retry_errors, "Retry Errors"); + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + NFE_SYSCTL_STAT_ADD32(ctx, child, "deferrals", + &stats->tx_deferals, "Deferrals"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "frames", + &stats->tx_frames, "Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "pause", + &stats->tx_pause, "Pause Frames"); + } + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + NFE_SYSCTL_STAT_ADD32(ctx, child, "unicast", + &stats->tx_deferals, "Unicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multicast", + &stats->tx_frames, "Multicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "broadcast", + &stats->tx_pause, "Broadcast Frames"); + } + + /* Rx statistics. */ + tree = SYSCTL_ADD_NODE(ctx, parent, OID_AUTO, "rx", CTLFLAG_RD, + NULL, "Rx MAC statistics"); + child = SYSCTL_CHILDREN(tree); + + NFE_SYSCTL_STAT_ADD32(ctx, child, "frame_errors", + &stats->rx_frame_errors, "Framing Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "extra_bytes", + &stats->rx_extra_bytes, "Extra Bytes"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "late_cols", + &stats->rx_late_cols, "Late Collisions"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "runts", + &stats->rx_runts, "Runts"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "jumbos", + &stats->rx_jumbos, "Jumbos"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fifo_overuns", + &stats->rx_fifo_overuns, "FIFO Overruns"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "crc_errors", + &stats->rx_crc_errors, "CRC Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fae", + &stats->rx_fae, "Frame Alignment Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "len_errors", + &stats->rx_len_errors, "Length Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "unicast", + &stats->rx_unicast, "Unicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multicast", + &stats->rx_multicast, "Multicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "brocadcast", + &stats->rx_broadcast, "Broadcast Frames"); + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + NFE_SYSCTL_STAT_ADD64(ctx, child, "octets", + &stats->rx_octets, "Octets"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "pause", + &stats->rx_pause, "Pause frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "drops", + &stats->rx_drops, "Drop frames"); + } +} + +#undef NFE_SYSCTL_STAT_ADD32 +#undef NFE_SYSCTL_STAT_ADD64 + +static void +nfe_stats_clear(struct nfe_softc *sc) +{ + int i, mib_cnt; + + if ((sc->nfe_flags & NFE_MIB_V1) != 0) + mib_cnt = NFE_NUM_MIB_STATV1; + else if ((sc->nfe_flags & (NFE_MIB_V2 | NFE_MIB_V3)) != 0) + mib_cnt = NFE_NUM_MIB_STATV2; + else + return; + + for (i = 0; i < mib_cnt; i += sizeof(uint32_t)) + NFE_READ(sc, NFE_TX_OCTET + i); + + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + NFE_READ(sc, NFE_TX_UNICAST); + NFE_READ(sc, NFE_TX_MULTICAST); + NFE_READ(sc, NFE_TX_BROADCAST); + } +} + +static void +nfe_stats_update(struct nfe_softc *sc) +{ + struct nfe_hw_stats *stats; + + NFE_LOCK_ASSERT(sc); + + if ((sc->nfe_flags & (NFE_MIB_V1 | NFE_MIB_V2 | NFE_MIB_V3)) == 0) + return; + + stats = &sc->nfe_stats; + stats->tx_octets += NFE_READ(sc, NFE_TX_OCTET); + stats->tx_zero_rexmits += NFE_READ(sc, NFE_TX_ZERO_REXMIT); + stats->tx_one_rexmits += NFE_READ(sc, NFE_TX_ONE_REXMIT); + stats->tx_multi_rexmits += NFE_READ(sc, NFE_TX_MULTI_REXMIT); + stats->tx_late_cols += NFE_READ(sc, NFE_TX_LATE_COL); + stats->tx_fifo_underuns += NFE_READ(sc, NFE_TX_FIFO_UNDERUN); + stats->tx_carrier_losts += NFE_READ(sc, NFE_TX_CARRIER_LOST); + stats->tx_excess_deferals += NFE_READ(sc, NFE_TX_EXCESS_DEFERRAL); + stats->tx_retry_errors += NFE_READ(sc, NFE_TX_RETRY_ERROR); + stats->rx_frame_errors += NFE_READ(sc, NFE_RX_FRAME_ERROR); + stats->rx_extra_bytes += NFE_READ(sc, NFE_RX_EXTRA_BYTES); + stats->rx_late_cols += NFE_READ(sc, NFE_RX_LATE_COL); + stats->rx_runts += NFE_READ(sc, NFE_RX_RUNT); + stats->rx_jumbos += NFE_READ(sc, NFE_RX_JUMBO); + stats->rx_fifo_overuns += NFE_READ(sc, NFE_RX_FIFO_OVERUN); + stats->rx_crc_errors += NFE_READ(sc, NFE_RX_CRC_ERROR); + stats->rx_fae += NFE_READ(sc, NFE_RX_FAE); + stats->rx_len_errors += NFE_READ(sc, NFE_RX_LEN_ERROR); + stats->rx_unicast += NFE_READ(sc, NFE_RX_UNICAST); + stats->rx_multicast += NFE_READ(sc, NFE_RX_MULTICAST); + stats->rx_broadcast += NFE_READ(sc, NFE_RX_BROADCAST); + + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + stats->tx_deferals += NFE_READ(sc, NFE_TX_DEFERAL); + stats->tx_frames += NFE_READ(sc, NFE_TX_FRAME); + stats->rx_octets += NFE_READ(sc, NFE_RX_OCTET); + stats->tx_pause += NFE_READ(sc, NFE_TX_PAUSE); + stats->rx_pause += NFE_READ(sc, NFE_RX_PAUSE); + stats->rx_drops += NFE_READ(sc, NFE_RX_DROP); + } + + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + stats->tx_unicast += NFE_READ(sc, NFE_TX_UNICAST); + stats->tx_multicast += NFE_READ(sc, NFE_TX_MULTICAST); + stats->rx_broadcast += NFE_READ(sc, NFE_TX_BROADCAST); + } +} Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 183480) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -51,7 +51,7 @@ #define NFE_MSI_MAP0 0x020 #define NFE_MSI_MAP1 0x024 #define NFE_MSI_IRQ_MASK 0x030 -#define NFE_MAC_RESET 0x03c +#define NFE_MAC_RESET 0x034 #define NFE_MISC1 0x080 #define NFE_TX_CTL 0x084 #define NFE_TX_STATUS 0x088 @@ -87,11 +87,41 @@ #define NFE_PHY_SPEED 0x18c #define NFE_PHY_CTL 0x190 #define NFE_PHY_DATA 0x194 +#define NFE_TX_UNICAST 0x1a0 +#define NFE_TX_MULTICAST 0x1a4 +#define NFE_TX_BROADCAST 0x1a8 #define NFE_WOL_CTL 0x200 #define NFE_PATTERN_CRC 0x204 #define NFE_PATTERN_MASK 0x208 #define NFE_PWR_CAP 0x268 #define NFE_PWR_STATE 0x26c +#define NFE_TX_OCTET 0x280 +#define NFE_TX_ZERO_REXMIT 0x284 +#define NFE_TX_ONE_REXMIT 0x288 +#define NFE_TX_MULTI_REXMIT 0x28c +#define NFE_TX_LATE_COL 0x290 +#define NFE_TX_FIFO_UNDERUN 0x294 +#define NFE_TX_CARRIER_LOST 0x298 +#define NFE_TX_EXCESS_DEFERRAL 0x29c +#define NFE_TX_RETRY_ERROR 0x2a0 +#define NFE_RX_FRAME_ERROR 0x2a4 +#define NFE_RX_EXTRA_BYTES 0x2a8 +#define NFE_RX_LATE_COL 0x2ac +#define NFE_RX_RUNT 0x2b0 +#define NFE_RX_JUMBO 0x2b4 +#define NFE_RX_FIFO_OVERUN 0x2b8 +#define NFE_RX_CRC_ERROR 0x2bc +#define NFE_RX_FAE 0x2c0 +#define NFE_RX_LEN_ERROR 0x2c4 +#define NFE_RX_UNICAST 0x2c8 +#define NFE_RX_MULTICAST 0x2cc +#define NFE_RX_BROADCAST 0x2d0 +#define NFE_TX_DEFERAL 0x2d4 +#define NFE_TX_FRAME 0x2d8 +#define NFE_RX_OCTET 0x2dc +#define NFE_TX_PAUSE 0x2e0 +#define NFE_RX_PAUSE 0x2e4 +#define NFE_RX_DROP 0x2e8 #define NFE_VTAG_CTL 0x300 #define NFE_MSIX_MAP0 0x3e0 #define NFE_MSIX_MAP1 0x3e4 @@ -182,6 +212,10 @@ #define NFE_SEED_100TX 0x00002d00 #define NFE_SEED_1000T 0x00007400 +#define NFE_NUM_MIB_STATV1 21 +#define NFE_NUM_MIB_STATV2 27 +#define NFE_NUM_MIB_STATV3 30 + #define NFE_MSI_MESSAGES 8 #define NFE_MSI_VECTOR_0_ENABLED 0x01 @@ -295,6 +329,14 @@ #define PCI_PRODUCT_NVIDIA_MCP73_LAN2 0x07dd #define PCI_PRODUCT_NVIDIA_MCP73_LAN3 0x07de #define PCI_PRODUCT_NVIDIA_MCP73_LAN4 0x07df +#define PCI_PRODUCT_NVIDIA_MCP77_LAN1 0x0760 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN2 0x0761 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN3 0x0762 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN4 0x0763 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN1 0x0ab0 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN2 0x0ab1 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN3 0x0ab2 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN4 0x0ab3 #define PCI_PRODUCT_NVIDIA_NFORCE3_LAN2 PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1 #define PCI_PRODUCT_NVIDIA_NFORCE3_LAN3 PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2 Index: sys/dev/nfe/if_nfevar.h =================================================================== --- sys/dev/nfe/if_nfevar.h (revision 183480) +++ sys/dev/nfe/if_nfevar.h (working copy) @@ -70,6 +70,39 @@ int jnext; }; +struct nfe_hw_stats { + uint64_t tx_octets; + uint32_t tx_zero_rexmits; + uint32_t tx_one_rexmits; + uint32_t tx_multi_rexmits; + uint32_t tx_late_cols; + uint32_t tx_fifo_underuns; + uint32_t tx_carrier_losts; + uint32_t tx_excess_deferals; + uint32_t tx_retry_errors; + uint32_t rx_frame_errors; + uint32_t rx_extra_bytes; + uint32_t rx_late_cols; + uint32_t rx_runts; + uint32_t rx_jumbos; + uint32_t rx_fifo_overuns; + uint32_t rx_crc_errors; + uint32_t rx_fae; + uint32_t rx_len_errors; + uint32_t rx_unicast; + uint32_t rx_multicast; + uint32_t rx_broadcast; + uint32_t tx_deferals; + uint32_t tx_frames; + uint64_t rx_octets; + uint32_t tx_pause; + uint32_t rx_pause; + uint32_t rx_drops; + uint32_t tx_unicast; + uint32_t tx_multicast; + uint32_t tx_broadcast; +}; + struct nfe_softc { struct ifnet *nfe_ifp; device_t nfe_dev; @@ -96,10 +129,14 @@ #define NFE_PWR_MGMT 0x0010 #define NFE_CORRECT_MACADDR 0x0020 #define NFE_TX_FLOW_CTRL 0x0040 +#define NFE_MIB_V1 0x0080 +#define NFE_MIB_V2 0x0100 +#define NFE_MIB_V3 0x0200 int nfe_jumbo_disable; uint32_t rxtxctl; uint8_t mii_phyaddr; uint8_t eaddr[ETHER_ADDR_LEN]; + struct nfe_hw_stats nfe_stats; struct taskqueue *nfe_tq; struct task nfe_int_task; struct task nfe_tx_task; --jho1yZJdad60DJr+-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:20:51 2008 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 078181065696 for ; Tue, 30 Sep 2008 04:20:51 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id B6F228FC23 for ; Tue, 30 Sep 2008 04:20:50 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 46E3617DB4; Tue, 30 Sep 2008 14:20:48 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (142.19.96.58.exetel.com.au [58.96.19.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 5CF9C17DA2 for ; Tue, 30 Sep 2008 14:20:42 +1000 (EST) Message-ID: <48E1A8E8.3090904@modulus.org> Date: Tue, 30 Sep 2008 14:19:52 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <48E183A2.8000209@modulus.org> <20080930041215.GH86326@dan.emsphone.com> In-Reply-To: <20080930041215.GH86326@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 04:20:51 -0000 Dan Nelson wrote: > That'd be handy, but at least on my system the data prefetcher isn't > really called often enough to make a difference either way (assuming > the counts are accurate). Metadata prefetch is a big win, however. arcstats.prefetch_data_hits: 4538242 (13%) arcstats.prefetch_data_misses: 29298997 arcstats.prefetch_metadata_hits: 593799808 (96%) arcstats.prefetch_metadata_misses: 21582847 You are much luckier than me. For obvious reasons, I would like to completely disable data prefetch but leave on metadata prefetch. I believe it would speed up the filesystem plus save RAM (less wasted use of ARC). But especially desktop systems would not need to waste space on such aggressive prefetching. - Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:32:06 2008 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 E1D841065686 for ; Tue, 30 Sep 2008 04:32:05 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp143.sat.emailsrvr.com (smtp143.sat.emailsrvr.com [66.216.121.143]) by mx1.freebsd.org (Postfix) with ESMTP id AD7F28FC13 for ; Tue, 30 Sep 2008 04:32:05 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from relay4.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 924CF27B400 for ; Mon, 29 Sep 2008 23:55:23 -0400 (EDT) Received: by relay4.relay.sat.mlsrvr.com (Authenticated sender: henrik-AT-ecwwebworks.com) with ESMTP id 188DC27ACFB for ; Mon, 29 Sep 2008 23:55:23 -0400 (EDT) From: Henrik Hudson To: freebsd-stable@freebsd.org Date: Mon, 29 Sep 2008 19:55:21 -0800 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809291955.21461.lists@rhavenn.net> Subject: wpi driver freeze on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@rhavenn.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 04:32:06 -0000 I've got a HP dv8000 laptop. Setting up the wpi driver for wireless freezes the system on boot with the following error: wpi0 requested unsupported memory range wpi0: could not allocate memory resource It lists a pcbi device (pcbi4 i think) and an actual memory range, but since I have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the info. Is there anyway to grab the info when it freezes when it reboots? I'm running i386 7.1-PRERELEASE from today. pciconf and the kernel are below. Let me know if you need anything else. pciconf -v -l: hostb0@pci0:0:0:0: class=0x060000 card=0x30a5103c chip=0x27a08086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x30a5103c chip=0x27a18086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '955XM/945GM/PM/GMS/940GML Express PCIe Root Port' class = bridge subclass = PCI-PCI pcm0@pci0:0:27:0: class=0x040300 card=0x30a5103c chip=0x27d88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class = multimedia pcib2@pci0:0:28:0: class=0x060400 card=0x30a5103c chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x30a5103c chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x30a5103c chip=0x27d48086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x30a5103c chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x30a5103c chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x30a5103c chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x30a5103c chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x30a5103c chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x30a5103c chip=0x24488086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x30a5103c chip=0x27b98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x30a5103c chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x30a5103c chip=0x27c58086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB Mobile I/O Controller Hub SATA cc=AHCI' class = mass storage none0@pci0:0:31:3: class=0x0c0500 card=0x30a5103c chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x30a5103c chip=0x039810de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'ff101179 31b7bfb9' class = display subclass = VGA none1@pci0:6:0:0: class=0x028000 card=0x135b103c chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '10418086 Intel 3945ABG Wireless LAN controller' class = network cbb0@pci0:8:6:0: class=0x060700 card=0x30a5103c chip=0x8039104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCIxx12 Cardbus Controller' class = bridge subclass = PCI-CardBus fwohci0@pci0:8:6:1: class=0x0c0010 card=0x30a5103c chip=0x803a104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = '??? OHCI Compliant IEEE 1394 Host controller' class = serial bus subclass = FireWire none2@pci0:8:6:2: class=0x018000 card=0x30a5103c chip=0x803b104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCIxx12 Integrated Flash Media Controller' class = mass storage none3@pci0:8:6:3: class=0x080500 card=0x30a5103c chip=0x803c104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCIxx12 SDA Standard Compliant SD Host Controller' class = base peripheral fxp0@pci0:8:8:0: class=0x020000 card=0x30a5103c chip=0x10928086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82562GZ PRO/100 VE Network Controller' class = network subclass = ethernet kernel (mostly generic): #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident ARUCARD # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x #device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc #device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device rum # Ralink Technology RT2501USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons #sound device sound device snd_hda #cd burner device atapicam #3945ABG wireless - additional items device wpi #firewall -pf device pf device pflog device pfsync #firewall options options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options SC_NO_HISTORY options SC_DISABLE_REBOOT -- Henrik Hudson lists@rhavenn.net ------------------------------ "God, root, what is difference?" Pitr; UF (http://www.userfriendly.org/) From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:32:52 2008 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 D926D106568C for ; Tue, 30 Sep 2008 04:32:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id B75398FC0C for ; Tue, 30 Sep 2008 04:32:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id LsSc1a00517UAYkA3sYsY1; Tue, 30 Sep 2008 04:32:52 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id LsYq1a00J4v8bD78ZsYrGU; Tue, 30 Sep 2008 04:32:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=-yhJEkN_MDzKlqzCys4A:9 a=edlQyZZIXfq769eLMXgA:7 a=7uWRdPfgoIcZitXqQ7ZnRmYUFrEA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D732CC9419; Mon, 29 Sep 2008 21:32:50 -0700 (PDT) Date: Mon, 29 Sep 2008 21:32:50 -0700 From: Jeremy Chadwick To: Andrew Snow Message-ID: <20080930043250.GA36878@icarus.home.lan> References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> <48E1839E.3060006@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E1839E.3060006@modulus.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 04:32:52 -0000 On Tue, Sep 30, 2008 at 11:40:46AM +1000, Andrew Snow wrote: > > Matthew Dillon wrote: >> It can take 6 hours to fsck a full 1TB HD. It can >> take over a day to fsck larger setups. Putting in a few sleeps here >> and there just makes the run time even longer and perpetuates the pain. > > We have a box with millions of files spread over 2TB, on a 16 disk RAID. > Foreground fsck takes almost 8 hours, so background fsck, which takes > almost 24 hours or more, is my only option when I want to bring the box > back online quickly. And UFS Snapshots are so slow as to be completely > useless. > > I've now converted the volume to ZFS, and am now enjoying instant boot > time and higher speed I/O under heavy load, at the expense of memory > consumption. > >> My recommendation? Default UFS back to a synchronous fsck and stop >> treating ZFS (your only real alternative) as being so ultra-alpha that >> it shouldn't be used. > > Completely agree. ZFS is the way of the future for FreeBSD. In my > latest testing, the memory problems are now under control, there is just > stability problems with random lockups after days of heavy load unless I > turn off ZIL. So its nearly there. It just now occurred to me that this entire conversation should've been moved to freebsd-fs weeks ago. *laugh* Oh well. :-) You're the first person I've encountered who has had to disable the ZIL to get stability in ZFS; ouch, that must hurt. ZFS stability has been discussed on freebsd-fs numerous times, but the answers provided are always penultimate; no one (AFAIK) has examined how to solve this from the start (specifically new FreeBSD installations). Yes, I know sysinstall/sade doesn't support ZFS (though the PC-BSD folks have apparently implemented this), but that's not what I'm talking about. I'm talking about the most commonly-encountered problem: kmem exhaustion. People want to be able to install FreeBSD then say "Okay! Time to give ZFS a try!" on some separate disks, and have it work. They don't want to encounter kmem exhaustion half way through the migration process; that's just going to dishearten them. I'll be starting up a new topic on freebsd-fs later tonight with an idea I came up with for solving this out-of-the-box. I have a feeling I'm going to get told "so who's going to do all the work?" or downright flamed, but I hope it induces a discussion of ideas, specifically with regards to new FreeBSD installations. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 04:54:48 2008 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 82C581065688 for ; Tue, 30 Sep 2008 04:54:48 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1A88FC1E for ; Tue, 30 Sep 2008 04:54:47 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id CD07E17DA2; Tue, 30 Sep 2008 14:54:46 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (142.19.96.58.exetel.com.au [58.96.19.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 8D317171C8; Tue, 30 Sep 2008 14:54:42 +1000 (EST) Message-ID: <48E1B0DF.4020601@modulus.org> Date: Tue, 30 Sep 2008 14:53:51 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> <48E1839E.3060006@modulus.org> <20080930043250.GA36878@icarus.home.lan> In-Reply-To: <20080930043250.GA36878@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 04:54:48 -0000 Jeremy Chadwick wrote: > You're the first person I've encountered who has had to disable the ZIL > to get stability in ZFS; ouch, that must hurt. Its not so bad: this machine is doing backups with rsync, sometimes running 50 simultaneously. This workload doesn't contain any need for synchronous operations, and any files which didn't get written after a crash can simply be re-rsync. But I hope eventually it will be fixed! > I'm talking about the most commonly-encountered problem: kmem > exhaustion. People want to be able to install FreeBSD then say "Okay! > Time to give ZFS a try!" on some separate disks, and have it work. Personally I don't think there's much point worrying about how to boot off ZFS at this stage until the code is up to date, stable, and running 7-STABLE branch. Until then I will also prefer to have a UFS root volume and just run ZFS for /usr and /home, because I still don't completely trust ZFS and I have a high value on being able to boot the system and have my tools available in /bin and /sbin. - Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 05:36:21 2008 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 EA2E7106569B for ; Tue, 30 Sep 2008 05:36:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8AB8FC14 for ; Tue, 30 Sep 2008 05:36:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA10.westchester.pa.mail.comcast.net with comcast id LfYs1a0221HzFnQ5AtcLxS; Tue, 30 Sep 2008 05:36:20 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA14.westchester.pa.mail.comcast.net with comcast id LtcK1a00B4v8bD73atcL5Y; Tue, 30 Sep 2008 05:36:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=7-BNHcITobPQHlsq6vEA:9 a=gzjGhLoFf_USr2RAgORIwtxnPc0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 84203C9419; Mon, 29 Sep 2008 22:36:19 -0700 (PDT) Date: Mon, 29 Sep 2008 22:36:19 -0700 From: Jeremy Chadwick To: Matthew Dillon Message-ID: <20080930053619.GA37286@icarus.home.lan> References: <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809291744.m8THiBlR034739@apollo.backplane.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 05:36:22 -0000 On Mon, Sep 29, 2008 at 10:44:11AM -0700, Matthew Dillon wrote: > A couple of things to note here. Well, many things actually. Matt, I just wanted to take a moment to thank you for your verbose and thorough outline of the issues as you see them. You're the first developer (albeit Dragonfly :-) ) I've seen to comment on these in detail. I fully agree with each and every item you covered, as well as the items in your follow-up mail to Andrew (re: mentioning BIOS/software RAID and hardware RAID at the end). Going with ZFS as the default filesystem is really something we should be considering seriously. Oh, and yes, I *completely* agree with your statement about the Foundation coughing up money to pjd@ for his efforts. ZFS "saving our asses" is how I put it too. :-) The topic of BIO_FLUSH is something I got to thinking about last night at work; the only condition where a disk with write caching enabled *would not* fully write the data to the platter would in fact be power loss. All other conditions (specifically soft reset and panic) should not require explicit flushing. I wonder why this is being done, especially on shutdown of FreeBSD. Assuming I understand it correctly, I'm talking about this: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...3 3 3 2 2 0 0 done All buffers synced. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 09:23:20 2008 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 A0358106568A for ; Tue, 30 Sep 2008 09:23:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 75CE38FC1B for ; Tue, 30 Sep 2008 09:23:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2356330rvf.43 for ; Tue, 30 Sep 2008 02:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8NOTTHt9kXl0hBoywXRyLDgkdihhOZnFSRTkd/3nkQI=; b=xUq8fAVdX5b13iTxTSoYRIz1lCbklaHrs7e8CdVt0Uz9Fa7eUICsD+IjxzEHB/Zr8m 7MvHW2RJpASX2RmKShBhEkhyPXxBW6uGD639kr29YWqpC51z0dfsiKS7f+aRcd1udOI5 lJ8sarJdchJCRA595xKS/1mvvHVKDEn7IsW74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EUOtluQsjxPqzXV+kOMbQqVZIueWuBlB42E1J/YwjhmcTQ9KadRM9vnDw9PKf1tCxs TzGv39xgneRARm1+yTozcpDQJxh+YZ313vgK2uSaNzwauodzpLNo686R9C+CEsJwMvCz VI9iv7j+fUMdj9Kuaf+3bTzDF10YnbdqRHZVU= Received: by 10.141.122.1 with SMTP id z1mr3216251rvm.197.1222766598987; Tue, 30 Sep 2008 02:23:18 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Tue, 30 Sep 2008 02:23:18 -0700 (PDT) Message-ID: <3a142e750809300223p529caafle7f02a58524abc18@mail.gmail.com> Date: Tue, 30 Sep 2008 11:23:18 +0200 From: "Paul B. Mahol" To: lists@rhavenn.net In-Reply-To: <200809291955.21461.lists@rhavenn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809291955.21461.lists@rhavenn.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpi driver freeze on boot 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, 30 Sep 2008 09:23:20 -0000 On 9/30/08, Henrik Hudson wrote: > I've got a HP dv8000 laptop. Setting up the wpi driver for wireless freezes > the system on boot with the following error: > > wpi0 requested unsupported memory range > wpi0: could not allocate memory resource > > It lists a pcbi device (pcbi4 i think) and an actual memory range, but since > I > have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the > info. Is there anyway to grab the info when it freezes when it reboots? Perhaps, entering single-user mode. Add this lines to your kernel to help debug problem. makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 09:25:12 2008 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 071D81065692 for ; Tue, 30 Sep 2008 09:25:12 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8058FC12 for ; Tue, 30 Sep 2008 09:25:11 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id m8U95gNC039199 for ; Tue, 30 Sep 2008 12:05:42 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <48E1EBE1.50206@eng.auth.gr> Date: Tue, 30 Sep 2008 12:05:37 +0300 From: George Mamalakis User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: jails and mac_seeotheruids problems in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 09:25:12 -0000 Hallo everyone, I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as "strong" as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 09:28:14 2008 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 9ADA01065691; Tue, 30 Sep 2008 09:28:14 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 598348FC29; Tue, 30 Sep 2008 09:28:14 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 168E32218A83; Tue, 30 Sep 2008 19:28:13 +1000 (EST) X-Viruscan-Id: <48E1F12C0000660924F016@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id BF0E621B6643; Tue, 30 Sep 2008 19:28:12 +1000 (EST) Received: from k7.mavetju (ppp121-44-153-110.lns10.syd7.internode.on.net [121.44.153.110]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 560D22218A81; Tue, 30 Sep 2008 19:28:12 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 5CCB7798; Tue, 30 Sep 2008 19:27:43 +1000 (EST) Date: Tue, 30 Sep 2008 19:27:43 +1000 From: Edwin Groothuis To: current@freebsd.org, stable@freebsd.org Message-ID: <20080930092743.GD3211@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <20080929120441.GA43384@voi.aagh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080929120441.GA43384@voi.aagh.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Request for testing - top 3.8b1 in the base 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, 30 Sep 2008 09:28:14 -0000 On Mon, Sep 29, 2008 at 01:04:41PM +0100, Thomas Hurst wrote: > * Edwin Groothuis (edwin@freebsd.org) wrote: > > > I have made an update for the top(1) utility in the FreeBSD base > > system to get it from the 3.5b12 version to the 3.8b1 version. > > Looks good, thanks! > > IO mode seems to have changed a bit, giving different values to 3.5, it > seems while 3.5 gives you the count for the sample period, 3.8 always > gives you a per-second rate, e.g. top -mio -s 20: > > 3.8: > 44181 freaky 240 0 240 0 0 240 99.74% cat > > 3.5: > 44181 freaky 4664 5 4667 0 0 4667 100.00% cat > > This might be confusing, since it means values from two different top > -mio's are no longer directly comparable. I will make it back to per-period because that is the one which actually makes sense (IMHO). > 3.8 also seems to be lacking IO sorting options; "o vcsw" etc are > missing. Will they be returning? They will be back. > Also, the [number] argument given to -m io has no effect: > > top -m io 10 > > Setting it after loading with "n 10" causes top to exit. That's a good one to catch, thanks! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 09:42:10 2008 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 4A12C1065687 for ; Tue, 30 Sep 2008 09:42:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2623D8FC1E for ; Tue, 30 Sep 2008 09:42:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id AF6AA46B8C; Tue, 30 Sep 2008 05:42:09 -0400 (EDT) Date: Tue, 30 Sep 2008 10:42:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: George Mamalakis In-Reply-To: <48E1EBE1.50206@eng.auth.gr> Message-ID: References: <48E1EBE1.50206@eng.auth.gr> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: jails and mac_seeotheruids problems in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 09:42:10 -0000 On Tue, 30 Sep 2008, George Mamalakis wrote: > I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them > is running 7-STABLE. All three have services running in jails. I noticed a > very peculiar behavior in 6-STABLE when I set the sysctl > security.mac.seeotheruids.enabled=1. The root user in my jails was not able > to see processes and sockets owned by other users of the same jail, whereas > the root user of the host system could see every process (thank the > Almighty). The same behavior does not apply on the server running 7-STABLE. > > In one sense it is more secure, since the root user in a jail is not as > "strong" as the root user should be in a UNIX system. On the other hand, the > root user looses its purpose of existence, which I suppose is a bug. > > Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge > > 6-STABLE: > > security.mac.max_slots: 4 > security.mac.enforce_network: 1 > security.mac.enforce_pipe: 1 > security.mac.enforce_posix_sem: 1 > security.mac.enforce_suid: 1 > security.mac.mmap_revocation_via_cow: 0 > security.mac.mmap_revocation: 1 > security.mac.enforce_vm: 1 > security.mac.enforce_process: 1 > security.mac.enforce_socket: 1 > security.mac.enforce_system: 1 > security.mac.enforce_kld: 1 > security.mac.enforce_sysv_msg: 1 > security.mac.enforce_sysv_sem: 1 > security.mac.enforce_sysv_shm: 1 > security.mac.enforce_fs: 1 > security.mac.seeotheruids.specificgid: 0 > security.mac.seeotheruids.specificgid_enabled: 0 > security.mac.seeotheruids.primarygroup_enabled: 0 > security.mac.seeotheruids.enabled: 1 > security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 > security.mac.portacl.port_high: 1023 > security.mac.portacl.autoport_exempt: 1 > security.mac.portacl.suser_exempt: 1 > security.mac.portacl.enabled: 1 > > > 7-STABLE: > > security.mac.max_slots: 4 > security.mac.version: 3 > security.mac.mmap_revocation_via_cow: 0 > security.mac.mmap_revocation: 1 > security.mac.seeotheruids.specificgid: 0 > security.mac.seeotheruids.specificgid_enabled: 0 > security.mac.seeotheruids.suser_privileged: 1 > security.mac.seeotheruids.primarygroup_enabled: 0 > security.mac.seeotheruids.enabled: 1 > > I would be very glad if someone could inform me whether I am doing something > wrong; if not I think I should inform FreeBSD about this bug. > > Thank you guys in advance, > > -- > George Mamalakis > > IT Officer > Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), > MSc (Imperial College of London) > > Department of Electrical and Computer Engineering > Faculty of Engineering > Aristotle University of Thessaloniki > > phone number : +30 (2310) 994379 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:08:51 2008 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 6C216106568A for ; Tue, 30 Sep 2008 10:08:51 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id D7A3A8FC1A for ; Tue, 30 Sep 2008 10:08:50 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id m8UA8mPt009733 for ; Tue, 30 Sep 2008 12:08:48 +0200 (CEST) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id m8UA8mpm009732 for stable@freebsd.org; Tue, 30 Sep 2008 12:08:48 +0200 (CEST) (envelope-from hk) Date: Tue, 30 Sep 2008 12:08:48 +0200 From: Holger Kipp To: stable@freebsd.org Message-ID: <20080930100848.GA9193@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 30 Sep 2008 10:08:51 -0000 Hi, could anyone give recommendations (or share experience) regarding using ZFS: - FreeBSD 7-Stable (amd64 with 8GB RAM) + special tuning necessary (apart from increasing kernel memory to 1 or more GB for ZFS) - Samba 3.2 + ACLs possible directly under ZFS? + recommended compile options? - NFS - email (imap) - jails (I have seen some problems exist with using snaphots within jails) This is on amd64 with 8GB RAM and external disk array (via FC). Many thanks and best regards, Holger -- Sorry - lost my signature somewhere. Need to buy a new one. Ofers? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:16:05 2008 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 20210106568B for ; Tue, 30 Sep 2008 10:16:05 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by mx1.freebsd.org (Postfix) with ESMTP id D162D8FC27 for ; Tue, 30 Sep 2008 10:16:04 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh03-2.mail.saunalahti.fi (Postfix) with SMTP id ACC62EBC9C; Tue, 30 Sep 2008 13:16:03 +0300 (EEST) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A00727A06B0; Tue, 30 Sep 2008 13:16:03 +0300 Received: from a91-153-122-179.elisa-laajakaista.fi (a91-153-122-179.elisa-laajakaista.fi [91.153.122.179]) by emh03.mail.saunalahti.fi (Postfix) with SMTP id 3D639158AFA; Tue, 30 Sep 2008 13:16:00 +0300 (EEST) Date: Tue, 30 Sep 2008 13:15:59 +0300 From: Jaakko Heinonen To: jb@FreeBSD.org Message-ID: <20080930101559.GA810@a91-153-122-179.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: VAMS Cc: mgass@unix.csbsju.edu, stable@FreeBSD.org Subject: DTrace MFC broke kldstat(2) on RELENG_7 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, 30 Sep 2008 10:16:05 -0000 Hi, I recently noticed that kldstat(8) started to dump core for me on RELENG_7. I traced the problem down to kldstat(2). r182231 (DTrace MFC) introduced a new version of kld_file_stat struct and added some code to support the old version of the structure in kldstat(). In the new code the old structure is known as kld_file_stat_1. Unfortunately there's a bug in this code: kldstat() copies always sizeof(struct kld_file_stat) of data to user space while it should copy sizeof(struct kld_file_stat_1) when the old struct is used. This guy is probably suffering from this problem too: http://lists.freebsd.org/pipermail/freebsd-questions/2008-September/182896.html I used this patch to fix the problem: %%% Index: sys/kern/kern_linker.c =================================================================== --- sys/kern/kern_linker.c (revision 183486) +++ sys/kern/kern_linker.c (working copy) @@ -1199,7 +1199,12 @@ kldstat(struct thread *td, struct kldsta td->td_retval[0] = 0; - return (copyout(&stat, uap->stat, sizeof(struct kld_file_stat))); + if (version_num == 1) + return (copyout(&stat, uap->stat, + sizeof(struct kld_file_stat_1))); + else + return (copyout(&stat, uap->stat, + sizeof(struct kld_file_stat))); } int %%% -- Jaakko From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:32:32 2008 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 C7F53106568B for ; Tue, 30 Sep 2008 10:32:32 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1C78FC15 for ; Tue, 30 Sep 2008 10:32:31 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8UAWRr6019877; Tue, 30 Sep 2008 11:32:28 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KkcWp-0007GL-TV; Tue, 30 Sep 2008 11:32:27 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8UAWQFi030191; Tue, 30 Sep 2008 11:32:27 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8UAWQZA030190; Tue, 30 Sep 2008 11:32:26 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Oliver Lehmann In-Reply-To: <20080929221408.54e6a03a.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 30 Sep 2008 11:32:26 +0100 Message-Id: <1222770746.29968.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 10:32:32 -0000 On Mon, 2008-09-29 at 22:14 +0200, Oliver Lehmann wrote: > Any idea what I could do to shed some more light on this behaviour? > Why it is happening and what really is causing it? > Would enabling the kernel debugger really help here? I mean the system > is really hanging up - except ping response it is not responding to > anything except the reset switch ;) If it's responding to ping, you should be able to get into the debugger. Compile it in, along with "options WITNESS" and "options WITNESS_SKIPSPIN", and press ctrl-alt-escape when the machine next hangs. >From there, it should hopefully be possible to get more info. It's been a long time since I've used the debugger under 6.x so some of the more useful commands may not exist, but the output of at least "sh locks", "sh alllocks" and "bt" on any processes that seem to be holding locks. Also "sh pcpu" and "ps" will help to determine exactly what was running at the time. Gavin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:39:30 2008 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 EE17C106564A for ; Tue, 30 Sep 2008 10:39:30 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2C05C8FC1E for ; Tue, 30 Sep 2008 10:39:30 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kkcdb-0005wG-4I; Tue, 30 Sep 2008 12:39:29 +0200 Message-ID: <48E201DF.5090001@kkip.pl> Date: Tue, 30 Sep 2008 12:39:27 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Oliver Lehmann , freebsd-stable@freebsd.org References: <20080929221408.54e6a03a.lehmann@ans-netz.de> In-Reply-To: <20080929221408.54e6a03a.lehmann@ans-netz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.8 X-Spam-Score-Int: -87 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-09-30 12:39:29 X-Connected-IP: 192.168.0.10:4819 X-Message-Linecount: 74 X-Body-Linecount: 61 X-Message-Size: 2973 X-Body-Size: 2416 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 10:39:31 -0000 Oliver Lehmann wrote: > Hi, > > My fileserver has sporadical hangups running 6.3: > > FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 > olivleh1@nudel.salatschuessel.net:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL > > The exact release doesn't matter since it happened before. It always > happens afer some time of having some load on the system (I'm building > ports with tinderbox and during the build process it just hangs up). > > The system does nothing write out on the console, neither the CRT, nor > the serial console. > > The system itself is: > > CPU: Intel Pentium III (845.64-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x683 Stepping = 3 > Features=0x387fbff > real memory = 805240832 (767 MB) > avail memory = 778481664 (742 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 1 > cpu1 (AP): APIC ID: 0 > ioapic0 irqs 0-23 on motherboard > > while the diskspace is provided by an 3ware RAID: > > twa0: <3ware 9000 series Storage Controller> port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf4800000-0xf4ffffff irq 18 at device 11.0 on pci0 > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 > > da0 at twa0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 100.000MB/s transfers > da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) > > I had - in the past - sometimes messages left which where indicating, > that the system was not able to allocate swap space fast enough if I > recall it correctly (_not_ out of swap space!) but the RAID is kinda > fast imho. > > Any idea what I could do to shed some more light on this behaviour? > Why it is happening and what really is causing it? > Would enabling the kernel debugger really help here? I mean the system > is really hanging up - except ping response it is not responding to > anything except the reset switch ;) > > Greetings, Oliver > > > Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:40:28 2008 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 13ECB106568A; Tue, 30 Sep 2008 10:40:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E340F8FC17; Tue, 30 Sep 2008 10:40:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 91FAD46B03; Tue, 30 Sep 2008 06:40:26 -0400 (EDT) Date: Tue, 30 Sep 2008 11:40:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gavin Atkinson In-Reply-To: <1222770746.29968.6.camel@buffy.york.ac.uk> Message-ID: References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <1222770746.29968.6.camel@buffy.york.ac.uk> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-stable@FreeBSD.org, Oliver Lehmann Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 10:40:28 -0000 On Tue, 30 Sep 2008, Gavin Atkinson wrote: > On Mon, 2008-09-29 at 22:14 +0200, Oliver Lehmann wrote: > >> Any idea what I could do to shed some more light on this behaviour? >> Why it is happening and what really is causing it? >> Would enabling the kernel debugger really help here? I mean the system >> is really hanging up - except ping response it is not responding to >> anything except the reset switch ;) > > If it's responding to ping, you should be able to get into the debugger. > Compile it in, along with "options WITNESS" and "options WITNESS_SKIPSPIN", > and press ctrl-alt-escape when the machine next hangs. > > From there, it should hopefully be possible to get more info. It's been a > long time since I've used the debugger under 6.x so some of the more useful > commands may not exist, but the output of at least "sh locks", "sh alllocks" > and "bt" on any processes that seem to be holding locks. Also "sh pcpu" and > "ps" will help to determine exactly what was running at the time. "show lockedvnods" is also quite useful if the problem originates in the file system, as it lists vnodes that have been locked, and by which threads. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:46:06 2008 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 B890A1065688 for ; Tue, 30 Sep 2008 10:46:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7CB8FC0A for ; Tue, 30 Sep 2008 10:46:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id Ly5Q1a00C17UAYkA8ym6XE; Tue, 30 Sep 2008 10:46:06 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id Lym51a0064v8bD78Zym5Ut; Tue, 30 Sep 2008 10:46:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=N8se_1cBi2wA:10 a=j3-Kh4PWcnIA:10 a=QycZ5dHgAAAA:8 a=Zj-cUZlRSTm4WY7tLLUA:9 a=vRaO9gA2lj36Lagy2GwA:7 a=zG9y2jBFfNYj2FggkgXM7Qbg6x8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 20079C9419; Tue, 30 Sep 2008 03:46:05 -0700 (PDT) Date: Tue, 30 Sep 2008 03:46:05 -0700 From: Jeremy Chadwick To: Holger Kipp Message-ID: <20080930104605.GA44675@icarus.home.lan> References: <20080930100848.GA9193@intserv.int1.b.intern> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080930100848.GA9193@intserv.int1.b.intern> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 30 Sep 2008 10:46:06 -0000 On Tue, Sep 30, 2008 at 12:08:48PM +0200, Holger Kipp wrote: > could anyone give recommendations (or share experience) regarding > using ZFS: > > - FreeBSD 7-Stable (amd64 with 8GB RAM) > + special tuning necessary (apart from increasing kernel memory > to 1 or more GB for ZFS) Applicable loader.conf variables which should suffice: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" vfs.zfs.prefetch_disable="1" You can increase arc_max gradually, and performance should increase as you do so. Just be aware that too large of a value could result in kmem exhaustion on RELENG_7. There is a 2GB limit on kmem on RELENG_7 (yes, both i386 AND amd64), so do not try to increase vm.kmem_size or kmem_size_max above what I've shown there (others may have chosen something slightly higher, but picking 2048M will cause the system not to boot). If the limit is a problem, consider running CURRENT which increases this to 512GB. The prefetch setting should improve overall system performance during heavy ZFS load; many of us (including core members) have found this to be true. > - email (imap) I've had good experience with dovecot; I tend to stay away from Cyrus products (disgusting code with a history of security issues), and Courier (no interest). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 10:48:29 2008 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 8D944106568A for ; Tue, 30 Sep 2008 10:48:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 73EBC8FC1C for ; Tue, 30 Sep 2008 10:48:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Lye91a0010S2fkCA6yoVoo; Tue, 30 Sep 2008 10:48:29 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id LyoT1a0064v8bD78VyoU7m; Tue, 30 Sep 2008 10:48:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=NakPE3hwIkWlccCA_jkA:9 a=bQjvDLxRWUS8k3SbAUsA:7 a=8Vgx2P8qC-esDYP9Usu0at5vUf8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A731FC9419; Tue, 30 Sep 2008 03:48:27 -0700 (PDT) Date: Tue, 30 Sep 2008 03:48:27 -0700 From: Jeremy Chadwick To: Bartosz Stec Message-ID: <20080930104827.GB44675@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E201DF.5090001@kkip.pl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Oliver Lehmann Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 10:48:29 -0000 On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: > Oliver Lehmann wrote: >> Hi, >> >> My fileserver has sporadical hangups running 6.3: >> >> FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 >> olivleh1@nudel.salatschuessel.net:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL >> >> The exact release doesn't matter since it happened before. It always >> happens afer some time of having some load on the system (I'm building >> ports with tinderbox and during the build process it just hangs up). >> >> The system does nothing write out on the console, neither the CRT, nor >> the serial console. >> >> The system itself is: >> >> CPU: Intel Pentium III (845.64-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x683 Stepping = 3 >> Features=0x387fbff >> real memory = 805240832 (767 MB) >> avail memory = 778481664 (742 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 1 >> cpu1 (AP): APIC ID: 0 >> ioapic0 irqs 0-23 on motherboard >> >> while the diskspace is provided by an 3ware RAID: >> >> twa0: <3ware 9000 series Storage Controller> port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf4800000-0xf4ffffff irq 18 at device 11.0 on pci0 >> twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: >> INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, >> Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 >> >> da0 at twa0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: 100.000MB/s transfers >> da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) >> >> I had - in the past - sometimes messages left which where indicating, >> that the system was not able to allocate swap space fast enough if I >> recall it correctly (_not_ out of swap space!) but the RAID is kinda >> fast imho. >> >> Any idea what I could do to shed some more light on this behaviour? >> Why it is happening and what really is causing it? >> Would enabling the kernel debugger really help here? I mean the system >> is really hanging up - except ping response it is not responding to >> anything except the reset switch ;) >> >> Greetings, Oliver >> >> >> > Personally I'd rather bet on some hardware problem (overheating?) Try to > install mbmon from ports. I had also similiar problems with old > motherboards with swelled capacitors. Be careful with mbmon and healthd -- just because they compile and run does not mean they're working properly (the values shown may be completely unreliable/incorrect). It's best to check such things in the system BIOS, unless you have absolute certainty that your motherboard is supported by mbmon/healthd. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 12:26:14 2008 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 A3B841065691 for ; Tue, 30 Sep 2008 12:26:14 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from zoc.com.ua (zoc.com.ua [82.144.212.13]) by mx1.freebsd.org (Postfix) with ESMTP id 439018FC19 for ; Tue, 30 Sep 2008 12:26:13 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from [192.168.0.22] (port=55474) by zoc.com.ua with esmtp (Exim 4.62) (envelope-from ) id 1Kkdov-00052Z-CZ for freebsd-stable@freebsd.org; Tue, 30 Sep 2008 14:55:13 +0300 From: Kyryll A Mirnenko aka Mirya Organization: zoc To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 14:54:45 +0300 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301454.47473.mirya@zoc.com.ua> X-CHECK-DB: NO Subject: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 30 Sep 2008 12:26:14 -0000 I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. Here's how it goes: I have the following /etc/fstab: /dev/ad0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1d /tmp ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /dev/ad0s1f.eli /usr/home ufs rw 2 2 After upgrading to 7.1 and rebooting: ... Configuring Disk Encryption for ad0s1f. Enter passphrase: geli: Cannot access ad0s1f (error=1). Attach failed; attempt 1 of 3. Enter passphrase: geli: Wrong key for ad0s1f. Attach failed; attempt 2 of 3. Enter passphrase: geli: Wrong key for ad0s1f. ... (the key entered is actually valid and attaching succeeds on 7.0 at this point). As far as mounting failed i'm entering the single-user mode, where "geli attach /dev/ad0s1f" works perfectly: GEOM_ELI: Device ad0s1f.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software After that exiting back to multi-user mounts the missing /usr/home, so loading completes. -- Regards, Mirya ICQ #313898202 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 12:30:24 2008 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 A7CD91065690 for ; Tue, 30 Sep 2008 12:30:24 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 383128FC1C for ; Tue, 30 Sep 2008 12:30:23 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id m8UCUNN4049482; Tue, 30 Sep 2008 15:30:23 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <48E21BD9.1080101@eng.auth.gr> Date: Tue, 30 Sep 2008 15:30:17 +0300 From: George Mamalakis User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: Robert Watson References: <48E1EBE1.50206@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/8358/Tue Sep 30 14:06:39 2008 on vergina.eng.auth.gr X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.org Subject: Re: jails and mac_seeotheruids problems in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 12:30:24 -0000 It works like a charm! Thank you very much for your time and help, regards, Robert Watson wrote: > > On Tue, 30 Sep 2008, George Mamalakis wrote: > >> I have 3 servers in my lab. 2 of them are running 6-STABLE and one of >> them is running 7-STABLE. All three have services running in jails. I >> noticed a very peculiar behavior in 6-STABLE when I set the sysctl >> security.mac.seeotheruids.enabled=1. The root user in my jails was >> not able to see processes and sockets owned by other users of the >> same jail, whereas the root user of the host system could see every >> process (thank the Almighty). The same behavior does not apply on the >> server running 7-STABLE. >> >> In one sense it is more secure, since the root user in a jail is not >> as "strong" as the root user should be in a UNIX system. On the other >> hand, the root user looses its purpose of existence, which I suppose >> is a bug. >> >> Below are the security.mac sysctl settings of both 6 and 7-STABLE: > > Could you try modifying > src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so > that the call to suser_cred() in mac_seeotheruids_check() passes the > SUSER_ALLOWJAIL flag rather than 0? This may correct the problem > you're experiencing. Let me know and I can merge that change to 6.x. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> 6-STABLE: >> >> security.mac.max_slots: 4 >> security.mac.enforce_network: 1 >> security.mac.enforce_pipe: 1 >> security.mac.enforce_posix_sem: 1 >> security.mac.enforce_suid: 1 >> security.mac.mmap_revocation_via_cow: 0 >> security.mac.mmap_revocation: 1 >> security.mac.enforce_vm: 1 >> security.mac.enforce_process: 1 >> security.mac.enforce_socket: 1 >> security.mac.enforce_system: 1 >> security.mac.enforce_kld: 1 >> security.mac.enforce_sysv_msg: 1 >> security.mac.enforce_sysv_sem: 1 >> security.mac.enforce_sysv_shm: 1 >> security.mac.enforce_fs: 1 >> security.mac.seeotheruids.specificgid: 0 >> security.mac.seeotheruids.specificgid_enabled: 0 >> security.mac.seeotheruids.primarygroup_enabled: 0 >> security.mac.seeotheruids.enabled: 1 >> security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 >> security.mac.portacl.port_high: 1023 >> security.mac.portacl.autoport_exempt: 1 >> security.mac.portacl.suser_exempt: 1 >> security.mac.portacl.enabled: 1 >> >> >> 7-STABLE: >> >> security.mac.max_slots: 4 >> security.mac.version: 3 >> security.mac.mmap_revocation_via_cow: 0 >> security.mac.mmap_revocation: 1 >> security.mac.seeotheruids.specificgid: 0 >> security.mac.seeotheruids.specificgid_enabled: 0 >> security.mac.seeotheruids.suser_privileged: 1 >> security.mac.seeotheruids.primarygroup_enabled: 0 >> security.mac.seeotheruids.enabled: 1 >> >> I would be very glad if someone could inform me whether I am doing >> something wrong; if not I think I should inform FreeBSD about this bug. >> >> Thank you guys in advance, >> >> -- >> George Mamalakis >> >> IT Officer >> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >> MSc (Imperial College of London) >> >> Department of Electrical and Computer Engineering >> Faculty of Engineering >> Aristotle University of Thessaloniki >> >> phone number : +30 (2310) 994379 >> >> _______________________________________________ >> 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" >> -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 12:39:16 2008 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 BD3371065678 for ; Tue, 30 Sep 2008 12:39:16 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC9C8FC13 for ; Tue, 30 Sep 2008 12:39:15 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 8A1CB17D92; Tue, 30 Sep 2008 22:39:13 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.100] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 66C3E173B0; Tue, 30 Sep 2008 22:39:05 +1000 (EST) Message-ID: <48E21DDC.9040809@modulus.org> Date: Tue, 30 Sep 2008 22:38:52 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080930100848.GA9193@intserv.int1.b.intern> In-Reply-To: <20080930100848.GA9193@intserv.int1.b.intern> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Holger Kipp Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 30 Sep 2008 12:39:16 -0000 Holger Kipp wrote: > - FreeBSD 7-Stable (amd64 with 8GB RAM) > + special tuning necessary (apart from increasing kernel memory > to 1 or more GB for ZFS) I haven't had much luck running ZFS under heavy load on 7-stable, I was forced to install 8-current and use the latest patch set posted by pjd. Don't jump in until you've tested it with a realistic production load. The nice thing was that 8-current didn't require any special kernel or memory tuning at all (except for disabling ZIL, but not everyone seems to have to do this). > - Samba 3.2 > + ACLs possible directly under ZFS? As far as I know ZFS does not support ACLs under FreeBSD at this time, and implementing it is non-trivial. - Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:35:29 2008 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 3DF141065688; Tue, 30 Sep 2008 14:35:29 +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 C30268FC16; Tue, 30 Sep 2008 14:35:28 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id m8UEZPJZ005217 ; Tue, 30 Sep 2008 16:35:25 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m8UEZOeW004616 ; Tue, 30 Sep 2008 16:35:24 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m8UEZL1I004613; Tue, 30 Sep 2008 16:35:21 +0200 (MEST) (envelope-from arno) To: Robert Watson References: <20080929043134.GD54819@cdnetworks.co.kr> From: "Arno J. Klaassen" Date: 30 Sep 2008 16:35:17 +0200 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.93.3/8359/Tue Sep 30 15:29:02 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48E2392D.015 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48E2392D.015/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 48E2392D.015 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.011 -> S=0.011 X-j-chkmail-Status: Ham Cc: pyunyh@gmail.com, stable@FreeBSD.org, rizzo@iet.unipi.it, net@FreeBSD.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 30 Sep 2008 14:35:29 -0000 Robert Watson writes: > On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > > > However, the "request/respones" tests are awfull for my notebook > > (test repeated on the notebook for the sake of conviction) : > > Is it possible to rerun these tests with a 7.0 kernel of the same > general configuration? That would help us determine if it's a > regression between 7.0 and 7.1, 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give same results : great streaming, very poor request/response > or perhaps a more general issue > between 6.x and 7.x. nve(4) does not recognise this chip. If someone does have a bootable 6-stable .iso with a backported nfe(4) ... or email if_nfe.ko to me and I will tes under 6-stable For now I will test the patches Pyun and Luigi sent me and let you know. Best, arno From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:37:46 2008 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 8CCF31065687; Tue, 30 Sep 2008 14:37:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6345E8FC1F; Tue, 30 Sep 2008 14:37:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 163DF46B23; Tue, 30 Sep 2008 10:37:46 -0400 (EDT) Date: Tue, 30 Sep 2008 15:37:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Arno J. Klaassen" In-Reply-To: Message-ID: References: <20080929043134.GD54819@cdnetworks.co.kr> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, stable@FreeBSD.org, rizzo@iet.unipi.it, net@FreeBSD.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) 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, 30 Sep 2008 14:37:46 -0000 On Tue, 30 Sep 2008, Arno J. Klaassen wrote: >>> However, the "request/respones" tests are awfull for my notebook (test >>> repeated on the notebook for the sake of conviction) : >> >> Is it possible to rerun these tests with a 7.0 kernel of the same general >> configuration? That would help us determine if it's a regression between >> 7.0 and 7.1, > > 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give > same results : great streaming, very poor request/response Thanks for testing this -- it rules out a host of potential issues that could have been from changes in flight between 7.0 and 7.1, which is very helpful. At least for me, since I made many of those changes :-). >> or perhaps a more general issue between 6.x and 7.x. > > nve(4) does not recognise this chip. > > If someone does have a bootable 6-stable .iso with a backported nfe(4) ... > or email if_nfe.ko to me and I will tes under 6-stable > > For now I will test the patches Pyun and Luigi sent me and let you know. OK. I'll drop out of the loop on this one unless it's determined that the network stack itself is implicated rather than the drivers. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:53:39 2008 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 E46B01065687 for ; Tue, 30 Sep 2008 14:53:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 87C3D8FC0A for ; Tue, 30 Sep 2008 14:53:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8UErRFe056950; Tue, 30 Sep 2008 10:53:27 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 10:47:29 -0400 User-Agent: KMail/1.9.7 References: <20080929221408.54e6a03a.lehmann@ans-netz.de> In-Reply-To: <20080929221408.54e6a03a.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301047.29629.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 30 Sep 2008 10:53:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8359/Tue Sep 30 09:29:02 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Oliver Lehmann Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 14:53:40 -0000 On Monday 29 September 2008 04:14:08 pm Oliver Lehmann wrote: > Hi, > > My fileserver has sporadical hangups running 6.3: > > FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 > olivleh1@nudel.salatschuessel.net:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL > > The exact release doesn't matter since it happened before. It always > happens afer some time of having some load on the system (I'm building > ports with tinderbox and during the build process it just hangs up). > > The system does nothing write out on the console, neither the CRT, nor > the serial console. 1) Setup support for crashdumps. 2) Add 'DDB' and 'KDB' to your kernel. When it hangs, break into the debugger (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. 3) ps -axl -M /var/crash/vmcore.X -N /boot/kernel/kernel (where vmcore.X is the core file generated, probably vmcore.0). That's the first place to start. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:53:43 2008 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 F3E59106568B; Tue, 30 Sep 2008 14:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 749098FC0A; Tue, 30 Sep 2008 14:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8UErRFf056950; Tue, 30 Sep 2008 10:53:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 10:50:40 -0400 User-Agent: KMail/1.9.7 References: <20080930101559.GA810@a91-153-122-179.elisa-laajakaista.fi> In-Reply-To: <20080930101559.GA810@a91-153-122-179.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301050.40828.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 30 Sep 2008 10:53:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8359/Tue Sep 30 09:29:02 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: mgass@unix.csbsju.edu, jb@freebsd.org, Jaakko Heinonen , stable@freebsd.org Subject: Re: DTrace MFC broke kldstat(2) on RELENG_7 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, 30 Sep 2008 14:53:43 -0000 On Tuesday 30 September 2008 06:15:59 am Jaakko Heinonen wrote: > > Hi, > > I recently noticed that kldstat(8) started to dump core for me on > RELENG_7. I traced the problem down to kldstat(2). r182231 (DTrace > MFC) introduced a new version of kld_file_stat struct and added some > code to support the old version of the structure in kldstat(). In the > new code the old structure is known as kld_file_stat_1. Unfortunately > there's a bug in this code: kldstat() copies always sizeof(struct > kld_file_stat) of data to user space while it should copy sizeof(struct > kld_file_stat_1) when the old struct is used. > > This guy is probably suffering from this problem too: > http://lists.freebsd.org/pipermail/freebsd-questions/2008-September/182896.html > > I used this patch to fix the problem: > > %%% > Index: sys/kern/kern_linker.c > =================================================================== > --- sys/kern/kern_linker.c (revision 183486) > +++ sys/kern/kern_linker.c (working copy) > @@ -1199,7 +1199,12 @@ kldstat(struct thread *td, struct kldsta > > td->td_retval[0] = 0; > > - return (copyout(&stat, uap->stat, sizeof(struct kld_file_stat))); > + if (version_num == 1) > + return (copyout(&stat, uap->stat, > + sizeof(struct kld_file_stat_1))); > + else > + return (copyout(&stat, uap->stat, > + sizeof(struct kld_file_stat))); > } > > int > %%% This is what is in HEAD and should fix it: Index: kern_linker.c =================================================================== --- kern_linker.c (revision 183497) +++ kern_linker.c (working copy) @@ -1199,7 +1199,7 @@ td->td_retval[0] = 0; - return (copyout(&stat, uap->stat, sizeof(struct kld_file_stat))); + return (copyout(&stat, uap->stat, version)); } I will send in a request to MFC it in a second. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:53:43 2008 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 F3E59106568B; Tue, 30 Sep 2008 14:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 749098FC0A; Tue, 30 Sep 2008 14:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8UErRFf056950; Tue, 30 Sep 2008 10:53:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 10:50:40 -0400 User-Agent: KMail/1.9.7 References: <20080930101559.GA810@a91-153-122-179.elisa-laajakaista.fi> In-Reply-To: <20080930101559.GA810@a91-153-122-179.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301050.40828.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 30 Sep 2008 10:53:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8359/Tue Sep 30 09:29:02 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: mgass@unix.csbsju.edu, jb@freebsd.org, Jaakko Heinonen , stable@freebsd.org Subject: Re: DTrace MFC broke kldstat(2) on RELENG_7 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, 30 Sep 2008 14:53:43 -0000 On Tuesday 30 September 2008 06:15:59 am Jaakko Heinonen wrote: > > Hi, > > I recently noticed that kldstat(8) started to dump core for me on > RELENG_7. I traced the problem down to kldstat(2). r182231 (DTrace > MFC) introduced a new version of kld_file_stat struct and added some > code to support the old version of the structure in kldstat(). In the > new code the old structure is known as kld_file_stat_1. Unfortunately > there's a bug in this code: kldstat() copies always sizeof(struct > kld_file_stat) of data to user space while it should copy sizeof(struct > kld_file_stat_1) when the old struct is used. > > This guy is probably suffering from this problem too: > http://lists.freebsd.org/pipermail/freebsd-questions/2008-September/182896.html > > I used this patch to fix the problem: > > %%% > Index: sys/kern/kern_linker.c > =================================================================== > --- sys/kern/kern_linker.c (revision 183486) > +++ sys/kern/kern_linker.c (working copy) > @@ -1199,7 +1199,12 @@ kldstat(struct thread *td, struct kldsta > > td->td_retval[0] = 0; > > - return (copyout(&stat, uap->stat, sizeof(struct kld_file_stat))); > + if (version_num == 1) > + return (copyout(&stat, uap->stat, > + sizeof(struct kld_file_stat_1))); > + else > + return (copyout(&stat, uap->stat, > + sizeof(struct kld_file_stat))); > } > > int > %%% This is what is in HEAD and should fix it: Index: kern_linker.c =================================================================== --- kern_linker.c (revision 183497) +++ kern_linker.c (working copy) @@ -1199,7 +1199,7 @@ td->td_retval[0] = 0; - return (copyout(&stat, uap->stat, sizeof(struct kld_file_stat))); + return (copyout(&stat, uap->stat, version)); } I will send in a request to MFC it in a second. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:55:39 2008 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 C62AC1065689 for ; Tue, 30 Sep 2008 14:55:39 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 14C348FC19 for ; Tue, 30 Sep 2008 14:55:38 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 91394 invoked by uid 89); 30 Sep 2008 14:55:36 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 30 Sep 2008 14:55:36 -0000 Date: Tue, 30 Sep 2008 16:55:34 +0200 From: Oliver Lehmann To: Jeremy Chadwick Message-Id: <20080930165534.f49f9f17.lehmann@ans-netz.de> In-Reply-To: <20080930104827.GB44675@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, Bartosz Stec Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 14:55:39 -0000 Hi, Jeremy Chadwick wrote: > On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: > > Personally I'd rather bet on some hardware problem (overheating?) Try to > > install mbmon from ports. I had also similiar problems with old > > motherboards with swelled capacitors. > > Be careful with mbmon and healthd -- just because they compile and run > does not mean they're working properly (the values shown may be > completely unreliable/incorrect). > > It's best to check such things in the system BIOS, unless you have > absolute certainty that your motherboard is supported by mbmon/healthd. The systems chipset (440GX - board is http://www.intel.com/support/motherboards/server/l440gx/) is not supported by mbmon. All I can check is the temperature of the harddrives and they are between 30 - 45 °C. Which just means nothing for the CPUs ;) make world for example does not break the system down - I only encounter this during my tinderbox runs - who knows what stresses it then that much. I'll now make a kernel with all the debugging stuff in it... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 14:57:23 2008 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 C763D106568D for ; Tue, 30 Sep 2008 14:57:23 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 199768FC1A for ; Tue, 30 Sep 2008 14:57:22 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 91548 invoked by uid 89); 30 Sep 2008 14:57:21 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 30 Sep 2008 14:57:21 -0000 Date: Tue, 30 Sep 2008 16:57:19 +0200 From: Oliver Lehmann To: John Baldwin Message-Id: <20080930165719.3e41e45a.lehmann@ans-netz.de> In-Reply-To: <200809301047.29629.jhb@freebsd.org> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <200809301047.29629.jhb@freebsd.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 14:57:23 -0000 John Baldwin wrote: > (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. problem here is, that after some memory upgrade my swapspace is no longer bigh enough to cover the memory size. I'll try this as a last resort if the interactive work with kdb does not provide any help and will remove some memory before it then... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 15:35:05 2008 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 55E6B1065693 for ; Tue, 30 Sep 2008 15:35:05 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 91C9C8FC1D for ; Tue, 30 Sep 2008 15:35:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0928A45B36; Tue, 30 Sep 2008 17:11:53 +0200 (CEST) Received: from localhost (pjdwl.wheel.pl [10.0.1.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DE84C45C8C; Tue, 30 Sep 2008 17:11:38 +0200 (CEST) Date: Tue, 30 Sep 2008 17:11:51 +0200 From: Pawel Jakub Dawidek To: Kyryll A Mirnenko aka Mirya Message-ID: <20080930151151.GE2152@garage.freebsd.pl> References: <200809301454.47473.mirya@zoc.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xJK8B5Wah2CMJs8h" Content-Disposition: inline In-Reply-To: <200809301454.47473.mirya@zoc.com.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 30 Sep 2008 15:35:05 -0000 --xJK8B5Wah2CMJs8h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2008 at 02:54:45PM +0300, Kyryll A Mirnenko aka Mirya wrote: > I was using a GELI partition for /usr/home on 7.0, so it attaches and mou= nts=20 > on boot. The problem is it stopped working after the system was upgraded = to=20 > RELENG_7/7.1-PRERELEASE. Here's how it goes: >=20 > I have the following /etc/fstab: >=20 > /dev/ad0s1b none swap sw 0 0 > /dev/ad0s1a / ufs rw 1 1 > /dev/ad0s1d /tmp ufs rw 2 2 > /dev/ad0s1e /var ufs rw 2 2 > /dev/ad0s1f.eli /usr/home ufs rw 2 2 >=20 > After upgrading to 7.1 and rebooting: >=20 > ... > Configuring Disk Encryption for ad0s1f. > Enter passphrase: >=20 > geli: > Cannot access ad0s1f (error=3D1). Something keeps ad0s1f open, so geli cannot access it. Could you add somewhere 'sysctl -b kern.geom.confxml' (maybe to /etc/rc.d/geli script), so we can see how keeps ad0s1f open. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xJK8B5Wah2CMJs8h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFI4kG3ForvXbEpPzQRAgklAJ9lhGdUOLaZKDY9qHbcMdr4qWcSPgCfU46Z 6YsGmfqtoCHMTFYoGGqtFsU= =qIyG -----END PGP SIGNATURE----- --xJK8B5Wah2CMJs8h-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 15:53:12 2008 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 6FCB61065698 for ; Tue, 30 Sep 2008 15:53:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 13CBF8FC0C for ; Tue, 30 Sep 2008 15:53:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8UFr4pI057376; Tue, 30 Sep 2008 11:53:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 11:48:33 -0400 User-Agent: KMail/1.9.7 References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <200809301047.29629.jhb@freebsd.org> <20080930165719.3e41e45a.lehmann@ans-netz.de> In-Reply-To: <20080930165719.3e41e45a.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301148.33749.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 30 Sep 2008 11:53:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8359/Tue Sep 30 09:29:02 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Oliver Lehmann Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 15:53:12 -0000 On Tuesday 30 September 2008 10:57:19 am Oliver Lehmann wrote: > John Baldwin wrote: > > > (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. > > problem here is, that after some memory upgrade my swapspace is no longer > bigh enough to cover the memory size. I'll try this as a last resort if > the interactive work with kdb does not provide any help and will remove > some memory before it then... Turn on minidumps. minidumps don't dump all of memory (generally a lot, lot less). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 16:08:04 2008 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 AE5CE1065691 for ; Tue, 30 Sep 2008 16:08:04 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from zoc.com.ua (zoc.com.ua [82.144.212.13]) by mx1.freebsd.org (Postfix) with ESMTP id 578B18FC0A for ; Tue, 30 Sep 2008 16:08:03 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from [192.168.0.22] (port=64133) by zoc.com.ua with esmtp (Exim 4.62) (envelope-from ) id 1KkhlS-0005wl-E5; Tue, 30 Sep 2008 19:07:54 +0300 From: Kyryll A Mirnenko aka Mirya Organization: zoc To: "Artis Caune" Date: Tue, 30 Sep 2008 19:07:27 +0300 User-Agent: KMail/1.9.4 References: <200809301454.47473.mirya@zoc.com.ua> <9e20d71e0809300843k65c980e6xaf7d12fd917e18ee@mail.gmail.com> In-Reply-To: <9e20d71e0809300843k65c980e6xaf7d12fd917e18ee@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301907.27623.mirya@zoc.com.ua> X-CHECK-DB: NO Cc: freebsd-stable@freebsd.org Subject: Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 30 Sep 2008 16:08:04 -0000 On Tuesday 30 September 2008 18:43, Artis Caune wrote: > Try with hint.kbdmux.0.disabled="1" in loader.conf I've already tried that, but the passphrase is correct (and as from original email: the error message would be different if i simply mistiped it), looks like it's all about some bad combination of GEOM_ options in the kernel, i'm currently tring to guess what actually breaks the stuff. -- Regards, Mirya ICQ #313898202 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 16:12:43 2008 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 113051065688 for ; Tue, 30 Sep 2008 16:12:43 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id BF7D58FC13 for ; Tue, 30 Sep 2008 16:12:42 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so20413ywe.13 for ; Tue, 30 Sep 2008 09:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pSsqEC/KRvyIORAtOjED2APpZKxhUOgMWJxBIt2ljTI=; b=evhqQgL5MVoLXuMR5nWPh8Yn6+KANBKwKd73q0jjcyGEv8qS8zrTEYROnF7+TkbudK WC1QysxBNLEAYTqnt5FhLqtw4VYESW5ymgxQieOpkcE73KKAYf8NN5zVs9SHjbiY8DlR nnGfKj8JxmEThGeuhhnJFQdj4kTgRo9xNZvJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cwQCoEslvqAPaQawRFFrs8FdgIOYVllUXx5w7NpJnCTGXBp5gQfIOblHOBVQ3lXOmd I3CKlvYwa+ncR12KaPczKj8CNWm10AvEgPW1TXGE6T4/YeMWZmal44S506hUTiVYgplP n9+u8c+fPlNoVsmdEo9vQiwU/hQljJ10qZI3I= Received: by 10.100.112.6 with SMTP id k6mr6115938anc.71.1222789389032; Tue, 30 Sep 2008 08:43:09 -0700 (PDT) Received: by 10.100.253.17 with HTTP; Tue, 30 Sep 2008 08:43:08 -0700 (PDT) Message-ID: <9e20d71e0809300843k65c980e6xaf7d12fd917e18ee@mail.gmail.com> Date: Tue, 30 Sep 2008 18:43:08 +0300 From: "Artis Caune" To: "Kyryll A Mirnenko aka Mirya" In-Reply-To: <200809301454.47473.mirya@zoc.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809301454.47473.mirya@zoc.com.ua> Cc: freebsd-stable@freebsd.org Subject: Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 30 Sep 2008 16:12:43 -0000 On Tue, Sep 30, 2008 at 2:54 PM, Kyryll A Mirnenko aka Mirya wrote: > I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts > on boot. The problem is it stopped working after the system was upgraded to > RELENG_7/7.1-PRERELEASE. Here's how it goes: Try with hint.kbdmux.0.disabled="1" in loader.conf I have same problem with laptop and also with 6.x whaen it's happened randomly. Try with 'set kern.geom.eli.visible_passphrase=1' and you will see some characters are repeated twice when you press it only once, some are lost. There was some locking issue, and I think it's fixed in current. -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 16:16:40 2008 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 A8DAE10656A9 for ; Tue, 30 Sep 2008 16:16:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5488FC36 for ; Tue, 30 Sep 2008 16:16:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 9529846B03; Tue, 30 Sep 2008 12:16:38 -0400 (EDT) Date: Tue, 30 Sep 2008 17:16:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: George Mamalakis In-Reply-To: <48E21BD9.1080101@eng.auth.gr> Message-ID: References: <48E1EBE1.50206@eng.auth.gr> <48E21BD9.1080101@eng.auth.gr> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org Subject: Re: jails and mac_seeotheruids problems in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 16:16:40 -0000 On Tue, 30 Sep 2008, George Mamalakis wrote: > It works like a charm! Thank you very much for your time and help, No problem -- I've gone ahead and committed that change to stable/6. If you're able to test 6.4RC1 when it comes out to confirm that the fix works there as desired, that would be most helpful. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > regards, > > > Robert Watson wrote: >> >> On Tue, 30 Sep 2008, George Mamalakis wrote: >> >>> I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them >>> is running 7-STABLE. All three have services running in jails. I noticed a >>> very peculiar behavior in 6-STABLE when I set the sysctl >>> security.mac.seeotheruids.enabled=1. The root user in my jails was not >>> able to see processes and sockets owned by other users of the same jail, >>> whereas the root user of the host system could see every process (thank >>> the Almighty). The same behavior does not apply on the server running >>> 7-STABLE. >>> >>> In one sense it is more secure, since the root user in a jail is not as >>> "strong" as the root user should be in a UNIX system. On the other hand, >>> the root user looses its purpose of existence, which I suppose is a bug. >>> >>> Below are the security.mac sysctl settings of both 6 and 7-STABLE: >> >> Could you try modifying >> src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that >> the call to suser_cred() in mac_seeotheruids_check() passes the >> SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're >> experiencing. Let me know and I can merge that change to 6.x. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> 6-STABLE: >>> >>> security.mac.max_slots: 4 >>> security.mac.enforce_network: 1 >>> security.mac.enforce_pipe: 1 >>> security.mac.enforce_posix_sem: 1 >>> security.mac.enforce_suid: 1 >>> security.mac.mmap_revocation_via_cow: 0 >>> security.mac.mmap_revocation: 1 >>> security.mac.enforce_vm: 1 >>> security.mac.enforce_process: 1 >>> security.mac.enforce_socket: 1 >>> security.mac.enforce_system: 1 >>> security.mac.enforce_kld: 1 >>> security.mac.enforce_sysv_msg: 1 >>> security.mac.enforce_sysv_sem: 1 >>> security.mac.enforce_sysv_shm: 1 >>> security.mac.enforce_fs: 1 >>> security.mac.seeotheruids.specificgid: 0 >>> security.mac.seeotheruids.specificgid_enabled: 0 >>> security.mac.seeotheruids.primarygroup_enabled: 0 >>> security.mac.seeotheruids.enabled: 1 >>> security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 >>> security.mac.portacl.port_high: 1023 >>> security.mac.portacl.autoport_exempt: 1 >>> security.mac.portacl.suser_exempt: 1 >>> security.mac.portacl.enabled: 1 >>> >>> >>> 7-STABLE: >>> >>> security.mac.max_slots: 4 >>> security.mac.version: 3 >>> security.mac.mmap_revocation_via_cow: 0 >>> security.mac.mmap_revocation: 1 >>> security.mac.seeotheruids.specificgid: 0 >>> security.mac.seeotheruids.specificgid_enabled: 0 >>> security.mac.seeotheruids.suser_privileged: 1 >>> security.mac.seeotheruids.primarygroup_enabled: 0 >>> security.mac.seeotheruids.enabled: 1 >>> >>> I would be very glad if someone could inform me whether I am doing >>> something wrong; if not I think I should inform FreeBSD about this bug. >>> >>> Thank you guys in advance, >>> >>> -- >>> George Mamalakis >>> >>> IT Officer >>> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >>> MSc (Imperial College of London) >>> >>> Department of Electrical and Computer Engineering >>> Faculty of Engineering >>> Aristotle University of Thessaloniki >>> >>> phone number : +30 (2310) 994379 >>> >>> _______________________________________________ >>> 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" >>> > > -- > George Mamalakis > > IT Officer > Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), > MSc (Imperial College of London) > > Department of Electrical and Computer Engineering > Faculty of Engineering > Aristotle University of Thessaloniki > > phone number : +30 (2310) 994379 > > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 16:51:49 2008 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 C0E951065687; Tue, 30 Sep 2008 16:51:49 +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 98DED8FC21; Tue, 30 Sep 2008 16:51:49 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1KkiRw-000PId-6Z; Tue, 30 Sep 2008 12:51:48 -0400 Date: Tue, 30 Sep 2008 12:51:48 -0400 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20080930165148.GG60230@in-addr.com> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080930104605.GA44675@icarus.home.lan> Cc: Holger Kipp , stable@freebsd.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 30 Sep 2008 16:51:49 -0000 On Tue, Sep 30, 2008 at 03:46:05AM -0700, Jeremy Chadwick wrote: > > - email (imap) > > I've had good experience with dovecot; I tend to stay away from Cyrus > products (disgusting code with a history of security issues), and > Courier (no interest). Also avoid /usr/ports/mail/imap-uw. I'm not sure if it can be configured to do otherwise, but by default it turns every file in the users home directory into an IMAP folder which can be opened and read. It might sound fine, but if you ever want to migrate off onto something else it becomes an issue. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 17:48:03 2008 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 37F551065686 for ; Tue, 30 Sep 2008 17:48:03 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id C3BD78FC12 for ; Tue, 30 Sep 2008 17:48:02 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id m8UHW2Mp032363; Tue, 30 Sep 2008 19:32:03 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 7E052BA84; Tue, 30 Sep 2008 19:32:02 +0200 (CEST) Date: Tue, 30 Sep 2008 19:32:02 +0200 From: Roland Smith To: Kyryll A Mirnenko aka Mirya Message-ID: <20080930173202.GA16426@slackbox.xs4all.nl> References: <200809301454.47473.mirya@zoc.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <200809301454.47473.mirya@zoc.com.ua> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 30 Sep 2008 17:48:03 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2008 at 02:54:45PM +0300, Kyryll A Mirnenko aka Mirya wrote: > I was using a GELI partition for /usr/home on 7.0, so it attaches and mou= nts=20 > on boot. The problem is it stopped working after the system was upgraded = to=20 > RELENG_7/7.1-PRERELEASE.=20 My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE (updated september 25th). I've been tracking stable since 7.0-RELEASE without problems.=20 My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO options are also part of the kernel. As far as I can see, the geli scripts in /etc/rc.d haven't changed in over a year. HTH, Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjiYpIACgkQEnfvsMMhpyW27QCgnm1FbULhvhsoaytpiKHXdk/G Ne8AoIw3RqMdGF5WxQXRrpGyC7uT7Buz =fVPW -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 19:00:31 2008 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 75E701065690; Tue, 30 Sep 2008 19:00:31 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 263028FC08; Tue, 30 Sep 2008 19:00:30 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m8UJ0Ups047244; Tue, 30 Sep 2008 12:00:30 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m8UJ0Ui2047243; Tue, 30 Sep 2008 12:00:30 -0700 (PDT) Date: Tue, 30 Sep 2008 12:00:30 -0700 (PDT) From: Matthew Dillon Message-Id: <200809301900.m8UJ0Ui2047243@apollo.backplane.com> To: Jeremy Chadwick References: <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> <200809291744.m8THiBlR034739@apollo.backplane.com> <20080930053619.GA37286@icarus.home.lan> Cc: freebsd-stable@FreeBSD.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 30 Sep 2008 19:00:31 -0000 :The topic of BIO_FLUSH is something I got to thinking about last night :at work; the only condition where a disk with write caching enabled :*would not* fully write the data to the platter would in fact be power :loss. All other conditions (specifically soft reset and panic) should :not require explicit flushing. : :I wonder why this is being done, especially on shutdown of FreeBSD. :Assuming I understand it correctly, I'm talking about this: : :Waiting (max 60 seconds) for system process `bufdaemon' to stop...done :Waiting (max 60 seconds) for system process `syncer' to stop... :Syncing disks, vnodes remaining...3 3 3 2 2 0 0 done :All buffers synced. : :-- :| Jeremy Chadwick jdc at parodius.com | BIO_FLUSH and "Syncing disks, vnodes ..." are two different things, so I'm not sure of the context but I will describe issues with both. -- BIO_FLUSH commands the disk firmware to flush out any dirty buffers in its drive cache. That is, writes that you have *already* issued to the drive and which returned completion, but which have not actually made it to the physical media yet. This is different from dirty buffers still being maintained by the kernel which have not yet been sent to the drive. (Just repeating this so the definition is clear to all the readers). So, yes, you would want to do a BIO_FLUSH before powering down a machine (halt -p) to ensure that all the dirty data you sent to the disk actually gets to the platter. I think you also want to issue it for a soft reset. It would not effect a SATA drive but it certainly would effect a USB drive powered from the computer. USB ports will be powered down during a soft reset. BIO_FLUSH isn't likely to cause problems during a crash, unlike flushing the buffer cache. Some people may remember earlier versions of Windows XP often powered the machine down before the hard drive managed to write all of its data to the platter. Sometime that would even destroy sectors on the drive. We know bad things happen if we don't issue the command, so best not to take chances by making assumptions. -- The "Syncing disks, vnodes ..." is the kernel flushing out any dirty data in the buffer cache which has not yet been sent to the disk driver. This is more problematic. Filesystems such as HAMMER (and presumably ZFS) absolutely do NOT want the system to flush dirty buffers unless they explicitly give permission to do so, because the dirty buffers might represent data for which the recovery information has not yet been written out, and thus can corrupt the filesystem on-media if a crash were to occur right then. In HAMMER's case I enchanced the bioops a bit to allow HAMMER to veto write-outs initiated by the system. sync_on_panic is irrelevant, the buffers will not be synced without HAMMER's permission and it won't give it. There is also the very real general case where a traditional filesystem such as UFS must peform multiple buffer cache ops, dirtying multiple buffer cache buffers, in order to complete an operation. If a crash were to occur right in the middle of such a sequence the kernel would wind up writing dirty buffers related to incomplete operations to the media, resulting in corruption. In the case of softupdates one is presented with a conundrum. If you don't write out the buffer cache during a crash you stand to lose a lot more then 60 seconds worth of changes due to deep dependancy chains. One 'sync' doesn't do the job and even though it is supposed to get all the primary data and meta-data onto the disk and just leave the bitmap updates for background operations it doesn't always seem to do that. The softupdates code is very fragile. On the other hand, if you *DO* try to write out the buffer cache during a crash you have a good chance of deadlocking the system or double-panicing, resulting in inconsistencies on the media, and you risk doing a partial write out also resulting in inconsistencies on the media. Here is example: How does the crash code deal with dirty but locked buffer cache buffers? Say you have a softupdates filesystem and through the course of operations you dirty a dozen buffers, then a crash occurs while you are in the middle of ANOTHER softupdates operation which is holding several buffers already dirtied by previous operations locked. What happens now if the crash code tries to sync the buffer cache? Will it sync the previously dirtied buffers that are currently locked? Will it sync the ones that haven't been locked but skip the ones that are locked? You lose both ways. There is no way to safely sync ANYTHING, whether locked or not, without risking unexpected softupdates inconsistencies on-media. This alone makes background fsck problematic and risky. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 19:07:09 2008 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 C91D91065694 for ; Tue, 30 Sep 2008 19:07:09 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp153.sat.emailsrvr.com (smtp153.sat.emailsrvr.com [66.216.121.153]) by mx1.freebsd.org (Postfix) with ESMTP id A8B6F8FC08 for ; Tue, 30 Sep 2008 19:07:09 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from relay5.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 742A8258AFE; Tue, 30 Sep 2008 15:07:08 -0400 (EDT) Received: by relay5.relay.sat.mlsrvr.com (Authenticated sender: henrik-AT-ecwwebworks.com) with ESMTP id 730CA258057; Tue, 30 Sep 2008 15:06:33 -0400 (EDT) From: Henrik Hudson To: freebsd-stable@freebsd.org Date: Tue, 30 Sep 2008 11:06:27 -0800 User-Agent: KMail/1.9.7 References: <200809291955.21461.lists@rhavenn.net> <3a142e750809300223p529caafle7f02a58524abc18@mail.gmail.com> In-Reply-To: <3a142e750809300223p529caafle7f02a58524abc18@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809301106.27666.lists@rhavenn.net> Cc: "Paul B. Mahol" Subject: Re: wpi driver freeze on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@rhavenn.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 19:07:09 -0000 On Tuesday 30 September 2008, "Paul B. Mahol" sent a missive stating: > On 9/30/08, Henrik Hudson wrote: > > I've got a HP dv8000 laptop. Setting up the wpi driver for wireless > > freezes the system on boot with the following error: > > > > wpi0 requested unsupported memory range > > wpi0: could not allocate memory resource > > > > It lists a pcbi device (pcbi4 i think) and an actual memory range, but > > since I > > have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the > > info. Is there anyway to grab the info when it freezes when it reboots? > > Perhaps, entering single-user mode. Nope. Disable ACPI, safe-mode and single user don't help at all. > Add this lines to your kernel to help debug problem. > > makeoptions DEBUG=-g > options KDB > options DDB > options GDB > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN This doesn't really add anything to the output near the wpi freeze and I still can't get to the actual message, since when I reboot it wipes it out. Any other isolation steps or ways to get detailed info to at least a cut and pastable state? Henrik -- Henrik Hudson lists@rhavenn.net ------------------------------ "God, root, what is difference?" Pitr; UF (http://www.userfriendly.org/) From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 20:03:00 2008 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 8EF28106568F for ; Tue, 30 Sep 2008 20:03:00 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 612A38FC15 for ; Tue, 30 Sep 2008 20:03:00 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so161286rvf.43 for ; Tue, 30 Sep 2008 13:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8vgIbWl1iWZ7nbkr97ws8GL0be/LpzWTAkZ+hr9pXjU=; b=owahFlCGgoL9AVTRr/cwdzbtg2ndcRT41qsdVi7sqNBvih1yiiMLB0MoMCDEx66vIJ 4EoieZjwiVYsiz5rz2TkQUJuXYIMgSDrWDtSZoZpbgWhQPyhSsnQfAjOxGo3Q1F3XDgC OHtYRNS5RdSeI9rGsCWTM/as4pQFvIFPXq3Xs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=h1Ey5bGJ+wBB3STpGG15mWzxjbYCMPui3Qe4CGI8MFlyijKmaHfwO5klAvdljSxngt 5ZWcAXg2sclfOs9iVYdSDbfJAybTKYM8E071G5EtMmSvztPEnzd5OXgFyCLEnuwGMeTH aYN/T0TuWlEG5LZtPpTE8JG6DkGJKdTozDDN4= Received: by 10.140.163.12 with SMTP id l12mr3821819rve.137.1222804979584; Tue, 30 Sep 2008 13:02:59 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Tue, 30 Sep 2008 13:02:59 -0700 (PDT) Message-ID: <3a142e750809301302l330f517dwe9e5a6bbd272c68e@mail.gmail.com> Date: Tue, 30 Sep 2008 22:02:59 +0200 From: "Paul B. Mahol" To: lists@rhavenn.net In-Reply-To: <200809301106.27666.lists@rhavenn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809291955.21461.lists@rhavenn.net> <3a142e750809300223p529caafle7f02a58524abc18@mail.gmail.com> <200809301106.27666.lists@rhavenn.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpi driver freeze on boot 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, 30 Sep 2008 20:03:00 -0000 On 9/30/08, Henrik Hudson wrote: > On Tuesday 30 September 2008, "Paul B. Mahol" sent a > missive stating: >> On 9/30/08, Henrik Hudson wrote: >> > I've got a HP dv8000 laptop. Setting up the wpi driver for wireless >> > freezes the system on boot with the following error: >> > >> > wpi0 requested unsupported memory range >> > wpi0: could not allocate memory resource >> > >> > It lists a pcbi device (pcbi4 i think) and an actual memory range, but >> > since I >> > have to reboot using kernel.old the /var/run/dmesg.boot is wiped with >> > the >> > info. Is there anyway to grab the info when it freezes when it reboots? >> >> Perhaps, entering single-user mode. > > Nope. Disable ACPI, safe-mode and single user don't help at all. Ah, I see it, there is no way to look dmesg output in that way because it was never actually saved. >> Add this lines to your kernel to help debug problem. >> >> makeoptions DEBUG=-g >> options KDB >> options DDB >> options GDB >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options WITNESS_SKIPSPIN > > This doesn't really add anything to the output near the wpi freeze and I > still This one should put you into kdb when system panics, from where you could post output of bt. > can't get to the actual message, since when I reboot it wipes it out. Any > other isolation steps or ways to get detailed info to at least a cut and > pastable state? In that case you need to enter to kdb as soon as possible during boot, and sidestep each boot instruction until something bad happens, .... well it is not trivial task at all. For more info you may read developers-hanbook. (Located in /usr/share/doc/en/books/) From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 21:43:24 2008 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 E4DF71065686 for ; Tue, 30 Sep 2008 21:43:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6038FC23 for ; Tue, 30 Sep 2008 21:43:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA04.westchester.pa.mail.comcast.net with comcast id M2XS1a0010mv7h0549jPf3; Tue, 30 Sep 2008 21:43:23 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.westchester.pa.mail.comcast.net with comcast id M9j51a0064v8bD73X9j5cV; Tue, 30 Sep 2008 21:43:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=QyXUC8HyAAAA:8 a=h3jrFwpMAAAA:8 a=QycZ5dHgAAAA:8 a=1sxjICzKQYnBB12ymawA:9 a=cjDVd6NyhcBTEmC_xlsA:7 a=eYaP5NnOAy7y8tLZLE4I7Le_Z0oA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D5440C9419; Tue, 30 Sep 2008 14:43:21 -0700 (PDT) Date: Tue, 30 Sep 2008 14:43:21 -0700 From: Jeremy Chadwick To: Oliver Lehmann Message-ID: <20080930214321.GA57024@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080930165534.f49f9f17.lehmann@ans-netz.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Bartosz Stec Subject: Re: system hangup - I'm lost 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, 30 Sep 2008 21:43:25 -0000 On Tue, Sep 30, 2008 at 04:55:34PM +0200, Oliver Lehmann wrote: > Hi, > > Jeremy Chadwick wrote: > > > On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: > > > Personally I'd rather bet on some hardware problem (overheating?) Try to > > > install mbmon from ports. I had also similiar problems with old > > > motherboards with swelled capacitors. > > > > Be careful with mbmon and healthd -- just because they compile and run > > does not mean they're working properly (the values shown may be > > completely unreliable/incorrect). > > > > It's best to check such things in the system BIOS, unless you have > > absolute certainty that your motherboard is supported by mbmon/healthd. > > The systems chipset (440GX - board is > http://www.intel.com/support/motherboards/server/l440gx/) is not > supported by mbmon. All I can check is the temperature of the harddrives > and they are between 30 - 45 C. Which just means nothing for the CPUs ;) The chipset rarely matters (I've yet to encounter any PC chipset that natively handles full fan, voltage, and temperature monitoring), but the motherboard model can tell me a lot. :-) Boards have to include an external H/W monitoring IC (such as one from National Semiconductor (LMxx), AMD, or Winbond), have thermistors placed around the board, and have the H/W IC tied into the ISA or SMBus. Sometimes the H/W monitoring IC also acts as a super I/O chip (which means it handles serial, parallel, keyboard, mouse, and floppy disks -- and sometimes IDE). I can't find anything on Intel's site that clues me in; all the PDFs are vague as far as what chips are on the board. I tried searching for a high-resolution photo of the L440GX on Google Images, but I find none which are sharp/clear enough. The best I could find was this: http://bbs.yjfy.com/UploadFile/2008-2/20082818545062073.jpg I see Intel northbridge and southbridges, a Cirrus Logic (VGA?) chip, an Intel flash chip (probably for CMOS), and an Intel NIC. Four chips I don't recognise are an Intel chip on the far right, a mystery chip at the bottom of the board (can't make out company logo), and two chips with "E" in their company logo (right of PCI slots). Possibly one of these handles H/W monitoring. If you can reboot the system and go into the BIOS, see if you can find anything that looks remotely like CPU and system temperatures, as well as voltages. If there's no such menu, the board likely has no support for such. P.S. -- You're the 2nd person I've encountered in under a week who's using 440BX/GX-based hardware in present day. I would not be surprised if the board is simply going bad/failing due to age. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 22:01:43 2008 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 47561106568F for ; Tue, 30 Sep 2008 22:01:43 +0000 (UTC) (envelope-from fernan.aguero@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 68CA18FC31 for ; Tue, 30 Sep 2008 22:01:42 +0000 (UTC) (envelope-from fernan.aguero@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so88531eyi.7 for ; Tue, 30 Sep 2008 15:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=dusyJFXPeRBKMJ1iBtD+sutoG+si6xiwdBKaketfmDk=; b=txTSg0QPVn7m1iFyIl91Zni9T2Jri02OGabmNCakw4jJESxRLvCJkSqOaQrp4CAh1u kPvDapfjdNBpIBmyMYsoQEZYN/EB92QNYzpxEUJT+UX9Fq4uuNpFzBQPRUO9/iNbyrrY B9w+j33hysQqmwWnaFcW4nnXctN/2EHSZNFEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=WsnrFQ7VzzwMEZusSKh03F+vZSGYUrsm/sM+FtGdHt5EoWBS+Qcm9Ew2v47/llhyO+ VThpagU6Za2vjMF1TVirOet7fT6Xyt/tr1As3WlhfsUQPBj9Ia/DLG5h4pbkE8+hz0H8 GHl4/VNQ69cLKsktzgZJFM6HP+yEs+cltg9NY= Received: by 10.210.17.14 with SMTP id 14mr8602724ebq.1.1222810444994; Tue, 30 Sep 2008 14:34:04 -0700 (PDT) Received: by 10.210.135.1 with HTTP; Tue, 30 Sep 2008 14:34:04 -0700 (PDT) Message-ID: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> Date: Tue, 30 Sep 2008 18:34:04 -0300 From: "Fernan Aguero" Sender: fernan.aguero@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 2500744b6f044c66 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 30 Sep 2008 22:01:43 -0000 Hi, I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which I'd like to try installing FreeBSD. I've already failed to make 7.0 work on this box and was wondering if you have information about the behavior of the upcoming 7.1 on this hardware. I've been following the "HT1000 chipset errata saga" thread, and the commits by sos@ to CVS (around Jan 2008), but have not seen other more recent posts about this issue ... is it because it's already fixed and working fine for everyone? http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Thanks in advance for any update on this, -- fernan From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 22:56:42 2008 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 C261B1065689 for ; Tue, 30 Sep 2008 22:56:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD128FC0A for ; Tue, 30 Sep 2008 22:56:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id M1RT1a0090vyq2s59Awh4g; Tue, 30 Sep 2008 22:56:41 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.westchester.pa.mail.comcast.net with comcast id MAwg1a00J4v8bD73RAwhR1; Tue, 30 Sep 2008 22:56:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=4BG5oNr0TW4A:10 a=zBfqvZn8nFgA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=AfZRL7bedDh4yfUqN2kA:9 a=Erdg3Z9whjMBGS3kJ0sFXypVG5wA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5E4A8C9419; Tue, 30 Sep 2008 15:56:40 -0700 (PDT) Date: Tue, 30 Sep 2008 15:56:40 -0700 From: Jeremy Chadwick To: Fernan Aguero Message-ID: <20080930225640.GA58895@icarus.home.lan> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 30 Sep 2008 22:56:42 -0000 On Tue, Sep 30, 2008 at 06:34:04PM -0300, Fernan Aguero wrote: > I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which > I'd like to try installing FreeBSD. I've already failed to make 7.0 > work on this box and was wondering if you have information about the > behavior of the upcoming 7.1 on this hardware. Why don't you try a 7.1-PRERELEASE ISO and see if it works for you? ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/200809/ > I've been following the "HT1000 chipset errata saga" thread, and the > commits by sos@ to CVS (around Jan 2008), but have not seen other more > recent posts about this issue ... is it because it's already fixed and > working fine for everyone? > > http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Wow; the 2nd URL there is major/huge. I feel sorry for anyone having to deal with this problem. I'll update my Wiki page to reflect this data; thanks for bringing it (indirectly) to my attention. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 23:40:18 2008 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 896591065697; Tue, 30 Sep 2008 23:40:18 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAA98FC19; Tue, 30 Sep 2008 23:40:18 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id EEF22D0066; Tue, 30 Sep 2008 13:40:14 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 307B8153882; Tue, 30 Sep 2008 13:40:14 -1000 (HST) Date: Tue, 30 Sep 2008 13:40:14 -1000 From: Clifton Royston To: Gary Palmer Message-ID: <20080930234013.GL3884@lava.net> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <20080930165148.GG60230@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080930165148.GG60230@in-addr.com> User-Agent: Mutt/1.4.2.2i Cc: Holger Kipp , Jeremy Chadwick , stable@freebsd.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 30 Sep 2008 23:40:18 -0000 On Tue, Sep 30, 2008 at 12:51:48PM -0400, Gary Palmer wrote: > On Tue, Sep 30, 2008 at 03:46:05AM -0700, Jeremy Chadwick wrote: > > > - email (imap) > > > > I've had good experience with dovecot; I tend to stay away from Cyrus > > products (disgusting code with a history of security issues), and > > Courier (no interest). > > Also avoid /usr/ports/mail/imap-uw. Performance on imap-uw is lousy also. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Sep 30 23:51:50 2008 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 54EAD1065689 for ; Tue, 30 Sep 2008 23:51:50 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 045758FC16 for ; Tue, 30 Sep 2008 23:51:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id m8UNpkSw073873; Tue, 30 Sep 2008 19:51:46 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m8UNpjs7024916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 19:51:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809302351.m8UNpjs7024916@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Sep 2008 19:51:41 -0400 To: "Fernan Aguero" , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.co m> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 30 Sep 2008 23:51:50 -0000 At 05:34 PM 9/30/2008, Fernan Aguero wrote: >I've been following the "HT1000 chipset errata saga" thread, and the >commits by sos@ to CVS (around Jan 2008), but have not seen other more >recent posts about this issue ... is it because it's already fixed and >working fine for everyone? > >http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Yes, we ran into this yesterday on a fresh install using the 7.1 beta CD as it was set to PATA mode by accident. Also, on some earlier BIOS revs, we had to turn off "enable USB legacy mode" as well as "EHCI handoff". By default we set those to disabled as it seems to sometimes create a high interrupt load on the USB bus if its enabled. If you forget to set the mode to SATA, the dmesg will look like Sep 30 13:37:08 dev2 kernel: ad4: DMA limited to UDMA33, device found non-ATA66 cable Sep 30 13:37:08 dev2 kernel: ad4: 152627MB at ata2-master UDMA33 and you will indeed get corruption Turning onto normal SATA mode in the BIOS, you should see Sep 30 16:14:15 dev2 kernel: ad4: 152627MB at ata2-master SATA150 ... And everything works great. atapci0@pci0:1:14:0: class=0x010405 card=0x024a1166 chip=0x024a1166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5785 (HT1000) SATA Native SATA Mode' class = mass storage subclass = RAID cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split transactions cap 01[90] = powerspec 2 supports D0 D3 current D0 cap 05[a0] = MSI supports 1 message Start with ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 00:25:44 2008 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 36047106568E for ; Wed, 1 Oct 2008 00:25:44 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id B5F368FC14 for ; Wed, 1 Oct 2008 00:25:43 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so201106fgb.35 for ; Tue, 30 Sep 2008 17:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NUVfyAtKk2Vlte0AsIrj0Nx0Xjd8EhXYbov7+uv6+VM=; b=blAhaolLsdZrwCU4qq5ufIGx5orQ78nlpWLgzlwqb2JUWPbt+Ym81yLiz9Wk3LRQDy cFC/e1th+hrVG0oomWJflECDksYHUn2HQDet2RLQE/qhqybQAIilB7xGHhyIVtl31LT4 ERtH0e5JFuYEqQL16E+CSz8NFlgcRC5isMAp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bjAVo06hfNHK7b+5Pf3hPQDFZ3cZ33K+IlWO9+y2IvESf8QrQdfjfP23t32Fzjoxl5 tz0MwJqrudj6aRcHPHgjl5msq51pQaB8zSCAxldM6pGzHfscKuUWlpPiUTFxAXW5TVId VM5QeJD1MYbSItZHtJdHq4YPY6bryaGmtLv0U= Received: by 10.86.82.16 with SMTP id f16mr6399560fgb.9.1222818834895; Tue, 30 Sep 2008 16:53:54 -0700 (PDT) Received: by 10.86.25.10 with HTTP; Tue, 30 Sep 2008 16:53:54 -0700 (PDT) Message-ID: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Date: Wed, 1 Oct 2008 07:53:54 +0800 From: lhmwzy To: freebsd-stable@freebsd.org In-Reply-To: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 00:25:44 -0000 I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml http://www.dragonflybsd.org/hammer/hammer.pdf From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 00:57:08 2008 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 CBC351065686 for ; Wed, 1 Oct 2008 00:57:08 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 57E2C8FC14 for ; Wed, 1 Oct 2008 00:57:08 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so103726eyi.7 for ; Tue, 30 Sep 2008 17:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2Bhm51C6SOiixkUEj3g7lW6f5DpJTGdvzXoXqm2YZPI=; b=cXNr+IyF8A6GpAdsu12b06+9Mqhl4cbyjMAhvtBdr9v6yEo7YITF4sNbhtkkv5Hwzp UnHtf7n4ZRcLBQXxghJARretATmx9lPoqxJlwDM70fEIh4aqjsCTXCJREE5Q4LhF8iOH UuS83y69124SMCara6glw4sDFH6vURS6aoBkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lt7S/26Lqc6oipfsJqCSY4zUB2GH/pHZEjquZ1ey+VGwL0vIolDBClz8il7TgA7C5v InCt6+rLS9Pto4K+ZCG3wpoV9CDhapnS4LuHGm8dswoQeEIaJ+Ruc5lOKDJe5AYIVB6O le/Q82jL+zK4nzWJjOFBMKPk/3l5ZkEPBMGMg= Received: by 10.103.244.19 with SMTP id w19mr5379517mur.68.1222822626907; Tue, 30 Sep 2008 17:57:06 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Tue, 30 Sep 2008 17:57:06 -0700 (PDT) Message-ID: Date: Tue, 30 Sep 2008 21:57:06 -0300 From: "Carlos A. M. dos Santos" To: lhmwzy In-Reply-To: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 00:57:08 -0000 On Tue, Sep 30, 2008 at 8:53 PM, lhmwzy wrote: > I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. > Would anybody do this? > I do not have the skill or I will do this.:) > links: http://www.dragonflybsd.org/hammer/index.shtml > http://www.dragonflybsd.org/hammer/hammer.pdf > _______________________________________________ > 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" > Do you subscribe freebsd-stable? This has bee discussed recently in this list: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html -- cd /usr/ports/sysutils/life make clean From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 01:30:00 2008 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 CA3381065687 for ; Wed, 1 Oct 2008 01:30:00 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id 75BA58FC12 for ; Wed, 1 Oct 2008 01:30:00 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so119246rne.12 for ; Tue, 30 Sep 2008 18:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=qxVBBdjAVEkE9+DHt+I2+yKOOlHiUZrO/cLbJEPl7LA=; b=Ri/V4E5vbz29+mOfPvLy3+2PfaDZAI4zFcGlUtGILUvwEpJKrmUBMl4z1t8Ix/I/Y2 p7+KuDOB4DHkjbxY28LLXHUBqVVjAMuBLjy08twpMwI7DGeiLyRuMlIbrpJ7p+sRWg7B WGoWeZ2Zf480Slp1Xi98VmMFR+0QQs6G2yqWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Ra0M3pml4jX3ayt0nQCbcYifEUPdFtZ4zLAdDfWVGKq7aYErvBzP4DkXnjN6fAmgwk IltQY2vZqgXnr9aR9aXYEUiVLkXc1bMD4Iv4jyXysiE2CYhVHoqQEAQUrx8hfhup9wkr fTBLdByJf2QamAU+CK2AEmXmuPJJvvDJBRm88= Received: by 10.90.33.5 with SMTP id g5mr8147778agg.115.1222823124421; Tue, 30 Sep 2008 18:05:24 -0700 (PDT) Received: by 10.90.51.19 with HTTP; Tue, 30 Sep 2008 18:05:24 -0700 (PDT) Message-ID: <19e9a5dc0809301805s5a83b594q19eceac5ac79906d@mail.gmail.com> Date: Wed, 1 Oct 2008 03:05:24 +0200 From: "Gonzalo Nemmi" To: freebsd-stable@freebsd.org In-Reply-To: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> MIME-Version: 1.0 References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 01:30:01 -0000 On Wed, Oct 1, 2008 at 1:53 AM, lhmwzy wrote: > I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. > Would anybody do this? > I do not have the skill or I will do this.:) > links: http://www.dragonflybsd.org/hammer/index.shtml > http://www.dragonflybsd.org/hammer/hammer.pdf > I've been wanting to ask the same question since July 6, 2008 ... http://leaf.dragonflybsd.org/mailarchive/kernel/2008-07/msg00015.html ... specially in the light of the all the effort that went (and goes on) on ZFS ... I, for once, don't care at all about ZFS, but would really like to see HAMMER ported over to FreeBSD (just as much as I'd like to see sysctl hw.sensors framework or so called framework... whereas it comes from Murenin's code or from code with a more "FreeBSD feel to it" .. or from a better implementation or solution or unameit). But I'm still too new to FreeBSD ... Would really like to see some resources redirected in HAMMER fs direction though ... -- Blessings Gonzalo Nemmi From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 01:44:00 2008 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 9DA89106568D for ; Wed, 1 Oct 2008 01:44:00 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E86C8FC0C for ; Wed, 1 Oct 2008 01:44:00 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m911i09C051465 for ; Tue, 30 Sep 2008 18:44:00 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m911i0Nw051464; Tue, 30 Sep 2008 18:44:00 -0700 (PDT) Date: Tue, 30 Sep 2008 18:44:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200810010144.m911i0Nw051464@apollo.backplane.com> To: freebsd-stable@freebsd.org References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <19e9a5dc0809301805s5a83b594q19eceac5ac79906d@mail.gmail.com> Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 01:44:00 -0000 Guys, please don't start a flamewar. And lhmwzy we discussed this on the DFly lists. It's really up to them... that is, a programmer who has an interest, inclination, and time. It isn't really fair to try to push it. I personally believe that the FreeBSD community as a whole should focus on ZFS for now. It has the momentum and the most interest on their lists. -Matt From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 04:53:14 2008 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 25CC1106568A for ; Wed, 1 Oct 2008 04:53:14 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 771DC8FC1A for ; Wed, 1 Oct 2008 04:53:12 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 43518 invoked by uid 89); 1 Oct 2008 04:53:10 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 1 Oct 2008 04:53:10 -0000 Date: Wed, 1 Oct 2008 06:53:09 +0200 From: Oliver Lehmann To: Jeremy Chadwick Message-Id: <20081001065309.3e7e108e.lehmann@ans-netz.de> In-Reply-To: <20080930214321.GA57024@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Bartosz Stec Subject: Re: system hangup - I'm lost 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, 01 Oct 2008 04:53:14 -0000 Jeremy Chadwick wrote: > I can't find anything on Intel's site that clues me in; all the PDFs > are vague as far as what chips are on the board. Have you tried the Product specifications? http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf Beginning on page 33 (43 of the pdf) It has 3 different Server Management busses. the temperature part is handled within a Baseboard Management Controller. This BMC is implemented using a DS82CL10. Because it is a Server Board it offers a lot of managing features and other nice things like serial console at bootup and system monitoring features... but all unsupported withn FreeBSDs software ;) > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) Hm - I'd wonder if this would be the case. I mean I'm using older hardware (Tyan Tsunami S1830S, PII300, DAC960P, RAID-1 2*IBM DFHS S2W) without any problems as router ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 05:10:34 2008 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 E0A901067C1F for ; Wed, 1 Oct 2008 05:10:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 799A58FC25 for ; Wed, 1 Oct 2008 05:10:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id MH4g1a0051HpZEsA1H9m61; Wed, 01 Oct 2008 05:09:46 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id MHA91a00V4v8bD78aHAAfs; Wed, 01 Oct 2008 05:10:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=8EjPQLliAAAA:8 a=QyXUC8HyAAAA:8 a=QycZ5dHgAAAA:8 a=GuNoaFkM1zUE1ActBQIA:9 a=MmdS8FLRKrXd4nJY_gwA:7 a=cbwKBWab_SP7qcDdIbUm0ADbRO0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id E5E4AC9419; Tue, 30 Sep 2008 22:10:08 -0700 (PDT) Date: Tue, 30 Sep 2008 22:10:08 -0700 From: Jeremy Chadwick To: Oliver Lehmann Message-ID: <20081001051008.GA65754@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> <20081001065309.3e7e108e.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081001065309.3e7e108e.lehmann@ans-netz.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Bartosz Stec Subject: Re: system hangup - I'm lost 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, 01 Oct 2008 05:10:35 -0000 On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: > Jeremy Chadwick wrote: > > > I can't find anything on Intel's site that clues me in; all the PDFs > > are vague as far as what chips are on the board. > > Have you tried the Product specifications? No need -- Charles Sprickman sent me high-resolution pictures of all the ICs on the 440GX board, and I was able to identify all of them except a few (and those are obviously bit-latches or gates of some kind, so not important). Here's the list: - National Semiconductor Super I/O chip [1] - Cirrus Logic GD5480 video/VGA chip - Samsung SGRAM module for VGA chip; 16MBytes, 70ns - Intel 82371EB (PIIX4E) chip [2] - Dallas Semiconductor DS80CH11 power management chip - EtronTech SRAM; 256kbit, 15ns - Unknown, looks like flash or DRAM - Intel S82093AA I/O APIC - Octal bit-latch IC - Intel SB21150BC PCI bridge; 66MHz - Intel chip of some kind, can't make it out due to dust - Texas Instrument UCC5638 SCSI terminator - Texas Instrument UCC5638 SCSI terminator - Cypress Semiconductor W48C101 clock chip - Numerous other bit-latching ICs - Cypress Semiconductor 3.3V SDRAM buffering chip; probably used to drive SDRAM DIMMs (system memory) - ??? Model 684702-003; not sure what this does, but is of no interest - Some TI chip, doesn't interest me - 2x California Micro Devices ECP/EPP (parallel port) terminator - Maxim MAX211ECA1, no idea but doesn't interest me [1]: I'll have to look up datasheets on this chip to see if it supports H/W monitoring. [2]: This chip does a **lot**, the most important piece being it drives the entire PCI bus. It *does* support SMBus, but not I2C. Linux lmsensors supports this chip, but I don't know ""how"" it supports it. I will need to look up the specs/datasheets on it http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/busses/i2c-piix4 > http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf > > Beginning on page 33 (43 of the pdf) > > It has 3 different Server Management busses. the temperature part is > handled within a Baseboard Management Controller. This BMC is implemented > using a DS82CL10. This tells me very little. :-) > Because it is a Server Board it offers a lot of managing features and > other nice things like serial console at bootup and system monitoring > features... but all unsupported withn FreeBSDs software ;) Really? That's interesting, because Charles Sprickman told me that there is no hardware monitoring information in the BIOS if you go in there. Most motherboards provide that in the BIOS as a centralised place above all else. Either way, I'm going to look into the details. Examining what exactly Linux lm-sensors means by "support" will be the first step. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 05:36:56 2008 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 6E03E106568A for ; Wed, 1 Oct 2008 05:36:56 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 477BC8FC1F for ; Wed, 1 Oct 2008 05:36:56 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m915atWo045566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 22:36:55 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Tue, 30 Sep 2008 22:36:47 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <274267384.20080930223647@takeda.tk> To: "Carlos A. M. dos Santos" In-Reply-To: References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8363/Tue Sep 30 20:24:25 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, lhmwzy Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 05:36:56 -0000 Hello Carlos, Tuesday, September 30, 2008, 5:57:06 PM, you wrote: > Do you subscribe freebsd-stable? This has bee discussed recently in this list: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html I wouldn't call it "discussion". It was mentioned and then quickly it was forgotten. BTW: Matt Dillon, is the founder of DragonflyBSD, which apparently already supports HAMMER. As far as I know, no actual FreeBSD developer commented in that thread yet. -- Best regards, Derek mailto:takeda@takeda.tk How many of you believe in telekinesis? Raise MY hand! From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 06:10:26 2008 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 D11EF1065687 for ; Wed, 1 Oct 2008 06:10:26 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1468FC1D for ; Wed, 1 Oct 2008 06:10:26 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so275518fgb.35 for ; Tue, 30 Sep 2008 23:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ToXwxy6xRHxNO7p89Rh8UDHTkpUFYtO8rRD1eFRs3NY=; b=QMw3uUL/pm85uiXBQhOr20JbusgoLr9M4383rDwhiWKN2UpvHJ5QKf/1cuzf7Pjxf2 MvqTtpBX4XZ3VuInIdpRrqfuRGBq0s4o4cicjCyqH6JD5ykLFOKbAMJAl773K7gdXV6Z UmfBuAwRGvFDKsdLvmYpPgolsdBmFkUBm9r0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sTQnkXNSaI9OMUKtGN9XExVRjtrrRWbyqYY5Khma9vwMs65DIHUBtE6wpxSO017v2o TP8z+UROpkXgw7Kc6KC0aJLuonJnNANVinCuzhg5febEKLfxKbss5SjlNcHEeG1MES7B aDU8729rIaPue1oiGEekhdRWHmZcfpXV35dws= Received: by 10.86.61.13 with SMTP id j13mr6551723fga.69.1222841424924; Tue, 30 Sep 2008 23:10:24 -0700 (PDT) Received: by 10.86.25.10 with HTTP; Tue, 30 Sep 2008 23:10:24 -0700 (PDT) Message-ID: <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> Date: Wed, 1 Oct 2008 14:10:24 +0800 From: lhmwzy To: "=?GB2312?B?RGVyZWsgS3Vsaai9c2tp?=" In-Reply-To: <274267384.20080930223647@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 06:10:26 -0000 WWVzLgpJdCBzZWVtcyB0aGF0IG5vYm9keSBpcyBpbnRlcmVzdGVkIGluIHRoaXMuCi1NYXR0IHdv dWxkIG5vdCBwb3J0IGlzIHRvIEZyZWVCU0Qsd2hpY2ggaXMgYSBiaWcgcmVncmV0ZnVsLgoKMjAw OC8xMC8xIERlcmVrIEt1bGmovXNraSA8dGFrZWRhQHRha2VkYS50az46Cj4gSGVsbG8gQ2FybG9z LAo+Cj4gVHVlc2RheSwgU2VwdGVtYmVyIDMwLCAyMDA4LCA1OjU3OjA2IFBNLCB5b3Ugd3JvdGU6 Cj4KPj4gRG8geW91IHN1YnNjcmliZSBmcmVlYnNkLXN0YWJsZT8gVGhpcyBoYXMgYmVlIGRpc2N1 c3NlZCByZWNlbnRseSBpbiB0aGlzIGxpc3Q6Cj4+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9w aXBlcm1haWwvZnJlZWJzZC1zdGFibGUvMjAwOC1TZXB0ZW1iZXIvMDQ1NTA2Lmh0bWwKPgo+IEkg d291bGRuJ3QgY2FsbCBpdCAiZGlzY3Vzc2lvbiIuIEl0IHdhcyBtZW50aW9uZWQgYW5kIHRoZW4g cXVpY2tseSBpdAo+IHdhcyBmb3Jnb3R0ZW4uCj4KPiBCVFc6IE1hdHQgRGlsbG9uLCBpcyB0aGUg Zm91bmRlciBvZiBEcmFnb25mbHlCU0QsIHdoaWNoIGFwcGFyZW50bHkKPiBhbHJlYWR5IHN1cHBv cnRzIEhBTU1FUi4KPgo+IEFzIGZhciBhcyBJIGtub3csIG5vIGFjdHVhbCBGcmVlQlNEIGRldmVs b3BlciBjb21tZW50ZWQgaW4gdGhhdAo+IHRocmVhZCB5ZXQuCj4KPiAtLQo+IEJlc3QgcmVnYXJk cywKPiAgRGVyZWsgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOnRha2VkYUB0YWtl ZGEudGsKPgo+IEhvdyBtYW55IG9mIHlvdSBiZWxpZXZlIGluIHRlbGVraW5lc2lzPyBSYWlzZSBN WSBoYW5kIQo+Cj4KPgo= From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 06:20:46 2008 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 EDC13106569B for ; Wed, 1 Oct 2008 06:20:46 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id C64DD8FC1D for ; Wed, 1 Oct 2008 06:20:46 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m916KjEd046078 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 23:20:46 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Tue, 30 Sep 2008 23:18:36 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1031817271.20080930231836@takeda.tk> To: lhmwzy In-Reply-To: <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8363/Tue Sep 30 20:24:25 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 06:20:47 -0000 Hello lhmwzy, Tuesday, September 30, 2008, 11:10:24 PM, you wrote: > Yes. > It seems that nobody is interested in this. > -Matt would not port is to FreeBSD,which is a big regretful. I'm pretty sure there are people who are interested, it looks more like there are no people who're capable of doing this and have time. -- Best regards, Derek mailto:takeda@takeda.tk An unemployed court jester is no one's fool. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 06:22:03 2008 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 87F50106568C for ; Wed, 1 Oct 2008 06:22:03 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1E24B8FC19 for ; Wed, 1 Oct 2008 06:22:02 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so277898fgb.35 for ; Tue, 30 Sep 2008 23:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=FdYBCXxYDCQprsCt7Kb+lIPxpKcHVdylKCA+0P9wZ7s=; b=w4HknbfYnqissrpqJ/dIy9qktQP+UHLodUrdRewQsBbtGsmqdAXVgv/Rq/tuESTU2Z zI4ny4QtugtbXhpWDFt5ftNv/TJQOVJIMrPrDL3x8s5ekh9M6dMXZgDiufR6HymrM8EZ cgjbWYa+fu3ffiJb1L1OLmU4KZ3wLuG53q4Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=UMggqAv+fWr+yL8S22QYRbdtSM3u8PWyuUyjqfloawPRywg9XJmr5FIIyQFIWYutWM Sw726jwus6muw2neTp6v5jRHaXAhvg1M+KNSSlgTkXKm88X2yuIe8aWBAfMd3txsvj4v eLrvxuK8hTqlxfeYqvdiSePn1jD8wpFarfHPk= Received: by 10.86.90.13 with SMTP id n13mr6658287fgb.3.1222842121943; Tue, 30 Sep 2008 23:22:01 -0700 (PDT) Received: by 10.86.25.10 with HTTP; Tue, 30 Sep 2008 23:22:01 -0700 (PDT) Message-ID: <78fb9d960809302322m40026ee0wbba3f8af199697d4@mail.gmail.com> Date: Wed, 1 Oct 2008 14:22:01 +0800 From: lhmwzy To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 06:22:03 -0000 >Guys, please don't start a flamewar. And lhmwzy we discussed this >on the DFly lists. It's really up to them... that is, a programmer >who has an interest, inclination, and time. It isn't really fair to >try to push it. You're right. >I personally believe that the FreeBSD community as a whole should >focus on ZFS for now. It has the momentum and the most interest >on their lists. > -Matt That's OK. The olny thing we can do is waiting. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 06:29:15 2008 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 6D5B71065687 for ; Wed, 1 Oct 2008 06:29:15 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 712468FC0A for ; Wed, 1 Oct 2008 06:29:13 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so279338fgb.35 for ; Tue, 30 Sep 2008 23:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3aBF5f6uk4fIRr5odUQD/2O4nySPiBKxnj/Vh2E1TPs=; b=hDG0t3Bvzvcd6uMMbmEI6aJCQn3QNXaQoG08Bv7Kj1UWNITy1mI7QhC5Ndb/iJlNQO yYDufX2iEjWPQenehEBhW6p56JcrEwA2WdF9qrlQQGHAtDC+fvJ+w23PFR1WvOxPlnaJ f6GYFjHGdlotsHFE4hucFI8eX7lEHhNV6A/HA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=riyD2PaQXZ806qIE+N+GhxKjmWRBF/5DqqrxXNpvmAK6cIk8r3QndYJ88ChvxvCtmg NJ/1TDj0/31+/GoOfhjonxxMnddb0OBJ9TFKrmP1J+dMM2D+J48NiFEXn7ZXc7Z+sTJI aJ3AhjafejRiyuOA+UfaPYPb+TlEyqksUKQCs= Received: by 10.86.72.15 with SMTP id u15mr5035565fga.34.1222842552266; Tue, 30 Sep 2008 23:29:12 -0700 (PDT) Received: by 10.86.25.10 with HTTP; Tue, 30 Sep 2008 23:29:12 -0700 (PDT) Message-ID: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> Date: Wed, 1 Oct 2008 14:29:12 +0800 From: lhmwzy To: "=?GB2312?B?RGVyZWsgS3Vsaai9c2tp?=" In-Reply-To: <1031817271.20080930231836@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 06:29:15 -0000 VGhhdCdzIGl0LgpTaW5jZSB3ZSBkb24ndCBoYXZlIHRoZSBza2lsbCx3aGF0IHdlIGNhbiBkbyBp cyB3YWl0LgoKV2FpdGluZyBpcyBzdWNoIGEgYmFkIHRoaW5nLi4uLi4uLgoKMjAwOC8xMC8xIERl cmVrIEt1bGmovXNraSA8dGFrZWRhQHRha2VkYS50az46Cj4gSGVsbG8gbGhtd3p5LAo+Cj4gVHVl c2RheSwgU2VwdGVtYmVyIDMwLCAyMDA4LCAxMToxMDoyNCBQTSwgeW91IHdyb3RlOgo+Cj4+IFll cy4KPj4gSXQgc2VlbXMgdGhhdCBub2JvZHkgaXMgaW50ZXJlc3RlZCBpbiB0aGlzLgo+PiAtTWF0 dCB3b3VsZCBub3QgcG9ydCBpcyB0byBGcmVlQlNELHdoaWNoIGlzIGEgYmlnIHJlZ3JldGZ1bC4K Pgo+IEknbSBwcmV0dHkgc3VyZSB0aGVyZSBhcmUgcGVvcGxlIHdobyBhcmUgaW50ZXJlc3RlZCwg aXQgbG9va3MgbW9yZQo+IGxpa2UgdGhlcmUgYXJlIG5vIHBlb3BsZSB3aG8ncmUgY2FwYWJsZSBv ZiBkb2luZyB0aGlzIGFuZCBoYXZlIHRpbWUuCj4KPiAtLQo+IEJlc3QgcmVnYXJkcywKPiAgRGVy ZWsgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOnRha2VkYUB0YWtlZGEudGsKPgo+ IEFuIHVuZW1wbG95ZWQgY291cnQgamVzdGVyIGlzIG5vIG9uZSdzIGZvb2wuCj4KPgo+Cg== From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 06:57:35 2008 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 9C4481065697 for ; Wed, 1 Oct 2008 06:57:35 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7195C8FC14 for ; Wed, 1 Oct 2008 06:57:35 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m916vYgr046393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 23:57:34 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Tue, 30 Sep 2008 23:57:24 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <853814696.20080930235724@takeda.tk> To: lhmwzy In-Reply-To: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8363/Tue Sep 30 20:24:25 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 06:57:35 -0000 Hello lhmwzy, Tuesday, September 30, 2008, 11:29:12 PM, you wrote: > That's it. > Since we don't have the skill,what we can do is wait. > Waiting is such a bad thing....... Though I don't have too much experience about filesystems, I personally would be interested in this since it would be a pretty good way to learn it. The biggest problem for me right now is the lack of time. I'm a full-time student right now :( If you have some experience in C and time, you can try to do some work, then announce to others. Maybe a developer will volunteer and act as a mentor. As far as I know many FreeBSD developers started that way. I remember PJD 7 years ago telling me that he's learning how to use FBSD, and look at him now :) I don't think "I don't know how to" is a good excuse. -- Best regards, Derek mailto:takeda@takeda.tk -- Will the information superhighway have any rest stops? From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 07:13:12 2008 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 429D5106564A for ; Wed, 1 Oct 2008 07:13:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id DC0F48FC1D for ; Wed, 1 Oct 2008 07:13:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id MKAB1a00G16LCl053KDB2K; Wed, 01 Oct 2008 07:13:11 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id MKD91a0024v8bD73SKDA2k; Wed, 01 Oct 2008 07:13:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=EsafgVd45cAA:10 a=5rEFM_Im40MA:10 a=QycZ5dHgAAAA:8 a=ZtPcwptDRJSYnSTXSYMA:9 a=XxSXQoiKak_yiqYj2ogI_rqY2noA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C9CC8C9432; Wed, 1 Oct 2008 00:13:09 -0700 (PDT) Date: Wed, 1 Oct 2008 00:13:09 -0700 From: Jeremy Chadwick To: lhmwzy Message-ID: <20081001071309.GA13616@icarus.home.lan> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Derek Kuli??ski , freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 07:13:12 -0000 On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: > That's it. > Since we don't have the skill,what we can do is wait. > > Waiting is such a bad thing....... If this functionality is really something you want/need, you should consider finding a kernel programmer who would be willing to port it, for financial exchange (in English: you will be paying them $XX/hour to port it to FreeBSD). This has happened in the past for some key features. Like I said, it all depends on how much it matters to you. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 07:15:41 2008 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 BB8D5106568E for ; Wed, 1 Oct 2008 07:15:41 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 454D78FC1C for ; Wed, 1 Oct 2008 07:15:40 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so288808fgb.35 for ; Wed, 01 Oct 2008 00:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rWPieS+/xgDznCTVaGby1eW91P2OlQ33s+a6Wgd4Jxk=; b=xeKFf6QFIxDYIgsf2SSWYUGIsuc0DN9NcO4F9QI0ugT8+jXsKALy7LNfdivRlgrILv l31YRRtAV0r29ty+bbMH+Fh72JkAXqIKmt20lI5TD/i00Jvh6JAZ12oSyO5DrmeiBRZX gA4EGC3BMFRX4r+vSC2zfpQZOb+0+qfsaZrfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FPHS2SHH3lOeJlldE7fXLdT9GAPmiclINOv5HEYrt1bz2fiq/XNp2pQGLwLoErJ4Dx qlLAmFe0eaZJkMaCsm/ezT8+WFIlWxzOPfDYfvUhZMz+dwag3sbMcagbwU7rnXJtOwxB aXRnMZMS4UFQg7c3JB+GQF3Rw4B3J3ALYNv/E= Received: by 10.86.33.19 with SMTP id g19mr6695549fgg.13.1222845339907; Wed, 01 Oct 2008 00:15:39 -0700 (PDT) Received: by 10.86.25.10 with HTTP; Wed, 1 Oct 2008 00:15:39 -0700 (PDT) Message-ID: <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> Date: Wed, 1 Oct 2008 15:15:39 +0800 From: lhmwzy To: "Jeremy Chadwick" In-Reply-To: <20081001071309.GA13616@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> Cc: freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 07:15:41 -0000 Yes,this is a way. I would do as you said if I need to do so. 2008/10/1 Jeremy Chadwick : > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing....... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 08:54:56 2008 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 281681065686; Wed, 1 Oct 2008 08:54:56 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id AB9018FC20; Wed, 1 Oct 2008 08:54:55 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id m918sqCC071062; Wed, 1 Oct 2008 11:54:52 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <48E33AD7.20707@eng.auth.gr> Date: Wed, 01 Oct 2008 11:54:47 +0300 From: George Mamalakis User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: Robert Watson References: <48E1EBE1.50206@eng.auth.gr> <48E21BD9.1080101@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: jails and mac_seeotheruids problems in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 08:54:56 -0000 Robert Watson wrote: > > On Tue, 30 Sep 2008, George Mamalakis wrote: > >> It works like a charm! Thank you very much for your time and help, > > No problem -- I've gone ahead and committed that change to stable/6. > If you're able to test 6.4RC1 when it comes out to confirm that the > fix works there as desired, that would be most helpful. > I will csup to 6.4RC1 when available, and will inform you of the outcome. Thanks again. > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> regards, >> >> >> Robert Watson wrote: >>> >>> On Tue, 30 Sep 2008, George Mamalakis wrote: >>> >>>> I have 3 servers in my lab. 2 of them are running 6-STABLE and one >>>> of them is running 7-STABLE. All three have services running in >>>> jails. I noticed a very peculiar behavior in 6-STABLE when I set >>>> the sysctl security.mac.seeotheruids.enabled=1. The root user in my >>>> jails was not able to see processes and sockets owned by other >>>> users of the same jail, whereas the root user of the host system >>>> could see every process (thank the Almighty). The same behavior >>>> does not apply on the server running 7-STABLE. >>>> >>>> In one sense it is more secure, since the root user in a jail is >>>> not as "strong" as the root user should be in a UNIX system. On the >>>> other hand, the root user looses its purpose of existence, which I >>>> suppose is a bug. >>>> >>>> Below are the security.mac sysctl settings of both 6 and 7-STABLE: >>> >>> Could you try modifying >>> src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree >>> so that the call to suser_cred() in mac_seeotheruids_check() passes >>> the SUSER_ALLOWJAIL flag rather than 0? This may correct the >>> problem you're experiencing. Let me know and I can merge that >>> change to 6.x. >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >>> >>>> >>>> 6-STABLE: >>>> >>>> security.mac.max_slots: 4 >>>> security.mac.enforce_network: 1 >>>> security.mac.enforce_pipe: 1 >>>> security.mac.enforce_posix_sem: 1 >>>> security.mac.enforce_suid: 1 >>>> security.mac.mmap_revocation_via_cow: 0 >>>> security.mac.mmap_revocation: 1 >>>> security.mac.enforce_vm: 1 >>>> security.mac.enforce_process: 1 >>>> security.mac.enforce_socket: 1 >>>> security.mac.enforce_system: 1 >>>> security.mac.enforce_kld: 1 >>>> security.mac.enforce_sysv_msg: 1 >>>> security.mac.enforce_sysv_sem: 1 >>>> security.mac.enforce_sysv_shm: 1 >>>> security.mac.enforce_fs: 1 >>>> security.mac.seeotheruids.specificgid: 0 >>>> security.mac.seeotheruids.specificgid_enabled: 0 >>>> security.mac.seeotheruids.primarygroup_enabled: 0 >>>> security.mac.seeotheruids.enabled: 1 >>>> security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 >>>> security.mac.portacl.port_high: 1023 >>>> security.mac.portacl.autoport_exempt: 1 >>>> security.mac.portacl.suser_exempt: 1 >>>> security.mac.portacl.enabled: 1 >>>> >>>> >>>> 7-STABLE: >>>> >>>> security.mac.max_slots: 4 >>>> security.mac.version: 3 >>>> security.mac.mmap_revocation_via_cow: 0 >>>> security.mac.mmap_revocation: 1 >>>> security.mac.seeotheruids.specificgid: 0 >>>> security.mac.seeotheruids.specificgid_enabled: 0 >>>> security.mac.seeotheruids.suser_privileged: 1 >>>> security.mac.seeotheruids.primarygroup_enabled: 0 >>>> security.mac.seeotheruids.enabled: 1 >>>> >>>> I would be very glad if someone could inform me whether I am doing >>>> something wrong; if not I think I should inform FreeBSD about this >>>> bug. >>>> >>>> Thank you guys in advance, >>>> >>>> -- >>>> George Mamalakis >>>> >>>> IT Officer >>>> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >>>> MSc (Imperial College of London) >>>> >>>> Department of Electrical and Computer Engineering >>>> Faculty of Engineering >>>> Aristotle University of Thessaloniki >>>> >>>> phone number : +30 (2310) 994379 >>>> >>>> _______________________________________________ >>>> 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" >>>> >> >> -- >> George Mamalakis >> >> IT Officer >> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >> MSc (Imperial College of London) >> >> Department of Electrical and Computer Engineering >> Faculty of Engineering >> Aristotle University of Thessaloniki >> >> phone number : +30 (2310) 994379 >> >> > _______________________________________________ > 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" -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 09:24:01 2008 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 C0D291065687; Wed, 1 Oct 2008 09:24:01 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 218358FC15; Wed, 1 Oct 2008 09:24:00 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from giskard.stuyts.nl (stuyts.xs4all.nl [82.95.106.42]) by altus-escon.com (8.14.2/8.14.2) with ESMTP id m918gbEI025114; Wed, 1 Oct 2008 10:42:42 +0200 (CEST) (envelope-from ben@altesco.nl) Message-Id: <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> From: Ben Stuyts To: Jeremy Chadwick In-Reply-To: <20080930104605.GA44675@icarus.home.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 1 Oct 2008 10:42:32 +0200 References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [10.0.0.150]); Wed, 01 Oct 2008 10:42:42 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8364/Wed Oct 1 09:11:44 2008 on mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Holger Kipp , stable@freebsd.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 01 Oct 2008 09:24:01 -0000 On 30 sep 2008, at 12:46, Jeremy Chadwick wrote: > On Tue, Sep 30, 2008 at 12:08:48PM +0200, Holger Kipp wrote: >> - email (imap) > > I've had good experience with dovecot; I tend to stay away from Cyrus > products (disgusting code with a history of security issues), and > Courier (no interest). I had to disable mmap access in dovecot, or it would coredump periodically. (mmap_disable = yes in dovecot.conf) I found that to be a problem only on ZFS. I don't know if that's been fixed yet. Apart from that it works great. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 09:39:11 2008 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 8F9C91065687; Wed, 1 Oct 2008 09:39:11 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from gateway.nixsys.be (gateway.nixsys.be [IPv6:2001:6f8:32f::42]) by mx1.freebsd.org (Postfix) with ESMTP id 285D08FC19; Wed, 1 Oct 2008 09:39:11 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from detritus.paeps.cx (detritus.paeps.cx [IPv6:2001:6f8:1408::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "detritus.paeps.cx", Issuer "NixSys CA" (verified OK)) by gateway.nixsys.be (Postfix) with ESMTP id 255564105; Wed, 1 Oct 2008 11:39:10 +0200 (CEST) Received: from carrot.paeps.cx (carrot [IPv6:2001:6f8:1408::2]) by detritus.paeps.cx (Postfix) with ESMTP id 8176220A9; Wed, 1 Oct 2008 11:39:08 +0200 (CEST) Received: from carrot.paeps.cx (philip@localhost [127.0.0.1]) by carrot.paeps.cx (8.14.3/8.14.3) with ESMTP id m919d7mf027523; Wed, 1 Oct 2008 11:39:07 +0200 (CEST) (envelope-from philip@carrot.paeps.cx) Received: (from philip@localhost) by carrot.paeps.cx (8.14.3/8.14.3/Submit) id m919d6cN027522; Wed, 1 Oct 2008 11:39:06 +0200 (CEST) (envelope-from philip) Date: Wed, 1 Oct 2008 11:39:06 +0200 From: Philip Paeps To: Nikola =?utf-8?B?TGXEjWnEhw==?= Message-ID: <20081001093906.GI6749@carrot.paeps.cx> Mail-Followup-To: Nikola =?utf-8?B?TGXEjWnEhw==?= , Edwin Groothuis , FreeBSD-current@FreeBSD.org, FreeBSD-stable@FreeBSD.org References: <20080928054620.GA80250@k7.mavetju> <20080928142409.19f94e5b@anthesphoria.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080928142409.19f94e5b@anthesphoria.net> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Today is Prickle-Prickle, the 55th day of Bureaucracy in the YOLD 3174 X-Date-in-France: =?utf-8?Q?D=C3=A9cadi_10_Vend=C3=A9miair?= =?utf-8?Q?e?= CCXVII, jour de la cuve X-Date-in-Rome: Kalendas Octobres MMDCCLXI ab Urbe Condida X-Phase-of-Moon: The Moon is Waxing Crescent (5% of Full) X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-current@FreeBSD.org, FreeBSD-stable@FreeBSD.org, Edwin Groothuis Subject: Re: Request for testing - top 3.8b1 in the base 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, 01 Oct 2008 09:39:11 -0000 On 2008-09-28 14:24:09 (+0200), Nikola Lečić wrote: > On Sun, 28 Sep 2008 15:46:20 +1000 Edwin Groothuis wrote: > > Please report any issues with it (compile time, run time) and a way to > > reproduce it (if possible). Thanks for your help! > > last pid: 70762; load avg: 1.22, 0.54, 0.33; up 0+16:48:11 14:08:01 > 177 threads: 11 running, 147 sleeping, 19 waiting > CPU: 27.6% user, 0.0% nice, 3.3% system, 0.7% interrupt, 68.4% idle > Kernel: 246626 ctxsw, 5063 trap, 362 intr, 354 soft, 5 fork, 4591 flt, 728 fr > Mem: 891M Active, 774M Inact, 233M Wired, 89M Cache, 112M Buf, 3668K Free > Swap: 4096M Total, 4096M Free > > [...] > > Btw, an aesthetic observation, in H mode the USERNAME column shrinks > and expands if username has less or more than 9 characters. :-) Another aesthetic observation is the alignment of the CPU: line - it would be nice if the data all lined up nicely with Kernel/Mem/Swap below. Very minor point though. Thanks for making this work! - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. Greebo's technique was unscientific and wouldn't have stood a chance against any decent swordmanship, but on his side was the fact that it is almost impossible to develop decent swordmanship when you seem to have run into a food mixer that is biting your ear off. -- (Terry Pratchett, Witches Abroad) From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 10:12:29 2008 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 86DE7106568C for ; Wed, 1 Oct 2008 10:12:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF3F8FC15 for ; Wed, 1 Oct 2008 10:12:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id MMwm1a0061GhbT852NC5zb; Wed, 01 Oct 2008 10:12:05 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.westchester.pa.mail.comcast.net with comcast id MNCT1a0064v8bD73TNCTap; Wed, 01 Oct 2008 10:12:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=N8se_1cBi2wA:10 a=j3-Kh4PWcnIA:10 a=mjMI4m5sAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=Pn-9Jm2b6MBDGmHg69oA:9 a=UiN34xJubOcMOt2v7yQA:7 a=lhGe_fnxfXtrynWrvXmDMsiFkq8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 37BD7C9432; Wed, 1 Oct 2008 03:12:27 -0700 (PDT) Date: Wed, 1 Oct 2008 03:12:27 -0700 From: Jeremy Chadwick To: Ben Stuyts Message-ID: <20081001101227.GA17912@icarus.home.lan> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Holger Kipp , stable@freebsd.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 01 Oct 2008 10:12:29 -0000 On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: > I had to disable mmap access in dovecot, or it would coredump > periodically. (mmap_disable = yes in dovecot.conf) I found that to be a > problem only on ZFS. I don't know if that's been fixed yet. Apart from > that it works great. This seems relevant to your problem: http://www.dovecot.org/list/dovecot/2008-March/029565.html HEAD had this problem fixed in rev 1.28, dated 2008/03/15. RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. Here's the proper file in cvsweb so you can see it yourself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Have you tried re-enabling mmap in dovecot on a system with a kernel build after those dates? If so, does it still randomly segfault? If so, have you reported this to pjd@? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 11:24:51 2008 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 3C6921065688; Wed, 1 Oct 2008 11:24:51 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from zoc.com.ua (zoc.com.ua [82.144.212.13]) by mx1.freebsd.org (Postfix) with ESMTP id B48B98FC23; Wed, 1 Oct 2008 11:24:49 +0000 (UTC) (envelope-from mirya@zoc.com.ua) Received: from [192.168.0.22] (port=50531) by zoc.com.ua with esmtp (Exim 4.62) (envelope-from ) id 1Kkzoq-0001b8-H5; Wed, 01 Oct 2008 14:24:36 +0300 From: Kyryll A Mirnenko aka Mirya Organization: zoc To: Roland Smith Date: Wed, 1 Oct 2008 14:24:01 +0300 User-Agent: KMail/1.9.4 References: <200809301454.47473.mirya@zoc.com.ua> <20080930173202.GA16426@slackbox.xs4all.nl> In-Reply-To: <20080930173202.GA16426@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810011424.02903.mirya@zoc.com.ua> X-CHECK-DB: NO Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade 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, 01 Oct 2008 11:24:51 -0000 On Tuesday 30 September 2008 20:32, Roland Smith wrote: > My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE > (updated september 25th). I've been tracking stable since 7.0-RELEASE > without problems. > > My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and > GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, > SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO > options are also part of the kernel. > First, I get to the following: if you have GEOM_PART_BSD in the kernel alone, attaching GELI at the boot time works as expected. If you add GEOM_PART_MBR (so both GEOM_PART_BSD and GEOM_PART_MBR are in), you face the problem i've described. Second, i've tried to get kern.geom.confxml sysctl as Pawel suggested, but with no lack. First, the whole XML dump doesn't feet the console buffer, so i can't later extract it from dmesg; i've tried to dump it to some file, but due to the fact everything is mounted -ro at the point /etc/rc.d/geli is executed, i placed "mount -u -rw /" in the beginning of it. While that made a trick and i got the dump (see below), the GELI partition attached successfully (while instantly failed with "Cannot access ad0s1f (error=1)" without remounting / -rw), so I guess remounting / read-write changed something and such dump will be of no use: ACD acd0 1 r0w0e0 acd0 8796093020160 2048 MD ELI JOURNAL VOL_FFS VFS ffs.ad0s1a 4 r1w1e1 MBR msdosfs/WD Passport 4 r0w0e0 r0w0e0 msdosfs/WD Passports4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0s1 3 r0w0e0 r0w0e0 da0s1s4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0 2 r0w0e0 r0w0e0 da0s1 120031478784 512 0 120031478784 234436482 32256 63 12 ad0 2 r1w1e3 r1w1e2 ad0s1 40007729664 512 0 40007729664 78140097 32256 63 165 MBREXT BDE PART da0 2 MBR 4 63 234441647 63 255 r0w0e0 r0w0e0 da0s1 120031478784 512 1 !12 32256 120031478784 12 ad0s1 3 BSD 8 0 78140096 63 16 r1w1e2 r0w0e0 ad0s1f 5368709120 512 6 freebsd-ufs 1048576000 5368709120 7 r0w0e0 ad0s1e 734003200 512 5 freebsd-ufs 314572800 734003200 7 r0w0e0 ad0s1d 314572800 512 4 freebsd-ufs 0 314572800 7 r0w0e0 ad0s1b 402653184 512 2 freebsd-swap 6417285120 402653184 1 r1w1e1 ad0s1a 33187791360 512 1 freebsd-ufs 6819938304 33187791360 7 DISK cd0 1 r0w0e0 cd0 0 2048 0 0 da0 1 r0w0e0 da0 120034123776 512 255 63 ad0 1 r1w1e3 ad0 40007761920 512 16 63 LABEL da0s1 3 r0w0e0 r0w0e0 msdosfs/WD Passport 120031478784 512 0 120031478784 234436482 0 0 SWAP DEV msdosfs/WD Passports4 5 r0w0e0 da0s1s4 4 r0w0e0 msdosfs/WD Passport 4 r0w0e0 cd0 2 r0w0e0 da0s1 3 r0w0e0 da0s1 3 r0w0e0 da0 2 r0w0e0 ad0s1df 5 r0w0e0 ad0s1de 5 r0w0e0 ad0s1dd 5 r0w0e0 ad0s1dc 5 r0w0e0 ad0s1db 5 r0w0e0 ad0s1da 5 r0w0e0 ad0s1f 4 r0w0e0 ad0s1e 4 r0w0e0 ad0s1d 4 r0w0e0 ad0s1b 4 r0w0e0 ad0s1a 4 r0w0e0 acd0 2 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 BSD ad0s1d 4 512 32256 32256 r0w0e0 r0w0e0 ad0s1df 5368709120 512 5 5368709120 10485760 1048576000 2048000 7 r0w0e0 ad0s1de 734003200 512 4 734003200 1433600 314572800 614400 7 r0w0e0 ad0s1dd 314572800 512 3 314572800 614400 0 0 7 r0w0e0 ad0s1dc 40007729664 512 2 40007729664 78140097 0 0 0 r0w0e0 ad0s1db 402653184 512 1 402653184 786432 6417285120 12533760 1 r0w0e0 ad0s1da 33187791360 512 0 33187791360 64819905 6819938304 13320192 7 Hope the above will help solving it, though as far as it's specific to my weird kernel configuration and the bad options combination is known it's low priority. Also, if someone can offer a simple way to get kern.geom.confxml at the time the problem occurs, i can experiment more. -- Regards, Mirya ICQ #313898202 From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 11:41:58 2008 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 753931065686 for ; Wed, 1 Oct 2008 11:41:58 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id 457958FC0A for ; Wed, 1 Oct 2008 11:41:58 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WCoYbJbAJmQ/tWvufAkLa8WGNT4GNetYOe6fT4mGb/QXGEmWtkS6HjO+jH/08VIm; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl05d-0004Gl-GS for freebsd-stable@freebsd.org; Wed, 01 Oct 2008 07:41:57 -0400 Message-ID: <48E36204.5090108@earthlink.net> Date: Wed, 01 Oct 2008 07:41:56 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec796d0107e56c3ce7d14698431cbb638458350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Subject: resource leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 11:41:58 -0000 Hello List, I am running into a strange problem that points to a resource leak. The problem manifests itself after one of our remote systems has been up around 100 days. The symptom is that it appears no new processes can be spawned. If I try to ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. Examining log files, like cron, etc show that when this happens no more entries are written into the cron log. The unit is acting as a firewall, router and vpn appliance these functions continue to work. We have a C application that is periodically started out of a shell script that reports various information about the system, it stops reporting, while vpns, ospf routing, and ipfilter firewalling continue to work and write into their logfiles. My question is how do I monitor the various resources in the system that could prevent the spawning of a new process? This is on FreeBSD 6.1, ipsec-tools-6.6, quagga-0.99.3 Any ideas or directions would be greatly appreciated. Thanks, Steve From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 11:50:48 2008 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 13785106568D for ; Wed, 1 Oct 2008 11:50:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id ED7C78FC14 for ; Wed, 1 Oct 2008 11:50:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id MP0Q1a00C1GXsucA2PqnmC; Wed, 01 Oct 2008 11:50:47 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id MPqm1a0054v8bD78TPqm2i; Wed, 01 Oct 2008 11:50:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=kb8kndks5vnnKcu7smUA:9 a=sZch_v3e5QWijE5lrlIA:7 a=9-yko1tzbrNF7AiPbLtBulX1kpgA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6E2F3C9432; Wed, 1 Oct 2008 04:50:46 -0700 (PDT) Date: Wed, 1 Oct 2008 04:50:46 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20081001115046.GA20384@icarus.home.lan> References: <48E36204.5090108@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E36204.5090108@earthlink.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Stable Subject: Re: resource leak 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, 01 Oct 2008 11:50:48 -0000 On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > Hello List, > > I am running into a strange problem that points to a resource leak. The > problem manifests itself after one of our remote systems has been up > around 100 days. > The symptom is that it appears no new processes can be spawned. If I try to > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > Examining log files, like cron, etc show that when this happens no more entries > are written into the cron log. The unit is acting as a firewall, router > and vpn appliance these functions continue to work. We have a C > application that is periodically started out of a shell script that > reports various information about the system, it stops reporting, while > vpns, ospf routing, and ipfilter firewalling continue to work and write > into their logfiles. > > My question is how do I monitor the various resources in the system that could > prevent the spawning of a new process? Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). Other things that might come in useful are "fstat" and "vmstat -s". It sounds like your C program relies heavily on system() or execl() and fork(), which is why it's affected -- while the other programs are likely kernel-level. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 12:30:29 2008 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 116791065687; Wed, 1 Oct 2008 12:30:29 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by mx1.freebsd.org (Postfix) with ESMTP id BD6A08FC22; Wed, 1 Oct 2008 12:30:28 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tA+GYeB+reob/XmCkazbDMrDJ1u1Ubosq3zSmdaxmAdS95ll5nckPhrBzem7RCl1; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl0qZ-0006j1-VN; Wed, 01 Oct 2008 08:30:28 -0400 Message-ID: <48E36D62.6090001@earthlink.net> Date: Wed, 01 Oct 2008 08:30:26 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Jeremy Chadwick References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> In-Reply-To: <20081001115046.GA20384@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79c99c8809d814e2ebca6a3e0d357cf308350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: FreeBSD Stable Subject: Re: resource leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 12:30:29 -0000 Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >> Hello List, >> >> I am running into a strange problem that points to a resource leak. The >> problem manifests itself after one of our remote systems has been up >> around 100 days. >> The symptom is that it appears no new processes can be spawned. If I try to >> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >> Examining log files, like cron, etc show that when this happens no more entries >> are written into the cron log. The unit is acting as a firewall, router >> and vpn appliance these functions continue to work. We have a C >> application that is periodically started out of a shell script that >> reports various information about the system, it stops reporting, while >> vpns, ospf routing, and ipfilter firewalling continue to work and write >> into their logfiles. >> >> My question is how do I monitor the various resources in the system that could >> prevent the spawning of a new process? > > Periodically logging "ps -auxw" output to a file would be useful, as > ideally you'd gradually see the list get longer and longer over time; > it's possible you have many zombie processes as a result of a parent > which is not reaping its children (calling waitpid(2) or its friends). > > Other things that might come in useful are "fstat" and "vmstat -s". > > It sounds like your C program relies heavily on system() or execl() and > fork(), which is why it's affected -- while the other programs are > likely kernel-level. > Thanks Jeremy, I have added those commands to a periodic daily script. Another thing I have noticed is that quite often the problem seems to start at 2am in the morning, right when the periodic daily script runs. But I think it is coincidence and that we have reached the edge of the resource limit and all the jobs that get spawned by the periodic daily scripts pushes us over the limit. The other thing is that having logged into some of the systems that have been up in the 80 day range, I don't see a lot/any zombies. I just wonder if it is and fd leak, the fstat should point that out. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 12:49:57 2008 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 364EF1065688 for ; Wed, 1 Oct 2008 12:49:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id D46478FC1C for ; Wed, 1 Oct 2008 12:49:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA02.westchester.pa.mail.comcast.net with comcast id MN0j1a0010vyq2s52QpZRK; Wed, 01 Oct 2008 12:49:33 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.westchester.pa.mail.comcast.net with comcast id MQpv1a00L4v8bD73RQpvSU; Wed, 01 Oct 2008 12:49:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=H2G1wkdtjRh1aceY5sEA:9 a=Qu1rpiLgyi4Y0pKoIcEA:7 a=r8Jiv72FVFJo-K63GSJBjWvzivAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 37E2AC9432; Wed, 1 Oct 2008 05:49:55 -0700 (PDT) Date: Wed, 1 Oct 2008 05:49:55 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20081001124955.GA21577@icarus.home.lan> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E36D62.6090001@earthlink.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Stable Subject: Re: resource leak 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, 01 Oct 2008 12:49:57 -0000 On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: > Jeremy Chadwick wrote: >> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >>> Hello List, >>> >>> I am running into a strange problem that points to a resource leak. >>> The problem manifests itself after one of our remote systems has been >>> up around 100 days. >>> The symptom is that it appears no new processes can be spawned. If I try to >>> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >>> Examining log files, like cron, etc show that when this happens no more entries >>> are written into the cron log. The unit is acting as a firewall, >>> router and vpn appliance these functions continue to work. We have a >>> C application that is periodically started out of a shell script that >>> reports various information about the system, it stops reporting, >>> while vpns, ospf routing, and ipfilter firewalling continue to work >>> and write into their logfiles. >>> >>> My question is how do I monitor the various resources in the system that could >>> prevent the spawning of a new process? >> >> Periodically logging "ps -auxw" output to a file would be useful, as >> ideally you'd gradually see the list get longer and longer over time; >> it's possible you have many zombie processes as a result of a parent >> which is not reaping its children (calling waitpid(2) or its friends). >> >> Other things that might come in useful are "fstat" and "vmstat -s". >> >> It sounds like your C program relies heavily on system() or execl() and >> fork(), which is why it's affected -- while the other programs are >> likely kernel-level. >> > Thanks Jeremy, > > I have added those commands to a periodic daily script. > > Another thing I have noticed is that quite often the problem seems to > start at 2am in the morning, right when the periodic daily script runs. > > But I think it is coincidence and that we have reached the edge of the > resource limit and all the jobs that get spawned by the periodic daily > scripts pushes us over the limit. > > The other thing is that having logged into some of the systems that have > been up in the 80 day range, I don't see a lot/any zombies. I just wonder > if it is and fd leak, the fstat should point that out. You might find the below thread beneficial -- an individual came to the lists stating that they were running out of fds as a result of some Java software running amok on their systems. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 13:35:06 2008 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 D83921065687; Wed, 1 Oct 2008 13:35:06 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBCA8FC1C; Wed, 1 Oct 2008 13:35:06 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KfRmdDQ0nE6b48+wytMxtYYLQ1RdICIyg+jNw2DHx4DRq9I4b8K5OEt9junXjcNQ; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl1r7-0005CC-Q2; Wed, 01 Oct 2008 09:35:05 -0400 Message-ID: <48E37C88.50805@earthlink.net> Date: Wed, 01 Oct 2008 09:35:04 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Jeremy Chadwick References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> <20081001124955.GA21577@icarus.home.lan> In-Reply-To: <20081001124955.GA21577@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79ef51a053f47e564b46bae13ca01a3de3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: FreeBSD Stable Subject: Re: resource leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 13:35:06 -0000 Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: >> Jeremy Chadwick wrote: >>> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >>>> Hello List, >>>> >>>> I am running into a strange problem that points to a resource leak. >>>> The problem manifests itself after one of our remote systems has been >>>> up around 100 days. >>>> The symptom is that it appears no new processes can be spawned. If I try to >>>> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >>>> Examining log files, like cron, etc show that when this happens no more entries >>>> are written into the cron log. The unit is acting as a firewall, >>>> router and vpn appliance these functions continue to work. We have a >>>> C application that is periodically started out of a shell script that >>>> reports various information about the system, it stops reporting, >>>> while vpns, ospf routing, and ipfilter firewalling continue to work >>>> and write into their logfiles. >>>> >>>> My question is how do I monitor the various resources in the system that could >>>> prevent the spawning of a new process? >>> Periodically logging "ps -auxw" output to a file would be useful, as >>> ideally you'd gradually see the list get longer and longer over time; >>> it's possible you have many zombie processes as a result of a parent >>> which is not reaping its children (calling waitpid(2) or its friends). >>> >>> Other things that might come in useful are "fstat" and "vmstat -s". >>> >>> It sounds like your C program relies heavily on system() or execl() and >>> fork(), which is why it's affected -- while the other programs are >>> likely kernel-level. >>> >> Thanks Jeremy, >> >> I have added those commands to a periodic daily script. >> >> Another thing I have noticed is that quite often the problem seems to >> start at 2am in the morning, right when the periodic daily script runs. >> >> But I think it is coincidence and that we have reached the edge of the >> resource limit and all the jobs that get spawned by the periodic daily >> scripts pushes us over the limit. >> >> The other thing is that having logged into some of the systems that have >> been up in the 80 day range, I don't see a lot/any zombies. I just wonder >> if it is and fd leak, the fstat should point that out. > > You might find the below thread beneficial -- an individual came to the > lists stating that they were running out of fds as a result of some > Java software running amok on their systems. > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html > Thanks, but after reading the thread is there a single place in the kernel that reports the how many fds are currently in use? Does the "no more fds" message get logged in /var/log/messages or only in the kernel log buffer, since I haven't seen that message in the messages file, and since we force to have a remote user reboot the box the kernel buffer is gone. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 13:56:54 2008 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 3EFB5106564A for ; Wed, 1 Oct 2008 13:56:54 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id EC0288FC28 for ; Wed, 1 Oct 2008 13:56:53 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk14 with SMTP id 14so130581gxk.19 for ; Wed, 01 Oct 2008 06:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Xs0z8uQmGGnzI4UKItXf6MExBOyxOvP0EJWKgL5wIuI=; b=Ppl30i3RYP5pcZbnYfUz+kMaMFQuqy3+JTLXN+NBQFM2Lb3gThq3ZHy4rpcKsdIBhK DKfqv+KouhcacegXpA3+18AYQjH+RuxQwcfJVsV1L7DEd72wdq92AZXKznHQMS8XBHKV XJVFt4wmb6yUCuDfZfri82y9cYXvktl+J0OsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=vOyveVt2yj1MpprCIHDz+eVjDi3zF0M3zkad/FC2gtho1AJUFUnbyWksTQMv7K9exm OgjxzG6kVcUknvUeA83bC1+gsXuOXNZ+GUHYpLkn29F0feQ2eW2dtAtUZG/oqrgroQZ0 DDRBdnce0qKcS7fzWjq6lVPGvwLK7RafJG9tQ= Received: by 10.151.103.11 with SMTP id f11mr12092196ybm.190.1222869412949; Wed, 01 Oct 2008 06:56:52 -0700 (PDT) Received: by 10.151.11.21 with HTTP; Wed, 1 Oct 2008 06:56:52 -0700 (PDT) Message-ID: <8cb6106e0810010656y7e2ac830je8465fe344824302@mail.gmail.com> Date: Wed, 1 Oct 2008 09:56:52 -0400 From: "Josh Carroll" To: sclark46@earthlink.net In-Reply-To: <48E37C88.50805@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> <20081001124955.GA21577@icarus.home.lan> <48E37C88.50805@earthlink.net> Cc: Jeremy Chadwick , FreeBSD Stable Subject: Re: resource leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 13:56:54 -0000 > Thanks, but after reading the thread is there a single place in the kernel > that reports the how many fds are currently in use? Does the "no more fds" > message get logged in /var/log/messages or only in the kernel log buffer, > since I haven't seen that message in the messages file, and since we force > to have a remote user reboot the box the kernel buffer is gone. Just a guess, but perhaps: vmstat -m | grep -E 'filedesc|Type' Regards, Josh From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 13:59:22 2008 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 C5A4810656AE; Wed, 1 Oct 2008 13:59:22 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 52C728FC0A; Wed, 1 Oct 2008 13:59:22 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from giskard.altus-escon.com (giskard.altus-escon.com [193.78.231.1]) by altus-escon.com (8.14.2/8.14.2) with ESMTP id m91Dvhjw043851; Wed, 1 Oct 2008 15:57:48 +0200 (CEST) (envelope-from ben@altesco.nl) Message-Id: From: Ben Stuyts To: Jeremy Chadwick In-Reply-To: <20081001101227.GA17912@icarus.home.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 1 Oct 2008 15:57:43 +0200 References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> <20081001101227.GA17912@icarus.home.lan> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [193.78.231.142]); Wed, 01 Oct 2008 15:57:48 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8366/Wed Oct 1 12:44:34 2008 on mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Holger Kipp , stable@FreeBSD.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 01 Oct 2008 13:59:22 -0000 On 1 okt 2008, at 12:12, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: >> I had to disable mmap access in dovecot, or it would coredump >> periodically. (mmap_disable = yes in dovecot.conf) I found that to >> be a >> problem only on ZFS. I don't know if that's been fixed yet. Apart >> from >> that it works great. > > RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. > > Here's the proper file in cvsweb so you can see it yourself: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > > Have you tried re-enabling mmap in dovecot on a system with a kernel > build after those dates? No, thanks for pointing that out. I have missed that. My 7-stable kernel is from July 16, so I will re-enable it and report back. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 14:24:41 2008 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 55D41106568B for ; Wed, 1 Oct 2008 14:24:41 +0000 (UTC) (envelope-from lists@pingle.org) Received: from willow.pingle.org (willow.pingle.org [68.76.213.30]) by mx1.freebsd.org (Postfix) with ESMTP id 01CE68FC15 for ; Wed, 1 Oct 2008 14:24:40 +0000 (UTC) (envelope-from lists@pingle.org) Received: from localhost (unknown [127.0.0.1]) by willow.pingle.org (Postfix) with ESMTP id 2307D11419; Wed, 1 Oct 2008 10:24:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at pingle.org Received: from willow.pingle.org ([127.0.0.1]) by localhost (willow.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaP0R5UTF3Kx; Wed, 1 Oct 2008 10:24:34 -0400 (EDT) Received: from [127.0.0.1] (hpcw.hpcisp.com [68.76.213.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by willow.pingle.org (Postfix) with ESMTPSA id 752221141B; Wed, 1 Oct 2008 10:24:34 -0400 (EDT) Message-ID: <48E38821.6090606@pingle.org> Date: Wed, 01 Oct 2008 10:24:33 -0400 From: Jim Pingle User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jeremy Chadwick References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> In-Reply-To: <20080930214321.GA57024@icarus.home.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: system hangup - I'm lost 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, 01 Oct 2008 14:24:41 -0000 Jeremy Chadwick wrote: > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) I still have quite a few of these in active use. They are good workhorses. Sure, they don't have the raw computing power of newer servers, but for most of our tasks they get the job done. I also have a couple stacks of these in 2U cases sitting unused for spare parts and testing. They make great FreeBSD boxes, and handle low-moderate loads pretty well. We use them for all kinds of things: firewalls, personal/testing servers, SVN repos, monitoring and traffic graphing, name servers, you name it. To bring this back on topic, they might be old, but I have yet to encounter one single motherboard from that series that has failed on me in any way. (*knock on wood*) However, mine are all Intel L440GX boards with dual PIII CPUs in the 600-800MHz range. We try to squeeze every last bit of value out of the hardware we have. :-) Jim From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 14:44:37 2008 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 8B501106569C for ; Wed, 1 Oct 2008 14:44:37 +0000 (UTC) (envelope-from johnny64@swissjabber.org) Received: from www.real-net.sk (www.real-net.sk [89.202.239.1]) by mx1.freebsd.org (Postfix) with ESMTP id 087F68FC14 for ; Wed, 1 Oct 2008 14:44:36 +0000 (UTC) (envelope-from johnny64@swissjabber.org) Received: from localhost (unknown [127.0.0.1]) by www.real-net.sk (Postfix) with ESMTP id 1A7D914BD472 for ; Wed, 1 Oct 2008 14:25:00 +0000 (UTC) X-Virus-Scanned: amavisd-new 2.6.1 (20080629) at real-net.sk Received: from www.real-net.sk ([127.0.0.1]) by localhost (www.real-net.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCYTHSP4CBjf for ; Wed, 1 Oct 2008 16:24:55 +0200 (CEST) Received: from georg.localdomain (unknown [10.200.9.170]) by www.real-net.sk (Postfix) with ESMTPS id 884F014BD483; Wed, 1 Oct 2008 16:24:54 +0200 (CEST) Received: from georg.localdomain (localhost [127.0.0.1]) by georg.localdomain (8.14.3/8.14.3) with ESMTP id m91EOqnZ000696; Wed, 1 Oct 2008 16:24:53 +0200 (CEST) (envelope-from johnny64@swissjabber.org) Received: (from johnny64@localhost) by georg.localdomain (8.14.3/8.14.3/Submit) id m91EOpek000235; Wed, 1 Oct 2008 16:24:51 +0200 (CEST) (envelope-from johnny64@swissjabber.org) X-Authentication-Warning: georg.localdomain: johnny64 set sender to johnny64@swissjabber.org using -f Date: Wed, 1 Oct 2008 16:24:50 +0200 From: "(-K JohnNy" To: Edwin Groothuis Message-ID: <20081001142450.GA58407@georg.localdomain> References: <20080928054620.GA80250@k7.mavetju> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20080928054620.GA80250@k7.mavetju> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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, 01 Oct 2008 14:44:37 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 28, 2008 at 03:46:20PM +1000, Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. >=20 > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. >=20 > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) >=20 > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. >=20 > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. >=20 > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". >=20 > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! >=20 > Edwin I found another bug. The new top doesn't handle newlines in full commandlines correctly -- if there is a command whose commandline contains a newline, which is quite common while some compilation is in progress, it is just printed out as it is, breaking the one-process-per-line layout. --=20 (-K JohnNy alias Partial Derivative =E2=88=82 [home] http://johnny64.fixinko.sk/ [icq] 338328204 [abandoned] [jabber] JohnNy64@swissjabber.org [skype] JohnNy64-konik [abandoned] --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjjiDEACgkQ11l9uIBrcFSzUQCfQ+lWU+JkrLBHGRApyZni/oTx P+cAoJT9k1QBqACGNSpVZ8M679gvHHLu =Gcl2 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 15:29:49 2008 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 2F4A91065688 for ; Wed, 1 Oct 2008 15:29:49 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 1B7FA8FC0A for ; Wed, 1 Oct 2008 15:29:46 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 96285 invoked by uid 89); 1 Oct 2008 15:29:44 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 1 Oct 2008 15:29:44 -0000 Date: Wed, 1 Oct 2008 17:29:43 +0200 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20081001172943.99e9d494.lehmann@ans-netz.de> In-Reply-To: <20080929221408.54e6a03a.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: system hangup - I'm lost 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, 01 Oct 2008 15:29:49 -0000 Hi, today I'd a crash again - I was not able to get a crash dump (thought a "panic" at the end of the kdb would do it but didn't - should have called dumpon before ;)) - so here now the information I was able to retrieve: Ok, what I've got so far is wrinting stuff out to the console when the system hangs up: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 ... and now the debugger stuff: KDB: enter: manual escape to debugger [thread pid 40 tid 100048 ] Stopped at kdb_enter+0x30: leave db> sh locks exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> sh alllocks Process 40 (irq1: atkbd0) thread 0xc4503a80 (100048) exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> so there are no locks except the one I caused but anyhow: db> bt 100048 Tracing pid 40 tid 100048 td 0xc4503a80 kdb_enter(c077aee6,4,1,0,1,...) at kdb_enter+0x30 scgetc(c0842b60,2,de391c88,c05ad0b7,c4609340,...) at scgetc+0x575 sckbdevent(c0823740,0,c0842b60,c07c73c0,8,...) at sckbdevent+0x210 atkbd_intr(c0823740,0,de391cd8,c05695b8,c0823740,...) at atkbd_intr+0xa1 atkbdintr(c0823740,0,c076448a,2a9,8,...) at atkbdintr+0x21 ithread_execute_handlers(c460cc90,c4449680,c076448a,30e,c4503a80,...) at ithread_execute_handlers+0x108 ithread_loop (c45f66c0,de391d38,c07642ea,30c,0,...) at ithread_loop+0x64 fork_exit (c05696b0,c45f66c0,de391d38) at fork_exit+0x78 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde391d6c, ebp = 0 --- db> sh pcpu cpuid = 0 curthread = 0xc4503a80: pid 40 "irq1: atkbd0" curpcb = 0xde391d90 fpcurthread = none idlethread = 0xc444c780: pid 11 "idle: cpu0" APIC ID = 1 currentldt = 0x50 spin locks held: and now the output of ps (beware, it is long, no idea why there are so many cron - maybe the crond still schedules but they don't get processed?) show lockedvnods follows afterwards db> ps pid ppid pgrp uid state wmesg wchan cmd 57919 57918 692 0 SV ufs 0xc47857c8 cron 57918 692 692 0 S ppwait 0xc6e63a78 cron 57917 57916 692 0 SV ufs 0xc47857c8 cron 57916 692 692 0 S ppwait 0xc6e63c90 cron 57915 57914 692 0 SV ufs 0xc47857c8 cron 57914 692 692 0 S ppwait 0xc6eb3000 cron 57913 57912 692 0 SV ufs 0xc47857c8 cron 57912 692 692 0 S ppwait 0xc70a9430 cron 57911 57908 692 0 SV ufs 0xc47857c8 cron 57910 57907 692 0 SV ufs 0xc47857c8 cron 57909 57906 692 0 SV ufs 0xc47857c8 cron 57908 692 692 0 S ppwait 0xc6eb3648 cron 57907 692 692 0 S ppwait 0xc6eb3860 cron 57906 692 692 0 S ppwait 0xc6eb3a78 cron 57905 686 686 25 S ufs 0xc4953388 sendmail 57904 57902 692 0 SV ufs 0xc47857c8 cron 57903 57901 692 0 SV ufs 0xc47857c8 cron 57902 692 692 0 S ppwait 0xc49a4430 cron 57901 692 692 0 S ppwait 0xc49a4648 cron 57900 57899 692 0 SV ufs 0xc47857c8 cron 57899 692 692 0 S ppwait 0xc49a4860 cron 57898 57897 692 0 SV ufs 0xc47857c8 cron 57897 692 692 0 S ppwait 0xc49a4a78 cron 57896 57895 692 0 SV ufs 0xc47857c8 cron 57895 692 692 0 S ppwait 0xc49a4c90 cron 57894 57893 692 0 SV ufs 0xc47857c8 cron 57893 692 692 0 S ppwait 0xc6b7c648 cron 57892 57891 692 0 SV ufs 0xc47857c8 cron 57891 692 692 0 S ppwait 0xc66bc430 cron 57890 57889 692 0 SV ufs 0xc47857c8 cron 57889 692 692 0 S ppwait 0xc6b7c860 cron 57888 57887 692 0 SV ufs 0xc47857c8 cron 57887 692 692 0 S ppwait 0xc66bc860 cron 57886 686 686 25 S ufs 0xc4953388 sendmail 57885 57884 692 0 SV ufs 0xc47857c8 cron 57884 692 692 0 S ppwait 0xc66bca78 cron 57883 57882 692 0 SV ufs 0xc47857c8 cron 57882 692 692 0 S ppwait 0xc66bcc90 cron 57881 57880 692 0 SV ufs 0xc47857c8 cron 57880 692 692 0 S ppwait 0xc6a65000 cron 57879 57878 692 0 SV ufs 0xc47857c8 cron 57878 692 692 0 S ppwait 0xc6a65218 cron 57877 57876 692 0 SV ufs 0xc47857c8 cron 57876 692 692 0 S ppwait 0xc6a65430 cron 57875 57874 692 0 SV ufs 0xc47857c8 cron 57874 692 692 0 S ppwait 0xc6a65648 cron 57873 57872 692 0 SV ufs 0xc47857c8 cron 57872 692 692 0 S ppwait 0xc48ed000 cron 57871 57867 692 0 SV ufs 0xc47857c8 cron 57870 57868 692 0 SV ufs 0xc47857c8 cron 57869 57866 692 0 SV ufs 0xc47857c8 cron 57868 692 692 0 S ppwait 0xc48ed430 cron 57867 692 692 0 S ppwait 0xc48ed648 cron 57866 692 692 0 S ppwait 0xc48ed860 cron 57865 686 686 25 S ufs 0xc4953388 sendmail 57864 57862 692 0 SV ufs 0xc47857c8 cron 57862 692 692 0 S ppwait 0xc4910000 cron 57861 692 692 0 S ppwait 0xc4910218 cron 57860 57859 692 0 SV ufs 0xc47857c8 cron 57859 692 692 0 S ppwait 0xc4910430 cron 57858 57857 692 0 SV ufs 0xc47857c8 cron 57857 692 692 0 S ppwait 0xc4910648 cron 57856 57855 692 0 SV ufs 0xc47857c8 cron 57855 692 692 0 S ppwait 0xc4910860 cron 57854 57853 692 0 SV ufs 0xc47857c8 cron 57853 692 692 0 S ppwait 0xc4910a78 cron 57852 57851 692 0 SV ufs 0xc47857c8 cron 57851 692 692 0 S ppwait 0xc4910c90 cron 57850 57849 692 0 SV ufs 0xc47857c8 cron 57849 692 692 0 S ppwait 0xc49a4000 cron 57848 57847 692 0 SV ufs 0xc47857c8 cron 57847 692 692 0 S ppwait 0xc49a4218 cron 57846 686 686 25 S ufs 0xc4953388 sendmail 57845 57844 692 0 SV ufs 0xc47857c8 cron 57844 692 692 0 S ppwait 0xc4e47860 cron 57843 57842 692 0 SV ufs 0xc47857c8 cron 57842 692 692 0 S ppwait 0xc66cd430 cron 57841 57840 692 0 SV ufs 0xc47857c8 cron 57840 692 692 0 S ppwait 0xc66cd648 cron 57839 57838 692 0 SV ufs 0xc47857c8 cron 57838 692 692 0 S ppwait 0xc4e59218 cron 57837 57836 692 0 SV ufs 0xc47857c8 cron 57836 692 692 0 S ppwait 0xc5cd6860 cron 57835 57834 692 0 SV ufs 0xc47857c8 cron 57834 692 692 0 S ppwait 0xc5cd5430 cron 57833 57832 692 0 SV ufs 0xc47857c8 cron 57832 692 692 0 S ppwait 0xc66c8c90 cron 57831 57828 692 0 SV ufs 0xc47857c8 cron 57830 57827 692 0 SV ufs 0xc47857c8 cron 57829 57826 692 0 SV ufs 0xc47857c8 cron 57828 692 692 0 S ppwait 0xc691e218 cron 57827 692 692 0 S ppwait 0xc4bd3218 cron 57826 692 692 0 S ppwait 0xc66c8430 cron 57825 686 686 25 S ufs 0xc4953388 sendmail 57824 57822 692 0 SV ufs 0xc47857c8 cron 57823 57821 692 0 SV ufs 0xc47857c8 cron 57822 692 692 0 S ppwait 0xc66cd860 cron 57821 692 692 0 S ppwait 0xc474ac90 cron 57820 57819 692 0 SV ufs 0xc47857c8 cron 57819 692 692 0 S ppwait 0xc4cdf860 cron 57818 57817 692 0 SV ufs 0xc47857c8 cron 57817 692 692 0 S ppwait 0xc4e5f430 cron 57816 57815 692 0 SV ufs 0xc47857c8 cron 57815 692 692 0 S ppwait 0xc5cd5000 cron 57814 57813 692 0 SV ufs 0xc47857c8 cron 57813 692 692 0 S ppwait 0xc4e47430 cron 57812 57811 692 0 SV ufs 0xc47857c8 cron 57811 692 692 0 S ppwait 0xc4bcd648 cron 57810 57809 692 0 SV ufs 0xc47857c8 cron 57809 692 692 0 S ppwait 0xc4cdfa78 cron 57808 57807 692 0 SV ufs 0xc47857c8 cron 57807 692 692 0 S ppwait 0xc4a34a78 cron 57806 686 686 25 S ufs 0xc4953388 sendmail 57805 57804 692 0 SV ufs 0xc47857c8 cron 57804 692 692 0 S ppwait 0xc6923648 cron 57803 57802 692 0 SV ufs 0xc47857c8 cron 57802 692 692 0 S ppwait 0xc4cdf430 cron 57801 57800 692 0 SV ufs 0xc47857c8 cron 57800 692 692 0 S ppwait 0xc691e430 cron 57799 57798 692 0 SV ufs 0xc47857c8 cron 57798 692 692 0 S ppwait 0xc4e59860 cron 57797 57796 692 0 SV ufs 0xc47857c8 cron 57796 692 692 0 S ppwait 0xc4e5fa78 cron 57795 57794 692 0 SV ufs 0xc47857c8 cron 57794 692 692 0 S ppwait 0xc4e4cc90 cron 57793 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57792 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57791 57790 692 0 SV ufs 0xc47857c8 cron 57790 692 692 0 S ppwait 0xc4e59000 cron 57789 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57788 57785 57788 0 SVs ufs 0xc47857c8 cron 57787 57784 57787 2 SVs ufs 0xc47857c8 cron 57786 57783 57786 0 SVs ufs 0xc47d9168 cron 57785 692 692 0 S ppwait 0xc66cda78 cron 57784 692 692 0 S ppwait 0xc66c8000 cron 57783 692 692 0 S ppwait 0xc66cd000 cron 57782 686 686 25 S biord 0xd3e374b8 sendmail 57780 57778 57778 2 S ufs 0xc6ebd9e8 sh 57778 57776 57778 2 Ss wait 0xc4a33000 sh 57776 692 692 0 S piperd 0xc719e660 cron 57772 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57771 1035 1035 0 SLJ swread 0xc1639568 httpd 57770 57769 57770 0 SVsJ ufs 0xc5502058 cron 57769 1048 1048 0 SJ ppwait 0xc4e5c000 cron 57765 57764 57765 0 SVsJ getblk 0xd3eba538 cron 57764 1048 1048 0 SJ ppwait 0xc5cd6000 cron 57762 57761 57761 2 S biord 0xd3e875f8 sh 57761 57760 57761 2 Ss wait 0xc4bd3a78 sh 57760 692 692 0 S piperd 0xc68137f8 cron 57759 936 936 0 SJ biowr 0xd3eba4d8 rateup 57732 51526 46607 0 S+ biowr 0xd3e5b170 sh 51526 51268 46607 0 S+ wait 0xc4cdf000 sh 51268 51267 46607 0 S+ wait 0xc66cd218 sh 51267 51264 46607 0 S+ wait 0xc5cd5c90 sh 51264 49494 46607 0 S+ select 0xc0815024 make 49494 46607 46607 0 S+ wait 0xc4bcd000 sh 78290 1035 1035 80 SJ ufs 0xc47668d8 httpd 78289 1035 1035 80 SJ ufs 0xc4ad87c8 httpd 78282 1035 1035 80 SJ ufs 0xc47d1168 httpd 75486 1035 1035 80 SJ ufs 0xc47d1168 httpd 72716 1035 1035 80 SJ ufs 0xc47d1168 httpd 72715 1035 1035 80 SJ ufs 0xc4ac5168 httpd 72603 1035 1035 80 SJ ufs 0xc4ac5388 httpd 70352 1035 1035 80 SJ ufs 0xc47d1168 httpd 53179 53008 53179 0 S+ ufs 0xc47857c8 csh 53008 49451 53008 1000 S+ wait 0xc4bcda78 su 49451 49449 49451 1000 Ss+ pause 0xc4e5c67c tcsh 49449 49270 49270 1000 S select 0xc0815024 sshd 49270 678 49270 0 Ss sbwait 0xc508179c sshd 46607 1208 46607 0 S+ wait 0xc66c8860 sh 1208 1206 1208 0 Ss+ pause 0xc4bd3cc4 csh 1206 1 1206 0 Ss select 0xc0815024 screen 1151 1117 1151 0 S+ ttyin 0xc4616010 csh 1132 928 928 89 SJ select 0xc0815024 perl5.8.8 1131 928 928 89 SJ select 0xc0815024 perl5.8.8 1118 1 1 0 S ttydcd 0xc4614000 getty 1117 1 1117 0 Ss+ wait 0xc4bcdc90 login 1116 1 1116 0 Ss+ ttyin 0xc4613010 getty 1115 1 1115 0 Ss+ ttyin 0xc461f410 getty 1114 1 1114 0 Ss+ ttyin 0xc45fc810 getty 1113 1 1113 0 Ss+ ttyin 0xc4615010 getty 1112 1 1112 0 Ss+ ttyin 0xc461ec10 getty 1111 1 1111 0 Ss+ ttyin 0xc461e810 getty 1110 1 1110 0 Ss+ ttyin 0xc461d810 getty 1109 1 1109 0 Ss+ ttyin 0xc461d410 getty 1093 1 1093 0 Ss select 0xc0815024 inetd 1092 1 1092 1000 SsJ ufs 0xc47d1168 fetchmail 1048 1 1048 0 SsJ ufs 0xc498a9e8 cron 1043 1 1043 0 SsJ select 0xc0815024 sshd 1035 1 1035 0 SsJ nanslp 0xc07c7cac httpd 1019 1 1019 0 SsJ (threaded) bacula-fd 100137 S kserel 0xc475fc94 bacula-fd 100158 S kserel 0xc475fc94 bacula-fd 100164 S select 0xc0815024 bacula-fd 100162 S ksesigwa 0xc49b1350 bacula-fd 1001 1000 1001 0 S+J select 0xc0815024 couriertcpd 1000 1 1000 0 S+J piperd 0xc48e5660 courierlogger 988 987 988 0 S+J select 0xc0815024 couriertcpd 987 1 987 0 S+J piperd 0xc4819cc0 courierlogger 976 975 976 0 S+J select 0xc0815024 couriertcpd 975 1 975 0 S+J piperd 0xc4a72198 courierlogger 971 946 945 0 S+J select 0xc0815024 authdaemond 970 946 945 0 S+J select 0xc0815024 authdaemond 969 946 945 0 S+J select 0xc0815024 authdaemond 968 946 945 0 S+J select 0xc0815024 authdaemond 967 946 945 0 S+J select 0xc0815024 authdaemond 946 945 945 0 S+J select 0xc0815024 authdaemond 945 1 945 0 S+J piperd 0xc48197f8 courierlogger 936 1 936 0 SsJ piperd 0xc6813cc0 perl 928 1 928 0 SsJ select 0xc0815024 perl5.8.8 926 1 907 0 S+J select 0xc0815024 sqwebmaild 924 1 907 0 S+J select 0xc0815024 sqwebmaild 922 1 907 0 S+J select 0xc0815024 sqwebmaild 920 1 907 0 S+J select 0xc0815024 sqwebmaild 918 1 907 0 S+J select 0xc0815024 sqwebmaild 908 907 907 0 S+J select 0xc0815024 sqwebmaild 907 1 907 0 S+J piperd 0xc48e5000 courierlogger 904 897 877 85 SJ piperd 0xc476fcc0 qmail-clean 903 897 877 86 SJ select 0xc0815024 qmail-rspawn 902 897 877 0 SJ select 0xc0815024 qmail-lspawn 901 897 877 83 SJ piperd 0xc4763330 multilog 897 887 877 87 SJ biord 0xd3e299a0 qmail-send 896 886 877 83 SJ piperd 0xc48e5198 multilog 895 885 877 89 SJ accept 0xc4a22302 tcpserver 894 883 877 0 SJ accept 0xc4a2772e tcpserver 893 888 877 83 SJ piperd 0xc47627f8 multilog 892 884 877 83 SJ piperd 0xc48e5330 multilog 888 879 877 0 SJ select 0xc0815024 supervise 887 879 877 0 SJ select 0xc0815024 supervise 886 879 877 0 SJ select 0xc0815024 supervise 885 879 877 0 SJ select 0xc0815024 supervise 884 879 877 0 SJ select 0xc0815024 supervise 883 879 877 0 SJ select 0xc0815024 supervise 880 1 877 0 SJ piperd 0xc476f330 readproctitle 879 1 877 0 SJ ufs 0xc47d1168 svscan 837 1 837 0 SsJ select 0xc0815024 syslogd 692 1 692 0 Ss nanslp 0xc07c7cac cron 686 1 686 25 Ss pause 0xc47f267c sendmail 683 1 683 0 Ss select 0xc0815024 sendmail 678 1 678 0 Ss select 0xc0815024 sshd 663 1 663 910 Ss (threaded) bacula-dir 100118 S kserel 0xc45d4754 bacula-dir 100121 S kserel 0xc45d4754 bacula-dir 100160 S select 0xc0815024 bacula-dir 100127 S ksesigwa 0xc47f4bb0 bacula-dir 657 1 657 0 Ss (threaded) bacula-fd 100123 S kserel 0xc45d4b14 bacula-fd 100114 S kserel 0xc45d4b14 bacula-fd 100163 S select 0xc0815024 bacula-fd 100115 S ksesigwa 0xc47f2568 bacula-fd 650 1 650 910 Ss (threaded) bacula-sd 100143 S kserel 0xc4450874 bacula-sd 100281 S kserel 0xc4450874 bacula-sd 100116 S select 0xc0815024 bacula-sd 100112 S ksesigwa 0xc474abb0 bacula-sd 649 623 620 88 S+ (threaded) mysqld 100119 S kserel 0xc45d4814 mysqld 100165 S select 0xc0815024 mysqld 100089 S kserel 0xc45d4814 mysqld 100125 S kserel 0xc44506f4 mysqld 100124 S sigwait 0xe4239c0c mysqld 100122 S ksesigwa 0xc47f4780 mysqld 623 1 620 88 S+ wait 0xc4760218 sh 610 1 610 0 Ss select 0xc0815024 usbd 588 1 588 0 Ss biord 0xd3d73060 ntpd 578 1 578 0 Ss select 0xc0815024 lpd 570 1 51 0 S+ select 0xc0815024 3dm2 569 555 555 0 S pause 0xc474a894 smbd 555 1 555 0 Ss select 0xc0815024 smbd 551 1 551 0 Ss select 0xc0815024 nmbd 532 1 531 0 S select 0xc0815024 snmpd 519 513 513 0 S rpcsvc 0xc4722a6c rpc.lockd 518 513 513 0 S nfslockd 0xc081d3c8 rpc.lockd 513 1 513 0 Ss select 0xc0815024 rpc.lockd 506 1 506 0 Ss select 0xc0815024 rpc.statd 500 496 496 0 S - 0xc4560c00 nfsd 499 496 496 0 S - 0xc46e6200 nfsd 498 496 496 0 S - 0xc46cec00 nfsd 497 496 496 0 S - 0xc4551a00 nfsd 496 1 496 0 Ss accept 0xc4802b5a nfsd 488 1 488 0 Ss ufs 0xc47857c8 mountd 452 1 452 0 Ss select 0xc0815024 rpcbind 435 1 435 0 Ss biord 0xd3ea6488 syslogd 377 1 377 0 Ss select 0xc0815024 devd 139 1 139 0 Ss pause 0xc474a034 adjkerntz 50 0 0 0 SL - 0xe2618cf8 [schedcpu] 49 0 0 0 SL sdflush 0xc0822714 [softdepflush] 48 0 0 0 SL vlruwt 0xc45d2a78 [vnlru] 47 0 0 0 SL getblk 0xd3e47410 [syncer] 46 0 0 0 SL psleep 0xc08155a0 [bufdaemon] 45 0 0 0 SL pgzero 0xc0823724 [pagezero] 44 0 0 0 SL psleep 0xc082322c [vmdaemon] 43 0 0 0 SL psleep 0xc08231e8 [pagedaemon] 42 0 0 0 WL [swi0: sio] 41 0 0 0 SL - 0xc45f283c [fdc0] 40 0 0 0 RL CPU 0 [irq1: atkbd0] 39 0 0 0 SL usbevt 0xc45e6210 [usb4] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 SL usbevt 0xc44f1210 [usb3] 35 0 0 0 WL [irq16: ehci0] 34 0 0 0 SL usbevt 0xc45da210 [usb2] 33 0 0 0 WL [irq23: ohci2] 32 0 0 0 SL usbevt 0xc45d8210 [usb1] 31 0 0 0 WL [irq22: ohci1] 30 0 0 0 SL usbtsk 0xc07c4364 [usbtask] 29 0 0 0 SL usbevt 0xc4577210 [usb0] 28 0 0 0 WL [irq21: fxp0 ohci0+] 27 0 0 0 SL idle 0xc4560600 [aic_recovery1] 26 0 0 0 SL idle 0xc4560600 [aic_recovery1] 25 0 0 0 SL idle 0xc4560400 [aic_recovery0] 24 0 0 0 WL [irq19: ahc0 ahc1] 23 0 0 0 SL idle 0xc4560400 [aic_recovery0] 22 0 0 0 WL [irq18: twa0] 21 0 0 0 WL [irq9: acpi0] 20 0 0 0 WL [swi6: Giant taskq] 19 0 0 0 WL [swi6: task queue] 18 0 0 0 WL [swi2: cambio] 17 0 0 0 SL ccb_scan 0xc07c0d04 [xpt_thrd] 9 0 0 0 SL - 0xc44a5700 [kqueue taskq] 8 0 0 0 SL - 0xc44a5800 [acpi_task_2] 7 0 0 0 SL - 0xc44a5800 [acpi_task_1] 6 0 0 0 SL - 0xc44a5800 [acpi_task_0] 16 0 0 0 WL [swi5: +] 5 0 0 0 SL - 0xc44a5980 [thread taskq] 15 0 0 0 SL - 0xc07c3c40 [yarrow] 4 0 0 0 SL - 0xc07c4c68 [g_down] 3 0 0 0 SL - 0xc07c4c64 [g_up] 2 0 0 0 SL - 0xc07c4c5c [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 WL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 10 0 0 0 RL CPU 1 [idle: cpu1] 1 0 1 0 SLs wait 0xc4451000 [init] 0 0 0 0 WLs [swapper] db> show lockedvnods Locked vnodes 0xc4785770: tag ufs, type VDIR usecount 1, writecount 0, refcount 67 mountedhere 0 flags (VV_ROOT) v_object 0xc6401000 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc4bd0180 (pid 57786) with 65 pending ino 2, on dev da0s1d 0xc47da660: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xc5f8239c ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc4e48c00 (pid 57780) ino 32899, on dev da0s1d 0xc47d9110: tag ufs, type VDIR usecount 5, writecount 0, refcount 9 mountedhere 0 flags () v_object 0xc6f788c4 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc47f6900 (pid 588) with 1 pending ino 49347, on dev da0s1d 0xc4827110: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xc481d948 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xc4611600 (pid 435) ino 49480, on dev da0s1d 0xc4953330: tag ufs, type VDIR usecount 15, writecount 0, refcount 18 mountedhere 0 flags () v_object 0xc4960318 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc5cdac00 (pid 57782) with 6 pending ino 49359, on dev da0s1d 0xc6ebd990: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4e4a480 (pid 57762) with 1 pending ino 32900, on dev da0s1d 0xc47b6aa0: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xc45d3600 (pid 47) 0xc5540330: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc6cca840 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc4f19000 (pid 57732) ino 1013632, on dev da0s1f 0xc78e6dd0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4f19000 (pid 57732) ino 1016580, on dev da0s1f 0xc47d1110: tag ufs, type VDIR usecount 165, writecount 0, refcount 168 mountedhere 0 flags () v_object 0xc4a2fdec ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4951480 (pid 1048) with 6 pending ino 9212984, on dev da0s1g 0xc47d2000: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc51f5d68 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc5cd8d80 (pid 72603) ino 9213777, on dev da0s1g 0xc498a990: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc5c4839c ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4e5e000 (pid 57770) with 1 pending ino 9213027, on dev da0s1g 0xc4ac5330: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f5dec ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4e4a000 (pid 72715) with 1 pending ino 9213787, on dev da0s1g 0xc4ac5110: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f6000 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a35300 (pid 78289) with 1 pending ino 9214698, on dev da0s1g 0xc4ad8770: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f6084 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a35600 (pid 78290) with 1 pending ino 9214827, on dev da0s1g 0xc4766880: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc5976108 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) with 1 pending ino 9214859, on dev da0s1g 0xc5502000: tag ufs, type VREG usecount 0, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc6979528 ref 0 pages 10 lock type ufs: EXCL (count 1) by thread 0xc6cd9900 (pid 57765) with 1 pending ino 9213198, on dev da0s1g 0xc7327cc0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc73d439c ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc47f7780 (pid 897) ino 19661150, on dev da0s1g 0xc6447770: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) ino 9213267, on dev da0s1g 0xc47d1dd0: tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 flags (VV_ROOT) v_object 0xc51f5d68 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc5cd8d80 (pid 72603) vp=0xc47d1dd0, lowervp=0xc47d2000 0xc594f110: tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) with 1 pending vp=0xc594f110, lowervp=0xc4766880 0xc7096660: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a35600 (pid 78290) with 1 pending vp=0xc7096660, lowervp=0xc4ad8770 0xc6183660: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a35300 (pid 78289) with 1 pending vp=0xc6183660, lowervp=0xc4ac5110 0xc6f2e220: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4e4a000 (pid 72715) with 1 pending vp=0xc6f2e220, lowervp=0xc4ac5330 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 15:32:03 2008 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 517D71065687 for ; Wed, 1 Oct 2008 15:32:03 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 990698FC0A for ; Wed, 1 Oct 2008 15:32:02 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 96530 invoked by uid 89); 1 Oct 2008 15:32:00 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 1 Oct 2008 15:32:00 -0000 Date: Wed, 1 Oct 2008 17:31:59 +0200 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20081001173159.c97d792d.lehmann@ans-netz.de> In-Reply-To: <20081001051008.GA65754@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> <20081001065309.3e7e108e.lehmann@ans-netz.de> <20081001051008.GA65754@icarus.home.lan> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Bartosz Stec Subject: Re: system hangup - I'm lost 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, 01 Oct 2008 15:32:03 -0000 Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: > > Because it is a Server Board it offers a lot of managing features and > > other nice things like serial console at bootup and system monitoring > > features... but all unsupported withn FreeBSDs software ;) > > Really? That's interesting, because Charles Sprickman told me that > there is no hardware monitoring information in the BIOS if you go in > there. Most motherboards provide that in the BIOS as a centralised > place above all else. You are right - I could have sworn that there was such an screen in the BIOS but all I can see is for setting up stuff like enabling eventlog and posting it through a modem connection and so on - server specific stuff - but no display screen for "health information"... So you where right ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 15:45:54 2008 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 8CCFA106568C for ; Wed, 1 Oct 2008 15:45:54 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (dev.null.cz [89.185.226.27]) by mx1.freebsd.org (Postfix) with ESMTP id F19BD8FC1F for ; Wed, 1 Oct 2008 15:45:53 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.13.1/8.13.1) with ESMTP id m91FHGxI069134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Oct 2008 17:17:21 +0200 (CEST) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.13.1/8.13.1/Submit) id m91FHG2L069133 for freebsd-stable@freebsd.org; Wed, 1 Oct 2008 17:17:16 +0200 (CEST) (envelope-from buki) Date: Wed, 1 Oct 2008 17:17:16 +0200 From: "Marek 'Buki' =?iso-8859-2?Q?Kozlovsk=FD?=" To: freebsd-stable@freebsd.org Message-ID: <20081001151716.GW2707@dev.null.cz> References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> <20080928115401.GU3210@k7.mavetju> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wtjvnLv0o8UUzur2" Content-Disposition: inline In-Reply-To: <20080928115401.GU3210@k7.mavetju> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV 0.88.7/7593/Mon Jun 30 23:00:22 2008 on dev.null.cz X-Virus-Status: Clean Subject: Re: Request for testing - top 3.8b1 in the base 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, 01 Oct 2008 15:45:54 -0000 --wtjvnLv0o8UUzur2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 28, 2008 at 09:54:01PM +1000, Edwin Groothuis wrote: > On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: > > > to reproduce it (if possible). Thanks for your help! > > Is this 7.0+ only? I run 6.3 and I see the following when I start it: > >=20 > > last pid: -1077944144; loa 0.52, 0.28, 0.26; > > up 11+15:31:33 = 11:33:05 > > 0 processes: > > CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle > > Kernel: 1 intr > > Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M F= ree > > Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse > > sysctlnametomib: No such file or directory > >=20 > > And no processes. >=20 > I didn't expect it not to work on 6.x, I will play around with it > tomorrow to see if it makes sense. Actually, I'm seeing the same behaviour on 7.0: last pid: 0943900; loa 0.98, 0.94, 0.57; = up 7+23:09:54 17:13:22 0 processes: CPU: 19.7% user, 0.0% nice, 40.0% system, 0.0% interrupt, 40.3% idle Kernel: 1687 ctxsw, 14864 trap, 6 intr, 204 soft, 235 fork, 14526 flt, 1171= 8 fr Mem: 78M Active, 690M Inact, 184M Wired, 29M Cache, 111M Buf, 11M Free Swap: 2048M Total, 136K Used, 2048M Free sysctl: Invalid argument PID USERNAME THR PRI NICE SIZE RES STATE FLG C TIME CPU COMMAND [no processes] |17:15:30|buki@hal9000:/home/buki/temp/3.8b1/usr.bin/top>uname -srmi FreeBSD 7.0-RELEASE-p2 i386 GENERIC > Edwin >=20 > --=20 > Edwin Groothuis | Personal website: http://www.mavetju.org > edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ Buki --=20 PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net --wtjvnLv0o8UUzur2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI45R8PzhIkpLLm08RAmdeAJ9S2/L2qJHXJRFaLYOZ2X45C9uyvwCghmK7 3q7NKS/A2xIxd1etJOeTfRk= =VZBf -----END PGP SIGNATURE----- --wtjvnLv0o8UUzur2-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 16:48:57 2008 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 6DCCF1065699; Wed, 1 Oct 2008 16:48:57 +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 4494B8FC1B; Wed, 1 Oct 2008 16:48:57 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Kl4si-0001qH-Ev; Wed, 01 Oct 2008 12:48:56 -0400 Date: Wed, 1 Oct 2008 12:48:56 -0400 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20081001164856.GA6478@in-addr.com> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081001115046.GA20384@icarus.home.lan> Cc: Stephen Clark , FreeBSD Stable Subject: Re: resource leak 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, 01 Oct 2008 16:48:57 -0000 On Wed, Oct 01, 2008 at 04:50:46AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > > Hello List, > > > > I am running into a strange problem that points to a resource leak. The > > problem manifests itself after one of our remote systems has been up > > around 100 days. > > The symptom is that it appears no new processes can be spawned. If I try to > > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > > Examining log files, like cron, etc show that when this happens no more entries > > are written into the cron log. The unit is acting as a firewall, router > > and vpn appliance these functions continue to work. We have a C > > application that is periodically started out of a shell script that > > reports various information about the system, it stops reporting, while > > vpns, ospf routing, and ipfilter firewalling continue to work and write > > into their logfiles. > > > > My question is how do I monitor the various resources in the system that could > > prevent the spawning of a new process? > > Periodically logging "ps -auxw" output to a file would be useful, as > ideally you'd gradually see the list get longer and longer over time; > it's possible you have many zombie processes as a result of a parent > which is not reaping its children (calling waitpid(2) or its friends). "ps alxw" may be of interest in addition to "ps auxw" as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where "ls /" hangs, and at that point you're stuck with an unresponsive box. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 17:56:30 2008 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 20E3F1065693; Wed, 1 Oct 2008 17:56:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ED2B28FC1A; Wed, 1 Oct 2008 17:56:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 851A746B09; Wed, 1 Oct 2008 13:56:29 -0400 (EDT) Date: Wed, 1 Oct 2008 18:56:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gary Palmer In-Reply-To: <20081001164856.GA6478@in-addr.com> Message-ID: References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stephen Clark , Jeremy Chadwick , FreeBSD Stable Subject: Re: resource leak 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, 01 Oct 2008 17:56:30 -0000 On Wed, 1 Oct 2008, Gary Palmer wrote: >> Periodically logging "ps -auxw" output to a file would be useful, as >> ideally you'd gradually see the list get longer and longer over time; it's >> possible you have many zombie processes as a result of a parent which is >> not reaping its children (calling waitpid(2) or its friends). > > "ps alxw" may be of interest in addition to "ps auxw" as it displays what > the processes are waiting on. It could conceivably be a problem of some > kind at the filesystem level. I've seen situations before where a problem > escalates to the point where "ls /" hangs, and at that point you're stuck > with an unresponsive box. If you want an even greater level of detail than ps -l, you can use procstat -k to generate kernel stack traces for all user/kernel threads. Wait channels are very useful, but they only tell you what the code that invoked the wait thinks it is for, not how that code was reached. A classic example is waiting on an exhausted UMA zone -- you get a uma wait channel, but no indication of what subsystem performed the memory allocation... This required FreeBSD 7.1 and higher, however. (Obviously, the same can be done easily using DDB, but that's hard on a box without a serial console, and requires interrupting the flow of the operating system, compiling with DDB, etc). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 18:06:38 2008 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 BDD99106568D for ; Wed, 1 Oct 2008 18:06:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 85E078FC20 for ; Wed, 1 Oct 2008 18:06:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id m91I6aJm024915; Wed, 1 Oct 2008 14:06:36 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m91I6a4Z029695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 14:06:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200810011806.m91I6a4Z029695@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Oct 2008 14:06:28 -0400 To: Fernan Aguero From: Mike Tancsa In-Reply-To: <20081001164001.GA81847@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200809302351.m8UNpjs7024916@lava.sentex.ca> <20081001164001.GA81847@iib.unsam.edu.ar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-stable@freebsd.org Subject: Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 01 Oct 2008 18:06:38 -0000 At 12:40 PM 10/1/2008, Fernan Aguero wrote: >Thanks for the tip. > >Unfortunately, the PowerEdge SC1435 BIOS does not allow much >options here ... I can set the embedded SATA to 'ATA mode' >(corruption hell, tested with 7.1 BETA) or just turn it >'OFF' in which case the FreeBSD installer sees no disk >present. >This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm >now researching how to update the BIOS to see if that helps. Wow, thats too bad. Hopefully a newer BIOS will let you put the controller in SATA mode. > > > > Start with > > > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso > >I've used the amd64 version ... don't know if that makes any >difference, though. It wont make a difference in terms of the SATA/PATA issue. However, once you get that fixes, you should be able to install the AMD64 image just fine. I would check the USB settings as well to make sure the "hand off mode" is disabled. ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 18:43:17 2008 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 66810106568C for ; Wed, 1 Oct 2008 18:43:17 +0000 (UTC) (envelope-from fernan@iib.unsam.edu.ar) Received: from usmmx.unsam.edu.ar (mx.unsam.edu.ar [200.45.170.30]) by mx1.freebsd.org (Postfix) with ESMTP id A7D9F8FC1A for ; Wed, 1 Oct 2008 18:43:16 +0000 (UTC) (envelope-from fernan@iib.unsam.edu.ar) Received: from unsam.edu.ar ([192.168.0.20]) by usmmx.unsam.edu.ar with InterScan Message Security Suite; Wed, 01 Oct 2008 15:00:46 -0300 Received: from gama.iib.unsam.edu.ar by unsam.edu.ar(MDaemon.PRO.v8.1.1.R)with ESMTP id md50010890521.msgfor ; Wed, 01 Oct 2008 13:41:37 -0300 Received: from gama.iib.unsam.edu.ar (localhost [127.0.0.1])by gama.iib.unsam.edu.ar (8.14.2/8.14.2) with ESMTP id m91Ge166083174; Wed, 1 Oct 2008 13:40:02 -0300 (ART)(envelope-from fernan@iib.unsam.edu.ar) Received: (from fernan@localhost)by gama.iib.unsam.edu.ar (8.14.2/8.14.2/Submit) id m91Ge13D083173; Wed, 1 Oct 2008 13:40:01 -0300 (ART)(envelope-from fernan@iib.unsam.edu.ar) X-Authentication-Warning: gama.iib.unsam.edu.ar: fernan set sender to fernan@iib.unsam.edu.ar using -f Date: Wed, 1 Oct 2008 13:40:01 -0300 From: Fernan Aguero To: Mike Tancsa Message-ID: <20081001164001.GA81847@iib.unsam.edu.ar> Mail-Followup-To: Fernan Aguero ,Mike Tancsa , freebsd-stable@freebsd.org References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200809302351.m8UNpjs7024916@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809302351.m8UNpjs7024916@lava.sentex.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Processed: unsam-mail.unsam.edu.ar, Wed, 01 Oct 2008 13:41:37 -0300(not processed: spam filter disabled) X-Return-Path: fernan@iib.unsam.edu.ar X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-MDAV-Processed: unsam-mail.unsam.edu.ar, Wed, 01 Oct 2008 15:01:29 -0300 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-13.2979 TC:1F TRN:47 TV:5.5.1027(16192.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: freebsd-stable@freebsd.org Subject: Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 01 Oct 2008 18:43:17 -0000 > At 05:34 PM 9/30/2008, Fernan Aguero wrote: > >> I've been following the "HT1000 chipset errata saga" thread, and the >> commits by sos@ to CVS (around Jan 2008), but have not seen other more >> recent posts about this issue ... is it because it's already fixed and >> working fine for everyone? >> >> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Yes, we ran into this yesterday on a fresh install using the 7.1 beta CD as > it was set to PATA mode by accident. Also, on some earlier BIOS revs, we > had to turn off "enable USB legacy mode" as well as "EHCI handoff". By > default we set those to disabled as it seems to sometimes create a high > interrupt load on the USB bus if its enabled. Thanks for the tip. Unfortunately, the PowerEdge SC1435 BIOS does not allow much options here ... I can set the embedded SATA to 'ATA mode' (corruption hell, tested with 7.1 BETA) or just turn it 'OFF' in which case the FreeBSD installer sees no disk present. This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm now researching how to update the BIOS to see if that helps. > If you forget to set the mode to SATA, the dmesg will look like > > Sep 30 13:37:08 dev2 kernel: ad4: DMA limited to UDMA33, device found > non-ATA66 cable > Sep 30 13:37:08 dev2 kernel: ad4: 152627MB at > ata2-master UDMA33 > > and you will indeed get corruption > > Turning onto normal SATA mode in the BIOS, you should see > > Sep 30 16:14:15 dev2 kernel: ad4: 152627MB at > ata2-master SATA150 > > ... And everything works great. > > Start with > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso I've used the amd64 version ... don't know if that makes any difference, though. Fernan From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 19:19:31 2008 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 7E05210656EF for ; Wed, 1 Oct 2008 19:19:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3678FC1C for ; Wed, 1 Oct 2008 19:19:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m91JJ425071550; Wed, 1 Oct 2008 15:19:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 1 Oct 2008 11:34:49 -0400 User-Agent: KMail/1.9.7 References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> In-Reply-To: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810011134.49795.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 01 Oct 2008 15:19:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8367/Wed Oct 1 12:39:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Fernan Aguero Subject: Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? 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, 01 Oct 2008 19:19:31 -0000 On Tuesday 30 September 2008 05:34:04 pm Fernan Aguero wrote: > Hi, > > I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which > I'd like to try installing FreeBSD. I've already failed to make 7.0 > work on this box and was wondering if you have information about the > behavior of the upcoming 7.1 on this hardware. > > I've been following the "HT1000 chipset errata saga" thread, and the > commits by sos@ to CVS (around Jan 2008), but have not seen other more > recent posts about this issue ... is it because it's already fixed and > working fine for everyone? > > http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Thanks in advance for any update on this, Try http://www.freebsd.org/~jhb/patches/ata_ht1000.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 19:37:35 2008 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 BDCD41065686 for ; Wed, 1 Oct 2008 19:37:35 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id A5AA48FC0C for ; Wed, 1 Oct 2008 19:37:35 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m91JbXev079480 for ; Wed, 1 Oct 2008 12:37:33 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.396] Message-Id: From: Jo Rhett To: freebsd-stable@FreeBSD.org In-Reply-To: <44abdw9oeq.fsf@be-well.ilk.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 1 Oct 2008 12:37:27 -0700 References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <44abdw9oeq.fsf@be-well.ilk.org> X-Mailer: Apple Mail (2.929.2) Cc: Subject: Re: proposed change to support policy for FreeBSD Releases 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, 01 Oct 2008 19:37:35 -0000 On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote: > I'm not clear on how this helps. We don't know if there will be a > need to produce a 6.5 release, so there's no way to judge whether 6.4 > should be designated "final" or not. The only logical answer is to do > so, which leaves a substantial chance that there will end up being > more than one "final" release on the 6.x line. That's not a > particularly desirable situation. > > In fact, it's worse, because if 6.5 happens, it will probably be > because there were problems with 6.4 serious enough that we'd rather > people move to 6.5 anyway (at least for critical systems). You are exactly right. I am proposing that we stop trying to guess whether or not it is a final release. A release will be supported until the next release + N months (N is currently being debated I guess) or 24 months if there is no followup release. This effectively solves both of the problems you've very accurately named above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 19:45:09 2008 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 AABF61065688 for ; Wed, 1 Oct 2008 19:45:09 +0000 (UTC) (envelope-from peter@wemm.org) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by mx1.freebsd.org (Postfix) with ESMTP id 487138FC08 for ; Wed, 1 Oct 2008 19:45:09 +0000 (UTC) (envelope-from peter@wemm.org) Received: by qb-out-0506.google.com with SMTP id f30so474641qba.35 for ; Wed, 01 Oct 2008 12:45:08 -0700 (PDT) Received: by 10.142.191.10 with SMTP id o10mr3524849wff.94.1222889347573; Wed, 01 Oct 2008 12:29:07 -0700 (PDT) Received: by 10.142.255.21 with HTTP; Wed, 1 Oct 2008 12:29:07 -0700 (PDT) Message-ID: Date: Wed, 1 Oct 2008 12:29:07 -0700 From: "Peter Wemm" To: "Jeremy Chadwick" In-Reply-To: <20081001071309.GA13616@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> Cc: Derek Kuli??ski , lhmwzy , freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 19:45:09 -0000 On Wed, Oct 1, 2008 at 12:13 AM, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing....... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. Another big consideration, is is 'HAMMER' sufficiently 'finished' to be worth trying this yet? Anybody attempting a port is going to have enough to worry about with the VFS/VM semantics differences, locking differences etc between the two different kernels. Having to worry about following a moving target as well would add unneeded difficulty. To be honest, I've not looked at the state of HAMMER. Is it still under active development or is it in a state where you could easily work from a snapshot of the source for months and not have to worry about getting too far out of sync, or be in need of functionality or bug fixes? That was one of the things that made the ZFS port possible. It was possible to take a known-good, "complete", working snapshot as a base and focus on getting it working in the FreeBSD kernel. It wasn't necessary to wonder (that much) if the bug you're currently fighting is a porting bug or an underlying ZFS bug. Of course, there's a lot more to it than that, but having a solid starting point is very important. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 20:36:51 2008 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 0469F10656A4; Wed, 1 Oct 2008 20:36:51 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by mx1.freebsd.org (Postfix) with ESMTP id AB7828FC20; Wed, 1 Oct 2008 20:36:50 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A8vfMrHguudr6kvQjAfYULE4bqbUt5ySuYuK6IN9LS71wmGG8mEgh8/j8QjT8CYw; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl8RD-0002rf-Pv; Wed, 01 Oct 2008 16:36:47 -0400 Message-ID: <48E3DF5E.6040607@earthlink.net> Date: Wed, 01 Oct 2008 16:36:46 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Robert Watson References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79e470412449f08ca0f436ca251300b077350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: Gary Palmer , Jeremy Chadwick , FreeBSD Stable Subject: Re: resource leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 20:36:51 -0000 Robert Watson wrote: > On Wed, 1 Oct 2008, Gary Palmer wrote: > >>> Periodically logging "ps -auxw" output to a file would be useful, as >>> ideally you'd gradually see the list get longer and longer over time; >>> it's possible you have many zombie processes as a result of a parent >>> which is not reaping its children (calling waitpid(2) or its friends). >> >> "ps alxw" may be of interest in addition to "ps auxw" as it displays >> what the processes are waiting on. It could conceivably be a problem >> of some kind at the filesystem level. I've seen situations before >> where a problem escalates to the point where "ls /" hangs, and at that >> point you're stuck with an unresponsive box. > > If you want an even greater level of detail than ps -l, you can use > procstat -k to generate kernel stack traces for all user/kernel > threads. Wait channels are very useful, but they only tell you what the > code that invoked the wait thinks it is for, not how that code was > reached. A classic example is waiting on an exhausted UMA zone -- you > get a uma wait channel, but no indication of what subsystem performed > the memory allocation... This required FreeBSD 7.1 and higher, > however. (Obviously, the same can be done easily using DDB, but that's > hard on a box without a serial console, and requires interrupting the > flow of the operating system, compiling with DDB, etc). > > Robert N M Watson > Computer Laboratory > University of Cambridge > A big part of problem is this seems to take about 100 days of uptime to occur. We have some inhouse test boxes but have never seen the problem, probably because non of them have been up more than about 45 days. The units in the field, of which there is about 300, are headless and none are physically close. When the boxes are rebooted there are no error messages in any of the log files, only the absence of information that would normally be logged by new processes that would be spawned. We are getting ready to install a patch that will try to gather more information. I thought about writing an app the would try to fork a child periodically and record in a log file if there was an error. But EAGAIN is nonspecific as to the real reason the fork failed. I was looking for some way to periodically log the resources that would cause the fork failure. procstat -k looks like it would have been a good candidate but unfortunately we are running 6.1. Thanks for the response. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 21:04:58 2008 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 DDF81106568A for ; Wed, 1 Oct 2008 21:04:58 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id B20B28FC15 for ; Wed, 1 Oct 2008 21:04:58 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: by wa-out-1112.google.com with SMTP id n4so370708wag.27 for ; Wed, 01 Oct 2008 14:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=G0ckb7MdoMKp1TxfGkc9f9MEpLb3BvmovK54diVNFPc=; b=MVdAudWGnjFWN5BUsdJh3NS0Dh6zFy4dCrHMGoGJk5Sfb3HgM6+mtn1GwrgyZCwarW QoBLvWJIYcrY+avxnSn8DlkAniElxc+w751HQvrZKsoJR2V8cWBBfUqxNFLmMxwNIK8r A4abRwJfcY00O3eTzlaesvdysD6NtKn/ADryU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SKTORe60QHq1Vjp4LSTHImRLLwiJXutkGP8xxYL/DLcq8RZS9/AkCqFdE11LHqTs5T 23ztTlDGItvpoKhb8tdyl9ijBCcbbluhhUxfJzAO7qZvrij6WspJjbp93mKWOyBuwm5S r7tnTl671lSKaFW+5R1pMjXvxL3K3b0Mo+oD8= Received: by 10.115.94.1 with SMTP id w1mr9819120wal.109.1222893444025; Wed, 01 Oct 2008 13:37:24 -0700 (PDT) Received: by 10.114.182.3 with HTTP; Wed, 1 Oct 2008 13:37:23 -0700 (PDT) Message-ID: <2b98f2f70810011337u6498a619n9b524feb847b49d9@mail.gmail.com> Date: Thu, 2 Oct 2008 00:37:23 +0400 From: "Jeff Laine" To: "Edwin Groothuis" In-Reply-To: <20080928054620.GA80250@k7.mavetju> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080928054620.GA80250@k7.mavetju> Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Request for testing - top 3.8b1 in the base 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, 01 Oct 2008 21:04:59 -0000 2008/9/28 Edwin Groothuis : > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin > > -- > Edwin Groothuis > edwin@freebsd.org > http://www.mavetju.org Hello. I have one issue, maybe not so important though. I've compiled top 3.8b1 on my 7.1-PRERELEASE and it looks like "t" hotkey (toggle displaying "top" process) don't work at all. (Sorry if somebody has pointed out that one already. I haven't read all thread so thoroughly. ) -- Best regards, Jeff. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 22:25:38 2008 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 4028B1065686; Wed, 1 Oct 2008 22:25:38 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id BEE678FC0C; Wed, 1 Oct 2008 22:25:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9583619E027; Thu, 2 Oct 2008 00:25:36 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 333D919E023; Thu, 2 Oct 2008 00:25:34 +0200 (CEST) Message-ID: <48E3F900.8020702@quip.cz> Date: Thu, 02 Oct 2008 00:26:08 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: lhmwzy References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> In-Reply-To: <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? 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, 01 Oct 2008 22:25:38 -0000 lhmwzy wrote: > Yes,this is a way. > I would do as you said if I need to do so. > > 2008/10/1 Jeremy Chadwick : > >>On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> >>>That's it. >>>Since we don't have the skill,what we can do is wait. >>> >>>Waiting is such a bad thing....... >> >>If this functionality is really something you want/need, you should >>consider finding a kernel programmer who would be willing to port it, >>for financial exchange (in English: you will be paying them $XX/hour >>to port it to FreeBSD). >> >>This has happened in the past for some key features. Like I said, it >>all depends on how much it matters to you. HAMMER seems good, but at this time, it is more important to finish ZFS integration in to FreeBSD. Fixing all known issues, more testing, wider audience and make it production ready. Not because ZFS is better, may be is worse - it does not metter. I think it is important to have one successful port finished than two filesystems in non-production state. FreeBSD is currently lag behind other operating systems in supported filesystems. UFS2 is insufficient for todays storage requirements. Once we have ZFS production ready, we can talk about another filesystems. I can't do any programming to port whatever filesystem, nor write patches. All I can do is testing and reporting - and I am doing it. I have some stresstests of ZFS. Currently I have one ZFS mount with 56 snapshots taken during heavy tasks like coping or removing large number of small files (mainly cp -R /usr/ports /tank/test/$i in loops plus taring / untaring tasks), some large files creation with dd on background etc. All is running fine on FreeBSD 7.0 amd64 with 4GB RAM and some kernel tunning. vm.kmem_size="1024M" vm.kmem_size_max="1024M" kern.maxvnodes="400000" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" There are 53202511 inodes on ZFS partition. Zpool was created over two slices of two disks (mirror): capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 434G 10.5G 75 1.24K 618K 5.76M mirror 434G 10.5G 75 1.24K 618K 5.76M ad4s2 - - 13 328 918K 5.76M ad6s2 - - 16 326 1.09M 5.76M ---------- ----- ----- ----- ----- ----- ----- I have no crash of ZFS, but as I read in mailing lists, there are still some problems, so let it be fixed and settle down before porting another good filesystem. Just my 0.02 Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 23:12:49 2008 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 EDC4C1065688 for ; Wed, 1 Oct 2008 23:12:49 +0000 (UTC) (envelope-from dmarini@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 921088FC21 for ; Wed, 1 Oct 2008 23:12:49 +0000 (UTC) (envelope-from dmarini@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m91N2Xrp003356; Wed, 1 Oct 2008 19:02:33 -0400 (EDT) Received: from davide-desktop (CH-Boston.tch.harvard.edu [134.174.21.2]) (authenticated bits=0) (User authenticated as dmarini@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m91N2WrG026874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Oct 2008 19:02:32 -0400 (EDT) Received: by davide-desktop (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) dmarini@mit.edu; Wed, 1 Oct 2008 19:09:28 -0400 (EDT) Date: Wed, 1 Oct 2008 19:09:28 -0400 From: Davide Marini To: freebsd-stable@freebsd.org Message-ID: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: Anti-MDR1 antibody 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, 01 Oct 2008 23:12:50 -0000 Dear All: Has anybody tried the anti-MDR1 from Millipore, by any chance? http://www.millipore.com/catalogue/item/mab4161# I am looking for a reliable mouse anti-human antibody, targeting the extracellular epitope of P-glycoprotein. Any suggestion is extremely appreciated! Thank you in advance. Davide From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 00:05:07 2008 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 A4919106568D for ; Thu, 2 Oct 2008 00:05:07 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6B48FC1B for ; Thu, 2 Oct 2008 00:05:07 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 48DC49FD001B7AD9 for freebsd-stable@freebsd.org; Thu, 2 Oct 2008 01:44:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwsAOOn40hV4jrQPGdsb2JhbACBZpFZAQEBATWqK4FqhBM Received: from c-d03ae255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.58.208]) by ironport2.bredband.com with ESMTP; 02 Oct 2008 01:44:56 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.2/8.14.2) with ESMTP id m91Ninth088531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Oct 2008 01:44:55 +0200 (CEST) (envelope-from freebsd-stable@pp.dyndns.biz) Message-ID: <48E40B71.2010303@pp.dyndns.biz> Date: Thu, 02 Oct 2008 01:44:49 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> In-Reply-To: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Anti-MDR1 antibody 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, 02 Oct 2008 00:05:07 -0000 I'm really not into that anti-human movement and I think it's a pity that poor mouse has to suffer. I suggest you take three Valiums instead and call me in the morning... Davide Marini wrote: > Dear All: > > Has anybody tried the anti-MDR1 from Millipore, by any chance? > > > I am looking for a reliable mouse anti-human antibody, targeting > the extracellular epitope of P-glycoprotein. > > Any suggestion is extremely appreciated! > > Thank you in advance. > > Davide > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 02:34:18 2008 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 BEF97106568D for ; Thu, 2 Oct 2008 02:34:18 +0000 (UTC) (envelope-from dmarini@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5618FC12 for ; Thu, 2 Oct 2008 02:34:18 +0000 (UTC) (envelope-from dmarini@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m922YFD9017719; Wed, 1 Oct 2008 22:34:15 -0400 (EDT) Received: from localhost (pool-151-203-35-6.bos.east.verizon.net [151.203.35.6]) (authenticated bits=0) (User authenticated as dmarini@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m922YDjJ028700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Oct 2008 22:34:15 -0400 (EDT) Date: Wed, 1 Oct 2008 22:34:13 -0400 From: Davide Marini To: freebsd-stable@freebsd.org Message-ID: <20081002023412.GB904@davide-laptop.myhome.westell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: mutt/1.5.17 (FreeBSD/i386) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: Anti-MDR1: Apologies 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, 02 Oct 2008 02:34:18 -0000 Dear All: My apologies for sending this message to the wrong mailing list. I am indeed on the freebsd-stable list, as I use this OS, but the message was mistakenly sent to this forum. Sorry for disturbing your work. Let me take this opportunity to thank the developers for such a superb operating system. Best Regards, Davide -- Davide M. Marini, Ph.D. Research Fellow, Department of Cardiology Children's Hospital Boston | Harvard Medical School Enders 1306, 320 Longwood Avenue, Boston, MA 02115 Research Associate, Department of Materials Science Massachusetts Institute of Technology | Biomolecular Materials Group 77 Massachusetts Avenue, Room 16-244 Cambridge, MA 02139 From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 07:40:55 2008 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 CDD5C1065694; Thu, 2 Oct 2008 07:40:55 +0000 (UTC) (envelope-from ws@au.dyndns.ws) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id A53D48FC14; Thu, 2 Oct 2008 07:40:54 +0000 (UTC) (envelope-from ws@au.dyndns.ws) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAIsS5EiWZWdv/2dsb2JhbAAIvEqBag X-IronPort-AV: E=Sophos;i="4.33,348,1220193000"; d="scan'208";a="220042731" Received: from ppp103-111.static.internode.on.net (HELO [192.168.1.157]) ([150.101.103.111]) by ipmail05.adl2.internode.on.net with ESMTP; 02 Oct 2008 16:55:27 +0930 From: Wayne Sierke To: sclark46@earthlink.net In-Reply-To: <48E3DF5E.6040607@earthlink.net> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> <48E3DF5E.6040607@earthlink.net> Content-Type: text/plain Date: Thu, 02 Oct 2008 16:55:25 +0930 Message-Id: <1222932325.2581.277.camel@predator-ii.buffyverse> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Jeremy Chadwick , Robert Watson Subject: Re: resource leak 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, 02 Oct 2008 07:40:55 -0000 On Wed, 2008-10-01 at 16:36 -0400, Stephen Clark wrote: > Robert Watson wrote: > > On Wed, 1 Oct 2008, Gary Palmer wrote: > > > >> "ps alxw" may be of interest in addition to "ps auxw" as it displays > >> what the processes are waiting on. It could conceivably be a problem > >> of some kind at the filesystem level. I've seen situations before > >> where a problem escalates to the point where "ls /" hangs, and at that > >> point you're stuck with an unresponsive box. > > > > If you want an even greater level of detail than ps -l, you can use > > procstat -k to generate kernel stack traces for all user/kernel > > threads. Wait channels are very useful, but they only tell you what the > > code that invoked the wait thinks it is for, not how that code was > > reached. A classic example is waiting on an exhausted UMA zone -- you > > get a uma wait channel, but no indication of what subsystem performed > > the memory allocation... This required FreeBSD 7.1 and higher, > > however. (Obviously, the same can be done easily using DDB, but that's > > hard on a box without a serial console, and requires interrupting the > > flow of the operating system, compiling with DDB, etc). > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > A big part of problem is this seems to take about 100 days of uptime to occur. > We have some inhouse test boxes but have never seen the problem, probably > because non of them have been up more than about 45 days. The units in the > field, of which there is about 300, are headless and none are physically close. > > When the boxes are rebooted there are no error messages in any of the log files, > only the absence of information that would normally be logged by new processes > that would be spawned. We are getting ready to install a patch that will try to > gather more information. > > I thought about writing an app the would try to fork a child periodically and > record in a log file if there was an error. But EAGAIN is nonspecific as to the > real reason the fork failed. I was looking for some way to periodically log the > resources that would cause the fork failure. > > procstat -k looks like it would have been a good candidate but unfortunately we > are running 6.1. > > Thanks for the response. > Steve I have a VIA EPIA-based system that was rebooting and not leaving behind any diagnosable evidence that I could find. Attaching a serial console revealed a kernel-trap which was double-faulting as it went to write the kernel dump. I've not yet had the opportunity to investigate further except that out of desperation I threw in an additional 64M of RAM - all I had to hand - adding to its 256M and I haven't seen it fault again in the 37 days since (it would often stay up for less than a day before that). I wonder whether it would be worth your while running a bench unit with limited RAM, either physically or via the hw.physmem tunable. I would probably try to identify the amount of RAM that just allows it to run "normally", ideally subjecting it to a typical workload if possible. If it bombs after running for a reasonable length of time, add back a fraction of the unused memory and see if it then stays up proportionally longer which could be indicative of a memory starvation issue. If you can get it to bomb in the above scenario then you can probably get some insight into where it's failing. Having said that, I should point out that I've not actually used the above technique so I may well be overlooking something which might prevent it from being useful or indeed from "working" at all. Wayne From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 07:59:18 2008 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 0A4F21065686 for ; Thu, 2 Oct 2008 07:59:18 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC6E8FC3B for ; Thu, 2 Oct 2008 07:59:17 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so278005eyi.7 for ; Thu, 02 Oct 2008 00:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:subject:message-id :x-mailer:mime-version:content-type:content-transfer-encoding:from; bh=7i0yv2W3MRg4gwRJz6/8h5PnnEmGJaR5fYkQq+Kjlq8=; b=lopFqhsXGNhFXUahw6D2gOFpcTm2m1UIHYBt4QoVkjIfpWPU+k3kseWt1K3hX7f+Bj fiOlxdowf0xiWvtAWDhgMjY+zrFcHHh07dbSfq/C0ftD42LDhS5nRygNyfZjN1LUin/a z3ol4RavXOlZBJ9HAH+0p83ikyMbMiXy6a/uE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding:from; b=hq0T+Ww29qxNQK+i4OHc0tVZmgntVGm33wp8uYsfaWdTa2bTbeUz9h7qKwa7CEdqzY 7y3ywjuAAKc9AGOiJuhiZQe3Hg9lQbmnDiUHBa6Fnys/oU1H7Rb5G/o+54ydL69Xc06G kyOjKJXVjz6Gw8I5bZZeCZKOlyMIjRDkyr+Zc= Received: by 10.210.123.2 with SMTP id v2mr10933318ebc.186.1222932364899; Thu, 02 Oct 2008 00:26:04 -0700 (PDT) Received: from notebook (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id y37sm1447865iky.5.2008.10.02.00.26.03 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 00:26:04 -0700 (PDT) Date: Thu, 2 Oct 2008 10:26:00 +0300 To: freebsd-stable@freebsd.org Message-ID: <20081002102600.45f407d2@notebook> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: "Sergey V. Dyatko" Subject: if_re is broken on RELENG_7 ? 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, 02 Oct 2008 07:59:18 -0000 Hi list, I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. Than I started to enjoy BCM43XX wi-fi adapter and now I recently decided to revert to the use of realtek adapter. But it doesn't work. I'm just not running a network card or at all does not work? some additional information: ifconfig shows such information, regardless of whether the cable is connected: %ifconfig re0 re0: flags=8802 metric 0 mtu 1500 options=389b ether 00:1a:92:ca:b3:bc media: Ethernet autoselect (10baseT/UTP ) status: no carrier [tiger@notebook]~%pciconf -lv | grep re0 -A 4 re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet dmesg output: http://tiger.byfly.by/files/dmesg.boot kernel config: http://tiger.byfly.by/files/tiger-asus-a6m p.s.: Excuse me for my English :) -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 08:08:30 2008 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 F3F391065688 for ; Thu, 2 Oct 2008 08:08:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA508FC1B for ; Thu, 2 Oct 2008 08:08:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Mk2H1a00D0vyq2s5Ak8Udw; Thu, 02 Oct 2008 08:08:28 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Mk8T1a0054v8bD73Rk8T61; Thu, 02 Oct 2008 08:08:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=lnfLXmXU98kA:10 a=wpzNn3oeAAAA:8 a=QycZ5dHgAAAA:8 a=ueyuDREMjvkqIxZjBtkA:9 a=hrn0iWxaVLH00Yi_sOvPeGTdZ_0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 2FCDBC9432; Thu, 2 Oct 2008 01:08:27 -0700 (PDT) Date: Thu, 2 Oct 2008 01:08:27 -0700 From: Jeremy Chadwick To: "Sergey V. Dyatko" Message-ID: <20081002080827.GA42696@icarus.home.lan> References: <20081002102600.45f407d2@notebook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081002102600.45f407d2@notebook> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Pyun YongHyeon , freebsd-stable@freebsd.org Subject: Re: if_re is broken on RELENG_7 ? 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, 02 Oct 2008 08:08:30 -0000 On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > Hi list, > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. > Than I started to enjoy BCM43XX wi-fi adapter and now I recently > decided to revert to the use of realtek adapter. But it doesn't work. > I'm just not running a network card or at all does not work? > > some additional information: > ifconfig shows such information, regardless of whether the cable is > connected: > > %ifconfig re0 > re0: flags=8802 metric 0 mtu 1500 > options=389b > ether 00:1a:92:ca:b3:bc > media: Ethernet autoselect (10baseT/UTP ) > status: no carrier > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > dmesg output: http://tiger.byfly.by/files/dmesg.boot > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > p.s.: Excuse me for my English :) Looks like link isn't being established, and autoselect is resorting to 10BT/half. Can you provide pciconf -lv output? CC'ing PYUN Yong-Hyeon (surname Pyun), who helps maintain this driver. He might have some patches for you. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 08:46:29 2008 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 A6EA61065691 for ; Thu, 2 Oct 2008 08:46:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id 252B98FC3F for ; Thu, 2 Oct 2008 08:46:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so521833tid.3 for ; Thu, 02 Oct 2008 01:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=t4ScqKKP8Y6n6remjeXBfgQniT6fs3DGXPC7nF386VY=; b=DXSIE3EwuZr9zWUdA76jlqi7kpeYw2Q+fdVOeHCGBBmyWTr11IzYgln0LHkha0CSWD 13+EvSxz6kJgQGLiPIdh4OGO7BcH7nXAQxGm5LYO71/2+p9HJUIxBKdzb6ONxsqDALVw H4K/MwrFl7nw+MN+aiXPLhOW0wH6SUX41/+Bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZqJiLkg6KiOgegF1aScbq9efQu8MLFCHtu5Tyyw2Mz+lfrkOCisk/L6y+/2JRyN8PA Z0cqKicVVPhkOoMaEAZBLL+HSUNJ9BXj6xCT26lmM47oB9ebVda6SkAfNV/W6NFzf5Nf uVbu0sroW1bcN8ksVa6m0vPGA+usWxJYYj0q0= Received: by 10.110.31.5 with SMTP id e5mr13654365tie.1.1222937186540; Thu, 02 Oct 2008 01:46:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id w12sm3263319tib.10.2008.10.02.01.46.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 01:46:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m928iPQW068718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 17:44:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m928iPqU068717; Thu, 2 Oct 2008 17:44:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 2 Oct 2008 17:44:25 +0900 From: Pyun YongHyeon To: "Sergey V. Dyatko" Message-ID: <20081002084425.GD67204@cdnetworks.co.kr> References: <20081002102600.45f407d2@notebook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081002102600.45f407d2@notebook> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: if_re is broken on RELENG_7 ? 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: Thu, 02 Oct 2008 08:46:29 -0000 On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > Hi list, > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. > Than I started to enjoy BCM43XX wi-fi adapter and now I recently > decided to revert to the use of realtek adapter. But it doesn't work. > I'm just not running a network card or at all does not work? > > some additional information: > ifconfig shows such information, regardless of whether the cable is > connected: > > %ifconfig re0 > re0: flags=8802 metric 0 mtu 1500 > options=389b > ether 00:1a:92:ca:b3:bc > media: Ethernet autoselect (10baseT/UTP ) > status: no carrier I don't see what's wrong in the output above. Because there is no "RUNNING" in flags field I guess you didn't up the interface. (e.g. either assign an IP address to the interface or run 'dhclient re0' if you want to get an IP address over DHCP). > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > dmesg output: http://tiger.byfly.by/files/dmesg.boot > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 08:55:22 2008 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 57A901065689 for ; Thu, 2 Oct 2008 08:55:22 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id D81708FC17 for ; Thu, 2 Oct 2008 08:55:21 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so398931nfh.33 for ; Thu, 02 Oct 2008 01:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:cc:subject:message-id :in-reply-to:references:x-mailer:mime-version:content-type :content-transfer-encoding:from; bh=mdip9yorvqr1z3eTpYuI1PCcnu+Dub9dBPEoy1+0AZg=; b=gGYqaTLGZSI/y0n3WFHR8zcT/M+2kqkGDIpXCw0gxVFeXbvQxbL44LVJ4U1lDt88hl z/8uyBIoXOnPDad2ch2D7y26nh82dUoSsWHpQdhkpJJz594CN1PEo7rCX6yju0KeY0/p VDG3Tib2cmfug/j3Ky8qHphMiT+Uga7vQlO64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding:from; b=kvJm0gTs8gleUfHtH2VJf5ZTlPfr4K6KtnOErN7Xk6EoCHxHm2c2JXC9BVeZY7iNOS GOSGEyhPVdbxTBZVmpXikQHBRQpXewIWwiljfYm6+ErNupSmzAz0CZ9uBb4/xd2pZ0jA Qmj9FvgxmJTYkgq8GBQOTWfQNoUv8GYOUEcxU= Received: by 10.210.27.20 with SMTP id a20mr11068072eba.119.1222937720281; Thu, 02 Oct 2008 01:55:20 -0700 (PDT) Received: from notebook (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id z34sm1536467ikz.3.2008.10.02.01.55.17 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 01:55:19 -0700 (PDT) Date: Thu, 2 Oct 2008 11:55:15 +0300 To: Jeremy Chadwick Message-ID: <20081002115515.6f6bfec2@notebook> In-Reply-To: <20081002080827.GA42696@icarus.home.lan> References: <20081002102600.45f407d2@notebook> <20081002080827.GA42696@icarus.home.lan> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit From: "Sergey V. Dyatko" Cc: Pyun YongHyeon , freebsd-stable@freebsd.org Subject: Re: if_re is broken on RELENG_7 ? 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, 02 Oct 2008 08:55:22 -0000 Thu, 2 Oct 2008 01:08:27 -0700 Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > Hi list, > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I recently > > decided to revert to the use of realtek adapter. But it doesn't > > work. I'm just not running a network card or at all does not work? > > > > some additional information: > > ifconfig shows such information, regardless of whether the cable is > > connected: > > > > %ifconfig re0 > > re0: flags=8802 metric 0 mtu 1500 > > options=389b > > ether 00:1a:92:ca:b3:bc > > media: Ethernet autoselect (10baseT/UTP ) > > status: no carrier > > > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec > > rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > dmesg output: http://tiger.byfly.by/files/dmesg.boot > > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > > > p.s.: Excuse me for my English :) > > Looks like link isn't being established, and autoselect is resorting > to 10BT/half. > > Can you provide pciconf -lv output? > sure, http://tiger.byfly.by/files/pciconf.txt > CC'ing PYUN Yong-Hyeon (surname Pyun), who helps maintain this driver. > He might have some patches for you. > -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 09:02:04 2008 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 897E8106568A for ; Thu, 2 Oct 2008 09:02:04 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9BF8FC24 for ; Thu, 2 Oct 2008 09:02:03 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so282351eyi.7 for ; Thu, 02 Oct 2008 02:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:cc:subject:message-id :in-reply-to:references:x-mailer:mime-version:content-type :content-transfer-encoding:from; bh=1JSoLFr9DOCA56YYK9AG6dSJo/QOxW+ZAH0Lli4Cb44=; b=fJnBkYu0BJnsuAJ7mBA1DeNAVBoNK+KjSN08oj2eRiJtz7Yf8GVquZ1SyDcYCPVgGE OPeGna76CVtTmGDZ/rwwatiXPt+KrK7YDSj4az/g/afi5Pnqm29uzYEskcRgt+OB4NEy FfR4MpfUX6Hjwg/llU2TPs8TTOCoHTF4h28Jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding:from; b=I0OyToew9STD6XkKVsYx9L9MueH8VjZ/548eAuKVtXyyOef/eGdxuQhoNVuqymChf9 Ba8OZHmg8Wa/lxDLQ44M5vWcls73iaBW2VM2vBRtaJ2wwnPyDlOphABWxQsYabmPqfIs O/mhgILv13AlPWeagpVbPQJ+eKef//PKzPOwI= Received: by 10.210.124.15 with SMTP id w15mr11098863ebc.81.1222938121879; Thu, 02 Oct 2008 02:02:01 -0700 (PDT) Received: from notebook (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id c22sm1561621ika.1.2008.10.02.02.01.59 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 02:02:01 -0700 (PDT) Date: Thu, 2 Oct 2008 12:01:57 +0300 To: pyunyh@gmail.com Message-ID: <20081002120157.4e72b2f0@notebook> In-Reply-To: <20081002084425.GD67204@cdnetworks.co.kr> References: <20081002102600.45f407d2@notebook> <20081002084425.GD67204@cdnetworks.co.kr> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit From: "Sergey V. Dyatko" Cc: freebsd-stable@freebsd.org Subject: Re: if_re is broken on RELENG_7 ? 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, 02 Oct 2008 09:02:04 -0000 Thu, 2 Oct 2008 17:44:25 +0900 Pyun YongHyeon : > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > Hi list, > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I > > recently decided to revert to the use of realtek adapter. But it > > doesn't work. I'm just not running a network card or at all does > > not work? > > > > some additional information: > > ifconfig shows such information, regardless of whether the cable is > > connected: > > > > %ifconfig re0 > > re0: flags=8802 metric 0 mtu 1500 > > options=389b > > ether 00:1a:92:ca:b3:bc > > media: Ethernet autoselect (10baseT/UTP ) > > status: no carrier > > I don't see what's wrong in the output above. Because there is no > "RUNNING" in flags field I guess you didn't up the interface. > (e.g. either assign an IP address to the interface or run > 'dhclient re0' if you want to get an IP address over DHCP). > Hmm, after command 'ifconfig re0 up' status changed to 'active', media to '100baseTX ' and everything work fine (dhclient re0). What time have I had to type "up" explicitly to make it work since? On my desktop with age(4): without cable: age0: flags=8802 metric 0 mtu 1500 options=319b ether 00:1b:fc:d4:7d:b3 media: Ethernet autoselect (none) status: no carrier Now I'll plug cable into NIC: age0: flags=8802 metric 0 mtu 1500 options=319b ether 00:1b:fc:d4:7d:b3 media: Ethernet autoselect (100baseTX ) status: active in that case I haven't "RUNNING" in flags field too, that flag and flag 'UP' appeared after I assing IP to age0 age0: flags=8843 metric 0 mtu1500 options=319b ether 00:1b:fc:d4:7d:b3 inet 192.168.9.240 netmask 0xffffff00 broadcast 192.168.9.255 > > > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec > > rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > dmesg output: http://tiger.byfly.by/files/dmesg.boot > > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > > -- -- , - tiger@agava.com From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 09:07:40 2008 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 D158D1065695; Thu, 2 Oct 2008 09:07:40 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF448FC1A; Thu, 2 Oct 2008 09:07:40 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m9297cVL039816; Thu, 2 Oct 2008 11:07:38 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m9297c6A039815; Thu, 2 Oct 2008 11:07:38 +0200 (CEST) (envelope-from olli) Date: Thu, 2 Oct 2008 11:07:38 +0200 (CEST) Message-Id: <200810020907.m9297c6A039815@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG In-Reply-To: <20081001051008.GA65754@icarus.home.lan> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 02 Oct 2008 11:07:38 +0200 (CEST) Cc: Subject: Re: system hangup - I'm lost X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2008 09:07:40 -0000 Jeremy Chadwick wrote: > - Maxim MAX211ECA1, no idea but doesn't interest me Just for completeness, this is a serial port driver IC. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 10:13:36 2008 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 04E111065687 for ; Thu, 2 Oct 2008 10:13:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by mx1.freebsd.org (Postfix) with ESMTP id 66F728FC0C for ; Thu, 2 Oct 2008 10:13:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so539414tid.3 for ; Thu, 02 Oct 2008 03:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=uKG1APcBXNpvH/MYoqpS8v3wO0IsS5IgSf0/ydhHyJo=; b=eKTbcTCoPyv1lx3yDS0bYXu6SrUUTXZXW80Bq3QAqLw5OktpsdA+NLHRethlpgMxjA 0a0/ZAFTLrTEvSMvpAx9IDNSeDwPeuXhOqiDF3ur+Mca2s9Y8lM++HNUQZvrIH9y4+9S Avlh8hb5VH5o0egbJOhcYE1PwVLn+cD+cPHng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=csXunb6TaXK3/3RwBck6VV7NmZh6IlvXYM2ka8JiG/RSm7QzBPIw07XKh6v2VcPPfg QLbQMWQGgGBsswBV2DFOAOARxk62amTfNaiuG1DTcRxD/s8vU7PI7eb1EZF8eraTcS8C R4wT7v61gtnDS/Hxb0G0pzjUx6ODbwbNErn7c= Received: by 10.110.46.3 with SMTP id t3mr13723606tit.33.1222942413497; Thu, 02 Oct 2008 03:13:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b4sm3539046tic.2.2008.10.02.03.13.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 03:13:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m92ABXDO068999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 19:11:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m92ABXKh068998; Thu, 2 Oct 2008 19:11:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 2 Oct 2008 19:11:33 +0900 From: Pyun YongHyeon To: "Sergey V. Dyatko" Message-ID: <20081002101133.GE67204@cdnetworks.co.kr> References: <20081002102600.45f407d2@notebook> <20081002084425.GD67204@cdnetworks.co.kr> <20081002120157.4e72b2f0@notebook> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081002120157.4e72b2f0@notebook> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: if_re is broken on RELENG_7 ? 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: Thu, 02 Oct 2008 10:13:36 -0000 On Thu, Oct 02, 2008 at 12:01:57PM +0300, Sergey V. Dyatko wrote: > Thu, 2 Oct 2008 17:44:25 +0900 > Pyun YongHyeon ڬ֬: > > > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > > Hi list, > > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I > > > recently decided to revert to the use of realtek adapter. But it > > > doesn't work. I'm just not running a network card or at all does > > > not work? > > > > > > some additional information: > > > ifconfig shows such information, regardless of whether the cable is > > > connected: > > > > > > %ifconfig re0 > > > re0: flags=8802 metric 0 mtu 1500 > > > options=389b > > > ether 00:1a:92:ca:b3:bc > > > media: Ethernet autoselect (10baseT/UTP ) > > > status: no carrier > > > > I don't see what's wrong in the output above. Because there is no > > "RUNNING" in flags field I guess you didn't up the interface. > > (e.g. either assign an IP address to the interface or run > > 'dhclient re0' if you want to get an IP address over DHCP). > > > Hmm, after command 'ifconfig re0 up' status changed to 'active', > media to '100baseTX ' and everything work fine (dhclient > re0). What time have I had to type "up" explicitly to make it work > since? You don't have to, just configure re0 interface(e.g. rc.conf) > > On my desktop with age(4): > without cable: > age0: flags=8802 metric 0 mtu 1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > media: Ethernet autoselect (none) > status: no carrier > Now I'll plug cable into NIC: > > age0: flags=8802 metric 0 mtu 1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > media: Ethernet autoselect (100baseTX ) > status: active > in that case I haven't "RUNNING" in flags field too, that flag and flag > 'UP' appeared after I assing IP to age0 > > age0: flags=8843 metric 0 > mtu1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > inet 192.168.9.240 netmask 0xffffff00 broadcast 192.168.9.255 That depends on PHY driver, rgephy(4) for re(4). Some PHY hardware requires special mode/initialization to establish a valid link with link partner. It seems that atphy(4) doesn't require any special PHY hardware configuration to establish a link. Also you can say the link status is valid only after interface up. Normally PHY drivers will have to restart auto-negotiation to choose the highest common denominator ability in interface up time. The established link after auto-negotiation may/may not agree on the speed/duplex of the link you've seen before the initialization. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 12:08:22 2008 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 D862210656AB; Thu, 2 Oct 2008 12:08:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF1178FC1A; Thu, 2 Oct 2008 12:08:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 5A69446B06; Thu, 2 Oct 2008 08:08:22 -0400 (EDT) Date: Thu, 2 Oct 2008 13:08:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephen Clark In-Reply-To: <48E3DF5E.6040607@earthlink.net> Message-ID: References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> <48E3DF5E.6040607@earthlink.net> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Gary Palmer , Jeremy Chadwick , FreeBSD Stable Subject: Re: resource leak 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, 02 Oct 2008 12:08:22 -0000 On Wed, 1 Oct 2008, Stephen Clark wrote: > A big part of problem is this seems to take about 100 days of uptime to > occur. We have some inhouse test boxes but have never seen the problem, > probably because non of them have been up more than about 45 days. The units > in the field, of which there is about 300, are headless and none are > physically close. > > When the boxes are rebooted there are no error messages in any of the log > files, only the absence of information that would normally be logged by new > processes that would be spawned. We are getting ready to install a patch > that will try to gather more information. > > I thought about writing an app the would try to fork a child periodically > and record in a log file if there was an error. But EAGAIN is nonspecific as > to the real reason the fork failed. I was looking for some way to > periodically log the resources that would cause the fork failure. The narrowness of the UNIX errno space is, at times, fairly unhelpful. As far as I'm aware, the two main causes of EAGAIN out of fork() are an exhaustion of maxprocs or an exhaustion of per-user process limits. This suggests one or more run-away applications or services, or a gradual leak of processes from a service (perhaps a failure to GC dead children, or a gradual increase but never decrease of worker processes?). Robert N M Watson Computer Laboratory University of Cambridge > > procstat -k looks like it would have been a good candidate but unfortunately > we > are running 6.1. > > Thanks for the response. > Steve > > -- > > "They that give up essential liberty to obtain temporary safety, > deserve neither liberty nor safety." (Ben Franklin) > > "The course of history shows that as a government grows, liberty > decreases." (Thomas Jefferson) > > > From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 13:30:51 2008 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 EF295106568D; Thu, 2 Oct 2008 13:30:51 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7858FC0A; Thu, 2 Oct 2008 13:30:51 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from giskard.altus-escon.com (giskard.altus-escon.com [193.78.231.1]) by altus-escon.com (8.14.2/8.14.2) with ESMTP id m92DTCqO073900; Thu, 2 Oct 2008 15:29:17 +0200 (CEST) (envelope-from ben@altesco.nl) Message-Id: <8C93174F-EC03-4775-A919-6CDE2AE80D9F@altesco.nl> From: Ben Stuyts To: Jeremy Chadwick In-Reply-To: <20081001101227.GA17912@icarus.home.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 15:29:11 +0200 References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> <20081001101227.GA17912@icarus.home.lan> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [193.78.231.142]); Thu, 02 Oct 2008 15:29:17 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94/8371/Thu Oct 2 12:15:33 2008 on mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Holger Kipp , stable@FreeBSD.org Subject: Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? 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, 02 Oct 2008 13:30:52 -0000 On 1 okt 2008, at 12:12, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: >> I had to disable mmap access in dovecot, or it would coredump >> periodically. (mmap_disable = yes in dovecot.conf) > > Have you tried re-enabling mmap in dovecot on a system with a kernel > build after those dates? It's been running for a day now wit mmap enabled, and it works fine now. Again thanks for pointing this out. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 14:16:32 2008 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 235681065758 for ; Thu, 2 Oct 2008 14:16:32 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.153.48.3]) by mx1.freebsd.org (Postfix) with ESMTP id 99DD38FC16 for ; Thu, 2 Oct 2008 14:16:31 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from [10.10.2.2] (189-19-2-198.dsl.telesp.net.br [189.19.2.198]) by msrv.matik.com.br (8.14.2/8.14.2) with ESMTP id m92Dq7UO060440 for ; Thu, 2 Oct 2008 10:52:07 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Thu, 2 Oct 2008 10:52:17 -0300 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810021052.17161.joao@matik.com.br> X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,BR_RECEIVED_SPAMMER, RDNS_DYNAMIC,SARE_RECV_SPAM_DOMN02,TW_TX autolearn=no version=3.2.5 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on msrv.matik.com.br X-Virus-Scanned: ClamAV 0.93.3/8371/Thu Oct 2 07:15:33 2008 on msrv.matik.com.br X-Virus-Status: Clean Subject: usb data xfer problem with to/from nokia smartphones 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, 02 Oct 2008 14:16:32 -0000 I have difficulties transferring data from or to nokia smartphones in mass= =20 storage mode, specially nokia N80 and N95. The files are coming with missing parts, accessing a photo which s stored o= nt=20 the phone is beeing seen cut somewhere in half, mp3 files are transferred b= ut=20 there are missing parts within, same with other binaries from the same computer (dual boot) with windows xp and fedora 8 txferring t= he=20 exact same file the thing runs fine happens on i386 and amd64 some idea what might be wrong? =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 16:51:11 2008 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 E409F106568A for ; Thu, 2 Oct 2008 16:51:11 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 2DD148FC1F for ; Thu, 2 Oct 2008 16:51:10 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 7724 invoked by uid 89); 2 Oct 2008 16:51:07 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 2 Oct 2008 16:51:07 -0000 Date: Thu, 2 Oct 2008 18:51:06 +0200 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20081002185106.a1183896.lehmann@ans-netz.de> In-Reply-To: <20081001172943.99e9d494.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Gavin Atkinson , Robert Watson , John Baldwin Subject: Re: system hangup - I'm lost 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, 02 Oct 2008 16:51:12 -0000 Oliver Lehmann wrote: > Hi, > > today I'd a crash again - I was not able to get a crash dump (thought a > "panic" at the end of the kdb would do it but didn't - should have called > dumpon before ;)) - so here now the information I was able to retrieve: > > Ok, what I've got so far is wrinting stuff out to the console when the > system hangs up: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > ... > > and now the debugger stuff: > > [snipped] > So.. no idea? anyone? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 18:21:47 2008 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 40B56106568D for ; Thu, 2 Oct 2008 18:21:47 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id EAD958FC1D for ; Thu, 2 Oct 2008 18:21:46 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by chen.org.nz (Postfix, from userid 1000) id DF4792840D; Fri, 3 Oct 2008 07:04:32 +1300 (NZDT) Date: Fri, 3 Oct 2008 07:04:32 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20081002180432.GA34898@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: ipfw: install_state: entry already present, done 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, 02 Oct 2008 18:21:47 -0000 Hi, I've just updated my 7-STABLE box to 7.1-PRERELEASE, and I'm seeing a quite a few ipfw kernel messages: ipfw: install_state: entry already present, done What is this mean? Has some regression occurred with ipfw? Cheers. -- Jonathan Chen ---------------------------------------------------------------------- Do not take life too seriously. You will never get out of it alive. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 18:30:42 2008 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 745621065877 for ; Thu, 2 Oct 2008 18:30:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 167C88FC15 for ; Thu, 2 Oct 2008 18:30:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m92IULIr083774; Thu, 2 Oct 2008 14:30:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 2 Oct 2008 13:11:47 -0400 User-Agent: KMail/1.9.7 References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> In-Reply-To: <20081001172943.99e9d494.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810021311.48127.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 02 Oct 2008 14:30:34 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8372/Thu Oct 2 11:21:47 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Oliver Lehmann Subject: Re: system hangup - I'm lost 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, 02 Oct 2008 18:30:42 -0000 On Wednesday 01 October 2008 11:29:43 am Oliver Lehmann wrote: > Hi, > > today I'd a crash again - I was not able to get a crash dump (thought a > "panic" at the end of the kdb would do it but didn't - should have called > dumpon before ;)) - so here now the information I was able to retrieve: > > Ok, what I've got so far is wrinting stuff out to the console when the > system hangs up: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 Sounds like your disk has died, or perhaps the controller is hung and not completing disk I/O requests anymore. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 20:07:20 2008 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 1CD55106568F for ; Thu, 2 Oct 2008 20:07:20 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 5CBDD8FC1A for ; Thu, 2 Oct 2008 20:07:18 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 22107 invoked by uid 89); 2 Oct 2008 20:07:16 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 2 Oct 2008 20:07:16 -0000 Date: Thu, 2 Oct 2008 22:07:14 +0200 From: Oliver Lehmann To: John Baldwin Message-Id: <20081002220714.2141f8f4.lehmann@ans-netz.de> In-Reply-To: <200810021311.48127.jhb@freebsd.org> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <200810021311.48127.jhb@freebsd.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: system hangup - I'm lost 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, 02 Oct 2008 20:07:20 -0000 John Baldwin wrote: > Sounds like your disk has died, or perhaps the controller is hung and not > completing disk I/O requests anymore. Hm - the 3ware eventlog does not shed any light on this - no events occured. So I can just guess that the controller and the disks are fine (I had once a hard failing disk and the controller detected it correctly) Do you have an idea how to debug this further? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 20:25:45 2008 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 ABE6C1065691 for ; Thu, 2 Oct 2008 20:25:45 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 67C9A8FC08 for ; Thu, 2 Oct 2008 20:25:45 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K8400LNDOQVML90@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 02 Oct 2008 22:25:43 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.72.201]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K84003JROQU0PI0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 02 Oct 2008 22:25:43 +0200 (CEST) Date: Thu, 02 Oct 2008 22:25:42 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080922021022.GC26294@cdnetworks.co.kr> References: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> <20080922021022.GC26294@cdnetworks.co.kr> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: pyunyh@gmail.com Subject: Re: FreeBSD 6.5-prerelease and if_re - patches needed? 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, 02 Oct 2008 20:25:45 -0000 On Mon, 22 Sep 2008 11:10:23 +0900 Pyun YongHyeon wrote: > Due to lack of time and energy the change made in HEAD wasn't MFCed > to RELENG_6 so you may still need some patch. stable/7 should have > no such problems though. Does anybody happen to know which patch? > Maybe the issue you're seeing comes from misuse of bus_dma(9) which > was corrected in stable/7. But not MFC'ed to RELENG_6 I guess? Is therer a patch for RELENG_6 somewhere? -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 20:58:45 2008 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 D5F86106569D for ; Thu, 2 Oct 2008 20:58:45 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD208FC17 for ; Thu, 2 Oct 2008 20:58:45 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id EC6C630126 for ; Thu, 2 Oct 2008 21:58:37 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 Received: from [IPv6:2a01:348:10f:0:8d8b:f2df:5261:fe25] (unknown [IPv6:2a01:348:10f:0:8d8b:f2df:5261:fe25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTP for ; Thu, 2 Oct 2008 21:58:35 +0100 (BST) Message-ID: <48E535D3.8000805@cran.org.uk> Date: Thu, 02 Oct 2008 21:57:55 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 02 Oct 2008 20:58:46 -0000 I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 22:19:04 2008 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 65AE41065692 for ; Thu, 2 Oct 2008 22:19:04 +0000 (UTC) (envelope-from Ron.Wingfield@Archaxis.net) Received: from archaxis.net (adsl-66-138-104-74.dsl.ltrkar.swbell.net [66.138.104.74]) by mx1.freebsd.org (Postfix) with ESMTP id 27FA28FC1B for ; Thu, 2 Oct 2008 22:19:03 +0000 (UTC) (envelope-from Ron.Wingfield@Archaxis.net) Received: from [192.168.1.2] ([192.168.1.1]) by archaxis.net (8.12.8p1/8.12.8) with ESMTP id m92LpOcH054202 for ; Thu, 2 Oct 2008 16:51:26 -0500 (CDT) (envelope-from Ron.Wingfield@Archaxis.net) Message-ID: <48E54264.9050203@Archaxis.net> Date: Thu, 02 Oct 2008 16:51:32 -0500 From: Ron Wingfield User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) To: freebsd-stable@freebsd.org Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: What has happened to the FreeBSD Forums? 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, 02 Oct 2008 22:19:04 -0000 My apologies in advance if this is an inappropriate "list question", but . . . What has happened to the FreeBSD Forum at [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent user/contributor to the forum . . .haven't been there in months, but WOW! what has happened to the moderation. Why is there so much filth and pornography posted there now? The site server response is also abysmal. Thanks for any info., Ron W. [2]Ron.Wingfield@Archaxis.net 501-920-7860 cell (best way) 501-228-4798 home References 1. http://www.freebsdforums.com/forums/ 2. mailto:Ron.Wingfield@Archaxis.net From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 22:23:01 2008 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 57EBF106568C for ; Thu, 2 Oct 2008 22:23:01 +0000 (UTC) (envelope-from freebsd-stable@bengrimm.net) Received: from office2.aipotu.nl (office2.aipotu.nl [194.123.169.74]) by mx1.freebsd.org (Postfix) with ESMTP id BE7C98FC0C for ; Thu, 2 Oct 2008 22:23:00 +0000 (UTC) (envelope-from freebsd-stable@bengrimm.net) X-H2O-MailScanner-Watermark: 1223590969.63738@b3/0fuy9IgCPfQR1YiCKNA Received: from hail.bengrimm.net (hail.bengrimm.net [86.90.159.11]) by office2.aipotu.nl (8.14.3/8.14.3) with ESMTP id m92MMkLJ072786; Fri, 3 Oct 2008 00:22:46 +0200 (CEST) Authentication-Results: office2.aipotu.nl; dkim=pass (1024-bit key) header.i=@bengrimm.net; dkim-adsp=pass X-AIPOTU-FROM: X-AIPOTU-IP: hail.bengrimm.net [86.90.159.11] X-H2O-MailScanner-Watermark: 1223590950.76707@eH+sOp2AzbZzoQeB7VEFFg Received: from benmobi.bengrimm.net (localhost [127.0.0.1]) by hail.bengrimm.net (8.14.3/8.14.3) with ESMTP id m92MMTOV060136; Fri, 3 Oct 2008 00:22:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bengrimm.net; s=libertas; t=1222986150; bh=eJXIFO2ZsHoumdGXFCKeW41hprKRA+EiII6tTO Mqe7w=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=E Jo/Wuf+zRjH9Zxz13PFK9qit5lioeEN8tVf/RfLWSihUBV8Z3d3L61bT2GPn0dfd912 9Ub4VunS9XZnF5oP1sxJUyJ2fLXtFoct76xv6KyYK/BGcEunyfIi45xCB0nt8H8ML1A MZuDrRkQ1xh36wrHsceLVB9P5D7Ig8cUC3DU= X-HAIL-FROM: X-HAIL-IP: localhost [127.0.0.1] Message-ID: <48E549A5.7050305@bengrimm.net> Date: Fri, 03 Oct 2008 00:22:29 +0200 From: "Ben C. O. Grimm" User-Agent: Thunderbird 2.0.0.16 (X11/20080816) MIME-Version: 1.0 To: Ron Wingfield References: <48E54264.9050203@Archaxis.net> In-Reply-To: <48E54264.9050203@Archaxis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Hail-MailScanner: Found to be clean X-Hail-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.398, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, DKIM_SIGNED 0.00) X-Hail-MailScanner-From: freebsd-stable@bengrimm.net X-MailScanner-ID: m92MMkLJ072786 X-Aipotu-MailScanner: Found to be clean X-Aipotu-MailScanner-SpamCheck: X-Aipotu-MailScanner-From: freebsd-stable@bengrimm.net Cc: freebsd-stable@freebsd.org Subject: Re: What has happened to the FreeBSD Forums? 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, 02 Oct 2008 22:23:01 -0000 Ron Wingfield wrote: > My apologies in advance if this is an inappropriate "list question", > but . . . > What has happened to the FreeBSD Forum at > [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent > user/contributor to the forum . . .haven't been there in months, but > WOW! what has happened to the moderation. Why is there so much > filth and pornography posted there now? The forums were abandoned. Everyone moved to http://www.daemonforums.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 22:50:10 2008 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 5B8B71065696 for ; Thu, 2 Oct 2008 22:50:10 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id E35FE8FC1D for ; Thu, 2 Oct 2008 22:50:09 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id C900235D04; Fri, 3 Oct 2008 00:50:07 +0200 (CEST) Date: Fri, 3 Oct 2008 00:50:36 +0200 From: cpghost To: Oliver Lehmann Message-ID: <20081002225036.GC2539@phenom.cordula.ws> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <20081002185106.a1183896.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081002185106.a1183896.lehmann@ans-netz.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: system hangup - I'm lost 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, 02 Oct 2008 22:50:10 -0000 On Thu, Oct 02, 2008 at 06:51:06PM +0200, Oliver Lehmann wrote: > > today I'd a crash again - I was not able to get a crash dump (thought a > > "panic" at the end of the kdb would do it but didn't - should have called > > dumpon before ;)) - so here now the information I was able to retrieve: > > > > Ok, what I've got so far is wrinting stuff out to the console when the > > system hangs up: > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > ... > > > > and now the debugger stuff: > > > > [snipped] > > > > So.. no idea? anyone? If it's PATA, check the cabling, then check it again, and just to make sure, replace the cable even if the system used to work flawlessly in the past. I've had this on a few servers, but replacing the cables always fixed the problem for me. Oh, btw, you can reproduce this exact behavior on diskless workstations with an NFS-mounted swap. IIRC, it even happened on VERY slow hardware with GBDE or GELI-encrypted swap partitions; but I'm not 100% sure it was due to slowness (it could have been a bad cabling issue as well). > -- > Oliver Lehmann > http://www.pofo.de/ > http://wishlist.ans-netz.de/ -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Thu Oct 2 23:34:52 2008 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 030DF1065692 for ; Thu, 2 Oct 2008 23:34:52 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id D86CC8FC12 for ; Thu, 2 Oct 2008 23:34:51 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 288A51A000B35 for ; Thu, 2 Oct 2008 16:34:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zkLyuAQzmIQq for ; Thu, 2 Oct 2008 16:34:47 -0700 (PDT) Received: from coal (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 9FE9B1A000B29 for ; Thu, 2 Oct 2008 16:34:47 -0700 (PDT) From: Freddie Cash To: freebsd-stable@freebsd.org Date: Thu, 2 Oct 2008 16:34:46 -0700 User-Agent: KMail/1.9.9 References: <48E54264.9050203@Archaxis.net> In-Reply-To: <48E54264.9050203@Archaxis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810021634.46398.fjwcash@gmail.com> Subject: Re: What has happened to the FreeBSD Forums? 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, 02 Oct 2008 23:34:52 -0000 On October 2, 2008 02:51 pm Ron Wingfield wrote: > My apologies in advance if this is an inappropriate "list question", > but . . . > What has happened to the FreeBSD Forum at > [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent > user/contributor to the forum . . .haven't been there in months, but > WOW! what has happened to the moderation. Why is there so much > filth and pornography posted there now? > The site server response is also abysmal. > Thanks for any info., > Ron W. The forums admin disappeared. We lowly moderators (there were only two of us) had no ability to change anything in the forum setup. We did the best we could for as long as we could to delete the spam entries every day. Several of the users joined together to start a new forum, with multiple admins, and better anti-spam setup. freebsdforums/bsdforums is all but dead. http://www.daemonforums.org is where we all hang out now. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 05:27:49 2008 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 3EA98106568A for ; Fri, 3 Oct 2008 05:27:49 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0107A8FC1C for ; Fri, 3 Oct 2008 05:27:48 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 1C3C3173B0; Fri, 3 Oct 2008 15:27:46 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-151-43.lns10.syd7.internode.on.net [121.44.151.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 25E791722A for ; Fri, 3 Oct 2008 15:27:42 +1000 (EST) Message-ID: <48E5AD16.5000101@modulus.org> Date: Fri, 03 Oct 2008 15:26:46 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: trying to track down UFS "dup alloc" message on iSCSI 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, 03 Oct 2008 05:27:49 -0000 I am playing with an iSCSI device on FreeBSD client running UFS2 on the device over a LAN. Everything works well until I reboot the iSCSI server - the client pauses for a minute or so then continues working after iSCSI server comes back. No I/O errors are reported. Everything seems to work fine for a little while! But shortly afterwards, I get a panic with the message panic: ffs_valloc: dup alloc It seems related to the length of the delay the iSCSI device is paused - restarting the iSCSI target daemon process doesn't cause the problem but rebooting the whole target box does cause it. 1. Could this be related to the patch Matt Dillon created years ago which I found here? http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html 2. Can anyone think of any other reason this might happen? I know I am stretching UFS to the limits here, expecting it to pause and restart after more than a minute of locked disk :-) However, since all I/O eventually complete successfully and no errors are reported, I find it suspicious. Cheers - Andrew ps. running latest iSCSI code 2.1 on latest 7-STABLE box. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 08:00:45 2008 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 6A8101065688; Fri, 3 Oct 2008 08:00:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id E7F548FC08; Fri, 3 Oct 2008 08:00:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Klfac-000DzZ-Ie; Fri, 03 Oct 2008 11:00:42 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Claus Guttesen" In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to "Claus Guttesen" message dated "Mon, 29 Sep 2008 10:40:05 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2008 11:00:42 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , Robert Watson , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 08:00:45 -0000 > > it more difficult than I expected. > > for one, the kernel date was missleading, the actual source update is the key, so > > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > > yet seems relevant. > > > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > > give the same throughput, which seem to point to UDP changes ... > > Can you post the network-numbers? so I ran some more test, these are for writes IO: server is a NetApp: kernel from 18/08/08 00:00:0 : /----- UDP ----//---- TCP -------/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 08:03:18 2008 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 9E7151065686 for ; Fri, 3 Oct 2008 08:03:18 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E396E8FC0C for ; Fri, 3 Oct 2008 08:03:17 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 03 Oct 2008 08:03:15 -0000 Received: from 85-127-18-201.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.18.201] by mail.gmx.net (mp003) with SMTP; 03 Oct 2008 10:03:15 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1/D01Z5vqrD49N8c+a4k0ivi4shgS5p30BPAyf4wZ qDDwPzS3W3fHdM From: Stefan Ehmann To: freebsd-stable@freebsd.org Date: Fri, 3 Oct 2008 10:03:13 +0200 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) MIME-Version: 1.0 Message-Id: <200810031003.14400.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55,0.55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: top/ps CPU percentage broken on 7.1-PRERELEASE? 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, 03 Oct 2008 08:03:18 -0000 The CPU % displayed by top/ps for single processes seem to be broken here. E.g. for a simple shell loop: top starts displaying around 20% for bash. Within some seconds it converges to 0%. ps values seem to be consistent with top. The value in the time column seems to be correct. On every refresh it increases by 2s. last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 09:07:00 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free Swap: 1280M Total, 1280M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash All other process are using 0% CPU. I did a buildworld/kernel yesterday to be sure everything is in sync. I have CURRENT on a different hard disk. Haven't seen the problem there. Are there any relevant fixes that weren't MFCed? Does anyone else see this? This is a single CPU i386 machine. -- Stefan From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 08:15:02 2008 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 42ED6106569E; Fri, 3 Oct 2008 08:15:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 150E08FC08; Fri, 3 Oct 2008 08:15:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 930A546B09; Fri, 3 Oct 2008 04:15:01 -0400 (EDT) Date: Fri, 3 Oct 2008 09:15:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 08:15:02 -0000 On Fri, 3 Oct 2008, Danny Braniss wrote: >>> it more difficult than I expected. >>> for one, the kernel date was missleading, the actual source update is the key, so >>> the window of changes is now 28/July to 19/August. I have the diffs, but nothing >>> yet seems relevant. >>> >>> on the other hand, I tried NFS/TCP, and there things seem ok, ie the >>> 'good' and the 'bad' give the same throughput, which seem to point to UDP >>> changes ... >> >> Can you post the network-numbers? > so I ran some more test, these are for writes IO: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to --------- --------- INP_RLOCK INP_WLOCK INP_RUNLOCK INP_WUNLOCK INP_RLOCK_ASSERT INP_WLOCK_ASSERT Robert N M Watson Computer Laboratory University of Cambridge > > server is a NetApp: > > kernel from 18/08/08 00:00:0 : > /----- UDP ----//---- TCP -------/ > 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s > 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s > 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s > 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s > 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s > 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s > 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s > 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s > 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s > 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s > 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s > 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s > 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s > 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s > 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s > 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s > > kernel from 19/08/08 00:00:00: > 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s > 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s > 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s > 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s > 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s > 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s > 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s > 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s > 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s > 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s > 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s > 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s > 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s > 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s > 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s > 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s > > > > > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 08:36:49 2008 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 AE0A1106569B for ; Fri, 3 Oct 2008 08:36:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0398FC18 for ; Fri, 3 Oct 2008 08:36:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so864501tid.3 for ; Fri, 03 Oct 2008 01:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CbyF/3dGZdrjsQWSdYHVPOfSoFzoakzjMfz4ye0Q1X8=; b=ZCc/HsPMkXyRG04djxtQRVOkfdxe9ZLjpBIm8cvvBD0M7QQowY75Ry2Be17QXKTo0l FIQIVtXKKrnWlnOjy0JcnZMciBIrnqKYSzGuliKweR1rDClcGZHhvJ6QpQvltzLElgbT 99nimi6IUy1tRMTlbGgl8NT74Y4pQ57ig5iu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dG0qbBNG1GGTO1hCWD8ChjoddwIz2CJ9FHmzCgooiIOBJKNetwq/e/Qq/cwQVrrSv3 iAOjm0iNIGtQJhvlbiquk2/x0QcvVP+qLO2Fa8HtPrQ7l2mdHeEPZLrKRLRSEGy5XgFS paYslImGI8QOhy8SWuu+WYS3cCJEL0+AYD810= Received: by 10.110.95.15 with SMTP id s15mr258518tib.8.1223023007423; Fri, 03 Oct 2008 01:36:47 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id j5sm144062tid.11.2008.10.03.01.36.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Oct 2008 01:36:45 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m938YinN072787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 17:34:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m938Yhg2072786; Fri, 3 Oct 2008 17:34:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 3 Oct 2008 17:34:43 +0900 From: Pyun YongHyeon To: Torfinn Ingolfsen Message-ID: <20081003083443.GD71518@cdnetworks.co.kr> References: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> <20080922021022.GC26294@cdnetworks.co.kr> <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.5-prerelease and if_re - patches needed? 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: Fri, 03 Oct 2008 08:36:49 -0000 On Thu, Oct 02, 2008 at 10:25:42PM +0200, Torfinn Ingolfsen wrote: > On Mon, 22 Sep 2008 11:10:23 +0900 > Pyun YongHyeon wrote: > > > Due to lack of time and energy the change made in HEAD wasn't MFCed > > to RELENG_6 so you may still need some patch. stable/7 should have > > no such problems though. > > Does anybody happen to know which patch? > > > Maybe the issue you're seeing comes from misuse of bus_dma(9) which > > was corrected in stable/7. > > But not MFC'ed to RELENG_6 I guess? > Is therer a patch for RELENG_6 somewhere? I couldn't find spare time to regenerate patches for RELENG_6. Sorry. Maybe you can use if_re.c/if_rlreg.h in RELENG_7 with minor modification. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:02:46 2008 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 4C9701065686; Fri, 3 Oct 2008 09:02:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id DAD958FC1E; Fri, 3 Oct 2008 09:02:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KlgYe-000Es2-8u; Fri, 03 Oct 2008 12:02:44 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Fri, 03 Oct 2008 09:15:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2008 12:02:43 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 09:02:46 -0000 > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >>> it more difficult than I expected. > >>> for one, the kernel date was missleading, the actual source update is the key, so > >>> the window of changes is now 28/July to 19/August. I have the diffs, but nothing > >>> yet seems relevant. > >>> > >>> on the other hand, I tried NFS/TCP, and there things seem ok, ie the > >>> 'good' and the 'bad' give the same throughput, which seem to point to UDP > >>> changes ... > >> > >> Can you post the network-numbers? > > so I ran some more test, these are for writes IO: > > OK, so it looks like this was almost certainly the rwlock change. What > happens if you pretty much universally substitute the following in > udp_usrreq.c: > > Currently Change to > --------- --------- > INP_RLOCK INP_WLOCK > INP_RUNLOCK INP_WUNLOCK > INP_RLOCK_ASSERT INP_WLOCK_ASSERT > I guess you were almost certainly correct :-) I did the global subst. on the udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! danny > Robert N M Watson > Computer Laboratory > University of Cambridge > > > > > server is a NetApp: > > > > kernel from 18/08/08 00:00:0 : > > /----- UDP ----//---- TCP -------/ > > 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s > > 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s > > 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s > > 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s > > 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s > > 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s > > 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s > > 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s > > 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s > > 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s > > 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s > > 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s > > 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s > > 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s > > 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s > > 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s > > > > kernel from 19/08/08 00:00:00: > > 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s > > 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s > > 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s > > 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s > > 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s > > 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s > > 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s > > 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s > > 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s > > 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s > > 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s > > 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s > > 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s > > 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s > > 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s > > 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s > > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:06:17 2008 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 469C51065687; Fri, 3 Oct 2008 09:06:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2F2A8FC28; Fri, 3 Oct 2008 09:06:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 7560946B1A; Fri, 3 Oct 2008 05:06:16 -0400 (EDT) Date: Fri, 3 Oct 2008 10:06:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 09:06:17 -0000 On Fri, 3 Oct 2008, Danny Braniss wrote: >> OK, so it looks like this was almost certainly the rwlock change. What >> happens if you pretty much universally substitute the following in >> udp_usrreq.c: >> >> Currently Change to >> --------- --------- >> INP_RLOCK INP_WLOCK >> INP_RUNLOCK INP_WUNLOCK >> INP_RLOCK_ASSERT INP_WLOCK_ASSERT > > I guess you were almost certainly correct :-) I did the global subst. on the > udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v > 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! OK. This is a change I'd rather not back out since it significantly improves performance for many other UDP workloads, so we need to figure out why it's hurting us so much here so that we know if there are reasonable alternatives. Would it be possible for you to do a run of the workload with both kernels using LOCK_PROFILING around the benchmark, and then we can compare lock contention in the two cases? What we often find is that relieving contention at one point causes new contention at another point, and if the primitive used at that point handles contention less well for whatever reason, performance can be reduced rather than improved. So maybe we're looking at an issue in the dispatched UDP code from so_upcall? Another less satisfying (and fundamentally more difficult) answer might be "something to do with the scheduler", but a bit more analysis may shed some light. Robert N M Watson Computer Laboratory University of Cambridge > > danny > > >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> server is a NetApp: >>> >>> kernel from 18/08/08 00:00:0 : >>> /----- UDP ----//---- TCP -------/ >>> 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s >>> 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s >>> 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s >>> 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s >>> 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s >>> 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s >>> 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s >>> 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s >>> 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s >>> 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s >>> 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s >>> 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s >>> 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s >>> 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s >>> 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s >>> 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s >>> >>> kernel from 19/08/08 00:00:00: >>> 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s >>> 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s >>> 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s >>> 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s >>> 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s >>> 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s >>> 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s >>> 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s >>> 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s >>> 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s >>> 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s >>> 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s >>> 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s >>> 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s >>> 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s >>> 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s >>> >>> >>> >>> >>> > > > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:08:47 2008 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 180CF106568A for ; Fri, 3 Oct 2008 09:08:47 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 799A58FC1A for ; Fri, 3 Oct 2008 09:08:45 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: (qmail 64385 invoked by uid 89); 3 Oct 2008 09:08:42 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 3 Oct 2008 09:08:42 -0000 Date: Fri, 3 Oct 2008 11:08:40 +0200 From: Oliver Lehmann To: cpghost Message-Id: <20081003110840.f1c2d5da.lehmann@ans-netz.de> In-Reply-To: <20081002225036.GC2539@phenom.cordula.ws> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <20081002185106.a1183896.lehmann@ans-netz.de> <20081002225036.GC2539@phenom.cordula.ws> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: system hangup - I'm lost 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, 03 Oct 2008 09:08:47 -0000 cpghost wrote: > If it's PATA, check the cabling, then check it again, and just to > make sure, replace the cable even if the system used to work flawlessly > in the past. I've had this on a few servers, but replacing the cables > always fixed the problem for me. It's SATA - it's a 3ware 9500S-4LP controller. I can just hope it would have detect any drive problem (even if it would result because of bad cabeling). If not I don't know why I had a raid controller anyway ;) The only other disk drive I've on that system is an USB attached hdd for backup purpose... So I can't realy try having the swap somewhere else.. //nudel> /c0 show all /c0 Driver Version = 3.60.04.003 /c0 Model = 9500S-4LP /c0 Available Memory = 112MB /c0 Firmware Version = FE9X 2.08.00.009 /c0 Bios Version = BE9X 2.03.01.052 /c0 Boot Loader Version = BL9X 2.02.00.001 /c0 Serial Number = D19004A5300589 /c0 PCB Version = Rev 019 /c0 PCHIP Version = 1.50 /c0 ACHIP Version = 3.20 /c0 Number of Ports = 4 /c0 Number of Drives = 4 /c0 Number of Units = 1 /c0 Total Optimal Units = 1 /c0 Not Optimal Units = 0 /c0 JBOD Export Policy = off /c0 Disk Spinup Policy = 1 /c0 Spinup Stagger Time Policy (sec) = 2 /c0 Cache on Degrade Policy = Follow Unit Policy Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 698.461 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 232.88 GB 488397168 WD-WCANK1079272 p1 OK u0 232.88 GB 488397168 WD-WCANK1120378 p2 OK u0 232.88 GB 488397168 WD-WCANK1120936 p3 OK u0 232.88 GB 488397168 WD-WCANK1120805 Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 255 24-Aug-2008 //nudel> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:17:46 2008 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 4D22210656A5; Fri, 3 Oct 2008 09:17:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id EB2F78FC16; Fri, 3 Oct 2008 09:17:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KlgnA-000F6w-NT; Fri, 03 Oct 2008 12:17:44 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Fri, 03 Oct 2008 10:06:16 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2008 12:17:44 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 09:17:46 -0000 > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >> OK, so it looks like this was almost certainly the rwlock change. What > >> happens if you pretty much universally substitute the following in > >> udp_usrreq.c: > >> > >> Currently Change to > >> --------- --------- > >> INP_RLOCK INP_WLOCK > >> INP_RUNLOCK INP_WUNLOCK > >> INP_RLOCK_ASSERT INP_WLOCK_ASSERT > > > > I guess you were almost certainly correct :-) I did the global subst. on the > > udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v > > 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! > > OK. This is a change I'd rather not back out since it significantly improves > performance for many other UDP workloads, so we need to figure out why it's > hurting us so much here so that we know if there are reasonable alternatives. > > Would it be possible for you to do a run of the workload with both kernels > using LOCK_PROFILING around the benchmark, and then we can compare lock > contention in the two cases? What we often find is that relieving contention > at one point causes new contention at another point, and if the primitive used > at that point handles contention less well for whatever reason, performance > can be reduced rather than improved. So maybe we're looking at an issue in > the dispatched UDP code from so_upcall? Another less satisfying (and > fundamentally more difficult) answer might be "something to do with the > scheduler", but a bit more analysis may shed some light. gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be helpfull. as a side note, many years ago I checked out NFS/TCP and it was really bad, I even remember NetApp telling us to drop TCP, but now, things look rather better. Wonder what caused it. danny From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:21:10 2008 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 CFF9610656B5; Fri, 3 Oct 2008 09:21:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0E78FC15; Fri, 3 Oct 2008 09:21:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KlgqT-000FAD-GE; Fri, 03 Oct 2008 12:21:09 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Fri, 03 Oct 2008 10:06:16 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2008 12:21:09 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 09:21:10 -0000 forget it about LOCK_PROFILING, I'm RTFM now :-) though some hints on values might be helpful. have a nice weekend, danny From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:25:24 2008 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 2FBAA106568D; Fri, 3 Oct 2008 09:25:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2DD28FC0C; Fri, 3 Oct 2008 09:25:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 880FD46B0D; Fri, 3 Oct 2008 05:25:23 -0400 (EDT) Date: Fri, 3 Oct 2008 10:25:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org, Claus Guttesen Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 09:25:24 -0000 On Fri, 3 Oct 2008, Danny Braniss wrote: > gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be > helpfull. The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the defaults work fine most of the time, so just use them. Turn the enable syscl on just before you begin a run, and turn it off immediately afterwards. Make sure to reset between reruns (rebooting to a new kernel is fine too!). > as a side note, many years ago I checked out NFS/TCP and it was really bad, > I even remember NetApp telling us to drop TCP, but now, things look rather > better. Wonder what caused it. Well, the virtues of TCP become more apparent with higher network speeds, as the logic to fill pipes using TCP, manage flow control, etc, is a lot more sophisticated than what's in the RPC code for using UDP. The downsides to UDP are also becoming more apparent: as network speeds go up, fragmented UDP risks IP ID collisions which could lead to data corruption, or at the very least, dropped packets. We have changed the default for NFSv3 mounts to TCP in 8.x, and talked about doing it for 7.1; unfortunately the timing wasn't quite right, so it most likely will appear in 7.2. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 09:39:39 2008 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 156F4106569C for ; Fri, 3 Oct 2008 09:39:39 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id AC1198FC20 for ; Fri, 3 Oct 2008 09:39:38 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by chen.org.nz (Postfix, from userid 1000) id 245E128418; Fri, 3 Oct 2008 22:39:37 +1300 (NZDT) Date: Fri, 3 Oct 2008 22:39:37 +1300 From: Jonathan Chen To: Stefan Ehmann Message-ID: <20081003093937.GA4944@osiris.chen.org.nz> References: <200810031003.14400.shoesoft@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810031003.14400.shoesoft@gmx.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: top/ps CPU percentage broken on 7.1-PRERELEASE? 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, 03 Oct 2008 09:39:39 -0000 On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote: > The CPU % displayed by top/ps for single processes seem to be broken here. > > E.g. for a simple shell loop: > top starts displaying around 20% for bash. Within some seconds it converges to > 0%. > > ps values seem to be consistent with top. > > The value in the time column seems to be correct. On every refresh it > increases by 2s. > > last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 > 09:07:00 > 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie > CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle > Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free > Swap: 1280M Total, 1280M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash > > All other process are using 0% CPU. > > I did a buildworld/kernel yesterday to be sure everything is in sync. I have > CURRENT on a different hard disk. Haven't seen the problem there. > Are there any relevant fixes that weren't MFCed? > > Does anyone else see this? This is a single CPU i386 machine. Yes, my Java processes now run at 800% at times on my dual processor AMD64 system. -- Jonathan Chen ---------------------------------------------------------------------- The Internet: an empirical test of the idea that a million monkeys banging on a million keyboards can produce Shakespeare From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 11:17:05 2008 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 8ECF210656A2 for ; Fri, 3 Oct 2008 11:17:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 748EC8FC1F for ; Fri, 3 Oct 2008 11:17:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id N9Wt1a00A0lTkoCA4BH50o; Fri, 03 Oct 2008 11:17:05 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id NBH31a0092P6wsM8QBH4bh; Fri, 03 Oct 2008 11:17:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=CHt_mEGTzOcA:10 a=OJujf1_Ut9MA:10 a=QycZ5dHgAAAA:8 a=uwOuELIn7mTlcXwOhWoA:9 a=LHRr8pLdzLOz8vaixfMSZ5ptZzgA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CDA94C9419; Fri, 3 Oct 2008 04:17:03 -0700 (PDT) Date: Fri, 3 Oct 2008 04:17:03 -0700 From: Jeremy Chadwick To: Bruce Cran Message-ID: <20081003111703.GA27385@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E535D3.8000805@cran.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 11:17:05 -0000 On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > rules got loaded during boot, despite pf itself having been enabled: > > router# pfctl -s rules > router# pfctl -e -f /etc/pf.conf > pfctl: pf already enabled > [connection is closed due to new rules being loaded] > router# pfctl -s rules > scrub in all fragment reassemble > [... lots of rules listed] > > Has anyone else seen this problem, or have I just missed something > that's changed between 7.0 and 7.1 in the way pf works? I was seeing something similar on my own box which I just upgraded from a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no rules. pfctl -s info showed packet counters, but no interface stats (due to the rules not being loaded, e.g. no loginterface). kldstat showed pflog.ko and pf.ko loaded. If I did /etc/rc.d/pf start, the rules would loaded, and everything starts working as expected. I rebooted the box and saw the following on serial console, which I'm pretty sure is what's responsible for the breakage: Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled I'd recommend you check your kernel console log on boot-up and see if anything is showing up there. I'm about to go digging to find out what's wrong with my ALTQ rules. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 11:38:28 2008 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 51A7C10656A0 for ; Fri, 3 Oct 2008 11:38:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id E457B8FC2E for ; Fri, 3 Oct 2008 11:38:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA10.westchester.pa.mail.comcast.net with comcast id NBU41a0010ldTLk5ABeT23; Fri, 03 Oct 2008 11:38:27 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA04.westchester.pa.mail.comcast.net with comcast id NBeQ1a00K2P6wsM3QBeQw2; Fri, 03 Oct 2008 11:38:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=CHt_mEGTzOcA:10 a=OJujf1_Ut9MA:10 a=QycZ5dHgAAAA:8 a=JOr_kaPOtu08zEbprysA:9 a=8El2cu6u8I-SJ3X6EeIA:7 a=mhKmPw4oBOWUK70ZEuP3FqN_iTEA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 3630FC941A; Fri, 3 Oct 2008 04:38:24 -0700 (PDT) Date: Fri, 3 Oct 2008 04:38:24 -0700 From: Jeremy Chadwick To: freebsd-pf@freebsd.org Message-ID: <20081003113824.GA27757@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081003111703.GA27385@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Bruce Cran , freebsd-stable@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 11:38:28 -0000 On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > > rules got loaded during boot, despite pf itself having been enabled: > > > > router# pfctl -s rules > > router# pfctl -e -f /etc/pf.conf > > pfctl: pf already enabled > > [connection is closed due to new rules being loaded] > > router# pfctl -s rules > > scrub in all fragment reassemble > > [... lots of rules listed] > > > > Has anyone else seen this problem, or have I just missed something > > that's changed between 7.0 and 7.1 in the way pf works? > > I was seeing something similar on my own box which I just upgraded from > a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no > rules. pfctl -s info showed packet counters, but no interface stats > (due to the rules not being loaded, e.g. no loginterface). > > kldstat showed pflog.ko and pf.ko loaded. > > If I did /etc/rc.d/pf start, the rules would loaded, and everything > starts working as expected. > > I rebooted the box and saw the following on serial console, which I'm > pretty sure is what's responsible for the breakage: > > Enabling pf. > Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received > cannot determine interface bandwidth for bge0, specify an absolute > bandwidth > altq not defined on bge0 > altq not defined on bge0 > /conf/ME/pf.conf:52: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:53: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:54: errors in queue definition > pfctl: Syntax error in config file: pf rules not loaded > pf enabled Cross-posting to freebsd-pf (I'm sorry for doing this, but it needs attention from both -pf and -stable). I've figured out what the problem is. This is not good, and is guaranteed to bite other people. I'd like to believe this is an rc-related problem, but I'm not sure how to fix it. The problem in my case: The physical interfaces were brought online, but were still technically offline (the switch and NIC PHY were taking some time to negotiate speed and duplex). Boot messages: bge0: link state changed to DOWN bge1: link state changed to DOWN lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bge0: flags=8843 mtu 1500 options=1b inet XXXXXXXXXXX netmask 0xffffff80 broadcast XXXXXXXXXXXXX ether 00:30:48:81:fc:8a media: Ethernet autoselect (none) status: no carrier bge1: flags=8843 mtu 1500 options=1b inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXXX ether 00:30:48:81:fc:8b media: Ethernet autoselect (none) status: no carrier Note that the interfaces are UP, not DOWN. Then the very next thing seen on the console: Starting pflog. pflog0: promiscuous mode enabled Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled The error message about "interface bandwidth" is the key here. My ALTQ rules use "bandwidth ", not a static amount in bits: altq on $ext_if cbq bandwidth 100% queue { std, blah, blah2 } queue std bandwidth 95% cbq(default borrow) queue blah bandwidth 384Kb queue blah2 bandwidth 384Kb Since the PHY hadn't negotiated speed, pf was unable to determine what the percentage really mapped to bandwidth/bit-wise. If at all possible, pf should wait for the interfaces to come up fully (that includes autonegotiation being completed; do we have framework for this?) before starting. I changed my rules to use a static speeds (100% --> 100Mb, and 95% --> 95Mb), which appear to work, but after the 2nd reboot the speed/duplex had been negotiated by the time pf had started, so I don't know if it truly fixed anything. I don't know what pf will do if you say "100Mb" for an interface which has no link/speed defined yet. It may behave the same way as shown above; I don't know. This needs some thought and definitely a solution. Again, note that I'm using RELENG_6, but I've a feeling this might bite RELENG_7 too. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 13:22:23 2008 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 1D7931065687 for ; Fri, 3 Oct 2008 13:22:23 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id CB1A08FC0A for ; Fri, 3 Oct 2008 13:22:22 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7c1c.q.ppp-pool.de [89.53.124.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 25FFF12883F for ; Fri, 3 Oct 2008 15:05:14 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 48D1E2E913; Fri, 3 Oct 2008 15:03:59 +0200 (CEST) Message-ID: <48E61880.903@vwsoft.com> Date: Fri, 03 Oct 2008 15:05:04 +0200 From: Volker User-Agent: Thunderbird 2.0.0.17 (X11/20080930) MIME-Version: 1.0 To: Bruce Cran References: <48E535D3.8000805@cran.org.uk> In-Reply-To: <48E535D3.8000805@cran.org.uk> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1223643845.86285@YsqcespMitDv2ue5qiatAw X-MailScanner-ID: 48D1E2E913.C1A88 X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: stable@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 13:22:23 -0000 On 12/23/-58 20:59, Bruce Cran wrote: >
I recently upgraded my i386 router from 7.0 > to 7.1-PRERELEASE. I rebooted it today but despite pf_enable="YES" > being in /etc/rc.conf no rules got loaded during boot, despite pf itself > having been enabled: > > router# pfctl -s rules > router# pfctl -e -f /etc/pf.conf > pfctl: pf already enabled > [connection is closed due to new rules being loaded] > router# pfctl -s rules > scrub in all fragment reassemble > [... lots of rules listed] > > Has anyone else seen this problem, or have I just missed something > that's changed between 7.0 and 7.1 in the way pf works? > Hi Bruce, > # pfctl -sr | wc -l > 81 > # grep pf /etc/rc.conf > pf_enable="YES" > pf_rules="/etc/Firewall/pf-ces.conf" > pflog_enable="YES" this is from a very recent 7-STABLE box: > # uname -a > FreeBSD cesar.sz.vwsoft.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #46: Tue Sep 30 23:33:36 CEST 2008 root@cesar.sz.vwsoft.com:/usr/obj/usr/src/sys/CESAR i386 Do you mind to show me your rules? What does ``pfctl -gnf /path/to/your/rules'' give? Volker From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 13:26:54 2008 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 55C19106568C; Fri, 3 Oct 2008 13:26:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 02C058FC16; Fri, 3 Oct 2008 13:26:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KlkgH-000Iv9-2A; Fri, 03 Oct 2008 16:26:53 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Fri, 03 Oct 2008 10:25:23 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2008 16:26:53 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 13:26:54 -0000 > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > > gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be > > helpfull. > > The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the > defaults work fine most of the time, so just use them. Turn the enable syscl > on just before you begin a run, and turn it off immediately afterwards. Make > sure to reset between reruns (rebooting to a new kernel is fine too!). > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof there 3 files: 7.1-100 host connected at 100 running -prerelease 7.1-1000 same but connected at 1000 7.0-1000 -stable with your 'patch' at 100 my benchmark didn't suffer from the profiling, average was about 9. at 1000 the benchmark got realy hit, average was around 12 for the patched, and 4 for the unpatched (less than at 100). danny From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 13:33:57 2008 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 09E341065691 for ; Fri, 3 Oct 2008 13:33:57 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 82AE38FC18 for ; Fri, 3 Oct 2008 13:33:56 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 3BF33191A71; Fri, 3 Oct 2008 15:33:54 +0200 (CEST) Received: from saturn.kn-bremen.de (noident@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m93DG1X1005596 for ; Fri, 3 Oct 2008 15:16:01 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m93DG0uW005595 for freebsd-stable@FreeBSD.org; Fri, 3 Oct 2008 15:16:00 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 3 Oct 2008 15:16:00 +0200 To: freebsd-stable@FreeBSD.org Message-ID: <20081003131600.GA5421@saturn.kn-bremen.de> Mail-Followup-To: freebsd-stable@FreeBSD.org References: <20080917204107.GA11167@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917204107.GA11167@saturn.kn-bremen.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb 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, 03 Oct 2008 13:33:57 -0000 On Wed, Sep 17, 2008 at 10:41:07PM +0200, I wrote: > Hi! > > I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c > commit (r183050, thanx! :) I was able to build a kernel that could > kldload dtraceall on 7-stable amd64, but trying even simple things like > dtrace -n tick-1sec > only runs for a short time, or not at all, ending with $subject: > > # dtrace -n tick-1sec > dtrace: description 'tick-1sec' matched 1 probe > dtrace: buffer size lowered to 2m > CPU ID FUNCTION:NAME > 1 32125 :tick-1sec > dtrace: processing aborted: Abort due to systemic unresponsiveness > # dtrace -n tick-1sec > dtrace: description 'tick-1sec' matched 1 probe > dtrace: buffer size lowered to 2m > dtrace: processing aborted: Abort due to systemic unresponsiveness > # > > Looking around on the net I find that this is probably related to > dtrace_gethrtime() (this box is SMP), which I see defined in > sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, > and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. > The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into > account which the one in sys/amd64/amd64/tsc.c doesn't, is there any > particular reason this version is used? Also I don't see it in HEAD... > I since found out two things: a) the version of dtrace_gethrtime() in sys/amd64/amd64/tsc.c is indeed not needed, and b) removing it still didn't fix my problem, stopping powerd then did, even with the original kernel. Doh! :) Anyway, I'm still pretty sure the #ifdef KDTRACE_HOOKS code in sys/amd64/amd64/tsc.c can go, the version of dtrace_gethrtime() in sys/cddl/dev/dtrace/amd64/dtrace_subr.c looks more correct at least... Thanx, Juergen From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 14:22:56 2008 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 4801C106568D for ; Fri, 3 Oct 2008 14:22:56 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id F27908FC0A for ; Fri, 3 Oct 2008 14:22:55 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KllYP-000LLq-0m for freebsd-stable@freebsd.org; Fri, 03 Oct 2008 16:22:55 +0200 Message-ID: <48E62ABA.6070901@kkip.pl> Date: Fri, 03 Oct 2008 16:22:50 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-10-03 16:22:55 X-Connected-IP: 192.168.0.10:4017 X-Message-Linecount: 35 X-Body-Linecount: 24 X-Message-Size: 1216 X-Body-Size: 814 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: fxp performance with POLLING 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, 03 Oct 2008 14:22:56 -0000 Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 15:06:23 2008 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 132BA106568A for ; Fri, 3 Oct 2008 15:06:23 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from mx.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb7:b8fe]) by mx1.freebsd.org (Postfix) with ESMTP id 88EE58FC19 for ; Fri, 3 Oct 2008 15:06:22 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id m93F6CdN029012; Fri, 3 Oct 2008 17:06:12 +0200 From: Pieter de Goeje To: freebsd-stable@freebsd.org Date: Fri, 3 Oct 2008 17:06:11 +0200 User-Agent: KMail/1.9.10 References: <48E62ABA.6070901@kkip.pl> In-Reply-To: <48E62ABA.6070901@kkip.pl> Organization: Service2Media MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810031706.11941.pdegoeje@service2media.com> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pdegoeje@service2media.com X-Spam-Status: No Cc: Bartosz Stec Subject: Re: fxp performance with POLLING 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, 03 Oct 2008 15:06:23 -0000 On Friday 03 October 2008, Bartosz Stec wrote: > Hello again :) > > With POLLING enabled I experience about 10%-25% performance drop when > copying files over network. Tested with both SAMBA and NFS. Is it normal? Yes. You don't want to use polling unless you set kern.hz to 10000 or something in that range. If you have a NIC with interrupt moderation, polling should almost never be necessary. Note that polling can still be useful for routers, because it allows you to have a much more responsive system even when handling heavy network traffic. -- Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 16:51:37 2008 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 A3486106568B for ; Fri, 3 Oct 2008 16:51:37 +0000 (UTC) (envelope-from henrik@50hz.ws) Received: from dsp.50hz.ws (50hz.ws [78.46.69.237]) by mx1.freebsd.org (Postfix) with ESMTP id 662C58FC1F for ; Fri, 3 Oct 2008 16:51:37 +0000 (UTC) (envelope-from henrik@50hz.ws) Received: by dsp.50hz.ws (Postfix, from userid 1001) id 15CD89B4ED; Fri, 3 Oct 2008 16:51:35 +0200 (CEST) Date: Fri, 3 Oct 2008 16:51:35 +0200 From: Henrik Friedrichsen To: FreeBSD stable Message-ID: <20081003145135.GA4528@dsp.50hz.ws> Mail-Followup-To: FreeBSD stable References: <48E02557.2020303@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE 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, 03 Oct 2008 16:51:37 -0000 USB support in the BIOS? What kind of support does the BIOS provide that you can disable? I'm only able to disable the USB device, but that'd turn it off completely :( Henrik. On Mon, Sep 29, 2008 at 10:05:02PM +0200, Ronald Klop wrote: > On Mon, 29 Sep 2008 02:46:15 +0200, Bruce M Simpson > wrote: > > >Hi, > > > >I've noticed some general instability with plugging in or removing USB > >devices with FreeBSD 7.x, even when the devices are not actively in use. > > > >I had this happen with umass and ucom devices 3 times today. The machine > >hangs solid, there are no obvious signs of a panic or trap to DDB. I > >can't provide backtraces unfortunately -- these hangs happen on both my > >laptop and desktop, and I usually have X running -- if I had more > >specific information, I'd open a PR. > > > >Again, there seems to be no reason why this should happen, the devices > >are off-the-shelf consumer items known to work with existing drivers, > >and have been repeatedly used in other OSes without these hangs > >happening; consider this an "anecdotal report". > > > >[For some reason my IBM laptop will often not allow me to break into DDB > >on a driver related panic, and will just immediately reboot -- I lack > >free time to track down exactly why this could be. > >My desktop has a USB keyboard and this appears not to be supported by > >DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another > >story.] > > > >thanks > >BMS > > On my computer I had to disable USB support in the BIOS because it > 'conflicted' with USB support of FreeBSD. > FreeBSD still detects USB and all connected devices. > Maybe this helps on your computer also. > > Ronald. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 18:02:43 2008 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 6ED48106568C for ; Fri, 3 Oct 2008 18:02:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 428568FC1A for ; Fri, 3 Oct 2008 18:02:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id DFE545D03; Fri, 3 Oct 2008 13:46:33 -0400 (EDT) X-Virus-Scanned: amavisd-new+ClamAV at codefab.com Received: from [192.168.1.3] (pool-71-190-72-228.nycmny.east.verizon.net [71.190.72.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTPSA id ACE105CEF; Fri, 3 Oct 2008 13:46:31 -0400 (EDT) Message-ID: <48E65A6E.4090203@mac.com> Date: Fri, 03 Oct 2008 13:46:22 -0400 From: Chuck Swiger User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Pieter de Goeje References: <48E62ABA.6070901@kkip.pl> <200810031706.11941.pdegoeje@service2media.com> In-Reply-To: <200810031706.11941.pdegoeje@service2media.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Bartosz Stec Subject: Re: fxp performance with POLLING 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, 03 Oct 2008 18:02:43 -0000 Pieter de Goeje wrote: > On Friday 03 October 2008, Bartosz Stec wrote: >> Hello again :) >> >> With POLLING enabled I experience about 10%-25% performance drop when >> copying files over network. Tested with both SAMBA and NFS. Is it normal? > > Yes. You don't want to use polling unless you set kern.hz to 10000 or > something in that range. HZ = 1000 or 2000 is fine for most purposes, at least up through T3 level bandwidth. For a home LAN or small business office of a half-dozen machines using DSL/Cable (~ 1-5 MBs up), even a P2-300 or VIA C3 600 at HZ=250 works OK as a firewall/router. The main thing that using polling does is that it adds a reasonably fixed amount of latency (ie, the poll interval) but gives solid processing performance even under heavy load, just as you say: > If you have a NIC with interrupt moderation, polling > should almost never be necessary. Note that polling can still be useful for > routers, because it allows you to have a much more responsive system even > when handling heavy network traffic. Note that he's got the link0 flag going, so that should mean he's using firmware with the fxp NIC which does interrupt moderation. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 18:04:53 2008 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 5628B10656A8; Fri, 3 Oct 2008 18:04:53 +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 2AC5D8FC12; Fri, 3 Oct 2008 18:04:53 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Klp1I-0002Xb-98; Fri, 03 Oct 2008 14:04:52 -0400 Date: Fri, 3 Oct 2008 14:04:52 -0400 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20081003180452.GA1262@in-addr.com> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081003111703.GA27385@icarus.home.lan> Cc: Bruce Cran , stable@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 18:04:53 -0000 On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > > rules got loaded during boot, despite pf itself having been enabled: > > > > router# pfctl -s rules > > router# pfctl -e -f /etc/pf.conf > > pfctl: pf already enabled > > [connection is closed due to new rules being loaded] > > router# pfctl -s rules > > scrub in all fragment reassemble > > [... lots of rules listed] > > > > Has anyone else seen this problem, or have I just missed something > > that's changed between 7.0 and 7.1 in the way pf works? > > I was seeing something similar on my own box which I just upgraded from > a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no > rules. pfctl -s info showed packet counters, but no interface stats > (due to the rules not being loaded, e.g. no loginterface). > > kldstat showed pflog.ko and pf.ko loaded. > > If I did /etc/rc.d/pf start, the rules would loaded, and everything > starts working as expected. > > I rebooted the box and saw the following on serial console, which I'm > pretty sure is what's responsible for the breakage: > > Enabling pf. > Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received > cannot determine interface bandwidth for bge0, specify an absolute > bandwidth > altq not defined on bge0 > altq not defined on bge0 > /conf/ME/pf.conf:52: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:53: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:54: errors in queue definition > pfctl: Syntax error in config file: pf rules not loaded > pf enabled > > I'd recommend you check your kernel console log on boot-up and see if > anything is showing up there. I'm about to go digging to find out > what's wrong with my ALTQ rules. I noticed the last time I rebooted my gateway to patch the latest v6 hole that vr0 (in my case) had not negotiated link by the time pf started (even tho its a static IP address, not DHCP). This meant that there was no link speed for altq to base its queueing on, and the entire pf load failed (I think). I changed my vr0 altq line to hardcode the speed at 100mbit and I think that should fix it Why this is an issue now and it wasn't previously I'm not sure. The current failure mode is certainly not helpful. I'm not sure if we should force pf to wait for link on altq interfaces or not. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 18:12:33 2008 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 26AA6106568E for ; Fri, 3 Oct 2008 18:12:33 +0000 (UTC) (envelope-from blue@white.lv) Received: from purple.the-7.net (purple.the-7.net [IPv6:2001:470:1f01:622:230:48ff:fe23:4c67]) by mx1.freebsd.org (Postfix) with ESMTP id EAD688FC0C for ; Fri, 3 Oct 2008 18:12:32 +0000 (UTC) (envelope-from blue@white.lv) Received: from sushi.local (sushi.astralblue.net [IPv6:2001:470:1f05:155:21e:c2ff:fe1a:9b3c]) by purple.the-7.net (8.14.3/8.14.3) with ESMTP id m93ICQ9H040568 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 3 Oct 2008 11:12:27 -0700 (PDT) (envelope-from blue@white.lv) Authentication-Results: purple.the-7.net; sender-id=none header.from=blue@white.lv; spf=none smtp.mfrom=blue@white.lv Message-ID: <48E6608A.1010606@white.lv> Date: Fri, 03 Oct 2008 11:12:26 -0700 From: "Eugene M. Kim" User-Agent: Thunderbird/3.0a2 (Macintosh; 2008072822) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=10.0 tests=NO_RELAYS autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on purple.the-7.net Cc: Subject: NFSv4 ACL on RELENG_7? 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, 03 Oct 2008 18:12:33 -0000 Hello, A quick question: Is there an NFSv4 ACL patch available for testing on RELENG_7? (I have a quite busy machine on which I wanted to test-drive NFSv4 ACL.) Cheers, Eugene From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 18:55:15 2008 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 6FAA6106568C; Fri, 3 Oct 2008 18:55:15 +0000 (UTC) (envelope-from watson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 299738FC13; Fri, 3 Oct 2008 18:55:15 +0000 (UTC) (envelope-from watson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id B59E346B23; Fri, 3 Oct 2008 14:55:14 -0400 (EDT) Date: Fri, 3 Oct 2008 19:55:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 03 Oct 2008 18:55:15 -0000 On Fri, 3 Oct 2008, Danny Braniss wrote: >> On Fri, 3 Oct 2008, Danny Braniss wrote: >> >>> gladly, but have no idea how to do LOCK_PROFILING, so some pointers would >>> be helpfull. >> >> The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that >> the defaults work fine most of the time, so just use them. Turn the enable >> syscl on just before you begin a run, and turn it off immediately >> afterwards. Make sure to reset between reruns (rebooting to a new kernel >> is fine too!). > > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof > there 3 files: > 7.1-100 host connected at 100 running -prerelease > 7.1-1000 same but connected at 1000 > 7.0-1000 -stable with your 'patch' > at 100 my benchmark didn't suffer from the profiling, average was about 9. > at 1000 the benchmark got realy hit, average was around 12 for the patched, > and 4 for the unpatched (less than at 100). Interesting. A bit of post-processing: robert@fledge:/tmp> cat 7.1-1000 | awk -F' ' '{print $3" "$9}' | sort -n | tail -10 2413283 /r+d/7/sys/kern/kern_mutex.c:141 2470096 /r+d/7/sys/nfsclient/nfs_socket.c:1218 2676282 /r+d/7/sys/net/route.c:293 2754866 /r+d/7/sys/kern/vfs_bio.c:1468 3196298 /r+d/7/sys/nfsclient/nfs_bio.c:1664 3318742 /r+d/7/sys/net/route.c:1584 3711139 /r+d/7/sys/dev/bge/if_bge.c:3287 3753518 /r+d/7/sys/net/if_ethersubr.c:405 3961312 /r+d/7/sys/nfsclient/nfs_subs.c:1066 10688531 /r+d/7/sys/dev/bge/if_bge.c:3726 robert@fledge:/tmp> cat 7.0-1000 | awk -F' ' '{print $3" "$9}' | sort -n | tail -10 468631 /r+d/hunt/src/sys/nfsclient/nfs_nfsiod.c:286 501989 /r+d/hunt/src/sys/nfsclient/nfs_vnops.c:1148 631587 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1198 701155 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1258 718211 /r+d/hunt/src/sys/kern/kern_mutex.c:141 1118711 /r+d/hunt/src/sys/nfsclient/nfs_bio.c:1664 1169125 /r+d/hunt/src/sys/nfsclient/nfs_subs.c:1066 1222867 /r+d/hunt/src/sys/kern/vfs_bio.c:1468 3876072 /r+d/hunt/src/sys/netinet/udp_usrreq.c:545 5198927 /r+d/hunt/src/sys/netinet/udp_usrreq.c:864 The first set above is with the unmodified 7-STABLE tree, the second with a reversion of read locking on the UDP inpcb. The big blinking sign of interest is that the bge interface lock is massively contended in the first set of output, and basically doesn't appear in the second. There are various reasons bge could stand out quite so much -- one possibly is that previously, the udp lock serialized all access to the interface from the send code, preventing the send and receive paths from contending. A few things to try: - Let's look compare the context switch rates on the two benchmarks. Could you run vmstat and look at the cpu cs line during the benchmarks and see how similar the two are as the benchmarks run? You'll want to run it with vmstat -w 1 and collect several samples per benchmark, since we're really interested in the distribution rather than an individual sample. - Is there any chance you could drop an if_em card into the same box and run the identical benchmarks with and without LOCK_PROFILING to see whether it behaves differently than bge when the patch is applied? if_em's interrupt handling is quite different, and may significantly affect lock use, and hence contention. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 22:06:21 2008 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 7BE061065687; Fri, 3 Oct 2008 22:06:21 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 986B08FC0A; Fri, 3 Oct 2008 22:06:20 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 429A330126; Fri, 3 Oct 2008 23:06:07 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from tau.draftnet (tau.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTP; Fri, 3 Oct 2008 23:06:06 +0100 (BST) Date: Fri, 3 Oct 2008 23:05:34 +0100 From: Bruce Cran To: Jeremy Chadwick Message-ID: <20081003230534.60b4c1cb@tau.draftnet> In-Reply-To: <20081003113824.GA27757@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Volker , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 22:06:21 -0000 On Fri, 3 Oct 2008 04:38:24 -0700 Jeremy Chadwick wrote: > I've figured out what the problem is. This is not good, and is > guaranteed to bite other people. I'd like to believe this is an > rc-related problem, but I'm not sure how to fix it. > > The problem in my case: > > The physical interfaces were brought online, but were still > technically offline (the switch and NIC PHY were taking some time to > negotiate speed and duplex). Boot messages: > My box is headless so I didn't see the startup messages until I attached a serial cable. It's a similar problem in my case, but caused because I'm firewalling an ADSL connection which uses PPP, and pf is being enabled before PPP has configured tun0: Setting hostname: router.draftnet. vr0: link state changed to DOWN dc0: link state changed to UP dc3: link state changed to UP lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff000000 vr0: flags=8843 metric 0 mtu 1500 options=2808 ether 00:40:63:e3:d1:b7 inet6 XXXXXXXXXX%vr0 prefixlen 64 tentative scopeid 0x1 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXX media: Ethernet autoselect (none) status: no carrier dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:80:c8:c9:96:6d inet6 XXXXXXXXX%dc0 prefixlen 64 tentative scopeid 0x2 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX media: Ethernet autoselect (100baseTX ) status: active dc3: flags=8843 metric 0 mtu 1500 options=8 ether 00:80:c8:c9:96:70 inet6 XXXXXXXXX%dc3 prefixlen 64 tentative scopeid 0x5 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX media: Ethernet autoselect (100baseTX ) status: active Enabling pf. no IP address found for tun0 /etc/pf.conf:45: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded pf enabled Starting PPP profile: demonLoading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Lodading /lib/libalcias_nbt.so Load1ing /lib/libalia:s_pptp.so Loadi ng /lib/libaliasl_skinny.so Loadiing /lib/libalians_smedia.so k. no IP address found for tun0 s /etc/pf.conf:45t: could not parsae host specificattion pfctl: Synetax error in con fig file: pf rulces not loaded ahdd net default: agateway tun0 Adnditional routingg options: IP gateeway=YES. dadd net ::ffff:0 .0.0.0: gateway t::1 add net ::0o.0.0.0: gateway ::1 net.inet6.iDp6.forwarding: 0O -> 1 net.inet6W.ip6.accept_rtadNv: 0 -> 0 dc2: link state changed to DOWN The messages following "link state changed to DOWN" indicate that all the interfaces are now properly configured with IP addresses, including the external ADSL tun0 and IPv6 gif0 interfaces. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 22:19:50 2008 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 A3FB81065694 for ; Fri, 3 Oct 2008 22:19:50 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFFC8FC12 for ; Fri, 3 Oct 2008 22:19:50 +0000 (UTC) (envelope-from dan@langille.org) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 8CC6F50848 for ; Fri, 3 Oct 2008 23:19:46 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW-gqR91-tUP for ; Fri, 3 Oct 2008 23:19:45 +0100 (BST) Received: from laptop.unixathome.org (bast.unixathome.org [72.78.246.37]) by nyi.unixathome.org (Postfix) with ESMTPSA id EA4375083F for ; Fri, 3 Oct 2008 23:19:44 +0100 (BST) Message-ID: <48E69A3B.7090904@langille.org> Date: Fri, 03 Oct 2008 18:18:35 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Thunderbird 2.0.0.14 (X11/20080623) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Upgrading to 7.x : make check-old 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, 03 Oct 2008 22:19:50 -0000 Folks: I have upgraded a server from 6.3 to 7.0. That went rather smoothly. I have a question about removing old libraries via make delete-old. Given the list of old libraries shown at the end of this URL: http://www.freebsddiary.org/upgrade-6.3-to-7.0.php Is that list more or less expected? From what I can tell, it's pretty safe to now do a make delete-old-libs. Do you concur? No, I won't hold you to it. I'm just looking for backup of my decision. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 22:24:58 2008 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 9954F1065696 for ; Fri, 3 Oct 2008 22:24:58 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8D68FC15 for ; Fri, 3 Oct 2008 22:24:58 +0000 (UTC) (envelope-from dan@langille.org) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A2AF150848 for ; Fri, 3 Oct 2008 23:24:54 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8mcTtvkQ0zd for ; Fri, 3 Oct 2008 23:24:53 +0100 (BST) Received: from laptop.unixathome.org (bast.unixathome.org [72.78.246.37]) by nyi.unixathome.org (Postfix) with ESMTPSA id C25815083F for ; Fri, 3 Oct 2008 23:24:53 +0100 (BST) Message-ID: <48E69B70.3090804@langille.org> Date: Fri, 03 Oct 2008 18:23:44 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Thunderbird 2.0.0.14 (X11/20080623) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: make delete-old vs make-delete-libs 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, 03 Oct 2008 22:24:58 -0000 I'm wondering if these commands from /usr/src/Makefile are correctly described: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files - Delete obsolete files. # delete-old-libs - Delete obsolete libraries. From the above, it appears as if 'make delete-old' is the same as doing: make delete-old-dirs make delete-old-files make delete-old-libs Running the command indicates otherwise. In fact, make delete-old outputs: >>> Removing old files (only deletes safe to delete libs) and: >>> Old directories removed To remove old libraries run 'make delete-old-libs'. That indicates, to me, that only old files were deleted. No old libraries were touched. What's up here? Which is right? thanks. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 23:05:42 2008 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 70FB51065686; Fri, 3 Oct 2008 23:05:42 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id EBF6F8FC08; Fri, 3 Oct 2008 23:05:41 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d3d.q.ppp-pool.de [89.53.125.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 329C412883F; Sat, 4 Oct 2008 00:40:53 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id A1AE72E90F; Sat, 4 Oct 2008 00:39:42 +0200 (CEST) Message-ID: <48E69F6D.5050001@vwsoft.com> Date: Sat, 04 Oct 2008 00:40:45 +0200 From: Volker User-Agent: Thunderbird 2.0.0.17 (X11/20080930) MIME-Version: 1.0 To: Bruce Cran References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> In-Reply-To: <20081003230534.60b4c1cb@tau.draftnet> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1223678386.31281@pkCxgK+QRMmbd06MSsRjPA X-MailScanner-ID: A1AE72E90F.F1033 X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 23:05:42 -0000 On 10/04/08 00:05, Bruce Cran wrote: > On Fri, 3 Oct 2008 04:38:24 -0700 > Jeremy Chadwick wrote: >> I've figured out what the problem is. This is not good, and is >> guaranteed to bite other people. I'd like to believe this is an >> rc-related problem, but I'm not sure how to fix it. >> >> The problem in my case: >> >> The physical interfaces were brought online, but were still >> technically offline (the switch and NIC PHY were taking some time to >> negotiate speed and duplex). Boot messages: >> > > My box is headless so I didn't see the startup messages until I > attached a serial cable. It's a similar problem in my case, but caused > because I'm firewalling an ADSL connection which uses PPP, and pf is > being enabled before PPP has configured tun0: > > Setting hostname: router.draftnet. > vr0: link state changed to DOWN > dc0: link state changed to UP > dc3: link state changed to UP > lo0: flags=8049 metric 0 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet 127.0.0.1 netmask 0xff000000 > vr0: flags=8843 metric 0 mtu > 1500 options=2808 > ether 00:40:63:e3:d1:b7 > inet6 XXXXXXXXXX%vr0 prefixlen 64 tentative > scopeid 0x1 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXX > media: Ethernet autoselect (none) > status: no carrier > dc0: flags=8843 metric 0 mtu > 1500 options=8 > ether 00:80:c8:c9:96:6d > inet6 XXXXXXXXX%dc0 prefixlen 64 tentative > scopeid 0x2 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX > media: Ethernet autoselect (100baseTX ) > status: active > dc3: flags=8843 metric 0 mtu > 1500 options=8 > ether 00:80:c8:c9:96:70 > inet6 XXXXXXXXX%dc3 prefixlen 64 tentative > scopeid 0x5 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX > media: Ethernet autoselect (100baseTX ) > status: active > Enabling pf. > no IP address found for tun0 > /etc/pf.conf:45: could not parse host specification > pfctl: Syntax error in config file: pf rules not loaded > pf enabled > Starting PPP profile: demonLoading /lib/libalias_cuseeme.so > Loading /lib/libalias_ftp.so > Loading /lib/libalias_irc.so > Lodading /lib/libalcias_nbt.so > Load1ing /lib/libalia:s_pptp.so > Loadi ng /lib/libaliasl_skinny.so > Loadiing /lib/libalians_smedia.so > k. > no IP address found for tun0 > s > /etc/pf.conf:45t: could not parsae host specificattion > pfctl: Synetax error in con fig file: pf rulces not loaded > ahdd net default: agateway tun0 > Adnditional routingg options: IP gateeway=YES. > dadd net ::ffff:0 .0.0.0: gateway t::1 > add net ::0o.0.0.0: gateway ::1 > net.inet6.iDp6.forwarding: 0O -> 1 > net.inet6W.ip6.accept_rtadNv: 0 -> 0 > > dc2: link state changed to DOWN > > The messages following "link state changed to DOWN" indicate that all > the interfaces are now properly configured with IP addresses, including > the external ADSL tun0 and IPv6 gif0 interfaces. > Bruce, looking into my crystal ball... ;) You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. Other than that suggestion, I may help you if you'll send me your rules (private mail is ok for me). Volker From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 23:23:01 2008 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 3BE5E106569B; Fri, 3 Oct 2008 23:23:01 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA6278FC1C; Fri, 3 Oct 2008 23:23:00 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 0266930126; Sat, 4 Oct 2008 00:22:56 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from tau.draftnet (tau.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTP; Sat, 4 Oct 2008 00:22:56 +0100 (BST) Date: Sat, 4 Oct 2008 00:22:29 +0100 From: Bruce Cran To: Volker Message-ID: <20081004002229.7089be9c@tau.draftnet> In-Reply-To: <48E69F6D.5050001@vwsoft.com> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> <48E69F6D.5050001@vwsoft.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 23:23:01 -0000 On Sat, 04 Oct 2008 00:40:45 +0200 Volker wrote: > You seem to have a rule like: > > pass ... on tun0 from any to tun0 ... > > If you change that into: > > pass ... on tun0 from any to (tun0) ... > > pf will happily parse your rules and activate your firewall even while > tun0 does not already have an IP address. You may also try to use > rules naming an interface family instead of a single interface. You're right - I mostly used lines with (tun0) but line 45 didn't have the brackets. I've just added them, rebooted and pf loaded the rules during boot. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 23:26:07 2008 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 015571065690; Fri, 3 Oct 2008 23:26:07 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id A8EC58FC16; Fri, 3 Oct 2008 23:26:06 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d3d.q.ppp-pool.de [89.53.125.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 8AF1412883F; Sat, 4 Oct 2008 01:25:57 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 406DC2E90F; Sat, 4 Oct 2008 01:24:46 +0200 (CEST) Message-ID: <48E6A9FD.4060406@vwsoft.com> Date: Sat, 04 Oct 2008 01:25:49 +0200 From: Volker User-Agent: Thunderbird 2.0.0.17 (X11/20080930) MIME-Version: 1.0 To: Bruce Cran References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> <48E69F6D.5050001@vwsoft.com> <20081004002229.7089be9c@tau.draftnet> In-Reply-To: <20081004002229.7089be9c@tau.draftnet> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1223681090.8577@XbLc3dd+NwLql3FmLiP34w X-MailScanner-ID: 406DC2E90F.C1F5B X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf rules not being loaded during boot on 7.1-PRERELEASE 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, 03 Oct 2008 23:26:07 -0000 On 10/04/08 01:22, Bruce Cran wrote: > On Sat, 04 Oct 2008 00:40:45 +0200 > Volker wrote: >> You seem to have a rule like: >> >> pass ... on tun0 from any to tun0 ... >> >> If you change that into: >> >> pass ... on tun0 from any to (tun0) ... >> >> pf will happily parse your rules and activate your firewall even while >> tun0 does not already have an IP address. You may also try to use >> rules naming an interface family instead of a single interface. > > You're right - I mostly used lines with (tun0) but line 45 didn't have > the brackets. I've just added them, rebooted and pf loaded the rules > during boot. > Well, sometimes my crystal ball works ;) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 06:10:47 2008 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 377EB1065686 for ; Sat, 4 Oct 2008 06:10:47 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7C2B28FC17 for ; Sat, 4 Oct 2008 06:10:46 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 04 Oct 2008 06:10:43 -0000 Received: from 85-127-18-201.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.18.201] by mail.gmx.net (mp030) with SMTP; 04 Oct 2008 08:10:43 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1+7d24aXiS7s9EPr6UMi0mqNgkhWn0AxdDwYXyscH KBFAVLVAWYvdyD From: Stefan Ehmann To: Jonathan Chen Date: Sat, 4 Oct 2008 08:10:41 +0200 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) References: <200810031003.14400.shoesoft@gmx.net> <20081003093937.GA4944@osiris.chen.org.nz> In-Reply-To: <20081003093937.GA4944@osiris.chen.org.nz> MIME-Version: 1.0 Message-Id: <200810040810.42363.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51,0.51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: top/ps CPU percentage broken on 7.1-PRERELEASE? (works with SCHED_4BSD) 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, 04 Oct 2008 06:10:47 -0000 On Friday 03 October 2008 11:39:37 Jonathan Chen wrote: > On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote: > > The CPU % displayed by top/ps for single processes seem to be broken > > here. > > > > E.g. for a simple shell loop: > > top starts displaying around 20% for bash. Within some seconds it > > converges to 0%. > > > > ps values seem to be consistent with top. > > > > The value in the time column seems to be correct. On every refresh it > > increases by 2s. > > > > last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 > > 09:07:00 > > 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie > > CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle > > Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free > > Swap: 1280M Total, 1280M Free > > > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > > 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash > > > > All other process are using 0% CPU. > > > > I did a buildworld/kernel yesterday to be sure everything is in sync. I > > have CURRENT on a different hard disk. Haven't seen the problem there. > > Are there any relevant fixes that weren't MFCed? > > > > Does anyone else see this? This is a single CPU i386 machine. > > Yes, my Java processes now run at 800% at times on my dual processor > AMD64 system. I've seen this behaviour too some time ago. Don't know if it's related to what I see. I recompiled my kernel with SCHED_4BSD and things work fine. So it seems to be a SCHED_ULE issue. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 06:40:48 2008 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 02C9B106568A; Sat, 4 Oct 2008 06:40:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3F48FC15; Sat, 4 Oct 2008 06:40:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Km0oo-00085m-D7; Sat, 04 Oct 2008 09:40:46 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Fri, 03 Oct 2008 19:55:14 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2008 09:40:46 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP performance 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, 04 Oct 2008 06:40:48 -0000 > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >> On Fri, 3 Oct 2008, Danny Braniss wrote: > >> > >>> gladly, but have no idea how to do LOCK_PROFILING, so some pointers would > >>> be helpfull. > >> > >> The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that > >> the defaults work fine most of the time, so just use them. Turn the enable > >> syscl on just before you begin a run, and turn it off immediately > >> afterwards. Make sure to reset between reruns (rebooting to a new kernel > >> is fine too!). > > > > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof > > there 3 files: > > 7.1-100 host connected at 100 running -prerelease > > 7.1-1000 same but connected at 1000 > > 7.0-1000 -stable with your 'patch' > > at 100 my benchmark didn't suffer from the profiling, average was about 9. > > at 1000 the benchmark got realy hit, average was around 12 for the patched, > > and 4 for the unpatched (less than at 100). > > Interesting. A bit of post-processing: > > robert@fledge:/tmp> cat 7.1-1000 | awk -F' ' '{print $3" "$9}' | sort -n | > tail -10 > 2413283 /r+d/7/sys/kern/kern_mutex.c:141 > 2470096 /r+d/7/sys/nfsclient/nfs_socket.c:1218 > 2676282 /r+d/7/sys/net/route.c:293 > 2754866 /r+d/7/sys/kern/vfs_bio.c:1468 > 3196298 /r+d/7/sys/nfsclient/nfs_bio.c:1664 > 3318742 /r+d/7/sys/net/route.c:1584 > 3711139 /r+d/7/sys/dev/bge/if_bge.c:3287 > 3753518 /r+d/7/sys/net/if_ethersubr.c:405 > 3961312 /r+d/7/sys/nfsclient/nfs_subs.c:1066 > 10688531 /r+d/7/sys/dev/bge/if_bge.c:3726 > robert@fledge:/tmp> cat 7.0-1000 | awk -F' ' '{print $3" "$9}' | sort -n | > tail -10 > 468631 /r+d/hunt/src/sys/nfsclient/nfs_nfsiod.c:286 > 501989 /r+d/hunt/src/sys/nfsclient/nfs_vnops.c:1148 > 631587 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1198 > 701155 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1258 > 718211 /r+d/hunt/src/sys/kern/kern_mutex.c:141 > 1118711 /r+d/hunt/src/sys/nfsclient/nfs_bio.c:1664 > 1169125 /r+d/hunt/src/sys/nfsclient/nfs_subs.c:1066 > 1222867 /r+d/hunt/src/sys/kern/vfs_bio.c:1468 > 3876072 /r+d/hunt/src/sys/netinet/udp_usrreq.c:545 > 5198927 /r+d/hunt/src/sys/netinet/udp_usrreq.c:864 > > The first set above is with the unmodified 7-STABLE tree, the second with a > reversion of read locking on the UDP inpcb. The big blinking sign of interest > is that the bge interface lock is massively contended in the first set of > output, and basically doesn't appear in the second. There are various reasons > bge could stand out quite so much -- one possibly is that previously, the udp > lock serialized all access to the interface from the send code, preventing the > send and receive paths from contending. > > A few things to try: > > - Let's look compare the context switch rates on the two benchmarks. Could > you run vmstat and look at the cpu cs line during the benchmarks and see how > similar the two are as the benchmarks run? You'll want to run it with > vmstat -w 1 and collect several samples per benchmark, since we're really > interested in the distribution rather than an individual sample. > > - Is there any chance you could drop an if_em card into the same box and run > the identical benchmarks with and without LOCK_PROFILING to see whether it > behaves differently than bge when the patch is applied? if_em's interrupt > handling is quite different, and may significantly affect lock use, and > hence contention. at the moment, the best I can do is run it on a different hardware that has if_em, the results are in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof/7.1-1000.em the benchmark ran better with the Intel NIC, averaged UDP 54MB/s, TCP 53MB/s (I get the same numbers with an older kernel). danny From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 11:44:21 2008 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 C8FEF1065687 for ; Sat, 4 Oct 2008 11:44:21 +0000 (UTC) (envelope-from bsd24x7@yahoo.com) Received: from n3.bullet.mail.gq1.yahoo.com (n3.bullet.mail.gq1.yahoo.com [67.195.9.86]) by mx1.freebsd.org (Postfix) with SMTP id 99A088FC0A for ; Sat, 4 Oct 2008 11:44:21 +0000 (UTC) (envelope-from bsd24x7@yahoo.com) Received: from [67.195.9.81] by n3.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2008 11:30:19 -0000 Received: from [67.195.9.103] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2008 11:30:19 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 04 Oct 2008 11:30:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55712.20597.bm@omp107.mail.gq1.yahoo.com Received: (qmail 22581 invoked by uid 60001); 4 Oct 2008 11:30:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=R1QQgWOrnnaCb/KDVxqMo+sBYkb/yNbFDpbJN0ly4Wouut5RT+ESohP5BgvMrfR0o/T8x2LZxabBHVAwrvgQzN0+GZg2blbwxIw8Vwsnne+HKvmDwRXRWKntCKyYlXUP9bICBZWoymGbNEJj3qtN+KabM1qFFdotr+pidHcRZdE=; X-YMail-OSG: sXEFv34VM1kGmtqP2wr_5pcnE8k4n7evkNCC8242HVzObif5TTNcBkTD6Yr4hHSNRcsNIGrZ5mIOWHzhMjtqYiNV.ff74FSbbK5hpXTjIElojZ3E9QSR3eznaiALdGEf6AE1 Received: from [67.140.225.63] by web110112.mail.gq1.yahoo.com via HTTP; Sat, 04 Oct 2008 04:30:18 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Sat, 4 Oct 2008 04:30:18 -0700 (PDT) From: Jeff Richards To: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: <884679.22561.qm@web110112.mail.gq1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 'at now' not working as expected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsd24x7@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 11:44:21 -0000 When I try to schedule something immediately with an 'at now' command it ap= pears to queue up but can wait multiple minutes before actually executing. Is there something I have missed with FreeBSD's version of at?=A0 I've used= 'at now' with AIX, Linux, and OpenBSD and it immediately executes for thos= e systems. I am running FreeBSD 7.0 stable. Thanks in advance. =0A=0A=0A From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 12:04:13 2008 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 494991065698 for ; Sat, 4 Oct 2008 12:04:13 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id E8F9F8FC18 for ; Sat, 4 Oct 2008 12:04:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id B5726130C74; Sat, 4 Oct 2008 14:04:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MINi3ogH7n+o; Sat, 4 Oct 2008 14:04:08 +0200 (CEST) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP; Sat, 4 Oct 2008 14:04:08 +0200 (CEST) Message-ID: <48E75BB7.2060206@madpilot.net> Date: Sat, 04 Oct 2008 14:04:07 +0200 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: bsd24x7@yahoo.com References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> In-Reply-To: <884679.22561.qm@web110112.mail.gq1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 'at now' not working as expected 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, 04 Oct 2008 12:04:13 -0000 Jeff Richards wrote: > When I try to schedule something immediately with an 'at now' command it appears to queue up but can wait multiple minutes before actually executing. > > Is there something I have missed with FreeBSD's version of at? I've used 'at now' with AIX, Linux, and OpenBSD and it immediately executes for those systems. > > I am running FreeBSD 7.0 stable. atrun is launched from crontab with a 5 minute granularity. So I think that at now can launch command with at most a 5 minutes delay. If this is a problem you can make atrun be launched every minute reconfiguring the crontab and you will wait at mosta one minute. This is explained in the at(1) man page. I don't know about other systems at setup. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 15:38:26 2008 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 48AB11065687; Sat, 4 Oct 2008 15:38:26 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail38.yandex.ru (webmail38.yandex.ru [77.88.60.17]) by mx1.freebsd.org (Postfix) with ESMTP id 224138FC0C; Sat, 4 Oct 2008 15:38:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail38) by mail.yandex.ru id S7045171AbYJDPiJ for (+ 2 others); Sat, 4 Oct 2008 19:38:09 +0400 X-Yandex-Spam: 1 Received: from [77.72.136.71] ([77.72.136.71]) by mail.yandex.ru with HTTP; Sat, 04 Oct 2008 19:38:09 +0400 From: "Andrey V. Elsukov" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-Id: <676151223134689@webmail38.yandex.ru> Date: Sat, 04 Oct 2008 19:38:09 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Type: multipart/mixed; boundary="----==--bound.67616.webmail38.yandex.ru" X-Mailman-Approved-At: Sat, 04 Oct 2008 15:47:26 +0000 Cc: kib@freebsd.org, sos@freebsd.org Subject: Request for testing: ata(4) MFC 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, 04 Oct 2008 15:38:26 -0000 ------==--bound.67616.webmail38.yandex.ru Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi, All. I prepared patch to make MFC of ata(4) driver into RELENG_7 before 7.1-RELEASE. Depending on results of the testing patch will be commited or not (if some regressions will be detected). So if you want or just can test it, please try and report here. -- WBR, Andrey V. Elsukov ------==--bound.67616.webmail38.yandex.ru Content-Disposition: attachment; filename="ata.diff" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream; name="ata.diff" LS0tIHNyYy9zeXMvZGV2L2F0YS9hdGEtYWxsLmMJMjAwOC0wOS0yOSAyMzo1NDozOC4wMDAwMDAw MDAgKzA0MDAKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtYWxsLmMJMjAwOC0wOC0xNSAxNDo1NTox MS4wMDAwMDAwMDAgKzA0MDAKQEAgLTEsNSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykg MTk5OCAtIDIwMDcgU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0 IChjKSAxOTk4IC0gMjAwOCBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwg cmlnaHRzIHJlc2VydmVkLgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNl IGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dApAQCAtNjIsNyArNjIsNiBAQCBzdGF0 aWMgc3RydWN0IGNkZXZzdyBhdGFfY2RldnN3ID0gewogLyogcHJvdG90eXBlcyAqLwogc3RhdGlj IHZvaWQgYXRhX2Jvb3RfYXR0YWNoKHZvaWQpOwogc3RhdGljIGRldmljZV90IGF0YV9hZGRfY2hp bGQoZGV2aWNlX3QsIHN0cnVjdCBhdGFfZGV2aWNlICosIGludCk7Ci1zdGF0aWMgaW50IGF0YV9n ZXRwYXJhbShzdHJ1Y3QgYXRhX2RldmljZSAqLCBpbnQpOwogc3RhdGljIHZvaWQgYnN3YXAoaW50 OF90ICosIGludCk7CiBzdGF0aWMgdm9pZCBidHJpbShpbnQ4X3QgKiwgaW50KTsKIHN0YXRpYyB2 b2lkIGJwYWNrKGludDhfdCAqLCBpbnQ4X3QgKiwgaW50KTsKQEAgLTc1LDYgKzc0LDcgQEAgZGV2 Y2xhc3NfdCBhdGFfZGV2Y2xhc3M7CiB1bWFfem9uZV90IGF0YV9yZXF1ZXN0X3pvbmU7CiB1bWFf em9uZV90IGF0YV9jb21wb3NpdGVfem9uZTsKIGludCBhdGFfd2MgPSAxOworaW50IGF0YV9zZXRt YXggPSAwOwogaW50IGF0YV9kbWFfY2hlY2tfODBwaW4gPSAxOwogCiAvKiBsb2NhbCB2YXJzICov CkBAIC05Niw2ICs5Niw5IEBAIFNZU0NUTF9JTlQoX2h3X2F0YSwgT0lEX0FVVE8sIGF0YXBpX2Rt YSwKIFRVTkFCTEVfSU5UKCJody5hdGEud2MiLCAmYXRhX3djKTsKIFNZU0NUTF9JTlQoX2h3X2F0 YSwgT0lEX0FVVE8sIHdjLCBDVExGTEFHX1JEVFVOLCAmYXRhX3djLCAwLAogCSAgICJBVEEgZGlz ayB3cml0ZSBjYWNoaW5nIik7CitUVU5BQkxFX0lOVCgiaHcuYXRhLnNldG1heCIsICZhdGFfc2V0 bWF4KTsKK1NZU0NUTF9JTlQoX2h3X2F0YSwgT0lEX0FVVE8sIHNldG1heCwgQ1RMRkxBR19SRFRV TiwgJmF0YV9zZXRtYXgsIDAsCisJICAgIkFUQSBkaXNrIHNldCBtYXggbmF0aXZlIGFkZHJlc3Mi KTsKIAogLyoKICAqIG5ld2J1cyBkZXZpY2UgaW50ZXJmYWNlIHJlbGF0ZWQgZnVuY3Rpb25zCkBA IC0xMzEsNiArMTM0LDEwIEBAIGF0YV9hdHRhY2goZGV2aWNlX3QgZGV2KQogICAgIEFUQV9SRVNF VChkZXYpOwogICAgIEFUQV9MT0NLSU5HKGRldiwgQVRBX0xGX1VOTE9DSyk7CiAKKyAgICAvKiBh bGxvY2F0ZSBETUEgcmVzb3VyY2VzIGlmIERNQSBIVyBwcmVzZW50Ki8KKyAgICBpZiAoY2gtPmRt YS5hbGxvYykKKwljaC0+ZG1hLmFsbG9jKGRldik7CisKICAgICAvKiBzZXR1cCBpbnRlcnJ1cHQg ZGVsaXZlcnkgKi8KICAgICByaWQgPSBBVEFfSVJRX1JJRDsKICAgICBjaC0+cl9pcnEgPSBidXNf YWxsb2NfcmVzb3VyY2VfYW55KGRldiwgU1lTX1JFU19JUlEsICZyaWQsCkBAIC00MDksMTMgKzQx NiwxMyBAQCBhdGFfaW9jdGwoc3RydWN0IGNkZXYgKmRldiwgdV9sb25nIGNtZCwgCiAJCWlmIChj aGlsZHJlbltpXSAmJiBkZXZpY2VfaXNfYXR0YWNoZWQoY2hpbGRyZW5baV0pKSB7CiAJCSAgICBz dHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhjaGlsZHJlbltpXSk7 CiAKLQkJICAgIGlmIChhdGFkZXYtPnVuaXQgPT0gQVRBX01BU1RFUikgeworCQkgICAgaWYgKGF0 YWRldi0+dW5pdCA9PSBBVEFfTUFTVEVSKSB7IC8qIFhYWCBTT1MgUE0gKi8KIAkJCXN0cm5jcHko ZGV2aWNlcy0+bmFtZVswXSwKIAkJCQlkZXZpY2VfZ2V0X25hbWV1bml0KGNoaWxkcmVuW2ldKSwg MzIpOwogCQkJYmNvcHkoJmF0YWRldi0+cGFyYW0sICZkZXZpY2VzLT5wYXJhbXNbMF0sCiAJCQkg ICAgICBzaXplb2Yoc3RydWN0IGF0YV9wYXJhbXMpKTsKIAkJICAgIH0KLQkJICAgIGlmIChhdGFk ZXYtPnVuaXQgPT0gQVRBX1NMQVZFKSB7CisJCSAgICBpZiAoYXRhZGV2LT51bml0ID09IEFUQV9T TEFWRSkgeyAvKiBYWFggU09TIFBNICovCiAJCQlzdHJuY3B5KGRldmljZXMtPm5hbWVbMV0sCiAJ CQkJZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZHJlbltpXSksIDMyKTsKIAkJCWJjb3B5KCZhdGFk ZXYtPnBhcmFtLCAmZGV2aWNlcy0+cGFyYW1zWzFdLApAQCAtNDU3LDYgKzQ2NCw3IEBAIGF0YV9k ZXZpY2VfaW9jdGwoZGV2aWNlX3QgZGV2LCB1X2xvbmcgY20KIAkgICAgZnJlZShidWYsIE1fQVRB KTsKIAkgICAgcmV0dXJuICBFTk9NRU07CiAJfQorCXJlcXVlc3QtPmRldiA9IGF0YWRldi0+ZGV2 OwogCWlmIChpb2NfcmVxdWVzdC0+ZmxhZ3MgJiBBVEFfQ01EX1dSSVRFKSB7CiAJICAgIGVycm9y ID0gY29weWluKGlvY19yZXF1ZXN0LT5kYXRhLCBidWYsIGlvY19yZXF1ZXN0LT5jb3VudCk7CiAJ ICAgIGlmIChlcnJvcikgewpAQCAtNDY1LDcgKzQ3Myw2IEBAIGF0YV9kZXZpY2VfaW9jdGwoZGV2 aWNlX3QgZGV2LCB1X2xvbmcgY20KIAkJcmV0dXJuIGVycm9yOwogCSAgICB9CiAJfQotCXJlcXVl c3QtPmRldiA9IGRldjsKIAlpZiAoaW9jX3JlcXVlc3QtPmZsYWdzICYgQVRBX0NNRF9BVEFQSSkg ewogCSAgICByZXF1ZXN0LT5mbGFncyA9IEFUQV9SX0FUQVBJOwogCSAgICBiY29weShpb2NfcmVx dWVzdC0+dS5hdGFwaS5jY2IsIHJlcXVlc3QtPnUuYXRhcGkuY2NiLCAxNik7CkBAIC01NzQsNyAr NTgxLDcgQEAgYXRhX2FkZF9jaGlsZChkZXZpY2VfdCBwYXJlbnQsIHN0cnVjdCBhdAogICAgIHJl dHVybiBjaGlsZDsKIH0KIAotc3RhdGljIGludAoraW50CiBhdGFfZ2V0cGFyYW0oc3RydWN0IGF0 YV9kZXZpY2UgKmF0YWRldiwgaW50IGluaXQpCiB7CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoYXRhZGV2LT5kZXYpKTsKQEAg LTU4MiwxMSArNTg5LDkgQEAgYXRhX2dldHBhcmFtKHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYs IAogICAgIHVfaW50OF90IGNvbW1hbmQgPSAwOwogICAgIGludCBlcnJvciA9IEVOT01FTSwgcmV0 cmllcyA9IDI7CiAKLSAgICBpZiAoY2gtPmRldmljZXMgJgotCShhdGFkZXYtPnVuaXQgPT0gQVRB X01BU1RFUiA/IEFUQV9BVEFfTUFTVEVSIDogQVRBX0FUQV9TTEFWRSkpCisgICAgaWYgKGNoLT5k ZXZpY2VzICYgKEFUQV9BVEFfTUFTVEVSIDw8IGF0YWRldi0+dW5pdCkpCiAJY29tbWFuZCA9IEFU QV9BVEFfSURFTlRJRlk7Ci0gICAgaWYgKGNoLT5kZXZpY2VzICYKLQkoYXRhZGV2LT51bml0ID09 IEFUQV9NQVNURVIgPyBBVEFfQVRBUElfTUFTVEVSIDogQVRBX0FUQVBJX1NMQVZFKSkKKyAgICBp ZiAoY2gtPmRldmljZXMgJiAoQVRBX0FUQVBJX01BU1RFUiA8PCBhdGFkZXYtPnVuaXQpKQogCWNv bW1hbmQgPSBBVEFfQVRBUElfSURFTlRJRlk7CiAgICAgaWYgKCFjb21tYW5kKQogCXJldHVybiBF TlhJTzsKQEAgLTYzNiw3ICs2NDEsNyBAQCBhdGFfZ2V0cGFyYW0oc3RydWN0IGF0YV9kZXZpY2Ug KmF0YWRldiwgCiAJaWYgKGJvb3R2ZXJib3NlKQogCSAgICBwcmludGYoImF0YSVkLSVzOiBwaW89 JXMgd2RtYT0lcyB1ZG1hPSVzIGNhYmxlPSVzIHdpcmVcbiIsCiAJCSAgIGRldmljZV9nZXRfdW5p dChjaC0+ZGV2KSwKLQkJICAgYXRhZGV2LT51bml0ID09IEFUQV9NQVNURVIgPyAibWFzdGVyIiA6 ICJzbGF2ZSIsCisJCSAgIGF0YV91bml0MnN0cihhdGFkZXYpLAogCQkgICBhdGFfbW9kZTJzdHIo YXRhX3Btb2RlKGF0YWNhcCkpLAogCQkgICBhdGFfbW9kZTJzdHIoYXRhX3dtb2RlKGF0YWNhcCkp LAogCQkgICBhdGFfbW9kZTJzdHIoYXRhX3Vtb2RlKGF0YWNhcCkpLApAQCAtNjQ4LDEzICs2NTMs MTMgQEAgYXRhX2dldHBhcmFtKHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYsIAogCSAgICBpZiAo KGF0YWRldi0+cGFyYW0uY29uZmlnICYgQVRBX1BST1RPX0FUQVBJKSAmJgogCQkoYXRhZGV2LT5w YXJhbS5jb25maWcgIT0gQVRBX0NGQV9NQUdJQzEpICYmCiAJCShhdGFkZXYtPnBhcmFtLmNvbmZp ZyAhPSBBVEFfQ0ZBX01BR0lDMikpIHsKLQkJaWYgKGF0YXBpX2RtYSAmJiBjaC0+ZG1hICYmCisJ CWlmIChhdGFwaV9kbWEgJiYKIAkJICAgIChhdGFkZXYtPnBhcmFtLmNvbmZpZyAmIEFUQV9EUlFf TUFTSykgIT0gQVRBX0RSUV9JTlRSICYmCiAJCSAgICBhdGFfdW1vZGUoJmF0YWRldi0+cGFyYW0p ID49IEFUQV9VRE1BMikKIAkJICAgIGF0YWRldi0+bW9kZSA9IEFUQV9ETUFfTUFYOwogCSAgICB9 CiAJICAgIGVsc2UgewotCQlpZiAoYXRhX2RtYSAmJiBjaC0+ZG1hICYmCisJCWlmIChhdGFfZG1h ICYmCiAJCSAgICAoYXRhX3Vtb2RlKCZhdGFkZXYtPnBhcmFtKSA+IDAgfHwKIAkJICAgICBhdGFf d21vZGUoJmF0YWRldi0+cGFyYW0pID4gMCkpCiAJCSAgICBhdGFkZXYtPm1vZGUgPSBBVEFfRE1B X01BWDsKQEAgLTY3Miw1MiArNjc3LDQyIEBAIGludAogYXRhX2lkZW50aWZ5KGRldmljZV90IGRl dikKIHsKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OwotICAgIHN0cnVjdCBhdGFfZGV2aWNlICptYXN0ZXIgPSBOVUxMLCAqc2xhdmUgPSBOVUxMOwot ICAgIGRldmljZV90IG1hc3Rlcl9jaGlsZCA9IE5VTEwsIHNsYXZlX2NoaWxkID0gTlVMTDsKLSAg ICBpbnQgbWFzdGVyX3VuaXQgPSAtMSwgc2xhdmVfdW5pdCA9IC0xOwotCi0gICAgaWYgKGNoLT5k ZXZpY2VzICYgKEFUQV9BVEFfTUFTVEVSIHwgQVRBX0FUQVBJX01BU1RFUikpIHsKLQlpZiAoISht YXN0ZXIgPSBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBhdGFfZGV2aWNlKSwKLQkJCSAgICAgIE1fQVRB LCBNX05PV0FJVCB8IE1fWkVSTykpKSB7Ci0JICAgIGRldmljZV9wcmludGYoZGV2LCAib3V0IG9m IG1lbW9yeVxuIik7Ci0JICAgIHJldHVybiBFTk9NRU07Ci0JfQotCW1hc3Rlci0+dW5pdCA9IEFU QV9NQVNURVI7Ci0gICAgfQotICAgIGlmIChjaC0+ZGV2aWNlcyAmIChBVEFfQVRBX1NMQVZFIHwg QVRBX0FUQVBJX1NMQVZFKSkgewotCWlmICghKHNsYXZlID0gbWFsbG9jKHNpemVvZihzdHJ1Y3Qg YXRhX2RldmljZSksCi0JCQkgICAgIE1fQVRBLCBNX05PV0FJVCB8IE1fWkVSTykpKSB7Ci0JICAg IGZyZWUobWFzdGVyLCBNX0FUQSk7Ci0JICAgIGRldmljZV9wcmludGYoZGV2LCAib3V0IG9mIG1l bW9yeVxuIik7Ci0JICAgIHJldHVybiBFTk9NRU07Ci0JfQotCXNsYXZlLT51bml0ID0gQVRBX1NM QVZFOwotICAgIH0KKyAgICBzdHJ1Y3QgYXRhX2RldmljZSAqZGV2aWNlc1tBVEFfUE1dOworICAg IGRldmljZV90IGNoaWxkZGV2c1tBVEFfUE1dOworICAgIGludCBpOwogCisgICAgaWYgKGJvb3R2 ZXJib3NlKQorCWRldmljZV9wcmludGYoZGV2LCAiaWRlbnRpZnkgY2gtPmRldmljZXM9JTA4eFxu IiwgY2gtPmRldmljZXMpOworCisgICAgZm9yIChpID0gMDsgaSA8IEFUQV9QTTsgKytpKSB7CisJ aWYgKGNoLT5kZXZpY2VzICYgKCgoQVRBX0FUQV9NQVNURVIgfCBBVEFfQVRBUElfTUFTVEVSKSA8 PCBpKSkpIHsKKwkgICAgaW50IHVuaXQgPSAtMTsKKworCSAgICBpZiAoIShkZXZpY2VzW2ldID0g bWFsbG9jKHNpemVvZihzdHJ1Y3QgYXRhX2RldmljZSksCisJCQkJICAgICAgTV9BVEEsIE1fTk9X QUlUIHwgTV9aRVJPKSkpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJvdXQgb2YgbWVtb3J5XG4i KTsKKwkJcmV0dXJuIEVOT01FTTsKKwkgICAgfQorCSAgICBkZXZpY2VzW2ldLT51bml0ID0gaTsK ICNpZmRlZiBBVEFfU1RBVElDX0lECi0gICAgaWYgKGNoLT5kZXZpY2VzICYgQVRBX0FUQV9NQVNU RVIpCi0JbWFzdGVyX3VuaXQgPSAoZGV2aWNlX2dldF91bml0KGRldikgPDwgMSk7Ci0jZW5kaWYK LSAgICBpZiAobWFzdGVyICYmICEobWFzdGVyX2NoaWxkID0gYXRhX2FkZF9jaGlsZChkZXYsIG1h c3RlciwgbWFzdGVyX3VuaXQpKSkgewotCWZyZWUobWFzdGVyLCBNX0FUQSk7Ci0JbWFzdGVyID0g TlVMTDsKLSAgICB9Ci0jaWZkZWYgQVRBX1NUQVRJQ19JRAotICAgIGlmIChjaC0+ZGV2aWNlcyAm IEFUQV9BVEFfU0xBVkUpCi0Jc2xhdmVfdW5pdCA9IChkZXZpY2VfZ2V0X3VuaXQoZGV2KSA8PCAx KSArIDE7CisJICAgIGlmIChjaC0+ZGV2aWNlcyAmICgoQVRBX0FUQV9NQVNURVIgPDwgaSkpKQor CQl1bml0ID0gKGRldmljZV9nZXRfdW5pdChkZXYpIDw8IDEpICsgaTsKICNlbmRpZgotICAgIGlm IChzbGF2ZSAmJiAhKHNsYXZlX2NoaWxkID0gYXRhX2FkZF9jaGlsZChkZXYsIHNsYXZlLCBzbGF2 ZV91bml0KSkpIHsKLQlmcmVlKHNsYXZlLCBNX0FUQSk7Ci0Jc2xhdmUgPSBOVUxMOwotICAgIH0K LQotICAgIGlmIChzbGF2ZSAmJiBhdGFfZ2V0cGFyYW0oc2xhdmUsIDEpKSB7Ci0JZGV2aWNlX2Rl bGV0ZV9jaGlsZChkZXYsIHNsYXZlX2NoaWxkKTsKLQlmcmVlKHNsYXZlLCBNX0FUQSk7Ci0gICAg fQotICAgIGlmIChtYXN0ZXIgJiYgYXRhX2dldHBhcmFtKG1hc3RlciwgMSkpIHsKLQlkZXZpY2Vf ZGVsZXRlX2NoaWxkKGRldiwgbWFzdGVyX2NoaWxkKTsKLQlmcmVlKG1hc3RlciwgTV9BVEEpOwor CSAgICBpZiAoIShjaGlsZGRldnNbaV0gPSBhdGFfYWRkX2NoaWxkKGRldiwgZGV2aWNlc1tpXSwg dW5pdCkpKSB7CisJCWZyZWUoZGV2aWNlc1tpXSwgTV9BVEEpOworCQlkZXZpY2VzW2ldPU5VTEw7 CisJICAgIH0KKwkgICAgZWxzZSB7CisJCWlmIChhdGFfZ2V0cGFyYW0oZGV2aWNlc1tpXSwgMSkp IHsKKwkJICAgIGRldmljZV9kZWxldGVfY2hpbGQoZGV2LCBjaGlsZGRldnNbaV0pOworCQkgICAg ZnJlZShkZXZpY2VzW2ldLCBNX0FUQSk7CisJCSAgICBjaGlsZGRldnNbaV0gPSBOVUxMOworCQkg ICAgZGV2aWNlc1tpXSA9IE5VTEw7CisJCX0KKwkgICAgfQorCX0KKwlkZXZpY2VzW2ldID0gTlVM TDsKKwljaGlsZGRldnNbaV0gPSBOVUxMOwogICAgIH0KIAogICAgIGJ1c19nZW5lcmljX3Byb2Jl KGRldik7CkBAIC04MTUsOCArODEwLDIzIEBAIGF0YV9tb2RpZnlfaWZfNDhiaXQoc3RydWN0IGF0 YV9yZXF1ZXN0ICoKIAljYXNlIEFUQV9GTFVTSENBQ0hFOgogCSAgICByZXF1ZXN0LT51LmF0YS5j b21tYW5kID0gQVRBX0ZMVVNIQ0FDSEU0ODsKIAkgICAgYnJlYWs7Ci0JY2FzZSBBVEFfUkVBRF9O QVRJVkVfTUFYX0FERERSRVNTOgotCSAgICByZXF1ZXN0LT51LmF0YS5jb21tYW5kID0gQVRBX1JF QURfTkFUSVZFX01BWF9BREREUkVTUzQ4OworCWNhc2UgQVRBX1NFVF9NQVhfQUREUkVTUzoKKwkg ICAgcmVxdWVzdC0+dS5hdGEuY29tbWFuZCA9IEFUQV9TRVRfTUFYX0FERFJFU1M0ODsKKwkgICAg YnJlYWs7CisJZGVmYXVsdDoKKwkgICAgcmV0dXJuOworCX0KKwlhdGFkZXYtPmZsYWdzIHw9IEFU QV9EXzQ4QklUX0FDVElWRTsKKyAgICB9CisgICAgZWxzZSBpZiAoYXRhZGV2LT5wYXJhbS5zdXBw b3J0LmNvbW1hbmQyICYgQVRBX1NVUFBPUlRfQUREUkVTUzQ4KSB7CisKKwkvKiB0cmFuc2xhdGUg Y29tbWFuZCBpbnRvIDQ4Yml0IHZlcnNpb24gKi8KKwlzd2l0Y2ggKHJlcXVlc3QtPnUuYXRhLmNv bW1hbmQpIHsKKwljYXNlIEFUQV9GTFVTSENBQ0hFOgorCSAgICByZXF1ZXN0LT51LmF0YS5jb21t YW5kID0gQVRBX0ZMVVNIQ0FDSEU0ODsKKwkgICAgYnJlYWs7CisJY2FzZSBBVEFfUkVBRF9OQVRJ VkVfTUFYX0FERFJFU1M6CisJICAgIHJlcXVlc3QtPnUuYXRhLmNvbW1hbmQgPSBBVEFfUkVBRF9O QVRJVkVfTUFYX0FERFJFU1M0ODsKIAkgICAgYnJlYWs7CiAJY2FzZSBBVEFfU0VUX01BWF9BRERS RVNTOgogCSAgICByZXF1ZXN0LT51LmF0YS5jb21tYW5kID0gQVRBX1NFVF9NQVhfQUREUkVTUzQ4 OwpAQCAtODM5LDYgKzg0OSwxOSBAQCBhdGFfdWRlbGF5KGludCBpbnRlcnZhbCkKIH0KIAogY2hh ciAqCithdGFfdW5pdDJzdHIoc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldikKK3sKKyAgICBzdHJ1 Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChh dGFkZXYtPmRldikpOworICAgIHN0YXRpYyBjaGFyIHN0cls4XTsKKworICAgIGlmIChjaC0+ZGV2 aWNlcyAmIEFUQV9QT1JUTVVMVElQTElFUikKKwlzcHJpbnRmKHN0ciwgInBvcnQlZCIsIGF0YWRl di0+dW5pdCk7CisgICAgZWxzZQorCXNwcmludGYoc3RyLCAiJXMiLCBhdGFkZXYtPnVuaXQgPT0g QVRBX01BU1RFUiA/ICJtYXN0ZXIiIDogInNsYXZlIik7CisgICAgcmV0dXJuIHN0cjsKK30KKwor Y2hhciAqCiBhdGFfbW9kZTJzdHIoaW50IG1vZGUpCiB7CiAgICAgc3dpdGNoIChtb2RlKSB7Ci0t LSBzcmMvc3lzL2Rldi9hdGEvYXRhLWFsbC5oCTIwMDgtMDgtMjIgMTI6MDk6MTMuMDAwMDAwMDAw ICswNDAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhLWFsbC5oCTIwMDgtMDgtMTUgMTQ6NTU6MTEu MDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDE5 OTggLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAo YykgMTk5OCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKQEAgLTE0OSw2ICsxNDksNyBAQAogLyog U0FUQSBBSENJIHYxLjAgcmVnaXN0ZXIgZGVmaW5lcyAqLwogI2RlZmluZSBBVEFfQUhDSV9DQVAg ICAgICAgICAgICAgICAgICAgIDB4MDAKICNkZWZpbmUgICAgICAgICBBVEFfQUhDSV9OUE1BU0sg ICAgICAgICAweDFmCisjZGVmaW5lCQlBVEFfQUhDSV9DQVBfU1BNCTB4MDAwMjAwMDAKICNkZWZp bmUJCUFUQV9BSENJX0NBUF9DTE8JMHgwMTAwMDAwMAogI2RlZmluZQkJQVRBX0FIQ0lfQ0FQXzY0 QklUCTB4ODAwMDAwMDAKIApAQCAtMjIwLDEzICsyMjEsMTQgQEAKICNkZWZpbmUgQVRBX0FIQ0lf UF9TRVJSICAgICAgICAgICAgICAgICAweDEzMAogI2RlZmluZSBBVEFfQUhDSV9QX1NBQ1QgICAg ICAgICAgICAgICAgIDB4MTM0CiAjZGVmaW5lIEFUQV9BSENJX1BfQ0kgICAgICAgICAgICAgICAg ICAgMHgxMzgKKyNkZWZpbmUgQVRBX0FIQ0lfUF9TTlRGICAgICAgICAgICAgICAgICAweDEzQwor I2RlZmluZSBBVEFfQUhDSV9QX0ZCUyAgICAgICAgICAgICAgICAgIDB4MTQwCiAKICNkZWZpbmUg QVRBX0FIQ0lfQ0xfU0laRSAgICAgICAgICAgICAgICAzMgogI2RlZmluZSBBVEFfQUhDSV9DTF9P RkZTRVQgICAgICAgICAgICAgIDAKLSNkZWZpbmUgQVRBX0FIQ0lfRkJfT0ZGU0VUICAgICAgICAg ICAgICAxMDI0Ci0jZGVmaW5lIEFUQV9BSENJX0NUX09GRlNFVCAgICAgICAgICAgICAgMTAyNCsy NTYKLSNkZWZpbmUgQVRBX0FIQ0lfQ1RfU0dfT0ZGU0VUICAgICAgICAgICAxMjgKLSNkZWZpbmUg QVRBX0FIQ0lfQ1RfU0laRSAgICAgICAgICAgICAgICAyNTYKKyNkZWZpbmUgQVRBX0FIQ0lfRkJf T0ZGU0VUICAgICAgICAgICAgICAoQVRBX0FIQ0lfQ0xfU0laRSAqIDMyKQorI2RlZmluZSBBVEFf QUhDSV9DVF9PRkZTRVQgICAgICAgICAgICAgIChBVEFfQUhDSV9GQl9PRkZTRVQgKyA0MDk2KQor I2RlZmluZSBBVEFfQUhDSV9DVF9TSVpFICAgICAgICAgICAgICAgICgxMDI0ICsgMTI4KQogCiBz dHJ1Y3QgYXRhX2FoY2lfZG1hX3ByZCB7CiAgICAgdV9pbnQ2NF90ICAgICAgICAgICAgICAgICAg IGRiYTsKQEAgLTI0MCwxMSArMjQyLDE5IEBAIHN0cnVjdCBhdGFfYWhjaV9jbWRfdGFiIHsKICAg ICB1X2ludDhfdCAgICAgICAgICAgICAgICAgICAgY2Zpc1s2NF07CiAgICAgdV9pbnQ4X3QgICAg ICAgICAgICAgICAgICAgIGFjbWRbMzJdOwogICAgIHVfaW50OF90ICAgICAgICAgICAgICAgICAg ICByZXNlcnZlZFszMl07Ci0gICAgc3RydWN0IGF0YV9haGNpX2RtYV9wcmQgICAgIHByZF90YWJb MTZdOworI2RlZmluZSBBVEFfQUhDSV9ETUFfRU5UUklFUyAgICAgICAgICAgIDY0CisgICAgc3Ry dWN0IGF0YV9haGNpX2RtYV9wcmQgICAgIHByZF90YWJbQVRBX0FIQ0lfRE1BX0VOVFJJRVNdOwog fSBfX3BhY2tlZDsKIAogc3RydWN0IGF0YV9haGNpX2NtZF9saXN0IHsKICAgICB1X2ludDE2X3Qg ICAgICAgICAgICAgICAgICAgY21kX2ZsYWdzOworI2RlZmluZSBBVEFfQUhDSV9DTURfQVRBUEkJ CTB4MDAyMAorI2RlZmluZSBBVEFfQUhDSV9DTURfV1JJVEUJCTB4MDA0MAorI2RlZmluZSBBVEFf QUhDSV9DTURfUFJFRkVUQ0gJCTB4MDA4MAorI2RlZmluZSBBVEFfQUhDSV9DTURfUkVTRVQJCTB4 MDEwMAorI2RlZmluZSBBVEFfQUhDSV9DTURfQklTVAkJMHgwMjAwCisjZGVmaW5lIEFUQV9BSENJ X0NNRF9DTFJfQlVTWQkJMHgwNDAwCisKICAgICB1X2ludDE2X3QgICAgICAgICAgICAgICAgICAg cHJkX2xlbmd0aDsgICAgIC8qIFBSRCBlbnRyaWVzICovCiAgICAgdV9pbnQzMl90ICAgICAgICAg ICAgICAgICAgIGJ5dGVjb3VudDsKICAgICB1X2ludDY0X3QgICAgICAgICAgICAgICAgICAgY21k X3RhYmxlX3BoeXM7IC8qIDEyOGJ5dGUgYWxpZ25lZCAqLwpAQCAtMjkxLDcgKzMwMSw3IEBAIHN0 cnVjdCBhdGFfYWhjaV9jbWRfbGlzdCB7CiAjZGVmaW5lIEFUQV9QQzk4X0NUTEFERFJfUklEICAg ICAgICAgICAgOAogI2RlZmluZSBBVEFfUEM5OF9CQU5LQUREUl9SSUQgICAgICAgICAgIDkKICNk ZWZpbmUgQVRBX0lSUV9SSUQgICAgICAgICAgICAgICAgICAgICAwCi0jZGVmaW5lIEFUQV9ERVYo ZGV2aWNlKSAgICAgICAgICAgICAgICAgKChkZXZpY2UgPT0gQVRBX01BU1RFUikgPyAwIDogMSkK KyNkZWZpbmUgQVRBX0RFVih1bml0KSAgICAgICAgICAgICAgICAgICAoKHVuaXQgPiAwKSA/IDB4 MTAgOiAwKQogI2RlZmluZSBBVEFfQ0ZBX01BR0lDMSAgICAgICAgICAgICAgICAgIDB4ODQ0QQog I2RlZmluZSBBVEFfQ0ZBX01BR0lDMiAgICAgICAgICAgICAgICAgIDB4ODQ4QQogI2RlZmluZSBB VEFfQ0ZBX01BR0lDMyAgICAgICAgICAgICAgICAgIDB4ODQwMApAQCAtMzQzLDYgKzM1Myw3IEBA IHN0cnVjdCBhdGFfcmVxdWVzdCB7CiAgICAgdV9pbnQzMl90ICAgICAgICAgICAgICAgICAgIGJ5 dGVjb3VudDsgICAgICAvKiBieXRlcyB0byB0cmFuc2ZlciAqLwogICAgIHVfaW50MzJfdCAgICAg ICAgICAgICAgICAgICB0cmFuc2ZlcnNpemU7ICAgLyogYnl0ZXMgcHIgdHJhbnNmZXIgKi8KICAg ICBjYWRkcl90ICAgICAgICAgICAgICAgICAgICAgZGF0YTsgICAgICAgICAgIC8qIHBvaW50ZXIg dG8gZGF0YSBidWYgKi8KKyAgICB1X2ludDMyX3QgICAgICAgICAgICAgICAgICAgdGFnOyAgICAg ICAgICAgIC8qIEhXIHRhZyBvZiB0aGlzIHJlcXVlc3QgKi8KICAgICBpbnQgICAgICAgICAgICAg ICAgICAgICAgICAgZmxhZ3M7CiAjZGVmaW5lICAgICAgICAgQVRBX1JfQ09OVFJPTCAgICAgICAg ICAgMHgwMDAwMDAwMQogI2RlZmluZSAgICAgICAgIEFUQV9SX1JFQUQgICAgICAgICAgICAgIDB4 MDAwMDAwMDIKQEAgLTM2Miw5ICszNzMsOSBAQCBzdHJ1Y3QgYXRhX3JlcXVlc3QgewogI2RlZmlu ZSAgICAgICAgIEFUQV9SX0RBTkdFUjEgICAgICAgICAgIDB4MjAwMDAwMDAKICNkZWZpbmUgICAg ICAgICBBVEFfUl9EQU5HRVIyICAgICAgICAgICAweDQwMDAwMDAwCiAKKyAgICBzdHJ1Y3QgYXRh X2RtYXNsb3QgICAgICAgICAgKmRtYTsgICAgICAgICAgIC8qIERNQSBzbG90IG9mIHRoaXMgcmVx dWVzdCAqLwogICAgIHVfaW50OF90ICAgICAgICAgICAgICAgICAgICBzdGF0dXM7ICAgICAgICAg LyogQVRBIHN0YXR1cyAqLwogICAgIHVfaW50OF90ICAgICAgICAgICAgICAgICAgICBlcnJvcjsg ICAgICAgICAgLyogQVRBIGVycm9yICovCi0gICAgdV9pbnQ4X3QgICAgICAgICAgICAgICAgICAg IGRtYXN0YXQ7ICAgICAgICAvKiBETUEgc3RhdHVzICovCiAgICAgdV9pbnQzMl90ICAgICAgICAg ICAgICAgICAgIGRvbmVjb3VudDsgICAgICAvKiBieXRlcyB0cmFuc2ZlcnJlZCAqLwogICAgIGlu dCAgICAgICAgICAgICAgICAgICAgICAgICByZXN1bHQ7ICAgICAgICAgLyogcmVzdWx0IGVycm9y IGNvZGUgKi8KICAgICB2b2lkICAgICAgICAgICAgICAgICAgICAgICAgKCpjYWxsYmFjaykoc3Ry dWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKQEAgLTM5OCw3ICs0MDksOCBAQCBzdHJ1Y3QgYXRh X2RldmljZSB7CiAgICAgZGV2aWNlX3QgICAgICAgICAgICAgICAgICAgIGRldjsgICAgICAgICAg ICAvKiBkZXZpY2UgaGFuZGxlICovCiAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgICAgIHVu aXQ7ICAgICAgICAgICAvKiBwaHlzaWNhbCB1bml0ICovCiAjZGVmaW5lICAgICAgICAgQVRBX01B U1RFUiAgICAgICAgICAgICAgMHgwMAotI2RlZmluZSAgICAgICAgIEFUQV9TTEFWRSAgICAgICAg ICAgICAgIDB4MTAKKyNkZWZpbmUgICAgICAgICBBVEFfU0xBVkUgICAgICAgICAgICAgICAweDAx CisjZGVmaW5lICAgICAgICAgQVRBX1BNICAgICAgICAgICAgICAgICAgMHgwZgogCiAgICAgc3Ry dWN0IGF0YV9wYXJhbXMgICAgICAgICAgIHBhcmFtOyAgICAgICAgICAvKiBhdGEgcGFyYW0gc3Ry dWN0dXJlICovCiAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGU7ICAgICAgICAg ICAvKiBjdXJyZW50IHRyYW5zZmVybW9kZSAqLwpAQCAtNDI2LDQzICs0MzgsNTAgQEAgc3RydWN0 IGF0YV9kbWFzZXRwcmRfYXJncyB7CiAgICAgaW50IGVycm9yOwogfTsKIAotLyogc3RydWN0dXJl IGhvbGRpbmcgRE1BIHJlbGF0ZWQgaW5mb3JtYXRpb24gKi8KLXN0cnVjdCBhdGFfZG1hIHsKLSAg ICBidXNfZG1hX3RhZ190ICAgICAgICAgICAgICAgZG1hdGFnOyAgICAgICAgIC8qIHBhcmVudCBE TUEgdGFnICovCitzdHJ1Y3QgYXRhX2RtYXNsb3QgeworICAgIHVfaW50OF90ICAgICAgICAgICAg ICAgICAgICBzdGF0dXM7ICAgICAgICAgLyogRE1BIHN0YXR1cyAqLwogICAgIGJ1c19kbWFfdGFn X3QgICAgICAgICAgICAgICBzZ190YWc7ICAgICAgICAgLyogU0cgbGlzdCBETUEgdGFnICovCiAg ICAgYnVzX2RtYW1hcF90ICAgICAgICAgICAgICAgIHNnX21hcDsgICAgICAgICAvKiBTRyBsaXN0 IERNQSBtYXAgKi8KICAgICB2b2lkICAgICAgICAgICAgICAgICAgICAgICAgKnNnOyAgICAgICAg ICAgIC8qIERNQSB0cmFuc2ZlciB0YWJsZSAqLwogICAgIGJ1c19hZGRyX3QgICAgICAgICAgICAg ICAgICBzZ19idXM7ICAgICAgICAgLyogYnVzIGFkZHJlc3Mgb2YgZG1hdGFiICovCiAgICAgYnVz X2RtYV90YWdfdCAgICAgICAgICAgICAgIGRhdGFfdGFnOyAgICAgICAvKiBkYXRhIERNQSB0YWcg Ki8KICAgICBidXNfZG1hbWFwX3QgICAgICAgICAgICAgICAgZGF0YV9tYXA7ICAgICAgIC8qIGRh dGEgRE1BIG1hcCAqLworfTsKKworLyogc3RydWN0dXJlIGhvbGRpbmcgRE1BIHJlbGF0ZWQgaW5m b3JtYXRpb24gKi8KK3N0cnVjdCBhdGFfZG1hIHsKKyAgICBidXNfZG1hX3RhZ190ICAgICAgICAg ICAgICAgZG1hdGFnOyAgICAgICAgIC8qIHBhcmVudCBETUEgdGFnICovCiAgICAgYnVzX2RtYV90 YWdfdCAgICAgICAgICAgICAgIHdvcmtfdGFnOyAgICAgICAvKiB3b3Jrc3BhY2UgRE1BIHRhZyAq LwogICAgIGJ1c19kbWFtYXBfdCAgICAgICAgICAgICAgICB3b3JrX21hcDsgICAgICAgLyogd29y a3NwYWNlIERNQSBtYXAgKi8KICAgICB1X2ludDhfdCAgICAgICAgICAgICAgICAgICAgKndvcms7 ICAgICAgICAgIC8qIHdvcmtzcGFjZSAqLwogICAgIGJ1c19hZGRyX3QgICAgICAgICAgICAgICAg ICB3b3JrX2J1czsgICAgICAgLyogYnVzIGFkZHJlc3Mgb2YgZG1hdGFiICovCiAKKyNkZWZpbmUg QVRBX0RNQV9TTE9UUwkJCTMyCisgICAgaW50CQkJCWRtYV9zbG90czsJLyogRE1BIHNsb3RzIGFs bG9jYXRlZCAqLworICAgIHN0cnVjdCBhdGFfZG1hc2xvdAkJc2xvdFtBVEFfRE1BX1NMT1RTXTsK ICAgICB1X2ludDMyX3QgICAgICAgICAgICAgICAgICAgYWxpZ25tZW50OyAgICAgIC8qIERNQSBT RyBsaXN0IGFsaWdubWVudCAqLwogICAgIHVfaW50MzJfdCAgICAgICAgICAgICAgICAgICBib3Vu ZGFyeTsgICAgICAgLyogRE1BIFNHIGxpc3QgYm91bmRhcnkgKi8KICAgICB1X2ludDMyX3QgICAg ICAgICAgICAgICAgICAgc2Vnc2l6ZTsgICAgICAgIC8qIERNQSBTRyBsaXN0IHNlZ21lbnQgc2l6 ZSAqLwogICAgIHVfaW50MzJfdCAgICAgICAgICAgICAgICAgICBtYXhfaW9zaXplOyAgICAgLyog RE1BIGRhdGEgbWF4IElPIHNpemUgKi8KLSAgICB1X2ludDMyX3QgICAgICAgICAgICAgICAgICAg Y3VyX2lvc2l6ZTsgICAgIC8qIERNQSBkYXRhIGN1cnJlbnQgSU8gc2l6ZSAqLwogICAgIHVfaW50 NjRfdCAgICAgICAgICAgICAgICAgICBtYXhfYWRkcmVzczsgICAgLyogaGlnaGVzdCBETUEnYWJs ZSBhZGRyZXNzICovCiAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgICAgIGZsYWdzOwotI2Rl ZmluZSBBVEFfRE1BX1JFQUQgICAgICAgICAgICAgICAgICAgIDB4MDEgICAgLyogdHJhbnNhY3Rp b24gaXMgYSByZWFkICovCi0jZGVmaW5lIEFUQV9ETUFfTE9BREVEICAgICAgICAgICAgICAgICAg MHgwMiAgICAvKiBETUEgdGFibGVzIGV0YyBsb2FkZWQgKi8KLSNkZWZpbmUgQVRBX0RNQV9BQ1RJ VkUgICAgICAgICAgICAgICAgICAweDA0ICAgIC8qIERNQSB0cmFuc2ZlciBpbiBwcm9ncmVzcyAq LworI2RlZmluZSBBVEFfRE1BX0FDVElWRSAgICAgICAgICAgICAgICAgIDB4MDEgICAgLyogRE1B IHRyYW5zZmVyIGluIHByb2dyZXNzICovCiAKICAgICB2b2lkICgqYWxsb2MpKGRldmljZV90IGRl dik7CiAgICAgdm9pZCAoKmZyZWUpKGRldmljZV90IGRldik7CiAgICAgdm9pZCAoKnNldHByZCko dm9pZCAqeHNjLCBidXNfZG1hX3NlZ21lbnRfdCAqc2VncywgaW50IG5zZWdzLCBpbnQgZXJyb3Ip OwotICAgIGludCAoKmxvYWQpKGRldmljZV90IGRldiwgY2FkZHJfdCBkYXRhLCBpbnQzMl90IGNv dW50LCBpbnQgZGlyLCB2b2lkICphZGRyLCBpbnQgKm5zZWdzKTsKLSAgICBpbnQgKCp1bmxvYWQp KGRldmljZV90IGRldik7Ci0gICAgaW50ICgqc3RhcnQpKGRldmljZV90IGRldik7Ci0gICAgaW50 ICgqc3RvcCkoZGV2aWNlX3QgZGV2KTsKKyAgICBpbnQgKCpsb2FkKShzdHJ1Y3QgYXRhX3JlcXVl c3QgKnJlcXVlc3QsIHZvaWQgKmFkZHIsIGludCAqbnNlZ3MpOworICAgIGludCAoKnVubG9hZCko c3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKKyAgICBpbnQgKCpzdGFydCkoc3RydWN0IGF0 YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKKyAgICBpbnQgKCpzdG9wKShzdHJ1Y3QgYXRhX3JlcXVlc3Qg KnJlcXVlc3QpOwogICAgIHZvaWQgKCpyZXNldCkoZGV2aWNlX3QgZGV2KTsKIH07CiAKIC8qIHN0 cnVjdHVyZSBob2xkaW5nIGxvd2xldmVsIGZ1bmN0aW9ucyAqLwogc3RydWN0IGF0YV9sb3dsZXZl bCB7CisgICAgdV9pbnQzMl90ICgqc29mdHJlc2V0KShkZXZpY2VfdCBkZXYsIGludCBwbXBvcnQp OworICAgIGludCAoKnBtX3JlYWQpKGRldmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVf aW50MzJfdCAqcmVzdWx0KTsKKyAgICBpbnQgKCpwbV93cml0ZSkoZGV2aWNlX3QgZGV2LCBpbnQg cG9ydCwgaW50IHJlZywgdV9pbnQzMl90IHZhbHVlKTsKICAgICBpbnQgKCpzdGF0dXMpKGRldmlj ZV90IGRldik7CiAgICAgaW50ICgqYmVnaW5fdHJhbnNhY3Rpb24pKHN0cnVjdCBhdGFfcmVxdWVz dCAqcmVxdWVzdCk7CiAgICAgaW50ICgqZW5kX3RyYW5zYWN0aW9uKShzdHJ1Y3QgYXRhX3JlcXVl c3QgKnJlcXVlc3QpOwpAQCAtNDg1LDcgKzUwNCw3IEBAIHN0cnVjdCBhdGFfY2hhbm5lbCB7CiAg ICAgc3RydWN0IHJlc291cmNlICAgICAgICAgICAgICpyX2lycTsgICAgICAgICAvKiBpbnRlcnJ1 cHQgb2YgdGhpcyBjaGFubmVsICovCiAgICAgdm9pZCAgICAgICAgICAgICAgICAgICAgICAgICpp aDsgICAgICAgICAgICAvKiBpbnRlcnJ1cHQgaGFuZGxlICovCiAgICAgc3RydWN0IGF0YV9sb3ds ZXZlbCAgICAgICAgIGh3OyAgICAgICAgICAgICAvKiBsb3dsZXZlbCBIVyBmdW5jdGlvbnMgKi8K LSAgICBzdHJ1Y3QgYXRhX2RtYSAgICAgICAgICAgICAgKmRtYTsgICAgICAgICAgIC8qIERNQSBk YXRhIC8gZnVuY3Rpb25zICovCisgICAgc3RydWN0IGF0YV9kbWEgICAgICAgICAgICAgIGRtYTsg ICAgICAgICAgICAvKiBETUEgZGF0YSAvIGZ1bmN0aW9ucyAqLwogICAgIGludCAgICAgICAgICAg ICAgICAgICAgICAgICBmbGFnczsgICAgICAgICAgLyogY2hhbm5lbCBmbGFncyAqLwogI2RlZmlu ZSAgICAgICAgIEFUQV9OT19TTEFWRSAgICAgICAgICAgIDB4MDEKICNkZWZpbmUgICAgICAgICBB VEFfVVNFXzE2QklUICAgICAgICAgICAweDAyCkBAIC00OTQsMTEgKzUxMywxMSBAQCBzdHJ1Y3Qg YXRhX2NoYW5uZWwgewogI2RlZmluZSAgICAgICAgIEFUQV9BTFdBWVNfRE1BU1RBVCAgICAgIDB4 MTAKIAogICAgIGludCAgICAgICAgICAgICAgICAgICAgICAgICBkZXZpY2VzOyAgICAgICAgLyog d2hhdCBpcyBwcmVzZW50ICovCi0jZGVmaW5lICAgICAgICAgQVRBX0FUQV9NQVNURVIgICAgICAg ICAgMHgwMQotI2RlZmluZSAgICAgICAgIEFUQV9BVEFfU0xBVkUgICAgICAgICAgIDB4MDIKLSNk ZWZpbmUgICAgICAgICBBVEFfQVRBUElfTUFTVEVSICAgICAgICAweDA0Ci0jZGVmaW5lICAgICAg ICAgQVRBX0FUQVBJX1NMQVZFICAgICAgICAgMHgwOAotI2RlZmluZSAgICAgICAgIEFUQV9QT1JU TVVMVElQTElFUiAgICAgIDB4MTAKKyNkZWZpbmUgICAgICAgICBBVEFfQVRBX01BU1RFUiAgICAg ICAgICAweDAwMDAwMDAxCisjZGVmaW5lICAgICAgICAgQVRBX0FUQV9TTEFWRSAgICAgICAgICAg MHgwMDAwMDAwMgorI2RlZmluZSAgICAgICAgIEFUQV9QT1JUTVVMVElQTElFUiAgICAgIDB4MDAw MDgwMDAKKyNkZWZpbmUgICAgICAgICBBVEFfQVRBUElfTUFTVEVSICAgICAgICAweDAwMDEwMDAw CisjZGVmaW5lICAgICAgICAgQVRBX0FUQVBJX1NMQVZFICAgICAgICAgMHgwMDAyMDAwMAogCiAg ICAgc3RydWN0IG10eCAgICAgICAgICAgICAgICAgIHN0YXRlX210eDsgICAgICAvKiBzdGF0ZSBs b2NrICovCiAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXRlOyAgICAgICAgICAv KiBBVEEgY2hhbm5lbCBzdGF0ZSAqLwpAQCAtNTI0LDYgKzU0Myw3IEBAIGV4dGVybiBpbnQgKCph dGFfcmFpZF9pb2N0bF9mdW5jKSh1X2xvbmcKIGV4dGVybiBzdHJ1Y3QgaW50cl9jb25maWdfaG9v ayAqYXRhX2RlbGF5ZWRfYXR0YWNoOwogZXh0ZXJuIGRldmNsYXNzX3QgYXRhX2RldmNsYXNzOwog ZXh0ZXJuIGludCBhdGFfd2M7CitleHRlcm4gaW50IGF0YV9zZXRtYXg7CiBleHRlcm4gaW50IGF0 YV9kbWFfY2hlY2tfODBwaW47CiAKIC8qIHB1YmxpYyBwcm90b3R5cGVzICovCkBAIC01MzYsMTAg KzU1NiwxMiBAQCBpbnQgYXRhX3N1c3BlbmQoZGV2aWNlX3QgZGV2KTsKIGludCBhdGFfcmVzdW1l KGRldmljZV90IGRldik7CiBpbnQgYXRhX2ludGVycnVwdCh2b2lkICpkYXRhKTsKIGludCBhdGFf ZGV2aWNlX2lvY3RsKGRldmljZV90IGRldiwgdV9sb25nIGNtZCwgY2FkZHJfdCBkYXRhKTsKK2lu dCBhdGFfZ2V0cGFyYW0oc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldiwgaW50IGluaXQpOwogaW50 IGF0YV9pZGVudGlmeShkZXZpY2VfdCBkZXYpOwogdm9pZCBhdGFfZGVmYXVsdF9yZWdpc3RlcnMo ZGV2aWNlX3QgZGV2KTsKIHZvaWQgYXRhX21vZGlmeV9pZl80OGJpdChzdHJ1Y3QgYXRhX3JlcXVl c3QgKnJlcXVlc3QpOwogdm9pZCBhdGFfdWRlbGF5KGludCBpbnRlcnZhbCk7CitjaGFyICphdGFf dW5pdDJzdHIoc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldik7CiBjaGFyICphdGFfbW9kZTJzdHIo aW50IG1vZGUpOwogaW50IGF0YV9wbW9kZShzdHJ1Y3QgYXRhX3BhcmFtcyAqYXApOwogaW50IGF0 YV93bW9kZShzdHJ1Y3QgYXRhX3BhcmFtcyAqYXApOwpAQCAtNTcxLDYgKzU5Myw3IEBAIGV4dGVy biB1bWFfem9uZV90IGF0YV9yZXF1ZXN0X3pvbmU7CiAJaWYgKCEocmVxdWVzdC0+ZmxhZ3MgJiBB VEFfUl9EQU5HRVIyKSkgXAogCSAgICB1bWFfemZyZWUoYXRhX3JlcXVlc3Rfem9uZSwgcmVxdWVz dCk7IFwKIAl9CisKIC8qIG1hY3JvcyBmb3IgYWxsb2MvZnJlZSBvZiBzdHJ1Y3QgYXRhX2NvbXBv c2l0ZSAqLwogZXh0ZXJuIHVtYV96b25lX3QgYXRhX2NvbXBvc2l0ZV96b25lOwogI2RlZmluZSBh dGFfYWxsb2NfY29tcG9zaXRlKCkgdW1hX3phbGxvYyhhdGFfY29tcG9zaXRlX3pvbmUsIE1fTk9X QUlUIHwgTV9aRVJPKQotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1jYXJkLmMJMjAwNy0wMi0yMSAy MjowNzoxOC4wMDAwMDAwMDAgKzAzMDAKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtY2FyZC5jCTIw MDgtMDQtMTAgMTc6MDU6MDQuMDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyotCi0g KiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9y Zz4KKyAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZyZWVC U0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBh bmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKLS0tIHNy Yy9zeXMvZGV2L2F0YS9hdGEtY2J1cy5jCTIwMDctMDItMjMgMTU6MTg6MzIuMDAwMDAwMDAwICsw MzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhLWNidXMuYwkyMDA4LTA0LTEwIDE3OjA1OjA1LjAw MDAwMDAwMCArMDQwMApAQCAtMSw1ICsxLDUgQEAKIC8qLQotICogQ29weXJpZ2h0IChjKSAyMDAy IC0gMjAwNyBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CisgKiBDb3B5cmlnaHQgKGMp IDIwMDIgLSAyMDA4IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KICAqIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0tLSBzcmMvc3lzL2Rldi9hdGEvYXRhLWNo aXBzZXQuYwkyMDA4LTA5LTEzIDExOjM2OjE2LjAwMDAwMDAwMCArMDQwMAorKysgc3JjL3N5cy9k ZXYvYXRhL2F0YS1jaGlwc2V0LmMJMjAwOC0wOS0yNiAxMToyOTo0OC4wMDAwMDAwMDAgKzA0MDAK QEAgLTEsNSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDcgU/hyZW4g U2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwOCBT +HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgog ICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMs IHdpdGggb3Igd2l0aG91dApAQCAtNjIsMTAgKzYyLDE1IEBAIHN0YXRpYyBpbnQgYXRhX3NhdGFf Y29ubmVjdChzdHJ1Y3QgYXRhX2MKIHN0YXRpYyB2b2lkIGF0YV9zYXRhX3NldG1vZGUoZGV2aWNl X3QgZGV2LCBpbnQgbW9kZSk7CiBzdGF0aWMgaW50IGF0YV9yZXF1ZXN0MmZpc19oMmQoc3RydWN0 IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0LCB1X2ludDhfdCAqZmlzKTsKIHN0YXRpYyBpbnQgYXRhX2Fo Y2lfY2hpcGluaXQoZGV2aWNlX3QgZGV2KTsKK3N0YXRpYyBpbnQgYXRhX2FoY2lfY3Rscl9yZXNl dChkZXZpY2VfdCBkZXYpOworc3RhdGljIGludCBhdGFfYWhjaV9zdXNwZW5kKGRldmljZV90IGRl dik7CiBzdGF0aWMgaW50IGF0YV9haGNpX2FsbG9jYXRlKGRldmljZV90IGRldik7CiBzdGF0aWMg aW50IGF0YV9haGNpX3N0YXR1cyhkZXZpY2VfdCBkZXYpOwogc3RhdGljIGludCBhdGFfYWhjaV9i ZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpOwogc3RhdGljIGlu dCBhdGFfYWhjaV9lbmRfdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KTsK K3N0YXRpYyBpbnQgYXRhX2FoY2lfcG1fcmVhZChkZXZpY2VfdCBkZXYsIGludCBwb3J0LCBpbnQg cmVnLCB1X2ludDMyX3QgKnJlc3VsdCk7CitzdGF0aWMgaW50IGF0YV9haGNpX3BtX3dyaXRlKGRl dmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCByZXN1bHQpOworc3RhdGlj IHVfaW50MzJfdCBhdGFfYWhjaV9zb2Z0cmVzZXQoZGV2aWNlX3QgZGV2LCBpbnQgcG9ydCk7CiBz dGF0aWMgdm9pZCBhdGFfYWhjaV9yZXNldChkZXZpY2VfdCBkZXYpOwogc3RhdGljIHZvaWQgYXRh X2FoY2lfZG1hc2V0cHJkKHZvaWQgKnhzYywgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCBu c2VncywgaW50IGVycm9yKTsKIHN0YXRpYyB2b2lkIGF0YV9haGNpX2RtYWluaXQoZGV2aWNlX3Qg ZGV2KTsKQEAgLTEwMiw3ICsxMDcsOCBAQCBzdGF0aWMgaW50IGF0YV9pbnRlbF8zMTI0NF9zdGF0 dXMoZGV2aWNlCiBzdGF0aWMgdm9pZCBhdGFfaW50ZWxfMzEyNDRfdGZfd3JpdGUoc3RydWN0IGF0 YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKIHN0YXRpYyB2b2lkIGF0YV9pbnRlbF8zMTI0NF9yZXNldChk ZXZpY2VfdCBkZXYpOwogc3RhdGljIGludCBhdGFfaXRlX2NoaXBpbml0KGRldmljZV90IGRldik7 Ci1zdGF0aWMgdm9pZCBhdGFfaXRlX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBpbnQgbW9kZSk7Citz dGF0aWMgdm9pZCBhdGFfaXRlXzgyMTNfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKTsK K3N0YXRpYyB2b2lkIGF0YV9pdGVfODIxeF9zZXRtb2RlKGRldmljZV90IGRldiwgaW50IG1vZGUp Owogc3RhdGljIGludCBhdGFfam1pY3Jvbl9jaGlwaW5pdChkZXZpY2VfdCBkZXYpOwogc3RhdGlj IGludCBhdGFfam1pY3Jvbl9hbGxvY2F0ZShkZXZpY2VfdCBkZXYpOwogc3RhdGljIHZvaWQgYXRh X2ptaWNyb25fcmVzZXQoZGV2aWNlX3QgZGV2KTsKQEAgLTEzMCw4ICsxMzYsOCBAQCBzdGF0aWMg dm9pZCBhdGFfbnZpZGlhX3Jlc2V0KGRldmljZV90IGRlCiBzdGF0aWMgaW50IGF0YV9wcm9taXNl X2NoaXBpbml0KGRldmljZV90IGRldik7CiBzdGF0aWMgaW50IGF0YV9wcm9taXNlX2FsbG9jYXRl KGRldmljZV90IGRldik7CiBzdGF0aWMgaW50IGF0YV9wcm9taXNlX3N0YXR1cyhkZXZpY2VfdCBk ZXYpOwotc3RhdGljIGludCBhdGFfcHJvbWlzZV9kbWFzdGFydChkZXZpY2VfdCBkZXYpOwotc3Rh dGljIGludCBhdGFfcHJvbWlzZV9kbWFzdG9wKGRldmljZV90IGRldik7CitzdGF0aWMgaW50IGF0 YV9wcm9taXNlX2RtYXN0YXJ0KHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCk7CitzdGF0aWMg aW50IGF0YV9wcm9taXNlX2RtYXN0b3Aoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKIHN0 YXRpYyB2b2lkIGF0YV9wcm9taXNlX2RtYXJlc2V0KGRldmljZV90IGRldik7CiBzdGF0aWMgdm9p ZCBhdGFfcHJvbWlzZV9kbWFpbml0KGRldmljZV90IGRldik7CiBzdGF0aWMgdm9pZCBhdGFfcHJv bWlzZV9zZXRtb2RlKGRldmljZV90IGRldiwgaW50IG1vZGUpOwpAQCAtMTQyLDYgKzE0OCw5IEBA IHN0YXRpYyB2b2lkIGF0YV9wcm9taXNlX21pb19pbnRyKHZvaWQgKmQKIHN0YXRpYyBpbnQgYXRh X3Byb21pc2VfbWlvX3N0YXR1cyhkZXZpY2VfdCBkZXYpOwogc3RhdGljIGludCBhdGFfcHJvbWlz ZV9taW9fY29tbWFuZChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpOwogc3RhdGljIHZvaWQg YXRhX3Byb21pc2VfbWlvX3Jlc2V0KGRldmljZV90IGRldik7CitzdGF0aWMgaW50IGF0YV9wcm9t aXNlX21pb19wbV9yZWFkKGRldmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJf dCAqcmVzdWx0KTsKK3N0YXRpYyBpbnQgYXRhX3Byb21pc2VfbWlvX3BtX3dyaXRlKGRldmljZV90 IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCByZXN1bHQpOworc3RhdGljIHVfaW50 MzJfdCBhdGFfcHJvbWlzZV9taW9fc29mdHJlc2V0KGRldmljZV90IGRldiwgaW50IHBvcnQpOwog c3RhdGljIHZvaWQgYXRhX3Byb21pc2VfbWlvX2RtYWluaXQoZGV2aWNlX3QgZGV2KTsKIHN0YXRp YyB2b2lkIGF0YV9wcm9taXNlX21pb19zZXRwcmQodm9pZCAqeHNjLCBidXNfZG1hX3NlZ21lbnRf dCAqc2VncywgaW50IG5zZWdzLCBpbnQgZXJyb3IpOwogc3RhdGljIHZvaWQgYXRhX3Byb21pc2Vf bWlvX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBpbnQgbW9kZSk7CkBAIC0xNjcsNiArMTc2LDkgQEAg c3RhdGljIGludCBhdGFfc2lpcHJiX2FsbG9jYXRlKGRldmljZV90IAogc3RhdGljIGludCBhdGFf c2lpcHJiX3N0YXR1cyhkZXZpY2VfdCBkZXYpOwogc3RhdGljIGludCBhdGFfc2lpcHJiX2JlZ2lu X3RyYW5zYWN0aW9uKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCk7CiBzdGF0aWMgaW50IGF0 YV9zaWlwcmJfZW5kX3RyYW5zYWN0aW9uKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCk7Citz dGF0aWMgaW50IGF0YV9zaWlwcmJfcG1fcmVhZChkZXZpY2VfdCBkZXYsIGludCBwb3J0LCBpbnQg cmVnLCB1X2ludDMyX3QgKnJlc3VsdCk7CitzdGF0aWMgaW50IGF0YV9zaWlwcmJfcG1fd3JpdGUo ZGV2aWNlX3QgZGV2LCBpbnQgcG9ydCwgaW50IHJlZywgdV9pbnQzMl90IHJlc3VsdCk7CitzdGF0 aWMgdV9pbnQzMl90IGF0YV9zaWlwcmJfc29mdHJlc2V0KGRldmljZV90IGRldiwgaW50IHBvcnQp Owogc3RhdGljIHZvaWQgYXRhX3NpaXByYl9yZXNldChkZXZpY2VfdCBkZXYpOwogc3RhdGljIHZv aWQgYXRhX3NpaXByYl9kbWFzZXRwcmQodm9pZCAqeHNjLCBidXNfZG1hX3NlZ21lbnRfdCAqc2Vn cywgaW50IG5zZWdzLCBpbnQgZXJyb3IpOwogc3RhdGljIHZvaWQgYXRhX3NpaXByYl9kbWFpbml0 KGRldmljZV90IGRldik7CkBAIC0yNjgsMTUgKzI4MCwxNSBAQCBhdGFfc2F0YV9waHlfY2hlY2tf ZXZlbnRzKGRldmljZV90IGRldikKIAkgICAgaWYgKCgoc3RhdHVzICYgQVRBX1NTX0NPTldFTExf TUFTSykgPT0gQVRBX1NTX0NPTldFTExfR0VOMSkgfHwKIAkJKChzdGF0dXMgJiBBVEFfU1NfQ09O V0VMTF9NQVNLKSA9PSBBVEFfU1NfQ09OV0VMTF9HRU4yKSkgewogCQlpZiAoYm9vdHZlcmJvc2Up Ci0JCSAgICBkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJDT05ORUNUIHJlcXVlc3RlZFxuIik7CisJ CSAgICBkZXZpY2VfcHJpbnRmKGRldiwgIkNPTk5FQ1QgcmVxdWVzdGVkXG4iKTsKIAkJdHAtPmFj dGlvbiA9IEFUQV9DX0FUVEFDSDsKIAkgICAgfQogCSAgICBlbHNlIHsKIAkJaWYgKGJvb3R2ZXJi b3NlKQotCQkgICAgZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAiRElTQ09OTkVDVCByZXF1ZXN0ZWRc biIpOworCQkgICAgZGV2aWNlX3ByaW50ZihkZXYsICJESVNDT05ORUNUIHJlcXVlc3RlZFxuIik7 CiAJCXRwLT5hY3Rpb24gPSBBVEFfQ19ERVRBQ0g7CiAJICAgIH0KLQkgICAgdHAtPmRldiA9IGNo LT5kZXY7CisJICAgIHRwLT5kZXYgPSBkZXY7CiAJICAgIFRBU0tfSU5JVCgmdHAtPnRhc2ssIDAs IGF0YV9zYXRhX3BoeV9ldmVudCwgdHApOwogCSAgICB0YXNrcXVldWVfZW5xdWV1ZSh0YXNrcXVl dWVfdGhyZWFkLCAmdHAtPnRhc2spOwogCX0KQEAgLTQwNywxNCArNDE5LDExMiBAQCBhdGFfc2F0 YV9zZXRtb2RlKGRldmljZV90IGRldiwgaW50IG1vZGUpCiAgICAgfQogfQogCitzdGF0aWMgdm9p ZAorYXRhX3BtX2lkZW50aWZ5KGRldmljZV90IGRldikKK3sKKyAgICBzdHJ1Y3QgYXRhX2NoYW5u ZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIHVfaW50MzJfdCBwbV9jaGlwaWQs IHBtX3JldmlzaW9uLCBwbV9wb3J0czsKKyAgICBpbnQgcG9ydDsKKworICAgIC8qIGdldCBQTSB2 ZW5kb3IgJiBwcm9kdWN0IGRhdGEgKi8KKyAgICBpZiAoY2gtPmh3LnBtX3JlYWQoZGV2LCBBVEFf UE0sIDAsICZwbV9jaGlwaWQpKSB7CisJZGV2aWNlX3ByaW50ZihkZXYsICJlcnJvciBnZXR0aW5n IFBNIHZlbmRvciBkYXRhXG4iKTsKKwlyZXR1cm47CisgICAgfQorCisgICAgLyogZ2V0IFBNIHJl dmlzaW9uIGRhdGEgKi8KKyAgICBpZiAoY2gtPmh3LnBtX3JlYWQoZGV2LCBBVEFfUE0sIDEsICZw bV9yZXZpc2lvbikpIHsKKwlkZXZpY2VfcHJpbnRmKGRldiwgImVycm9yIGdldHRpbmcgUE0gcmV2 aXNvbiBkYXRhXG4iKTsKKwlyZXR1cm47CisgICAgfQorCisgICAgLyogZ2V0IG51bWJlciBvZiBI VyBwb3J0cyBvbiB0aGUgUE0gKi8KKyAgICBpZiAoY2gtPmh3LnBtX3JlYWQoZGV2LCBBVEFfUE0s IDIsICZwbV9wb3J0cykpIHsKKwlkZXZpY2VfcHJpbnRmKGRldiwgImVycm9yIGdldHRpbmcgUE0g cG9ydCBpbmZvXG4iKTsKKwlyZXR1cm47CisgICAgfQorICAgIHBtX3BvcnRzICY9IDB4MDAwMDAw MGY7CisKKyAgICAvKiBjaGlwIHNwZWNpZmljIHF1aXJrcyAqLworICAgIHN3aXRjaCAocG1fY2hp cGlkKSB7CisgICAgY2FzZSAweDM3MjYxMDk1OgorCS8qIFNvbWUgb2YgdGhlc2UgYm9ndXNseSBy ZXBvcnRzIDYgcG9ydHMgKi8KKwlwbV9wb3J0cyA9IDU7CisJZGV2aWNlX3ByaW50ZihkZXYsICJT aUkgMzcyNiByJXggUG9ydG11bHRpcGxpZXIgd2l0aCAlZCBwb3J0c1xuIiwKKwkJICAgICAgcG1f cmV2aXNpb24sIHBtX3BvcnRzKTsKKwlicmVhazsKKworICAgIGRlZmF1bHQ6CisJZGV2aWNlX3By aW50ZihkZXYsICJQb3J0bXVsdGlwbGllciAoaWQ9JTA4eCByZXY9JXgpIHdpdGggJWQgcG9ydHNc biIsCisJCSAgICAgIHBtX2NoaXBpZCwgcG1fcmV2aXNpb24sIHBtX3BvcnRzKTsKKyAgICB9CisK KyAgICAvKiBpbmZvcm0gZG1hLmFsbG9jKCkgYWJvdXQgbmVlZGVkIERNQSBzbG90cyAqLworICAg IGNoLT5kbWEuZG1hX3Nsb3RzID0gcG1fcG9ydHM7CisKKyAgICAvKiByZXNldCBhbGwgcG9ydHMg YW5kIHJlZ2lzdGVyIGlmIGFueXRoaW5nIGNvbm5lY3RlZCAqLworICAgIGZvciAocG9ydD0wOyBw b3J0IDwgcG1fcG9ydHM7IHBvcnQrKykgeworCXVfaW50MzJfdCBzaWduYXR1cmUsIHN0YXR1czsK KwlpbnQgdGltZW91dDsKKworCWlmIChjaC0+aHcucG1fd3JpdGUoZGV2LCBwb3J0LCAyLCBBVEFf U0NfREVUX1JFU0VUKSkgeworCSAgICBkZXZpY2VfcHJpbnRmKGRldiwgInAlZDogd3JpdGluZyBB VEFfU0NfREVUX1JFU0VUIGZhaWxlZFxuIiwgcG9ydCk7CisJICAgIGNvbnRpbnVlOworCX0KKwor CWF0YV91ZGVsYXkoNTAwMCk7CisKKwlpZiAoY2gtPmh3LnBtX3dyaXRlKGRldiwgcG9ydCwgMiwg QVRBX1NDX0RFVF9JRExFKSkgeworCSAgICBkZXZpY2VfcHJpbnRmKGRldiwgInAlZDogd3JpdGlu ZyBBVEFfU0NfREVUX2lkbGUgZmFpbGVkXG4iLCBwb3J0KTsKKwkgICAgY29udGludWU7CisJfQor CisJYXRhX3VkZWxheSg1MDAwKTsKKworCS8qIHdhaXQgdXAgdG8gMSBzZWNvbmQgZm9yICJjb25u ZWN0IHdlbGwiICovCisJZm9yICh0aW1lb3V0ID0gMDsgdGltZW91dCA8IDEwMCA7IHRpbWVvdXQr KykgeworCSAgICBjaC0+aHcucG1fcmVhZChkZXYsIHBvcnQsIDAsICZzdGF0dXMpOworCSAgICBp ZiAoKHN0YXR1cyAmIEFUQV9TU19DT05XRUxMX01BU0spID09IEFUQV9TU19DT05XRUxMX0dFTjEg fHwKKwkJKHN0YXR1cyAmIEFUQV9TU19DT05XRUxMX01BU0spID09IEFUQV9TU19DT05XRUxMX0dF TjIpCisJCWJyZWFrOworCSAgICBhdGFfdWRlbGF5KDEwMDAwKTsKKwl9CisJaWYgKHRpbWVvdXQg Pj0gMTAwKSB7CisJICAgIGlmIChib290dmVyYm9zZSkKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJw JWQ6IGNvbm5lY3Qgc3RhdHVzPSUwOHhcbiIsIHBvcnQsIHN0YXR1cyk7CisJICAgIGNvbnRpbnVl OworCX0KKwlpZiAoYm9vdHZlcmJvc2UpCisJICAgIGRldmljZV9wcmludGYoZGV2LCAicCVkOiBj b25uZWN0IHRpbWUgJWRtc1xuIiwgcG9ydCwgdGltZW91dCAqIDEwKTsKKworCS8qIGNsZWFyIFNF UlJPUiByZWdpc3RlciAqLworCWNoLT5ody5wbV93cml0ZShkZXYsIHBvcnQsIDEsIDB4ZmZmZmZm ZmYpOworCisJc2lnbmF0dXJlID0gY2gtPmh3LnNvZnRyZXNldChkZXYsIHBvcnQpOworCisJaWYg KGJvb3R2ZXJib3NlKQorCSAgICBkZXZpY2VfcHJpbnRmKGRldiwgInAlZDogU0lHTkFUVVJFPSUw OHhcbiIsIHBvcnQsIHNpZ25hdHVyZSk7CisKKwkvKiBmaWd1cmUgb3V0IHdoYXRzIHRoZXJlICov CisJc3dpdGNoIChzaWduYXR1cmUpIHsKKwljYXNlIDB4MDAwMDAxMDE6CisJICAgIGNoLT5kZXZp Y2VzIHw9IChBVEFfQVRBX01BU1RFUiA8PCBwb3J0KTsKKwkgICAgY29udGludWU7CisJY2FzZSAw eGViMTQwMTAxOgorCSAgICBjaC0+ZGV2aWNlcyB8PSAoQVRBX0FUQVBJX01BU1RFUiA8PCBwb3J0 KTsKKwkgICAgY29udGludWU7CisJfQorICAgIH0KK30KKwogc3RhdGljIGludAogYXRhX3JlcXVl c3QyZmlzX2gyZChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QsIHVfaW50OF90ICpmaXMpCiB7 CiAgICAgc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9nZXRfc29mdGMocmVxdWVz dC0+ZGV2KTsKIAogICAgIGlmIChyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX0FUQVBJKSB7Ci0JZmlz WzBdID0gMHgyNzsgIC8qIGhvc3QgdG8gZGV2aWNlICovCi0JZmlzWzFdID0gMHg4MDsgIC8qIGNv bW1hbmQgRklTIChub3RlIFBNIGdvZXMgaGVyZSkgKi8KKwlmaXNbMF0gPSAweDI3OyAgCQkvKiBo b3N0IHRvIGRldmljZSAqLworCWZpc1sxXSA9IDB4ODAgfCAoYXRhZGV2LT51bml0ICYgMHgwZik7 CiAJZmlzWzJdID0gQVRBX1BBQ0tFVF9DTUQ7CiAJaWYgKHJlcXVlc3QtPmZsYWdzICYgKEFUQV9S X1JFQUQgfCBBVEFfUl9XUklURSkpCiAJICAgIGZpc1szXSA9IEFUQV9GX0RNQTsKQEAgLTQyMiwy MiArNTMyLDIyIEBAIGF0YV9yZXF1ZXN0MmZpc19oMmQoc3RydWN0IGF0YV9yZXF1ZXN0ICoKIAkg ICAgZmlzWzVdID0gcmVxdWVzdC0+dHJhbnNmZXJzaXplOwogCSAgICBmaXNbNl0gPSByZXF1ZXN0 LT50cmFuc2ZlcnNpemUgPj4gODsKIAl9Ci0JZmlzWzddID0gQVRBX0RfTEJBIHwgYXRhZGV2LT51 bml0OworCWZpc1s3XSA9IEFUQV9EX0xCQTsKIAlmaXNbMTVdID0gQVRBX0FfNEJJVDsKIAlyZXR1 cm4gMjA7CiAgICAgfQogICAgIGVsc2UgewogCWF0YV9tb2RpZnlfaWZfNDhiaXQocmVxdWVzdCk7 Ci0JZmlzWzBdID0gMHgyNzsgIC8qIGhvc3QgdG8gZGV2aWNlICovCi0JZmlzWzFdID0gMHg4MDsg IC8qIGNvbW1hbmQgRklTIChub3RlIFBNIGdvZXMgaGVyZSkgKi8KKwlmaXNbMF0gPSAweDI3OwkJ CS8qIGhvc3QgdG8gZGV2aWNlICovCisJZmlzWzFdID0gMHg4MCB8IChhdGFkZXYtPnVuaXQgJiAw eDBmKTsKIAlmaXNbMl0gPSByZXF1ZXN0LT51LmF0YS5jb21tYW5kOwogCWZpc1szXSA9IHJlcXVl c3QtPnUuYXRhLmZlYXR1cmU7CiAJZmlzWzRdID0gcmVxdWVzdC0+dS5hdGEubGJhOwogCWZpc1s1 XSA9IHJlcXVlc3QtPnUuYXRhLmxiYSA+PiA4OwogCWZpc1s2XSA9IHJlcXVlc3QtPnUuYXRhLmxi YSA+PiAxNjsKLQlmaXNbN10gPSBBVEFfRF9MQkEgfCBhdGFkZXYtPnVuaXQ7CisJZmlzWzddID0g QVRBX0RfTEJBOwogCWlmICghKGF0YWRldi0+ZmxhZ3MgJiBBVEFfRF80OEJJVF9BQ1RJVkUpKQot CSAgICBmaXNbN10gfD0gKHJlcXVlc3QtPnUuYXRhLmxiYSA+PiAyNCAmIDB4MGYpOworCSAgICBm aXNbN10gfD0gKEFUQV9EX0lCTSB8IChyZXF1ZXN0LT51LmF0YS5sYmEgPj4gMjQgJiAweDBmKSk7 CiAJZmlzWzhdID0gcmVxdWVzdC0+dS5hdGEubGJhID4+IDI0OwogCWZpc1s5XSA9IHJlcXVlc3Qt PnUuYXRhLmxiYSA+PiAzMjsgCiAJZmlzWzEwXSA9IHJlcXVlc3QtPnUuYXRhLmxiYSA+PiA0MDsg CkBAIC00OTUsNiArNjA1LDQyIEBAIGF0YV9haGNpX2NoaXBpbml0KGRldmljZV90IGRldikKICAg ICBlbHNlCiAJZGV2aWNlX3ByaW50ZihkZXYsICJBSENJIGNhbGxlZCBmcm9tIHZlbmRvciBzcGVj aWZpYyBkcml2ZXJcbiIpOwogCisgICAgLyogcmVzZXQgY29udHJvbGxlciAqLworICAgIGF0YV9h aGNpX2N0bHJfcmVzZXQoZGV2KTsKKworICAgIC8qIGdldCB0aGUgbnVtYmVyIG9mIEhXIGNoYW5u ZWxzICovCisgICAgY3Rsci0+Y2hhbm5lbHMgPQorCU1BWChmbHNsKEFUQV9JTkwoY3Rsci0+cl9y ZXMyLCBBVEFfQUhDSV9QSSkpLCAKKwkgICAgKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhD SV9DQVApICYgQVRBX0FIQ0lfTlBNQVNLKSArIDEpOworCisgICAgY3Rsci0+cmVzZXQgPSBhdGFf YWhjaV9yZXNldDsKKyAgICBjdGxyLT5kbWFpbml0ID0gYXRhX2FoY2lfZG1haW5pdDsKKyAgICBj dGxyLT5hbGxvY2F0ZSA9IGF0YV9haGNpX2FsbG9jYXRlOworICAgIGN0bHItPnNldG1vZGUgPSBh dGFfc2F0YV9zZXRtb2RlOworICAgIGN0bHItPnN1c3BlbmQgPSBhdGFfYWhjaV9zdXNwZW5kOwor ICAgIGN0bHItPnJlc3VtZSA9IGF0YV9haGNpX2N0bHJfcmVzZXQ7CisKKyAgICAvKiBlbmFibGUg UENJIGludGVycnVwdCAqLworICAgIHBjaV93cml0ZV9jb25maWcoZGV2LCBQQ0lSX0NPTU1BTkQs CisJCSAgICAgcGNpX3JlYWRfY29uZmlnKGRldiwgUENJUl9DT01NQU5ELCAyKSAmIH4weDA0MDAs IDIpOworCisgICAgLyogYW5ub3VuY2Ugd2Ugc3VwcG9ydCB0aGUgSFcgKi8KKyAgICB2ZXJzaW9u ID0gQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1ZTKTsKKyAgICBkZXZpY2VfcHJpbnRm KGRldiwKKwkJICAiQUhDSSBWZXJzaW9uICV4JXguJXgleCBjb250cm9sbGVyIHdpdGggJWQgcG9y dHMgUE0gJXNcbiIsCisJCSAgKHZlcnNpb24gPj4gMjQpICYgMHhmZiwgKHZlcnNpb24gPj4gMTYp ICYgMHhmZiwKKwkJICAodmVyc2lvbiA+PiA4KSAmIDB4ZmYsIHZlcnNpb24gJiAweGZmLAorCQkg IChBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfQ0FQKSAmIEFUQV9BSENJX05QTUFTSykg KyAxLAorCQkgIChBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfQ0FQKSAmIEFUQV9BSENJ X0NBUF9TUE0pID8KKwkJICAic3VwcG9ydGVkIiA6ICJub3Qgc3VwcG9ydGVkIik7CisgICAgcmV0 dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQKK2F0YV9haGNpX2N0bHJfcmVzZXQoZGV2aWNlX3QgZGV2 KQoreworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisKICAgICAvKiBlbmFibGUgQUhDSSBtb2RlICovCiAgICAgQVRBX09VVEwoY3Rs ci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMsIEFUQV9BSENJX0dIQ19BRSk7CiAKQEAgLTUxMCwxMSAr NjU2LDYgQEAgYXRhX2FoY2lfY2hpcGluaXQoZGV2aWNlX3QgZGV2KQogICAgIC8qIHJlZW5hYmxl IEFIQ0kgbW9kZSAqLwogICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfR0hDLCBB VEFfQUhDSV9HSENfQUUpOwogCi0gICAgLyogZ2V0IHRoZSBudW1iZXIgb2YgSFcgY2hhbm5lbHMg Ki8KLSAgICBjdGxyLT5jaGFubmVscyA9Ci0JTUFYKGZsc2woQVRBX0lOTChjdGxyLT5yX3JlczIs IEFUQV9BSENJX1BJKSksIAotCSAgICAoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0NB UCkgJiBBVEFfQUhDSV9OUE1BU0spICsgMSk7Ci0KICAgICAvKiBjbGVhciBpbnRlcnJ1cHRzICov CiAgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9JUywgQVRBX0lOTChjdGxyLT5y X3JlczIsIEFUQV9BSENJX0lTKSk7CiAKQEAgLTUyMiwzMSArNjYzLDI2IEBAIGF0YV9haGNpX2No aXBpbml0KGRldmljZV90IGRldikKICAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJ X0dIQywKIAkgICAgIEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMpIHwgQVRBX0FI Q0lfR0hDX0lFKTsKIAotICAgIGN0bHItPnJlc2V0ID0gYXRhX2FoY2lfcmVzZXQ7Ci0gICAgY3Rs ci0+ZG1haW5pdCA9IGF0YV9haGNpX2RtYWluaXQ7Ci0gICAgY3Rsci0+YWxsb2NhdGUgPSBhdGFf YWhjaV9hbGxvY2F0ZTsKLSAgICBjdGxyLT5zZXRtb2RlID0gYXRhX3NhdGFfc2V0bW9kZTsKKyAg ICByZXR1cm4gMDsKK30KIAotICAgIC8qIGVuYWJsZSBQQ0kgaW50ZXJydXB0ICovCi0gICAgcGNp X3dyaXRlX2NvbmZpZyhkZXYsIFBDSVJfQ09NTUFORCwKLQkJICAgICBwY2lfcmVhZF9jb25maWco ZGV2LCBQQ0lSX0NPTU1BTkQsIDIpICYgfjB4MDQwMCwgMik7CitzdGF0aWMgaW50CithdGFfYWhj aV9zdXNwZW5kKGRldmljZV90IGRldikKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVy ICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogCi0gICAgLyogYW5ub3VuY2Ugd2Ugc3Vw cG9ydCB0aGUgSFcgKi8KLSAgICB2ZXJzaW9uID0gQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9B SENJX1ZTKTsKLSAgICBkZXZpY2VfcHJpbnRmKGRldiwKLQkJICAiQUhDSSBWZXJzaW9uICV4JXgu JXgleCBjb250cm9sbGVyIHdpdGggJWQgcG9ydHMgZGV0ZWN0ZWRcbiIsCi0JCSAgKHZlcnNpb24g Pj4gMjQpICYgMHhmZiwgKHZlcnNpb24gPj4gMTYpICYgMHhmZiwKLQkJICAodmVyc2lvbiA+PiA4 KSAmIDB4ZmYsIHZlcnNpb24gJiAweGZmLAotCQkgIChBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRB X0FIQ0lfQ0FQKSAmIEFUQV9BSENJX05QTUFTSykgKyAxKTsKKyAgICAvKiBkaXNhYmxlIGludGVy dXB0cyBzbyB0aGUgc3RhdGUgY2hhbmdlKHMpIGRvZXNuJ3QgdHJpZ2dlciAqLworICAgIEFUQV9P VVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfR0hDLAorICAgICAgICAgICAgIEFUQV9JTkwoY3Rs ci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMpICYgKH5BVEFfQUhDSV9HSENfSUUpKTsKICAgICByZXR1 cm4gMDsKIH0KIAorCiBzdGF0aWMgaW50CiBhdGFfYWhjaV9hbGxvY2F0ZShkZXZpY2VfdCBkZXYp CiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRfc29m dGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLSAgICB1X2ludDY0X3Qgd29yazsKICAgICBpbnQgb2Zm c2V0ID0gY2gtPnVuaXQgPDwgNzsKIAogICAgIC8qIHNldCB0aGUgU0FUQSByZXNvdXJjZXMgKi8K QEAgLTU2MywyOCArNjk5LDEwIEBAIGF0YV9haGNpX2FsbG9jYXRlKGRldmljZV90IGRldikKICAg ICBjaC0+aHcuYmVnaW5fdHJhbnNhY3Rpb24gPSBhdGFfYWhjaV9iZWdpbl90cmFuc2FjdGlvbjsK ICAgICBjaC0+aHcuZW5kX3RyYW5zYWN0aW9uID0gYXRhX2FoY2lfZW5kX3RyYW5zYWN0aW9uOwog ICAgIGNoLT5ody5jb21tYW5kID0gTlVMTDsgICAgICAvKiBub3QgdXNlZCBoZXJlICovCisgICAg Y2gtPmh3LnNvZnRyZXNldCA9IGF0YV9haGNpX3NvZnRyZXNldDsKKyAgICBjaC0+aHcucG1fcmVh ZCA9IGF0YV9haGNpX3BtX3JlYWQ7CisgICAgY2gtPmh3LnBtX3dyaXRlID0gYXRhX2FoY2lfcG1f d3JpdGU7CiAKLSAgICAvKiBzZXR1cCB3b3JrIGFyZWFzICovCi0gICAgd29yayA9IGNoLT5kbWEt PndvcmtfYnVzICsgQVRBX0FIQ0lfQ0xfT0ZGU0VUOwotICAgIEFUQV9PVVRMKGN0bHItPnJfcmVz MiwgQVRBX0FIQ0lfUF9DTEIgKyBvZmZzZXQsIHdvcmsgJiAweGZmZmZmZmZmKTsKLSAgICBBVEFf T1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ0xCVSArIG9mZnNldCwgd29yayA+PiAzMik7 Ci0KLSAgICB3b3JrID0gY2gtPmRtYS0+d29ya19idXMgKyBBVEFfQUhDSV9GQl9PRkZTRVQ7Ci0g ICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0ZCICsgb2Zmc2V0LCB3b3JrICYg MHhmZmZmZmZmZik7IAotICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9GQlUg KyBvZmZzZXQsIHdvcmsgPj4gMzIpOwotCi0gICAgLyogZW5hYmxlIHdhbnRlZCBwb3J0IGludGVy cnVwdHMgKi8KLSAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfSUUgKyBvZmZz ZXQsCi0JICAgICAoQVRBX0FIQ0lfUF9JWF9DUEQgfCBBVEFfQUhDSV9QX0lYX1RGRSB8IEFUQV9B SENJX1BfSVhfSEJGIHwKLQkgICAgICBBVEFfQUhDSV9QX0lYX0hCRCB8IEFUQV9BSENJX1BfSVhf SUYgfCBBVEFfQUhDSV9QX0lYX09GIHwKLQkgICAgICBBVEFfQUhDSV9QX0lYX1BSQyB8IEFUQV9B SENJX1BfSVhfUEMgfCBBVEFfQUhDSV9QX0lYX0RQIHwKLQkgICAgICBBVEFfQUhDSV9QX0lYX1VG IHwgQVRBX0FIQ0lfUF9JWF9TREIgfCBBVEFfQUhDSV9QX0lYX0RTIHwKLQkgICAgICBBVEFfQUhD SV9QX0lYX1BTIHwgQVRBX0FIQ0lfUF9JWF9ESFIpKTsKLQotICAgIC8qIHN0YXJ0IG9wZXJhdGlv bnMgb24gdGhpcyBjaGFubmVsICovCi0gICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhD SV9QX0NNRCArIG9mZnNldCwKLQkgICAgIChBVEFfQUhDSV9QX0NNRF9BQ1RJVkUgfCBBVEFfQUhD SV9QX0NNRF9GUkUgfAotCSAgICAgIEFUQV9BSENJX1BfQ01EX1BPRCB8IEFUQV9BSENJX1BfQ01E X1NVRCB8IEFUQV9BSENJX1BfQ01EX1NUKSk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTU5NSwy MiArNzEzLDI1IEBAIGF0YV9haGNpX3N0YXR1cyhkZXZpY2VfdCBkZXYpCiAgICAgc3RydWN0IGF0 YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKICAgICB1X2ludDMyX3QgYWN0 aW9uID0gQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0lTKTsKICAgICBpbnQgb2Zmc2V0 ID0gY2gtPnVuaXQgPDwgNzsKLSAgICBpbnQgdGFnID0gMDsKKworI2RlZmluZSBBVEFfQUhDSV9T VEFUQklUUyBcCisJKEFUQV9BSENJX1BfSVhfSUZ8QVRBX0FIQ0lfUF9JWF9IQkR8QVRBX0FIQ0lf UF9JWF9IQkZ8QVRBX0FIQ0lfUF9JWF9URkUpCiAKICAgICBpZiAoYWN0aW9uICYgKDEgPDwgY2gt PnVuaXQpKSB7CiAJdV9pbnQzMl90IGlzdGF0dXMgPSBBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRB X0FIQ0lfUF9JUyArIG9mZnNldCk7CiAJdV9pbnQzMl90IGNzdGF0dXMgPSBBVEFfSU5MKGN0bHIt PnJfcmVzMiwgQVRBX0FIQ0lfUF9DSSArIG9mZnNldCk7CiAKIAkvKiBjbGVhciBpbnRlcnJ1cHQo cykgKi8KLQlBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0lTLCBhY3Rpb24gJiAoMSA8 PCBjaC0+dW5pdCkpOwogCUFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9JUyArIG9m ZnNldCwgaXN0YXR1cyk7CisJQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9JUywgYWN0 aW9uICYgKDEgPDwgY2gtPnVuaXQpKTsKIAogCS8qIGRvIHdlIGhhdmUgYW55IFBIWSBldmVudHMg PyAqLwotCS8qIFhYWCBTT1MgY2hlY2sgaXN0YXR1cyBwaHkgYml0cyAqLwotCWF0YV9zYXRhX3Bo eV9jaGVja19ldmVudHMoZGV2KTsKKwlpZiAoaXN0YXR1cyAmIChBVEFfQUhDSV9QX0lYX1BSQyB8 IEFUQV9BSENJX1BfSVhfUEMpKQorCSAgICBhdGFfc2F0YV9waHlfY2hlY2tfZXZlbnRzKGRldik7 CiAKIAkvKiBkbyB3ZSBoYXZlIGEgcG90ZW50aWFsbHkgaGFuZ2luZyBlbmdpbmUgdG8gdGFrZSBj YXJlIG9mPyAqLwotCWlmICgoaXN0YXR1cyAmIDB4Nzg0MDAwNTApICYmIChjc3RhdHVzICYgKDEg PDwgdGFnKSkpIHsKKwkvKiBYWFggU09TIHdoYXQgdG9kbyBvbiBOQ1EgKi8KKwlpZiAoKGlzdGF0 dXMgJiBBVEFfQUhDSV9TVEFUQklUUykgJiYgKGNzdGF0dXMgJiAxKSkgewogCiAJICAgIHVfaW50 MzJfdCBjbWQgPSBBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQp OwogCSAgICBpbnQgdGltZW91dCA9IDA7CkBAIC02MjIsNyArNzQzLDcgQEAgYXRhX2FoY2lfc3Rh dHVzKGRldmljZV90IGRldikKIAkgICAgLyogWFhYIFNPUyB0aGlzIGlzIG5vdCBlbnRpcmVseSB3 cm9uZyAqLwogCSAgICBkbyB7CiAJCURFTEFZKDEwMDApOwotCQlpZiAodGltZW91dCsrID4gNTAw KSB7CisJCWlmICh0aW1lb3V0KysgPiAxMDAwKSB7CiAJCSAgICBkZXZpY2VfcHJpbnRmKGRldiwg InN0b3BwaW5nIEFIQ0kgZW5naW5lIGZhaWxlZFxuIik7CiAJCSAgICBicmVhazsKIAkJfQpAQCAt NjM2LDcgKzc1Nyw4IEBAIGF0YV9haGNpX3N0YXR1cyhkZXZpY2VfdCBkZXYpCiAJICAgIHJldHVy biAxOwogCX0KIAllbHNlCi0JICAgIHJldHVybiAoIShjc3RhdHVzICYgKDEgPDwgdGFnKSkpOwor CSAgICAvKiBYWFggU09TIHdoYXQgdG9kbyBvbiBOQ1EgKi8KKwkgICAgcmV0dXJuICghKGNzdGF0 dXMgJiAxKSk7CiAgICAgfQogICAgIHJldHVybiAwOwogfQpAQCAtNjQ2LDE2ICs3NjgsMTggQEAg c3RhdGljIGludAogYXRhX2FoY2lfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZXF1ZXN0 ICpyZXF1ZXN0KQogewogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHI9ZGV2aWNl X2dldF9zb2Z0YyhHUkFORFBBUkVOVChyZXF1ZXN0LT5kZXYpKTsKLSAgICBzdHJ1Y3QgYXRhX2No YW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChyZXF1ZXN0LT5k ZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1 ZXN0LT5wYXJlbnQpOworICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0 X3NvZnRjKHJlcXVlc3QtPmRldik7CiAgICAgc3RydWN0IGF0YV9haGNpX2NtZF90YWIgKmN0cDsK ICAgICBzdHJ1Y3QgYXRhX2FoY2lfY21kX2xpc3QgKmNscDsKICAgICBpbnQgb2Zmc2V0ID0gY2gt PnVuaXQgPDwgNzsKLSAgICBpbnQgdGFnID0gMCwgZW50cmllcyA9IDA7CisgICAgaW50IHBvcnQg PSBhdGFkZXYtPnVuaXQgJiAweDBmOworICAgIGludCBlbnRyaWVzID0gMDsKICAgICBpbnQgZmlz X3NpemU7CiAJCiAgICAgLyogZ2V0IGEgcGllY2Ugb2YgdGhlIHdvcmtzcGFjZSBmb3IgdGhpcyBy ZXF1ZXN0ICovCiAgICAgY3RwID0gKHN0cnVjdCBhdGFfYWhjaV9jbWRfdGFiICopCi0JICAoY2gt PmRtYS0+d29yayArIEFUQV9BSENJX0NUX09GRlNFVCArIChBVEFfQUhDSV9DVF9TSVpFICogdGFn KSk7CisJICAoY2gtPmRtYS53b3JrICsgQVRBX0FIQ0lfQ1RfT0ZGU0VUICsgKEFUQV9BSENJX0NU X1NJWkUqcmVxdWVzdC0+dGFnKSk7CiAKICAgICAvKiBzZXR1cCB0aGUgRklTIGZvciB0aGlzIHJl cXVlc3QgKi8KICAgICBpZiAoIShmaXNfc2l6ZSA9IGF0YV9haGNpX3NldHVwX2ZpcyhjdHAsIHJl cXVlc3QpKSkgewpAQCAtNjY2LDkgKzc5MCw3IEBAIGF0YV9haGNpX2JlZ2luX3RyYW5zYWN0aW9u KHN0cnVjdCBhdGFfcmUKIAogICAgIC8qIGlmIHJlcXVlc3QgbW92ZXMgZGF0YSBzZXR1cCBhbmQg bG9hZCBTRyBsaXN0ICovCiAgICAgaWYgKHJlcXVlc3QtPmZsYWdzICYgKEFUQV9SX1JFQUQgfCBB VEFfUl9XUklURSkpIHsKLQlpZiAoY2gtPmRtYS0+bG9hZChjaC0+ZGV2LCByZXF1ZXN0LT5kYXRh LCByZXF1ZXN0LT5ieXRlY291bnQsCi0JCQkgIHJlcXVlc3QtPmZsYWdzICYgQVRBX1JfUkVBRCwK LQkJCSAgY3RwLT5wcmRfdGFiLCAmZW50cmllcykpIHsKKwlpZiAoY2gtPmRtYS5sb2FkKHJlcXVl c3QsIGN0cC0+cHJkX3RhYiwgJmVudHJpZXMpKSB7CiAJICAgIGRldmljZV9wcmludGYocmVxdWVz dC0+ZGV2LCAic2V0dGluZyB1cCBETUEgZmFpbGVkXG4iKTsKIAkgICAgcmVxdWVzdC0+cmVzdWx0 ID0gRUlPOwogCSAgICByZXR1cm4gQVRBX09QX0ZJTklTSEVEOwpAQCAtNjc3LDE4ICs3OTksMjEg QEAgYXRhX2FoY2lfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZQogCiAgICAgLyogc2V0 dXAgdGhlIGNvbW1hbmQgbGlzdCBlbnRyeSAqLwogICAgIGNscCA9IChzdHJ1Y3QgYXRhX2FoY2lf Y21kX2xpc3QgKikKLQkgIChjaC0+ZG1hLT53b3JrICsgQVRBX0FIQ0lfQ0xfT0ZGU0VUICsgKEFU QV9BSENJX0NMX1NJWkUgKiB0YWcpKTsKKwkgIChjaC0+ZG1hLndvcmsgKyBBVEFfQUhDSV9DTF9P RkZTRVQgKyAoQVRBX0FIQ0lfQ0xfU0laRSpyZXF1ZXN0LT50YWcpKTsKIAogICAgIGNscC0+cHJk X2xlbmd0aCA9IGVudHJpZXM7Ci0gICAgY2xwLT5jbWRfZmxhZ3MgPSAocmVxdWVzdC0+ZmxhZ3Mg JiBBVEFfUl9XUklURSA/ICgxPDw2KSA6IDApIHwKLQkJICAgICAocmVxdWVzdC0+ZmxhZ3MgJiBB VEFfUl9BVEFQSSA/ICgoMTw8NSkgfCAoMTw8NykpIDogMCkgfAotCQkgICAgIChmaXNfc2l6ZSAv IHNpemVvZih1X2ludDMyX3QpKTsKKyAgICBjbHAtPmNtZF9mbGFncyA9IChyZXF1ZXN0LT5mbGFn cyAmIEFUQV9SX1dSSVRFID8gQVRBX0FIQ0lfQ01EX1dSSVRFIDogMCkgfAorCQkgICAgIChyZXF1 ZXN0LT5mbGFncyAmIEFUQV9SX0FUQVBJID8KKwkJICAgICAgKEFUQV9BSENJX0NNRF9BVEFQSSB8 IEFUQV9BSENJX0NNRF9QUkVGRVRDSCkgOiAwKSB8CisJCSAgICAgKGZpc19zaXplIC8gc2l6ZW9m KHVfaW50MzJfdCkpIHwKKyAgICAJCSAgICAgKHBvcnQgPDwgMTIpOwogICAgIGNscC0+Ynl0ZWNv dW50ID0gMDsKLSAgICBjbHAtPmNtZF90YWJsZV9waHlzID0gaHRvbGU2NChjaC0+ZG1hLT53b3Jr X2J1cyArIEFUQV9BSENJX0NUX09GRlNFVCArCi0JCQkJICAoQVRBX0FIQ0lfQ1RfU0laRSAqIHRh ZykpOworICAgIGNscC0+Y21kX3RhYmxlX3BoeXMgPSBodG9sZTY0KGNoLT5kbWEud29ya19idXMg KyBBVEFfQUhDSV9DVF9PRkZTRVQgKworCQkJCSAgKEFUQV9BSENJX0NUX1NJWkUgKiByZXF1ZXN0 LT50YWcpKTsKIAogICAgIC8qIGNsZWFyIGV2ZW50dWFsIEFDVElWRSBiaXQgKi8KLSAgICBBVEFf SURYX09VVEwoY2gsIEFUQV9TQUNUSVZFLCBBVEFfSURYX0lOTChjaCwgQVRBX1NBQ1RJVkUpICYg KDEgPDwgdGFnKSk7CisgICAgQVRBX0lEWF9PVVRMKGNoLCBBVEFfU0FDVElWRSwKKwkJIEFUQV9J RFhfSU5MKGNoLCBBVEFfU0FDVElWRSkgJiAoMSA8PCByZXF1ZXN0LT50YWcpKTsKIAogICAgIC8q IHNldCBjb21tYW5kIHR5cGUgYml0ICovCiAgICAgaWYgKHJlcXVlc3QtPmZsYWdzICYgQVRBX1Jf QVRBUEkpCkBAIC03MDAsOCArODI1LDExIEBAIGF0YV9haGNpX2JlZ2luX3RyYW5zYWN0aW9uKHN0 cnVjdCBhdGFfcmUKIAkJIEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9m ZnNldCkgJgogCQkgfkFUQV9BSENJX1BfQ01EX0FUQVBJKTsKIAorICAgIC8qIHNldCBQTSBwb3J0 IHRvIGFkZHJlc3MgKi8KKyAgICAvL0FUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9G QlMgKyBvZmZzZXQsIChwb3J0IDw8IDgpIHwgMHgwMDAwMDAwMSk7CisKICAgICAvKiBpc3N1ZSBj b21tYW5kIHRvIGNvbnRyb2xsZXIgKi8KLSAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9B SENJX1BfQ0kgKyBvZmZzZXQsICgxIDw8IHRhZykpOworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVz MiwgQVRBX0FIQ0lfUF9DSSArIG9mZnNldCwgKDEgPDwgcmVxdWVzdC0+dGFnKSk7CiAgICAgCiAg ICAgaWYgKCEocmVxdWVzdC0+ZmxhZ3MgJiBBVEFfUl9BVEFQSSkpIHsKIAkvKiBkZXZpY2UgcmVz ZXQgZG9lc24ndCBpbnRlcnJ1cHQgKi8KQEAgLTczNCwxMSArODYyLDEwIEBAIHN0YXRpYyBpbnQK IGF0YV9haGNpX2VuZF90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiB7 CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3Rscj1kZXZpY2VfZ2V0X3NvZnRjKEdS QU5EUEFSRU5UKHJlcXVlc3QtPmRldikpOwotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBk ZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3QtPmRldikpOworICAgIHN0 cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7 CiAgICAgc3RydWN0IGF0YV9haGNpX2NtZF9saXN0ICpjbHA7CiAgICAgdV9pbnQzMl90IHRmX2Rh dGE7CiAgICAgaW50IG9mZnNldCA9IGNoLT51bml0IDw8IDc7Ci0gICAgaW50IHRhZyA9IDA7CiAK ICAgICAvKiBraWxsIHRoZSB0aW1lb3V0ICovCiAgICAgY2FsbG91dF9zdG9wKCZyZXF1ZXN0LT5j YWxsb3V0KTsKQEAgLTc1MSwzMSArODc4LDE0MCBAQCBhdGFfYWhjaV9lbmRfdHJhbnNhY3Rpb24o c3RydWN0IGF0YV9yZXF1CiAgICAgaWYgKHJlcXVlc3QtPnN0YXR1cyAmIEFUQV9TX0VSUk9SKSAg CiAJcmVxdWVzdC0+ZXJyb3IgPSB0Zl9kYXRhID4+IDg7CiAKKyAgICAvKiBvbiBjb250cm9sIGNv bW1hbmRzIHJlYWQgYmFjayByZWdpc3RlcnMgdG8gdGhlIHJlcXVlc3Qgc3RydWN0ICovCisgICAg aWYgKHJlcXVlc3QtPmZsYWdzICYgQVRBX1JfQ09OVFJPTCkgeworCXN0cnVjdCBhdGFfZGV2aWNl ICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPmRldik7CisJdV9pbnQ4X3QgKmZp cyA9IGNoLT5kbWEud29yayArIEFUQV9BSENJX0ZCX09GRlNFVCArIDB4NDA7CisKKwlyZXF1ZXN0 LT51LmF0YS5jb3VudCA9IGZpc1sxMl0gfCAoKHVfaW50MTZfdClmaXNbMTNdIDw8IDgpOworCXJl cXVlc3QtPnUuYXRhLmxiYSA9IGZpc1s0XSB8ICgodV9pbnQ2NF90KWZpc1s1XSA8PCA4KSB8CisJ CQkgICAgICgodV9pbnQ2NF90KWZpc1s2XSA8PCAxNik7CisJaWYgKGF0YWRldi0+ZmxhZ3MgJiBB VEFfRF80OEJJVF9BQ1RJVkUpCisJICAgIHJlcXVlc3QtPnUuYXRhLmxiYSB8PSAoKHVfaW50NjRf dClmaXNbOF0gPDwgMjQpIHwKKwkJCQkgICgodV9pbnQ2NF90KWZpc1s5XSA8PCAzMikgfAorCQkJ CSAgKCh1X2ludDY0X3QpZmlzWzEwXSA8PCA0MCk7CisJZWxzZQorCSAgICByZXF1ZXN0LT51LmF0 YS5sYmEgfD0gKCh1X2ludDY0X3QpKGZpc1s3XSAmIDB4MGYpIDw8IDI0KTsKKyAgICB9CisKICAg ICAvKiByZWNvcmQgaG93IG11Y2ggZGF0YSB3ZSBhY3R1YWxseSBtb3ZlZCAqLwogICAgIGNscCA9 IChzdHJ1Y3QgYXRhX2FoY2lfY21kX2xpc3QgKikKLQkgIChjaC0+ZG1hLT53b3JrICsgQVRBX0FI Q0lfQ0xfT0ZGU0VUICsgKEFUQV9BSENJX0NMX1NJWkUgKiB0YWcpKTsKKwkgIChjaC0+ZG1hLndv cmsgKyBBVEFfQUhDSV9DTF9PRkZTRVQgKyAoQVRBX0FIQ0lfQ0xfU0laRSpyZXF1ZXN0LT50YWcp KTsKICAgICByZXF1ZXN0LT5kb25lY291bnQgPSBjbHAtPmJ5dGVjb3VudDsKIAogICAgIC8qIHJl bGVhc2UgU0cgbGlzdCBldGMgKi8KLSAgICBjaC0+ZG1hLT51bmxvYWQoY2gtPmRldik7CisgICAg Y2gtPmRtYS51bmxvYWQocmVxdWVzdCk7CiAKICAgICByZXR1cm4gQVRBX09QX0ZJTklTSEVEOwog fQogCi1zdGF0aWMgdm9pZAotYXRhX2FoY2lfcmVzZXQoZGV2aWNlX3QgZGV2KQorc3RhdGljIGlu dAorYXRhX2FoY2lfaXNzdWVfY21kKGRldmljZV90IGRldiwgdV9pbnQxNl90IGZsYWdzLCBpbnQg dGltZW91dCkKIHsKICAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNl X2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKICAgICBzdHJ1Y3QgYXRhX2NoYW5u ZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwotICAgIHVfaW50MzJfdCBjbWQsIHNpZ25h dHVyZTsKKyAgICBzdHJ1Y3QgYXRhX2FoY2lfY21kX2xpc3QgKmNscCA9CisJKHN0cnVjdCBhdGFf YWhjaV9jbWRfbGlzdCAqKShjaC0+ZG1hLndvcmsgKyBBVEFfQUhDSV9DTF9PRkZTRVQpOworICAg IHN0cnVjdCBhdGFfYWhjaV9jbWRfdGFiICpjdHAgPQorCShzdHJ1Y3QgYXRhX2FoY2lfY21kX3Rh YiAqKShjaC0+ZG1hLndvcmsgKyBBVEFfQUhDSV9DVF9PRkZTRVQpOworICAgIHVfaW50MzJfdCBz dGF0dXMgPSAwOwogICAgIGludCBvZmZzZXQgPSBjaC0+dW5pdCA8PCA3OwotICAgIGludCB0aW1l b3V0OworICAgIGludCBwb3J0ID0gKGN0cC0+Y2Zpc1sxXSAmIDB4MGYpOworICAgIGludCBjb3Vu dDsKIAotICAgIGlmICghKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QSSkgJiAoMSA8 PCBjaC0+dW5pdCkpKSB7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJwb3J0IG5vdCBpbXBsZW1lbnRl ZFxuIik7Ci0JcmV0dXJuOworICAgIGNscC0+cHJkX2xlbmd0aCA9IDA7CisgICAgY2xwLT5jbWRf ZmxhZ3MgPSAoMjAgLyBzaXplb2YodV9pbnQzMl90KSkgfCBmbGFncyB8IChwb3J0IDw8IDEyKTsK KyAgICBjbHAtPmJ5dGVjb3VudCA9IDA7CisgICAgY2xwLT5jbWRfdGFibGVfcGh5cyA9IGh0b2xl NjQoY2gtPmRtYS53b3JrX2J1cyArIEFUQV9BSENJX0NUX09GRlNFVCk7CisKKyAgICAvKiBzZXQg UE0gcG9ydCAqLworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9GQlMgKyBv ZmZzZXQsIChwb3J0IDw8IDgpIHwgMHgwMDAwMDAwMSk7CisKKyAgICAvKiBpc3N1ZSBjb21tYW5k IHRvIGNvbnRyb2xsZXIgKi8KKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1Bf Q0kgKyBvZmZzZXQsIDEpOworCisgICAgLyogcG9sbCBmb3IgY29tbWFuZCBmaW5pc2hlZCAqLwor ICAgIGZvciAoY291bnQgPSAwOyBjb3VudCA8IHRpbWVvdXQ7IGNvdW50KyspIHsKKyAgICAgICAg REVMQVkoMTAwMCk7CisgICAgICAgIGlmICghKChzdGF0dXMgPSBBVEFfSU5MKGN0bHItPnJfcmVz MiwgQVRBX0FIQ0lfUF9DSSArIG9mZnNldCkpICYgMSkpCisgICAgICAgICAgICBicmVhazsKKyAg ICB9CisKKyAgICAvKiBjbGVhciBpbnRlcnJ1cHRzICovCisgICAgQVRBX09VVEwoY3Rsci0+cl9y ZXMyLCBBVEFfQUhDSV9QX0lTICsgb2Zmc2V0LAorCSAgICAgQVRBX0lOTChjdGxyLT5yX3JlczIs IEFUQV9BSENJX1BfSVMgKyBvZmZzZXQpKTsKKworICAgIGlmIChib290dmVyYm9zZSkKKwlkZXZp Y2VfcHJpbnRmKGRldiwgImFoY2lfaXNzdWVfY21kIHRpbWU9JWRtcyBjbnQ9JWRtcyBzdGF0dXM9 JTA4eFxuIiwKKwkJICAgICAgdGltZW91dCwgY291bnQsIHN0YXR1cyk7CisgICAgaWYgKHRpbWVv dXQgJiYgKGNvdW50ID49IHRpbWVvdXQpKQorCXJldHVybiBFSU87CisKKyAgICByZXR1cm4gMDsK K30KKworc3RhdGljIGludAorYXRhX2FoY2lfcG1fcmVhZChkZXZpY2VfdCBkZXYsIGludCBwb3J0 LCBpbnQgcmVnLCB1X2ludDMyX3QgKnJlc3VsdCkKK3sKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwg KmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIHN0cnVjdCBhdGFfYWhjaV9jbWRfdGFi ICpjdHAgPQorCShzdHJ1Y3QgYXRhX2FoY2lfY21kX3RhYiAqKShjaC0+ZG1hLndvcmsgKyBBVEFf QUhDSV9DVF9PRkZTRVQpOworICAgIHVfaW50OF90ICpmaXMgPSBjaC0+ZG1hLndvcmsgKyBBVEFf QUhDSV9GQl9PRkZTRVQgKyAweDQwOworCisgICAgYnplcm8oY3RwLT5jZmlzLCA2NCk7CisgICAg Y3RwLT5jZmlzWzBdID0gMHgyNzsJLyogaG9zdCB0byBkZXZpY2UgKi8KKyAgICBjdHAtPmNmaXNb MV0gPSAweDhmOwkvKiBjb21tYW5kIEZJUyB0byBQTSBwb3J0ICovCisgICAgY3RwLT5jZmlzWzJd ID0gQVRBX1JFQURfUE07CisgICAgY3RwLT5jZmlzWzNdID0gcmVnOworICAgIGN0cC0+Y2Zpc1s3 XSA9IHBvcnQgfCBBVEFfRF9MQkE7CisgICAgY3RwLT5jZmlzWzE1XSA9IEFUQV9BXzRCSVQ7CisK KyAgICBpZiAoYXRhX2FoY2lfaXNzdWVfY21kKGRldiwgMCwgMTApKSB7CisJZGV2aWNlX3ByaW50 ZihkZXYsICJlcnJvciByZWFkaW5nIFBNIHBvcnRcbiIpOworCXJldHVybiBFSU87CiAgICAgfQot ICAgIGNoLT5kZXZpY2VzID0gMDsKKworICAgICpyZXN1bHQgPSBmaXNbMTJdIHwgKGZpc1s0XSA8 PCA4KSB8IChmaXNbNV0gPDwgMTYpIHwgKGZpc1s2XSA8PCAyNCk7CisgICAgcmV0dXJuIDA7Cit9 CisKK3N0YXRpYyBpbnQKK2F0YV9haGNpX3BtX3dyaXRlKGRldmljZV90IGRldiwgaW50IHBvcnQs IGludCByZWcsIHVfaW50MzJfdCB2YWx1ZSkKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9s bGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKKyAg ICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIHN0 cnVjdCBhdGFfYWhjaV9jbWRfdGFiICpjdHAgPQorCShzdHJ1Y3QgYXRhX2FoY2lfY21kX3RhYiAq KShjaC0+ZG1hLndvcmsgKyBBVEFfQUhDSV9DVF9PRkZTRVQpOworICAgIGludCBvZmZzZXQgPSBj aC0+dW5pdCA8PCA3OworCisgICAgYnplcm8oY3RwLT5jZmlzLCA2NCk7CisgICAgY3RwLT5jZmlz WzBdID0gMHgyNzsJLyogaG9zdCB0byBkZXZpY2UgKi8KKyAgICBjdHAtPmNmaXNbMV0gPSAweDhm OwkvKiBjb21tYW5kIEZJUyB0byBQTSBwb3J0ICovCisgICAgY3RwLT5jZmlzWzJdID0gQVRBX1dS SVRFX1BNOworICAgIGN0cC0+Y2Zpc1szXSA9IHJlZzsKKyAgICBjdHAtPmNmaXNbN10gPSBwb3J0 IHwgQVRBX0RfTEJBOworICAgIGN0cC0+Y2Zpc1sxMl0gPSB2YWx1ZSAmIDB4ZmY7CisgICAgY3Rw LT5jZmlzWzRdID0gKHZhbHVlID4+IDgpICYgMHhmZjs7CisgICAgY3RwLT5jZmlzWzVdID0gKHZh bHVlID4+IDE2KSAmIDB4ZmY7OworICAgIGN0cC0+Y2Zpc1s2XSA9ICh2YWx1ZSA+PiAyNCkgJiAw eGZmOzsKKyAgICBjdHAtPmNmaXNbMTVdID0gQVRBX0FfNEJJVDsKKworICAgIGlmIChhdGFfYWhj aV9pc3N1ZV9jbWQoZGV2LCAwLCAxMDApKSB7CisJZGV2aWNlX3ByaW50ZihkZXYsICJlcnJvciB3 cml0aW5nIFBNIHBvcnRcbiIpOworCXJldHVybiBBVEFfRV9BQk9SVDsKKyAgICB9CisKKyAgICBy ZXR1cm4gKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX1RGRCArIG9mZnNldCkgPj4g OCkgJiAweGZmOworfQorCitzdGF0aWMgdm9pZAorYXRhX2FoY2lfcmVzdGFydChkZXZpY2VfdCBk ZXYpCit7CisgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRf c29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICB1X2ludDMyX3QgY21kOworICAgIGludCBv ZmZzZXQgPSBjaC0+dW5pdCA8PCA3OworICAgIGludCB0aW1lb3V0OwogCiAgICAgLyoga2lsbCBv ZmYgYWxsIGFjdGl2aXR5IG9uIHRoaXMgY2hhbm5lbCAqLwogICAgIGNtZCA9IEFUQV9JTkwoY3Rs ci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCk7CkBAIC03ODYsNyArMTAyMiw3IEBA IGF0YV9haGNpX3Jlc2V0KGRldmljZV90IGRldikKICAgICB0aW1lb3V0ID0gMDsKICAgICBkbyB7 CiAJREVMQVkoMTAwMCk7Ci0JaWYgKHRpbWVvdXQrKyA+IDUwMCkgeworCWlmICh0aW1lb3V0Kysg PiAxMDAwKSB7CiAJICAgIGRldmljZV9wcmludGYoZGV2LCAic3RvcHBpbmcgQUhDSSBlbmdpbmUg ZmFpbGVkXG4iKTsKIAkgICAgYnJlYWs7CiAJfQpAQCAtODAxLDcgKzEwMzcsNyBAQCBhdGFfYWhj aV9yZXNldChkZXZpY2VfdCBkZXYpCiAJdGltZW91dCA9IDA7CiAJZG8gewogCSAgICBERUxBWSgx MDAwKTsKLQkgICAgaWYgKHRpbWVvdXQrKyA+IDUwMCkgeworCSAgICBpZiAodGltZW91dCsrID4g MTAwMCkgewogCQlkZXZpY2VfcHJpbnRmKGRldiwgImV4ZWN1dGluZyBDTE8gZmFpbGVkXG4iKTsK IAkJYnJlYWs7CiAJICAgIH0KQEAgLTgwOSw0NSArMTA0NSwxNTEgQEAgYXRhX2FoY2lfcmVzZXQo ZGV2aWNlX3QgZGV2KQogCXdoaWxlIChBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9D TUQrb2Zmc2V0KSZBVEFfQUhDSV9QX0NNRF9DTE8pOwogICAgIH0KIAotICAgIC8qIHJlc2V0IFBI WSBhbmQgZGVjaWRlIHdoYXQgaXMgcHJlc2VudCAqLwotICAgIGlmIChhdGFfc2F0YV9waHlfcmVz ZXQoZGV2KSkgeworICAgIC8qIGNsZWFyIFNBVEEgZXJyb3IgcmVnaXN0ZXIgKi8KKyAgICBBVEFf SURYX09VVEwoY2gsIEFUQV9TRVJST1IsIEFUQV9JRFhfSU5MKGNoLCBBVEFfU0VSUk9SKSk7CisK KyAgICAvKiBjbGVhciBhbnkgaW50ZXJydXB0cyBwZW5kaW5nIG9uIHRoaXMgY2hhbm5lbCAqLwor ICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9JUyArIG9mZnNldCwKKwkgICAg IEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0lTICsgb2Zmc2V0KSk7CisKKyAgICAv KiBzdGFydCBvcGVyYXRpb25zIG9uIHRoaXMgY2hhbm5lbCAqLworICAgIGNtZCA9IEFUQV9JTkwo Y3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCk7CisgICAgQVRBX09VVEwoY3Rs ci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCwKKwkgICAgIGNtZCB8IChBVEFfQUhD SV9QX0NNRF9GUkUgfCBBVEFfQUhDSV9QX0NNRF9TVCkgfAorCSAgICAgKGNoLT5kZXZpY2VzICYg QVRBX1BPUlRNVUxUSVBMSUVSID8gQVRBX0FIQ0lfUF9DTURfUE1BIDogMCkpOworfQorCitzdGF0 aWMgdV9pbnQzMl90CithdGFfYWhjaV9zb2Z0cmVzZXQoZGV2aWNlX3QgZGV2LCBpbnQgcG9ydCkK K3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIGludCBvZmZzZXQgPSBjaC0+dW5pdCA8PCA3Owor ICAgIGludCB0aW1lb3V0ID0gMDsKKyNpZmRlZiBBSENJX1BNCisgICAgc3RydWN0IGF0YV9haGNp X2NtZF90YWIgKmN0cCA9CisJKHN0cnVjdCBhdGFfYWhjaV9jbWRfdGFiICopKGNoLT5kbWEud29y ayArIEFUQV9BSENJX0NUX09GRlNFVCk7CisKKyAgICAvKiBraWNrIGNvbnRyb2xsZXIgaW50byBz YW5lIHN0YXRlIGlmIG5lZWRlZCAqLworICAgIGF0YV9haGNpX3Jlc3RhcnQoZGV2KTsKKworICAg IC8qIHB1bGwgcmVzZXQgYWN0aXZlICovCisgICAgYnplcm8oY3RwLT5jZmlzLCA2NCk7CisgICAg Y3RwLT5jZmlzWzBdID0gMHgyNzsKKyAgICBjdHAtPmNmaXNbMV0gPSBwb3J0ICYgMHgwZjsKKyAg ICAvL2N0cC0+Y2Zpc1s3XSA9IEFUQV9EX0xCQSB8IEFUQV9EX0lCTTsKKyAgICBjdHAtPmNmaXNb MTVdID0gKEFUQV9BXzRCSVQgfCBBVEFfQV9SRVNFVCk7CisKKyAgICBpZiAoYXRhX2FoY2lfaXNz dWVfY21kKGRldiwgQVRBX0FIQ0lfQ01EX1JFU0VUIHwgQVRBX0FIQ0lfQ01EX0NMUl9CVVNZLDEw MCkpCisJZGV2aWNlX3ByaW50ZihkZXYsICJzZXR0aW5nIFNSU1QgZmFpbGVkID8/XG4iKTsKKwkv L3JldHVybiAtMTsKIAotCS8qIGNsZWFyIGFueSBpbnRlcnJ1cHRzIHBlbmRpbmcgb24gdGhpcyBj aGFubmVsICovCi0JQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0lTICsgb2Zmc2V0 LAotCQkgQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfSVMgKyBvZmZzZXQpKTsKKyAg ICBhdGFfdWRlbGF5KDUwMDApOwogCi0JLyogY2xlYXIgU0FUQSBlcnJvciByZWdpc3RlciAqLwot CUFUQV9JRFhfT1VUTChjaCwgQVRBX1NFUlJPUiwgQVRBX0lEWF9JTkwoY2gsIEFUQV9TRVJST1Ip KTsKKyAgICAvKiBwdWxsIHJlc2V0IGluYWN0aXZlIC0+IGRldmljZSBzb2Z0cmVzZXQgKi8KKyAg ICBiemVybyhjdHAtPmNmaXMsIDY0KTsKKyAgICBjdHAtPmNmaXNbMF0gPSAweDI3OworICAgIGN0 cC0+Y2Zpc1sxXSA9IHBvcnQgJiAweDBmOworICAgIC8vY3RwLT5jZmlzWzddID0gQVRBX0RfTEJB IHwgQVRBX0RfSUJNOworICAgIGN0cC0+Y2Zpc1sxNV0gPSBBVEFfQV80QklUOworICAgIGlmIChh dGFfYWhjaV9pc3N1ZV9jbWQoZGV2LCAwLCAwKSkKKwlyZXR1cm4gLTE7CisKKyAgICBhdGFfdWRl bGF5KDE1MDAwMCk7CisKKyNlbmRpZgorICAgIGRvIHsKKwkgICAgREVMQVkoMTAwMCk7CisJICAg IGlmICh0aW1lb3V0KysgPiAxMDAwKSB7CisJCWRldmljZV9wcmludGYoZGV2LCAic3RpbGwgQlVT WSBhZnRlciBzb2Z0cmVzZXRcbiIpOworCQlicmVhazsKKwkgICAgfQorICAgIH0gd2hpbGUgKEFU QV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX1RGRCArIG9mZnNldCkgJiBBVEFfU19CVVNZ KTsKKyAgICBpZiAoYm9vdHZlcmJvc2UpCisJZGV2aWNlX3ByaW50ZihkZXYsICJCVVNZIHdhaXQg dGltZT0lZG1zXG4iLCB0aW1lb3V0KTsKIAotCS8qIHN0YXJ0IG9wZXJhdGlvbnMgb24gdGhpcyBj aGFubmVsICovCisgICAgcmV0dXJuIEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX1NJ RyArIG9mZnNldCk7Cit9CisKK3N0YXRpYyB2b2lkCithdGFfYWhjaV9yZXNldChkZXZpY2VfdCBk ZXYpCit7CisgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRf c29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICB1X2ludDY0X3Qgd29yazsKKyAgICB1X2lu dDMyX3QgY21kLCBzaWduYXR1cmU7CisgICAgaW50IG9mZnNldCA9IGNoLT51bml0IDw8IDc7CisK KyAgICBpZiAoIShBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUEkpICYgKDEgPDwgY2gt PnVuaXQpKSkgeworCWRldmljZV9wcmludGYoZGV2LCAicG9ydCBub3QgaW1wbGVtZW50ZWRcbiIp OworCXJldHVybjsKKyAgICB9CisKKyAgICAvKiBzZXR1cCB3b3JrIGFyZWFzICovCisgICAgd29y ayA9IGNoLT5kbWEud29ya19idXMgKyBBVEFfQUhDSV9DTF9PRkZTRVQ7CisgICAgQVRBX09VVEwo Y3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NMQiArIG9mZnNldCwgd29yayAmIDB4ZmZmZmZmZmYp OworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTEJVICsgb2Zmc2V0LCB3 b3JrID4+IDMyKTsKKworICAgIHdvcmsgPSBjaC0+ZG1hLndvcmtfYnVzICsgQVRBX0FIQ0lfRkJf T0ZGU0VUOworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9GQiArIG9mZnNl dCwgd29yayAmIDB4ZmZmZmZmZmYpOyAKKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9B SENJX1BfRkJVICsgb2Zmc2V0LCB3b3JrID4+IDMyKTsKKworICAgIC8qIGVuYWJsZSB3YW50ZWQg cG9ydCBpbnRlcnJ1cHRzICovCisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9Q X0lFICsgb2Zmc2V0LAorCSAgICAgKEFUQV9BSENJX1BfSVhfQ1BEIHwgQVRBX0FIQ0lfUF9JWF9U RkUgfCBBVEFfQUhDSV9QX0lYX0hCRiB8CisJICAgICAgQVRBX0FIQ0lfUF9JWF9IQkQgfCBBVEFf QUhDSV9QX0lYX0lGIHwgQVRBX0FIQ0lfUF9JWF9PRiB8CisJICAgICAgQVRBX0FIQ0lfUF9JWF9Q UkMgfCBBVEFfQUhDSV9QX0lYX1BDIHwgQVRBX0FIQ0lfUF9JWF9EUCB8CisJICAgICAgQVRBX0FI Q0lfUF9JWF9VRiB8IEFUQV9BSENJX1BfSVhfU0RCIHwgQVRBX0FIQ0lfUF9JWF9EUyB8CisJICAg ICAgQVRBX0FIQ0lfUF9JWF9QUyB8IEFUQV9BSENJX1BfSVhfREhSKSk7CisKKyAgICAvKiBhY3Rp dmF0ZSB0aGUgY2hhbm5lbCBhbmQgcG93ZXIvc3BpbiB1cCBkZXZpY2UgKi8KKyAgICBBVEFfT1VU TChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LAorCSAgICAgKEFUQV9BSENJ X1BfQ01EX0FDVElWRSB8IEFUQV9BSENJX1BfQ01EX1BPRCB8IEFUQV9BSENJX1BfQ01EX1NVRCkp OworCisgICAgYXRhX2FoY2lfcmVzdGFydChkZXYpOworCisgICAgLyogZW5hYmxlIEZJUyBiYXNl ZCBzd2l0Y2hpbmcgKi8KKyAgICAvL0FUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9G QlMgKyBvZmZzZXQsIDB4MDAwMDAwMDMpOworCisgICAgaWYgKCFhdGFfc2F0YV9waHlfcmVzZXQo ZGV2KSkgeworCWlmIChib290dmVyYm9zZSkKKwkgICAgZGV2aWNlX3ByaW50ZihkZXYsICJwaHkg cmVzZXQgZm91bmQgbm8gZGV2aWNlXG4iKTsKKwljaC0+ZGV2aWNlcyA9IDA7CisKKwkvKiBraWxs IG9mZiBhbGwgYWN0aXZpdHkgb24gdGhpcyBjaGFubmVsICovCisJY21kID0gQVRBX0lOTChjdGxy LT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0KTsKIAlBVEFfT1VUTChjdGxyLT5yX3Jl czIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LAotCQkgKEFUQV9BSENJX1BfQ01EX0FDVElWRSB8 IEFUQV9BSENJX1BfQ01EX0ZSRSB8Ci0JCSAgQVRBX0FIQ0lfUF9DTURfUE9EIHwgQVRBX0FIQ0lf UF9DTURfU1VEIHwgQVRBX0FIQ0lfUF9DTURfU1QpKTsKKwkJIGNtZCAmIH4oQVRBX0FIQ0lfUF9D TURfRlJFIHwgQVRBX0FIQ0lfUF9DTURfU1QpKTsKKwlyZXR1cm47CisgICAgfQorCisgICAgLyog b25seSBwcm9iZSBmb3IgUG9ydE11bHRpcGxpZXIgaWYgSFcgaGFzIHN1cHBvcnQgKi8KKyAgICBp ZiAoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0NBUCkgJiBBVEFfQUhDSV9DQVBfU1BN KQorCXNpZ25hdHVyZSA9IGF0YV9haGNpX3NvZnRyZXNldChkZXYsIEFUQV9QTSk7CisgICAgZWxz ZSB7CisJc2lnbmF0dXJlID0gYXRhX2FoY2lfc29mdHJlc2V0KGRldiwgMCk7CisgICAgfQorICAg IGlmIChib290dmVyYm9zZSkKKwlkZXZpY2VfcHJpbnRmKGRldiwgIlNJR05BVFVSRTogJTA4eFxu Iiwgc2lnbmF0dXJlKTsKIAotCXNpZ25hdHVyZSA9IEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFf QUhDSV9QX1NJRyArIG9mZnNldCk7CisgICAgc3dpdGNoIChzaWduYXR1cmUpIHsKKyAgICBjYXNl IDB4MDAwMDAxMDE6CisJY2gtPmRldmljZXMgPSBBVEFfQVRBX01BU1RFUjsKKwlicmVhazsKKyAg ICBjYXNlIDB4OTY2OTAxMDE6CisJY2gtPmRldmljZXMgPSBBVEFfUE9SVE1VTFRJUExJRVI7CisJ YXRhX3BtX2lkZW50aWZ5KGRldik7CisJYnJlYWs7CisgICAgY2FzZSAweGViMTQwMTAxOgorCWNo LT5kZXZpY2VzID0gQVRBX0FUQVBJX01BU1RFUjsKKwlicmVhazsKKyAgICBkZWZhdWx0OiAvKiBT T1MgWFhYICovCiAJaWYgKGJvb3R2ZXJib3NlKQotCSAgICBkZXZpY2VfcHJpbnRmKGRldiwgIlNJ R05BVFVSRTogJTA4eFxuIiwgc2lnbmF0dXJlKTsKLQlzd2l0Y2ggKHNpZ25hdHVyZSkgewotCWNh c2UgMHgwMDAwMDEwMToKLQkgICAgY2gtPmRldmljZXMgPSBBVEFfQVRBX01BU1RFUjsKLQkgICAg YnJlYWs7Ci0JY2FzZSAweDk2NjkwMTAxOgotCSAgICBjaC0+ZGV2aWNlcyA9IEFUQV9QT1JUTVVM VElQTElFUjsKLQkgICAgZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAiUG9ydG11bHRpcGxpZXJzIG5v dCBzdXBwb3J0ZWQgeWV0XG4iKTsKLQkgICAgY2gtPmRldmljZXMgPSAwOwotCSAgICBicmVhazsK LQljYXNlIDB4ZWIxNDAxMDE6Ci0JICAgIGNoLT5kZXZpY2VzID0gQVRBX0FUQVBJX01BU1RFUjsK LQkgICAgYnJlYWs7Ci0JZGVmYXVsdDogLyogU09TIFhYWCAqLwotCSAgICBpZiAoYm9vdHZlcmJv c2UpCi0JCWRldmljZV9wcmludGYoY2gtPmRldiwgIk5vIHNpZ25hdHVyZSwgYXN1bWluZyBkaXNr IGRldmljZVxuIik7Ci0JICAgIGNoLT5kZXZpY2VzID0gQVRBX0FUQV9NQVNURVI7Ci0JfQorCSAg ICBkZXZpY2VfcHJpbnRmKGRldiwgIk5vIHNpZ25hdHVyZSwgYXN1bWluZyBkaXNrIGRldmljZVxu Iik7CisJY2gtPmRldmljZXMgPSBBVEFfQVRBX01BU1RFUjsKICAgICB9CiAgICAgaWYgKGJvb3R2 ZXJib3NlKQotICAgICAgICBkZXZpY2VfcHJpbnRmKGRldiwgImFoY2lfcmVzZXQgZGV2aWNlcz0w eCViXG4iLCBjaC0+ZGV2aWNlcywKLSAgICAgICAgICAgICAgICAgICAgICAiXDIwXDRBVEFQSV9T TEFWRVwzQVRBUElfTUFTVEVSXDJBVEFfU0xBVkVcMUFUQV9NQVNURVIiKTsKKyAgICAgICAgZGV2 aWNlX3ByaW50ZihkZXYsICJhaGNpX3Jlc2V0IGRldmljZXM9JTA4eFxuIiwgY2gtPmRldmljZXMp OwogfQogCiBzdGF0aWMgdm9pZApAQCAtODYzLDcgKzEyMDUsOCBAQCBhdGFfYWhjaV9kbWFzZXRw cmQodm9pZCAqeHNjLCBidXNfZG1hX3NlCiAJICAgIHByZFtpXS5kYmMgPSBodG9sZTMyKChzZWdz W2ldLmRzX2xlbiAtIDEpICYgQVRBX0FIQ0lfUFJEX01BU0spOwogCX0KICAgICB9Ci0gICAgS0FT U0VSVChuc2VncyA8PSBBVEFfRE1BX0VOVFJJRVMsICgidG9vIG1hbnkgRE1BIHNlZ21lbnQgZW50 cmllc1xuIikpOworCisgICAgS0FTU0VSVChuc2VncyA8PSBBVEFfQUhDSV9ETUFfRU5UUklFUywg KCJ0b28gbWFueSBETUEgc2VnbWVudCBlbnRyaWVzXG4iKSk7CiAgICAgYXJncy0+bnNlZ3MgPSBu c2VnczsKIH0KIApAQCAtODc0LDEzICsxMjE3LDExIEBAIGF0YV9haGNpX2RtYWluaXQoZGV2aWNl X3QgZGV2KQogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7CiAKICAgICBhdGFfZG1haW5pdChkZXYpOwotICAgIGlmIChjaC0+ZG1hKSB7Ci0JLyogbm90 ZSBzdGFydCBhbmQgc3RvcCBhcmUgbm90IHVzZWQgaGVyZSAqLwotCWNoLT5kbWEtPnNldHByZCA9 IGF0YV9haGNpX2RtYXNldHByZDsKLQljaC0+ZG1hLT5tYXhfaW9zaXplID0gODE5MiAqIERFVl9C U0laRTsKLQlpZiAoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0NBUCkgJiBBVEFfQUhD SV9DQVBfNjRCSVQpCi0JICAgIGNoLT5kbWEtPm1heF9hZGRyZXNzID0gQlVTX1NQQUNFX01BWEFE RFI7Ci0gICAgfQorICAgIC8qIG5vdGUgc3RhcnQgYW5kIHN0b3AgYXJlIG5vdCB1c2VkIGhlcmUg Ki8KKyAgICBjaC0+ZG1hLnNldHByZCA9IGF0YV9haGNpX2RtYXNldHByZDsKKyAgICBjaC0+ZG1h Lm1heF9pb3NpemUgPSA4MTkyICogREVWX0JTSVpFOworICAgIGlmIChBVEFfSU5MKGN0bHItPnJf cmVzMiwgQVRBX0FIQ0lfQ0FQKSAmIEFUQV9BSENJX0NBUF82NEJJVCkKKwljaC0+ZG1hLm1heF9h ZGRyZXNzID0gQlVTX1NQQUNFX01BWEFERFI7CiB9CiAKIHN0YXRpYyBpbnQKQEAgLTk1Niw5ICsx Mjk3LDkgQEAgYXRhX2FjYXJkX3N0YXR1cyhkZXZpY2VfdCBkZXYpCiAgICAgc3RydWN0IGF0YV9j aGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKIAogICAgIGlmIChjdGxyLT5jaGlw LT5jZmcxID09IEFUUE9MRCAmJgotCUFUQV9MT0NLSU5HKGNoLT5kZXYsIEFUQV9MRl9XSElDSCkg IT0gY2gtPnVuaXQpCisJQVRBX0xPQ0tJTkcoZGV2LCBBVEFfTEZfV0hJQ0gpICE9IGNoLT51bml0 KQogCSAgICByZXR1cm4gMDsKLSAgICBpZiAoY2gtPmRtYSAmJiAoY2gtPmRtYS0+ZmxhZ3MgJiBB VEFfRE1BX0FDVElWRSkpIHsKKyAgICBpZiAoY2gtPmRtYS5mbGFncyAmIEFUQV9ETUFfQUNUSVZF KSB7CiAJaW50IGJtc3RhdCA9IEFUQV9JRFhfSU5CKGNoLCBBVEFfQk1TVEFUX1BPUlQpICYgQVRB X0JNU1RBVF9NQVNLOwogCiAJaWYgKChibXN0YXQgJiAoQVRBX0JNU1RBVF9BQ1RJVkUgfCBBVEFf Qk1TVEFUX0lOVEVSUlVQVCkpICE9CkBAIC05ODUsNyArMTMyNiw3IEBAIGF0YV9hY2FyZF84NTBf c2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCAKICAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVy ICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhncGFyZW50KTsKICAgICBzdHJ1Y3QgYXRhX2NoYW5u ZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKICAgICBz dHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwotICAgIGlu dCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIEFUQV9ERVYoYXRhZGV2LT51bml0KTsKKyAgICBp bnQgZGV2bm8gPSAoY2gtPnVuaXQgPDwgMSkgKyBhdGFkZXYtPnVuaXQ7CiAgICAgaW50IGVycm9y OwogCiAgICAgbW9kZSA9IGF0YV9saW1pdF9tb2RlKGRldiwgbW9kZSwKQEAgLTEwMjEsNyArMTM2 Miw3IEBAIGF0YV9hY2FyZF84Nlhfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCAKICAgICBzdHJ1 Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhncGFyZW50KTsK ICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0 X3BhcmVudChkZXYpKTsKICAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOwotICAgIGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIEFUQV9ERVYo YXRhZGV2LT51bml0KTsKKyAgICBpbnQgZGV2bm8gPSAoY2gtPnVuaXQgPDwgMSkgKyBhdGFkZXYt PnVuaXQ7CiAgICAgaW50IGVycm9yOwogCiAKQEAgLTEyMzQsNyArMTU3NSw3IEBAIGF0YV9hbGlf c2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKQogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRy b2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFf Y2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwog ICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0g ICAgaW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOwor ICAgIGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQg ZXJyb3I7CiAKICAgICBtb2RlID0gYXRhX2xpbWl0X21vZGUoZGV2LCBtb2RlLCBjdGxyLT5jaGlw LT5tYXhfZG1hKTsKQEAgLTEzMjIsMTMgKzE2NjMsMzQgQEAgYXRhX2FtZF9jaGlwaW5pdChkZXZp Y2VfdCBkZXYpCiAgICAgaWYgKGF0YV9zZXR1cF9pbnRlcnJ1cHQoZGV2KSkKIAlyZXR1cm4gRU5Y SU87CiAKLSAgICAvKiBkaXNhYmxlL3NldCBwcmVmZXRjaCwgcG9zdHdyaXRlICovCi0gICAgaWYg KGN0bHItPmNoaXAtPmNmZzIgJiBBTURCVUcpCi0JcGNpX3dyaXRlX2NvbmZpZyhkZXYsIDB4NDEs IHBjaV9yZWFkX2NvbmZpZyhkZXYsIDB4NDEsIDEpICYgMHgwZiwgMSk7Ci0gICAgZWxzZQotCXBj aV93cml0ZV9jb25maWcoZGV2LCAweDQxLCBwY2lfcmVhZF9jb25maWcoZGV2LCAweDQxLCAxKSB8 IDB4ZjAsIDEpOworICAgIC8qIGRpc2FibGUvc2V0IHByZWZldGNoLCBwb3N0d3JpdGUgKi8KKyAg ICBpZiAoY3Rsci0+Y2hpcC0+Y2ZnMiAmIEFNREJVRykKKwlwY2lfd3JpdGVfY29uZmlnKGRldiwg MHg0MSwgcGNpX3JlYWRfY29uZmlnKGRldiwgMHg0MSwgMSkgJiAweDBmLCAxKTsKKyAgICBlbHNl CisJcGNpX3dyaXRlX2NvbmZpZyhkZXYsIDB4NDEsIHBjaV9yZWFkX2NvbmZpZyhkZXYsIDB4NDEs IDEpIHwgMHhmMCwgMSk7CisKKyAgICBjdGxyLT5zZXRtb2RlID0gYXRhX3ZpYV9mYW1pbHlfc2V0 bW9kZTsKKyAgICByZXR1cm4gMDsKK30KKworCisvKgorICogQWRhcHRlYyBjaGlwc2V0IHN1cHBv cnQgZnVuY3Rpb25zCisgKi8KK2ludAorYXRhX2FkYXB0ZWNfaWRlbnQoZGV2aWNlX3QgZGV2KQor eworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRj KGRldik7CisgICAgc3RhdGljIHN0cnVjdCBhdGFfY2hpcF9pZCBpZHNbXSA9CisgICAge3sgQVRB X0FEQVBURUNfMTQyMCwgMCwgNCwgTVY2MFhYLCBBVEFfU0EzMDAsICIxNDIwU0EiIH0sCisgICAg IHsgMCwgMCwgMCwgMCwgMCwgMH19OworCisgICAgaWYgKCEoY3Rsci0+Y2hpcCA9IGF0YV9tYXRj aF9jaGlwKGRldiwgaWRzKSkpCisJcmV0dXJuIEVOWElPOworCisgICAgYXRhX3NldF9kZXNjKGRl dik7CisgICAgY3Rsci0+Y2hpcGluaXQgPSBhdGFfbWFydmVsbF9lZG1hX2NoaXBpbml0OwogCi0g ICAgY3Rsci0+c2V0bW9kZSA9IGF0YV92aWFfZmFtaWx5X3NldG1vZGU7CiAgICAgcmV0dXJuIDA7 CiB9CiAKQEAgLTEzOTgsNyArMTc2MCw3IEBAIGF0YV9hdGlfc2V0bW9kZShkZXZpY2VfdCBkZXYs IGludCBtb2RlKQogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2Vf Z2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNl ICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgaW50IGRldm5vID0gKGNoLT51 bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBkZXZubyA9IChjaC0+ dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQgb2Zmc2V0ID0gKGRldm5vIF4gMHgw MSkgPDwgMzsKICAgICBpbnQgZXJyb3I7CiAgICAgdV9pbnQ4X3QgcGlvdGltaW5nc1tdID0geyAw eDVkLCAweDQ3LCAweDM0LCAweDIyLCAweDIwLCAweDM0LCAweDIyLCAweDIwLApAQCAtMTQ5Miwx NSArMTg1NCwxNSBAQCBhdGFfY3lyaXhfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlCiB7 CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dl dF9wYXJlbnQoZGV2KSk7CiAgICAgc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9n ZXRfc29mdGMoZGV2KTsKLSAgICBpbnQgZGV2bm8gPSAoY2gtPnVuaXQgPDwgMSkgKyBBVEFfREVW KGF0YWRldi0+dW5pdCk7CisgICAgaW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsgYXRhZGV2 LT51bml0OwogICAgIHVfaW50MzJfdCBwaW90aW1pbmdbXSA9IAogCXsgMHgwMDAwOTE3MiwgMHgw MDAxMjE3MSwgMHgwMDAyMDA4MCwgMHgwMDAzMjAxMCwgMHgwMDA0MDAxMCB9OwogICAgIHVfaW50 MzJfdCBkbWF0aW1pbmdbXSA9IHsgMHgwMDA3Nzc3MSwgMHgwMDAxMjEyMSwgMHgwMDAwMjAyMCB9 OwogICAgIHVfaW50MzJfdCB1ZG1hdGltaW5nW10gPSB7IDB4MDA5MjEyNTAsIDB4MDA5MTExNDAs IDB4MDA5MTEwMzAgfTsKICAgICBpbnQgZXJyb3I7CiAKLSAgICBjaC0+ZG1hLT5hbGlnbm1lbnQg PSAxNjsKLSAgICBjaC0+ZG1hLT5tYXhfaW9zaXplID0gMTI2ICogREVWX0JTSVpFOworICAgIGNo LT5kbWEuYWxpZ25tZW50ID0gMTY7CisgICAgY2gtPmRtYS5tYXhfaW9zaXplID0gMTI2ICogREVW X0JTSVpFOwogCiAgICAgbW9kZSA9IGF0YV9saW1pdF9tb2RlKGRldiwgbW9kZSwgQVRBX1VETUEy KTsKIApAQCAtMTY4MSw3ICsyMDQzLDcgQEAgYXRhX2hpZ2hwb2ludF9zZXRtb2RlKGRldmljZV90 IGRldiwgaW50IAogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2Vf Z2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNl ICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgaW50IGRldm5vID0gKGNoLT51 bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBkZXZubyA9IChjaC0+ dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQgZXJyb3I7CiAgICAgdV9pbnQzMl90 IHRpbWluZ3MzM1tdWzRdID0gewogICAgIC8qICAgIEhQVDM2NiAgICAgIEhQVDM3MCAgICAgIEhQ VDM3MiAgICAgIEhQVDM3NCAgICAgICAgICAgICAgIG1vZGUgKi8KQEAgLTE4MDAsNiArMjE2Miw3 IEBAIGF0YV9pbnRlbF9pZGVudChkZXZpY2VfdCBkZXYpCiAgICAgIHsgQVRBX0k2M1hYRVNCMl9S MiwgMCwgQUhDSSwgMHgwMCwgQVRBX1NBMzAwLCAiNjNYWEVTQjIiIH0sCiAgICAgIHsgQVRBX0k4 MjgwMUhCX1MxLCAgMCwgQUhDSSwgMHgwMCwgQVRBX1NBMzAwLCAiSUNIOCIgfSwKICAgICAgeyBB VEFfSTgyODAxSEJfUzIsICAwLCBBSENJLCAweDAwLCBBVEFfU0EzMDAsICJJQ0g4IiB9LAorICAg ICB7IEFUQV9JODI4MDFIQl9SMSwgIDIsIEFIQ0ksIDB4MDAsIEFUQV9TQTMwMCwgIklDSDlSIiB9 LAogICAgICB7IEFUQV9JODI4MDFIQl9SMSwgIDAsIEFIQ0ksIDB4MDAsIEFUQV9TQTMwMCwgIklD SDgiIH0sCiAgICAgIHsgQVRBX0k4MjgwMUhCX0FINCwgMCwgQUhDSSwgMHgwMCwgQVRBX1NBMzAw LCAiSUNIOCIgfSwKICAgICAgeyBBVEFfSTgyODAxSEJfQUg2LCAwLCBBSENJLCAweDAwLCBBVEFf U0EzMDAsICJJQ0g4IiB9LApAQCAtMTk2Myw3ICsyMzI2LDcgQEAgYXRhX2ludGVsX25ld19zZXRt b2RlKGRldmljZV90IGRldiwgaW50IAogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0 bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAq Y2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwogICAgIHN0cnVj dCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgaW50IGRl dm5vID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBk ZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICB1X2ludDMyX3QgcmVn NDAgPSBwY2lfcmVhZF9jb25maWcoZ3BhcmVudCwgMHg0MCwgNCk7CiAgICAgdV9pbnQ4X3QgcmVn NDQgPSBwY2lfcmVhZF9jb25maWcoZ3BhcmVudCwgMHg0NCwgMSk7CiAgICAgdV9pbnQ4X3QgcmVn NDggPSBwY2lfcmVhZF9jb25maWcoZ3BhcmVudCwgMHg0OCwgMSk7CkBAIC0xOTg4LDUyICsyMzUx LDU0IEBAIGF0YV9pbnRlbF9uZXdfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCAKIAlkZXZpY2Vf cHJpbnRmKGRldiwgIiVzc2V0dGluZyAlcyBvbiAlcyBjaGlwXG4iLAogCQkgICAgICAoZXJyb3Ip ID8gIkZBSUxVUkUgIiA6ICIiLAogCQkgICAgICBhdGFfbW9kZTJzdHIobW9kZSksIGN0bHItPmNo aXAtPnRleHQpOwotICAgIGlmIChlcnJvcikKLQlyZXR1cm47CisgICAgaWYgKCFlcnJvcikgewor CWlmIChtb2RlID49IEFUQV9VRE1BMCkgeworCSAgICB1X2ludDhfdCB1dGltaW5nc1tdID0geyAw eDAwLCAweDAxLCAweDEwLCAweDAxLCAweDEwLCAweDAxLCAweDEwIH07CiAKLSAgICBpZiAobW9k ZSA+PSBBVEFfVURNQTApIHsKLQlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NDgsIHJlZzQ4 IHwgKDB4MDAwMSA8PCBkZXZubyksIDIpOwotCXBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0 YSwKLQkJCSAocmVnNGEgJiB+KDB4MyA8PCAoZGV2bm8gPDwgMikpKSB8Ci0JCQkgKCgweDAxICsg IShtb2RlICYgMHgwMSkpIDw8IChkZXZubyA8PCAyKSksIDIpOwotICAgIH0KLSAgICBlbHNlIHsK LQlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NDgsIHJlZzQ4ICYgfigweDAwMDEgPDwgZGV2 bm8pLCAyKTsKLQlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NGEsIChyZWc0YSAmIH4oMHgz IDw8IChkZXZubyA8PCAyKSkpLCAyKTsKLSAgICB9Ci0gICAgcmVnNTQgfD0gMHgwNDAwOwotICAg IGlmIChtb2RlID49IEFUQV9VRE1BMikKLQlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NTQs IHJlZzU0IHwgKDB4MSA8PCBkZXZubyksIDIpOwotICAgIGVsc2UKLQlwY2lfd3JpdGVfY29uZmln KGdwYXJlbnQsIDB4NTQsIHJlZzU0ICYgfigweDEgPDwgZGV2bm8pLCAyKTsKKwkgICAgcGNpX3dy aXRlX2NvbmZpZyhncGFyZW50LCAweDQ4LCByZWc0OCB8ICgweDAwMDEgPDwgZGV2bm8pLCAyKTsK KwkgICAgcGNpX3dyaXRlX2NvbmZpZyhncGFyZW50LCAweDRhLAorCQkJICAgICAocmVnNGEgJiB+ KDB4MyA8PCAoZGV2bm8gPDwgMikpKSB8CisJCQkgICAgICh1dGltaW5nc1ttb2RlICYgQVRBX01P REVfTUFTS10gPDwgKGRldm5vPDwyKSksIDIpOworCX0KKwllbHNlIHsKKwkgICAgcGNpX3dyaXRl X2NvbmZpZyhncGFyZW50LCAweDQ4LCByZWc0OCAmIH4oMHgwMDAxIDw8IGRldm5vKSwgMik7CisJ ICAgIHBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0YSwgKHJlZzRhICYgfigweDMgPDwgKGRl dm5vIDw8IDIpKSksMik7CisJfQorCXJlZzU0IHw9IDB4MDQwMDsKKwlpZiAobW9kZSA+PSBBVEFf VURNQTIpCisJICAgIHJlZzU0IHw9ICgweDEgPDwgZGV2bm8pOworCWVsc2UKKwkgICAgcmVnNTQg Jj0gfigweDEgPDwgZGV2bm8pOworCWlmIChtb2RlID49IEFUQV9VRE1BNSkKKwkgICAgcmVnNTQg fD0gKDB4MTAwMCA8PCBkZXZubyk7CisJZWxzZSAKKwkgICAgcmVnNTQgJj0gfigweDEwMDAgPDwg ZGV2bm8pOwogCi0gICAgaWYgKG1vZGUgPj0gQVRBX1VETUE1KQotCXBjaV93cml0ZV9jb25maWco Z3BhcmVudCwgMHg1NCwgcmVnNTQgfCAoMHgxMDAwIDw8IGRldm5vKSwgMik7Ci0gICAgZWxzZSAK LQlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NTQsIHJlZzU0ICYgfigweDEwMDAgPDwgZGV2 bm8pLCAyKTsKKwlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NTQsIHJlZzU0LCAyKTsKIAot ICAgIHJlZzQwICY9IH4weDAwZmYwMGZmOwotICAgIHJlZzQwIHw9IDB4NDA3NzQwNzc7CisJcmVn NDAgJj0gfjB4MDBmZjAwZmY7CisJcmVnNDAgfD0gMHg0MDc3NDA3NzsKIAotICAgIGlmIChhdGFk ZXYtPnVuaXQgPT0gQVRBX01BU1RFUikgewotCW1hc2s0MCA9IDB4MzMwMDsKLQluZXc0MCA9IHRp bWluZ3NbYXRhX21vZGUyaWR4KG1vZGUpXSA8PCA4OwotICAgIH0KLSAgICBlbHNlIHsKLQltYXNr NDQgPSAweDBmOwotCW5ldzQ0ID0gKCh0aW1pbmdzW2F0YV9tb2RlMmlkeChtb2RlKV0gJiAweDMw KSA+PiAyKSB8Ci0JCSh0aW1pbmdzW2F0YV9tb2RlMmlkeChtb2RlKV0gJiAweDAzKTsKLSAgICB9 Ci0gICAgaWYgKGNoLT51bml0KSB7Ci0JbWFzazQwIDw8PSAxNjsKLQluZXc0MCA8PD0gMTY7Ci0J bWFzazQ0IDw8PSA0OwotCW5ldzQ0IDw8PSA0OwotICAgIH0KLSAgICBwY2lfd3JpdGVfY29uZmln KGdwYXJlbnQsIDB4NDAsIChyZWc0MCAmIH5tYXNrNDApIHwgbmV3NDAsIDQpOwotICAgIHBjaV93 cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0NCwgKHJlZzQ0ICYgfm1hc2s0NCkgfCBuZXc0NCwgMSk7 CisJaWYgKGF0YWRldi0+dW5pdCA9PSBBVEFfTUFTVEVSKSB7CisJICAgIG1hc2s0MCA9IDB4MzMw MDsKKwkgICAgbmV3NDAgPSB0aW1pbmdzW2F0YV9tb2RlMmlkeChtb2RlKV0gPDwgODsKKwl9CisJ ZWxzZSB7CisJICAgIG1hc2s0NCA9IDB4MGY7CisJICAgIG5ldzQ0ID0gKCh0aW1pbmdzW2F0YV9t b2RlMmlkeChtb2RlKV0gJiAweDMwKSA+PiAyKSB8CisJCSAgICAodGltaW5nc1thdGFfbW9kZTJp ZHgobW9kZSldICYgMHgwMyk7CisJfQorCWlmIChjaC0+dW5pdCkgeworCSAgICBtYXNrNDAgPDw9 IDE2OworCSAgICBuZXc0MCA8PD0gMTY7CisJICAgIG1hc2s0NCA8PD0gNDsKKwkgICAgbmV3NDQg PDw9IDQ7CisJfQorCXBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0MCwgKHJlZzQwICYgfm1h c2s0MCkgfCBuZXc0MCwgNCk7CisJcGNpX3dyaXRlX2NvbmZpZyhncGFyZW50LCAweDQ0LCAocmVn NDQgJiB+bWFzazQ0KSB8IG5ldzQ0LCAxKTsKIAotICAgIGF0YWRldi0+bW9kZSA9IG1vZGU7CisJ YXRhZGV2LT5tb2RlID0gbW9kZTsKKyAgICB9CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0yMDQ1LDcg KzI0MTAsNyBAQCBhdGFfaW50ZWxfc2F0YV9zZXRtb2RlKGRldmljZV90IGRldiwgaW50CiAJYXRh ZGV2LT5wYXJhbS5zYXRhY2FwYWJpbGl0aWVzICE9IDB4ZmZmZikgewogCiAJc3RydWN0IGF0YV9j aGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7Ci0J aW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworCWlu dCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKIAogCS8qIG9uIHNvbWUg ZHJpdmVzIHdlIG5lZWQgdG8gc2V0IHRoZSB0cmFuc2ZlciBtb2RlICovCiAJYXRhX2NvbnRyb2xj bWQoZGV2LCBBVEFfU0VURkVBVFVSRVMsIEFUQV9TRl9TRVRYRkVSLCAwLApAQCAtMjE0MSw3ICsy NTA2LDcgQEAgYXRhX2ludGVsXzMxMjQ0X3RmX3dyaXRlKHN0cnVjdCBhdGFfcmVxdQogCQkJCSAg ICAgICAoKHJlcXVlc3QtPnUuYXRhLmxiYSA+PiA4KSAmIDB4MDBmZikpOwogCUFUQV9JRFhfT1VU VyhjaCwgQVRBX0NZTF9NU0IsICgocmVxdWVzdC0+dS5hdGEubGJhID4+IDMyKSAmIDB4ZmYwMCkg fCAKIAkJCQkgICAgICAgKChyZXF1ZXN0LT51LmF0YS5sYmEgPj4gMTYpICYgMHgwMGZmKSk7Ci0J QVRBX0lEWF9PVVRXKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0xCQSB8IGF0YWRldi0+dW5pdCk7CisJ QVRBX0lEWF9PVVRXKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0xCQSB8IEFUQV9ERVYoYXRhZGV2LT51 bml0KSk7CiAgICAgfQogICAgIGVsc2UgewogCUFUQV9JRFhfT1VUQihjaCwgQVRBX0ZFQVRVUkUs IHJlcXVlc3QtPnUuYXRhLmZlYXR1cmUpOwpAQCAtMjE2Miw3ICsyNTI3LDcgQEAgYXRhX2ludGVs XzMxMjQ0X3RmX3dyaXRlKHN0cnVjdCBhdGFfcmVxdQogCQkJIChyZXF1ZXN0LT51LmF0YS5sYmEg LyAoc2VjdG9ycyAqIGhlYWRzKSkpOwogCSAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9DWUxfTVNC LAogCQkJIChyZXF1ZXN0LT51LmF0YS5sYmEgLyAoc2VjdG9ycyAqIGhlYWRzKSkgPj4gOCk7Ci0J ICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLCBBVEFfRF9JQk0gfCBhdGFkZXYtPnVuaXQg fCAKKwkgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IEFUQV9ERVYo YXRhZGV2LT51bml0KSB8IAogCQkJICgoKHJlcXVlc3QtPnUuYXRhLmxiYSUgKHNlY3RvcnMgKiBo ZWFkcykpIC8KIAkJCSAgIHNlY3RvcnMpICYgMHhmKSk7CiAJfQpAQCAtMjE3MSw3ICsyNTM2LDcg QEAgYXRhX2ludGVsXzMxMjQ0X3RmX3dyaXRlKHN0cnVjdCBhdGFfcmVxdQogCSAgICBBVEFfSURY X09VVEIoY2gsIEFUQV9DWUxfTFNCLCByZXF1ZXN0LT51LmF0YS5sYmEgPj4gOCk7CiAJICAgIEFU QV9JRFhfT1VUQihjaCwgQVRBX0NZTF9NU0IsIHJlcXVlc3QtPnUuYXRhLmxiYSA+PiAxNik7CiAJ ICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLAotCQkJIEFUQV9EX0lCTSB8IEFUQV9EX0xC QSB8IGF0YWRldi0+dW5pdCB8CisJCQkgQVRBX0RfSUJNIHwgQVRBX0RfTEJBIHwgQVRBX0RFVihh dGFkZXYtPnVuaXQpIHwKIAkJCSAoKHJlcXVlc3QtPnUuYXRhLmxiYSA+PiAyNCkgJiAweDBmKSk7 CiAJfQogICAgIH0KQEAgLTIxOTMsNyArMjU1OCw4IEBAIGF0YV9pdGVfaWRlbnQoZGV2aWNlX3Qg ZGV2KQogewogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0 X3NvZnRjKGRldik7CiAgICAgc3RhdGljIHN0cnVjdCBhdGFfY2hpcF9pZCBpZHNbXSA9Ci0gICAg e3sgQVRBX0lUODIxMkYsIDB4MDAsIDB4MDAsIDB4MDAsIEFUQV9VRE1BNiwgIklUODIxMkYiIH0s CisgICAge3sgQVRBX0lUODIxM0YsIDB4MDAsIDB4MDAsIDB4MDAsIEFUQV9VRE1BNiwgIklUODIx M0YiIH0sCisgICAgIHsgQVRBX0lUODIxMkYsIDB4MDAsIDB4MDAsIDB4MDAsIEFUQV9VRE1BNiwg IklUODIxMkYiIH0sCiAgICAgIHsgQVRBX0lUODIxMUYsIDB4MDAsIDB4MDAsIDB4MDAsIEFUQV9V RE1BNiwgIklUODIxMUYiIH0sCiAgICAgIHsgMCwgMCwgMCwgMCwgMCwgMH19OwogCkBAIC0yMjEz LDI0ICsyNTc5LDMzIEBAIGF0YV9pdGVfY2hpcGluaXQoZGV2aWNlX3QgZGV2KQogICAgIGlmIChh dGFfc2V0dXBfaW50ZXJydXB0KGRldikpCiAJcmV0dXJuIEVOWElPOwogCi0gICAgY3Rsci0+c2V0 bW9kZSA9IGF0YV9pdGVfc2V0bW9kZTsKKyAgICBpZiAoY3Rsci0+Y2hpcC0+Y2hpcGlkID09IEFU QV9JVDgyMTNGKSB7CisJLyogdGhlIElURSA4MjEzRiBvbmx5IGhhcyBvbmUgY2hhbm5lbCAqLwor CWN0bHItPmNoYW5uZWxzID0gMTsKKworCWN0bHItPnNldG1vZGUgPSBhdGFfaXRlXzgyMTNfc2V0 bW9kZTsKKyAgICB9CisgICAgZWxzZSB7CisJLyogc2V0IFBDSSBtb2RlIGFuZCA2Nk1oeiByZWZl cmVuY2UgY2xvY2sgKi8KKwlwY2lfd3JpdGVfY29uZmlnKGRldiwgMHg1MCwgcGNpX3JlYWRfY29u ZmlnKGRldiwgMHg1MCwgMSkgJiB+MHg4MywgMSk7CiAKLSAgICAvKiBzZXQgUENJIG1vZGUgYW5k IDY2TWh6IHJlZmVyZW5jZSBjbG9jayAqLwotICAgIHBjaV93cml0ZV9jb25maWcoZGV2LCAweDUw LCBwY2lfcmVhZF9jb25maWcoZGV2LCAweDUwLCAxKSAmIH4weDgzLCAxKTsKKwkvKiBzZXQgZGVm YXVsdCBhY3RpdmUgJiByZWNvdmVyIHRpbWluZ3MgKi8KKwlwY2lfd3JpdGVfY29uZmlnKGRldiwg MHg1NCwgMHgzMSwgMSk7CisJcGNpX3dyaXRlX2NvbmZpZyhkZXYsIDB4NTYsIDB4MzEsIDEpOwor CisJY3Rsci0+c2V0bW9kZSA9IGF0YV9pdGVfODIxeF9zZXRtb2RlOworICAgIH0KIAotICAgIC8q IHNldCBkZWZhdWx0IGFjdGl2ZSAmIHJlY292ZXIgdGltaW5ncyAqLwotICAgIHBjaV93cml0ZV9j b25maWcoZGV2LCAweDU0LCAweDMxLCAxKTsKLSAgICBwY2lfd3JpdGVfY29uZmlnKGRldiwgMHg1 NiwgMHgzMSwgMSk7CiAgICAgcmV0dXJuIDA7CiB9CiAgCiBzdGF0aWMgdm9pZAotYXRhX2l0ZV9z ZXRtb2RlKGRldmljZV90IGRldiwgaW50IG1vZGUpCithdGFfaXRlXzgyMXhfc2V0bW9kZShkZXZp Y2VfdCBkZXYsIGludCBtb2RlKQogewogICAgIGRldmljZV90IGdwYXJlbnQgPSBHUkFORFBBUkVO VChkZXYpOwogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dmljZV9nZXRfcGFyZW50KGRldikpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBk ZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgaW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsg QVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSAr IGF0YWRldi0+dW5pdDsKICAgICBpbnQgZXJyb3I7CiAKICAgICAvKiBjb3JyZWN0IHRoZSBtb2Rl IGZvciB3aGF0IHRoZSBIVyBzdXBwb3J0cyAqLwpAQCAtMjI2Myw3ICsyNjM4LDcgQEAgYXRhX2l0 ZV9zZXRtb2RlKGRldmljZV90IGRldiwgaW50IG1vZGUpCiAKIAkgICAgLyogc2V0IFVETUEgdGlt aW5nICovCiAJICAgIHBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwKLQkJCSAgICAgMHg1NiArIChj aC0+dW5pdCA8PCAyKSArIEFUQV9ERVYoYXRhZGV2LT51bml0KSwKKwkJCSAgICAgMHg1NiArIChj aC0+dW5pdCA8PCAyKSArIGF0YWRldi0+dW5pdCwKIAkJCSAgICAgdWRtYXRpbWluZ1ttb2RlICYg QVRBX01PREVfTUFTS10sIDEpOwogCX0KIAllbHNlIHsKQEAgLTIyODUsNiArMjY2MCw4MCBAQCBh dGFfaXRlX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBpbnQgbW9kZSkKICAgICB9CiB9CiAKK3N0YXRp YyB2b2lkCithdGFfaXRlXzgyMTNfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKQorewor ICAgIGRldmljZV90IGdwYXJlbnQgPSBHUkFORFBBUkVOVChkZXYpOworICAgIHN0cnVjdCBhdGFf cGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGdwYXJlbnQpOworICAgIHN0 cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisgICAgdV9p bnQxNl90IHJlZzQwID0gcGNpX3JlYWRfY29uZmlnKGdwYXJlbnQsIDB4NDAsIDIpOworICAgIHVf aW50OF90IHJlZzQ0ID0gcGNpX3JlYWRfY29uZmlnKGdwYXJlbnQsIDB4NDQsIDEpOworICAgIHVf aW50OF90IHJlZzQ4ID0gcGNpX3JlYWRfY29uZmlnKGdwYXJlbnQsIDB4NDgsIDEpOworICAgIHVf aW50MTZfdCByZWc0YSA9IHBjaV9yZWFkX2NvbmZpZyhncGFyZW50LCAweDRhLCAyKTsKKyAgICB1 X2ludDE2X3QgcmVnNTQgPSBwY2lfcmVhZF9jb25maWcoZ3BhcmVudCwgMHg1NCwgMik7CisgICAg dV9pbnQxNl90IG1hc2s0MCA9IDAsIG5ldzQwID0gMDsKKyAgICB1X2ludDhfdCBtYXNrNDQgPSAw LCBuZXc0NCA9IDA7CisgICAgaW50IGRldm5vID0gYXRhZGV2LT51bml0OworICAgIGludCBlcnJv cjsKKyAgICB1X2ludDhfdCB0aW1pbmdzW10gPSB7IDB4MDAsIDB4MDAsIDB4MTAsIDB4MjEsIDB4 MjMsIDB4MTAsIDB4MjEsIDB4MjMsCisJCQkgICAweDIzLCAweDIzLCAweDIzLCAweDIzLCAweDIz LCAweDIzIH07CisKKyAgICBtb2RlID0gYXRhX2xpbWl0X21vZGUoZGV2LCBtb2RlLCBjdGxyLT5j aGlwLT5tYXhfZG1hKTsKKworICAgIGlmIChtb2RlID4gQVRBX1VETUEyICYmICEocmVnNTQgJiAo MHgxMCA8PCBkZXZubykpKSB7CisJYXRhX3ByaW50X2NhYmxlKGRldiwgImNvbnRyb2xsZXIiKTsK Kwltb2RlID0gQVRBX1VETUEyOworICAgIH0KKworICAgIGVycm9yID0gYXRhX2NvbnRyb2xjbWQo ZGV2LCBBVEFfU0VURkVBVFVSRVMsIEFUQV9TRl9TRVRYRkVSLCAwLCBtb2RlKTsKKworICAgIGlm IChib290dmVyYm9zZSkKKwlkZXZpY2VfcHJpbnRmKGRldiwgIiVzc2V0dGluZyAlcyBvbiAlcyBj aGlwXG4iLAorCQkgICAgICAoZXJyb3IpID8gIkZBSUxVUkUgIiA6ICIiLAorCQkgICAgICBhdGFf bW9kZTJzdHIobW9kZSksIGN0bHItPmNoaXAtPnRleHQpOworICAgIGlmICghZXJyb3IpIHsKKwlp ZiAobW9kZSA+PSBBVEFfVURNQTApIHsKKwkgICAgdV9pbnQ4X3QgdXRpbWluZ3NbXSA9IHsgMHgw MCwgMHgwMSwgMHgxMCwgMHgwMSwgMHgxMCwgMHgwMSwgMHgxMCB9OworCisJICAgIHBjaV93cml0 ZV9jb25maWcoZ3BhcmVudCwgMHg0OCwgcmVnNDggfCAoMHgwMDAxIDw8IGRldm5vKSwgMik7CisJ ICAgIHBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0YSwKKwkJCSAgICAgKHJlZzRhICYgfigw eDMgPDwgKGRldm5vIDw8IDIpKSkgfAorCQkJICAgICAodXRpbWluZ3NbbW9kZSAmIEFUQV9NT0RF X01BU0tdIDw8IChkZXZubzw8MikpLCAyKTsKKwl9CisJZWxzZSB7CisJICAgIHBjaV93cml0ZV9j b25maWcoZ3BhcmVudCwgMHg0OCwgcmVnNDggJiB+KDB4MDAwMSA8PCBkZXZubyksIDIpOworCSAg ICBwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQsIDB4NGEsIChyZWc0YSAmIH4oMHgzIDw8IChkZXZu byA8PCAyKSkpLDIpOworCX0KKwlpZiAobW9kZSA+PSBBVEFfVURNQTIpCisJICAgIHJlZzU0IHw9 ICgweDEgPDwgZGV2bm8pOworCWVsc2UKKwkgICAgcmVnNTQgJj0gfigweDEgPDwgZGV2bm8pOwor CWlmIChtb2RlID49IEFUQV9VRE1BNSkKKwkgICAgcmVnNTQgfD0gKDB4MTAwMCA8PCBkZXZubyk7 CisJZWxzZSAKKwkgICAgcmVnNTQgJj0gfigweDEwMDAgPDwgZGV2bm8pOworCXBjaV93cml0ZV9j b25maWcoZ3BhcmVudCwgMHg1NCwgcmVnNTQsIDIpOworCisJcmVnNDAgJj0gMHhmZjAwOworCXJl ZzQwIHw9IDB4NDAzMzsKKwlpZiAoYXRhZGV2LT51bml0ID09IEFUQV9NQVNURVIpIHsKKwkgICAg cmVnNDAgfD0gKGF0YV9hdGFwaShkZXYpID8gMHgwNCA6IDB4MDApOworCSAgICBtYXNrNDAgPSAw eDMzMDA7CisJICAgIG5ldzQwID0gdGltaW5nc1thdGFfbW9kZTJpZHgobW9kZSldIDw8IDg7CisJ fQorCWVsc2UgeworCSAgICByZWc0MCB8PSAoYXRhX2F0YXBpKGRldikgPyAweDQwIDogMHgwMCk7 CisJICAgIG1hc2s0NCA9IDB4MGY7CisJICAgIG5ldzQ0ID0gKCh0aW1pbmdzW2F0YV9tb2RlMmlk eChtb2RlKV0gJiAweDMwKSA+PiAyKSB8CisJCSAgICAodGltaW5nc1thdGFfbW9kZTJpZHgobW9k ZSldICYgMHgwMyk7CisJfQorCXBjaV93cml0ZV9jb25maWcoZ3BhcmVudCwgMHg0MCwgKHJlZzQw ICYgfm1hc2s0MCkgfCBuZXc0MCwgNCk7CisJcGNpX3dyaXRlX2NvbmZpZyhncGFyZW50LCAweDQ0 LCAocmVnNDQgJiB+bWFzazQ0KSB8IG5ldzQ0LCAxKTsKKworCWF0YWRldi0+bW9kZSA9IG1vZGU7 CisgICAgfQorfQorCiAKIC8qCiAgKiBKTWljcm9uIGNoaXBzZXQgc3VwcG9ydCBmdW5jdGlvbnMK QEAgLTI1NzMsMTEgKzMwMjIsMTEgQEAgYXRhX21hcnZlbGxfZWRtYV9hbGxvY2F0ZShkZXZpY2Vf dCBkZXYpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9n ZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CiAgICAgc3RydWN0IGF0YV9jaGFubmVs ICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLSAgICB1X2ludDY0X3Qgd29yayA9IGNoLT5k bWEtPndvcmtfYnVzOworICAgIHVfaW50NjRfdCB3b3JrID0gY2gtPmRtYS53b3JrX2J1czsKICAg ICBpbnQgaTsKIAogICAgIC8qIGNsZWFyIHdvcmsgYXJlYSAqLwotICAgIGJ6ZXJvKGNoLT5kbWEt PndvcmssIDEwMjQrMjU2KTsKKyAgICBiemVybyhjaC0+ZG1hLndvcmssIDEwMjQrMjU2KTsKIAog ICAgIC8qIHNldCBsZWdhY3kgQVRBIHJlc291cmNlcyAqLwogICAgIGZvciAoaSA9IEFUQV9EQVRB OyBpIDw9IEFUQV9DT01NQU5EOyBpKyspIHsKQEAgLTI2ODQsMTMgKzMxMzMsMTMgQEAgc3RhdGlj IGludAogYXRhX21hcnZlbGxfZWRtYV9iZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVl c3QgKnJlcXVlc3QpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3Rscj1kZXZp Y2VfZ2V0X3NvZnRjKEdSQU5EUEFSRU5UKHJlcXVlc3QtPmRldikpOwotICAgIHN0cnVjdCBhdGFf Y2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3Qt PmRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJl cXVlc3QtPnBhcmVudCk7CiAgICAgdV9pbnQzMl90IHJlcV9pbjsKICAgICB1X2ludDhfdCAqYnl0 ZXA7CiAgICAgdV9pbnQxNl90ICp3b3JkcDsKICAgICB1X2ludDMyX3QgKnF1YWRwOwotICAgIGlu dCBpLCB0YWcgPSAweDA3OwotICAgIGludCBkdW1teSwgZXJyb3IsIHNsb3Q7CisgICAgaW50IGk7 CisgICAgaW50IGVycm9yLCBzbG90OwogCiAgICAgLyogb25seSBETUEgUi9XIGdvZXMgdGhyb3Vn aCB0aGUgRU1EQSBtYWNoaW5lICovCiAgICAgaWYgKHJlcXVlc3QtPnUuYXRhLmNvbW1hbmQgIT0g QVRBX1JFQURfRE1BICYmCkBAIC0yNzA2LDkgKzMxNTUsNyBAQCBhdGFfbWFydmVsbF9lZG1hX2Jl Z2luX3RyYW5zYWN0aW9uKHN0cnVjCiAgICAgYXRhX21vZGlmeV9pZl80OGJpdChyZXF1ZXN0KTsK IAogICAgIC8qIGNoZWNrIHNhbml0eSwgc2V0dXAgU0cgbGlzdCBhbmQgRE1BIGVuZ2luZSAqLwot ICAgIGlmICgoZXJyb3IgPSBjaC0+ZG1hLT5sb2FkKGNoLT5kZXYsIHJlcXVlc3QtPmRhdGEsIHJl cXVlc3QtPmJ5dGVjb3VudCwKLQkJCSAgICAgICByZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQs IGNoLT5kbWEtPnNnLAotCQkJICAgICAgICZkdW1teSkpKSB7CisgICAgaWYgKChlcnJvciA9IGNo LT5kbWEubG9hZChyZXF1ZXN0LCBOVUxMLCBOVUxMKSkpIHsKIAlkZXZpY2VfcHJpbnRmKHJlcXVl c3QtPmRldiwgInNldHRpbmcgdXAgRE1BIGZhaWxlZFxuIik7CiAJcmVxdWVzdC0+cmVzdWx0ID0g ZXJyb3I7CiAJcmV0dXJuIEFUQV9PUF9GSU5JU0hFRDsKQEAgLTI3MTcsMTUgKzMxNjQsMTUgQEAg YXRhX21hcnZlbGxfZWRtYV9iZWdpbl90cmFuc2FjdGlvbihzdHJ1YwogICAgIC8qIGdldCBuZXh0 IGZyZWUgcmVxdWVzdCBxdWV1ZSBzbG90ICovCiAgICAgcmVxX2luID0gQVRBX0lOTChjdGxyLT5y X3JlczEsIDB4MDIwMTQgKyBBVEFfTVZfRURNQV9CQVNFKGNoKSk7CiAgICAgc2xvdCA9ICgoKHJl cV9pbiAmIH4weGZmZmZmYzAwKSA+PiA1KSArIDApICYgMHgxZjsKLSAgICBieXRlcCA9ICh1X2lu dDhfdCAqKShjaC0+ZG1hLT53b3JrKTsKKyAgICBieXRlcCA9ICh1X2ludDhfdCAqKShjaC0+ZG1h LndvcmspOwogICAgIGJ5dGVwICs9IChzbG90IDw8IDUpOwogICAgIHdvcmRwID0gKHVfaW50MTZf dCAqKWJ5dGVwOwogICAgIHF1YWRwID0gKHVfaW50MzJfdCAqKWJ5dGVwOwogCiAgICAgLyogZmls bCBpbiB0aGlzIHJlcXVlc3QgKi8KLSAgICBxdWFkcFswXSA9IChsb25nKWNoLT5kbWEtPnNnX2J1 cyAmIDB4ZmZmZmZmZmY7Ci0gICAgcXVhZHBbMV0gPSAodV9pbnQ2NF90KWNoLT5kbWEtPnNnX2J1 cyA+PiAzMjsKLSAgICB3b3JkcFs0XSA9IChyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQgPyAw eDAxIDogMHgwMCkgfCAodGFnPDwxKTsKKyAgICBxdWFkcFswXSA9IChsb25nKXJlcXVlc3QtPmRt YS0+c2dfYnVzICYgMHhmZmZmZmZmZjsKKyAgICBxdWFkcFsxXSA9ICh1X2ludDY0X3QpcmVxdWVz dC0+ZG1hLT5zZ19idXMgPj4gMzI7CisgICAgd29yZHBbNF0gPSAocmVxdWVzdC0+ZmxhZ3MgJiBB VEFfUl9SRUFEID8gMHgwMSA6IDB4MDApIHwgKHJlcXVlc3QtPnRhZzw8MSk7CiAKICAgICBpID0g MTA7CiAgICAgYnl0ZXBbaSsrXSA9IChyZXF1ZXN0LT51LmF0YS5jb3VudCA+PiA4KSAmIDB4ZmY7 CkBAIC0yNzc2LDcgKzMyMjMsNyBAQCBzdGF0aWMgaW50CiBhdGFfbWFydmVsbF9lZG1hX2VuZF90 cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiB7CiAgICAgc3RydWN0IGF0 YV9wY2lfY29udHJvbGxlciAqY3Rscj1kZXZpY2VfZ2V0X3NvZnRjKEdSQU5EUEFSRU5UKHJlcXVl c3QtPmRldikpOwotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRj KGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3QtPmRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5l bCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7CiAgICAgaW50IG9mZnNl dCA9IChjaC0+dW5pdCA+IDMgPyAweDMwMDE0IDogMHgyMDAxNCk7CiAgICAgdV9pbnQzMl90IGlj ciA9IEFUQV9JTkwoY3Rsci0+cl9yZXMxLCBvZmZzZXQpOwogICAgIGludCByZXM7CkBAIC0yNzk3 LDcgKzMyNDQsNyBAQCBhdGFfbWFydmVsbF9lZG1hX2VuZF90cmFuc2FjdGlvbihzdHJ1Y3QgCiAJ cnNwX291dCAmPSAweGZmZmZmZjAwOwogCXJzcF9vdXQgKz0gKHNsb3QgPDwgMyk7CiAJcmVzcG9u c2UgPSAoc3RydWN0IGF0YV9tYXJ2ZWxsX3Jlc3BvbnNlICopCi0JCSAgIChjaC0+ZG1hLT53b3Jr ICsgMTAyNCArIChzbG90IDw8IDMpKTsKKwkJICAgKGNoLT5kbWEud29yayArIDEwMjQgKyAoc2xv dCA8PCAzKSk7CiAKIAkvKiByZWNvcmQgc3RhdHVzIGZvciB0aGlzIHJlcXVlc3QgKi8KIAlyZXF1 ZXN0LT5zdGF0dXMgPSByZXNwb25zZS0+ZGV2X3N0YXR1czsKQEAgLTI4MTIsNyArMzI1OSw3IEBA IGF0YV9tYXJ2ZWxsX2VkbWFfZW5kX3RyYW5zYWN0aW9uKHN0cnVjdCAKIAkgICAgcmVxdWVzdC0+ ZG9uZWNvdW50ID0gcmVxdWVzdC0+Ynl0ZWNvdW50OwogCiAJLyogdW5sb2FkIFNHIGxpc3QgKi8K LQljaC0+ZG1hLT51bmxvYWQoY2gtPmRldik7CisJY2gtPmRtYS51bmxvYWQocmVxdWVzdCk7CiAK IAlyZXMgPSBBVEFfT1BfRklOSVNIRUQ7CiAgICAgfQpAQCAtMjg4MywxNyArMzMzMCwxNSBAQCBh dGFfbWFydmVsbF9lZG1hX2RtYWluaXQoZGV2aWNlX3QgZGV2KQogICAgIHN0cnVjdCBhdGFfY2hh bm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKICAgICBhdGFfZG1haW5pdChkZXYp OwotICAgIGlmIChjaC0+ZG1hKSB7Ci0JLyogbm90ZSBzdGFydCBhbmQgc3RvcCBhcmUgbm90IHVz ZWQgaGVyZSAqLwotCWNoLT5kbWEtPnNldHByZCA9IGF0YV9tYXJ2ZWxsX2VkbWFfZG1hc2V0cHJk OworICAgIC8qIG5vdGUgc3RhcnQgYW5kIHN0b3AgYXJlIG5vdCB1c2VkIGhlcmUgKi8KKyAgICBj aC0+ZG1hLnNldHByZCA9IGF0YV9tYXJ2ZWxsX2VkbWFfZG1hc2V0cHJkOwogCQotCS8qIGlmIDY0 Yml0IHN1cHBvcnQgcHJlc2VudCBhZGp1c3QgbWF4IGFkZHJlc3MgdXNlZCAqLwotCWlmIChBVEFf SU5MKGN0bHItPnJfcmVzMSwgMHgwMGQwMCkgJiAweDAwMDAwMDA0KQotCSAgICBjaC0+ZG1hLT5t YXhfYWRkcmVzcyA9IEJVU19TUEFDRV9NQVhBRERSOworICAgIC8qIGlmIDY0Yml0IHN1cHBvcnQg cHJlc2VudCBhZGp1c3QgbWF4IGFkZHJlc3MgdXNlZCAqLworICAgIGlmIChBVEFfSU5MKGN0bHIt PnJfcmVzMSwgMHgwMGQwMCkgJiAweDAwMDAwMDA0KQorCWNoLT5kbWEubWF4X2FkZHJlc3MgPSBC VVNfU1BBQ0VfTUFYQUREUjsKIAotCS8qIGNoaXAgZG9lcyBub3QgcmVsaWFibHkgZG8gNjRLIERN QSB0cmFuc2ZlcnMgKi8KLQljaC0+ZG1hLT5tYXhfaW9zaXplID0gMTI2ICogREVWX0JTSVpFOyAK LSAgICB9CisgICAgLyogY2hpcCBkb2VzIG5vdCByZWxpYWJseSBkbyA2NEsgRE1BIHRyYW5zZmVy cyAqLworICAgIGNoLT5kbWEubWF4X2lvc2l6ZSA9IDEyNiAqIERFVl9CU0laRTsgCiB9CiAKIApA QCAtMjkzMiw3ICszMzc3LDcgQEAgYXRhX25hdGlvbmFsX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBp bnQgbQogICAgIGRldmljZV90IGdwYXJlbnQgPSBHUkFORFBBUkVOVChkZXYpOwogICAgIHN0cnVj dCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRl dikpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7Ci0gICAgaW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVu aXQpOworICAgIGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAg ICB1X2ludDMyX3QgcGlvdGltaW5nW10gPQogCXsgMHg5MTcyZDEzMiwgMHgyMTcxNzEyMSwgMHgw MDgwMzAyMCwgMHgyMDEwMjAxMCwgMHgwMDEwMDAxMCwKIAkgIDB4MDA4MDMwMjAsIDB4MjAxMDIw MTAsIDB4MDAxMDAwMTAsCkBAIC0yOTQxLDggKzMzODYsOCBAQCBhdGFfbmF0aW9uYWxfc2V0bW9k ZShkZXZpY2VfdCBkZXYsIGludCBtCiAgICAgdV9pbnQzMl90IHVkbWF0aW1pbmdbXSA9IHsgMHg4 MDkyMTI1MCwgMHg4MDkxMTE0MCwgMHg4MDkxMTAzMCB9OwogICAgIGludCBlcnJvcjsKIAotICAg IGNoLT5kbWEtPmFsaWdubWVudCA9IDE2OwotICAgIGNoLT5kbWEtPm1heF9pb3NpemUgPSAxMjYg KiBERVZfQlNJWkU7CisgICAgY2gtPmRtYS5hbGlnbm1lbnQgPSAxNjsKKyAgICBjaC0+ZG1hLm1h eF9pb3NpemUgPSAxMjYgKiBERVZfQlNJWkU7CiAKICAgICBtb2RlID0gYXRhX2xpbWl0X21vZGUo ZGV2LCBtb2RlLCBBVEFfVURNQTIpOwogCkBAIC0zMTUwLDE1ICszNTk1LDIzIEBAIGF0YV9udmlk aWFfc3RhdHVzKGRldmljZV90IGRldikKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2 aWNlX2dldF9zb2Z0YyhkZXYpOwogICAgIGludCBvZmZzZXQgPSBjdGxyLT5jaGlwLT5jZmcyICYg TlY0ID8gMHgwNDQwIDogMHgwMDEwOwogICAgIGludCBzaGlmdCA9IGNoLT51bml0IDw8IChjdGxy LT5jaGlwLT5jZmcyICYgTlZRID8gNCA6IDIpOwotICAgIHVfaW50MzJfdCBpc3RhdHVzID0gQVRB X0lOTChjdGxyLT5yX3JlczIsIG9mZnNldCk7CisgICAgdV9pbnQzMl90IGlzdGF0dXM7CisKKyAg ICAvKiBnZXQgaW50ZXJydXB0IHN0YXR1cyAqLworICAgIGlmIChjdGxyLT5jaGlwLT5jZmcyICYg TlZRKQorCWlzdGF0dXMgPSBBVEFfSU5MKGN0bHItPnJfcmVzMiwgb2Zmc2V0KTsKKyAgICBlbHNl CisJaXN0YXR1cyA9IEFUQV9JTkIoY3Rsci0+cl9yZXMyLCBvZmZzZXQpOwogCiAgICAgLyogZG8g d2UgaGF2ZSBhbnkgUEhZIGV2ZW50cyA/ICovCiAgICAgaWYgKGlzdGF0dXMgJiAoMHgwYyA8PCBz aGlmdCkpCiAJYXRhX3NhdGFfcGh5X2NoZWNrX2V2ZW50cyhkZXYpOwogCiAgICAgLyogY2xlYXIg aW50ZXJydXB0KHMpICovCi0gICAgQVRBX09VVEIoY3Rsci0+cl9yZXMyLCBvZmZzZXQsCi0JICAg ICAoMHgwZiA8PCBzaGlmdCkgfCAoY3Rsci0+Y2hpcC0+Y2ZnMiAmIE5WUSA/IDB4MDBmMDAwZjAg OiAwKSk7CisgICAgaWYgKGN0bHItPmNoaXAtPmNmZzIgJiBOVlEpCisJQVRBX09VVEwoY3Rsci0+ cl9yZXMyLCBvZmZzZXQsICgweDBmIDw8IHNoaWZ0KSB8IDB4MDBmMDAwZjApOworICAgIGVsc2UK KwlBVEFfT1VUQihjdGxyLT5yX3JlczIsIG9mZnNldCwgKDB4MGYgPDwgc2hpZnQpKTsKIAogICAg IC8qIGRvIHdlIGhhdmUgYW55IGRldmljZSBhY3Rpb24gPyAqLwogICAgIHJldHVybiAoaXN0YXR1 cyAmICgweDAxIDw8IHNoaWZ0KSk7CkBAIC0zNDA4LDcgKzM4NjEsNyBAQCBzYXRhaWk6CiAJLyog Y2xlYXIgU0FUQSBzdGF0dXMgYW5kIHVubWFzayBpbnRlcnJ1cHRzICovCiAJQVRBX09VVEwoY3Rs ci0+cl9yZXMyLCBzdGF0X3JlZywgMHgwMDAwMDBmZik7CiAKLQkvKiBlbmFibGUgImxvbmcgYnVy c3QgbGVuZ2h0IiBvbiBnZW4yIGNoaXBzICovCisJLyogZW5hYmxlICJsb25nIGJ1cnN0IGxlbmd0 aCIgb24gZ2VuMiBjaGlwcyAqLwogCWlmICgoY3Rsci0+Y2hpcC0+Y2ZnMiA9PSBQUlNBVEEyKSB8 fCAoY3Rsci0+Y2hpcC0+Y2ZnMiA9PSBQUkNNQk8yKSkKIAkgICAgQVRBX09VVEwoY3Rsci0+cl9y ZXMyLCAweDQ0LCBBVEFfSU5MKGN0bHItPnJfcmVzMiwgMHg0NCkgfCAweDIwMDApOwogCkBAIC0z NDUzLDM1ICszOTA2LDM1IEBAIGF0YV9wcm9taXNlX3N0YXR1cyhkZXZpY2VfdCBkZXYpCiB9CiAK IHN0YXRpYyBpbnQKLWF0YV9wcm9taXNlX2RtYXN0YXJ0KGRldmljZV90IGRldikKK2F0YV9wcm9t aXNlX2RtYXN0YXJ0KHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCkKIHsKLSAgICBzdHJ1Y3Qg YXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhHUkFORFBBUkVOVChk ZXYpKTsKLSAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZp Y2VfZ2V0X3BhcmVudChkZXYpKTsKLSAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ICA9IGRl dmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxy PWRldmljZV9nZXRfc29mdGMoR1JBTkRQQVJFTlQocmVxdWVzdC0+ZGV2KSk7CisgICAgc3RydWN0 IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50KTsKKyAg ICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ICA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+ ZGV2KTsKIAogICAgIGlmIChhdGFkZXYtPmZsYWdzICYgQVRBX0RfNDhCSVRfQUNUSVZFKSB7CiAJ QVRBX09VVEIoY3Rsci0+cl9yZXMxLCAweDExLAogCQkgQVRBX0lOQihjdGxyLT5yX3JlczEsIDB4 MTEpIHwgKGNoLT51bml0ID8gMHgwOCA6IDB4MDIpKTsKIAlBVEFfT1VUTChjdGxyLT5yX3JlczEs IGNoLT51bml0ID8gMHgyNCA6IDB4MjAsCi0JCSAoKGNoLT5kbWEtPmZsYWdzICYgQVRBX0RNQV9S RUFEKSA/IDB4MDUwMDAwMDAgOiAweDA2MDAwMDAwKSB8Ci0JCSAoY2gtPmRtYS0+Y3VyX2lvc2l6 ZSA+PiAxKSk7CisJCSAoKHJlcXVlc3QtPmZsYWdzICYgQVRBX1JfUkVBRCkgPyAweDA1MDAwMDAw IDogMHgwNjAwMDAwMCkgfAorCQkgKHJlcXVlc3QtPmJ5dGVjb3VudCA+PiAxKSk7CiAgICAgfQog ICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0JNU1RBVF9QT1JULCAoQVRBX0lEWF9JTkIoY2gsIEFU QV9CTVNUQVRfUE9SVCkgfAogCQkgKEFUQV9CTVNUQVRfSU5URVJSVVBUIHwgQVRBX0JNU1RBVF9F UlJPUikpKTsKLSAgICBBVEFfSURYX09VVEwoY2gsIEFUQV9CTURUUF9QT1JULCBjaC0+ZG1hLT5z Z19idXMpOworICAgIEFUQV9JRFhfT1VUTChjaCwgQVRBX0JNRFRQX1BPUlQsIHJlcXVlc3QtPmRt YS0+c2dfYnVzKTsKICAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9CTUNNRF9QT1JULAotCQkgKChj aC0+ZG1hLT5mbGFncyAmIEFUQV9ETUFfUkVBRCkgPyBBVEFfQk1DTURfV1JJVEVfUkVBRCA6IDAp IHwKKwkJICgocmVxdWVzdC0+ZmxhZ3MgJiBBVEFfUl9SRUFEKSA/IEFUQV9CTUNNRF9XUklURV9S RUFEIDogMCkgfAogCQkgQVRBX0JNQ01EX1NUQVJUX1NUT1ApOwotICAgIGNoLT5mbGFncyB8PSBB VEFfRE1BX0FDVElWRTsKKyAgICBjaC0+ZG1hLmZsYWdzIHw9IEFUQV9ETUFfQUNUSVZFOwogICAg IHJldHVybiAwOwogfQogCiBzdGF0aWMgaW50Ci1hdGFfcHJvbWlzZV9kbWFzdG9wKGRldmljZV90 IGRldikKK2F0YV9wcm9taXNlX2RtYXN0b3Aoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KQog ewotICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRj KEdSQU5EUEFSRU5UKGRldikpOwotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwotICAgIHN0cnVjdCBhdGFfZGV2aWNl ICphdGFkZXYgID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIHN0cnVjdCBhdGFfcGNpX2Nv bnRyb2xsZXIgKmN0bHI9ZGV2aWNlX2dldF9zb2Z0YyhHUkFORFBBUkVOVChyZXF1ZXN0LT5kZXYp KTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1ZXN0 LT5wYXJlbnQpOworICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgID0gZGV2aWNlX2dldF9z b2Z0YyhyZXF1ZXN0LT5kZXYpOwogICAgIGludCBlcnJvcjsKIAogICAgIGlmIChhdGFkZXYtPmZs YWdzICYgQVRBX0RfNDhCSVRfQUNUSVZFKSB7CkBAIC0zNDkzLDcgKzM5NDYsNyBAQCBhdGFfcHJv bWlzZV9kbWFzdG9wKGRldmljZV90IGRldikKICAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9CTUNN RF9QT1JULAogCQkgQVRBX0lEWF9JTkIoY2gsIEFUQV9CTUNNRF9QT1JUKSAmIH5BVEFfQk1DTURf U1RBUlRfU1RPUCk7CiAgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfQk1TVEFUX1BPUlQsIEFUQV9C TVNUQVRfSU5URVJSVVBUIHwgQVRBX0JNU1RBVF9FUlJPUik7IAotICAgIGNoLT5mbGFncyAmPSB+ QVRBX0RNQV9BQ1RJVkU7CisgICAgY2gtPmRtYS5mbGFncyAmPSB+QVRBX0RNQV9BQ1RJVkU7CiAg ICAgcmV0dXJuIGVycm9yOwogfQogCkBAIC0zNTE0LDExICszOTY3LDkgQEAgYXRhX3Byb21pc2Vf ZG1haW5pdChkZXZpY2VfdCBkZXYpCiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmlj ZV9nZXRfc29mdGMoZGV2KTsKIAogICAgIGF0YV9kbWFpbml0KGRldik7Ci0gICAgaWYgKGNoLT5k bWEpIHsKLQljaC0+ZG1hLT5zdGFydCA9IGF0YV9wcm9taXNlX2RtYXN0YXJ0OwotCWNoLT5kbWEt PnN0b3AgPSBhdGFfcHJvbWlzZV9kbWFzdG9wOwotCWNoLT5kbWEtPnJlc2V0ID0gYXRhX3Byb21p c2VfZG1hcmVzZXQ7Ci0gICAgfQorICAgIGNoLT5kbWEuc3RhcnQgPSBhdGFfcHJvbWlzZV9kbWFz dGFydDsKKyAgICBjaC0+ZG1hLnN0b3AgPSBhdGFfcHJvbWlzZV9kbWFzdG9wOworICAgIGNoLT5k bWEucmVzZXQgPSBhdGFfcHJvbWlzZV9kbWFyZXNldDsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTM1 MjgsNyArMzk3OSw3IEBAIGF0YV9wcm9taXNlX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBpbnQgbW8K ICAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0Yyhn cGFyZW50KTsKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKICAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwotICAgIGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSAr IEFUQV9ERVYoYXRhZGV2LT51bml0KTsKKyAgICBpbnQgZGV2bm8gPSAoY2gtPnVuaXQgPDwgMSkg KyBhdGFkZXYtPnVuaXQ7CiAgICAgaW50IGVycm9yOwogICAgIHVfaW50MzJfdCB0aW1pbmdzW11b Ml0gPSB7CiAgICAgLyogICAgUFJPTEQgICAgICAgUFJORVcgICAgICAgICAgICAgICAgbW9kZSAq LwpAQCAtMzY1Niw2ICs0MTA3LDkgQEAgYXRhX3Byb21pc2VfbWlvX2FsbG9jYXRlKGRldmljZV90 IGRldikKICAgICBlbHNlIHsKIAljaC0+aHcuY29tbWFuZCA9IGF0YV9wcm9taXNlX21pb19jb21t YW5kOwogCWNoLT5ody5zdGF0dXMgPSBhdGFfcHJvbWlzZV9taW9fc3RhdHVzOworCWNoLT5ody5z b2Z0cmVzZXQgPSBhdGFfcHJvbWlzZV9taW9fc29mdHJlc2V0OworCWNoLT5ody5wbV9yZWFkID0g YXRhX3Byb21pc2VfbWlvX3BtX3JlYWQ7CisJY2gtPmh3LnBtX3dyaXRlID0gYXRhX3Byb21pc2Vf bWlvX3BtX3dyaXRlOwogICAgICB9CiAgICAgcmV0dXJuIDA7CiB9CkBAIC0zNzM3LDkgKzQxOTEs OSBAQCBhdGFfcHJvbWlzZV9taW9fc3RhdHVzKGRldmljZV90IGRldikKIAkJICAgICBNX0FUQSwg TV9OT1dBSVQgfCBNX1pFUk8pKSkgewogCiAJaWYgKGJvb3R2ZXJib3NlKQotCSAgICBkZXZpY2Vf cHJpbnRmKGNoLT5kZXYsICJESVNDT05ORUNUIHJlcXVlc3RlZFxuIik7CisJICAgIGRldmljZV9w cmludGYoZGV2LCAiRElTQ09OTkVDVCByZXF1ZXN0ZWRcbiIpOwogCXRwLT5hY3Rpb24gPSBBVEFf Q19ERVRBQ0g7Ci0JdHAtPmRldiA9IGNoLT5kZXY7CisJdHAtPmRldiA9IGRldjsKIAlUQVNLX0lO SVQoJnRwLT50YXNrLCAwLCBhdGFfc2F0YV9waHlfZXZlbnQsIHRwKTsKIAl0YXNrcXVldWVfZW5x dWV1ZSh0YXNrcXVldWVfdGhyZWFkLCAmdHAtPnRhc2spOwogICAgIH0KQEAgLTM3NTEsOSArNDIw NSw5IEBAIGF0YV9wcm9taXNlX21pb19zdGF0dXMoZGV2aWNlX3QgZGV2KQogCQkgICAgIE1fQVRB LCBNX05PV0FJVCB8IE1fWkVSTykpKSB7CiAKIAlpZiAoYm9vdHZlcmJvc2UpCi0JICAgIGRldmlj ZV9wcmludGYoY2gtPmRldiwgIkNPTk5FQ1QgcmVxdWVzdGVkXG4iKTsKKwkgICAgZGV2aWNlX3By aW50ZihkZXYsICJDT05ORUNUIHJlcXVlc3RlZFxuIik7CiAJdHAtPmFjdGlvbiA9IEFUQV9DX0FU VEFDSDsKLQl0cC0+ZGV2ID0gY2gtPmRldjsKKwl0cC0+ZGV2ID0gZGV2OwogCVRBU0tfSU5JVCgm dHAtPnRhc2ssIDAsIGF0YV9zYXRhX3BoeV9ldmVudCwgdHApOwogCXRhc2txdWV1ZV9lbnF1ZXVl KHRhc2txdWV1ZV90aHJlYWQsICZ0cC0+dGFzayk7CiAgICAgfQpAQCAtMzc2NiwxMSArNDIyMCwx NiBAQCBzdGF0aWMgaW50CiBhdGFfcHJvbWlzZV9taW9fY29tbWFuZChzdHJ1Y3QgYXRhX3JlcXVl c3QgKnJlcXVlc3QpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3Rscj1kZXZp Y2VfZ2V0X3NvZnRjKEdSQU5EUEFSRU5UKHJlcXVlc3QtPmRldikpOwotICAgIHN0cnVjdCBhdGFf Y2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3Qt PmRldikpOwotICAgIHVfaW50MzJfdCAqd29yZHAgPSAodV9pbnQzMl90ICopY2gtPmRtYS0+d29y azsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1ZXN0 LT5wYXJlbnQpOworICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3Nv ZnRjKHJlcXVlc3QtPmRldik7CisKKyAgICB1X2ludDMyX3QgKndvcmRwID0gKHVfaW50MzJfdCAq KWNoLT5kbWEud29yazsKIAogICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgKGNoLT51bml0ICsg MSkgPDwgMiwgMHgwMDAwMDAwMSk7CiAKKyAgICAvKiBzZXQgcG9ydG11bHRpcGxpZXIgcG9ydCAq LworICAgIEFUQV9PVVRCKGN0bHItPnJfcmVzMiwgMHg0ZTggKyAoY2gtPnVuaXQgPDwgOCksIGF0 YWRldi0+dW5pdCAmIDB4MGYpOworCiAgICAgLyogWFhYIFNPUyBhZGQgQVRBUEkgY29tbWFuZHMg c3VwcG9ydCBsYXRlciAqLwogICAgIHN3aXRjaCAocmVxdWVzdC0+dS5hdGEuY29tbWFuZCkgewog ICAgIGRlZmF1bHQ6CkBAIC0zNzg2LDExICs0MjQ1LDExIEBAIGF0YV9wcm9taXNlX21pb19jb21t YW5kKHN0cnVjdCBhdGFfcmVxdWUKIAl3b3JkcFswXSA9IGh0b2xlMzIoMHgwMCB8ICgoY2gtPnVu aXQgKyAxKSA8PCAxNikgfCAoMHgwMCA8PCAyNCkpOwogCWJyZWFrOwogICAgIH0KLSAgICB3b3Jk cFsxXSA9IGh0b2xlMzIoY2gtPmRtYS0+c2dfYnVzKTsKKyAgICB3b3JkcFsxXSA9IGh0b2xlMzIo cmVxdWVzdC0+ZG1hLT5zZ19idXMpOwogICAgIHdvcmRwWzJdID0gMDsKICAgICBhdGFfcHJvbWlz ZV9hcGt0KCh1X2ludDhfdCopd29yZHAsIHJlcXVlc3QpOwogCi0gICAgQVRBX09VVEwoY3Rsci0+ cl9yZXMyLCAweDAyNDAgKyAoY2gtPnVuaXQgPDwgNyksIGNoLT5kbWEtPndvcmtfYnVzKTsKKyAg ICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIDB4MDI0MCArIChjaC0+dW5pdCA8PCA3KSwgY2gtPmRt YS53b3JrX2J1cyk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTM4NTksNyArNDMxOCw3IEBAIGF0 YV9wcm9taXNlX21pb19yZXNldChkZXZpY2VfdCBkZXYpCiAJaWYgKChjdGxyLT5jaGlwLT5jZmcy ID09IFBSU0FUQTIpIHx8CiAJICAgICgoY3Rsci0+Y2hpcC0+Y2ZnMiA9PSBQUkNNQk8yKSAmJiAo Y2gtPnVuaXQgPCAyKSkpIHsKIAkgICAgLyogc2V0IHBvcnRtdWx0aXBsaWVyIHBvcnQgKi8KLQkg ICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCAweDRlOCArIChjaC0+dW5pdCA8PCA4KSwgMHgwZik7 CisJICAgIC8vQVRBX09VVEwoY3Rsci0+cl9yZXMyLCAweDRlOCArIChjaC0+dW5pdCA8PCA4KSwg MHgwZik7CiAKIAkgICAgLyogbWFzayBwbHVnL3VucGx1ZyBpbnRyICovCiAJICAgIEFUQV9PVVRM KGN0bHItPnJfcmVzMiwgMHgwNjAsICgweDAwMTEwMDAwIDw8IGNoLT51bml0KSk7CkBAIC0zODgw LDEzICs0MzM5LDM5IEBAIGF0YV9wcm9taXNlX21pb19yZXNldChkZXZpY2VfdCBkZXYpCiAJCSAg ICAgKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCAweDQxNCArIChjaC0+dW5pdCA8PCA4KSkgJgogCQkg ICAgIH4weDAwMDAwMDAzKSB8IDB4MDAwMDAwMDEpOwogCi0JICAgIGlmIChhdGFfc2F0YV9waHlf cmVzZXQoZGV2KSkKLQkJYXRhX2dlbmVyaWNfcmVzZXQoZGV2KTsKKwkgICAgaWYgKGF0YV9zYXRh X3BoeV9yZXNldChkZXYpKSB7CisJCXVfaW50MzJfdCBzaWduYXR1cmUgPSBjaC0+aHcuc29mdHJl c2V0KGRldiwgQVRBX1BNKTsKKworCQlpZiAoMSB8IGJvb3R2ZXJib3NlKQorICAgICAgICAJICAg IGRldmljZV9wcmludGYoZGV2LCAiU0lHTkFUVVJFOiAlMDh4XG4iLCBzaWduYXR1cmUpOworCisJ CXN3aXRjaCAoc2lnbmF0dXJlKSB7CisJCWNhc2UgMHgwMDAwMDEwMToKKwkJICAgIGNoLT5kZXZp Y2VzID0gQVRBX0FUQV9NQVNURVI7CisJCSAgICBicmVhazsKKwkJY2FzZSAweDk2NjkwMTAxOgor CQkgICAgY2gtPmRldmljZXMgPSBBVEFfUE9SVE1VTFRJUExJRVI7CisJCSAgICBhdGFfcG1faWRl bnRpZnkoZGV2KTsKKwkJICAgIGJyZWFrOworCQljYXNlIDB4ZWIxNDAxMDE6CisJCSAgICBjaC0+ ZGV2aWNlcyA9IEFUQV9BVEFQSV9NQVNURVI7CisJCSAgICBicmVhazsKKwkJZGVmYXVsdDogLyog U09TIFhYWCAqLworCQkgICAgaWYgKGJvb3R2ZXJib3NlKQorCQkJZGV2aWNlX3ByaW50ZihkZXYs CisJCQkJICAgICAgIk5vIHNpZ25hdHVyZSwgYXN1bWluZyBkaXNrIGRldmljZVxuIik7CisJCSAg ICBjaC0+ZGV2aWNlcyA9IEFUQV9BVEFfTUFTVEVSOworCQl9CisJCWlmIChib290dmVyYm9zZSkK KwkJICAgIGRldmljZV9wcmludGYoZGV2LCAicHJvbWlzZV9taW9fcmVzZXQgZGV2aWNlcz0lMDh4 XG4iLAorCQkgICAgCQkgIGNoLT5kZXZpY2VzKTsKKworCSAgICB9CiAKIAkgICAgLyogcmVzZXQg YW5kIGVuYWJsZSBwbHVnL3VucGx1ZyBpbnRyICovCiAJICAgIEFUQV9PVVRMKGN0bHItPnJfcmVz MiwgMHgwNjAsICgweDAwMDAwMDExIDw8IGNoLT51bml0KSk7CiAKLQkgICAgLyogc2V0IHBvcnRt dWx0aXBsaWVyIHBvcnQgKi8KKwkgICAgLy8vKiBzZXQgcG9ydG11bHRpcGxpZXIgcG9ydCAqLwog CSAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIDB4NGU4ICsgKGNoLT51bml0IDw8IDgpLCAweDAw KTsKIAl9CiAJZWxzZQpAQCAtMzg5NiwxNSArNDM4MSwxMjcgQEAgYXRhX3Byb21pc2VfbWlvX3Jl c2V0KGRldmljZV90IGRldikKICAgICB9CiB9CiAKK3N0YXRpYyBpbnQKK2F0YV9wcm9taXNlX21p b19wbV9yZWFkKGRldmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCAqcmVz dWx0KQoreworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0 X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAq Y2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisgICAgaW50IHRpbWVvdXQgPSAwOworCisgICAg Lyogc2V0IHBvcnRtdWx0aXBsaWVyIHBvcnQgKi8KKyAgICBBVEFfT1VUQihjdGxyLT5yX3JlczIs IDB4NGU4ICsgKGNoLT51bml0IDw8IDgpLCAweDBmKTsKKworICAgIEFUQV9JRFhfT1VUQihjaCwg QVRBX0ZFQVRVUkUsIHJlZyk7CisgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIHBvcnQp OworCisgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfQ09NTUFORCwgQVRBX1JFQURfUE0pOworCisg ICAgd2hpbGUgKHRpbWVvdXQgPCAxMDAwMDAwKSB7CisJdV9pbnQ4X3Qgc3RhdHVzID0gQVRBX0lE WF9JTkIoY2gsIEFUQV9TVEFUVVMpOworCWlmICghKHN0YXR1cyAmIEFUQV9TX0JVU1kpKQorCSAg ICBicmVhazsKKwl0aW1lb3V0ICs9IDEwMDA7CisJREVMQVkoMTAwMCk7CisgICAgfQorICAgIGlm ICh0aW1lb3V0ID49IDEwMDAwMDApCisJcmV0dXJuIEFUQV9FX0FCT1JUOworCisgICAgKnJlc3Vs dCA9IEFUQV9JRFhfSU5CKGNoLCBBVEFfQ09VTlQpIHwKKwkgICAgICAoQVRBX0lEWF9JTkIoY2gs IEFUQV9TRUNUT1IpIDw8IDgpIHwKKwkgICAgICAoQVRBX0lEWF9JTkIoY2gsIEFUQV9DWUxfTFNC KSA8PCAxNikgfAorCSAgICAgIChBVEFfSURYX0lOQihjaCwgQVRBX0NZTF9NU0IpIDw8IDI0KTsK KyAgICByZXR1cm4gMDsKK30KKworc3RhdGljIGludAorYXRhX3Byb21pc2VfbWlvX3BtX3dyaXRl KGRldmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCB2YWx1ZSkKK3sKKyAg ICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZp Y2VfZ2V0X3BhcmVudChkZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNl X2dldF9zb2Z0YyhkZXYpOworICAgIGludCB0aW1lb3V0ID0gMDsKKworICAgIC8qIHNldCBwb3J0 bXVsdGlwbGllciBwb3J0ICovCisgICAgQVRBX09VVEIoY3Rsci0+cl9yZXMyLCAweDRlOCArIChj aC0+dW5pdCA8PCA4KSwgMHgwZik7CisKKyAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9GRUFUVVJF LCByZWcpOworICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLCBwb3J0KTsKKyAgICBBVEFf SURYX09VVEIoY2gsIEFUQV9DT1VOVCwgdmFsdWUgJiAweGZmKTsKKyAgICBBVEFfSURYX09VVEIo Y2gsIEFUQV9TRUNUT1IsICh2YWx1ZSA+PiA4KSAmIDB4ZmYpOworICAgIEFUQV9JRFhfT1VUQihj aCwgQVRBX0NZTF9MU0IsICh2YWx1ZSA+PiAxNikgJiAweGZmKTsKKyAgICBBVEFfSURYX09VVEIo Y2gsIEFUQV9DWUxfTVNCLCAodmFsdWUgPj4gMjQpICYgMHhmZik7CisKKyAgICBBVEFfSURYX09V VEIoY2gsIEFUQV9DT01NQU5ELCBBVEFfV1JJVEVfUE0pOworCisgICAgd2hpbGUgKHRpbWVvdXQg PCAxMDAwMDAwKSB7CisJdV9pbnQ4X3Qgc3RhdHVzID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9TVEFU VVMpOworCWlmICghKHN0YXR1cyAmIEFUQV9TX0JVU1kpKQorCSAgICBicmVhazsKKwl0aW1lb3V0 ICs9IDEwMDA7CisJREVMQVkoMTAwMCk7CisgICAgfQorICAgIGlmICh0aW1lb3V0ID49IDEwMDAw MDApCisJcmV0dXJuIEFUQV9FX0FCT1JUOworCisgICAgcmV0dXJuIEFUQV9JRFhfSU5CKGNoLCBB VEFfRVJST1IpOworfQorCisvKiBtdXN0IGJlIGNhbGxlZCB3aXRoIEFUQSBjaGFubmVsIGxvY2tl ZCBhbmQgc3RhdGVfbXR4IGhlbGQgKi8KK3N0YXRpYyB1X2ludDMyX3QKK2F0YV9wcm9taXNlX21p b19zb2Z0cmVzZXQoZGV2aWNlX3QgZGV2LCBpbnQgcG9ydCkKK3sKKyAgICBzdHJ1Y3QgYXRhX3Bj aV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChk ZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OworICAgIGludCB0aW1lb3V0OworCisgICAgLyogc2V0IHBvcnRtdWx0aXBsaWVyIHBvcnQgKi8K KyAgICBBVEFfT1VUQihjdGxyLT5yX3JlczIsIDB4NGU4ICsgKGNoLT51bml0IDw8IDgpLCBwb3J0 ICYgMHgwZik7CisKKyAgICAvKiBzb2Z0cmVzZXQgZGV2aWNlIG9uIHRoaXMgY2hhbm5lbCAqLwor ICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLCBBVEFfRF9JQk0gfCBBVEFfRF9MQkEgfCBB VEFfREVWKEFUQV9NQVNURVIpKTsKKyAgICBERUxBWSgxMCk7CisgICAgQVRBX0lEWF9PVVRCKGNo LCBBVEFfQ09OVFJPTCwgQVRBX0FfSURTIHwgQVRBX0FfUkVTRVQpOworICAgIGF0YV91ZGVsYXko MTAwMDApOyAKKyAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9DT05UUk9MLCBBVEFfQV9JRFMpOwor ICAgIGF0YV91ZGVsYXkoMTUwMDAwKTsKKyAgICBBVEFfSURYX0lOQihjaCwgQVRBX0VSUk9SKTsK KworICAgIC8qIHdhaXQgZm9yIEJVU1kgdG8gZ28gaW5hY3RpdmUgKi8KKyAgICBmb3IgKHRpbWVv dXQgPSAwOyB0aW1lb3V0IDwgMTAwOyB0aW1lb3V0KyspIHsKKwl1X2ludDhfdCBlcnIsIHN0YXQ7 CisKKwllcnIgPSBBVEFfSURYX0lOQihjaCwgQVRBX0VSUk9SKTsKKwlzdGF0ID0gQVRBX0lEWF9J TkIoY2gsIEFUQV9TVEFUVVMpOworCisJLy9pZiAoc3RhdCA9PSBlcnIgJiYgdGltZW91dCA+IChz dGF0ICYgQVRBX1NfQlVTWSA/IDEwMCA6IDEwKSkKKwkgICAgLy9icmVhazsKKworCWlmICghKHN0 YXQgJiBBVEFfU19CVVNZKSkgeworCSAgICAvL2lmICgoZXJyICYgMHg3ZikgPT0gQVRBX0VfSUxJ KSB7CisJCXJldHVybiBBVEFfSURYX0lOQihjaCwgQVRBX0NPVU5UKSB8CisJCSAgICAgICAoQVRB X0lEWF9JTkIoY2gsIEFUQV9TRUNUT1IpIDw8IDgpIHwKKwkJICAgICAgIChBVEFfSURYX0lOQihj aCwgQVRBX0NZTF9MU0IpIDw8IDE2KSB8CisJCSAgICAgICAoQVRBX0lEWF9JTkIoY2gsIEFUQV9D WUxfTVNCKSA8PCAyNCk7CisJICAgIC8vfQorCSAgICAvL2Vsc2UgaWYgKHN0YXQgJiAweDBmKSB7 CisJCS8vc3RhdCB8PSBBVEFfU19CVVNZOworCSAgICAvL30KKwl9CisKKwlpZiAoIShzdGF0ICYg QVRBX1NfQlVTWSkgfHwgKHN0YXQgPT0gMHhmZiAmJiB0aW1lb3V0ID4gMTApKQorCSAgICBicmVh azsKKwlhdGFfdWRlbGF5KDEwMDAwMCk7CisgICAgfQorICAgIHJldHVybiAtMTsKK30KKwogc3Rh dGljIHZvaWQKIGF0YV9wcm9taXNlX21pb19kbWFpbml0KGRldmljZV90IGRldikKIHsKICAgICBz dHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogCi0gICAgLyog bm90ZSBzdGFydCBhbmQgc3RvcCBhcmUgbm90IHVzZWQgaGVyZSAqLwogICAgIGF0YV9kbWFpbml0 KGRldik7Ci0gICAgaWYgKGNoLT5kbWEpIAotCWNoLT5kbWEtPnNldHByZCA9IGF0YV9wcm9taXNl X21pb19zZXRwcmQ7CisgICAgLyogbm90ZSBzdGFydCBhbmQgc3RvcCBhcmUgbm90IHVzZWQgaGVy ZSAqLworICAgIGNoLT5kbWEuc2V0cHJkID0gYXRhX3Byb21pc2VfbWlvX3NldHByZDsKIH0KIAog CkBAIC0zOTkwLDggKzQ1ODcsOCBAQCBhdGFfcHJvbWlzZV9zeDRfY29tbWFuZChzdHJ1Y3QgYXRh X3JlcXVlCiB7CiAgICAgZGV2aWNlX3QgZ3BhcmVudCA9IEdSQU5EUEFSRU5UKHJlcXVlc3QtPmRl dik7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRfc29m dGMoZ3BhcmVudCk7Ci0gICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29m dGMoZGV2aWNlX2dldF9wYXJlbnQocmVxdWVzdC0+ZGV2KSk7Ci0gICAgc3RydWN0IGF0YV9kbWFf cHJkZW50cnkgKnByZCA9IGNoLT5kbWEtPnNnOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2gg PSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7CisgICAgc3RydWN0IGF0YV9kbWFf cHJkZW50cnkgKnByZCA9IHJlcXVlc3QtPmRtYS0+c2c7CiAgICAgY2FkZHJfdCB3aW5kb3cgPSBy bWFuX2dldF92aXJ0dWFsKGN0bHItPnJfcmVzMSk7CiAgICAgdV9pbnQzMl90ICp3b3JkcDsKICAg ICBpbnQgaSwgaWR4LCBsZW5ndGggPSAwOwpAQCAtNDA5OCw3ICs0Njk1LDcgQEAgYXRhX3Byb21p c2VfYXBrdCh1X2ludDhfdCAqYnl0ZXAsIHN0cnVjdAogICAgIGludCBpID0gMTI7CiAKICAgICBi eXRlcFtpKytdID0gQVRBX1BEQ18xQiB8IEFUQV9QRENfV1JJVEVfUkVHIHwgQVRBX1BEQ19XQUlU X05CVVNZfEFUQV9EUklWRTsKLSAgICBieXRlcFtpKytdID0gQVRBX0RfSUJNIHwgQVRBX0RfTEJB IHwgYXRhZGV2LT51bml0OworICAgIGJ5dGVwW2krK10gPSBBVEFfRF9JQk0gfCBBVEFfRF9MQkEg fCBBVEFfREVWKGF0YWRldi0+dW5pdCk7CiAgICAgYnl0ZXBbaSsrXSA9IEFUQV9QRENfMUIgfCBB VEFfUERDX1dSSVRFX0NUTDsKICAgICBieXRlcFtpKytdID0gQVRBX0FfNEJJVDsKIApAQCAtNDEx OSw3ICs0NzE2LDcgQEAgYXRhX3Byb21pc2VfYXBrdCh1X2ludDhfdCAqYnl0ZXAsIHN0cnVjdAog CWJ5dGVwW2krK10gPSByZXF1ZXN0LT51LmF0YS5sYmEgPj4gNDA7CiAJYnl0ZXBbaSsrXSA9IHJl cXVlc3QtPnUuYXRhLmxiYSA+PiAxNjsKIAlieXRlcFtpKytdID0gQVRBX1BEQ18xQiB8IEFUQV9Q RENfV1JJVEVfUkVHIHwgQVRBX0RSSVZFOwotCWJ5dGVwW2krK10gPSBBVEFfRF9MQkEgfCBhdGFk ZXYtPnVuaXQ7CisJYnl0ZXBbaSsrXSA9IEFUQV9EX0xCQSB8IEFUQV9ERVYoYXRhZGV2LT51bml0 KTsKICAgICB9CiAgICAgZWxzZSB7CiAJYnl0ZXBbaSsrXSA9IEFUQV9QRENfMUIgfCBBVEFfUERD X1dSSVRFX1JFRyB8IEFUQV9GRUFUVVJFOwpAQCAtNDEzNCw3ICs0NzMxLDggQEAgYXRhX3Byb21p c2VfYXBrdCh1X2ludDhfdCAqYnl0ZXAsIHN0cnVjdAogCWJ5dGVwW2krK10gPSByZXF1ZXN0LT51 LmF0YS5sYmEgPj4gMTY7CiAJYnl0ZXBbaSsrXSA9IEFUQV9QRENfMUIgfCBBVEFfUERDX1dSSVRF X1JFRyB8IEFUQV9EUklWRTsKIAlieXRlcFtpKytdID0gKGF0YWRldi0+ZmxhZ3MgJiBBVEFfRF9V U0VfQ0hTID8gMCA6IEFUQV9EX0xCQSkgfAotCQkgICBBVEFfRF9JQk0gfCBhdGFkZXYtPnVuaXQg fCAoKHJlcXVlc3QtPnUuYXRhLmxiYSA+PiAyNCkmMHhmKTsKKwkJICAgICBBVEFfRF9JQk0gfCBB VEFfREVWKGF0YWRldi0+dW5pdCkgfAorCQkgICAgICgocmVxdWVzdC0+dS5hdGEubGJhID4+IDI0 KSYweGYpOwogICAgIH0KICAgICBieXRlcFtpKytdID0gQVRBX1BEQ18xQiB8IEFUQV9QRENfV1JJ VEVfRU5EIHwgQVRBX0NPTU1BTkQ7CiAgICAgYnl0ZXBbaSsrXSA9IHJlcXVlc3QtPnUuYXRhLmNv bW1hbmQ7CkBAIC00Mjk0LDggKzQ4OTIsNyBAQCBhdGFfc2VydmVyd29ya3NfYWxsb2NhdGUoZGV2 aWNlX3QgZGV2KQogICAgIGNoLT5ody50Zl93cml0ZSA9IGF0YV9zZXJ2ZXJ3b3Jrc190Zl93cml0 ZTsKIAogICAgIC8qIGNoaXAgZG9lcyBub3QgcmVsaWFibHkgZG8gNjRLIERNQSB0cmFuc2ZlcnMg Ki8KLSAgICBpZiAoY2gtPmRtYSkKLQljaC0+ZG1hLT5tYXhfaW9zaXplID0gMTI2ICogREVWX0JT SVpFOworICAgIGNoLT5kbWEubWF4X2lvc2l6ZSA9IDEyNiAqIERFVl9CU0laRTsKIAogICAgIHJl dHVybiAwOwogfQpAQCAtNDMwMyw3ICs0OTAwLDcgQEAgYXRhX3NlcnZlcndvcmtzX2FsbG9jYXRl KGRldmljZV90IGRldikKIHN0YXRpYyB2b2lkCiBhdGFfc2VydmVyd29ya3NfdGZfcmVhZChzdHJ1 Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiB7Ci0gICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9 IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQocmVxdWVzdC0+ZGV2KSk7CisgICAg c3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50 KTsKICAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1 ZXN0LT5kZXYpOwogCiAgICAgaWYgKGF0YWRldi0+ZmxhZ3MgJiBBVEFfRF80OEJJVF9BQ1RJVkUp IHsKQEAgLTQzMzIsNyArNDkyOSw3IEBAIGF0YV9zZXJ2ZXJ3b3Jrc190Zl9yZWFkKHN0cnVjdCBh dGFfcmVxdWUKIHN0YXRpYyB2b2lkCiBhdGFfc2VydmVyd29ya3NfdGZfd3JpdGUoc3RydWN0IGF0 YV9yZXF1ZXN0ICpyZXF1ZXN0KQogewotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3QtPmRldikpOworICAgIHN0cnVj dCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7CiAg ICAgc3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+ ZGV2KTsKIAogICAgIGlmIChhdGFkZXYtPmZsYWdzICYgQVRBX0RfNDhCSVRfQUNUSVZFKSB7CkBA IC00MzQ0LDcgKzQ5NDEsNyBAQCBhdGFfc2VydmVyd29ya3NfdGZfd3JpdGUoc3RydWN0IGF0YV9y ZXF1CiAJCQkJICAgICAgICgocmVxdWVzdC0+dS5hdGEubGJhID4+IDgpICYgMHgwMGZmKSk7CiAJ QVRBX0lEWF9PVVRXKGNoLCBBVEFfQ1lMX01TQiwgKChyZXF1ZXN0LT51LmF0YS5sYmEgPj4gMzIp ICYgMHhmZjAwKSB8IAogCQkJCSAgICAgICAoKHJlcXVlc3QtPnUuYXRhLmxiYSA+PiAxNikgJiAw eDAwZmYpKTsKLQlBVEFfSURYX09VVFcoY2gsIEFUQV9EUklWRSwgQVRBX0RfTEJBIHwgYXRhZGV2 LT51bml0KTsKKwlBVEFfSURYX09VVFcoY2gsIEFUQV9EUklWRSwgQVRBX0RfTEJBIHwgQVRBX0RF VihhdGFkZXYtPnVuaXQpKTsKICAgICB9CiAgICAgZWxzZSB7CiAJQVRBX0lEWF9PVVRXKGNoLCBB VEFfRkVBVFVSRSwgcmVxdWVzdC0+dS5hdGEuZmVhdHVyZSk7CkBAIC00MzY1LDcgKzQ5NjIsNyBA QCBhdGFfc2VydmVyd29ya3NfdGZfd3JpdGUoc3RydWN0IGF0YV9yZXF1CiAJCQkgKHJlcXVlc3Qt PnUuYXRhLmxiYSAvIChzZWN0b3JzICogaGVhZHMpKSk7CiAJICAgIEFUQV9JRFhfT1VUVyhjaCwg QVRBX0NZTF9NU0IsCiAJCQkgKHJlcXVlc3QtPnUuYXRhLmxiYSAvIChzZWN0b3JzICogaGVhZHMp KSA+PiA4KTsKLQkgICAgQVRBX0lEWF9PVVRXKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IGF0 YWRldi0+dW5pdCB8IAorCSAgICBBVEFfSURYX09VVFcoY2gsIEFUQV9EUklWRSwgQVRBX0RfSUJN IHwgQVRBX0RFVihhdGFkZXYtPnVuaXQpIHwgCiAJCQkgKCgocmVxdWVzdC0+dS5hdGEubGJhJSAo c2VjdG9ycyAqIGhlYWRzKSkgLwogCQkJICAgc2VjdG9ycykgJiAweGYpKTsKIAl9CkBAIC00Mzc0 LDcgKzQ5NzEsNyBAQCBhdGFfc2VydmVyd29ya3NfdGZfd3JpdGUoc3RydWN0IGF0YV9yZXF1CiAJ ICAgIEFUQV9JRFhfT1VUVyhjaCwgQVRBX0NZTF9MU0IsIHJlcXVlc3QtPnUuYXRhLmxiYSA+PiA4 KTsKIAkgICAgQVRBX0lEWF9PVVRXKGNoLCBBVEFfQ1lMX01TQiwgcmVxdWVzdC0+dS5hdGEubGJh ID4+IDE2KTsKIAkgICAgQVRBX0lEWF9PVVRXKGNoLCBBVEFfRFJJVkUsCi0JCQkgQVRBX0RfSUJN IHwgQVRBX0RfTEJBIHwgYXRhZGV2LT51bml0IHwKKwkJCSBBVEFfRF9JQk0gfCBBVEFfRF9MQkEg fCBBVEFfREVWKGF0YWRldi0+dW5pdCkgfAogCQkJICgocmVxdWVzdC0+dS5hdGEubGJhID4+IDI0 KSAmIDB4MGYpKTsKIAl9CiAgICAgfQpAQCAtNDM4Nyw3ICs0OTg0LDcgQEAgYXRhX3NlcnZlcndv cmtzX3NldG1vZGUoZGV2aWNlX3QgZGV2LCBpbgogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xs ZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfY2hh bm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwogICAg IHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAg aW50IGRldm5vID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAg IGludCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQgb2Zm c2V0ID0gKGRldm5vIF4gMHgwMSkgPDwgMzsKICAgICBpbnQgZXJyb3I7CiAgICAgdV9pbnQ4X3Qg cGlvdGltaW5nc1tdID0geyAweDVkLCAweDQ3LCAweDM0LCAweDIyLCAweDIwLCAweDM0LCAweDIy LCAweDIwLApAQCAtNDQ0OSwyMSArNTA0NiwyMSBAQCBhdGFfc2lpX2lkZW50KGRldmljZV90IGRl dikKIHsKICAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9z b2Z0YyhkZXYpOwogICAgIHN0YXRpYyBzdHJ1Y3QgYXRhX2NoaXBfaWQgaWRzW10gPQotICAgIHt7 IEFUQV9TSUkzMTE0LCAgIDB4MDAsIFNJSU1FTUlPLCBTSUk0Q0gsICAgIEFUQV9TQTE1MCwgIlNp SSAzMTE0IiB9LAotICAgICB7IEFUQV9TSUkzNTEyLCAgIDB4MDIsIFNJSU1FTUlPLCAwLCAgICAg ICAgIEFUQV9TQTE1MCwgIlNpSSAzNTEyIiB9LAotICAgICB7IEFUQV9TSUkzMTEyLCAgIDB4MDIs IFNJSU1FTUlPLCAwLCAgICAgICAgIEFUQV9TQTE1MCwgIlNpSSAzMTEyIiB9LAotICAgICB7IEFU QV9TSUkzMTEyXzEsIDB4MDIsIFNJSU1FTUlPLCAwLCAgICAgICAgIEFUQV9TQTE1MCwgIlNpSSAz MTEyIiB9LAotICAgICB7IEFUQV9TSUkzNTEyLCAgIDB4MDAsIFNJSU1FTUlPLCBTSUlCVUcsICAg IEFUQV9TQTE1MCwgIlNpSSAzNTEyIiB9LAotICAgICB7IEFUQV9TSUkzMTEyLCAgIDB4MDAsIFNJ SU1FTUlPLCBTSUlCVUcsICAgIEFUQV9TQTE1MCwgIlNpSSAzMTEyIiB9LAotICAgICB7IEFUQV9T SUkzMTEyXzEsIDB4MDAsIFNJSU1FTUlPLCBTSUlCVUcsICAgIEFUQV9TQTE1MCwgIlNpSSAzMTEy IiB9LAotICAgICB7IEFUQV9TSUkzMTI0LCAgIDB4MDAsIFNJSVBSQklPLCBTSUk0Q0gsICAgIEFU QV9TQTMwMCwgIlNpSSAzMTI0IiB9LAotICAgICB7IEFUQV9TSUkzMTMyLCAgIDB4MDAsIFNJSVBS QklPLCAwLCAgICAgICAgIEFUQV9TQTMwMCwgIlNpSSAzMTMyIiB9LAotICAgICB7IEFUQV9TSUkz MTMyXzEsIDB4MDAsIFNJSVBSQklPLCAwLCAgICAgICAgIEFUQV9TQTMwMCwgIlNpSSAzMTMyIiB9 LAotICAgICB7IEFUQV9TSUkwNjgwLCAgIDB4MDAsIFNJSU1FTUlPLCBTSUlTRVRDTEssIEFUQV9V RE1BNiwgIlNpSSAwNjgwIiB9LAotICAgICB7IEFUQV9DTUQ2NDksICAgIDB4MDAsIDAsICAgICAg ICBTSUlJTlRSLCAgIEFUQV9VRE1BNSwgIkNNRCA2NDkiIH0sCi0gICAgIHsgQVRBX0NNRDY0OCwg ICAgMHgwMCwgMCwgICAgICAgIFNJSUlOVFIsICAgQVRBX1VETUE0LCAiQ01EIDY0OCIgfSwKLSAg ICAgeyBBVEFfQ01ENjQ2LCAgICAweDA3LCAwLCAgICAgICAgMCwgICAgICAgICBBVEFfVURNQTIs ICJDTUQgNjQ2VTIiIH0sCi0gICAgIHsgQVRBX0NNRDY0NiwgICAgMHgwMCwgMCwgICAgICAgIDAs ICAgICAgICAgQVRBX1dETUEyLCAiQ01EIDY0NiIgfSwKKyAgICB7eyBBVEFfU0lJMzExNCwgICAw eDAwLCBTSUlNRU1JTywgU0lJNENILCAgICBBVEFfU0ExNTAsICIzMTE0IiB9LAorICAgICB7IEFU QV9TSUkzNTEyLCAgIDB4MDIsIFNJSU1FTUlPLCAwLCAgICAgICAgIEFUQV9TQTE1MCwgIjM1MTIi IH0sCisgICAgIHsgQVRBX1NJSTMxMTIsICAgMHgwMiwgU0lJTUVNSU8sIDAsICAgICAgICAgQVRB X1NBMTUwLCAiMzExMiIgfSwKKyAgICAgeyBBVEFfU0lJMzExMl8xLCAweDAyLCBTSUlNRU1JTywg MCwgICAgICAgICBBVEFfU0ExNTAsICIzMTEyIiB9LAorICAgICB7IEFUQV9TSUkzNTEyLCAgIDB4 MDAsIFNJSU1FTUlPLCBTSUlCVUcsICAgIEFUQV9TQTE1MCwgIjM1MTIiIH0sCisgICAgIHsgQVRB X1NJSTMxMTIsICAgMHgwMCwgU0lJTUVNSU8sIFNJSUJVRywgICAgQVRBX1NBMTUwLCAiMzExMiIg fSwKKyAgICAgeyBBVEFfU0lJMzExMl8xLCAweDAwLCBTSUlNRU1JTywgU0lJQlVHLCAgICBBVEFf U0ExNTAsICIzMTEyIiB9LAorICAgICB7IEFUQV9TSUkzMTI0LCAgIDB4MDAsIFNJSVBSQklPLCBT SUk0Q0gsICAgIEFUQV9TQTMwMCwgIjMxMjQiIH0sCisgICAgIHsgQVRBX1NJSTMxMzIsICAgMHgw MCwgU0lJUFJCSU8sIDAsICAgICAgICAgQVRBX1NBMzAwLCAiMzEzMiIgfSwKKyAgICAgeyBBVEFf U0lJMzEzMl8xLCAweDAwLCBTSUlQUkJJTywgMCwgICAgICAgICBBVEFfU0EzMDAsICIzMTMyIiB9 LAorICAgICB7IEFUQV9TSUkwNjgwLCAgIDB4MDAsIFNJSU1FTUlPLCBTSUlTRVRDTEssIEFUQV9V RE1BNiwgIjY4MCIgfSwKKyAgICAgeyBBVEFfQ01ENjQ5LCAgICAweDAwLCAwLCAgICAgICAgU0lJ SU5UUiwgICBBVEFfVURNQTUsICIoQ01EKSA2NDkiIH0sCisgICAgIHsgQVRBX0NNRDY0OCwgICAg MHgwMCwgMCwgICAgICAgIFNJSUlOVFIsICAgQVRBX1VETUE0LCAiKENNRCkgNjQ4IiB9LAorICAg ICB7IEFUQV9DTUQ2NDYsICAgIDB4MDcsIDAsICAgICAgICAwLCAgICAgICAgIEFUQV9VRE1BMiwg IihDTUQpIDY0NlUyIiB9LAorICAgICB7IEFUQV9DTUQ2NDYsICAgIDB4MDAsIDAsICAgICAgICAw LCAgICAgICAgIEFUQV9XRE1BMiwgIihDTUQpIDY0NiIgfSwKICAgICAgeyAwLCAwLCAwLCAwLCAw LCAwfX07CiAKICAgICBpZiAoIShjdGxyLT5jaGlwID0gYXRhX21hdGNoX2NoaXAoZGV2LCBpZHMp KSkKQEAgLTQ1MTcsNyArNTExNCw3IEBAIGF0YV9zaWlfY2hpcGluaXQoZGV2aWNlX3QgZGV2KQog CWN0bHItPnJfdHlwZTIgPSBTWVNfUkVTX01FTU9SWTsKIAljdGxyLT5yX3JpZDIgPSBQQ0lSX0JB Uig1KTsKIAlpZiAoIShjdGxyLT5yX3JlczIgPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwg Y3Rsci0+cl90eXBlMiwKLQkJCQkJCSAgICAmY3Rsci0+cl9yaWQyLCBSRl9BQ1RJVkUpKSkgewor CQkJCQkJICAgICZjdGxyLT5yX3JpZDIsIFJGX0FDVElWRSkpKXsKIAkgICAgaWYgKGN0bHItPmNo aXAtPmNoaXBpZCAhPSBBVEFfU0lJMDY4MCB8fAogCQkJICAgIChwY2lfcmVhZF9jb25maWcoZGV2 LCAweDhhLCAxKSAmIDEpKQogCQlyZXR1cm4gRU5YSU87CkBAIC00NTk0LDkgKzUxOTEsOSBAQCBh dGFfY21kX3N0YXR1cyhkZXZpY2VfdCBkZXYpCiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKICAgICB1X2ludDhfdCByZWc3MTsKIAotICAgIGlmICgo KHJlZzcxID0gcGNpX3JlYWRfY29uZmlnKGRldmljZV9nZXRfcGFyZW50KGNoLT5kZXYpLCAweDcx LCAxKSkgJgorICAgIGlmICgoKHJlZzcxID0gcGNpX3JlYWRfY29uZmlnKGRldmljZV9nZXRfcGFy ZW50KGRldiksIDB4NzEsIDEpKSAmCiAJIChjaC0+dW5pdCA/IDB4MDggOiAweDA0KSkpIHsKLQlw Y2lfd3JpdGVfY29uZmlnKGRldmljZV9nZXRfcGFyZW50KGNoLT5kZXYpLCAweDcxLAorCXBjaV93 cml0ZV9jb25maWcoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSwgMHg3MSwKIAkJCSByZWc3MSAmIH4o Y2gtPnVuaXQgPyAweDA0IDogMHgwOCksIDEpOwogCXJldHVybiBhdGFfcGNpX3N0YXR1cyhkZXYp OwogICAgIH0KQEAgLTQ2MTAsNyArNTIwNyw3IEBAIGF0YV9jbWRfc2V0bW9kZShkZXZpY2VfdCBk ZXYsIGludCBtb2RlKQogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZp Y2VfZ2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOwogICAgIHN0cnVjdCBhdGFfZGV2 aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgaW50IGRldm5vID0gKGNo LT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBkZXZubyA9IChj aC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQgZXJyb3I7CiAKICAgICBtb2Rl ID0gYXRhX2xpbWl0X21vZGUoZGV2LCBtb2RlLCBjdGxyLT5jaGlwLT5tYXhfZG1hKTsKQEAgLTQ2 MzUsNyArNTIzMiw3IEBAIGF0YV9jbWRfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKQog CSAgICB1X2ludDhfdCB1bW9kZSA9IHBjaV9yZWFkX2NvbmZpZyhncGFyZW50LCB1cmVnLCAxKTsK IAogCSAgICB1bW9kZSAmPSB+KGF0YWRldi0+dW5pdCA9PSBBVEFfTUFTVEVSID8gMHgzNSA6IDB4 Y2EpOwotCSAgICB1bW9kZSB8PSB1ZG1hdGltaW5nc1ttb2RlICYgQVRBX01PREVfTUFTS11bQVRB X0RFVihhdGFkZXYtPnVuaXQpXTsKKwkgICAgdW1vZGUgfD0gdWRtYXRpbWluZ3NbbW9kZSAmIEFU QV9NT0RFX01BU0tdW2F0YWRldi0+dW5pdF07CiAJICAgIHBjaV93cml0ZV9jb25maWcoZ3BhcmVu dCwgdXJlZywgdW1vZGUsIDEpOwogCX0KIAllbHNlIGlmIChtb2RlID49IEFUQV9XRE1BMCkgeyAK QEAgLTQ2OTUsMTAgKzUyOTIsMTAgQEAgYXRhX3NpaV9hbGxvY2F0ZShkZXZpY2VfdCBkZXYpCiAJ QVRBX09VVEwoY3Rsci0+cl9yZXMyLCAweDE0OCArICh1bml0MDEgPDwgNykgKyAodW5pdDEwIDw8 IDgpLCgxIDw8IDE2KSk7CiAgICAgfQogCi0gICAgaWYgKChjdGxyLT5jaGlwLT5jZmcyICYgU0lJ QlVHKSAmJiBjaC0+ZG1hKSB7CisgICAgaWYgKGN0bHItPmNoaXAtPmNmZzIgJiBTSUlCVUcpIHsK IAkvKiB3b3JrIGFyb3VuZCBlcnJhdGEgaW4gZWFybHkgY2hpcHMgKi8KLQljaC0+ZG1hLT5ib3Vu ZGFyeSA9IDgxOTI7Ci0JY2gtPmRtYS0+c2Vnc2l6ZSA9IDE1ICogREVWX0JTSVpFOworCWNoLT5k bWEuYm91bmRhcnkgPSA4MTkyOworCWNoLT5kbWEuc2Vnc2l6ZSA9IDE1ICogREVWX0JTSVpFOwog ICAgIH0KIAogICAgIGF0YV9wY2lfaHcoZGV2KTsKQEAgLTQ3MzksOSArNTMzNiw5IEBAIGF0YV9z aWlfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKQogICAgIHN0cnVjdCBhdGFfcGNpX2Nv bnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGdwYXJlbnQpOwogICAgIHN0cnVjdCBh dGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikp OwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 Ci0gICAgaW50IHJlZ28gPSAoY2gtPnVuaXQgPDwgNCkgKyAoQVRBX0RFVihhdGFkZXYtPnVuaXQp IDw8IDEpOworICAgIGludCByZWdvID0gKGNoLT51bml0IDw8IDQpICsgKGF0YWRldi0+dW5pdCA8 PCAxKTsKICAgICBpbnQgbXJlZyA9IGNoLT51bml0ID8gMHg4NCA6IDB4ODA7Ci0gICAgaW50IG1h c2sgPSAweDAzIDw8IChBVEFfREVWKGF0YWRldi0+dW5pdCkgPDwgMik7CisgICAgaW50IG1hc2sg PSAweDAzIDw8IChhdGFkZXYtPnVuaXQgPDwgMik7CiAgICAgaW50IG12YWwgPSBwY2lfcmVhZF9j b25maWcoZ3BhcmVudCwgbXJlZywgMSkgJiB+bWFzazsKICAgICBpbnQgZXJyb3I7CiAKQEAgLTQ3 NzEsNyArNTM2OCw3IEBAIGF0YV9zaWlfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKQog CXVfaW50OF90IHVyZWcgPSAweGFjICsgcmVnbzsKIAogCXBjaV93cml0ZV9jb25maWcoZ3BhcmVu dCwgbXJlZywKLQkJCSBtdmFsIHwgKDB4MDMgPDwgKEFUQV9ERVYoYXRhZGV2LT51bml0KSA8PCAy KSksIDEpOworCQkJIG12YWwgfCAoMHgwMyA8PCAoYXRhZGV2LT51bml0IDw8IDIpKSwgMSk7CiAJ cGNpX3dyaXRlX2NvbmZpZyhncGFyZW50LCB1cmVnLCAKIAkJCSAocGNpX3JlYWRfY29uZmlnKGdw YXJlbnQsIHVyZWcsIDEpICYgfjB4M2YpIHwKIAkJCSB1ZG1hdGltaW5nc1ttb2RlICYgQVRBX01P REVfTUFTS10sIDEpOwpAQCAtNDc4Miw3ICs1Mzc5LDcgQEAgYXRhX3NpaV9zZXRtb2RlKGRldmlj ZV90IGRldiwgaW50IG1vZGUpCiAJdV9pbnQxNl90IGRtYXRpbWluZ3NbXSA9IHsgMHgyMjA4LCAw eDEwYzIsIDB4MTBjMSB9OwogCiAJcGNpX3dyaXRlX2NvbmZpZyhncGFyZW50LCBtcmVnLAotCQkJ IG12YWwgfCAoMHgwMiA8PCAoQVRBX0RFVihhdGFkZXYtPnVuaXQpIDw8IDIpKSwgMSk7CisJCQkg bXZhbCB8ICgweDAyIDw8IChhdGFkZXYtPnVuaXQgPDwgMikpLCAxKTsKIAlwY2lfd3JpdGVfY29u ZmlnKGdwYXJlbnQsIGRyZWcsIGRtYXRpbWluZ3NbbW9kZSAmIEFUQV9NT0RFX01BU0tdLCAyKTsK IAogICAgIH0KQEAgLTQ3OTEsNyArNTM4OCw3IEBAIGF0YV9zaWlfc2V0bW9kZShkZXZpY2VfdCBk ZXYsIGludCBtb2RlKQogCXVfaW50MTZfdCBwaW90aW1pbmdzW10gPSB7IDB4MzI4YSwgMHgyMjgz LCAweDExMDQsIDB4MTBjMywgMHgxMGMxIH07CiAKIAlwY2lfd3JpdGVfY29uZmlnKGdwYXJlbnQs IG1yZWcsCi0JCQkgbXZhbCB8ICgweDAxIDw8IChBVEFfREVWKGF0YWRldi0+dW5pdCkgPDwgMikp LCAxKTsKKwkJCSBtdmFsIHwgKDB4MDEgPDwgKGF0YWRldi0+dW5pdCA8PCAyKSksIDEpOwogCXBj aV93cml0ZV9jb25maWcoZ3BhcmVudCwgcHJlZywgcGlvdGltaW5nc1ttb2RlICYgQVRBX01PREVf TUFTS10sIDIpOwogICAgIH0KICAgICBhdGFkZXYtPm1vZGUgPSBtb2RlOwpAQCAtNDgwNCwxMyAr NTQwMSwxNCBAQCBzdHJ1Y3QgYXRhX3NpaXByYl9kbWFfcHJkZW50cnkgewogICAgIHVfaW50MzJf dCBjb250cm9sOwogfSBfX3BhY2tlZDsKIAorI2RlZmluZSBBVEFfU0lJUFJCX0RNQV9FTlRSSUVT CQkxMjUKIHN0cnVjdCBhdGFfc2lpcHJiX2F0YV9jb21tYW5kIHsKLSAgICBzdHJ1Y3QgYXRhX3Np aXByYl9kbWFfcHJkZW50cnkgcHJkWzEyNl07CisgICAgc3RydWN0IGF0YV9zaWlwcmJfZG1hX3By ZGVudHJ5IHByZFtBVEFfU0lJUFJCX0RNQV9FTlRSSUVTXTsKIH0gX19wYWNrZWQ7CiAKIHN0cnVj dCBhdGFfc2lpcHJiX2F0YXBpX2NvbW1hbmQgewogICAgIHVfaW50OF90IGNjYlsxNl07Ci0gICAg c3RydWN0IGF0YV9zaWlwcmJfZG1hX3ByZGVudHJ5IHByZFsxMjVdOworICAgIHN0cnVjdCBhdGFf c2lpcHJiX2RtYV9wcmRlbnRyeSBwcmRbQVRBX1NJSVBSQl9ETUFfRU5UUklFU107CiB9IF9fcGFj a2VkOwogCiBzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kIHsKQEAgLTQ4NDEsMTAgKzU0MzksMTQg QEAgYXRhX3NpaXByYl9hbGxvY2F0ZShkZXZpY2VfdCBkZXYpCiAgICAgY2gtPnJfaW9bQVRBX1NB Q1RJVkVdLnJlcyA9IGN0bHItPnJfcmVzMjsKICAgICBjaC0+cl9pb1tBVEFfU0FDVElWRV0ub2Zm c2V0ID0gMHgxZjBjICsgb2Zmc2V0OwogICAgCisgICAgY2gtPmh3LnN0YXR1cyA9IGF0YV9zaWlw cmJfc3RhdHVzOwogICAgIGNoLT5ody5iZWdpbl90cmFuc2FjdGlvbiA9IGF0YV9zaWlwcmJfYmVn aW5fdHJhbnNhY3Rpb247CiAgICAgY2gtPmh3LmVuZF90cmFuc2FjdGlvbiA9IGF0YV9zaWlwcmJf ZW5kX3RyYW5zYWN0aW9uOwotICAgIGNoLT5ody5zdGF0dXMgPSBhdGFfc2lpcHJiX3N0YXR1czsK ICAgICBjaC0+aHcuY29tbWFuZCA9IE5VTEw7CS8qIG5vdCB1c2VkIGhlcmUgKi8KKyAgICBjaC0+ aHcuc29mdHJlc2V0ID0gYXRhX3NpaXByYl9zb2Z0cmVzZXQ7CisgICAgY2gtPmh3LnBtX3JlYWQg PSBhdGFfc2lpcHJiX3BtX3JlYWQ7CisgICAgY2gtPmh3LnBtX3dyaXRlID0gYXRhX3NpaXByYl9w bV93cml0ZTsKKyAgICAgCiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTQ4NzUsMTIgKzU0NzcsMTEg QEAgc3RhdGljIGludAogYXRhX3NpaXByYl9iZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3Jl cXVlc3QgKnJlcXVlc3QpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3Rscj1k ZXZpY2VfZ2V0X3NvZnRjKEdSQU5EUEFSRU5UKHJlcXVlc3QtPmRldikpOwotICAgIHN0cnVjdCBh dGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVl c3QtPmRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRj KHJlcXVlc3QtPnBhcmVudCk7CiAgICAgc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqcHJiOwog ICAgIHN0cnVjdCBhdGFfc2lpcHJiX2RtYV9wcmRlbnRyeSAqcHJkOwogICAgIGludCBvZmZzZXQg PSBjaC0+dW5pdCAqIDB4MjAwMDsKICAgICB1X2ludDY0X3QgcHJiX2J1czsKLSAgICBpbnQgdGFn ID0gMCwgZHVtbXk7CiAKICAgICAvKiBTT1MgWFhYICovCiAgICAgaWYgKHJlcXVlc3QtPnUuYXRh LmNvbW1hbmQgPT0gQVRBX0RFVklDRV9SRVNFVCkgewpAQCAtNDg4OCwxMiArNTQ4OSw5IEBAIGF0 YV9zaWlwcmJfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV8KICAgICAgICAgcmV0dXJuIEFU QV9PUF9GSU5JU0hFRDsKICAgICB9CiAKLSAgICAvKiBjaGVjayBmb3IgNDggYml0IGFjY2VzcyBh bmQgY29udmVydCBpZiBuZWVkZWQgKi8KLSAgICBhdGFfbW9kaWZ5X2lmXzQ4Yml0KHJlcXVlc3Qp OwotCiAgICAgLyogZ2V0IGEgcGllY2Ugb2YgdGhlIHdvcmtzcGFjZSBmb3IgdGhpcyByZXF1ZXN0 ICovCiAgICAgcHJiID0gKHN0cnVjdCBhdGFfc2lpcHJiX2NvbW1hbmQgKikKLQkoY2gtPmRtYS0+ d29yayArIChzaXplb2Yoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCkgKiB0YWcpKTsKKwkoY2gt PmRtYS53b3JrICsgKHNpemVvZihzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kKSAqIHJlcXVlc3Qt PnRhZykpOwogCiAgICAgLyogc2V0IGJhc2ljIHByZCBvcHRpb25zIGF0YS9hdGFwaSBldGMgZXRj ICovCiAgICAgYnplcm8ocHJiLCBzaXplb2Yoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCkpOwpA QCAtNDkyNSw4ICs1NTIzLDcgQEAgYXRhX3NpaXByYl9iZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3Qg YXRhXwogCiAgICAgLyogaWYgcmVxdWVzdCBtb3ZlcyBkYXRhIHNldHVwIGFuZCBsb2FkIFNHIGxp c3QgKi8KICAgICBpZiAocmVxdWVzdC0+ZmxhZ3MgJiAoQVRBX1JfUkVBRCB8IEFUQV9SX1dSSVRF KSkgewotCWlmIChjaC0+ZG1hLT5sb2FkKGNoLT5kZXYsIHJlcXVlc3QtPmRhdGEsIHJlcXVlc3Qt PmJ5dGVjb3VudCwKLQkJCSAgcmVxdWVzdC0+ZmxhZ3MgJiBBVEFfUl9SRUFELCBwcmQsICZkdW1t eSkpIHsKKwlpZiAoY2gtPmRtYS5sb2FkKHJlcXVlc3QsIHByZCwgTlVMTCkpIHsKIAkgICAgZGV2 aWNlX3ByaW50ZihyZXF1ZXN0LT5kZXYsICJzZXR0aW5nIHVwIERNQSBmYWlsZWRcbiIpOwogCSAg ICByZXF1ZXN0LT5yZXN1bHQgPSBFSU87CiAJICAgIHJldHVybiBBVEFfT1BfRklOSVNIRUQ7CkBA IC00OTM0LDExICs1NTMxLDEyIEBAIGF0YV9zaWlwcmJfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0 IGF0YV8KICAgICB9CiAKICAgICAvKiBhY3RpdmF0ZSB0aGUgcHJiICovCi0gICAgcHJiX2J1cyA9 IGNoLT5kbWEtPndvcmtfYnVzICsgKHNpemVvZihzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kKSAq IHRhZyk7CisgICAgcHJiX2J1cyA9IGNoLT5kbWEud29ya19idXMgKworCSAgICAgIChzaXplb2Yo c3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCkgKiByZXF1ZXN0LT50YWcpOwogICAgIEFUQV9PVVRM KGN0bHItPnJfcmVzMiwKLQkgICAgIDB4MWMwMCArIG9mZnNldCArICh0YWcgKiBzaXplb2YodV9p bnQ2NF90KSksIHByYl9idXMpOworCSAgICAgMHgxYzAwICsgb2Zmc2V0ICsgKHJlcXVlc3QtPnRh ZyAqIHNpemVvZih1X2ludDY0X3QpKSwgcHJiX2J1cyk7CiAgICAgQVRBX09VVEwoY3Rsci0+cl9y ZXMyLAotCSAgICAgMHgxYzA0ICsgb2Zmc2V0ICsgKHRhZyAqIHNpemVvZih1X2ludDY0X3QpKSwg cHJiX2J1cz4+MzIpOworCSAgICAgMHgxYzA0ICsgb2Zmc2V0ICsgKHJlcXVlc3QtPnRhZyAqIHNp emVvZih1X2ludDY0X3QpKSwgcHJiX2J1cz4+MzIpOwogCiAgICAgLyogc3RhcnQgdGhlIHRpbWVv dXQgKi8KICAgICBjYWxsb3V0X3Jlc2V0KCZyZXF1ZXN0LT5jYWxsb3V0LCByZXF1ZXN0LT50aW1l b3V0ICogaHosCkBAIC00OTUwLDE2ICs1NTQ4LDE2IEBAIHN0YXRpYyBpbnQKIGF0YV9zaWlwcmJf ZW5kX3RyYW5zYWN0aW9uKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCkKIHsKICAgICBzdHJ1 Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyPWRldmljZV9nZXRfc29mdGMoR1JBTkRQQVJFTlQo cmVxdWVzdC0+ZGV2KSk7Ci0gICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRf c29mdGMoZGV2aWNlX2dldF9wYXJlbnQocmVxdWVzdC0+ZGV2KSk7CisgICAgc3RydWN0IGF0YV9j aGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50KTsKICAgICBzdHJ1 Y3QgYXRhX3NpaXByYl9jb21tYW5kICpwcmI7CiAgICAgaW50IG9mZnNldCA9IGNoLT51bml0ICog MHgyMDAwOwotICAgIGludCBlcnJvciwgdGltZW91dCwgdGFnID0gMDsKKyAgICBpbnQgZXJyb3Is IHRpbWVvdXQ7CiAKICAgICAvKiBraWxsIHRoZSB0aW1lb3V0ICovCiAgICAgY2FsbG91dF9zdG9w KCZyZXF1ZXN0LT5jYWxsb3V0KTsKICAgICAKICAgICBwcmIgPSAoc3RydWN0IGF0YV9zaWlwcmJf Y29tbWFuZCAqKQotCSgodV9pbnQ4X3QgKilybWFuX2dldF92aXJ0dWFsKGN0bHItPnJfcmVzMikg KyAodGFnIDw8IDcpICsgb2Zmc2V0KTsKKwkoKHVfaW50OF90ICopcm1hbl9nZXRfdmlydHVhbChj dGxyLT5yX3JlczIpKyhyZXF1ZXN0LT50YWcgPDwgNykrb2Zmc2V0KTsKIAogICAgIC8qIGFueSBj b250cm9sbGVyIGVycm9ycyBmbGFnZ2VkID8gKi8KICAgICBpZiAoKGVycm9yID0gQVRBX0lOTChj dGxyLT5yX3JlczIsIDB4MTAyNCArIG9mZnNldCkpKSB7CkBAIC00OTkzLDYgKzU1OTEsMjEgQEAg YXRhX3NpaXByYl9lbmRfdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZQogCX0KICAgICB9CiAKKyAg ICAvKiBvbiBjb250cm9sIGNvbW1hbmRzIHJlYWQgYmFjayByZWdpc3RlcnMgdG8gdGhlIHJlcXVl c3Qgc3RydWN0ICovCisgICAgaWYgKHJlcXVlc3QtPmZsYWdzICYgQVRBX1JfQ09OVFJPTCkgewor ICAgICAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1 ZXN0LT5kZXYpOworCisJcmVxdWVzdC0+dS5hdGEuY291bnQgPSBwcmItPmZpc1sxMl0gfCAoKHVf aW50MTZfdClwcmItPmZpc1sxM10gPDwgOCk7CisJcmVxdWVzdC0+dS5hdGEubGJhID0gcHJiLT5m aXNbNF0gfCAoKHVfaW50NjRfdClwcmItPmZpc1s1XSA8PCA4KSB8CisJCQkgICAgICgodV9pbnQ2 NF90KXByYi0+ZmlzWzZdIDw8IDE2KTsKKwlpZiAoYXRhZGV2LT5mbGFncyAmIEFUQV9EXzQ4QklU X0FDVElWRSkKKwkgICAgcmVxdWVzdC0+dS5hdGEubGJhIHw9ICgodV9pbnQ2NF90KXByYi0+Zmlz WzhdIDw8IDI0KSB8CisJCQkJICAoKHVfaW50NjRfdClwcmItPmZpc1s5XSA8PCAzMikgfAorCQkJ CSAgKCh1X2ludDY0X3QpcHJiLT5maXNbMTBdIDw8IDQwKTsKKwllbHNlCisJICAgIHJlcXVlc3Qt PnUuYXRhLmxiYSB8PSAoKHVfaW50NjRfdCkocHJiLT5maXNbN10gJiAweDBmKSA8PCAyNCk7Cisg ICAgfQorCiAgICAgLyogdXBkYXRlIHByb2dyZXNzICovCiAgICAgaWYgKCEocmVxdWVzdC0+c3Rh dHVzICYgQVRBX1NfRVJST1IpICYmICEocmVxdWVzdC0+ZmxhZ3MgJiBBVEFfUl9USU1FT1VUKSkg ewogCWlmIChyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQpCkBAIC01MDAyLDIxICs1NjE1LDEy NiBAQCBhdGFfc2lpcHJiX2VuZF90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlCiAgICAgfQogCiAg ICAgLyogcmVsZWFzZSBTRyBsaXN0IGV0YyAqLwotICAgIGNoLT5kbWEtPnVubG9hZChjaC0+ZGV2 KTsKKyAgICBjaC0+ZG1hLnVubG9hZChyZXF1ZXN0KTsKIAogICAgIHJldHVybiBBVEFfT1BfRklO SVNIRUQ7CiB9CiAKK3N0YXRpYyBpbnQKK2F0YV9zaWlwcmJfaXNzdWVfY21kKGRldmljZV90IGRl dikKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9z b2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNo ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIHVfaW50NjRfdCBwcmJfYnVzID0gY2gtPmRt YS53b3JrX2J1czsKKyAgICB1X2ludDMyX3Qgc3RhdHVzOworICAgIGludCBvZmZzZXQgPSBjaC0+ dW5pdCAqIDB4MjAwMDsKKyAgICBpbnQgdGltZW91dDsKKworICAgIC8qIGlzc3VlIGNvbW1hbmQg dG8gY2hpcCAqLworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgMHgxYzAwICsgb2Zmc2V0LCBw cmJfYnVzKTsKKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIDB4MWMwNCArIG9mZnNldCwgcHJi X2J1cyA+PiAzMik7CisKKyAgICAvKiBwb2xsIGZvciBjb21tYW5kIGZpbmlzaGVkICovCisgICAg Zm9yICh0aW1lb3V0ID0gMDsgdGltZW91dCA8IDEwMDAwOyB0aW1lb3V0KyspIHsKKyAgICAgICAg REVMQVkoMTAwMCk7CisgICAgICAgIGlmICgoc3RhdHVzID0gQVRBX0lOTChjdGxyLT5yX3JlczIs IDB4MTAwOCArIG9mZnNldCkpICYgMHgwMDAxMDAwMCkKKyAgICAgICAgICAgIGJyZWFrOworICAg IH0KKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIDB4MTAwOCArIG9mZnNldCwgMHgwMDAxMDAw MCk7CisKKyAgICBpZiAodGltZW91dCA+PSAxMDAwKQorCXJldHVybiBFSU87CisKKyAgICBpZiAo Ym9vdHZlcmJvc2UpCisJZGV2aWNlX3ByaW50ZihkZXYsICJzaWlwcmJfaXNzdWVfY21kIHRpbWU9 JWRtcyBzdGF0dXM9JTA4eFxuIiwKKwkJICAgICAgdGltZW91dCwgc3RhdHVzKTsKKyAgICByZXR1 cm4gMDsKK30KKworc3RhdGljIGludAorYXRhX3NpaXByYl9wbV9yZWFkKGRldmljZV90IGRldiwg aW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCAqcmVzdWx0KQoreworICAgIHN0cnVjdCBhdGFf cGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50 KGRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7CisgICAgc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqcHJiID0gKHN0cnVjdCBhdGFfc2lp cHJiX2NvbW1hbmQgKiljaC0+ZG1hLndvcms7CisgICAgaW50IG9mZnNldCA9IGNoLT51bml0ICog MHgyMDAwOworCisgICAgYnplcm8ocHJiLCBzaXplb2Yoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFu ZCkpOworICAgIHByYi0+ZmlzWzBdID0gMHgyNzsJLyogaG9zdCB0byBkZXZpY2UgKi8KKyAgICBw cmItPmZpc1sxXSA9IDB4OGY7CS8qIGNvbW1hbmQgRklTIHRvIFBNIHBvcnQgKi8KKyAgICBwcmIt PmZpc1syXSA9IEFUQV9SRUFEX1BNOworICAgIHByYi0+ZmlzWzNdID0gcmVnOworICAgIHByYi0+ ZmlzWzddID0gcG9ydDsKKyAgICBpZiAoYXRhX3NpaXByYl9pc3N1ZV9jbWQoZGV2KSkgeworCWRl dmljZV9wcmludGYoZGV2LCAiZXJyb3IgcmVhZGluZyBQTSBwb3J0XG4iKTsKKwlyZXR1cm4gRUlP OworICAgIH0KKyAgICBwcmIgPSAoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqKQorCSgodV9p bnQ4X3QgKilybWFuX2dldF92aXJ0dWFsKGN0bHItPnJfcmVzMikgKyBvZmZzZXQpOworICAgICpy ZXN1bHQgPSBwcmItPmZpc1sxMl18KHByYi0+ZmlzWzRdPDw4KXwocHJiLT5maXNbNV08PDE2KXwo cHJiLT5maXNbNl08PDI0KTsKKyAgICByZXR1cm4gMDsKK30KKworc3RhdGljIGludAorYXRhX3Np aXByYl9wbV93cml0ZShkZXZpY2VfdCBkZXYsIGludCBwb3J0LCBpbnQgcmVnLCB1X2ludDMyX3Qg dmFsdWUpCit7CisgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9n ZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CisgICAgc3RydWN0IGF0YV9jaGFubmVs ICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICBzdHJ1Y3QgYXRhX3NpaXByYl9jb21t YW5kICpwcmIgPSAoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqKWNoLT5kbWEud29yazsKKyAg ICBpbnQgb2Zmc2V0ID0gY2gtPnVuaXQgKiAweDIwMDA7CisKKyAgICBiemVybyhwcmIsIHNpemVv ZihzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kKSk7CisgICAgcHJiLT5maXNbMF0gPSAweDI3Owkv KiBob3N0IHRvIGRldmljZSAqLworICAgIHByYi0+ZmlzWzFdID0gMHg4ZjsJLyogY29tbWFuZCBG SVMgdG8gUE0gcG9ydCAqLworICAgIHByYi0+ZmlzWzJdID0gQVRBX1dSSVRFX1BNOworICAgIHBy Yi0+ZmlzWzNdID0gcmVnOworICAgIHByYi0+ZmlzWzddID0gcG9ydDsKKyAgICBwcmItPmZpc1sx Ml0gPSB2YWx1ZSAmIDB4ZmY7CisgICAgcHJiLT5maXNbNF0gPSAodmFsdWUgPj4gOCkgJiAweGZm OzsKKyAgICBwcmItPmZpc1s1XSA9ICh2YWx1ZSA+PiAxNikgJiAweGZmOzsKKyAgICBwcmItPmZp c1s2XSA9ICh2YWx1ZSA+PiAyNCkgJiAweGZmOzsKKyAgICBpZiAoYXRhX3NpaXByYl9pc3N1ZV9j bWQoZGV2KSkgeworCWRldmljZV9wcmludGYoZGV2LCAiZXJyb3Igd3JpdGluZyBQTSBwb3J0XG4i KTsKKwlyZXR1cm4gQVRBX0VfQUJPUlQ7CisgICAgfQorICAgIHByYiA9IChzdHJ1Y3QgYXRhX3Np aXByYl9jb21tYW5kICopCisJKCh1X2ludDhfdCAqKXJtYW5fZ2V0X3ZpcnR1YWwoY3Rsci0+cl9y ZXMyKSArIG9mZnNldCk7CisgICAgcmV0dXJuIHByYi0+ZmlzWzNdOworfQorCitzdGF0aWMgdV9p bnQzMl90CithdGFfc2lpcHJiX3NvZnRyZXNldChkZXZpY2VfdCBkZXYsIGludCBwb3J0KQorewor ICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dmljZV9nZXRfcGFyZW50KGRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisgICAgc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqcHJiID0g KHN0cnVjdCBhdGFfc2lpcHJiX2NvbW1hbmQgKiljaC0+ZG1hLndvcms7CisgICAgaW50IG9mZnNl dCA9IGNoLT51bml0ICogMHgyMDAwOworCisgICAgLyogc2V0dXAgdGhlIHdvcmtzcGFjZSBmb3Ig YSBzb2Z0IHJlc2V0IGNvbW1hbmQgKi8KKyAgICBiemVybyhwcmIsIHNpemVvZihzdHJ1Y3QgYXRh X3NpaXByYl9jb21tYW5kKSk7CisgICAgcHJiLT5jb250cm9sID0gaHRvbGUxNigweDAwODApOwor ICAgIHByYi0+ZmlzWzFdID0gcG9ydCAmIDB4MGY7CisKKyAgICAvKiBpc3N1ZSBzb2Z0IHJlc2V0 ICovCisgICAgaWYgKGF0YV9zaWlwcmJfaXNzdWVfY21kKGRldikpCisJcmV0dXJuIC0xOworCisg ICAgYXRhX3VkZWxheSgxNTAwMDApOworCisgICAgLyogcmV0dXJuIHBvc3NpYmxlIHNpZ25hdHVy ZSAqLworICAgIHByYiA9IChzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kICopCisJKCh1X2ludDhf dCAqKXJtYW5fZ2V0X3ZpcnR1YWwoY3Rsci0+cl9yZXMyKSArIG9mZnNldCk7CisgICAgcmV0dXJu IHByYi0+ZmlzWzEyXXwocHJiLT5maXNbNF08PDgpfChwcmItPmZpc1s1XTw8MTYpfChwcmItPmZp c1s2XTw8MjQpOworfQorCiBzdGF0aWMgdm9pZAogYXRhX3NpaXByYl9yZXNldChkZXZpY2VfdCBk ZXYpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRf c29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKICAgICBpbnQgb2Zmc2V0ID0gY2gtPnVuaXQgKiAw eDIwMDA7Ci0gICAgc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqcHJiOwotICAgIHVfaW50NjRf dCBwcmJfYnVzOwogICAgIHVfaW50MzJfdCBzdGF0dXMsIHNpZ25hdHVyZTsKLSAgICBpbnQgdGlt ZW91dCwgdGFnID0gMDsKKyAgICBpbnQgdGltZW91dDsKIAogICAgIC8qIHJlc2V0IGNoYW5uZWwg SFcgKi8KICAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIDB4MTAwMCArIG9mZnNldCwgMHgwMDAw MDAwMSk7CkBAIC01MDMzLDYyICs1NzUxLDMzIEBAIGF0YV9zaWlwcmJfcmVzZXQoZGV2aWNlX3Qg ZGV2KQogCiAgICAgaWYgKGJvb3R2ZXJib3NlKSB7CiAJaWYgKHRpbWVvdXQgPj0gMTAwMCkKLQkg ICAgZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAiY2hhbm5lbCBIVyByZXNldCB0aW1lb3V0XG4iKTsK KwkgICAgZGV2aWNlX3ByaW50ZihkZXYsICJjaGFubmVsIEhXIHJlc2V0IHRpbWVvdXRcbiIpOwog CWVsc2UKLQkgICAgZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAiY2hhbm5lbCBIVyByZXNldCB0aW1l PSVkbXNcbiIsIHRpbWVvdXQpOworCSAgICBkZXZpY2VfcHJpbnRmKGRldiwgImNoYW5uZWwgSFcg cmVzZXQgdGltZT0lZG1zXG4iLCB0aW1lb3V0KTsKICAgICB9CiAKICAgICAvKiByZXNldCBwaHkg Ki8KICAgICBpZiAoIWF0YV9zYXRhX3BoeV9yZXNldChkZXYpKSB7CiAJaWYgKGJvb3R2ZXJib3Nl KQotCSAgICBkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNl XG4iKTsKKwkgICAgZGV2aWNlX3ByaW50ZihkZXYsICJwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNl XG4iKTsKIAljaC0+ZGV2aWNlcyA9IDA7CiAJZ290byBmaW5pc2g7CiAgICAgfQogCi0gICAgLyog Z2V0IGEgcGllY2Ugb2YgdGhlIHdvcmtzcGFjZSBmb3IgYSBzb2Z0IHJlc2V0IHJlcXVlc3QgKi8K LSAgICBwcmIgPSAoc3RydWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqKQotCShjaC0+ZG1hLT53b3Jr ICsgKHNpemVvZihzdHJ1Y3QgYXRhX3NpaXByYl9jb21tYW5kKSAqIHRhZykpOwotICAgIGJ6ZXJv KHByYiwgc2l6ZW9mKHN0cnVjdCBhdGFfc2lpcHJiX2NvbW1hbmQpKTsKLSAgICBwcmItPmNvbnRy b2wgPSBodG9sZTE2KDB4MDA4MCk7Ci0KLSAgICAvKiBhY3RpdmF0ZSB0aGUgc29mdCByZXNldCBw cmIgKi8KLSAgICBwcmJfYnVzID0gY2gtPmRtYS0+d29ya19idXMgKyAoc2l6ZW9mKHN0cnVjdCBh dGFfc2lpcHJiX2NvbW1hbmQpICogdGFnKTsKLSAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsCi0J ICAgICAweDFjMDAgKyBvZmZzZXQgKyAodGFnICogc2l6ZW9mKHVfaW50NjRfdCkpLCBwcmJfYnVz KTsKLSAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsCi0JICAgICAweDFjMDQgKyBvZmZzZXQgKyAo dGFnICogc2l6ZW9mKHVfaW50NjRfdCkpLCBwcmJfYnVzPj4zMik7Ci0KLSAgICAvKiBwb2xsIGZv ciBjb21tYW5kIGZpbmlzaGVkICovCi0gICAgZm9yICh0aW1lb3V0ID0gMDsgdGltZW91dCA8IDEw MDAwOyB0aW1lb3V0KyspIHsKLSAgICAgICAgREVMQVkoMTAwMCk7Ci0gICAgICAgIGlmICgoc3Rh dHVzID0gQVRBX0lOTChjdGxyLT5yX3JlczIsIDB4MTAwOCArIG9mZnNldCkpICYgMHgwMDAxMDAw MCkKLSAgICAgICAgICAgIGJyZWFrOwotICAgIH0KLSAgICBpZiAodGltZW91dCA+PSAxMDAwKSB7 Ci0JZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAicmVzZXQgdGltZW91dCAtIG5vIGRldmljZSBmb3Vu ZFxuIik7Ci0JY2gtPmRldmljZXMgPSAwOwotCWdvdG8gZmluaXNoOwotICAgIH0KKyAgICAvKiBp c3N1ZSBzb2Z0IHJlc2V0ICovCisgICAgc2lnbmF0dXJlID0gYXRhX3NpaXByYl9zb2Z0cmVzZXQo ZGV2LCBBVEFfUE0pOwogICAgIGlmIChib290dmVyYm9zZSkKLQlkZXZpY2VfcHJpbnRmKGNoLT5k ZXYsICJzb2Z0IHJlc2V0IGV4ZWMgdGltZT0lZG1zIHN0YXR1cz0lMDh4XG4iLAotCQkJdGltZW91 dCwgc3RhdHVzKTsKKwlkZXZpY2VfcHJpbnRmKGRldiwgIlNJR05BVFVSRT0lMDh4XG4iLCBzaWdu YXR1cmUpOwogCi0gICAgLyogZmluZCBvdXQgd2hhdHMgdGhlcmUgKi8KLSAgICBwcmIgPSAoc3Ry dWN0IGF0YV9zaWlwcmJfY29tbWFuZCAqKQotCSgodV9pbnQ4X3QgKilybWFuX2dldF92aXJ0dWFs KGN0bHItPnJfcmVzMikgKyAodGFnIDw8IDcpICsgb2Zmc2V0KTsKLSAgICBzaWduYXR1cmUgPQot CXByYi0+ZmlzWzEyXXwocHJiLT5maXNbNF08PDgpfChwcmItPmZpc1s1XTw8MTYpfChwcmItPmZp c1s2XTw8MjQpOwotICAgIGlmIChib290dmVyYm9zZSkKLQlkZXZpY2VfcHJpbnRmKGNoLT5kZXYs ICJTSUdOQVRVUkU9JTA4eFxuIiwgc2lnbmF0dXJlKTsKKyAgICAvKiBmaWd1cmUgb3V0IHdoYXRz IHRoZXJlICovCiAgICAgc3dpdGNoIChzaWduYXR1cmUpIHsKICAgICBjYXNlIDB4MDAwMDAxMDE6 CiAJY2gtPmRldmljZXMgPSBBVEFfQVRBX01BU1RFUjsKIAlicmVhazsKICAgICBjYXNlIDB4OTY2 OTAxMDE6CiAJY2gtPmRldmljZXMgPSBBVEFfUE9SVE1VTFRJUExJRVI7Ci0JZGV2aWNlX3ByaW50 ZihjaC0+ZGV2LCAiUG9ydG11bHRpcGxpZXJzIG5vdCBzdXBwb3J0ZWQgeWV0XG4iKTsKLQljaC0+ ZGV2aWNlcyA9IDA7CisJQVRBX09VVEwoY3Rsci0+cl9yZXMyLCAweDEwMDAgKyBvZmZzZXQsIDB4 MjAwMCk7IC8qIGVuYWJsZSBQTSBzdXBwb3J0ICovCisJYXRhX3BtX2lkZW50aWZ5KGRldik7CiAJ YnJlYWs7CiAgICAgY2FzZSAweGViMTQwMTAxOgogCWNoLT5kZXZpY2VzID0gQVRBX0FUQVBJX01B U1RFUjsKQEAgLTUwOTcsOCArNTc4Niw3IEBAIGF0YV9zaWlwcmJfcmVzZXQoZGV2aWNlX3QgZGV2 KQogCWNoLT5kZXZpY2VzID0gMDsKICAgICB9CiAgICAgaWYgKGJvb3R2ZXJib3NlKQotICAgICAg ICBkZXZpY2VfcHJpbnRmKGRldiwgInNpaXByYl9yZXNldCBkZXZpY2VzPTB4JWJcbiIsIGNoLT5k ZXZpY2VzLAotICAgICAgICAgICAgICAgICAgICAgICJcMjBcNEFUQVBJX1NMQVZFXDNBVEFQSV9N QVNURVJcMkFUQV9TTEFWRVwxQVRBX01BU1RFUiIpOworICAgICAgICBkZXZpY2VfcHJpbnRmKGRl diwgInNpaXByYl9yZXNldCBkZXZpY2VzPSUwOHhcbiIsIGNoLT5kZXZpY2VzKTsKIAogZmluaXNo OgogICAgIC8qIGNsZWFyIGludGVycnVwdChzKSAqLwpAQCAtNTEyOSw3ICs1ODE3LDcgQEAgYXRh X3NpaXByYl9kbWFzZXRwcmQodm9pZCAqeHNjLCBidXNfZG1hXwogCXByZFtpXS5jb3VudCA9IGh0 b2xlMzIoc2Vnc1tpXS5kc19sZW4pOwogICAgIH0KICAgICBwcmRbaSAtIDFdLmNvbnRyb2wgPSBo dG9sZTMyKEFUQV9ETUFfRU9UKTsKLSAgICBLQVNTRVJUKG5zZWdzIDw9IEFUQV9ETUFfRU5UUklF UywgKCJ0b28gbWFueSBETUEgc2VnbWVudCBlbnRyaWVzXG4iKSk7CisgICAgS0FTU0VSVChuc2Vn cyA8PSBBVEFfU0lJUFJCX0RNQV9FTlRSSUVTLCgidG9vIG1hbnkgRE1BIHNlZ21lbnQgZW50cmll c1xuIikpOwogICAgIGFyZ3MtPm5zZWdzID0gbnNlZ3M7CiB9CiAKQEAgLTUxMzksMTEgKzU4Mjcs OSBAQCBhdGFfc2lpcHJiX2RtYWluaXQoZGV2aWNlX3QgZGV2KQogICAgIHN0cnVjdCBhdGFfY2hh bm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKICAgICBhdGFfZG1haW5pdChkZXYp OwotICAgIGlmIChjaC0+ZG1hKSB7Ci0JLyogbm90ZSBzdGFydCBhbmQgc3RvcCBhcmUgbm90IHVz ZWQgaGVyZSAqLwotCWNoLT5kbWEtPnNldHByZCA9IGF0YV9zaWlwcmJfZG1hc2V0cHJkOwotCWNo LT5kbWEtPm1heF9hZGRyZXNzID0gQlVTX1NQQUNFX01BWEFERFI7Ci0gICAgfQorICAgIC8qIG5v dGUgc3RhcnQgYW5kIHN0b3AgYXJlIG5vdCB1c2VkIGhlcmUgKi8KKyAgICBjaC0+ZG1hLnNldHBy ZCA9IGF0YV9zaWlwcmJfZG1hc2V0cHJkOworICAgIGNoLT5kbWEubWF4X2FkZHJlc3MgPSBCVVNf U1BBQ0VfTUFYQUREUjsKIH0KIAogCkBAIC01MzE0LDcgKzYwMDAsNyBAQCBhdGFfc2lzX3NldG1v ZGUoZGV2aWNlX3QgZGV2LCBpbnQgbW9kZSkKICAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVy ICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhncGFyZW50KTsKICAgICBzdHJ1Y3QgYXRhX2NoYW5u ZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKICAgICBz dHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwotICAgIGlu dCBkZXZubyA9IChjaC0+dW5pdCA8PCAxKSArIEFUQV9ERVYoYXRhZGV2LT51bml0KTsKKyAgICBp bnQgZGV2bm8gPSAoY2gtPnVuaXQgPDwgMSkgKyBhdGFkZXYtPnVuaXQ7CiAgICAgaW50IGVycm9y OwogCiAgICAgbW9kZSA9IGF0YV9saW1pdF9tb2RlKGRldiwgbW9kZSwgY3Rsci0+Y2hpcC0+bWF4 X2RtYSk7CkBAIC01NjM5LDcgKzYzMjUsNyBAQCBhdGFfdmlhX2ZhbWlseV9zZXRtb2RlKGRldmlj ZV90IGRldiwgaW50CiAJeyAweGY3LCAweGY2LCAweGY0LCAweGYyLCAweGYxLCAweGYwLCAweDAw IH0sICAgLyogVklBIEFUQTEwMCAqLwogCXsgMHhmNywgMHhmNywgMHhmNiwgMHhmNCwgMHhmMiwg MHhmMSwgMHhmMCB9LCAgIC8qIFZJQSBBVEExMzMgKi8KIAl7IDB4YzIsIDB4YzEsIDB4YzAsIDB4 YzQsIDB4YzUsIDB4YzYsIDB4YzcgfX07ICAvKiBBTUQvblZJRElBICovCi0gICAgaW50IGRldm5v ID0gKGNoLT51bml0IDw8IDEpICsgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworICAgIGludCBkZXZu byA9IChjaC0+dW5pdCA8PCAxKSArIGF0YWRldi0+dW5pdDsKICAgICBpbnQgcmVnID0gMHg1MyAt IGRldm5vOwogICAgIGludCBlcnJvcjsKIApAQCAtNTc5Myw3ICs2NDc5LDcgQEAgYXRhX3Nlcmlh bGl6ZShkZXZpY2VfdCBkZXYsIGludCBmbGFncykKIAkJaWYgKChjaCA9IGN0bHItPmludGVycnVw dFtzZXJpYWwtPnJlc3RhcnRfY2hdLmFyZ3VtZW50KSkgewogCQkgICAgc2VyaWFsLT5yZXN0YXJ0 X2NoID0gLTE7CiAJCSAgICBtdHhfdW5sb2NrKCZzZXJpYWwtPmxvY2tlZF9tdHgpOwotCQkgICAg YXRhX3N0YXJ0KGNoLT5kZXYpOworCQkgICAgYXRhX3N0YXJ0KGRldik7CiAJCSAgICByZXR1cm4g LTE7CiAJCX0KIAkgICAgfQotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1kaXNrLmMJMjAwOC0wNC0w OCAxNDo0ODoyMS4wMDAwMDAwMDAgKzA0MDAKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtZGlzay5j CTIwMDgtMDUtMDggMjE6NTU6NDQuMDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyot Ci0gKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNE Lm9yZz4KKyAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZy ZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlv biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKQEAg LTM5LDcgKzM5LDYgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMvc3lzL2Rldi9hdGEvYXRhLQog I2luY2x1ZGUgPHN5cy9jb25mLmg+CiAjaW5jbHVkZSA8c3lzL2Rpc2suaD4KICNpbmNsdWRlIDxz eXMvY29ucy5oPgotI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KICNpbmNsdWRlIDxzeXMvc2VtYS5o PgogI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KICNpbmNsdWRlIDx2bS91bWEuaD4KQEAgLTU0 LDEwICs1MywxMiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L2F0YS9hdGEtCiAj aW5jbHVkZSA8YXRhX2lmLmg+CiAKIC8qIHByb3RvdHlwZXMgKi8KLXN0YXRpYyB2b2lkIGFkX2lu aXQoZGV2aWNlX3QpOwotc3RhdGljIHZvaWQgYWRfZG9uZShzdHJ1Y3QgYXRhX3JlcXVlc3QgKik7 CitzdGF0aWMgdm9pZCBhZF9pbml0KGRldmljZV90IGRldik7CitzdGF0aWMgdm9pZCBhZF9nZXRf Z2VvbWV0cnkoZGV2aWNlX3QgZGV2KTsKK3N0YXRpYyB2b2lkIGFkX3NldF9nZW9tZXRyeShkZXZp Y2VfdCBkZXYpOworc3RhdGljIHZvaWQgYWRfZG9uZShzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVl c3QpOwogc3RhdGljIHZvaWQgYWRfZGVzY3JpYmUoZGV2aWNlX3QgZGV2KTsKLXN0YXRpYyBpbnQg YWRfdmVyc2lvbih1X2ludDE2X3QpOworc3RhdGljIGludCBhZF92ZXJzaW9uKHVfaW50MTZfdCB2 ZXJzaW9uKTsKIHN0YXRpYyBkaXNrX3N0cmF0ZWd5X3QgYWRfc3RyYXRlZ3k7CiBzdGF0aWMgZGlz a19pb2N0bF90IGFkX2lvY3RsOwogc3RhdGljIGR1bXBlcl90IGFkX2R1bXA7CkBAIC05Myw4ICs5 NCw2IEBAIGFkX2F0dGFjaChkZXZpY2VfdCBkZXYpCiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CiAgICAgc3RydWN0 IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKICAgICBzdHJ1Y3Qg YWRfc29mdGMgKmFkcDsKLSAgICB1X2ludDMyX3QgbGJhc2l6ZTsKLSAgICB1X2ludDY0X3QgbGJh c2l6ZTQ4OwogCiAgICAgLyogY2hlY2sgdGhhdCB3ZSBoYXZlIGEgdmlyZ2luIGRpc2sgdG8gYXR0 YWNoICovCiAgICAgaWYgKGRldmljZV9nZXRfaXZhcnMoZGV2KSkKQEAgLTEwNiwzNyArMTA1LDEy IEBAIGFkX2F0dGFjaChkZXZpY2VfdCBkZXYpCiAgICAgfQogICAgIGRldmljZV9zZXRfaXZhcnMo ZGV2LCBhZHApOwogCi0gICAgaWYgKChhdGFkZXYtPnBhcmFtLmF0YXZhbGlkICYgQVRBX0ZMQUdf NTRfNTgpICYmCi0JYXRhZGV2LT5wYXJhbS5jdXJyZW50X2hlYWRzICYmIGF0YWRldi0+cGFyYW0u Y3VycmVudF9zZWN0b3JzKSB7Ci0JYWRwLT5oZWFkcyA9IGF0YWRldi0+cGFyYW0uY3VycmVudF9o ZWFkczsKLQlhZHAtPnNlY3RvcnMgPSBhdGFkZXYtPnBhcmFtLmN1cnJlbnRfc2VjdG9yczsKLQlh ZHAtPnRvdGFsX3NlY3MgPSAodV9pbnQzMl90KWF0YWRldi0+cGFyYW0uY3VycmVudF9zaXplXzEg fAotCQkJICAoKHVfaW50MzJfdClhdGFkZXYtPnBhcmFtLmN1cnJlbnRfc2l6ZV8yIDw8IDE2KTsK LSAgICB9Ci0gICAgZWxzZSB7Ci0JYWRwLT5oZWFkcyA9IGF0YWRldi0+cGFyYW0uaGVhZHM7Ci0J YWRwLT5zZWN0b3JzID0gYXRhZGV2LT5wYXJhbS5zZWN0b3JzOwotCWFkcC0+dG90YWxfc2VjcyA9 IGF0YWRldi0+cGFyYW0uY3lsaW5kZXJzICogYWRwLT5oZWFkcyAqIGFkcC0+c2VjdG9yczsgIAot ICAgIH0KLSAgICBsYmFzaXplID0gKHVfaW50MzJfdClhdGFkZXYtPnBhcmFtLmxiYV9zaXplXzEg fAotCSAgICAgICgodV9pbnQzMl90KWF0YWRldi0+cGFyYW0ubGJhX3NpemVfMiA8PCAxNik7Ci0K LSAgICAvKiBkb2VzIHRoaXMgZGV2aWNlIG5lZWQgb2xkc3R5bGUgQ0hTIGFkZHJlc3NpbmcgKi8K LSAgICBpZiAoIWFkX3ZlcnNpb24oYXRhZGV2LT5wYXJhbS52ZXJzaW9uX21ham9yKSB8fCAhbGJh c2l6ZSkKLQlhdGFkZXYtPmZsYWdzIHw9IEFUQV9EX1VTRV9DSFM7CisgICAgLyogZ2V0IGRldmlj ZSBnZW9tZXRyeSBpbnRvIGludGVybmFsIHN0cnVjdHMgKi8KKyAgICBhZF9nZXRfZ2VvbWV0cnko ZGV2KTsKIAotICAgIC8qIHVzZSB0aGUgMjhiaXQgTEJBIHNpemUgaWYgdmFsaWQgb3IgYmlnZ2Vy IHRoYW4gdGhlIENIUyBtYXBwaW5nICovCi0gICAgaWYgKGF0YWRldi0+cGFyYW0uY3lsaW5kZXJz ID09IDE2MzgzIHx8IGFkcC0+dG90YWxfc2VjcyA8IGxiYXNpemUpCi0JYWRwLT50b3RhbF9zZWNz ID0gbGJhc2l6ZTsKLQotICAgIC8qIHVzZSB0aGUgNDhiaXQgTEJBIHNpemUgaWYgdmFsaWQgKi8K LSAgICBsYmFzaXplNDggPSAoKHVfaW50NjRfdClhdGFkZXYtPnBhcmFtLmxiYV9zaXplNDhfMSkg fAotCQkoKHVfaW50NjRfdClhdGFkZXYtPnBhcmFtLmxiYV9zaXplNDhfMiA8PCAxNikgfAotCQko KHVfaW50NjRfdClhdGFkZXYtPnBhcmFtLmxiYV9zaXplNDhfMyA8PCAzMikgfAotCQkoKHVfaW50 NjRfdClhdGFkZXYtPnBhcmFtLmxiYV9zaXplNDhfNCA8PCA0OCk7Ci0gICAgaWYgKChhdGFkZXYt PnBhcmFtLnN1cHBvcnQuY29tbWFuZDIgJiBBVEFfU1VQUE9SVF9BRERSRVNTNDgpICYmCi0JbGJh c2l6ZTQ4ID4gQVRBX01BWF8yOEJJVF9MQkEpCi0JYWRwLT50b3RhbF9zZWNzID0gbGJhc2l6ZTQ4 OworICAgIC8qIHNldCB0aGUgbWF4IHNpemUgaWYgY29uZmlndXJlZCAqLworICAgIGlmIChhdGFf c2V0bWF4KQorCWFkX3NldF9nZW9tZXRyeShkZXYpOwogCiAgICAgLyogaW5pdCBkZXZpY2UgcGFy YW1ldGVycyAqLwogICAgIGFkX2luaXQoZGV2KTsKQEAgLTE1MSwxMCArMTI1LDcgQEAgYWRfYXR0 YWNoKGRldmljZV90IGRldikKICAgICBhZHAtPmRpc2stPmRfZHVtcCA9IGFkX2R1bXA7CiAgICAg YWRwLT5kaXNrLT5kX25hbWUgPSAiYWQiOwogICAgIGFkcC0+ZGlzay0+ZF9kcnYxID0gZGV2Owot ICAgIGlmIChjaC0+ZG1hKQotCWFkcC0+ZGlzay0+ZF9tYXhzaXplID0gY2gtPmRtYS0+bWF4X2lv c2l6ZTsKLSAgICBlbHNlCi0JYWRwLT5kaXNrLT5kX21heHNpemUgPSBERkxUUEhZUzsKKyAgICBh ZHAtPmRpc2stPmRfbWF4c2l6ZSA9IGNoLT5kbWEubWF4X2lvc2l6ZSA/IGNoLT5kbWEubWF4X2lv c2l6ZSA6IERGTFRQSFlTOwogICAgIGFkcC0+ZGlzay0+ZF9zZWN0b3JzaXplID0gREVWX0JTSVpF OwogICAgIGFkcC0+ZGlzay0+ZF9tZWRpYXNpemUgPSBERVZfQlNJWkUgKiAob2ZmX3QpYWRwLT50 b3RhbF9zZWNzOwogICAgIGFkcC0+ZGlzay0+ZF9md3NlY3RvcnMgPSBhZHAtPnNlY3RvcnM7CkBA IC0yNDksNyArMjIwLDcgQEAgYWRfc3BpbmRvd24odm9pZCAqcHJpdikKICAgICBzdHJ1Y3QgYXRh X2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogICAgIHN0cnVjdCBhdGFf cmVxdWVzdCAqcmVxdWVzdDsKIAotICAgIGlmKGF0YWRldi0+c3BpbmRvd24gPT0gMCkKKyAgICBp ZiAoIWF0YWRldi0+c3BpbmRvd24pCiAJcmV0dXJuOwogICAgIGRldmljZV9wcmludGYoZGV2LCAi SWRsZSwgc3BpbiBkb3duXG4iKTsKICAgICBhdGFkZXYtPnNwaW5kb3duX3N0YXRlID0gMTsKQEAg LTI1Nyw4ICsyMjgsOCBAQCBhZF9zcGluZG93bih2b2lkICpwcml2KQogCWRldmljZV9wcmludGYo ZGV2LCAiRkFJTFVSRSAtIG91dCBvZiBtZW1vcnkgaW4gYWRfc3BpbmRvd25cbiIpOwogCXJldHVy bjsKICAgICB9Ci0gICAgcmVxdWVzdC0+ZmxhZ3MgPSBBVEFfUl9DT05UUk9MOwogICAgIHJlcXVl c3QtPmRldiA9IGRldjsKKyAgICByZXF1ZXN0LT5mbGFncyA9IEFUQV9SX0NPTlRST0w7CiAgICAg cmVxdWVzdC0+dGltZW91dCA9IDU7CiAgICAgcmVxdWVzdC0+cmV0cmllcyA9IDE7CiAgICAgcmVx dWVzdC0+Y2FsbGJhY2sgPSBhZF9wb3dlcl9jYWxsYmFjazsKQEAgLTI3NCw5ICsyNDUsOSBAQCBh ZF9zdHJhdGVneShzdHJ1Y3QgYmlvICpicCkKICAgICBzdHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2 ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogICAgIHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVz dDsKIAotICAgIGlmIChhdGFkZXYtPnNwaW5kb3duICE9IDApCisgICAgaWYgKGF0YWRldi0+c3Bp bmRvd24pCiAJY2FsbG91dF9yZXNldCgmYXRhZGV2LT5zcGluZG93bl90aW1lciwgaHogKiBhdGFk ZXYtPnNwaW5kb3duLAotCSAgICBhZF9zcGluZG93biwgZGV2KTsKKwkJICAgICAgYWRfc3BpbmRv d24sIGRldik7CiAKICAgICBpZiAoIShyZXF1ZXN0ID0gYXRhX2FsbG9jX3JlcXVlc3QoKSkpIHsK IAlkZXZpY2VfcHJpbnRmKGRldiwgIkZBSUxVUkUgLSBvdXQgb2YgbWVtb3J5IGluIHN0YXJ0XG4i KTsKQEAgLTI5Miw3ICsyNjMsOCBAQCBhZF9zdHJhdGVneShzdHJ1Y3QgYmlvICpicCkKIAlkZXZp Y2VfcHJpbnRmKGRldiwgInJlcXVlc3Qgd2hpbGUgc3B1biBkb3duLCBzdGFydGluZy5cbiIpOwog CWF0YWRldi0+c3BpbmRvd25fc3RhdGUgPSAwOwogCXJlcXVlc3QtPnRpbWVvdXQgPSAzMTsKLSAg ICB9IGVsc2UgeworICAgIH0KKyAgICBlbHNlIHsKIAlyZXF1ZXN0LT50aW1lb3V0ID0gNTsKICAg ICB9CiAgICAgcmVxdWVzdC0+cmV0cmllcyA9IDI7CkBAIC00MjYsNyArMzk4LDEwNSBAQCBhZF9p bml0KGRldmljZV90IGRldikKIAlhdGFkZXYtPm1heF9pb3NpemUgPSBERVZfQlNJWkU7CiB9CiAK LXZvaWQKK3N0YXRpYyB2b2lkCithZF9nZXRfZ2VvbWV0cnkoZGV2aWNlX3QgZGV2KQoreworICAg IHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisgICAg c3RydWN0IGFkX3NvZnRjICphZHAgPSBkZXZpY2VfZ2V0X2l2YXJzKGRldik7CisgICAgdV9pbnQ2 NF90IGxiYXNpemU0ODsKKyAgICB1X2ludDMyX3QgbGJhc2l6ZTsKKworICAgIGlmICgoYXRhZGV2 LT5wYXJhbS5hdGF2YWxpZCAmIEFUQV9GTEFHXzU0XzU4KSAmJgorCWF0YWRldi0+cGFyYW0uY3Vy cmVudF9oZWFkcyAmJiBhdGFkZXYtPnBhcmFtLmN1cnJlbnRfc2VjdG9ycykgeworCWFkcC0+aGVh ZHMgPSBhdGFkZXYtPnBhcmFtLmN1cnJlbnRfaGVhZHM7CisJYWRwLT5zZWN0b3JzID0gYXRhZGV2 LT5wYXJhbS5jdXJyZW50X3NlY3RvcnM7CisJYWRwLT50b3RhbF9zZWNzID0gKHVfaW50MzJfdClh dGFkZXYtPnBhcmFtLmN1cnJlbnRfc2l6ZV8xIHwKKwkJCSAgKCh1X2ludDMyX3QpYXRhZGV2LT5w YXJhbS5jdXJyZW50X3NpemVfMiA8PCAxNik7CisgICAgfQorICAgIGVsc2UgeworCWFkcC0+aGVh ZHMgPSBhdGFkZXYtPnBhcmFtLmhlYWRzOworCWFkcC0+c2VjdG9ycyA9IGF0YWRldi0+cGFyYW0u c2VjdG9yczsKKwlhZHAtPnRvdGFsX3NlY3MgPSBhdGFkZXYtPnBhcmFtLmN5bGluZGVycyAqIGFk cC0+aGVhZHMgKiBhZHAtPnNlY3RvcnM7ICAKKyAgICB9CisgICAgbGJhc2l6ZSA9ICh1X2ludDMy X3QpYXRhZGV2LT5wYXJhbS5sYmFfc2l6ZV8xIHwKKwkgICAgICAoKHVfaW50MzJfdClhdGFkZXYt PnBhcmFtLmxiYV9zaXplXzIgPDwgMTYpOworCisgICAgLyogZG9lcyB0aGlzIGRldmljZSBuZWVk IG9sZHN0eWxlIENIUyBhZGRyZXNzaW5nICovCisgICAgaWYgKCFhZF92ZXJzaW9uKGF0YWRldi0+ cGFyYW0udmVyc2lvbl9tYWpvcikgfHwgIWxiYXNpemUpCisJYXRhZGV2LT5mbGFncyB8PSBBVEFf RF9VU0VfQ0hTOworCisgICAgLyogdXNlIHRoZSAyOGJpdCBMQkEgc2l6ZSBpZiB2YWxpZCBvciBi aWdnZXIgdGhhbiB0aGUgQ0hTIG1hcHBpbmcgKi8KKyAgICBpZiAoYXRhZGV2LT5wYXJhbS5jeWxp bmRlcnMgPT0gMTYzODMgfHwgYWRwLT50b3RhbF9zZWNzIDwgbGJhc2l6ZSkKKwlhZHAtPnRvdGFs X3NlY3MgPSBsYmFzaXplOworCisgICAgLyogdXNlIHRoZSA0OGJpdCBMQkEgc2l6ZSBpZiB2YWxp ZCAqLworICAgIGxiYXNpemU0OCA9ICgodV9pbnQ2NF90KWF0YWRldi0+cGFyYW0ubGJhX3NpemU0 OF8xKSB8CisJCSgodV9pbnQ2NF90KWF0YWRldi0+cGFyYW0ubGJhX3NpemU0OF8yIDw8IDE2KSB8 CisJCSgodV9pbnQ2NF90KWF0YWRldi0+cGFyYW0ubGJhX3NpemU0OF8zIDw8IDMyKSB8CisJCSgo dV9pbnQ2NF90KWF0YWRldi0+cGFyYW0ubGJhX3NpemU0OF80IDw8IDQ4KTsKKyAgICBpZiAoKGF0 YWRldi0+cGFyYW0uc3VwcG9ydC5jb21tYW5kMiAmIEFUQV9TVVBQT1JUX0FERFJFU1M0OCkgJiYK KwlsYmFzaXplNDggPiBBVEFfTUFYXzI4QklUX0xCQSkKKwlhZHAtPnRvdGFsX3NlY3MgPSBsYmFz aXplNDg7Cit9CisKK3N0YXRpYyB2b2lkCithZF9zZXRfZ2VvbWV0cnkoZGV2aWNlX3QgZGV2KQor eworICAgIHN0cnVjdCBhZF9zb2Z0YyAqYWRwID0gZGV2aWNlX2dldF9pdmFycyhkZXYpOworICAg IHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdDsKKworICAgIGlmICgxIHwgYm9vdHZlcmJvc2Up CisJZGV2aWNlX3ByaW50ZihkZXYsICJPUkcgJWp1IHNlY3RvcnMgWyVqdUMvJWRILyVkU11cbiIs IGFkcC0+dG90YWxfc2VjcywKKwkJICAgICAgYWRwLT50b3RhbF9zZWNzIC8gKGFkcC0+aGVhZHMg KiBhZHAtPnNlY3RvcnMpLAorCQkgICAgICBhZHAtPmhlYWRzLCBhZHAtPnNlY3RvcnMpOworCisg ICAgaWYgKCEocmVxdWVzdCA9IGF0YV9hbGxvY19yZXF1ZXN0KCkpKQorCXJldHVybjsKKworICAg IC8qIGdldCB0aGUgbWF4IG5hdGl2ZSBzaXplIHRoZSBkZXZpY2Ugc3VwcG9ydHMgKi8KKyAgICBy ZXF1ZXN0LT5kZXYgPSBkZXY7CisgICAgcmVxdWVzdC0+dS5hdGEuY29tbWFuZCA9IEFUQV9SRUFE X05BVElWRV9NQVhfQUREUkVTUzsKKyAgICByZXF1ZXN0LT51LmF0YS5sYmEgPSAwOworICAgIHJl cXVlc3QtPnUuYXRhLmNvdW50ID0gMDsKKyAgICByZXF1ZXN0LT51LmF0YS5mZWF0dXJlID0gMDsK KyAgICByZXF1ZXN0LT5mbGFncyA9IEFUQV9SX0NPTlRST0wgfCBBVEFfUl9RVUlFVDsKKyAgICBy ZXF1ZXN0LT50aW1lb3V0ID0gNTsKKyAgICByZXF1ZXN0LT5yZXRyaWVzID0gMDsKKyAgICBhdGFf cXVldWVfcmVxdWVzdChyZXF1ZXN0KTsKKyAgICBpZiAocmVxdWVzdC0+c3RhdHVzICYgQVRBX1Nf RVJST1IpCisJZ290byBvdXQ7CisKKyAgICBpZiAoMSB8IGJvb3R2ZXJib3NlKQorCWRldmljZV9w cmludGYoZGV2LCAiTUFYICVqdSBzZWN0b3JzXG4iLCByZXF1ZXN0LT51LmF0YS5sYmEgKyAxKTsK KworICAgIC8qIGlmIG9yaWdpbmFsIHNpemUgZXF1YWxzIG1heCBzaXplIG5vdGhpbmcgbW9yZSB0 b2RvICovCisgICAgaWYgKGFkcC0+dG90YWxfc2VjcyA+PSByZXF1ZXN0LT51LmF0YS5sYmEpCisJ Z290byBvdXQ7CisKKyAgICAvKiBzZXQgdGhlIG1heCBuYXRpdmUgc2l6ZSB0byBpdHMgbWF4ICov CisgICAgcmVxdWVzdC0+ZGV2ID0gZGV2OworICAgIHJlcXVlc3QtPnUuYXRhLmNvbW1hbmQgPSBB VEFfU0VUX01BWF9BRERSRVNTOworICAgIHJlcXVlc3QtPnUuYXRhLmNvdW50ID0gMTsKKyAgICBy ZXF1ZXN0LT51LmF0YS5mZWF0dXJlID0gMDsKKyAgICByZXF1ZXN0LT5mbGFncyA9IEFUQV9SX0NP TlRST0w7CisgICAgcmVxdWVzdC0+dGltZW91dCA9IDU7CisgICAgcmVxdWVzdC0+cmV0cmllcyA9 IDA7CisgICAgYXRhX3F1ZXVlX3JlcXVlc3QocmVxdWVzdCk7CisgICAgaWYgKHJlcXVlc3QtPnN0 YXR1cyAmIEFUQV9TX0VSUk9SKQorCWdvdG8gb3V0OworCisgICAgLyogcmVmcmVzaCBnZW9tZXRy eSBmcm9tIGRyaXZlICovCisgICAgYXRhX2dldHBhcmFtKGRldmljZV9nZXRfc29mdGMoZGV2KSwg MCk7CisgICAgYWRfZ2V0X2dlb21ldHJ5KGRldik7CisgICAgaWYgKDEgfCBib290dmVyYm9zZSkK KwlkZXZpY2VfcHJpbnRmKGRldiwgIk5FVyAlanUgc2VjdG9ycyBbJWp1Qy8lZEgvJWRTXVxuIiwg YWRwLT50b3RhbF9zZWNzLAorCQkgICAgICBhZHAtPnRvdGFsX3NlY3MgLyAoYWRwLT5oZWFkcyAq IGFkcC0+c2VjdG9ycyksCisJCSAgICAgIGFkcC0+aGVhZHMsIGFkcC0+c2VjdG9ycyk7CitvdXQ6 CisgICAgYXRhX2ZyZWVfcmVxdWVzdChyZXF1ZXN0KTsKK30KKworc3RhdGljIHZvaWQKIGFkX2Rl c2NyaWJlKGRldmljZV90IGRldikKIHsKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2 aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKQEAgLTQ1OCw4ICs1MjgsNyBA QCBhZF9kZXNjcmliZShkZXZpY2VfdCBkZXYpCiAgICAgZGV2aWNlX3ByaW50ZihkZXYsICIlanVN QiA8JXMlcyAlLjhzPiBhdCBhdGElZC0lcyAlcyVzXG4iLAogCQkgIGFkcC0+dG90YWxfc2VjcyAv ICgxMDQ4NTc2IC8gREVWX0JTSVpFKSwKIAkJICB2ZW5kb3IsIHByb2R1Y3QsIGF0YWRldi0+cGFy YW0ucmV2aXNpb24sCi0JCSAgZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLAotCQkgIChhdGFkZXYt PnVuaXQgPT0gQVRBX01BU1RFUikgPyAibWFzdGVyIiA6ICJzbGF2ZSIsCisJCSAgZGV2aWNlX2dl dF91bml0KGNoLT5kZXYpLCBhdGFfdW5pdDJzdHIoYXRhZGV2KSwKIAkJICAoYWRwLT5mbGFncyAm IEFEX0ZfVEFHX0VOQUJMRUQpID8gInRhZ2dlZCAiIDogIiIsCiAJCSAgYXRhX21vZGUyc3RyKGF0 YWRldi0+bW9kZSkpOwogICAgIGlmIChib290dmVyYm9zZSkgewotLS0gc3JjL3N5cy9kZXYvYXRh L2F0YS1kaXNrLmgJMjAwNy0wMi0yMSAyMjowNzoxOC4wMDAwMDAwMDAgKzAzMDAKKysrIHNyYy9z eXMvZGV2L2F0YS9hdGEtZGlzay5oCTIwMDgtMDQtMTAgMTc6MDU6MDUuMDAwMDAwMDAwICswNDAw CkBAIC0xLDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA3IFP4cmVu IFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDgg U/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4K ICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1z LCB3aXRoIG9yIHdpdGhvdXQKQEAgLTM0LDcgKzM0LDcgQEAgc3RydWN0IGFkX3NvZnRjIHsgIAog ICAgIHVfaW50MzJfdCAgICAgICAgICAgICAgICAgICB0cmFuc2ZlcnNpemU7ICAgLyogc2l6ZSBv ZiBlYWNoIHRyYW5zZmVyICovCiAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgICAgIG51bV90 YWdzOyAgICAgICAvKiBudW1iZXIgb2YgdGFncyBzdXBwb3J0ZWQgKi8KICAgICBpbnQgICAgICAg ICAgICAgICAgICAgICAgICAgZmxhZ3M7ICAgICAgICAgIC8qIGRyaXZlIGZsYWdzICovCi0jZGVm aW5lICAgICAgICAgQURfRl9MQUJFTExJTkcgICAgICAgICAgMHgwMDAxICAgICAgICAgIAorI2Rl ZmluZSAgICAgICAgIEFEX0ZfTEFCRUxMSU5HICAgICAgICAgIDB4MDAwMQogI2RlZmluZSAgICAg ICAgIEFEX0ZfQ0hTX1VTRUQgICAgICAgICAgIDB4MDAwMgogI2RlZmluZSAgICAgICAgIEFEX0Zf MzJCX0VOQUJMRUQgICAgICAgIDB4MDAwNAogI2RlZmluZSAgICAgICAgIEFEX0ZfVEFHX0VOQUJM RUQgICAgICAgIDB4MDAwOAotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1kbWEuYwkyMDA4LTAxLTA5 IDExOjU0OjQ3LjAwMDAwMDAwMCArMDMwMAorKysgc3JjL3N5cy9kZXYvYXRhL2F0YS1kbWEuYwky MDA4LTA0LTE4IDE5OjE1OjA0LjAwMDAwMDAwMCArMDQwMApAQCAtMSw1ICsxLDUgQEAKIC8qLQot ICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwNyBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5v cmc+CisgKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA4IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVl QlNELm9yZz4KICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24g YW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CkBAIC00 NSwxMSArNDUsMTMgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMvc3lzL2Rldi9hdGEvYXRhLQog I2luY2x1ZGUgPGRldi9hdGEvYXRhLXBjaS5oPgogCiAvKiBwcm90b3R5cGVzICovCi1zdGF0aWMg dm9pZCBhdGFfZG1hYWxsb2MoZGV2aWNlX3QpOwotc3RhdGljIHZvaWQgYXRhX2RtYWZyZWUoZGV2 aWNlX3QpOwotc3RhdGljIHZvaWQgYXRhX2RtYXNldHByZCh2b2lkICosIGJ1c19kbWFfc2VnbWVu dF90ICosIGludCwgaW50KTsKLXN0YXRpYyBpbnQgYXRhX2RtYWxvYWQoZGV2aWNlX3QsIGNhZGRy X3QsIGludDMyX3QsIGludCwgdm9pZCAqLCBpbnQgKik7Ci1zdGF0aWMgaW50IGF0YV9kbWF1bmxv YWQoZGV2aWNlX3QpOworc3RhdGljIHZvaWQgYXRhX2RtYWZpbmkoZGV2aWNlX3QgZGV2KTsKK3N0 YXRpYyB2b2lkIGF0YV9kbWFzZXR1cGNfY2Iodm9pZCAqeHNjLCBidXNfZG1hX3NlZ21lbnRfdCAq c2VncywgaW50IG5zZWdzLCBpbnQgZXJyb3IpOworc3RhdGljIHZvaWQgYXRhX2RtYWFsbG9jKGRl dmljZV90IGRldik7CitzdGF0aWMgdm9pZCBhdGFfZG1hZnJlZShkZXZpY2VfdCBkZXYpOworc3Rh dGljIHZvaWQgYXRhX2RtYXNldHByZCh2b2lkICp4c2MsIGJ1c19kbWFfc2VnbWVudF90ICpzZWdz LCBpbnQgbnNlZ3MsIGludCBlcnJvcik7CitzdGF0aWMgaW50IGF0YV9kbWFsb2FkKHN0cnVjdCBh dGFfcmVxdWVzdCAqcmVxdWVzdCwgdm9pZCAqYWRkciwgaW50ICpuc2Vncyk7CitzdGF0aWMgaW50 IGF0YV9kbWF1bmxvYWQoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KTsKIAogLyogbG9jYWwg dmFycyAqLwogc3RhdGljIE1BTExPQ19ERUZJTkUoTV9BVEFETUEsICJhdGFfZG1hIiwgIkFUQSBk cml2ZXIgRE1BIik7CkBAIC02NywxMzQgKzY5LDE3MCBAQCB2b2lkIAogYXRhX2RtYWluaXQoZGV2 aWNlX3QgZGV2KQogewogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisgICAgc3RydWN0IGF0YV9kY19jYl9hcmdzIGRjYmE7CiAKLSAgICBpZiAoKGNo LT5kbWEgPSBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBhdGFfZG1hKSwgTV9BVEFETUEsIE1fTk9XQUlU fE1fWkVSTykpKSB7Ci0JY2gtPmRtYS0+YWxsb2MgPSBhdGFfZG1hYWxsb2M7Ci0JY2gtPmRtYS0+ ZnJlZSA9IGF0YV9kbWFmcmVlOwotCWNoLT5kbWEtPnNldHByZCA9IGF0YV9kbWFzZXRwcmQ7Ci0J Y2gtPmRtYS0+bG9hZCA9IGF0YV9kbWFsb2FkOwotCWNoLT5kbWEtPnVubG9hZCA9IGF0YV9kbWF1 bmxvYWQ7Ci0JY2gtPmRtYS0+YWxpZ25tZW50ID0gMjsKLQljaC0+ZG1hLT5ib3VuZGFyeSA9IDY1 NTM2OwotCWNoLT5kbWEtPnNlZ3NpemUgPSAxMjggKiBERVZfQlNJWkU7Ci0JY2gtPmRtYS0+bWF4 X2lvc2l6ZSA9IDEyOCAqIERFVl9CU0laRTsKLQljaC0+ZG1hLT5tYXhfYWRkcmVzcyA9IEJVU19T UEFDRV9NQVhBRERSXzMyQklUOworICAgIGNoLT5kbWEuYWxsb2MgPSBhdGFfZG1hYWxsb2M7Cisg ICAgY2gtPmRtYS5mcmVlID0gYXRhX2RtYWZyZWU7CisgICAgY2gtPmRtYS5zZXRwcmQgPSBhdGFf ZG1hc2V0cHJkOworICAgIGNoLT5kbWEubG9hZCA9IGF0YV9kbWFsb2FkOworICAgIGNoLT5kbWEu dW5sb2FkID0gYXRhX2RtYXVubG9hZDsKKyAgICBjaC0+ZG1hLmFsaWdubWVudCA9IDI7CisgICAg Y2gtPmRtYS5ib3VuZGFyeSA9IDY1NTM2OworICAgIGNoLT5kbWEuc2Vnc2l6ZSA9IDYzNTM2Owor ICAgIGNoLT5kbWEubWF4X2lvc2l6ZSA9IDEyOCAqIERFVl9CU0laRTsKKyAgICBjaC0+ZG1hLm1h eF9hZGRyZXNzID0gQlVTX1NQQUNFX01BWEFERFJfMzJCSVQ7CisgICAgY2gtPmRtYS5kbWFfc2xv dHMgPSAyOworCisgICAgaWYgKGJ1c19kbWFfdGFnX2NyZWF0ZShidXNfZ2V0X2RtYV90YWcoZGV2 KSwgY2gtPmRtYS5hbGlnbm1lbnQsIDAsCisJCQkgICBjaC0+ZG1hLm1heF9hZGRyZXNzLCBCVVNf U1BBQ0VfTUFYQUREUiwKKwkJCSAgIE5VTEwsIE5VTEwsIGNoLT5kbWEubWF4X2lvc2l6ZSwKKwkJ CSAgIEFUQV9ETUFfRU5UUklFUywgY2gtPmRtYS5zZWdzaXplLAorCQkJICAgMCwgTlVMTCwgTlVM TCwgJmNoLT5kbWEuZG1hdGFnKSkKKwlnb3RvIGVycm9yOworCisgICAgaWYgKGJ1c19kbWFfdGFn X2NyZWF0ZShjaC0+ZG1hLmRtYXRhZywgUEFHRV9TSVpFLCA2NCAqIDEwMjQsCisJCQkgICBjaC0+ ZG1hLm1heF9hZGRyZXNzLCBCVVNfU1BBQ0VfTUFYQUREUiwKKwkJCSAgIE5VTEwsIE5VTEwsIE1B WFdTUENTWiwgMSwgTUFYV1NQQ1NaLAorCQkJICAgMCwgTlVMTCwgTlVMTCwgJmNoLT5kbWEud29y a190YWcpKQorCWdvdG8gZXJyb3I7CisKKyAgICBpZiAoYnVzX2RtYW1lbV9hbGxvYyhjaC0+ZG1h LndvcmtfdGFnLCAodm9pZCAqKikmY2gtPmRtYS53b3JrLCAwLAorCQkJICZjaC0+ZG1hLndvcmtf bWFwKSkKKwlnb3RvIGVycm9yOworCisgICAgaWYgKGJ1c19kbWFtYXBfbG9hZChjaC0+ZG1hLndv cmtfdGFnLCBjaC0+ZG1hLndvcmtfbWFwLCBjaC0+ZG1hLndvcmssCisJCQlNQVhXU1BDU1osIGF0 YV9kbWFzZXR1cGNfY2IsICZkY2JhLCAwKSB8fAorCQkJZGNiYS5lcnJvcikgeworCWJ1c19kbWFt ZW1fZnJlZShjaC0+ZG1hLndvcmtfdGFnLCBjaC0+ZG1hLndvcmssIGNoLT5kbWEud29ya19tYXAp OworCWdvdG8gZXJyb3I7CisgICAgfQorICAgIGNoLT5kbWEud29ya19idXMgPSBkY2JhLm1hZGRy OworICAgIHJldHVybjsKKworZXJyb3I6CisgICAgZGV2aWNlX3ByaW50ZihkZXYsICJXQVJOSU5H IC0gRE1BIGluaXRpYWxpemF0aW9uIGZhaWxlZCwgZGlzYWJsaW5nIERNQVxuIik7CisgICAgYXRh X2RtYWZpbmkoZGV2KTsKK30KKwordm9pZCAKK2F0YV9kbWFmaW5pKGRldmljZV90IGRldikKK3sK KyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCisg ICAgaWYgKGNoLT5kbWEud29ya19idXMpIHsKKwlidXNfZG1hbWFwX3VubG9hZChjaC0+ZG1hLndv cmtfdGFnLCBjaC0+ZG1hLndvcmtfbWFwKTsKKwlidXNfZG1hbWVtX2ZyZWUoY2gtPmRtYS53b3Jr X3RhZywgY2gtPmRtYS53b3JrLCBjaC0+ZG1hLndvcmtfbWFwKTsKKwljaC0+ZG1hLndvcmtfYnVz ID0gMDsKKwljaC0+ZG1hLndvcmtfbWFwID0gTlVMTDsKKwljaC0+ZG1hLndvcmsgPSBOVUxMOwor ICAgIH0KKyAgICBpZiAoY2gtPmRtYS53b3JrX3RhZykgeworCWJ1c19kbWFfdGFnX2Rlc3Ryb3ko Y2gtPmRtYS53b3JrX3RhZyk7CisJY2gtPmRtYS53b3JrX3RhZyA9IE5VTEw7CisgICAgfQorICAg IGlmIChjaC0+ZG1hLmRtYXRhZykgeworCWJ1c19kbWFfdGFnX2Rlc3Ryb3koY2gtPmRtYS5kbWF0 YWcpOworCWNoLT5kbWEuZG1hdGFnID0gTlVMTDsKICAgICB9CiB9CiAKIHN0YXRpYyB2b2lkCiBh dGFfZG1hc2V0dXBjX2NiKHZvaWQgKnhzYywgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCBu c2VncywgaW50IGVycm9yKQogewotICAgIHN0cnVjdCBhdGFfZGNfY2JfYXJncyAqY2JhID0gKHN0 cnVjdCBhdGFfZGNfY2JfYXJncyAqKXhzYzsKKyAgICBzdHJ1Y3QgYXRhX2RjX2NiX2FyZ3MgKmRj YmEgPSAoc3RydWN0IGF0YV9kY19jYl9hcmdzICopeHNjOwogCi0gICAgaWYgKCEoY2JhLT5lcnJv ciA9IGVycm9yKSkKLQljYmEtPm1hZGRyID0gc2Vnc1swXS5kc19hZGRyOworICAgIGlmICghKGRj YmEtPmVycm9yID0gZXJyb3IpKQorCWRjYmEtPm1hZGRyID0gc2Vnc1swXS5kc19hZGRyOwogfQog CiBzdGF0aWMgdm9pZAogYXRhX2RtYWFsbG9jKGRldmljZV90IGRldikKIHsKICAgICBzdHJ1Y3Qg YXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwotICAgIHN0cnVjdCBhdGFf ZGNfY2JfYXJncyBjY2JhOwotCi0gICAgaWYgKGJ1c19kbWFfdGFnX2NyZWF0ZShidXNfZ2V0X2Rt YV90YWcoZGV2KSwgY2gtPmRtYS0+YWxpZ25tZW50LCAwLAotCQkJICAgY2gtPmRtYS0+bWF4X2Fk ZHJlc3MsIEJVU19TUEFDRV9NQVhBRERSLAotCQkJICAgTlVMTCwgTlVMTCwgY2gtPmRtYS0+bWF4 X2lvc2l6ZSwKLQkJCSAgIEFUQV9ETUFfRU5UUklFUywgY2gtPmRtYS0+c2Vnc2l6ZSwKLQkJCSAg IDAsIE5VTEwsIE5VTEwsICZjaC0+ZG1hLT5kbWF0YWcpKQotCWdvdG8gZXJyb3I7Ci0KLSAgICBp ZiAoYnVzX2RtYV90YWdfY3JlYXRlKGNoLT5kbWEtPmRtYXRhZywgUEFHRV9TSVpFLCBQQUdFX1NJ WkUsCi0JCQkgICBjaC0+ZG1hLT5tYXhfYWRkcmVzcywgQlVTX1NQQUNFX01BWEFERFIsCi0JCQkg ICBOVUxMLCBOVUxMLCBNQVhUQUJTWiwgMSwgTUFYVEFCU1osCi0JCQkgICAwLCBOVUxMLCBOVUxM LCAmY2gtPmRtYS0+c2dfdGFnKSkKLQlnb3RvIGVycm9yOwotCi0gICAgaWYgKGJ1c19kbWFfdGFn X2NyZWF0ZShjaC0+ZG1hLT5kbWF0YWcsY2gtPmRtYS0+YWxpZ25tZW50LGNoLT5kbWEtPmJvdW5k YXJ5LAotCQkJICAgY2gtPmRtYS0+bWF4X2FkZHJlc3MsIEJVU19TUEFDRV9NQVhBRERSLAotCQkJ ICAgTlVMTCwgTlVMTCwgY2gtPmRtYS0+bWF4X2lvc2l6ZSwKLQkJCSAgIEFUQV9ETUFfRU5UUklF UywgY2gtPmRtYS0+c2Vnc2l6ZSwKLQkJCSAgIDAsIE5VTEwsIE5VTEwsICZjaC0+ZG1hLT5kYXRh X3RhZykpCi0JZ290byBlcnJvcjsKLQotICAgIGlmIChidXNfZG1hbWVtX2FsbG9jKGNoLT5kbWEt PnNnX3RhZywgKHZvaWQgKiopJmNoLT5kbWEtPnNnLCAwLAotCQkJICZjaC0+ZG1hLT5zZ19tYXAp KQotCWdvdG8gZXJyb3I7Ci0KLSAgICBpZiAoYnVzX2RtYW1hcF9sb2FkKGNoLT5kbWEtPnNnX3Rh ZywgY2gtPmRtYS0+c2dfbWFwLCBjaC0+ZG1hLT5zZywKLQkJCU1BWFRBQlNaLCBhdGFfZG1hc2V0 dXBjX2NiLCAmY2NiYSwgMCkgfHwgY2NiYS5lcnJvcikgewotCWJ1c19kbWFtZW1fZnJlZShjaC0+ ZG1hLT5zZ190YWcsIGNoLT5kbWEtPnNnLCBjaC0+ZG1hLT5zZ19tYXApOwotCWdvdG8gZXJyb3I7 Ci0gICAgfQotICAgIGNoLT5kbWEtPnNnX2J1cyA9IGNjYmEubWFkZHI7Ci0KLSAgICBpZiAoYnVz X2RtYW1hcF9jcmVhdGUoY2gtPmRtYS0+ZGF0YV90YWcsIDAsICZjaC0+ZG1hLT5kYXRhX21hcCkp Ci0JZ290byBlcnJvcjsKLQotICAgIGlmIChidXNfZG1hX3RhZ19jcmVhdGUoY2gtPmRtYS0+ZG1h dGFnLCBQQUdFX1NJWkUsIDY0ICogMTAyNCwKLQkJCSAgIGNoLT5kbWEtPm1heF9hZGRyZXNzLCBC VVNfU1BBQ0VfTUFYQUREUiwKLQkJCSAgIE5VTEwsIE5VTEwsIE1BWFdTUENTWiwgMSwgTUFYV1NQ Q1NaLAotCQkJICAgMCwgTlVMTCwgTlVMTCwgJmNoLT5kbWEtPndvcmtfdGFnKSkKLQlnb3RvIGVy cm9yOwotCi0gICAgaWYgKGJ1c19kbWFtZW1fYWxsb2MoY2gtPmRtYS0+d29ya190YWcsICh2b2lk ICoqKSZjaC0+ZG1hLT53b3JrLCAwLAotCQkJICZjaC0+ZG1hLT53b3JrX21hcCkpCi0JZ290byBl cnJvcjsKKyAgICBzdHJ1Y3QgYXRhX2RjX2NiX2FyZ3MgZGNiYTsKKyAgICBpbnQgaTsKIAotICAg IGlmIChidXNfZG1hbWFwX2xvYWQoY2gtPmRtYS0+d29ya190YWcsIGNoLT5kbWEtPndvcmtfbWFw LGNoLT5kbWEtPndvcmssCi0JCQlNQVhXU1BDU1osIGF0YV9kbWFzZXR1cGNfY2IsICZjY2JhLCAw KSB8fCBjY2JhLmVycm9yKSB7Ci0JYnVzX2RtYW1lbV9mcmVlKGNoLT5kbWEtPndvcmtfdGFnLGNo LT5kbWEtPndvcmssIGNoLT5kbWEtPndvcmtfbWFwKTsKLQlnb3RvIGVycm9yOworICAgIC8qIGFs bG9jIGFuZCBzZXR1cCBuZWVkZWQgZG1hIHNsb3RzICovCisgICAgYnplcm8oY2gtPmRtYS5zbG90 LCBzaXplb2Yoc3RydWN0IGF0YV9kbWFzbG90KSAqIEFUQV9ETUFfU0xPVFMpOworICAgIGZvciAo aSA9IDA7IGkgPCBjaC0+ZG1hLmRtYV9zbG90czsgaSsrKSB7CisJc3RydWN0IGF0YV9kbWFzbG90 ICpzbG90ID0gJmNoLT5kbWEuc2xvdFtpXTsKKworCWlmIChidXNfZG1hX3RhZ19jcmVhdGUoY2gt PmRtYS5kbWF0YWcsIFBBR0VfU0laRSwgUEFHRV9TSVpFLAorCQkJICAgICAgIGNoLT5kbWEubWF4 X2FkZHJlc3MsIEJVU19TUEFDRV9NQVhBRERSLAorCQkJICAgICAgIE5VTEwsIE5VTEwsIFBBR0Vf U0laRSwgMSwgUEFHRV9TSVpFLAorCQkJICAgICAgIDAsIE5VTEwsIE5VTEwsICZzbG90LT5zZ190 YWcpKSB7CisgICAgICAgICAgICBkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJGQUlMVVJFIC0gY3Jl YXRlIHNnX3RhZ1xuIik7CisgICAgICAgICAgICBnb3RvIGVycm9yOworCX0KKworCWlmIChidXNf ZG1hbWVtX2FsbG9jKHNsb3QtPnNnX3RhZywgKHZvaWQgKiopJnNsb3QtPnNnLAorCQkJICAgICAw LCAmc2xvdC0+c2dfbWFwKSkgeworCSAgICBkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJGQUlMVVJF IC0gYWxsb2Mgc2dfbWFwXG4iKTsKKwkgICAgZ290byBlcnJvcjsKKyAgICAgICAgfQorCisJaWYg KGJ1c19kbWFtYXBfbG9hZChzbG90LT5zZ190YWcsIHNsb3QtPnNnX21hcCwgc2xvdC0+c2csIE1B WFRBQlNaLAorCQkJICAgIGF0YV9kbWFzZXR1cGNfY2IsICZkY2JhLCAwKSB8fCBkY2JhLmVycm9y KSB7CisJICAgIGRldmljZV9wcmludGYoY2gtPmRldiwgIkZBSUxVUkUgLSBsb2FkIHNnXG4iKTsK KwkgICAgZ290byBlcnJvcjsKKwl9CisJc2xvdC0+c2dfYnVzID0gZGNiYS5tYWRkcjsKKworCWlm IChidXNfZG1hX3RhZ19jcmVhdGUoY2gtPmRtYS5kbWF0YWcsCisJCQkgICAgICAgY2gtPmRtYS5h bGlnbm1lbnQsIGNoLT5kbWEuYm91bmRhcnksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY2gtPmRtYS5tYXhfYWRkcmVzcywgQlVTX1NQQUNFX01BWEFERFIsCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTlVMTCwgTlVMTCwgY2gtPmRtYS5tYXhfaW9zaXplLAorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFUQV9ETUFfRU5UUklFUywgY2gtPmRtYS5zZWdzaXpl LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJVU19ETUFfQUxMT0NOT1csIE5VTEws IE5VTEwsICZzbG90LT5kYXRhX3RhZykpIHsKKwkgICAgZGV2aWNlX3ByaW50ZihjaC0+ZGV2LCAi RkFJTFVSRSAtIGNyZWF0ZSBkYXRhX3RhZ1xuIik7CisJICAgIGdvdG8gZXJyb3I7CisJfQorCisJ aWYgKGJ1c19kbWFtYXBfY3JlYXRlKHNsb3QtPmRhdGFfdGFnLCAwLCAmc2xvdC0+ZGF0YV9tYXAp KSB7CisJICAgIGRldmljZV9wcmludGYoY2gtPmRldiwgIkZBSUxVUkUgLSBjcmVhdGUgZGF0YV9t YXBcbiIpOworCSAgICBnb3RvIGVycm9yOworICAgICAgICB9CiAgICAgfQotICAgIGNoLT5kbWEt PndvcmtfYnVzID0gY2NiYS5tYWRkcjsKIAogICAgIHJldHVybjsKIAogZXJyb3I6CiAgICAgZGV2 aWNlX3ByaW50ZihkZXYsICJXQVJOSU5HIC0gRE1BIGFsbG9jYXRpb24gZmFpbGVkLCBkaXNhYmxp bmcgRE1BXG4iKTsKICAgICBhdGFfZG1hZnJlZShkZXYpOwotICAgIGZyZWUoY2gtPmRtYSwgTV9B VEFETUEpOwotICAgIGNoLT5kbWEgPSBOVUxMOwogfQogCiBzdGF0aWMgdm9pZAogYXRhX2RtYWZy ZWUoZGV2aWNlX3QgZGV2KQogewogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldik7CisgICAgaW50IGk7CiAKLSAgICBpZiAoY2gtPmRtYS0+d29ya19idXMp IHsKLQlidXNfZG1hbWFwX3VubG9hZChjaC0+ZG1hLT53b3JrX3RhZywgY2gtPmRtYS0+d29ya19t YXApOwotCWJ1c19kbWFtZW1fZnJlZShjaC0+ZG1hLT53b3JrX3RhZywgY2gtPmRtYS0+d29yaywg Y2gtPmRtYS0+d29ya19tYXApOwotCWNoLT5kbWEtPndvcmtfYnVzID0gMDsKLQljaC0+ZG1hLT53 b3JrX21hcCA9IE5VTEw7Ci0JY2gtPmRtYS0+d29yayA9IE5VTEw7Ci0gICAgfQotICAgIGlmIChj aC0+ZG1hLT53b3JrX3RhZykgewotCWJ1c19kbWFfdGFnX2Rlc3Ryb3koY2gtPmRtYS0+d29ya190 YWcpOwotCWNoLT5kbWEtPndvcmtfdGFnID0gTlVMTDsKLSAgICB9Ci0gICAgaWYgKGNoLT5kbWEt PnNnX2J1cykgewotCWJ1c19kbWFtYXBfdW5sb2FkKGNoLT5kbWEtPnNnX3RhZywgY2gtPmRtYS0+ c2dfbWFwKTsKLQlidXNfZG1hbWVtX2ZyZWUoY2gtPmRtYS0+c2dfdGFnLCBjaC0+ZG1hLT5zZywg Y2gtPmRtYS0+c2dfbWFwKTsKLQljaC0+ZG1hLT5zZ19idXMgPSAwOwotCWNoLT5kbWEtPnNnX21h cCA9IE5VTEw7Ci0JY2gtPmRtYS0+c2cgPSBOVUxMOwotICAgIH0KLSAgICBpZiAoY2gtPmRtYS0+ ZGF0YV9tYXApIHsKLQlidXNfZG1hbWFwX2Rlc3Ryb3koY2gtPmRtYS0+ZGF0YV90YWcsIGNoLT5k bWEtPmRhdGFfbWFwKTsKLQljaC0+ZG1hLT5kYXRhX21hcCA9IE5VTEw7Ci0gICAgfQotICAgIGlm IChjaC0+ZG1hLT5zZ190YWcpIHsKLQlidXNfZG1hX3RhZ19kZXN0cm95KGNoLT5kbWEtPnNnX3Rh Zyk7Ci0JY2gtPmRtYS0+c2dfdGFnID0gTlVMTDsKLSAgICB9Ci0gICAgaWYgKGNoLT5kbWEtPmRh dGFfdGFnKSB7Ci0JYnVzX2RtYV90YWdfZGVzdHJveShjaC0+ZG1hLT5kYXRhX3RhZyk7Ci0JY2gt PmRtYS0+ZGF0YV90YWcgPSBOVUxMOwotICAgIH0KLSAgICBpZiAoY2gtPmRtYS0+ZG1hdGFnKSB7 Ci0JYnVzX2RtYV90YWdfZGVzdHJveShjaC0+ZG1hLT5kbWF0YWcpOwotCWNoLT5kbWEtPmRtYXRh ZyA9IE5VTEw7CisgICAgLyogZnJlZSBhbGwgZG1hIHNsb3RzICovCisgICAgZm9yIChpID0gMDsg aSA8IEFUQV9ETUFfU0xPVFM7IGkrKykgeworCXN0cnVjdCBhdGFfZG1hc2xvdCAqc2xvdCA9ICZj aC0+ZG1hLnNsb3RbaV07CisKKwlpZiAoc2xvdC0+c2dfYnVzKSB7CisgICAgICAgICAgICBidXNf ZG1hbWFwX3VubG9hZChzbG90LT5zZ190YWcsIHNsb3QtPnNnX21hcCk7CisgICAgICAgICAgICBz bG90LT5zZ19idXMgPSAwOworCX0KKwlpZiAoc2xvdC0+c2dfbWFwKSB7CisgICAgICAgICAgICBi dXNfZG1hbWVtX2ZyZWUoc2xvdC0+c2dfdGFnLCBzbG90LT5zZywgc2xvdC0+c2dfbWFwKTsKKyAg ICAgICAgICAgIGJ1c19kbWFtYXBfZGVzdHJveShzbG90LT5zZ190YWcsIHNsb3QtPnNnX21hcCk7 CisgICAgICAgICAgICBzbG90LT5zZyA9IE5VTEw7CisgICAgICAgICAgICBzbG90LT5zZ19tYXAg PSBOVUxMOworCX0KKwlpZiAoc2xvdC0+ZGF0YV9tYXApIHsKKyAgICAgICAgICAgIGJ1c19kbWFt YXBfZGVzdHJveShzbG90LT5kYXRhX3RhZywgc2xvdC0+ZGF0YV9tYXApOworICAgICAgICAgICAg c2xvdC0+ZGF0YV9tYXAgPSBOVUxMOworCX0KKwlpZiAoc2xvdC0+c2dfdGFnKSB7CisgICAgICAg ICAgICBidXNfZG1hX3RhZ19kZXN0cm95KHNsb3QtPnNnX3RhZyk7CisgICAgICAgICAgICBzbG90 LT5zZ190YWcgPSBOVUxMOworCX0KKwlpZiAoc2xvdC0+ZGF0YV90YWcpIHsKKyAgICAgICAgICAg IGJ1c19kbWFfdGFnX2Rlc3Ryb3koc2xvdC0+ZGF0YV90YWcpOworICAgICAgICAgICAgc2xvdC0+ ZGF0YV90YWcgPSBOVUxMOworCX0KICAgICB9CiB9CiAKQEAgLTIxOCw2NyArMjU2LDgzIEBAIGF0 YV9kbWFzZXRwcmQodm9pZCAqeHNjLCBidXNfZG1hX3NlZ21lbnQKIH0KIAogc3RhdGljIGludAot YXRhX2RtYWxvYWQoZGV2aWNlX3QgZGV2LCBjYWRkcl90IGRhdGEsIGludDMyX3QgY291bnQsIGlu dCBkaXIsCi0JICAgIHZvaWQgKmFkZHIsIGludCAqZW50cmllcykKK2F0YV9kbWFsb2FkKHN0cnVj dCBhdGFfcmVxdWVzdCAqcmVxdWVzdCwgdm9pZCAqYWRkciwgaW50ICplbnRyaWVzKQogewotICAg IHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0gICAgc3Ry dWN0IGF0YV9kbWFzZXRwcmRfYXJncyBjYmE7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9 IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50KTsKKyAgICBzdHJ1Y3QgYXRhX2Rldmlj ZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1ZXN0LT5kZXYpOworICAgIHN0cnVjdCBh dGFfZG1hc2V0cHJkX2FyZ3MgZHNwYTsKICAgICBpbnQgZXJyb3I7CiAKLSAgICBpZiAoY2gtPmRt YS0+ZmxhZ3MgJiBBVEFfRE1BX0xPQURFRCkgewotCWRldmljZV9wcmludGYoZGV2LCAiRkFJTFVS RSAtIGFscmVhZHkgYWN0aXZlIERNQSBvbiB0aGlzIGRldmljZVxuIik7CisgICAgQVRBX0RFQlVH X1JRKHJlcXVlc3QsICJkbWFsb2FkIik7CisKKyAgICBpZiAocmVxdWVzdC0+ZG1hKSB7CisJZGV2 aWNlX3ByaW50ZihyZXF1ZXN0LT5kZXYsCisJCSAgICAgICJGQUlMVVJFIC0gYWxyZWFkeSBhY3Rp dmUgRE1BIG9uIHRoaXMgZGV2aWNlXG4iKTsKIAlyZXR1cm4gRUlPOwogICAgIH0KLSAgICBpZiAo IWNvdW50KSB7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJGQUlMVVJFIC0gemVybyBsZW5ndGggRE1B IHRyYW5zZmVyIGF0dGVtcHRlZFxuIik7CisgICAgaWYgKCFyZXF1ZXN0LT5ieXRlY291bnQpIHsK KwlkZXZpY2VfcHJpbnRmKHJlcXVlc3QtPmRldiwKKwkJICAgICAgIkZBSUxVUkUgLSB6ZXJvIGxl bmd0aCBETUEgdHJhbnNmZXIgYXR0ZW1wdGVkXG4iKTsKIAlyZXR1cm4gRUlPOwogICAgIH0KLSAg ICBpZiAoKCh1aW50cHRyX3QpZGF0YSAmIChjaC0+ZG1hLT5hbGlnbm1lbnQgLSAxKSkgfHwKLQko Y291bnQgJiAoY2gtPmRtYS0+YWxpZ25tZW50IC0gMSkpKSB7Ci0JZGV2aWNlX3ByaW50ZihkZXYs ICJGQUlMVVJFIC0gbm9uIGFsaWduZWQgRE1BIHRyYW5zZmVyIGF0dGVtcHRlZFxuIik7CisgICAg aWYgKCgodWludHB0cl90KShyZXF1ZXN0LT5kYXRhKSAmIChjaC0+ZG1hLmFsaWdubWVudCAtIDEp KSB8fAorCShyZXF1ZXN0LT5ieXRlY291bnQgJiAoY2gtPmRtYS5hbGlnbm1lbnQgLSAxKSkpIHsK KwlkZXZpY2VfcHJpbnRmKHJlcXVlc3QtPmRldiwKKwkJICAgICAgIkZBSUxVUkUgLSBub24gYWxp Z25lZCBETUEgdHJhbnNmZXIgYXR0ZW1wdGVkXG4iKTsKIAlyZXR1cm4gRUlPOwogICAgIH0KLSAg ICBpZiAoY291bnQgPiBjaC0+ZG1hLT5tYXhfaW9zaXplKSB7Ci0JZGV2aWNlX3ByaW50ZihkZXYs ICJGQUlMVVJFIC0gb3ZlcnNpemVkIERNQSB0cmFuc2ZlciBhdHRlbXB0ICVkID4gJWRcbiIsCi0J CSAgICAgIGNvdW50LCBjaC0+ZG1hLT5tYXhfaW9zaXplKTsKKyAgICBpZiAocmVxdWVzdC0+Ynl0 ZWNvdW50ID4gY2gtPmRtYS5tYXhfaW9zaXplKSB7CisJZGV2aWNlX3ByaW50ZihyZXF1ZXN0LT5k ZXYsCisJCSAgICAgICJGQUlMVVJFIC0gb3ZlcnNpemVkIERNQSB0cmFuc2ZlciBhdHRlbXB0ICVk ID4gJWRcbiIsCisJCSAgICAgIHJlcXVlc3QtPmJ5dGVjb3VudCwgY2gtPmRtYS5tYXhfaW9zaXpl KTsKIAlyZXR1cm4gRUlPOwogICAgIH0KIAotICAgIGNiYS5kbWF0YWIgPSBhZGRyOwotCi0gICAg aWYgKChlcnJvciA9IGJ1c19kbWFtYXBfbG9hZChjaC0+ZG1hLT5kYXRhX3RhZywgY2gtPmRtYS0+ ZGF0YV9tYXAsCi0JCQkJIGRhdGEsIGNvdW50LCBjaC0+ZG1hLT5zZXRwcmQsICZjYmEsCi0JCQkJ IEJVU19ETUFfTk9XQUlUKSkgfHwgKGVycm9yID0gY2JhLmVycm9yKSkKLQlyZXR1cm4gZXJyb3I7 Ci0KLSAgICAqZW50cmllcyA9IGNiYS5uc2VnczsKKyAgICAvKiBzZXQgb3VyIHNsb3QsIHVuaXQg Zm9yIHNpbXBsaWNpdHkgWFhYIFNPUyBOQ1Egd2lsbCBjaGFuZ2UgdGhhdCAqLworICAgIHJlcXVl c3QtPmRtYSA9ICZjaC0+ZG1hLnNsb3RbYXRhZGV2LT51bml0XTsKIAotICAgIGJ1c19kbWFtYXBf c3luYyhjaC0+ZG1hLT5zZ190YWcsIGNoLT5kbWEtPnNnX21hcCwgQlVTX0RNQVNZTkNfUFJFV1JJ VEUpOworICAgIGlmIChhZGRyKQorCWRzcGEuZG1hdGFiID0gYWRkcjsKKyAgICBlbHNlCisJZHNw YS5kbWF0YWIgPSByZXF1ZXN0LT5kbWEtPnNnOworCisgICAgaWYgKChlcnJvciA9IGJ1c19kbWFt YXBfbG9hZChyZXF1ZXN0LT5kbWEtPmRhdGFfdGFnLCByZXF1ZXN0LT5kbWEtPmRhdGFfbWFwLAor CQkJCSByZXF1ZXN0LT5kYXRhLCByZXF1ZXN0LT5ieXRlY291bnQsCisJCQkJIGNoLT5kbWEuc2V0 cHJkLCAmZHNwYSwgQlVTX0RNQV9OT1dBSVQpKSB8fAorCQkJCSAoZXJyb3IgPSBkc3BhLmVycm9y KSkgeworCWRldmljZV9wcmludGYocmVxdWVzdC0+ZGV2LCAiRkFJTFVSRSAtIGxvYWQgZGF0YVxu Iik7CisJZ290byBlcnJvcjsKKyAgICB9CiAKLSAgICBidXNfZG1hbWFwX3N5bmMoY2gtPmRtYS0+ ZGF0YV90YWcsIGNoLT5kbWEtPmRhdGFfbWFwLAotCQkgICAgZGlyID8gQlVTX0RNQVNZTkNfUFJF UkVBRCA6IEJVU19ETUFTWU5DX1BSRVdSSVRFKTsKKyAgICBpZiAoZW50cmllcykKKwkqZW50cmll cyA9IGRzcGEubnNlZ3M7CiAKLSAgICBjaC0+ZG1hLT5jdXJfaW9zaXplID0gY291bnQ7Ci0gICAg Y2gtPmRtYS0+ZmxhZ3MgPSBkaXIgPyAoQVRBX0RNQV9MT0FERUQgfCBBVEFfRE1BX1JFQUQpIDog QVRBX0RNQV9MT0FERUQ7CisgICAgYnVzX2RtYW1hcF9zeW5jKHJlcXVlc3QtPmRtYS0+c2dfdGFn LCByZXF1ZXN0LT5kbWEtPnNnX21hcCwKKwkJICAgIEJVU19ETUFTWU5DX1BSRVdSSVRFKTsKKyAg ICBidXNfZG1hbWFwX3N5bmMocmVxdWVzdC0+ZG1hLT5kYXRhX3RhZywgcmVxdWVzdC0+ZG1hLT5k YXRhX21hcCwKKwkJICAgIChyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQpID8KKwkJICAgIEJV U19ETUFTWU5DX1BSRVJFQUQgOiBCVVNfRE1BU1lOQ19QUkVXUklURSk7CiAgICAgcmV0dXJuIDA7 CisKK2Vycm9yOgorICAgIGF0YV9kbWF1bmxvYWQocmVxdWVzdCk7CisgICAgcmV0dXJuIEVJTzsK IH0KIAogaW50Ci1hdGFfZG1hdW5sb2FkKGRldmljZV90IGRldikKK2F0YV9kbWF1bmxvYWQoc3Ry dWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0KQogewotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2gg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisgICAgQVRBX0RFQlVHX1JRKHJlcXVlc3QsICJkbWF1 bmxvYWQiKTsKIAotICAgIGlmIChjaC0+ZG1hLT5mbGFncyAmIEFUQV9ETUFfTE9BREVEKSB7Ci0J YnVzX2RtYW1hcF9zeW5jKGNoLT5kbWEtPnNnX3RhZywgY2gtPmRtYS0+c2dfbWFwLAorICAgIGlm IChyZXF1ZXN0LT5kbWEpIHsKKwlidXNfZG1hbWFwX3N5bmMocmVxdWVzdC0+ZG1hLT5zZ190YWcs IHJlcXVlc3QtPmRtYS0+c2dfbWFwLAogCQkJQlVTX0RNQVNZTkNfUE9TVFdSSVRFKTsKLQotCWJ1 c19kbWFtYXBfc3luYyhjaC0+ZG1hLT5kYXRhX3RhZywgY2gtPmRtYS0+ZGF0YV9tYXAsCi0JCQko Y2gtPmRtYS0+ZmxhZ3MgJiBBVEFfRE1BX1JFQUQpID8KKwlidXNfZG1hbWFwX3N5bmMocmVxdWVz dC0+ZG1hLT5kYXRhX3RhZywgcmVxdWVzdC0+ZG1hLT5kYXRhX21hcCwKKwkJCShyZXF1ZXN0LT5m bGFncyAmIEFUQV9SX1JFQUQpID8KIAkJCUJVU19ETUFTWU5DX1BPU1RSRUFEIDogQlVTX0RNQVNZ TkNfUE9TVFdSSVRFKTsKLQlidXNfZG1hbWFwX3VubG9hZChjaC0+ZG1hLT5kYXRhX3RhZywgY2gt PmRtYS0+ZGF0YV9tYXApOwogCi0JY2gtPmRtYS0+Y3VyX2lvc2l6ZSA9IDA7Ci0JY2gtPmRtYS0+ ZmxhZ3MgJj0gfkFUQV9ETUFfTE9BREVEOworCWJ1c19kbWFtYXBfdW5sb2FkKHJlcXVlc3QtPmRt YS0+ZGF0YV90YWcsIHJlcXVlc3QtPmRtYS0+ZGF0YV9tYXApOworICAgICAgICByZXF1ZXN0LT5k bWEgPSBOVUxMOwogICAgIH0KICAgICByZXR1cm4gMDsKIH0KLS0tIHNyYy9zeXMvZGV2L2F0YS9h dGEtaXNhLmMJMjAwNy0wMi0yMSAyMjowNzoxOC4wMDAwMDAwMDAgKzAzMDAKKysrIHNyYy9zeXMv ZGV2L2F0YS9hdGEtaXNhLmMJMjAwOC0wNC0xMCAxNzowNTowNS4wMDAwMDAwMDAgKzA0MDAKQEAg LTEsNSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDcgU/hyZW4gU2No bWlkdCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwOCBT+HJl biBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoK ICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdp dGggb3Igd2l0aG91dAotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1sb3dsZXZlbC5jCTIwMDgtMDEt MDkgMTE6NTQ6NDguMDAwMDAwMDAwICswMzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhLWxvd2xl dmVsLmMJMjAwOC0wNS0wOCAyMTo1NTo0NC4wMDAwMDAwMDAgKzA0MDAKQEAgLTEsNSArMSw1IEBA CiAvKi0KLSAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDcgU/hyZW4gU2NobWlkdCA8c29zQEZy ZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwOCBT+HJlbiBTY2htaWR0IDxz b3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKICAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dApAQCAtNjQsMTYgKzY0LDE5IEBAIGF0YV9nZW5lcmljX2h3KGRldmljZV90IGRldikKICAgICBj aC0+aHcuYmVnaW5fdHJhbnNhY3Rpb24gPSBhdGFfYmVnaW5fdHJhbnNhY3Rpb247CiAgICAgY2gt Pmh3LmVuZF90cmFuc2FjdGlvbiA9IGF0YV9lbmRfdHJhbnNhY3Rpb247CiAgICAgY2gtPmh3LnN0 YXR1cyA9IGF0YV9nZW5lcmljX3N0YXR1czsKKyAgICBjaC0+aHcuc29mdHJlc2V0ID0gTlVMTDsK ICAgICBjaC0+aHcuY29tbWFuZCA9IGF0YV9nZW5lcmljX2NvbW1hbmQ7CiAgICAgY2gtPmh3LnRm X3JlYWQgPSBhdGFfdGZfcmVhZDsKICAgICBjaC0+aHcudGZfd3JpdGUgPSBhdGFfdGZfd3JpdGU7 CisgICAgY2gtPmh3LnBtX3JlYWQgPSBOVUxMOworICAgIGNoLT5ody5wbV93cml0ZSA9IE5VTEw7 CiB9CiAKIC8qIG11c3QgYmUgY2FsbGVkIHdpdGggQVRBIGNoYW5uZWwgbG9ja2VkIGFuZCBzdGF0 ZV9tdHggaGVsZCAqLwogaW50CiBhdGFfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZXF1 ZXN0ICpyZXF1ZXN0KQogewotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0 X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJlcXVlc3QtPmRldikpOworICAgIHN0cnVjdCBhdGFf Y2hhbm5lbCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7CiAgICAgc3Ry dWN0IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+ZGV2KTsK ICAgICBpbnQgZHVtbXksIGVycm9yOwogCkBAIC0xMzMsOSArMTM2LDcgQEAgYXRhX2JlZ2luX3Ry YW5zYWN0aW9uKHN0cnVjdCBhdGFfcmVxdWVzdAogICAgIC8qIEFUQSBETUEgZGF0YSB0cmFuc2Zl ciBjb21tYW5kcyAqLwogICAgIGNhc2UgQVRBX1JfRE1BOgogCS8qIGNoZWNrIHNhbml0eSwgc2V0 dXAgU0cgbGlzdCBhbmQgRE1BIGVuZ2luZSAqLwotCWlmICgoZXJyb3IgPSBjaC0+ZG1hLT5sb2Fk KGNoLT5kZXYsIHJlcXVlc3QtPmRhdGEsIHJlcXVlc3QtPmJ5dGVjb3VudCwKLQkJCQkgICByZXF1 ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQsIGNoLT5kbWEtPnNnLCAKLQkJCQkgICAmZHVtbXkpKSkg eworCWlmICgoZXJyb3IgPSBjaC0+ZG1hLmxvYWQocmVxdWVzdCwgTlVMTCwgJmR1bW15KSkpIHsK IAkgICAgZGV2aWNlX3ByaW50ZihyZXF1ZXN0LT5kZXYsICJzZXR0aW5nIHVwIERNQSBmYWlsZWRc biIpOwogCSAgICByZXF1ZXN0LT5yZXN1bHQgPSBlcnJvcjsKIAkgICAgZ290byBiZWdpbl9maW5p c2hlZDsKQEAgLTE1MCw3ICsxNTEsNyBAQCBhdGFfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0 YV9yZXF1ZXN0CiAJfQogCiAJLyogc3RhcnQgRE1BIGVuZ2luZSAqLwotCWlmIChjaC0+ZG1hLT5z dGFydCAmJiBjaC0+ZG1hLT5zdGFydChyZXF1ZXN0LT5kZXYpKSB7CisJaWYgKGNoLT5kbWEuc3Rh cnQgJiYgY2gtPmRtYS5zdGFydChyZXF1ZXN0KSkgewogCSAgICBkZXZpY2VfcHJpbnRmKHJlcXVl c3QtPmRldiwgImVycm9yIHN0YXJ0aW5nIERNQVxuIik7CiAJICAgIHJlcXVlc3QtPnJlc3VsdCA9 IEVJTzsKIAkgICAgZ290byBiZWdpbl9maW5pc2hlZDsKQEAgLTE2MSw3ICsxNjIsNyBAQCBhdGFf YmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZXF1ZXN0CiAgICAgY2FzZSBBVEFfUl9BVEFQ SToKIAkvKiBpcyB0aGlzIGp1c3QgYSBQT0xMIERTQyBjb21tYW5kID8gKi8KIAlpZiAocmVxdWVz dC0+dS5hdGFwaS5jY2JbMF0gPT0gQVRBUElfUE9MTF9EU0MpIHsKLQkgICAgQVRBX0lEWF9PVVRC KGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IGF0YWRldi0+dW5pdCk7CisJICAgIEFUQV9JRFhf T1VUQihjaCwgQVRBX0RSSVZFLCBBVEFfRF9JQk0gfCBBVEFfREVWKGF0YWRldi0+dW5pdCkpOwog CSAgICBERUxBWSgxMCk7CiAJICAgIGlmICghKEFUQV9JRFhfSU5CKGNoLCBBVEFfQUxUU1RBVCkg JiBBVEFfU19EU0MpKQogCQlyZXF1ZXN0LT5yZXN1bHQgPSBFQlVTWTsKQEAgLTE4MCw3ICsxODEs NyBAQCBhdGFfYmVnaW5fdHJhbnNhY3Rpb24oc3RydWN0IGF0YV9yZXF1ZXN0CiAgICAgY2FzZSBB VEFfUl9BVEFQSXxBVEFfUl9ETUE6CiAJLyogaXMgdGhpcyBqdXN0IGEgUE9MTCBEU0MgY29tbWFu ZCA/ICovCiAJaWYgKHJlcXVlc3QtPnUuYXRhcGkuY2NiWzBdID09IEFUQVBJX1BPTExfRFNDKSB7 Ci0JICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLCBBVEFfRF9JQk0gfCBhdGFkZXYtPnVu aXQpOworCSAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9EUklWRSwgQVRBX0RfSUJNIHwgQVRBX0RF VihhdGFkZXYtPnVuaXQpKTsKIAkgICAgREVMQVkoMTApOwogCSAgICBpZiAoIShBVEFfSURYX0lO QihjaCwgQVRBX0FMVFNUQVQpICYgQVRBX1NfRFNDKSkKIAkJcmVxdWVzdC0+cmVzdWx0ID0gRUJV U1k7CkBAIC0xODgsOSArMTg5LDcgQEAgYXRhX2JlZ2luX3RyYW5zYWN0aW9uKHN0cnVjdCBhdGFf cmVxdWVzdAogCX0KIAogCS8qIGNoZWNrIHNhbml0eSwgc2V0dXAgU0cgbGlzdCBhbmQgRE1BIGVu Z2luZSAqLwotCWlmICgoZXJyb3IgPSBjaC0+ZG1hLT5sb2FkKGNoLT5kZXYsIHJlcXVlc3QtPmRh dGEsIHJlcXVlc3QtPmJ5dGVjb3VudCwKLQkJCQkgICByZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JF QUQsIGNoLT5kbWEtPnNnLAotCQkJCSAgICZkdW1teSkpKSB7CisJaWYgKChlcnJvciA9IGNoLT5k bWEubG9hZChyZXF1ZXN0LCBOVUxMLCAmZHVtbXkpKSkgewogCSAgICBkZXZpY2VfcHJpbnRmKHJl cXVlc3QtPmRldiwgInNldHRpbmcgdXAgRE1BIGZhaWxlZFxuIik7CiAJICAgIHJlcXVlc3QtPnJl c3VsdCA9IGVycm9yOwogCSAgICBnb3RvIGJlZ2luX2ZpbmlzaGVkOwpAQCAtMjA0LDcgKzIwMyw3 IEBAIGF0YV9iZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVlc3QKIAl9CiAKIAkvKiBz dGFydCBETUEgZW5naW5lICovCi0JaWYgKGNoLT5kbWEtPnN0YXJ0ICYmIGNoLT5kbWEtPnN0YXJ0 KHJlcXVlc3QtPmRldikpIHsKKwlpZiAoY2gtPmRtYS5zdGFydCAmJiBjaC0+ZG1hLnN0YXJ0KHJl cXVlc3QpKSB7CiAJICAgIHJlcXVlc3QtPnJlc3VsdCA9IEVJTzsKIAkgICAgZ290byBiZWdpbl9m aW5pc2hlZDsKIAl9CkBAIC0yMTQsOCArMjEzLDkgQEAgYXRhX2JlZ2luX3RyYW5zYWN0aW9uKHN0 cnVjdCBhdGFfcmVxdWVzdAogICAgIHByaW50ZigiYXRhX2JlZ2luX3RyYW5zYWN0aW9uIE9PUFMh ISFcbiIpOwogCiBiZWdpbl9maW5pc2hlZDoKLSAgICBpZiAoY2gtPmRtYSAmJiBjaC0+ZG1hLT5m bGFncyAmIEFUQV9ETUFfTE9BREVEKQotCWNoLT5kbWEtPnVubG9hZChjaC0+ZGV2KTsKKyAgICBp ZiAoY2gtPmRtYS51bmxvYWQpIHsKKyAgICAgICAgY2gtPmRtYS51bmxvYWQocmVxdWVzdCk7Cisg ICAgfQogICAgIHJldHVybiBBVEFfT1BfRklOSVNIRUQ7CiAKIGJlZ2luX2NvbnRpbnVlOgpAQCAt MjI4LDcgKzIyOCw3IEBAIGJlZ2luX2NvbnRpbnVlOgogaW50CiBhdGFfZW5kX3RyYW5zYWN0aW9u KHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCkKIHsKLSAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwg KmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChyZXF1ZXN0LT5kZXYpKTsK KyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1ZXN0LT5w YXJlbnQpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZpY2VfZ2V0X3NvZnRj KHJlcXVlc3QtPmRldik7CiAgICAgaW50IGxlbmd0aDsKIApAQCAtMzE0LDE5ICszMTQsMTkgQEAg YXRhX2VuZF90cmFuc2FjdGlvbihzdHJ1Y3QgYXRhX3JlcXVlc3QgKgogICAgIGNhc2UgQVRBX1Jf RE1BOgogCiAJLyogc3RvcCBETUEgZW5naW5lIGFuZCBnZXQgc3RhdHVzICovCi0JaWYgKGNoLT5k bWEtPnN0b3ApCi0JICAgIHJlcXVlc3QtPmRtYXN0YXQgPSBjaC0+ZG1hLT5zdG9wKHJlcXVlc3Qt PmRldik7CisJaWYgKGNoLT5kbWEuc3RvcCkKKwkgICAgcmVxdWVzdC0+ZG1hLT5zdGF0dXMgPSBj aC0+ZG1hLnN0b3AocmVxdWVzdCk7CiAKIAkvKiBkaWQgd2UgZ2V0IGVycm9yIG9yIGRhdGEgKi8K IAlpZiAocmVxdWVzdC0+c3RhdHVzICYgQVRBX1NfRVJST1IpCiAJICAgIHJlcXVlc3QtPmVycm9y ID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9FUlJPUik7Ci0JZWxzZSBpZiAocmVxdWVzdC0+ZG1hc3Rh dCAmIEFUQV9CTVNUQVRfRVJST1IpCisJZWxzZSBpZiAocmVxdWVzdC0+ZG1hLT5zdGF0dXMgJiBB VEFfQk1TVEFUX0VSUk9SKQogCSAgICByZXF1ZXN0LT5zdGF0dXMgfD0gQVRBX1NfRVJST1I7CiAJ ZWxzZSBpZiAoIShyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1RJTUVPVVQpKQogCSAgICByZXF1ZXN0 LT5kb25lY291bnQgPSByZXF1ZXN0LT5ieXRlY291bnQ7CiAKIAkvKiByZWxlYXNlIFNHIGxpc3Qg ZXRjICovCi0JY2gtPmRtYS0+dW5sb2FkKGNoLT5kZXYpOworCWNoLT5kbWEudW5sb2FkKHJlcXVl c3QpOwogCiAJLyogZG9uZSB3aXRoIEhXICovCiAJZ290byBlbmRfZmluaXNoZWQ7CkBAIC00MjYs MTkgKzQyNiwxOSBAQCBhdGFfZW5kX3RyYW5zYWN0aW9uKHN0cnVjdCBhdGFfcmVxdWVzdCAqCiAg ICAgY2FzZSBBVEFfUl9BVEFQSXxBVEFfUl9ETUE6CiAKIAkvKiBzdG9wIERNQSBlbmdpbmUgYW5k IGdldCBzdGF0dXMgKi8KLQlpZiAoY2gtPmRtYS0+c3RvcCkKLQkgICAgcmVxdWVzdC0+ZG1hc3Rh dCA9IGNoLT5kbWEtPnN0b3AocmVxdWVzdC0+ZGV2KTsKKwlpZiAoY2gtPmRtYS5zdG9wKQorCSAg ICByZXF1ZXN0LT5kbWEtPnN0YXR1cyA9IGNoLT5kbWEuc3RvcChyZXF1ZXN0KTsKIAogCS8qIGRp ZCB3ZSBnZXQgZXJyb3Igb3IgZGF0YSAqLwogCWlmIChyZXF1ZXN0LT5zdGF0dXMgJiAoQVRBX1Nf RVJST1IgfCBBVEFfU19EV0YpKQogCSAgICByZXF1ZXN0LT5lcnJvciA9IEFUQV9JRFhfSU5CKGNo LCBBVEFfRVJST1IpOwotCWVsc2UgaWYgKHJlcXVlc3QtPmRtYXN0YXQgJiBBVEFfQk1TVEFUX0VS Uk9SKQorCWVsc2UgaWYgKHJlcXVlc3QtPmRtYS0+c3RhdHVzICYgQVRBX0JNU1RBVF9FUlJPUikK IAkgICAgcmVxdWVzdC0+c3RhdHVzIHw9IEFUQV9TX0VSUk9SOwogCWVsc2UgaWYgKCEocmVxdWVz dC0+ZmxhZ3MgJiBBVEFfUl9USU1FT1VUKSkKIAkgICAgcmVxdWVzdC0+ZG9uZWNvdW50ID0gcmVx dWVzdC0+Ynl0ZWNvdW50OwogIAogCS8qIHJlbGVhc2UgU0cgbGlzdCBldGMgKi8KLQljaC0+ZG1h LT51bmxvYWQoY2gtPmRldik7CisJY2gtPmRtYS51bmxvYWQocmVxdWVzdCk7CiAKIAkvKiBkb25l IHdpdGggSFcgKi8KIAlnb3RvIGVuZF9maW5pc2hlZDsKQEAgLTQ2NSw3ICs0NjUsNyBAQCBhdGFf Z2VuZXJpY19yZXNldChkZXZpY2VfdCBkZXYpCiAgICAgaW50IG1hc2sgPSAwLCB0aW1lb3V0Owog CiAgICAgLyogZG8gd2UgaGF2ZSBhbnkgc2lnbnMgb2YgQVRBL0FUQVBJIEhXIGJlaW5nIHByZXNl bnQgPyAqLwotICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZFLCBBVEFfRF9JQk0gfCBBVEFf RF9MQkEgfCBBVEFfTUFTVEVSKTsKKyAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9EUklWRSwgQVRB X0RfSUJNIHwgQVRBX0RfTEJBIHwgQVRBX0RFVihBVEFfTUFTVEVSKSk7CiAgICAgREVMQVkoMTAp OwogICAgIG9zdGF0MCA9IEFUQV9JRFhfSU5CKGNoLCBBVEFfU1RBVFVTKTsKICAgICBpZiAoKG9z dGF0MCAmIDB4ZjgpICE9IDB4ZjggJiYgb3N0YXQwICE9IDB4YTUpIHsKQEAgLTQ3NSw3ICs0NzUs NyBAQCBhdGFfZ2VuZXJpY19yZXNldChkZXZpY2VfdCBkZXYpCiAKICAgICAvKiBpbiBzb21lIHNl dHVwcyB3ZSBkb250IHdhbnQgdG8gdGVzdCBmb3IgYSBzbGF2ZSAqLwogICAgIGlmICghKGNoLT5m bGFncyAmIEFUQV9OT19TTEFWRSkpIHsKLQlBVEFfSURYX09VVEIoY2gsIEFUQV9EUklWRSwgQVRB X0RfSUJNIHwgQVRBX0RfTEJBIHwgQVRBX1NMQVZFKTsKKwlBVEFfSURYX09VVEIoY2gsIEFUQV9E UklWRSwgQVRBX0RfSUJNIHwgQVRBX0RfTEJBIHwgQVRBX0RFVihBVEFfU0xBVkUpKTsKIAlERUxB WSgxMCk7ICAgICAgCiAJb3N0YXQxID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9TVEFUVVMpOwogCWlm ICgob3N0YXQxICYgMHhmOCkgIT0gMHhmOCAmJiBvc3RhdDEgIT0gMHhhNSkgewpAQCAtNDk1LDcg KzQ5NSw3IEBAIGF0YV9nZW5lcmljX3Jlc2V0KGRldmljZV90IGRldikKIAlyZXR1cm47CiAKICAg ICAvKiByZXNldCAoYm90aCkgZGV2aWNlcyBvbiB0aGlzIGNoYW5uZWwgKi8KLSAgICBBVEFfSURY X09VVEIoY2gsIEFUQV9EUklWRSwgQVRBX0RfSUJNIHwgQVRBX0RfTEJBIHwgQVRBX01BU1RFUik7 CisgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IEFUQV9EX0xCQSB8 IEFUQV9ERVYoQVRBX01BU1RFUikpOwogICAgIERFTEFZKDEwKTsKICAgICBBVEFfSURYX09VVEIo Y2gsIEFUQV9DT05UUk9MLCBBVEFfQV9JRFMgfCBBVEFfQV9SRVNFVCk7CiAgICAgYXRhX3VkZWxh eSgxMDAwMCk7IApAQCAtNTA2LDcgKzUwNiw3IEBAIGF0YV9nZW5lcmljX3Jlc2V0KGRldmljZV90 IGRldikKICAgICAvKiB3YWl0IGZvciBCVVNZIHRvIGdvIGluYWN0aXZlICovCiAgICAgZm9yICh0 aW1lb3V0ID0gMDsgdGltZW91dCA8IDMxMDsgdGltZW91dCsrKSB7CiAJaWYgKChtYXNrICYgMHgw MSkgJiYgKHN0YXQwICYgQVRBX1NfQlVTWSkpIHsKLQkgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFf RFJJVkUsIEFUQV9EX0lCTSB8IEFUQV9NQVNURVIpOworCSAgICBBVEFfSURYX09VVEIoY2gsIEFU QV9EUklWRSwgQVRBX0RfSUJNIHwgQVRBX0RFVihBVEFfTUFTVEVSKSk7CiAJICAgIERFTEFZKDEw KTsKIAkgICAgZXJyID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9FUlJPUik7CiAJICAgIGxzYiA9IEFU QV9JRFhfSU5CKGNoLCBBVEFfQ1lMX0xTQik7CkBAIC01MzYsNyArNTM2LDcgQEAgYXRhX2dlbmVy aWNfcmVzZXQoZGV2aWNlX3QgZGV2KQogCiAJaWYgKChtYXNrICYgMHgwMikgJiYgKHN0YXQxICYg QVRBX1NfQlVTWSkgJiYKIAkgICAgISgobWFzayAmIDB4MDEpICYmIChzdGF0MCAmIEFUQV9TX0JV U1kpKSkgewotCSAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9EUklWRSwgQVRBX0RfSUJNIHwgQVRB X1NMQVZFKTsKKwkgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IEFU QV9ERVYoQVRBX1NMQVZFKSk7CiAJICAgIERFTEFZKDEwKTsKIAkgICAgZXJyID0gQVRBX0lEWF9J TkIoY2gsIEFUQV9FUlJPUik7CiAJICAgIGxzYiA9IEFUQV9JRFhfSU5CKGNoLCBBVEFfQ1lMX0xT Qik7CkBAIC01ODQsOSArNTg0LDggQEAgYXRhX2dlbmVyaWNfcmVzZXQoZGV2aWNlX3QgZGV2KQog ICAgIH0KIAogICAgIGlmIChib290dmVyYm9zZSkKLQlkZXZpY2VfcHJpbnRmKGRldiwgInJlc2V0 IHRwMiBzdGF0MD0lMDJ4IHN0YXQxPSUwMnggZGV2aWNlcz0weCViXG4iLAotCQkgICAgICBzdGF0 MCwgc3RhdDEsIGNoLT5kZXZpY2VzLAotCQkgICAgICAiXDIwXDRBVEFQSV9TTEFWRVwzQVRBUElf TUFTVEVSXDJBVEFfU0xBVkVcMUFUQV9NQVNURVIiKTsKKwlkZXZpY2VfcHJpbnRmKGRldiwgInJl c2V0IHRwMiBzdGF0MD0lMDJ4IHN0YXQxPSUwMnggZGV2aWNlcz0weCV4XG4iLAorCQkgICAgICBz dGF0MCwgc3RhdDEsIGNoLT5kZXZpY2VzKTsKIH0KIAogLyogbXVzdCBiZSBjYWxsZWQgd2l0aCBB VEEgY2hhbm5lbCBsb2NrZWQgYW5kIHN0YXRlX210eCBoZWxkICovCkBAIC02MTcsNyArNjE2LDcg QEAgYXRhX3dhaXQoc3RydWN0IGF0YV9jaGFubmVsICpjaCwgc3RydWN0IAogCiAJLyogaWYgZHJp dmUgZmFpbHMgc3RhdHVzLCByZXNlbGVjdCB0aGUgZHJpdmUgYW5kIHRyeSBhZ2FpbiAqLwogCWlm IChzdGF0dXMgPT0gMHhmZikgewotCSAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9EUklWRSwgQVRB X0RfSUJNIHwgYXRhZGV2LT51bml0KTsKKwkgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUs IEFUQV9EX0lCTSB8IEFUQV9ERVYoYXRhZGV2LT51bml0KSk7CiAJICAgIHRpbWVvdXQgKz0gMTAw MDsKIAkgICAgREVMQVkoMTAwMCk7CiAJICAgIGNvbnRpbnVlOwpAQCAtNjU3LDExICs2NTYsMTEg QEAgYXRhX3dhaXQoc3RydWN0IGF0YV9jaGFubmVsICpjaCwgc3RydWN0IAogaW50CiBhdGFfZ2Vu ZXJpY19jb21tYW5kKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCkKIHsKLSAgICBzdHJ1Y3Qg YXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChyZXF1 ZXN0LT5kZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0 YyhyZXF1ZXN0LT5wYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZp Y2VfZ2V0X3NvZnRjKHJlcXVlc3QtPmRldik7CiAKICAgICAvKiBzZWxlY3QgZGV2aWNlICovCi0g ICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8IEFUQV9EX0xCQSB8IGF0 YWRldi0+dW5pdCk7CisgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJVkUsIEFUQV9EX0lCTSB8 IEFUQV9EX0xCQSB8IEFUQV9ERVYoYXRhZGV2LT51bml0KSk7CiAKICAgICAvKiByZWFkeSB0byBp c3N1ZSBjb21tYW5kID8gKi8KICAgICBpZiAoYXRhX3dhaXQoY2gsIGF0YWRldiwgMCkgPCAwKSB7 IApAQCAtNzI4LDcgKzcyNyw3IEBAIGF0YV9nZW5lcmljX2NvbW1hbmQoc3RydWN0IGF0YV9yZXF1 ZXN0ICoKIHN0YXRpYyB2b2lkCiBhdGFfdGZfcmVhZChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVl c3QpCiB7Ci0gICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2 aWNlX2dldF9wYXJlbnQocmVxdWVzdC0+ZGV2KSk7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50KTsKICAgICBzdHJ1Y3QgYXRhX2Rl dmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhyZXF1ZXN0LT5kZXYpOwogCiAgICAgaWYg KGF0YWRldi0+ZmxhZ3MgJiBBVEFfRF80OEJJVF9BQ1RJVkUpIHsKQEAgLTc1OCw3ICs3NTcsNyBA QCBhdGFfdGZfcmVhZChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiBzdGF0aWMgdm9pZAog YXRhX3RmX3dyaXRlKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCkKIHsKLSAgICBzdHJ1Y3Qg YXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChyZXF1 ZXN0LT5kZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0 YyhyZXF1ZXN0LT5wYXJlbnQpOwogICAgIHN0cnVjdCBhdGFfZGV2aWNlICphdGFkZXYgPSBkZXZp Y2VfZ2V0X3NvZnRjKHJlcXVlc3QtPmRldik7CiAKICAgICBpZiAoYXRhZGV2LT5mbGFncyAmIEFU QV9EXzQ4QklUX0FDVElWRSkgewpAQCAtNzcyLDcgKzc3MSw3IEBAIGF0YV90Zl93cml0ZShzdHJ1 Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QKIAlBVEFfSURYX09VVEIoY2gsIEFUQV9DWUxfTFNCLCBy ZXF1ZXN0LT51LmF0YS5sYmEgPj4gOCk7CiAJQVRBX0lEWF9PVVRCKGNoLCBBVEFfQ1lMX01TQiwg cmVxdWVzdC0+dS5hdGEubGJhID4+IDQwKTsKIAlBVEFfSURYX09VVEIoY2gsIEFUQV9DWUxfTVNC LCByZXF1ZXN0LT51LmF0YS5sYmEgPj4gMTYpOwotCUFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZF LCBBVEFfRF9MQkEgfCBhdGFkZXYtPnVuaXQpOworCUFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZF LCBBVEFfRF9MQkEgfCBBVEFfREVWKGF0YWRldi0+dW5pdCkpOwogICAgIH0KICAgICBlbHNlIHsK IAlBVEFfSURYX09VVEIoY2gsIEFUQV9GRUFUVVJFLCByZXF1ZXN0LT51LmF0YS5mZWF0dXJlKTsK QEAgLTc5NCw3ICs3OTMsNyBAQCBhdGFfdGZfd3JpdGUoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1 ZXN0CiAJCQkgKHJlcXVlc3QtPnUuYXRhLmxiYSAvIChzZWN0b3JzICogaGVhZHMpKSk7CiAJICAg IEFUQV9JRFhfT1VUQihjaCwgQVRBX0NZTF9NU0IsCiAJCQkgKHJlcXVlc3QtPnUuYXRhLmxiYSAv IChzZWN0b3JzICogaGVhZHMpKSA+PiA4KTsKLQkgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfRFJJ VkUsIEFUQV9EX0lCTSB8IGF0YWRldi0+dW5pdCB8IAorCSAgICBBVEFfSURYX09VVEIoY2gsIEFU QV9EUklWRSwgQVRBX0RfSUJNIHwgQVRBX0RFVihhdGFkZXYtPnVuaXQpIHwgCiAJCQkgKCgocmVx dWVzdC0+dS5hdGEubGJhJSAoc2VjdG9ycyAqIGhlYWRzKSkgLwogCQkJICAgc2VjdG9ycykgJiAw eGYpKTsKIAl9CkBAIC04MDMsNyArODAyLDcgQEAgYXRhX3RmX3dyaXRlKHN0cnVjdCBhdGFfcmVx dWVzdCAqcmVxdWVzdAogCSAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9DWUxfTFNCLCByZXF1ZXN0 LT51LmF0YS5sYmEgPj4gOCk7CiAJICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0NZTF9NU0IsIHJl cXVlc3QtPnUuYXRhLmxiYSA+PiAxNik7CiAJICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0RSSVZF LAotCQkJIEFUQV9EX0lCTSB8IEFUQV9EX0xCQSB8IGF0YWRldi0+dW5pdCB8CisJCQkgQVRBX0Rf SUJNIHwgQVRBX0RfTEJBIHwgQVRBX0RFVihhdGFkZXYtPnVuaXQpIHwKIAkJCSAoKHJlcXVlc3Qt PnUuYXRhLmxiYSA+PiAyNCkgJiAweDBmKSk7CiAJfQogICAgIH0KQEAgLTgxMiw3ICs4MTEsNyBA QCBhdGFfdGZfd3JpdGUoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0CiBzdGF0aWMgdm9pZAog YXRhX3Bpb19yZWFkKHN0cnVjdCBhdGFfcmVxdWVzdCAqcmVxdWVzdCwgaW50IGxlbmd0aCkKIHsK LSAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0 X3BhcmVudChyZXF1ZXN0LT5kZXYpKTsKKyAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2 aWNlX2dldF9zb2Z0YyhyZXF1ZXN0LT5wYXJlbnQpOwogICAgIGludCBzaXplID0gbWluKHJlcXVl c3QtPnRyYW5zZmVyc2l6ZSwgbGVuZ3RoKTsKICAgICBpbnQgcmVzaWQ7CiAKQEAgLTgzNyw3ICs4 MzYsNyBAQCBhdGFfcGlvX3JlYWQoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0CiBzdGF0aWMg dm9pZAogYXRhX3Bpb193cml0ZShzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QsIGludCBsZW5n dGgpCiB7Ci0gICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2 aWNlX2dldF9wYXJlbnQocmVxdWVzdC0+ZGV2KSk7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50KTsKICAgICBpbnQgc2l6ZSA9IG1p bihyZXF1ZXN0LT50cmFuc2ZlcnNpemUsIGxlbmd0aCk7CiAgICAgaW50IHJlc2lkOwogCi0tLSBz cmMvc3lzL2Rldi9hdGEvYXRhLXBjaS5jCTIwMDctMTEtMjIgMDA6MTU6MDAuMDAwMDAwMDAwICsw MzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhLXBjaS5jCTIwMDgtMDktMTggMTY6MTI6MzQuMDAw MDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDE5OTgg LSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykg MTk5OCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0 cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKQEAgLTk2LDYgKzk2LDEwIEBAIGF0YV9wY2lf cHJvYmUoZGV2aWNlX3QgZGV2KQogCWlmICghYXRhX2FtZF9pZGVudChkZXYpKQogCSAgICByZXR1 cm4gQVRBX1BST0JFX09LOwogCWJyZWFrOworICAgIGNhc2UgQVRBX0FEQVBURUNfSUQ6CisJaWYg KCFhdGFfYWRhcHRlY19pZGVudChkZXYpKQorCSAgICByZXR1cm4gQVRBX1BST0JFX09LOworCWJy ZWFrOwogICAgIGNhc2UgQVRBX0FUSV9JRDoKIAlpZiAoIWF0YV9hdGlfaWRlbnQoZGV2KSkKIAkg ICAgcmV0dXJuIEFUQV9QUk9CRV9PSzsKQEAgLTI1OCw2ICsyNjIsMzEgQEAgYXRhX3BjaV9kZXRh Y2goZGV2aWNlX3QgZGV2KQogICAgIHJldHVybiAwOwogfQogCitpbnQKK2F0YV9wY2lfc3VzcGVu ZChkZXZpY2VfdCBkZXYpCit7CisgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICBpbnQgZXJyb3IgPSAwOworIAorICAgIGJ1c19n ZW5lcmljX3N1c3BlbmQoZGV2KTsKKyAgICBpZiAoY3Rsci0+c3VzcGVuZCkKKwllcnJvciA9IGN0 bHItPnN1c3BlbmQoZGV2KTsKKyAgICByZXR1cm4gZXJyb3I7Cit9CisgIAoraW50CithdGFfcGNp X3Jlc3VtZShkZXZpY2VfdCBkZXYpCit7CisgICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAq Y3RsciA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKyAgICBpbnQgZXJyb3IgPSAwOworIAorICAg IGlmIChjdGxyLT5yZXN1bWUpCisJZXJyb3IgPSBjdGxyLT5yZXN1bWUoZGV2KTsKKyAgICBidXNf Z2VuZXJpY19yZXN1bWUoZGV2KTsKKyAgICByZXR1cm4gZXJyb3I7Cit9CisKKwogc3RydWN0IHJl c291cmNlICoKIGF0YV9wY2lfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBj aGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAogCQkgICAgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcg ZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQpAQCAtNDIyLDIzICs0NTEsMTQgQEAgYXRh X3BjaV9hbGxvY2F0ZShkZXZpY2VfdCBkZXYpCiAgICAgcmV0dXJuIDA7CiB9CiAKLXZvaWQKLWF0 YV9wY2lfaHcoZGV2aWNlX3QgZGV2KQotewotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBk ZXZpY2VfZ2V0X3NvZnRjKGRldik7Ci0KLSAgICBhdGFfZ2VuZXJpY19odyhkZXYpOwotICAgIGNo LT5ody5zdGF0dXMgPSBhdGFfcGNpX3N0YXR1czsKLX0KLQogaW50CiBhdGFfcGNpX3N0YXR1cyhk ZXZpY2VfdCBkZXYpCiB7CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRf c29mdGMoZGV2KTsKIAogICAgIGlmICgoZHVtcGluZyB8fCAhYXRhX2xlZ2FjeShkZXZpY2VfZ2V0 X3BhcmVudChkZXYpKSkgJiYKLQljaC0+ZG1hICYmICgoY2gtPmZsYWdzICYgQVRBX0FMV0FZU19E TUFTVEFUKSB8fAotCQkgICAgKGNoLT5kbWEtPmZsYWdzICYgQVRBX0RNQV9BQ1RJVkUpKSkgewor CSgoY2gtPmZsYWdzICYgQVRBX0FMV0FZU19ETUFTVEFUKSB8fAorCSAoY2gtPmRtYS5mbGFncyAm IEFUQV9ETUFfQUNUSVZFKSkpIHsKIAlpbnQgYm1zdGF0ID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9C TVNUQVRfUE9SVCkgJiBBVEFfQk1TVEFUX01BU0s7CiAKIAlpZiAoKGJtc3RhdCAmIChBVEFfQk1T VEFUX0FDVElWRSB8IEFUQV9CTVNUQVRfSU5URVJSVVBUKSkgIT0KQEAgLTQ1NSwzMSArNDc1LDQ0 IEBAIGF0YV9wY2lfc3RhdHVzKGRldmljZV90IGRldikKICAgICByZXR1cm4gMTsKIH0KIAordm9p ZAorYXRhX3BjaV9odyhkZXZpY2VfdCBkZXYpCit7CisgICAgc3RydWN0IGF0YV9jaGFubmVsICpj aCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKworICAgIGF0YV9nZW5lcmljX2h3KGRldik7Cisg ICAgY2gtPmh3LnN0YXR1cyA9IGF0YV9wY2lfc3RhdHVzOworfQorCiBzdGF0aWMgaW50Ci1hdGFf cGNpX2RtYXN0YXJ0KGRldmljZV90IGRldikKK2F0YV9wY2lfZG1hc3RhcnQoc3RydWN0IGF0YV9y ZXF1ZXN0ICpyZXF1ZXN0KQogewotICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KGRldikpOworICAgIHN0cnVjdCBhdGFfY2hhbm5l bCAqY2ggPSBkZXZpY2VfZ2V0X3NvZnRjKHJlcXVlc3QtPnBhcmVudCk7CisKKyAgICBBVEFfREVC VUdfUlEocmVxdWVzdCwgImRtYXN0YXJ0Iik7CiAKICAgICBBVEFfSURYX09VVEIoY2gsIEFUQV9C TVNUQVRfUE9SVCwgKEFUQV9JRFhfSU5CKGNoLCBBVEFfQk1TVEFUX1BPUlQpIHwgCiAJCSAoQVRB X0JNU1RBVF9JTlRFUlJVUFQgfCBBVEFfQk1TVEFUX0VSUk9SKSkpOwotICAgIEFUQV9JRFhfT1VU TChjaCwgQVRBX0JNRFRQX1BPUlQsIGNoLT5kbWEtPnNnX2J1cyk7Ci0gICAgY2gtPmRtYS0+Zmxh Z3MgfD0gQVRBX0RNQV9BQ1RJVkU7CisgICAgQVRBX0lEWF9PVVRMKGNoLCBBVEFfQk1EVFBfUE9S VCwgcmVxdWVzdC0+ZG1hLT5zZ19idXMpOworICAgIGNoLT5kbWEuZmxhZ3MgfD0gQVRBX0RNQV9B Q1RJVkU7CiAgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfQk1DTURfUE9SVCwKIAkJIChBVEFfSURY X0lOQihjaCwgQVRBX0JNQ01EX1BPUlQpICYgfkFUQV9CTUNNRF9XUklURV9SRUFEKSB8Ci0JCSAo KGNoLT5kbWEtPmZsYWdzICYgQVRBX0RNQV9SRUFEKSA/IEFUQV9CTUNNRF9XUklURV9SRUFEIDog MCkgfAorCQkgKChyZXF1ZXN0LT5mbGFncyAmIEFUQV9SX1JFQUQpID8gQVRBX0JNQ01EX1dSSVRF X1JFQUQgOiAwKXwKIAkJIEFUQV9CTUNNRF9TVEFSVF9TVE9QKTsKICAgICByZXR1cm4gMDsKIH0K IAogc3RhdGljIGludAotYXRhX3BjaV9kbWFzdG9wKGRldmljZV90IGRldikKK2F0YV9wY2lfZG1h c3RvcChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiB7Ci0gICAgc3RydWN0IGF0YV9jaGFu bmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7CisgICAg c3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMocmVxdWVzdC0+cGFyZW50 KTsKICAgICBpbnQgZXJyb3I7CiAKKyAgICBBVEFfREVCVUdfUlEocmVxdWVzdCwgImRtYXN0b3Ai KTsKKwogICAgIEFUQV9JRFhfT1VUQihjaCwgQVRBX0JNQ01EX1BPUlQsIAogCQkgQVRBX0lEWF9J TkIoY2gsIEFUQV9CTUNNRF9QT1JUKSAmIH5BVEFfQk1DTURfU1RBUlRfU1RPUCk7Ci0gICAgY2gt PmRtYS0+ZmxhZ3MgJj0gfkFUQV9ETUFfQUNUSVZFOworICAgIGNoLT5kbWEuZmxhZ3MgJj0gfkFU QV9ETUFfQUNUSVZFOwogICAgIGVycm9yID0gQVRBX0lEWF9JTkIoY2gsIEFUQV9CTVNUQVRfUE9S VCkgJiBBVEFfQk1TVEFUX01BU0s7CiAgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfQk1TVEFUX1BP UlQsIEFUQV9CTVNUQVRfSU5URVJSVVBUIHwgQVRBX0JNU1RBVF9FUlJPUik7CiAgICAgcmV0dXJu IGVycm9yOwpAQCAtNDg5LDEyICs1MjIsMTYgQEAgc3RhdGljIHZvaWQKIGF0YV9wY2lfZG1hcmVz ZXQoZGV2aWNlX3QgZGV2KQogewogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldik7CisgICAgc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0OwogCiAgICAg QVRBX0lEWF9PVVRCKGNoLCBBVEFfQk1DTURfUE9SVCwgCiAJCSBBVEFfSURYX0lOQihjaCwgQVRB X0JNQ01EX1BPUlQpICYgfkFUQV9CTUNNRF9TVEFSVF9TVE9QKTsKLSAgICBjaC0+ZG1hLT5mbGFn cyAmPSB+QVRBX0RNQV9BQ1RJVkU7CisgICAgY2gtPmRtYS5mbGFncyAmPSB+QVRBX0RNQV9BQ1RJ VkU7CiAgICAgQVRBX0lEWF9PVVRCKGNoLCBBVEFfQk1TVEFUX1BPUlQsIEFUQV9CTVNUQVRfSU5U RVJSVVBUIHwgQVRBX0JNU1RBVF9FUlJPUik7Ci0gICAgY2gtPmRtYS0+dW5sb2FkKGRldik7Cisg ICAgaWYgKChyZXF1ZXN0ID0gY2gtPnJ1bm5pbmcpKSB7CisJZGV2aWNlX3ByaW50ZihyZXF1ZXN0 LT5kZXYsICJETUEgcmVzZXQgY2FsbGluZyB1bmxvYWRcbiIpOworCWNoLT5kbWEudW5sb2FkKHJl cXVlc3QpOworICAgIH0KIH0KIAogdm9pZApAQCAtNTAzLDExICs1NDAsOSBAQCBhdGFfcGNpX2Rt YWluaXQoZGV2aWNlX3QgZGV2KQogICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldik7CiAKICAgICBhdGFfZG1haW5pdChkZXYpOwotICAgIGlmIChjaC0+ZG1h KSB7Ci0JY2gtPmRtYS0+c3RhcnQgPSBhdGFfcGNpX2RtYXN0YXJ0OwotCWNoLT5kbWEtPnN0b3Ag PSBhdGFfcGNpX2RtYXN0b3A7Ci0JY2gtPmRtYS0+cmVzZXQgPSBhdGFfcGNpX2RtYXJlc2V0Owot ICAgIH0KKyAgICBjaC0+ZG1hLnN0YXJ0ID0gYXRhX3BjaV9kbWFzdGFydDsKKyAgICBjaC0+ZG1h LnN0b3AgPSBhdGFfcGNpX2RtYXN0b3A7CisgICAgY2gtPmRtYS5yZXNldCA9IGF0YV9wY2lfZG1h cmVzZXQ7CiB9CiAKIGNoYXIgKgpAQCAtNTE3LDYgKzU1Miw3IEBAIGF0YV9wY2l2ZW5kb3Iyc3Ry KGRldmljZV90IGRldikKICAgICBjYXNlIEFUQV9BQ0FSRF9JRDogICAgICAgICAgcmV0dXJuICJB Y2FyZCI7CiAgICAgY2FzZSBBVEFfQUNFUl9MQUJTX0lEOiAgICAgIHJldHVybiAiQWNlckxhYnMi OwogICAgIGNhc2UgQVRBX0FNRF9JRDogICAgICAgICAgICByZXR1cm4gIkFNRCI7CisgICAgY2Fz ZSBBVEFfQURBUFRFQ19JRDogICAgICAgIHJldHVybiAiQWRhcHRlYyI7CiAgICAgY2FzZSBBVEFf QVRJX0lEOiAgICAgICAgICAgIHJldHVybiAiQVRJIjsKICAgICBjYXNlIEFUQV9DWVJJWF9JRDog ICAgICAgICAgcmV0dXJuICJDeXJpeCI7CiAgICAgY2FzZSBBVEFfQ1lQUkVTU19JRDogICAgICAg IHJldHVybiAiQ3lwcmVzcyI7CkBAIC01NDQsOSArNTgwLDkgQEAgc3RhdGljIGRldmljZV9tZXRo b2RfdCBhdGFfcGNpX21ldGhvZHNbXQogICAgIERFVk1FVEhPRChkZXZpY2VfcHJvYmUsICAgICAg ICAgICAgIGF0YV9wY2lfcHJvYmUpLAogICAgIERFVk1FVEhPRChkZXZpY2VfYXR0YWNoLCAgICAg ICAgICAgIGF0YV9wY2lfYXR0YWNoKSwKICAgICBERVZNRVRIT0QoZGV2aWNlX2RldGFjaCwgICAg ICAgICAgICBhdGFfcGNpX2RldGFjaCksCisgICAgREVWTUVUSE9EKGRldmljZV9zdXNwZW5kLCAg ICAgICAgICAgYXRhX3BjaV9zdXNwZW5kKSwKKyAgICBERVZNRVRIT0QoZGV2aWNlX3Jlc3VtZSwg ICAgICAgICAgICBhdGFfcGNpX3Jlc3VtZSksCiAgICAgREVWTUVUSE9EKGRldmljZV9zaHV0ZG93 biwgICAgICAgICAgYnVzX2dlbmVyaWNfc2h1dGRvd24pLAotICAgIERFVk1FVEhPRChkZXZpY2Vf c3VzcGVuZCwgICAgICAgICAgIGJ1c19nZW5lcmljX3N1c3BlbmQpLAotICAgIERFVk1FVEhPRChk ZXZpY2VfcmVzdW1lLCAgICAgICAgICAgIGJ1c19nZW5lcmljX3Jlc3VtZSksCiAKICAgICAvKiBi dXMgbWV0aG9kcyAqLwogICAgIERFVk1FVEhPRChidXNfYWxsb2NfcmVzb3VyY2UsICAgICAgIGF0 YV9wY2lfYWxsb2NfcmVzb3VyY2UpLApAQCAtNjAwLDE5ICs2MzYsMTMgQEAgc3RhdGljIGludAog YXRhX3BjaWNoYW5uZWxfYXR0YWNoKGRldmljZV90IGRldikKIHsKICAgICBzdHJ1Y3QgYXRhX3Bj aV9jb250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChk ZXYpKTsKLSAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OwogICAgIGludCBlcnJvcjsKIAogICAgIGlmIChjdGxyLT5kbWFpbml0KQogCWN0bHItPmRtYWlu aXQoZGV2KTsKLSAgICBpZiAoY2gtPmRtYSkKLQljaC0+ZG1hLT5hbGxvYyhkZXYpOwogCi0gICAg aWYgKChlcnJvciA9IGN0bHItPmFsbG9jYXRlKGRldikpKSB7Ci0JaWYgKGNoLT5kbWEpCi0JICAg IGNoLT5kbWEtPmZyZWUoZGV2KTsKKyAgICBpZiAoKGVycm9yID0gY3Rsci0+YWxsb2NhdGUoZGV2 KSkpCiAJcmV0dXJuIGVycm9yOwotICAgIH0KIAogICAgIHJldHVybiBhdGFfYXR0YWNoKGRldik7 CiB9CkBAIC02MjYsOCArNjU2LDcgQEAgYXRhX3BjaWNoYW5uZWxfZGV0YWNoKGRldmljZV90IGRl dikKICAgICBpZiAoKGVycm9yID0gYXRhX2RldGFjaChkZXYpKSkKIAlyZXR1cm4gZXJyb3I7CiAK LSAgICBpZiAoY2gtPmRtYSkKLQljaC0+ZG1hLT5mcmVlKGRldik7CisgICAgY2gtPmRtYS5mcmVl KGRldik7CiAKICAgICAvKiBYWFggU09TIGZyZWUgcmVzb3VyY2VzIGZvciBpbyBhbmQgY3RsaW8g Pz8gKi8KIApAQCAtNjUzLDExICs2ODIsOCBAQCBhdGFfcGNpY2hhbm5lbF9yZXNldChkZXZpY2Vf dCBkZXYpCiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2 KTsKIAogICAgIC8qIGlmIERNQSBlbmdpbmUgcHJlc2VudCByZXNldCBpdCAgKi8KLSAgICBpZiAo Y2gtPmRtYSkgewotCWlmIChjaC0+ZG1hLT5yZXNldCkKLQkgICAgY2gtPmRtYS0+cmVzZXQoZGV2 KTsKLQljaC0+ZG1hLT51bmxvYWQoZGV2KTsKLSAgICB9CisgICAgaWYgKGNoLT5kbWEucmVzZXQp CisJY2gtPmRtYS5yZXNldChkZXYpOwogCiAgICAgLyogcmVzZXQgdGhlIGNvbnRyb2xsZXIgSFcg Ki8KICAgICBpZiAoY3Rsci0+cmVzZXQpCi0tLSBzcmMvc3lzL2Rldi9hdGEvYXRhLXBjaS5oCTIw MDgtMDktMTMgMTE6MzY6MTYuMDAwMDAwMDAwICswNDAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRh LXBjaS5oCTIwMDgtMDktMjYgMTE6Mjk6NDguMDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBA QAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDIwMDMgLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BG cmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykgMjAwMyAtIDIwMDggU/hyZW4gU2NobWlkdCA8 c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3Ry aWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhv dXQKQEAgLTUwLDYgKzUwLDggQEAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciB7CiAgICAgc3Ry dWN0IGF0YV9jaGlwX2lkICAqY2hpcDsKICAgICBpbnQgICAgICAgICAgICAgICAgIGNoYW5uZWxz OwogICAgIGludCAgICAgICAgICAgICAgICAgKCpjaGlwaW5pdCkoZGV2aWNlX3QpOworICAgIGlu dCAgICAgICAgICAgICAgICAgKCpzdXNwZW5kKShkZXZpY2VfdCk7CisgICAgaW50ICAgICAgICAg ICAgICAgICAoKnJlc3VtZSkoZGV2aWNlX3QpOwogICAgIGludCAgICAgICAgICAgICAgICAgKCph bGxvY2F0ZSkoZGV2aWNlX3QpOwogICAgIGludCAgICAgICAgICAgICAgICAgKCpsb2NraW5nKShk ZXZpY2VfdCwgaW50KTsKICAgICB2b2lkICAgICAgICAgICAgICAgICgqcmVzZXQpKGRldmljZV90 KTsKQEAgLTgwLDYgKzgyLDE0IEBAIHN0cnVjdCBhdGFfY29ubmVjdF90YXNrIHsKICNkZWZpbmUg QVRBX0FUUDg2NUEgICAgICAgICAgICAgMHgwMDA4MTE5MQogI2RlZmluZSBBVEFfQVRQODY1UiAg ICAgICAgICAgICAweDAwMDkxMTkxCiAKKyNkZWZpbmUgQVRBX0FDRVJfTEFCU19JRCAgICAgICAg MHgxMGI5CisjZGVmaW5lIEFUQV9BTElfMTUzMyAgICAgICAgICAgIDB4MTUzMzEwYjkKKyNkZWZp bmUgQVRBX0FMSV81MjI5ICAgICAgICAgICAgMHg1MjI5MTBiOQorI2RlZmluZSBBVEFfQUxJXzUy ODEgICAgICAgICAgICAweDUyODExMGI5CisjZGVmaW5lIEFUQV9BTElfNTI4NyAgICAgICAgICAg IDB4NTI4NzEwYjkKKyNkZWZpbmUgQVRBX0FMSV81Mjg4ICAgICAgICAgICAgMHg1Mjg4MTBiOQor I2RlZmluZSBBVEFfQUxJXzUyODkgICAgICAgICAgICAweDUyODkxMGI5CisKICNkZWZpbmUgQVRB X0FNRF9JRCAgICAgICAgICAgICAgMHgxMDIyCiAjZGVmaW5lIEFUQV9BTUQ3NTUgICAgICAgICAg ICAgIDB4NzQwMTEwMjIKICNkZWZpbmUgQVRBX0FNRDc1NiAgICAgICAgICAgICAgMHg3NDA5MTAy MgpAQCAtODgsMTMgKzk4LDggQEAgc3RydWN0IGF0YV9jb25uZWN0X3Rhc2sgewogI2RlZmluZSBB VEFfQU1EODExMSAgICAgICAgICAgICAweDc0NjkxMDIyCiAjZGVmaW5lIEFUQV9BTUQ1NTM2ICAg ICAgICAgICAgIDB4MjA5YTEwMjIKIAotI2RlZmluZSBBVEFfQUNFUl9MQUJTX0lEICAgICAgICAw eDEwYjkKLSNkZWZpbmUgQVRBX0FMSV8xNTMzICAgICAgICAgICAgMHgxNTMzMTBiOQotI2RlZmlu ZSBBVEFfQUxJXzUyMjkgICAgICAgICAgICAweDUyMjkxMGI5Ci0jZGVmaW5lIEFUQV9BTElfNTI4 MSAgICAgICAgICAgIDB4NTI4MTEwYjkKLSNkZWZpbmUgQVRBX0FMSV81Mjg3ICAgICAgICAgICAg MHg1Mjg3MTBiOQotI2RlZmluZSBBVEFfQUxJXzUyODggICAgICAgICAgICAweDUyODgxMGI5Ci0j ZGVmaW5lIEFUQV9BTElfNTI4OSAgICAgICAgICAgIDB4NTI4OTEwYjkKKyNkZWZpbmUgQVRBX0FE QVBURUNfSUQgICAgICAgICAgMHg5MDA1CisjZGVmaW5lIEFUQV9BREFQVEVDXzE0MjAgICAgICAg IDB4MDI0MTkwMDUKIAogI2RlZmluZSBBVEFfQVRJX0lEICAgICAgICAgICAgICAweDEwMDIKICNk ZWZpbmUgQVRBX0FUSV9JWFAyMDAgICAgICAgICAgMHg0MzQ5MTAwMgpAQCAtMTg1LDYgKzE5MCw3 IEBAIHN0cnVjdCBhdGFfY29ubmVjdF90YXNrIHsKICNkZWZpbmUgQVRBX0lURV9JRCAgICAgICAg ICAgICAgMHgxMjgzCiAjZGVmaW5lIEFUQV9JVDgyMTFGICAgICAgICAgICAgIDB4ODIxMTEyODMK ICNkZWZpbmUgQVRBX0lUODIxMkYgICAgICAgICAgICAgMHg4MjEyMTI4MworI2RlZmluZSBBVEFf SVQ4MjEzRiAgICAgICAgICAgICAweDgyMTMxMjgzCiAKICNkZWZpbmUgQVRBX0pNSUNST05fSUQg ICAgICAgICAgMHgxOTdiCiAjZGVmaW5lIEFUQV9KTUIzNjAgICAgICAgICAgICAgIDB4MjM2MDE5 N2IKQEAgLTQ1OCwxMyArNDY0LDE1IEBAIHN0cnVjdCBhdGFfY29ubmVjdF90YXNrIHsKIGludCBh dGFfcGNpX3Byb2JlKGRldmljZV90IGRldik7CiBpbnQgYXRhX3BjaV9hdHRhY2goZGV2aWNlX3Qg ZGV2KTsKIGludCBhdGFfcGNpX2RldGFjaChkZXZpY2VfdCBkZXYpOworaW50IGF0YV9wY2lfc3Vz cGVuZChkZXZpY2VfdCBkZXYpOworaW50IGF0YV9wY2lfcmVzdW1lKGRldmljZV90IGRldik7CiBz dHJ1Y3QgcmVzb3VyY2UgKiBhdGFfcGNpX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5k LCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsKIGludCBhdGFfcGNpX3JlbGVhc2VfcmVzb3Vy Y2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQsIHN0cnVj dCByZXNvdXJjZSAqcik7CiBpbnQgYXRhX3BjaV9zZXR1cF9pbnRyKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqaXJxLCBpbnQgZmxhZ3MsIGRyaXZlcl9maWx0 ZXJfdCAqZmlsdGVyLCBkcml2ZXJfaW50cl90ICpmdW5jdGlvbiwgdm9pZCAqYXJndW1lbnQsIHZv aWQgKipjb29raWVwKTsKICBpbnQgYXRhX3BjaV90ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwg ZGV2aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqaXJxLCB2b2lkICpjb29raWUpOwogaW50 IGF0YV9wY2lfYWxsb2NhdGUoZGV2aWNlX3QgZGV2KTsKLXZvaWQgYXRhX3BjaV9odyhkZXZpY2Vf dCBkZXYpOwogaW50IGF0YV9wY2lfc3RhdHVzKGRldmljZV90IGRldik7Cit2b2lkIGF0YV9wY2lf aHcoZGV2aWNlX3QgZGV2KTsKIHZvaWQgYXRhX3BjaV9kbWFpbml0KGRldmljZV90IGRldik7CiBj aGFyICphdGFfcGNpdmVuZG9yMnN0cihkZXZpY2VfdCBkZXYpOwogCkBAIC00NzUsNiArNDgzLDcg QEAgaW50IGF0YV9haGNpX2lkZW50KGRldmljZV90KTsKIGludCBhdGFfYWNhcmRfaWRlbnQoZGV2 aWNlX3QpOwogaW50IGF0YV9hbGlfaWRlbnQoZGV2aWNlX3QpOwogaW50IGF0YV9hbWRfaWRlbnQo ZGV2aWNlX3QpOworaW50IGF0YV9hZGFwdGVjX2lkZW50KGRldmljZV90KTsKIGludCBhdGFfYXRp X2lkZW50KGRldmljZV90KTsKIGludCBhdGFfY3lyaXhfaWRlbnQoZGV2aWNlX3QpOwogaW50IGF0 YV9jeXByZXNzX2lkZW50KGRldmljZV90KTsKLS0tIHNyYy9zeXMvZGV2L2F0YS9hdGEtcXVldWUu YwkyMDA3LTAzLTEzIDIzOjMxOjU2LjAwMDAwMDAwMCArMDMwMAorKysgc3JjL3N5cy9kZXYvYXRh L2F0YS1xdWV1ZS5jCTIwMDgtMDQtMjEgMTQ6MzU6MTkuMDAwMDAwMDAwICswNDAwCkBAIC0xLDUg KzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA3IFP4cmVuIFNjaG1pZHQg PHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDggU/hyZW4gU2No bWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBS ZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9y IHdpdGhvdXQKQEAgLTU2LDcgKzU2LDcgQEAgYXRhX3F1ZXVlX3JlcXVlc3Qoc3RydWN0IGF0YV9y ZXF1ZXN0ICpyZQogICAgIC8qIHRyZWF0IHJlcXVlc3QgYXMgdmlyZ2luICh0aGlzIG1pZ2h0IGJl IGFuIEFUQV9SX1JFUVVFVUUpICovCiAgICAgcmVxdWVzdC0+cmVzdWx0ID0gcmVxdWVzdC0+c3Rh dHVzID0gcmVxdWVzdC0+ZXJyb3IgPSAwOwogCi0gICAgLyogY2hlY2sgdGhhdCB0aGF0IHRoZSBk ZXZpY2UgaXMgc3RpbGwgdmFsaWQgKi8KKyAgICAvKiBjaGVjayB0aGF0IHRoZSBkZXZpY2UgaXMg c3RpbGwgdmFsaWQgKi8KICAgICBpZiAoIShyZXF1ZXN0LT5wYXJlbnQgPSBkZXZpY2VfZ2V0X3Bh cmVudChyZXF1ZXN0LT5kZXYpKSkgewogCXJlcXVlc3QtPnJlc3VsdCA9IEVOWElPOwogCWlmIChy ZXF1ZXN0LT5jYWxsYmFjaykKQEAgLTM1OCw4ICszNTgsOCBAQCBhdGFfY29tcGxldGVkKHZvaWQg KmNvbnRleHQsIGludCBkdW1teSkKIAkJCSAgICAgICJcNE1FRElBX0NIQU5HRV9SRVFFU1QiCiAJ CQkgICAgICAiXDNBQk9SVEVEXDJOT19NRURJQVwxSUxMRUdBTF9MRU5HVEgiKTsKIAkJaWYgKChy ZXF1ZXN0LT5mbGFncyAmIEFUQV9SX0RNQSkgJiYKLQkJICAgIChyZXF1ZXN0LT5kbWFzdGF0ICYg QVRBX0JNU1RBVF9FUlJPUikpCi0JCSAgICBwcmludGYoIiBkbWE9MHglMDJ4IiwgcmVxdWVzdC0+ ZG1hc3RhdCk7CisJCSAgICAocmVxdWVzdC0+ZG1hLT5zdGF0dXMgJiBBVEFfQk1TVEFUX0VSUk9S KSkKKwkJICAgIHByaW50ZigiIGRtYT0weCUwMngiLCByZXF1ZXN0LT5kbWEtPnN0YXR1cyk7CiAJ CWlmICghKHJlcXVlc3QtPmZsYWdzICYgKEFUQV9SX0FUQVBJIHwgQVRBX1JfQ09OVFJPTCkpKQog CQkgICAgcHJpbnRmKCIgTEJBPSVqdSIsIHJlcXVlc3QtPnUuYXRhLmxiYSk7CiAJCXByaW50Zigi XG4iKTsKQEAgLTUwMyw2ICs1MDMsNyBAQCBhdGFfdGltZW91dChzdHJ1Y3QgYXRhX3JlcXVlc3Qg KnJlcXVlc3QpCiAJcmVxdWVzdC0+ZmxhZ3MgfD0gQVRBX1JfVElNRU9VVDsKIAltdHhfdW5sb2Nr KCZjaC0+c3RhdGVfbXR4KTsKIAlBVEFfTE9DS0lORyhjaC0+ZGV2LCBBVEFfTEZfVU5MT0NLKTsK KwljaC0+ZG1hLnVubG9hZChyZXF1ZXN0KTsKIAlhdGFfZmluaXNoKHJlcXVlc3QpOwogICAgIH0K ICAgICBlbHNlIHsKQEAgLTY5NCwxMSArNjk1LDEzIEBAIGF0YV9jbWQyc3RyKHN0cnVjdCBhdGFf cmVxdWVzdCAqcmVxdWVzdCkKIAljYXNlIDB4MjQ6IHJldHVybiAoIlJFQUQ0OCIpOwogCWNhc2Ug MHgyNTogcmV0dXJuICgiUkVBRF9ETUE0OCIpOwogCWNhc2UgMHgyNjogcmV0dXJuICgiUkVBRF9E TUFfUVVFVUVENDgiKTsKKwljYXNlIDB4Mjc6IHJldHVybiAoIlJFQURfTkFUSVZFX01BWF9BRERS RVNTNDgiKTsKIAljYXNlIDB4Mjk6IHJldHVybiAoIlJFQURfTVVMNDgiKTsKIAljYXNlIDB4MzA6 IHJldHVybiAoIldSSVRFIik7CiAJY2FzZSAweDM0OiByZXR1cm4gKCJXUklURTQ4Iik7CiAJY2Fz ZSAweDM1OiByZXR1cm4gKCJXUklURV9ETUE0OCIpOwogCWNhc2UgMHgzNjogcmV0dXJuICgiV1JJ VEVfRE1BX1FVRVVFRDQ4Iik7CisJY2FzZSAweDM3OiByZXR1cm4gKCJTRVRfTUFYX0FERFJFU1M0 OCIpOwogCWNhc2UgMHgzOTogcmV0dXJuICgiV1JJVEVfTVVMNDgiKTsKIAljYXNlIDB4NzA6IHJl dHVybiAoIlNFRUsiKTsKIAljYXNlIDB4YTA6IHJldHVybiAoIlBBQ0tFVF9DTUQiKTsKQEAgLTcy Nyw2ICs3MzAsOSBAQCBhdGFfY21kMnN0cihzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QpCiAJ ICAgIH0KIAkgICAgc3ByaW50ZihidWZmZXIsICJTRVRGRUFUVVJFUyAweCUwMngiLCByZXF1ZXN0 LT51LmF0YS5mZWF0dXJlKTsKIAkgICAgcmV0dXJuIGJ1ZmZlcjsKKwljYXNlIDB4ZjU6IHJldHVy biAoIlNFQ1VSSVRZX0ZSRUVfTE9DSyIpOworCWNhc2UgMHhmODogcmV0dXJuICgiUkVBRF9OQVRJ VkVfTUFYX0FERFJFU1MiKTsKKwljYXNlIDB4Zjk6IHJldHVybiAoIlNFVF9NQVhfQUREUkVTUyIp OwogCX0KICAgICB9CiAgICAgc3ByaW50ZihidWZmZXIsICJ1bmtub3duIENNRCAoMHglMDJ4KSIs IHJlcXVlc3QtPnUuYXRhLmNvbW1hbmQpOwotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1yYWlkLmMJ MjAwNy0wOC0xMyAyMjo0NjozMS4wMDAwMDAwMDAgKzA0MDAKKysrIHNyYy9zeXMvZGV2L2F0YS9h dGEtcmFpZC5jCTIwMDgtMDQtMTcgMTY6Mjk6MzUuMDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEs NSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDIwMDAgLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNv c0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykgMjAwMCAtIDIwMDggU/hyZW4gU2NobWlk dCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRp c3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdp dGhvdXQKQEAgLTgzLDcgKzgzLDcgQEAgc3RhdGljIGludCBhdGFfcmFpZF9zaXNfcmVhZF9tZXRh KGRldmljZQogc3RhdGljIGludCBhdGFfcmFpZF9zaXNfd3JpdGVfbWV0YShzdHJ1Y3QgYXJfc29m dGMgKnJkcCk7CiBzdGF0aWMgaW50IGF0YV9yYWlkX3ZpYV9yZWFkX21ldGEoZGV2aWNlX3QgZGV2 LCBzdHJ1Y3QgYXJfc29mdGMgKipyYWlkcCk7CiBzdGF0aWMgaW50IGF0YV9yYWlkX3ZpYV93cml0 ZV9tZXRhKHN0cnVjdCBhcl9zb2Z0YyAqcmRwKTsKLXN0YXRpYyBzdHJ1Y3QgYXRhX3JlcXVlc3Qg KmF0YV9yYWlkX2luaXRfcmVxdWVzdChzdHJ1Y3QgYXJfc29mdGMgKnJkcCwgc3RydWN0IGJpbyAq YmlvKTsKK3N0YXRpYyBzdHJ1Y3QgYXRhX3JlcXVlc3QgKmF0YV9yYWlkX2luaXRfcmVxdWVzdChk ZXZpY2VfdCBkZXYsIHN0cnVjdCBhcl9zb2Z0YyAqcmRwLCBzdHJ1Y3QgYmlvICpiaW8pOwogc3Rh dGljIGludCBhdGFfcmFpZF9zZW5kX3JlcXVlc3Qoc3RydWN0IGF0YV9yZXF1ZXN0ICpyZXF1ZXN0 KTsKIHN0YXRpYyBpbnQgYXRhX3JhaWRfcncoZGV2aWNlX3QgZGV2LCB1X2ludDY0X3QgbGJhLCB2 b2lkICpkYXRhLCB1X2ludCBiY291bnQsIGludCBmbGFncyk7CiBzdGF0aWMgY2hhciAqIGF0YV9y YWlkX2Zvcm1hdChzdHJ1Y3QgYXJfc29mdGMgKnJkcCk7CkBAIC0yNjMsNyArMjYzLDcgQEAgYXRh X3JhaWRfZmx1c2goc3RydWN0IGJpbyAqYnApCiAgICAgZm9yIChkaXNrID0gMDsgZGlzayA8IHJk cC0+dG90YWxfZGlza3M7IGRpc2srKykgewogCWlmICgoZGV2ID0gcmRwLT5kaXNrc1tkaXNrXS5k ZXYpID09IE5VTEwpCiAJICAgIGNvbnRpbnVlOwotCWlmICghKHJlcXVlc3QgPSBhdGFfcmFpZF9p bml0X3JlcXVlc3QocmRwLCBicCkpKQorCWlmICghKHJlcXVlc3QgPSBhdGFfcmFpZF9pbml0X3Jl cXVlc3QoZGV2LCByZHAsIGJwKSkpCiAJICAgIHJldHVybiBFTk9NRU07CiAJcmVxdWVzdC0+ZGV2 ID0gZGV2OwogCXJlcXVlc3QtPnUuYXRhLmNvbW1hbmQgPSBBVEFfRkxVU0hDQUNIRTsKQEAgLTM1 Myw3ICszNTMsNyBAQCBhdGFfcmFpZF9zdHJhdGVneShzdHJ1Y3QgYmlvICpicCkKIAlpZiAoIShk cnYgPT0gMCAmJiByZHAtPmZvcm1hdCA9PSBBUl9GX0hQVFYyX1JBSUQpKQogCSAgICBsYmEgKz0g cmRwLT5vZmZzZXRfc2VjdG9yczsKIAotCWlmICghKHJlcXVlc3QgPSBhdGFfcmFpZF9pbml0X3Jl cXVlc3QocmRwLCBicCkpKSB7CisJaWYgKCEocmVxdWVzdCA9IGF0YV9yYWlkX2luaXRfcmVxdWVz dChyZHAtPmRpc2tzW2Rydl0uZGV2LCByZHAsIGJwKSkpIHsKIAkgICAgYmlvZmluaXNoKGJwLCBO VUxMLCBFSU8pOwogCSAgICByZXR1cm47CiAJfQpAQCAtMzc1LDcgKzM3NSw3IEBAIGF0YV9yYWlk X3N0cmF0ZWd5KHN0cnVjdCBiaW8gKmJwKQogCQlyZXR1cm47CiAJICAgIH0KIAkgICAgcmVxdWVz dC0+dGhpcyA9IGRydjsKLQkgICAgcmVxdWVzdC0+ZGV2ID0gcmRwLT5kaXNrc1tyZXF1ZXN0LT50 aGlzXS5kZXY7CisJICAgIHJlcXVlc3QtPmRldiA9IHJkcC0+ZGlza3NbZHJ2XS5kZXY7CiAJICAg IGF0YV9yYWlkX3NlbmRfcmVxdWVzdChyZXF1ZXN0KTsKIAkgICAgYnJlYWs7CiAKQEAgLTQ1Nywx MiArNDU3LDE0IEBAIGF0YV9yYWlkX3N0cmF0ZWd5KHN0cnVjdCBiaW8gKmJwKQogCQkgICAgLyog ZG8gd2UgaGF2ZSBhIHNwYXJlIHRvIHJlYnVpbGQgb24gPyAqLwogCQkgICAgaWYgKHJkcC0+ZGlz a3NbdGhpc10uZmxhZ3MgJiBBUl9ERl9TUEFSRSkgewogCQkJaWYgKChjb21wb3NpdGUgPSBhdGFf YWxsb2NfY29tcG9zaXRlKCkpKSB7Ci0JCQkgICAgaWYgKChyZWJ1aWxkID0gYXRhX2FsbG9jX3Jl cXVlc3QoKSkpIHsKKwkJCSAgICBpZiAoKHJlYnVpbGQgPSBhdGFfcmFpZF9pbml0X3JlcXVlc3Qo CisJCQkJICAgIAkgICByZHAtPmRpc2tzW3RoaXNdLmRldiwgcmRwLCBicCkpKSB7CiAJCQkJcmRw LT5yZWJ1aWxkX2xiYSA9IGJsayArIGNodW5rOwotCQkJCWJjb3B5KHJlcXVlc3QsIHJlYnVpbGQs Ci0JCQkJICAgICAgc2l6ZW9mKHN0cnVjdCBhdGFfcmVxdWVzdCkpOworCQkJCXJlYnVpbGQtPmRh dGEgPSByZXF1ZXN0LT5kYXRhOworCQkJCXJlYnVpbGQtPmJ5dGVjb3VudCA9IHJlcXVlc3QtPmJ5 dGVjb3VudDsKKwkJCQlyZWJ1aWxkLT51LmF0YS5sYmEgPSByZXF1ZXN0LT51LmF0YS5sYmE7CisJ CQkJcmVidWlsZC0+dS5hdGEuY291bnQgPSByZXF1ZXN0LT51LmF0YS5jb3VudDsKIAkJCQlyZWJ1 aWxkLT50aGlzID0gdGhpczsKLQkJCQlyZWJ1aWxkLT5kZXYgPSByZHAtPmRpc2tzW3RoaXNdLmRl djsKIAkJCQlyZWJ1aWxkLT5mbGFncyAmPSB+QVRBX1JfUkVBRDsKIAkJCQlyZWJ1aWxkLT5mbGFn cyB8PSBBVEFfUl9XUklURTsKIAkJCQltdHhfaW5pdCgmY29tcG9zaXRlLT5sb2NrLApAQCAtNTE4 LDE0ICs1MjAsMTYgQEAgYXRhX3JhaWRfc3RyYXRlZ3koc3RydWN0IGJpbyAqYnApCiAJCQlpbnQg dGhpcyA9IGRydiArIHJkcC0+d2lkdGg7CiAKIAkJCWlmICgoY29tcG9zaXRlID0gYXRhX2FsbG9j X2NvbXBvc2l0ZSgpKSkgewotCQkJICAgIGlmICgobWlycm9yID0gYXRhX2FsbG9jX3JlcXVlc3Qo KSkpIHsKKwkJCSAgICBpZiAoKG1pcnJvciA9IGF0YV9yYWlkX2luaXRfcmVxdWVzdCgKKwkJCQkg ICAgCSAgcmRwLT5kaXNrc1t0aGlzXS5kZXYsIHJkcCwgYnApKSkgewogCQkJCWlmICgoYmxrIDw9 IHJkcC0+cmVidWlsZF9sYmEpICYmCiAJCQkJICAgICgoYmxrICsgY2h1bmspID4gcmRwLT5yZWJ1 aWxkX2xiYSkpCiAJCQkJICAgIHJkcC0+cmVidWlsZF9sYmEgPSBibGsgKyBjaHVuazsKLQkJCQli Y29weShyZXF1ZXN0LCBtaXJyb3IsCi0JCQkJICAgICAgc2l6ZW9mKHN0cnVjdCBhdGFfcmVxdWVz dCkpOworCQkJCW1pcnJvci0+ZGF0YSA9IHJlcXVlc3QtPmRhdGE7CisJCQkJbWlycm9yLT5ieXRl Y291bnQgPSByZXF1ZXN0LT5ieXRlY291bnQ7CisJCQkJbWlycm9yLT51LmF0YS5sYmEgPSByZXF1 ZXN0LT51LmF0YS5sYmE7CisJCQkJbWlycm9yLT51LmF0YS5jb3VudCA9IHJlcXVlc3QtPnUuYXRh LmNvdW50OwogCQkJCW1pcnJvci0+dGhpcyA9IHRoaXM7Ci0JCQkJbWlycm9yLT5kZXYgPSByZHAt PmRpc2tzW3RoaXNdLmRldjsKIAkJCQltdHhfaW5pdCgmY29tcG9zaXRlLT5sb2NrLAogCQkJCQkg IkFUQSBQc2V1ZG9SQUlEIG1pcnJvciBsb2NrIiwKIAkJCQkJIE5VTEwsIE1UWF9ERUYpOwpAQCAt ODU2LDYgKzg2MCw3IEBAIGF0YV9yYWlkX2NvbmZpZ19jaGFuZ2VkKHN0cnVjdCBhcl9zb2Z0YyAK ICAgICBpbnQgZGlzaywgY291bnQsIHN0YXR1czsKIAogICAgIG10eF9sb2NrKCZyZHAtPmxvY2sp OworCiAgICAgLyogc2V0IGRlZmF1bHQgYWxsIHdvcmtpbmcgbW9kZSAqLwogICAgIHN0YXR1cyA9 IHJkcC0+c3RhdHVzOwogICAgIHJkcC0+c3RhdHVzICY9IH5BUl9TX0RFR1JBREVEOwpAQCAtOTEw LDYgKzkxNSwxMSBAQCBhdGFfcmFpZF9jb25maWdfY2hhbmdlZChzdHJ1Y3QgYXJfc29mdGMgCiAg ICAgfQogCiAgICAgaWYgKHJkcC0+c3RhdHVzICE9IHN0YXR1cykgeworCQorCS8qIHJhaWQgc3Rh dHVzIGhhcyBjaGFuZ2VkLCB1cGRhdGUgbWV0YWRhdGEgKi8KKwl3cml0ZWJhY2sgPSAxOworCisJ LyogYW5ub3VuY2Ugd2UgaGF2ZSB0cm91YmxlIGFoZWFkICovCiAJaWYgKCEocmRwLT5zdGF0dXMg JiBBUl9TX1JFQURZKSkgewogCSAgICBwcmludGYoImFyJWQ6IEZBSUxVUkUgLSAlcyBhcnJheSBi cm9rZW5cbiIsCiAJCSAgIHJkcC0+bHVuLCBhdGFfcmFpZF90eXBlKHJkcCkpOwpAQCAtMTY1OSw5 ICsxNjY5LDggQEAgYXRhX3JhaWRfYWRhcHRlY19yZWFkX21ldGEoZGV2aWNlX3QgZGV2LAogCWlm IChiZTMydG9oKG1ldGEtPmdlbmVyYXRpb24pID49IHJhaWQtPmdlbmVyYXRpb24pIHsKIAkgICAg c3RydWN0IGF0YV9kZXZpY2UgKmF0YWRldiA9IGRldmljZV9nZXRfc29mdGMocGFyZW50KTsKIAkg ICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoR1JBTkRQQVJFTlQo ZGV2KSk7Ci0JICAgIGludCBkaXNrX251bWJlciA9IChjaC0+dW5pdCA8PCAhKGNoLT5mbGFncyAm IEFUQV9OT19TTEFWRSkpICsKLQkJCSAgICAgIEFUQV9ERVYoYXRhZGV2LT51bml0KTsKLQorCSAg ICBpbnQgZGlza19udW1iZXIgPQorCQkoY2gtPnVuaXQgPDwgIShjaC0+ZmxhZ3MgJiBBVEFfTk9f U0xBVkUpKSArIGF0YWRldi0+dW5pdDsKIAkgICAgcmFpZC0+ZGlza3NbZGlza19udW1iZXJdLmRl diA9IHBhcmVudDsKIAkgICAgcmFpZC0+ZGlza3NbZGlza19udW1iZXJdLnNlY3RvcnMgPSAKIAkJ YmUzMnRvaChtZXRhLT5jb25maWdzW2Rpc2tfbnVtYmVyICsgMV0uc2VjdG9ycyk7CkBAIC0yMjcy LDExICsyMjgxLDE0IEBAIGF0YV9yYWlkX2ludGVsX3dyaXRlX21ldGEoc3RydWN0IGFyX3NvZnQK ICAgICB9CiAKICAgICByZHAtPmdlbmVyYXRpb24rKzsKLSAgICBtaWNyb3RpbWUoJnRpbWVzdGFt cCk7CisgICAgaWYgKCFyZHAtPm1hZ2ljXzApIHsKKwltaWNyb3RpbWUoJnRpbWVzdGFtcCk7CisJ cmRwLT5tYWdpY18wID0gdGltZXN0YW1wLnR2X3NlYyBeIHRpbWVzdGFtcC50dl91c2VjOworICAg IH0KIAogICAgIGJjb3B5KElOVEVMX01BR0lDLCBtZXRhLT5pbnRlbF9pZCwgc2l6ZW9mKG1ldGEt PmludGVsX2lkKSk7CiAgICAgYmNvcHkoSU5URUxfVkVSU0lPTl8xMTAwLCBtZXRhLT52ZXJzaW9u LCBzaXplb2YobWV0YS0+dmVyc2lvbikpOwotICAgIG1ldGEtPmNvbmZpZ19pZCA9IHRpbWVzdGFt cC50dl9zZWM7CisgICAgbWV0YS0+Y29uZmlnX2lkID0gcmRwLT5tYWdpY18wOwogICAgIG1ldGEt PmdlbmVyYXRpb24gPSByZHAtPmdlbmVyYXRpb247CiAgICAgbWV0YS0+dG90YWxfZGlza3MgPSBy ZHAtPnRvdGFsX2Rpc2tzOwogICAgIG1ldGEtPnRvdGFsX3ZvbHVtZXMgPSAxOyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC8qIFhYWCBTT1MgKi8KQEAgLTIyOTAsNyArMjMwMiw3 IEBAIGF0YV9yYWlkX2ludGVsX3dyaXRlX21ldGEoc3RydWN0IGFyX3NvZnQKIAkgICAgYmNvcHko YXRhZGV2LT5wYXJhbS5zZXJpYWwsIG1ldGEtPmRpc2tbZGlza10uc2VyaWFsLAogCQkgIHNpemVv ZihyZHAtPmRpc2tzW2Rpc2tdLnNlcmlhbCkpOwogCSAgICBtZXRhLT5kaXNrW2Rpc2tdLnNlY3Rv cnMgPSByZHAtPmRpc2tzW2Rpc2tdLnNlY3RvcnM7Ci0JICAgIG1ldGEtPmRpc2tbZGlza10uaWQg PSAoY2gtPnVuaXQgPDwgMTYpIHwgQVRBX0RFVihhdGFkZXYtPnVuaXQpOworCSAgICBtZXRhLT5k aXNrW2Rpc2tdLmlkID0gKGNoLT51bml0IDw8IDE2KSB8IGF0YWRldi0+dW5pdDsKIAl9CiAJZWxz ZQogCSAgICBtZXRhLT5kaXNrW2Rpc2tdLnNlY3RvcnMgPSByZHAtPnRvdGFsX3NlY3RvcnMgLyBy ZHAtPndpZHRoOwpAQCAtMzMxNSw3ICszMzI3LDcgQEAgYXRhX3JhaWRfcHJvbWlzZV93cml0ZV9t ZXRhKHN0cnVjdCBhcl9zbwogCQlkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRfcGFyZW50KHJk cC0+ZGlza3NbZGlza10uZGV2KSk7CiAKIAkgICAgbWV0YS0+cmFpZC5jaGFubmVsID0gY2gtPnVu aXQ7Ci0JICAgIG1ldGEtPnJhaWQuZGV2aWNlID0gQVRBX0RFVihhdGFkZXYtPnVuaXQpOworCSAg ICBtZXRhLT5yYWlkLmRldmljZSA9IGF0YWRldi0+dW5pdDsKIAkgICAgbWV0YS0+cmFpZC5kaXNr X3NlY3RvcnMgPSByZHAtPmRpc2tzW2Rpc2tdLnNlY3RvcnM7CiAJICAgIG1ldGEtPnJhaWQuZGlz a19vZmZzZXQgPSByZHAtPm9mZnNldF9zZWN0b3JzOwogCX0KQEAgLTM0MDMsNyArMzQxNSw3IEBA IGF0YV9yYWlkX3Byb21pc2Vfd3JpdGVfbWV0YShzdHJ1Y3QgYXJfc28KIAkJICAgIGRldmljZV9n ZXRfc29mdGMocmRwLT5kaXNrc1tkcml2ZV0uZGV2KTsKIAogCQltZXRhLT5yYWlkLmRpc2tbZHJp dmVdLmNoYW5uZWwgPSBjaC0+dW5pdDsKLQkJbWV0YS0+cmFpZC5kaXNrW2RyaXZlXS5kZXZpY2Ug PSBBVEFfREVWKGF0YWRldi0+dW5pdCk7CisJCW1ldGEtPnJhaWQuZGlza1tkcml2ZV0uZGV2aWNl ID0gYXRhZGV2LT51bml0OwogCSAgICB9CiAJICAgIG1ldGEtPnJhaWQuZGlza1tkcml2ZV0ubWFn aWNfMCA9CiAJCVBSX01BR0lDMChtZXRhLT5yYWlkLmRpc2tbZHJpdmVdKSB8IHRpbWVzdGFtcC50 dl9zZWM7CkBAIC0zNzI5LDcgKzM3NDEsNyBAQCBhdGFfcmFpZF9zaXNfd3JpdGVfbWV0YShzdHJ1 Y3QgYXJfc29mdGMgCiAJICAgIHN0cnVjdCBhdGFfY2hhbm5lbCAqY2ggPSAKIAkJZGV2aWNlX2dl dF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChyZHAtPmRpc2tzW2Rpc2tdLmRldikpOwogCSAgICBz dHJ1Y3QgYXRhX2RldmljZSAqYXRhZGV2ID0gZGV2aWNlX2dldF9zb2Z0YyhyZHAtPmRpc2tzW2Rp c2tdLmRldik7Ci0JICAgIGludCBkaXNrX251bWJlciA9IDEgKyBBVEFfREVWKGF0YWRldi0+dW5p dCkgKyAoY2gtPnVuaXQgPDwgMSk7CisJICAgIGludCBkaXNrX251bWJlciA9IDEgKyBhdGFkZXYt PnVuaXQgKyAoY2gtPnVuaXQgPDwgMSk7CiAKIAkgICAgbWV0YS0+ZGlza3MgfD0gZGlza19udW1i ZXIgPDwgKCgxIC0gZGlzaykgPDwgMik7CiAJfQpAQCAtMzc2Nyw3ICszNzc5LDcgQEAgYXRhX3Jh aWRfc2lzX3dyaXRlX21ldGEoc3RydWN0IGFyX3NvZnRjIAogCSAgICBiY29weShhdGFkZXYtPnBh cmFtLm1vZGVsLCBtZXRhLT5tb2RlbCwgc2l6ZW9mKG1ldGEtPm1vZGVsKSk7CiAKIAkgICAgLyog WFhYIFNPUyBpZiB0b3RhbF9kaXNrcyA+IDIgdGhpcyBtYXkgbm90IGZsb2F0ICovCi0JICAgIG1l dGEtPmRpc2tfbnVtYmVyID0gMSArIEFUQV9ERVYoYXRhZGV2LT51bml0KSArIChjaC0+dW5pdCA8 PCAxKTsKKwkgICAgbWV0YS0+ZGlza19udW1iZXIgPSAxICsgYXRhZGV2LT51bml0ICsgKGNoLT51 bml0IDw8IDEpOwogCiAJICAgIGlmICh0ZXN0aW5nIHx8IGJvb3R2ZXJib3NlKQogCQlhdGFfcmFp ZF9zaXNfcHJpbnRfbWV0YShtZXRhKTsKQEAgLTQwMTEsNyArNDAyMyw3IEBAIGF0YV9yYWlkX3Zp YV93cml0ZV9tZXRhKHN0cnVjdCBhcl9zb2Z0YyAKIH0KIAogc3RhdGljIHN0cnVjdCBhdGFfcmVx dWVzdCAqCi1hdGFfcmFpZF9pbml0X3JlcXVlc3Qoc3RydWN0IGFyX3NvZnRjICpyZHAsIHN0cnVj dCBiaW8gKmJpbykKK2F0YV9yYWlkX2luaXRfcmVxdWVzdChkZXZpY2VfdCBkZXYsIHN0cnVjdCBh cl9zb2Z0YyAqcmRwLCBzdHJ1Y3QgYmlvICpiaW8pCiB7CiAgICAgc3RydWN0IGF0YV9yZXF1ZXN0 ICpyZXF1ZXN0OwogCkBAIC00MDE5LDYgKzQwMzEsNyBAQCBhdGFfcmFpZF9pbml0X3JlcXVlc3Qo c3RydWN0IGFyX3NvZnRjICpyCiAJcHJpbnRmKCJGQUlMVVJFIC0gb3V0IG9mIG1lbW9yeSBpbiBh dGFfcmFpZF9pbml0X3JlcXVlc3RcbiIpOwogCXJldHVybiBOVUxMOwogICAgIH0KKyAgICByZXF1 ZXN0LT5kZXYgPSBkZXY7CiAgICAgcmVxdWVzdC0+dGltZW91dCA9IDU7CiAgICAgcmVxdWVzdC0+ cmV0cmllcyA9IDI7CiAgICAgcmVxdWVzdC0+Y2FsbGJhY2sgPSBhdGFfcmFpZF9kb25lOwotLS0g c3JjL3N5cy9kZXYvYXRhL2F0YS1yYWlkLmgJMjAwNy0wMi0yMSAyMjowNzoxOC4wMDAwMDAwMDAg KzAzMDAKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtcmFpZC5oCTIwMDgtMDQtMTAgMTc6MDU6MDUu MDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDIw MDAgLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAo YykgMjAwMCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKLS0tIHNyYy9zeXMvZGV2L2F0YS9hdGEt dXNiLmMJMjAwNy0wNi0yNCAwMTo1MjowNS4wMDAwMDAwMDAgKzA0MDAKKysrIHNyYy9zeXMvZGV2 L2F0YS9hdGEtdXNiLmMJMjAwOC0wNC0xMCAxNzowNTowNS4wMDAwMDAwMDAgKzA0MDAKQEAgLTEs NSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykgMjAwNiAtIDIwMDcgU/hyZW4gU2NobWlk dCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAyMDA2IC0gMjAwOCBT+HJlbiBT Y2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKICAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dApAQCAtMzYsNyArMzYsNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9zeXMv ZGV2L2F0YS9hdGEtCiAjaW5jbHVkZSA8c3lzL2F0YS5oPgogI2luY2x1ZGUgPHN5cy9idXMuaD4K ICNpbmNsdWRlIDxzeXMvZW5kaWFuLmg+Ci0jaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1 ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CiAjaW5jbHVkZSA8c3lz L3NlbWEuaD4KLS0tIHNyYy9zeXMvZGV2L2F0YS9hdGFfaWYubQkyMDA3LTA0LTA2IDIwOjE4OjU5 LjAwMDAwMDAwMCArMDQwMAorKysgc3JjL3N5cy9kZXYvYXRhL2F0YV9pZi5tCTIwMDgtMDQtMTAg MTc6MDU6MDUuMDAwMDAwMDAwICswNDAwCkBAIC0xLDQgKzEsNCBAQAotIyBDb3B5cmlnaHQgKGMp IDIwMDQgLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyMgQ29weXJpZ2h0 IChjKSAyMDA0IC0gMjAwOCBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAjIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCiAjCiAjIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YXBp LWNkLmMJMjAwNy0xMS0yMiAwMDoxNTowMC4wMDAwMDAwMDAgKzAzMDAKKysrIHNyYy9zeXMvZGV2 L2F0YS9hdGFwaS1jZC5jCTIwMDgtMDUtMDggMjE6NTU6NDQuMDAwMDAwMDAwICswNDAwCkBAIC0x LDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA3IFP4cmVuIFNjaG1p ZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDggU/hyZW4g U2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAg KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKQEAgLTY5Niw3ICs2OTYsNiBAQCBhY2RfZ2VvbV9hY2Nlc3Moc3RydWN0IGdf cHJvdmlkZXIgKnBwLCBpCiAKICAgICAvKiB3YWl0IGlmIGRyaXZlIGlzIG5vdCBmaW5pc2hlZCBs b2FkaW5nIHRoZSBtZWRpdW0gKi8KICAgICB3aGlsZSAodGltZW91dC0tKSB7Ci0JYnplcm8ocmVx dWVzdCwgc2l6ZW9mKHN0cnVjdCBhdGFfcmVxdWVzdCkpOwogCXJlcXVlc3QtPmRldiA9IGRldjsK IAliY29weShjY2IsIHJlcXVlc3QtPnUuYXRhcGkuY2NiLCAxNik7CiAJcmVxdWVzdC0+ZmxhZ3Mg PSBBVEFfUl9BVEFQSTsKQEAgLTkwNywxMSArOTA2LDExIEBAIGFjZF9zZXRfaW9wYXJtKGRldmlj ZV90IGRldikKIHsKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKICAgICBzdHJ1Y3QgYWNkX3NvZnRjICpjZHAgPSBk ZXZpY2VfZ2V0X2l2YXJzKGRldik7CisgICAgdWludDMyX3QgbWF4X2lvc2l6ZTsKIAotICAgIGlm IChjaC0+ZG1hKQotCWNkcC0+aW9tYXggPSBtaW4oY2gtPmRtYS0+bWF4X2lvc2l6ZSwgNjU1MzQp OwotICAgIGVsc2UKLQljZHAtPmlvbWF4ID0gbWluKERGTFRQSFlTLCA2NTUzNCk7CisgICAgbWF4 X2lvc2l6ZSA9IGNoLT5kbWEubWF4X2lvc2l6ZSA/IGNoLT5kbWEubWF4X2lvc2l6ZSA6IERGTFRQ SFlTOworCisgICAgY2RwLT5pb21heCA9IG1pbihtYXhfaW9zaXplLCA2NTUzNCk7CiB9CiAKIHN0 YXRpYyB2b2lkIApAQCAtMTcwNiw4ICsxNzA1LDcgQEAgYWNkX2Rlc2NyaWJlKGRldmljZV90IGRl dikKIAkJCShjZHAtPmNhcC5tZWRpYSAmIE1TVF9XUklURV9DRFJXKSA/ICJDRFJXIiA6CiAJCQkg KGNkcC0+Y2FwLm1lZGlhICYgTVNUX1dSSVRFX0NEUikgPyAiQ0RSIiA6IAogCQkJICAoY2RwLT5j YXAubWVkaWEgJiBNU1RfUkVBRF9EVkRST00pID8gIkRWRFJPTSI6IkNEUk9NIiwKLQkJICAgICAg ZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLAotCQkgICAgICAoYXRhZGV2LT51bml0ID09IEFUQV9N QVNURVIpID8gIm1hc3RlciIgOiAic2xhdmUiKTsKKwkJICAgICAgZGV2aWNlX2dldF91bml0KGNo LT5kZXYpLCBhdGFfdW5pdDJzdHIoYXRhZGV2KSk7CiAKIAlkZXZpY2VfcHJpbnRmKGRldiwgIiVz IiwgIiIpOwogCWlmIChjZHAtPmNhcC5jdXJfcmVhZF9zcGVlZCkgewpAQCAtMTg3OSw4ICsxODc3 LDcgQEAgYWNkX2Rlc2NyaWJlKGRldmljZV90IGRldikKIAkgICAgcHJpbnRmKCJ3aXRoICVkIENE IGNoYW5nZXIgIiwgY2RwLT5jaGFuZ2VyX2luZm8tPnNsb3RzKTsKIAlwcmludGYoIjwlLjQwcy8l LjhzPiBhdCBhdGElZC0lcyAlc1xuIiwKIAkgICAgICAgYXRhZGV2LT5wYXJhbS5tb2RlbCwgYXRh ZGV2LT5wYXJhbS5yZXZpc2lvbiwKLQkgICAgICAgZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLAot CSAgICAgICAoYXRhZGV2LT51bml0ID09IEFUQV9NQVNURVIpID8gIm1hc3RlciIgOiAic2xhdmUi LAorCSAgICAgICBkZXZpY2VfZ2V0X3VuaXQoY2gtPmRldiksIGF0YV91bml0MnN0cihhdGFkZXYp LAogCSAgICAgICBhdGFfbW9kZTJzdHIoYXRhZGV2LT5tb2RlKSApOwogICAgIH0KIH0KLS0tIHNy Yy9zeXMvZGV2L2F0YS9hdGFwaS1jZC5oCTIwMDctMTAtMzEgMjI6NTk6NTMuMDAwMDAwMDAwICsw MzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhcGktY2QuaAkyMDA4LTA0LTEwIDE3OjA1OjA1LjAw MDAwMDAwMCArMDQwMApAQCAtMSw1ICsxLDUgQEAKIC8qLQotICogQ29weXJpZ2h0IChjKSAxOTk4 IC0gMjAwNyBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CisgKiBDb3B5cmlnaHQgKGMp IDE5OTggLSAyMDA4IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KICAqIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0tLSBzcmMvc3lzL2Rldi9hdGEvYXRhcGkt ZmQuYwkyMDA3LTExLTIyIDAwOjE1OjAwLjAwMDAwMDAwMCArMDMwMAorKysgc3JjL3N5cy9kZXYv YXRhL2F0YXBpLWZkLmMJMjAwOC0wNS0wOCAyMTo1NTo0NC4wMDAwMDAwMDAgKzA0MDAKQEAgLTEs NSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykgMTk5OCAtIDIwMDcgU/hyZW4gU2NobWlk dCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwOCBT+HJlbiBT Y2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKICAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dApAQCAtMTA1LDEwICsxMDUsNyBAQCBhZmRfYXR0YWNoKGRldmljZV90IGRldikK ICAgICBmZHAtPmRpc2stPmRfaW9jdGwgPSBhZmRfaW9jdGw7CiAgICAgZmRwLT5kaXNrLT5kX25h bWUgPSAiYWZkIjsKICAgICBmZHAtPmRpc2stPmRfZHJ2MSA9IGRldjsKLSAgICBpZiAoY2gtPmRt YSkKLQlmZHAtPmRpc2stPmRfbWF4c2l6ZSA9IGNoLT5kbWEtPm1heF9pb3NpemU7Ci0gICAgZWxz ZQotCWZkcC0+ZGlzay0+ZF9tYXhzaXplID0gREZMVFBIWVM7CisgICAgZmRwLT5kaXNrLT5kX21h eHNpemUgPSBjaC0+ZG1hLm1heF9pb3NpemUgPyBjaC0+ZG1hLm1heF9pb3NpemUgOiBERkxUUEhZ UzsKICAgICBmZHAtPmRpc2stPmRfdW5pdCA9IGRldmljZV9nZXRfdW5pdChkZXYpOwogICAgIGRp c2tfY3JlYXRlKGZkcC0+ZGlzaywgRElTS19WRVJTSU9OKTsKICAgICByZXR1cm4gMDsKQEAgLTQw Niw4ICs0MDMsNyBAQCBhZmRfZGVzY3JpYmUoZGV2aWNlX3QgZGV2KQogIAogICAgIGRldmljZV9w cmludGYoZGV2LCAiJXMgPCUuNDBzICUuOHM+IGF0IGF0YSVkLSVzICVzXG4iLAogCQkgIHNpemVz dHJpbmcsIGF0YWRldi0+cGFyYW0ubW9kZWwsIGF0YWRldi0+cGFyYW0ucmV2aXNpb24sCi0JCSAg ZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLAotCQkgIChhdGFkZXYtPnVuaXQgPT0gQVRBX01BU1RF UikgPyAibWFzdGVyIiA6ICJzbGF2ZSIsCisJCSAgZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLCBh dGFfdW5pdDJzdHIoYXRhZGV2KSwKIAkJICBhdGFfbW9kZTJzdHIoYXRhZGV2LT5tb2RlKSk7CiAg ICAgaWYgKGJvb3R2ZXJib3NlKSB7CiAJZGV2aWNlX3ByaW50ZihkZXYsICIlanUgc2VjdG9ycyBb JWp1Qy8lZEgvJWRTXVxuIiwKLS0tIHNyYy9zeXMvZGV2L2F0YS9hdGFwaS1mZC5oCTIwMDctMDIt MjEgMjI6MDc6MTkuMDAwMDAwMDAwICswMzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhcGktZmQu aAkyMDA4LTA0LTEwIDE3OjA1OjA1LjAwMDAwMDAwMCArMDQwMApAQCAtMSw1ICsxLDUgQEAKIC8q LQotICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwNyBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJT RC5vcmc+CisgKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA4IFP4cmVuIFNjaG1pZHQgPHNvc0BG cmVlQlNELm9yZz4KICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRp b24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0t LSBzcmMvc3lzL2Rldi9hdGEvYXRhcGktdGFwZS5jCTIwMDctMTEtMjIgMDA6MTU6MDAuMDAwMDAw MDAwICswMzAwCisrKyBzcmMvc3lzL2Rldi9hdGEvYXRhcGktdGFwZS5jCTIwMDgtMDktMjcgMTI6 NTE6MTguMDAwMDAwMDAwICswNDAwCkBAIC0xLDUgKzEsNSBAQAogLyotCi0gKiBDb3B5cmlnaHQg KGMpIDE5OTggLSAyMDA3IFP4cmVuIFNjaG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KKyAqIENvcHly aWdodCAoYykgMTk5OCAtIDIwMDggU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgogICog QWxsIHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKQEAgLTE0MiwxOSArMTQyLDEz IEBAIGFzdF9hdHRhY2goZGV2aWNlX3QgZGV2KQogCQkgICAgICBVSURfUk9PVCwgR0lEX09QRVJB VE9SLCAwNjQwLCAiYXN0JWQiLAogCQkgICAgICBkZXZpY2VfZ2V0X3VuaXQoZGV2KSk7CiAgICAg ZGV2aWNlLT5zaV9kcnYxID0gZGV2OwotICAgIGlmIChjaC0+ZG1hKQotCWRldmljZS0+c2lfaW9z aXplX21heCA9IGNoLT5kbWEtPm1heF9pb3NpemU7Ci0gICAgZWxzZQotCWRldmljZS0+c2lfaW9z aXplX21heCA9IERGTFRQSFlTOworICAgIGRldmljZS0+c2lfaW9zaXplX21heCA9IGNoLT5kbWEu bWF4X2lvc2l6ZSA/IGNoLT5kbWEubWF4X2lvc2l6ZSA6IERGTFRQSFlTOwogICAgIHN0cC0+ZGV2 MSA9IGRldmljZTsKICAgICBkZXZpY2UgPSBtYWtlX2RldigmYXN0X2NkZXZzdywgMiAqIGRldmlj ZV9nZXRfdW5pdChkZXYpICsgMSwKIAkJICAgICAgVUlEX1JPT1QsIEdJRF9PUEVSQVRPUiwgMDY0 MCwgIm5hc3QlZCIsCiAJCSAgICAgIGRldmljZV9nZXRfdW5pdChkZXYpKTsKICAgICBkZXZpY2Ut PnNpX2RydjEgPSBkZXY7Ci0gICAgaWYgKGNoLT5kbWEpCi0JZGV2aWNlLT5zaV9pb3NpemVfbWF4 ID0gY2gtPmRtYS0+bWF4X2lvc2l6ZTsKLSAgICBlbHNlCi0JZGV2aWNlLT5zaV9pb3NpemVfbWF4 ID0gREZMVFBIWVM7CisgICAgZGV2aWNlLT5zaV9pb3NpemVfbWF4ID0gY2gtPmRtYS5tYXhfaW9z aXplOwogICAgIHN0cC0+ZGV2MiA9IGRldmljZTsKIAogICAgIC8qIGFubm91bmNlIHdlIGFyZSBo ZXJlIGFuZCByZWFkeSAqLwpAQCAtMjQ0LDcgKzIzOCw3IEBAIGFzdF9jbG9zZShzdHJ1Y3QgY2Rl diAqY2RldiwgaW50IGZsYWdzLCAKIAlhc3Rfd3JpdGVfZmlsZW1hcmsoZGV2LCBBVEFQSV9XRl9X UklURSk7CiAKICAgICAvKiBpZiBtaW5vciBpcyBldmVuIHJld2luZCBvbiBjbG9zZSAqLwotICAg IGlmICghKG1pbm9yKGNkZXYpICYgMHgwMSkpCisgICAgaWYgKCEoZGV2MnVuaXQoY2RldikgJiAw eDAxKSkKIAlhc3RfcmV3aW5kKGRldik7CiAKICAgICBpZiAoc3RwLT5jYXAubG9jayAmJiBjb3Vu dF9kZXYoY2RldikgPT0gMSkKQEAgLTY3OCw4ICs2NzIsNyBAQCBhc3RfZGVzY3JpYmUoZGV2aWNl X3QgZGV2KQogICAgIGlmIChib290dmVyYm9zZSkgewogCWRldmljZV9wcmludGYoZGV2LCAiPCUu NDBzLyUuOHM+IHRhcGUgZHJpdmUgYXQgYXRhJWQgYXMgJXNcbiIsCiAJCSAgICAgIGF0YWRldi0+ cGFyYW0ubW9kZWwsIGF0YWRldi0+cGFyYW0ucmV2aXNpb24sCi0JCSAgICAgIGRldmljZV9nZXRf dW5pdChjaC0+ZGV2KSwKLQkJICAgICAgKGF0YWRldi0+dW5pdCA9PSBBVEFfTUFTVEVSKSA/ICJt YXN0ZXIiIDogInNsYXZlIik7CisJCSAgICAgIGRldmljZV9nZXRfdW5pdChjaC0+ZGV2KSwgYXRh X3VuaXQyc3RyKGF0YWRldikpOwogCWRldmljZV9wcmludGYoZGV2LCAiJWRLQi9zLCAiLCBzdHAt PmNhcC5tYXhfc3BlZWQpOwogCXByaW50ZigidHJhbnNmZXIgbGltaXQgJWQgYmxrJXMsICIsCiAJ ICAgICAgIHN0cC0+Y2FwLmN0bCwgKHN0cC0+Y2FwLmN0bCA+IDEpID8gInMiIDogIiIpOwpAQCAt NzE3LDggKzcxMCw3IEBAIGFzdF9kZXNjcmliZShkZXZpY2VfdCBkZXYpCiAgICAgZWxzZSB7CiAJ ZGV2aWNlX3ByaW50ZihkZXYsICJUQVBFIDwlLjQwcy8lLjhzPiBhdCBhdGElZC0lcyAlc1xuIiwK IAkJICAgICAgYXRhZGV2LT5wYXJhbS5tb2RlbCwgYXRhZGV2LT5wYXJhbS5yZXZpc2lvbiwKLQkJ ICAgICAgZGV2aWNlX2dldF91bml0KGNoLT5kZXYpLAotCQkgICAgICAoYXRhZGV2LT51bml0ID09 IEFUQV9NQVNURVIpID8gIm1hc3RlciIgOiAic2xhdmUiLAorCQkgICAgICBkZXZpY2VfZ2V0X3Vu aXQoY2gtPmRldiksIGF0YV91bml0MnN0cihhdGFkZXYpLAogCQkgICAgICBhdGFfbW9kZTJzdHIo YXRhZGV2LT5tb2RlKSk7CiAgICAgfQogfQotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YXBpLXRhcGUu aAkyMDA3LTAyLTIxIDIyOjA3OjE5LjAwMDAwMDAwMCArMDMwMAorKysgc3JjL3N5cy9kZXYvYXRh L2F0YXBpLXRhcGUuaAkyMDA4LTA0LTEwIDE3OjA1OjA1LjAwMDAwMDAwMCArMDQwMApAQCAtMSw1 ICsxLDUgQEAKIC8qLQotICogQ29weXJpZ2h0IChjKSAxOTk4IC0gMjAwNyBT+HJlbiBTY2htaWR0 IDxzb3NARnJlZUJTRC5vcmc+CisgKiBDb3B5cmlnaHQgKGMpIDE5OTggLSAyMDA4IFP4cmVuIFNj aG1pZHQgPHNvc0BGcmVlQlNELm9yZz4KICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgogICog UmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBv ciB3aXRob3V0Ci0tLSBzcmMvc3lzL3N5cy9hdGEuaAkyMDA4LTA0LTA4IDEwOjQ4OjIxLjAwMDAw MDAwMCArMDAwMAorKysgc3JjL3N5cy9zeXMvYXRhLmgJMjAwOC0wNC0xMCAxMzowMToxNy4wMDAw MDAwMDAgKzAwMDAKQEAgLTEsNSArMSw1IEBACiAvKi0KLSAqIENvcHlyaWdodCAoYykgMjAwMCAt IDIwMDYgU/hyZW4gU2NobWlkdCA8c29zQEZyZWVCU0Qub3JnPgorICogQ29weXJpZ2h0IChjKSAy MDAwIC0gMjAwOCBT+HJlbiBTY2htaWR0IDxzb3NARnJlZUJTRC5vcmc+CiAgKiBBbGwgcmlnaHRz IHJlc2VydmVkLgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBi aW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dApAQCAtMjM5LDcgKzIzOSw3IEBAIHN0cnVjdCBh dGFfcGFyYW1zIHsKICNkZWZpbmUgQVRBX1JFQUQ0OCAgICAgICAgICAgICAgICAgICAgICAweDI0 ICAgIC8qIHJlYWQgNDhiaXQgTEJBICovCiAjZGVmaW5lIEFUQV9SRUFEX0RNQTQ4ICAgICAgICAg ICAgICAgICAgMHgyNSAgICAvKiByZWFkIERNQSA0OGJpdCBMQkEgKi8KICNkZWZpbmUgQVRBX1JF QURfRE1BX1FVRVVFRDQ4ICAgICAgICAgICAweDI2ICAgIC8qIHJlYWQgRE1BIFFVRVVFRCA0OGJp dCBMQkEgKi8KLSNkZWZpbmUgQVRBX1JFQURfTkFUSVZFX01BWF9BREREUkVTUzQ4ICAweDI3ICAg IC8qIHJlYWQgbmF0aXZlIG1heCBhZGRyIDQ4Yml0ICovCisjZGVmaW5lIEFUQV9SRUFEX05BVElW RV9NQVhfQUREUkVTUzQ4ICAgMHgyNyAgICAvKiByZWFkIG5hdGl2ZSBtYXggYWRkciA0OGJpdCAq LwogI2RlZmluZSBBVEFfUkVBRF9NVUw0OCAgICAgICAgICAgICAgICAgIDB4MjkgICAgLyogcmVh ZCBtdWx0aSA0OGJpdCBMQkEgKi8KICNkZWZpbmUgQVRBX1dSSVRFICAgICAgICAgICAgICAgICAg ICAgICAweDMwICAgIC8qIHdyaXRlICovCiAjZGVmaW5lIEFUQV9XUklURTQ4ICAgICAgICAgICAg ICAgICAgICAgMHgzNCAgICAvKiB3cml0ZSA0OGJpdCBMQkEgKi8KQEAgLTI2Nyw4ICsyNjcsMTAg QEAgc3RydWN0IGF0YV9wYXJhbXMgewogI2RlZmluZSBBVEFfU1RBTkRCWV9DTUQgICAgICAgICAg ICAgICAgIDB4ZTIgICAgLyogc3RhbmRieSAqLwogI2RlZmluZSBBVEFfSURMRV9DTUQgICAgICAg ICAgICAgICAgICAgIDB4ZTMgICAgLyogaWRsZSAqLwogI2RlZmluZSBBVEFfUkVBRF9CVUZGRVIg ICAgICAgICAgICAgICAgIDB4ZTQgICAgLyogcmVhZCBidWZmZXIgKi8KKyNkZWZpbmUgQVRBX1JF QURfUE0gICAgICAgICAgICAgICAgICAgICAweGU0ICAgIC8qIHJlYWQgcG9ydG11bHRpcGxpZXIg Ki8KICNkZWZpbmUgQVRBX1NMRUVQICAgICAgICAgICAgICAgICAgICAgICAweGU2ICAgIC8qIHNs ZWVwICovCiAjZGVmaW5lIEFUQV9GTFVTSENBQ0hFICAgICAgICAgICAgICAgICAgMHhlNyAgICAv KiBmbHVzaCBjYWNoZSB0byBkaXNrICovCisjZGVmaW5lIEFUQV9XUklURV9QTSAgICAgICAgICAg ICAgICAgICAgMHhlOCAgICAvKiB3cml0ZSBwb3J0bXVsdGlwbGllciAqLwogI2RlZmluZSBBVEFf RkxVU0hDQUNIRTQ4ICAgICAgICAgICAgICAgIDB4ZWEgICAgLyogZmx1c2ggY2FjaGUgdG8gZGlz ayAqLwogI2RlZmluZSBBVEFfQVRBX0lERU5USUZZICAgICAgICAgICAgICAgIDB4ZWMgICAgLyog Z2V0IEFUQSBwYXJhbXMgKi8KICNkZWZpbmUgQVRBX1NFVEZFQVRVUkVTICAgICAgICAgICAgICAg ICAweGVmICAgIC8qIGZlYXR1cmVzIGNvbW1hbmQgKi8KQEAgLTI4Miw3ICsyODQsNyBAQCBzdHJ1 Y3QgYXRhX3BhcmFtcyB7CiAjZGVmaW5lICAgICAgICAgQVRBX1NGX0VOQUJfU1JWSVJRICAgICAg MHg1ZSAgICAvKiBlbmFibGUgc2VydmljZSBpbnRlcnJ1cHQgKi8KICNkZWZpbmUgICAgICAgICBB VEFfU0ZfRElTX1NSVklSUSAgICAgICAweGRlICAgIC8qIGRpc2FibGUgc2VydmljZSBpbnRlcnJ1 cHQgKi8KICNkZWZpbmUgQVRBX1NFQ1VSSVRZX0ZSRUVFX0xPQ0sgICAgICAgICAweGY1ICAgIC8q IGZyZWV6ZSBzZWN1cml0eSBjb25maWcgKi8KLSNkZWZpbmUgQVRBX1JFQURfTkFUSVZFX01BWF9B REREUkVTUyAgICAweGY4ICAgIC8qIHJlYWQgbmF0aXZlIG1heCBhZGRyZXNzICovCisjZGVmaW5l IEFUQV9SRUFEX05BVElWRV9NQVhfQUREUkVTUyAgICAgMHhmOCAgICAvKiByZWFkIG5hdGl2ZSBt YXggYWRkcmVzcyAqLwogI2RlZmluZSBBVEFfU0VUX01BWF9BRERSRVNTICAgICAgICAgICAgIDB4 ZjkgICAgLyogc2V0IG1heCBhZGRyZXNzICovCiAKIAo= ------==--bound.67616.webmail38.yandex.ru-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 19:56:34 2008 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 7E2B1106568C for ; Sat, 4 Oct 2008 19:56:34 +0000 (UTC) (envelope-from eirik@nynorsk.no) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.248.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41B498FC13 for ; Sat, 4 Oct 2008 19:56:33 +0000 (UTC) (envelope-from eirik@nynorsk.no) Received: from proxy-gw.uib.no ([129.177.138.109] helo=dhcp-10-38-234.frydenbo.privnett.uib.no) by smtp.domeneshop.no with esmtpa (Exim 4.68) (envelope-from ) id 1KmCMt-0008Rj-HH for freebsd-stable@freebsd.org; Sat, 04 Oct 2008 21:00:43 +0200 Message-ID: <48E7BD60.80001@nynorsk.no> Date: Sat, 04 Oct 2008 21:00:48 +0200 From: =?ISO-8859-1?Q?Eirik_Wix=F8e_Svela?= User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Is FreeBSD a suitable choice for a MacBook? 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, 04 Oct 2008 19:56:34 -0000 I have an Apple MacBook with an Intel Core 2 Duo processor (November 2007 edition, cf. the Wikipedia article for specifications), and I have been considering switching to one of the free UNIX clones for some time now. I understand that Ubuntu GNU/Linux is supposed to work well on this kind of machine, but I would rather use some variant of BSD if that is a viable alternative. I would therefore like to ask you whether anyone here has any experience with FreeBSD, either 7.0-RELEASE or any other version, that they would like to share so I might know what to expect if I choose to go through with this. I have some time on my hands the next couple of weeks, so I am prepared to spend some days tweaking things to work if it is worth the effort, but if it isn't, I might as well take Ubuntu for a spin or do a clean install of Mac OS X. Best regards Eirik W. Svela OpenPGP key ID 0x46DCA4C4