From owner-freebsd-current@FreeBSD.ORG Sun May 17 01:47:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE06106566B for ; Sun, 17 May 2009 01:47:51 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3008FC13 for ; Sun, 17 May 2009 01:47:50 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by bwz9 with SMTP id 9so2581887bwz.43 for ; Sat, 16 May 2009 18:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=IIEwS/ozfsRrOTwDImKIPVk6eplBg9F9uUdqZ8b3/Kg=; b=XzuSrG4Je68MPexLLWxkInVB46dcC1u2qnsG/1CqMZ3K7cCsX3X9DAlyoN+/LrQrGl P244/Bm5fey5tZA63tnfxASEtlWlscIb+VbzlVePjOuddroKT9qnt+452GwAsd4HyCsu wxg9kEVDl3K02wjWO9XIsXyONwToYAHC44lbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=JPm5mkbC+KIVgF0v09ZFcI04z8x824y6gZGA+/1J7HI43G4/Z2OwMiE4yc9oQWBDky rejJtWwu7CMQYFo1gxgZPIAg6J39eODiA2/OiL+S0Ni365x+rrmowraM7XN0orxfgShu kpuLuCrxoxzvYKI3Q/37GwC3Ai5sX5ZbF0Gn4= MIME-Version: 1.0 Received: by 10.204.54.4 with SMTP id o4mr5071482bkg.10.1242524869074; Sat, 16 May 2009 18:47:49 -0700 (PDT) From: Scott Ullrich Date: Sat, 16 May 2009 21:47:28 -0400 Message-ID: To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Launching a CURSES based application on bootup and before getty launches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 01:47:51 -0000 Hello CURRENT, I am trying to launch a CURSES based program (BSDInstaller FrontEND http://cvs.bsdinstaller.org/cgi-bin/cvsweb.cgi/installer/src/frontends/ncurses/) prior to full system bootup. After launching the curses based program everything on the console seems to block. If I press CTRL-D then I see the curses based screen appear but the console is still blocked (does not accept keyboard input). Anyone have any pointers or suggestions? The ISO is available here if someone wants to give it a spin: http://cvs.pfsense.com/~sullrich/pfSense.iso The idea is being able to launch a recovery console (BSDInstaller option) to rescue config.xml from a failed hard disk and allow the system to use the newer config.xml on bootup in a LiveCD environment. Appreciate any help, comments, questions, etc. Thanks all, Scott From owner-freebsd-current@FreeBSD.ORG Sun May 17 02:25:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12DA1065672 for ; Sun, 17 May 2009 02:25:25 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 355908FC0A for ; Sun, 17 May 2009 02:25:24 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by bwz9 with SMTP id 9so2587622bwz.43 for ; Sat, 16 May 2009 19:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=HGBNUBnLlsuGoMRXV4CXPMfmwde5Icqxg96VBDdcbKQ=; b=f+mvHCug8tmPzwF1PNrk/t31vXwuFoJ9okzRQBtXz+IRQ2eRU/PuMLQMpTLpRY+Y0k 5cTrCp8XroPA36Ojl8m9Owk69M5xfqPqJZky+Qaelq1VyR6i1NzrIpo3dJ6DdLXpusGO /OeGZ9mrEAsJmcBz0cxJLg7yPwVSkFhHsixeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Eua+ErAEB9Yw9MoiGq4JSTG428d0dOwBxY1Sb1AnUue6Ibjbrw0sPZFAw/HOD/jR26 3NHnrHYV98shvYq0kBYrsnFLlADdCEifcUzDOJ2+M8TNZibMfiPnGz1KItvqHcriEQKG TfMmc+6pLDfRK5SvGYI9Dv4fwjY/XD9GTt+hY= MIME-Version: 1.0 Received: by 10.204.64.136 with SMTP id e8mr5109517bki.46.1242527122162; Sat, 16 May 2009 19:25:22 -0700 (PDT) In-Reply-To: References: From: Scott Ullrich Date: Sat, 16 May 2009 22:25:02 -0400 Message-ID: To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Launching a CURSES based application on bootup and before getty launches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 02:25:26 -0000 On Sat, May 16, 2009 at 9:47 PM, Scott Ullrich wrote: > Hello CURRENT, > > I am trying to launch a CURSES based program (BSDInstaller FrontEND > http://cvs.bsdinstaller.org/cgi-bin/cvsweb.cgi/installer/src/frontends/nc= urses/) > prior to full system bootup. > > After launching the curses based program everything on the console > seems to block. =A0 If I press CTRL-D then I see the curses based screen > appear but the console is still blocked (does not accept keyboard > input). > > Anyone have any pointers or suggestions? =A0The ISO is available here if > someone wants to give it a spin: > http://cvs.pfsense.com/~sullrich/pfSense.iso > > The idea is being able to launch a recovery console (BSDInstaller > option) to rescue config.xml from a failed hard disk and allow the > system to use the newer config.xml on bootup in a LiveCD environment. > > Appreciate any help, comments, questions, etc. > > Thanks all, > > Scott > Well it seems emailing this list brings good luck! Just resolved the issue and happy to say it was not FreeBSD's fault. Sorry for the noise. Scott From owner-freebsd-current@FreeBSD.ORG Sun May 17 07:19:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C80106564A; Sun, 17 May 2009 07:19:44 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 309298FC08; Sun, 17 May 2009 07:19:43 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from localhost.my.domain (ppp-93-104-126-3.dynamic.mnet-online.de [93.104.126.3]) by dd12710.kasserver.com (Postfix) with ESMTP id B4778183FB7F4; Sun, 17 May 2009 09:19:43 +0200 (CEST) Received: (from guru@localhost) by localhost.my.domain (8.14.3/8.14.3/Submit) id n4H9JlCp003017; Sun, 17 May 2009 09:19:47 GMT (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 17 May 2009 09:19:47 +0000 From: Matthias Apitz To: Alexander Motin Message-ID: <20090517091947.GA2887@current.Sisis.de> References: <1242469381.00112742.1242456003@10.7.7.3> <4A0F31F0.8090601@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A0F31F0.8090601@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: CURRENT && HDA Driver Revision: 20090401_0132 && no recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 07:19:45 -0000 El día Sunday, May 17, 2009 a las 12:36:48AM +0300, Alexander Motin escribió: > Matthias Apitz wrote: > >I can't get to work recording in environment -CURRENT && HDA Driver > >Revision: 20090401_0132 > > > >the sound output is fine in KDE, but as well the KDE mixer does > >not control it; only with mixer(1) command I can change the volume for > >example; I've already tried all values for setting > > > >$ mixer =rec rdev > > > >but nothing helps switching on the micro. The man page of snd_hda(4) > >explains a lot of device.hints(5) options, but understanding all this is > >out of my control; I'm attaching a 'dmesg | fgrep hdac'. > > > >Any idea how to get recording switched on? I need this for business for > >Skype... This is the last blocking point to switch over to my new Dell > >M4400 btw: I have now already moved all my userland to the M4400; > > You have 3 recording sources available via 2 pcm devices. As I can see, > your built-in mic assigned to pcm1 device. Have you tried to record from > pcm1? It was even more simple. I was only thinking that recording was not working because I could not hear my own voice while speaking in the headset (what I can hear for example in the EeePC 900 using snd_hda too); that's why I did not tried the Echo Service of Skype; later on I did tried it and it records fine from 'mic': # mixer Mixer vol is currently set to 83:83 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mix is currently set to 100:100 Mixer rec is currently set to 100:100 Recording source: mic > > PS: `dmesg | fgrep pcm` is also interesting. # dmesg | fgrep pcm pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 The last (non blocking) problem is to get support for the Wifi card: EMEA Intel Pro Wireless WI-FI 5100 (802.11a/g/ Draft-n) or replace it by some other card (the card is a plug-in card and can be changed by the user in the laptop). Thanks for your reply in any case. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Sun May 17 08:27:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E4F6106566B for ; Sun, 17 May 2009 08:27:20 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id B0F9E8FC0A for ; Sun, 17 May 2009 08:27:19 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 129E8EB57CD; Sun, 17 May 2009 11:00:11 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id C9CEE450D0; Sun, 17 May 2009 11:00:11 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xik4jnUzoWu6; Sun, 17 May 2009 11:00:11 +0300 (EEST) Received: from kobe.laptop (adsl86-220.kln.forthnet.gr [77.49.53.220]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 91376450C6; Sun, 17 May 2009 11:00:11 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n4H80Bpo025274; Sun, 17 May 2009 11:00:11 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n4H80AaA025265; Sun, 17 May 2009 11:00:10 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Paul B. Mahol" References: <608744.62543.qm@web63905.mail.re1.yahoo.com> <3a142e750905160518r173f421bw709ec54d5910c240@mail.gmail.com> Date: Sun, 17 May 2009 11:00:10 +0300 In-Reply-To: <3a142e750905160518r173f421bw709ec54d5910c240@mail.gmail.com> (Paul B. Mahol's message of "Sat, 16 May 2009 14:18:40 +0200") Message-ID: <87fxf4f9bp.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Barney Cordoba , current@freebsd.org Subject: Re: Can't boot new kernel build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 08:27:20 -0000 On Sat, 16 May 2009 14:18:40 +0200, "Paul B. Mahol" wrote: > On 5/16/09, Barney Cordoba wrote: >> I've built a new kernel and done a make install, and the system keeps > > # make installkernel KERNCONF=the_kernel KODIR=/boot/here_is_the_kernel FWIW, just KERNCONF=name should do :) From owner-freebsd-current@FreeBSD.ORG Sun May 17 10:27:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D46C71065670 for ; Sun, 17 May 2009 10:27:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 81EC78FC13 for ; Sun, 17 May 2009 10:27:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so4975423qyk.3 for ; Sun, 17 May 2009 03:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YHijb2mKqW1aaW/DTEzZ2Zlwi6Q/VOnYbFVjtAhzmJc=; b=M910B3s0l9NOxpYFYPFpj/mYLnKcaHObguqgnHWdJm2KwAMZyuyPMkyIzYM/G4yi6k zyjsCdT/oJ3+kRhyitGeUsqBbhuX1Jj5dR0K7pTJv6YqQZrmArMw10UWpeHLO4cSr6yg S9BPHDB37zJahLH7iKx7NIZqojxoLd4pwax9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=PDya255kpUlPOoKZOQb4glOYksThQr28Fz2ciDQ+eZwR07ZN1rmpOUTkDO3Pd1Dh7o UZJFpec/fPQyx525byUQ9m2a46TG8sbFMAZt8Xpr+RMfQGtIWX8k6chKvYUT8AufYAEX 071iQ/MU6KltuR+UZw8NCGizS0d9XJw1AXO/o= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.99.66 with SMTP id t2mr2818390qcn.38.1242556077731; Sun, 17 May 2009 03:27:57 -0700 (PDT) Date: Sun, 17 May 2009 18:27:57 +0800 X-Google-Sender-Auth: bab9bf51c8e0c23d Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Xen/FreeBSD-current issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 10:27:59 -0000 I've managed to build up a basic install of FreeBSD-current from yesterday under Xen. The kernel unfortunately panics on startup when the network interface is probed; it boots to completion fine when no interface is configured in the Xen config file. Configuration file: kernel = "/home/adrian/xen/kernel.current" memory = 256 name = "freebsd" vif = [ 'mac=00:bd:c4:12:00:ef,bridge=xenbr0' ] disk = [ 'phy:/dev/hosting2_data2/XEN_freebsd,hda,w' ] on_crash = 'preserve' extra = "boot_verbose=1" extra += ",vfs.root.mountfrom=ufs:/dev/ad0s1a" extra += ",kern.hz=100" Dmesg and stuff follows: [root@hosting-2 xen]# xm console freebsd WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sun May 17 09:43:08 UTC 2009 adrian@agnus.home.cacheboy.net:/home/adrian/work/freebsd/xen/obj/home/adrian/work/freebsd/xen/src/sys/XEN WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 1674.429 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1674.43-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0400800 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 268435456 (256 MB) Physical memory chunk(s): 0x00000000006aa000 - 0x000000000fb3bfff, 256450560 bytes (62610 pages) avail memory = 254377984 (242 MB) APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) ULE: setup cpu 0 cpu=0 irq=0 vector=0 cpu=0 irq=0 vector=1 Event-channel device installed. random: kbd0 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: io: Grant table initialized xenbus0: on motherboard xc0: on motherboard npx0: INT 16 interface Device configuration finished. procfs registered Timecounters tick every 10.000 msec lo0: bpf attached xbd0: 10240MB at device/vbd/768 on xenbus0 xbd0: attaching as ad0 GEOM: new disk ad0 xn0: at device/vif/0 on xenbus0 xn0: bpf attached xn0: Ethernet address: 00:bd:c4:12:00:ef WARNING: WITNESS option enabled, expect reduced performance. flowtable cleaner started Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex xennetif_rx (network receive lock) r = 0 (0xc18580b4) locked @ /home/adrian/work/freebsd/xen/src/sys/dev/xen/netfront/netfront.c:1123 KDB: stack backtrace: X_db_sym_numargs(c035ef81,cbe5daf0,c0111b25,c038262f,463,...) at X_db_sym_numargs+0x146 kdb_backtrace(c038262f,463,ffffffff,c05104fc,cbe5db28,...) at kdb_backtrace+0x29 witness_display_spinlock(c03613ca,cbe5db3c,4,1,0,...) at witness_display_spinlock+0x75 witness_warn(5,0,c038acd6,c17d8b00,c,...) at witness_warn+0x1fd trap(cbe5dbc4) at trap+0x13e alltraps(c1858000,cbe5dcc8,c00c3854,c03d4200,c175a738,...) at alltraps+0x1b intr_event_execute_handlers(c17097ec,c175a700,c03577af,4dd,c175a770,...) at intr_event_execute_handlers+0x125 intr_event_add_handler(c1768490,cbe5dd38,c03574ec,336,c17097ec,...) at intr_event_add_handler+0x41f fork_exit(c00afd10,c1768490,cbe5dd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xcbe5dd70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x21:0xc0301037 stack pointer = 0x29:0xcbe5dc04 frame pointer = 0x29:0xcbe5dca0 code segment = base 0x0, limit 0xf67ff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq134: xn) [thread pid 12 tid 100023 ] Stopped at xlvbd_add+0x3747: movl %edx,0(%esi) db> xccncheckc:155 xccncheckc:155 bt: Tracing pid 12 tid 100023 td 0xc175b000 xlvbd_add(c1858000,cbe5dcc8,c00c3854,c03d4200,c175a738,...) at xlvbd_add+0x3747 intr_event_execute_handlers(c17097ec,c175a700,c03577af,4dd,c175a770,...) at intr_event_execute_handlers+0x125 intr_event_add_handler(c1768490,cbe5dd38,c03574ec,336,c17097ec,...) at intr_event_add_handler+0x41f fork_exit(c00afd10,c1768490,cbe5dd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xcbe5dd70, ebp = 0 --- ps: pid ppid pgrp uid state wmesg wchan cmd 20 0 0 0 SL flowclea 0xc03d00e4 [flowcleaner] 19 0 0 0 SL sdflush 0xc05484e0 [softdepflush] 18 0 0 0 SL vlruwt 0xc18867ec [vnlru] 17 0 0 0 SL syncer 0xc053c750 [syncer] 16 0 0 0 SL psleep 0xc053c488 [bufdaemon] 9 0 0 0 SL pgzero 0xc0549164 [pagezero] 8 0 0 0 SL psleep 0xc0548d3c [vmdaemon] 7 0 0 0 SL psleep 0xc0548d04 [pagedaemon] 6 0 0 0 SL waiting_ 0xc053e5bc [sctp_iterator] 5 0 0 0 SL balloon 0xc02fc590 [balloon] 15 0 0 0 SL xbread 0xc0621000 [xenbus] 14 0 0 0 SL waitev 0xc054c000 [xenwatch] 13 0 0 0 SL - 0xc03d00e4 [yarrow] 4 0 0 0 SL - 0xc03cdea4 [g_down] 3 0 0 0 SL - 0xc03cdea0 [g_up] 2 0 0 0 RL [g_event] 12 0 0 0 RL (threaded) intr 100023 Run CPU 0 [irq134: xn] 100022 I [irq133: xbd] xccncheckc:155 100019 I [irq131: xencons] xccncheckc:155 100016 I [irq130: xenbus] 100015 I [swi6: Giant taskq] 100013 I [swi5: +] 100011 I [swi6: task queue] 100006 I [swi3: vm] 100005 I [swi1: net] 100004 I [swi4: clock] 11 0 0 0 RL [idle: cpu0] 1 0 0 0 SL g_waitid 0xc03cdde4 [kernel] 10 0 0 0 SL audit_wo 0xc0547e80 [audit] 0 0 0 0 SLs (threaded) kernel 100014 D - 0xc1747c80 [thread taskq] 100012 D - 0xc1747d40 [kqueue taskq] 100000 D sched 0xc03cdf40 [swapper] From owner-freebsd-current@FreeBSD.ORG Sun May 17 10:28:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E4EE10656A4 for ; Sun, 17 May 2009 10:28:05 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD8B8FC15 for ; Sun, 17 May 2009 10:28:05 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 632831D404; Sun, 17 May 2009 12:30:02 +0200 (CEST) Date: Sun, 17 May 2009 12:30:02 +0200 From: Ed Schouten To: Scott Ullrich Message-ID: <20090517103002.GB1271@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: Launching a CURSES based application on bootup and before getty launches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 10:28:06 -0000 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Scott, I'm a little lazy to experiment with your ISO, but I have two questions: - How are you launching the installer? /etc/rc? Is it a stripped down version of a FreeBSD install? If so, can you explain to me how the boot procedure works? - What version of FreeBSD are you using? Is it HEAD or RELENG_*? --=20 Ed Schouten WWW: http://80386.nl/ --V0207lvV8h4k8FAm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoP5yoACgkQ52SDGA2eCwUHbACfa8vvLSB/AARqf4ixuk0A2SXl PbkAn3Q8vOeDTghCpT56upUEfdk3PLJK =6/Ou -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From owner-freebsd-current@FreeBSD.ORG Sun May 17 11:00:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C76771065670; Sun, 17 May 2009 11:00:25 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5BF8FC14; Sun, 17 May 2009 11:00:25 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121] (may be forged)) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n4HB0JRh057996; Sun, 17 May 2009 20:00:24 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 17 May 2009 20:00:19 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org Message-Id: <20090517200019.275f6c71.nork@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Norikatsu Shigemura Subject: panic after dhclient in sys/net/if.c mtx_lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 11:00:26 -0000 Hi. I got a panic after dhclient like following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - <118>re0: no link ... <118>. <118> got link <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPACK from 192.168.36.1 <118> Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802bb31e stack pointer = 0x28:0xffffff80ec9167e0 frame pointer = 0x28:0xffffff80ec916800 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 542 (ifconfig) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - According to backtrace, I got following list: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8019306c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801933a1 in db_command (last_cmdp=0xffffffff8070c9a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801935f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff80195599 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff802f9000 in kdb_trap (type=12, code=0, tf=0xffffff80ec916730) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8049e29d in trap_fatal (frame=0xffffff80ec916730, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff8049e674 in trap_pfault (frame=0xffffff80ec916730, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #8 0xffffffff8049f0bf in trap (frame=0xffffff80ec916730) at /usr/src/sys/amd64/amd64/trap.c:494 #9 0xffffffff80478d33 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #10 0xffffffff802bb31e in _mtx_lock_sleep (m=0xffffff00050cae20, tid=18446742974297508528, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:340 #11 0xffffffff8036f4ad in ifaof_ifpforaddr (addr=0xffffffff806e4800, ifp=0xffffff00050caa00) at /usr/src/sys/net/if.c:1541 #12 0xffffffff8037b4d8 in rt_getifa_fib (info=0xffffff80ec9168d0, fibnum=0) at /usr/src/sys/net/route.c:745 #13 0xffffffff8037bc8d in rtrequest1_fib (req=Variable "req" is not available. ) at /usr/src/sys/net/route.c:1025 #14 0xffffffff8038650d in in_ifinit (ifp=Variable "ifp" is not available. ) at /usr/src/sys/netinet/in.c:921 #15 0xffffffff80387aeb in in_control (so=Variable "so" is not available. ) at /usr/src/sys/netinet/in.c:547 #16 0xffffffff80372d91 in ifioctl (so=0xffffff0005fa5510, cmd=2151704858, data=0xffffff000576bcc0 "re0", td=0xffffff0005ef8ab0) at /usr/src/sys/net/if.c:2226 #17 0xffffffff80307c1f in kern_ioctl (td=0xffffff0005ef8ab0, fd=Variable "fd" is not available. ) at file.h:262 #18 0xffffffff80307e51 in ioctl (td=0xffffff0005ef8ab0, uap=0xffffff80ec916c00) at /usr/src/sys/kern/sys_generic.c:677 #19 0xffffffff8049e8e7 in syscall (frame=0xffffff80ec916c90) at /usr/src/sys/amd64/amd64/trap.c:984 #20 0xffffffff80478fc0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #21 0x0000000800a6d19c in ?? () Previous frame inner to this frame (corrupt stack?) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So, I up 10 and print 'v' value: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (kgdb) up 10 #10 0xffffffff802bb31e in _mtx_lock_sleep (m=0xffffff00050cae20, tid=18446742974297508528, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:340 340 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) p v $1 = 0 (kgdb) p m $2 = (struct mtx *) 0xffffff00050cae20 (kgdb) p *m $3 = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In this time, mtx_lock == NULL. So more up: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (kgdb) up #11 0xffffffff8036f4ad in ifaof_ifpforaddr (addr=0xffffffff806e4800, ifp=0xffffff00050caa00) at /usr/src/sys/net/if.c:1541 1541 IF_ADDR_LOCK(ifp); (kgdb) p *ifp $4 = {if_softc = 0xffffff00050caa90, if_l2com = 0x0, if_vnet = 0xffffffff80393b30, if_link = {tqe_next = 0x0, tqe_prev = 0xffffffff80379700}, if_xname = "\000\000\000\000\000\000\000\000:9\200", if_dname = 0xffffffff80379f20 "UH\211H\211H\203 H\205H\211]L\211mH\211L\211eI\211u\025H\213]L\213eH\211L\213m$BO>(B\001", if_dunit = 0, if_refcount = 0, if_addrhead = {tqh_first = 0xffffffff803790a0, tqh_last = 0xffffffff80378f50}, if_klist = {kl_list = { slh_first = 0xffffffff80393700}, kl_lock = 0, kl_unlock = 0xffffff0005f49b20, kl_locked = 0x600ffdf, kl_lockarg = 0xffffff000516b180}, if_pcount = 0, if_carp = 0x0, if_bpf = 0x0, if_index = 43664, if_timer = 1292, if_vlantrunk = 0x6800020, if_flags = 4, if_capabilities = 0, if_capenable = 99916576, if_linkmib = 0xffffff000b1c8350, if_linkmiblen = 0, if_data = {ifi_type = 80 'P', ifi_physical = 131 '\203', ifi_addrlen = 28 '\034', ifi_hdrlen = 11 '\v', ifi_link_state = 0 '\0', ifi_spare_char1 = 255 '', ifi_spare_char2 = 255 '', ifi_datalen = 255 '', ifi_mtu = 100728799, ifi_metric = 18446742974283297180, ifi_baudrate = 0, ifi_ipackets = 0, ifi_ierrors = 1, ifi_opackets = 18446744071567800714, ifi_oerrors = 69926912, ifi_collisions = 0, ifi_ibytes = 1, ifi_obytes = 0, ifi_imcasts = 0, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, if_multiaddrs = {tqh_first = 0x0, tqh_last = 0x0}, if_amcount = 0, if_output = 0, if_input = 0, if_start = 0, if_ioctl = 0, if_watchdog = 0, if_init = 0, if_resolvemulti = 0, if_qflush = 0, if_transmit = 0, if_addr = 0x0, if_llsoftc = 0x0, if_drv_flags = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 0, ifq_drops = 0, ifq_mtx = {lock_object = {lo_name = 0x0, lo_flags = 84716688, lo_data = 4294967040, lo_witness = 0x0}, mtx_lock = 18446744071565818672}, ifq_drv_head = 0x0, ifq_drv_tail = 0xffffffff80379700, ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = -2143733008, altq_flags = -1, altq_disc = 0xffffffff80379f20, altq_ifp = 0x0, altq_enqueue = 0xffffffff803790a0 , altq_dequeue = 0xffffffff80378f50 , altq_request = 0xffffffff80393700 , altq_clfier = 0x0, altq_classify = 0xffffff0005f49be8, altq_tbr = 0x600ffdf, altq_cdnr = 0xffffff000516b180}, if_broadcastaddr = 0x0, if_bridge = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0xffffff00050cac90, tqh_last = 0x6800020}, if_afdata = {0x4, 0xffffff0005f49be8, 0xffffff000b1c8418, 0x0, 0xffffff000b1c8418, 0x600ffdf, 0xffffff000516b19c, 0x0, 0x0, 0x1, 0xffffffff8057798a, 0x42b0000, 0x0, 0xffffff0005ef8ab0, 0x0 }, if_afdata_initialized = 0, if_afdata_lock = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness = 0x0}, rw_lock = 0}, if_linktask = { ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0, ta_context = 0x0}, if_addr_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, if_clones = {le_next = 0x0, le_prev = 0x0}, if_groups = {tqh_first = 0x0, tqh_last = 0x0}, if_pf_kif = 0x0, if_lagg = 0x0, if_alloctype = 0 '\0', if_cspare = "\000\000", if_pspare = {0x0, 0x0, ---Type to continue, or q to quit--- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_ispare = {0, 0, 0, 0}} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sorry, I don't have any idea. Is above report OK? From owner-freebsd-current@FreeBSD.ORG Sun May 17 09:19:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9906106564A; Sun, 17 May 2009 09:19:04 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6318FC16; Sun, 17 May 2009 09:19:04 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4H8uQxB074884; Sun, 17 May 2009 10:56:26 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4H8uQwV074883; Sun, 17 May 2009 10:56:26 +0200 (CEST) (envelope-from byshenknet) Date: Sun, 17 May 2009 10:56:26 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090517085626.GD2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <3481d8e60905141449qfcf5da8r95d54281206304a4@mail.gmail.com> <3481d8e60905161016k3de535e3n9a570c5bee6ba517@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3481d8e60905161016k3de535e3n9a570c5bee6ba517@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-Mailman-Approved-At: Sun, 17 May 2009 11:29:45 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Benoit Calvez Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 09:19:05 -0000 On Sat, May 16, 2009 at 07:16:13PM +0200, Benoit Calvez wrote: > On Thu, May 14, 2009 at 11:49 PM, Benoit Calvez wrote: > > On Thu, May 14, 2009 at 9:12 PM, Martin Wilke wrote: > >> After the announcement from Alexander Eichner about > >> Virtualbox on FreeBSD, we started the work on a port > >> for FreeBSD. Now we think that we solved the most > >> problems and are ready for the first Call for Testing. > >> > >> Some notes before you can test the port: > >> Make sure you are using RELENG_7 or higher. You have > >> to use a fresh portstree with uptodate ports!! Please > >> read carefully the pkg-messages. > >> > >> Some known issues / Troubleshooting: > >> Sometimes the kernel on HEAD coredumps when loading > >> or unloading the kernel module. A small workaround > >> to prevent the crash is to not start X, mount proc, > >> then load the kernel module and start X from the > >> console. That helped me and some testers, maybe you > >> too. :P AMD64 should be work in general, it builds > >> and start. But not right tested at the moment. We > >> want here also some feedback. > >> > >> Some Thanks: > >> First of all we'd like to say many thanks to _ALL_ > >> vbox developers. Next people are Bernhard Froehlich > >> (aka decke), Beat Gaetzi (beat@), Dennis Herrmann > >> (dhn@), Pietro Cerutti (gahr@), myself (*gg*), > >> and _ALL_ who helped and provided feedback. > >> > >> Happy Testing :-) > >> > >> Download: > >> > >> http://people.freebsd.org/~miwi/vbox/vboxport.tgz > >> > >> Wiki Page: > >> http://wiki.freebsd.org/VirtualBox > >> > >> - Martin > > I'm trying to build from amd64, but got the following error. Sorry but I > > didn't look, and it's a fresh paste: > > [...] > I just tryed with the last tarball ( > http://people.freebsd.org/~miwi/vbox/virtualbox_1.tgz) and it compiles fine. > > the kernel module loads, and I'll try to boot an opensolaris in a few > moments. I've just tried with virtualbox_1.tgz, and it builds without a problem, the module installs without a problem, but attempting to start VirtualBox fails. I get no error at all, VirtualBox just hangs. If I attempt to run 'truss VirtualBox', I get the error: Effective UID is not root (euid=1001 egid=1001 uid=1001 gid=1001) (rc=-10) It may help to reinstall VirtualBox. But checking shows that VirtualBox is SUID root: $ ls -l /usr/local/lib/virtualbox/VirtualBox -r-s--x--x 1 root vboxusers 21016 May 17 10:21 /usr/local/lib/virtualbox/VirtualBox It seems that I can create a vm: $ VBoxManage createvm --name test VirtualBox Command Line Management Interface Version 2.2.51_OSE (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Virtual machine 'test' is created. UUID: 9be28271-55c2-4299-b69a-266c58716db7 Settings file: '/home/gbyshenk/.VirtualBox/Machines/test/test.xml' $ VirtualBox $ ls -l /home/gbyshenk/.VirtualBox/Machines/test/test.xml -rw------- 1 gbyshenk gbyshenk 2302 May 17 10:37 /home/gbyshenk/.VirtualBox/Machines/test/test.xml But VirtualBox itself fails to start -- even if I run as root. System is amd64, 7-STABLE as of 26-04-2009. Does it need to be more recent...? -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-current@FreeBSD.ORG Sun May 17 11:43:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA461065673; Sun, 17 May 2009 11:43:25 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 09A2E8FC08; Sun, 17 May 2009 11:43:24 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n4HBhMfw098077 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 11:43:23 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: svn-src-all@freebsd.org Date: Sun, 17 May 2009 11:43:20 +0000 User-Agent: KMail/1.11.2 (FreeBSD/8.0-CURRENT; KDE/4.2.3; amd64; ; ) References: <200905161048.n4GAmKRh057122@svn.freebsd.org> <200905161835.26281.ken@mthelicon.com> <6971FF74-A53E-4354-A7F5-9139A5F8E5D9@rabson.org> In-Reply-To: <6971FF74-A53E-4354-A7F5-9139A5F8E5D9@rabson.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905171143.21602.ken@mthelicon.com> Cc: svn-src-head@freebsd.org, Doug Rabson , src-committers@freebsd.org, current@freebsd.org Subject: Re: svn commit: r192194 - in head/sys: boot/i386/zfsboot boot/zfs cddl/boot/zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 11:43:26 -0000 On Saturday 16 May 2009 18:47:16 Doug Rabson wrote: > On 16 May 2009, at 19:35, Pegasus Mc Cleaft wrote: > > On Saturday 16 May 2009 10:48:20 Doug Rabson wrote: > >> Author: dfr > >> Date: Sat May 16 10:48:20 2009 > >> New Revision: 192194 > >> URL: http://svn.freebsd.org/changeset/base/192194 > >> > >> Log: > >> Add support for booting from raidz1 and raidz2 pools. > >> > >> Modified: > >> head/sys/boot/i386/zfsboot/zfsboot.c > >> head/sys/boot/zfs/zfsimpl.c > >> head/sys/cddl/boot/zfs/README > >> head/sys/cddl/boot/zfs/zfsimpl.h > >> head/sys/cddl/boot/zfs/zfssubr.c > > > > I think there may be a bug when you boot the machine from a drive > > that is a > > member of a zfs-mirror and you have raidz pools elsewhere. > > > > On reboot, I would get message saying there was no bootable kernel > > and > > dropped me down to the "OK" prompt. At that point, lsdev would show > > all the > > pools (both zfs-mirror and zraid's) and "ls" would return an error > > saying > > there were to many open files. > > > > I was able to work around the problem by pulling all the drives in > > the zraid > > pool into single user, attach all the drives and use atacontrol > > attach to > > bring them online before going to multi-user and hitting /etc/rc.d/ > > zfs start. > > > > The only thing I haven't tried, and may be the key to the problem is > > reloading the boot-strap on the bootable drives. Would that make any > > difference? > > I'm not sure but it can't hurt. The part of the bootstrap that runs > before /boot/loader (e.g. gptzfsboot) also has access to all the pools > in the system (at least the ones where the drives are visible to the > BIOS). It should figure out which pool contains the drive that was > actually booted and load /boot/loader from that. It should also pass > the identity of that pool down to /boot/loader so that the process > continues with the correct pool. > Naww.. Still no joy with that. I updated the boot drives with the latest gptzfsloader this morning and got the same results when I rebooted. System still thinks there are no loadable kernels until I remove all the zpool drives from the machine and reboot. Once I get the "BSD Daemon" screen and it starts to load the kernel, I can quicly slap the caddies back into the machine and they are detected when polled and everything is OK. I currently have the pools set up as follows: feathers$ zpool status pool: PegaBackup state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM PegaBackup ONLINE 0 0 0 ad10p4 ONLINE 0 0 0 errors: No known data errors pool: PegaBase state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM PegaBase ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad26 ONLINE 0 0 0 ad30 ONLINE 0 0 0 ad28 ONLINE 0 0 0 ad24 ONLINE 0 0 0 ad22 ONLINE 0 0 0 ad20 ONLINE 0 0 0 cache ad16p4 ONLINE 0 0 0 ad14p4 ONLINE 0 0 0 errors: No known data errors pool: PegaBoot2 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM PegaBoot2 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10p3 ONLINE 0 0 0 ad14p3 ONLINE 0 0 0 ad16p3 ONLINE 0 0 0 errors: No known data errors From owner-freebsd-current@FreeBSD.ORG Sun May 17 11:41:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48134106566B for ; Sun, 17 May 2009 11:41:51 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0CEA38FC16 for ; Sun, 17 May 2009 11:41:50 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from libero.it (192.168.17.9) by cp-out2.libero.it (8.5.107) id 4A0A85D1003D78E7 for freebsd-current@freebsd.org; Sun, 17 May 2009 13:30:48 +0200 Date: Sun, 17 May 2009 13:30:48 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "freebsd-current" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 87.11.236.164 X-Mailman-Approved-At: Sun, 17 May 2009 11:53:45 +0000 Subject: non-ATA66 cable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 11:41:51 -0000 # uname -a FreeBSD satanasso.local.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu May 1= 4 23:54:57 CEST 2009 root@satanasso.local.net:/usr/obj/usr/src/sys/SA= TANASSO i386 In my dmesg I have: atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x17= 7,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ... ad0: DMA limited to UDMA33, device found non-ATA66 cable ad0: 152627MB at ata0-master UDMA33 ... ad1: 117246MB at ata0-slave UDMA133 # atacontrol info ata0 Master: ad0 ATA/ATAPI revision 7 Slave: ad1 ATA/ATAPI revision 7 So why ad1 isn't limited too, being attached with the same cable? On 7-STABLE, I have: ad0: 152627MB at ata0-master UDMA100 Thanks. From owner-freebsd-current@FreeBSD.ORG Sun May 17 12:16:41 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF541065694; Sun, 17 May 2009 12:16:41 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121]) by mx1.freebsd.org (Postfix) with ESMTP id 851858FC12; Sun, 17 May 2009 12:16:41 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121] (may be forged)) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n4HCGZeh004492; Sun, 17 May 2009 21:16:40 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 17 May 2009 21:16:35 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org Message-Id: <20090517211635.216b23ae.nork@FreeBSD.org> In-Reply-To: <20090517200019.275f6c71.nork@FreeBSD.org> References: <20090517200019.275f6c71.nork@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Norikatsu Shigemura Subject: Re: panic after dhclient in sys/net/if.c mtx_lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 12:16:42 -0000 Hi. On Sun, 17 May 2009 20:00:19 +0900 Norikatsu Shigemura wrote: > ta_context = 0x0}, if_addr_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0, > lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, if_clones = {le_next = 0x0, In this time, if_addr_mtx doesn't initilized. According to /usr/src/sys/netinet/in.c:921 (UP#14), ifp = &info, So I read: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* * add a loopback route to self */ if (!(ifp->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT))) { bzero(&info, sizeof(info)); info.rti_ifp = V_loif; info.rti_flags = ia->ia_flags | RTF_HOST | RTF_STATIC; info.rti_info[RTAX_DST] = (struct sockaddr *)&ia->ia_addr; info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&null_sdl; error = rtrequest1_fib(RTM_ADD, &info, &rt, 0); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - info.rti_ifp == V_loif (=vnet_net_0._loif), but different: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (kgdb) p info.rti_ifp $16 = (struct ifnet *) 0xffffff00050caa00 (kgdb) p vnet_net_0._loif $17 = (struct ifnet *) 0xffffff0005172000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Of cource, V_loif->if_addr_mtx is initialized. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (kgdb) p vnet_net_0._loif->if_addr_mtx $18 = {lock_object = {lo_name = 0xffffffff80576ca1 "if_addr_mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hum..... From owner-freebsd-current@FreeBSD.ORG Sun May 17 12:54:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA39106564A; Sun, 17 May 2009 12:54:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2344D8FC12; Sun, 17 May 2009 12:54:13 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0E60D41C707; Sun, 17 May 2009 14:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id iFD8XRJFeYLr; Sun, 17 May 2009 14:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9428D41C732; Sun, 17 May 2009 14:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 27EE14448E6; Sun, 17 May 2009 12:31:37 +0000 (UTC) Date: Sun, 17 May 2009 12:31:37 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Norikatsu Shigemura In-Reply-To: <20090517211635.216b23ae.nork@FreeBSD.org> Message-ID: <20090517123008.B72053@maildrop.int.zabbadoz.net> References: <20090517200019.275f6c71.nork@FreeBSD.org> <20090517211635.216b23ae.nork@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: panic after dhclient in sys/net/if.c mtx_lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 12:54:14 -0000 On Sun, 17 May 2009, Norikatsu Shigemura wrote: Hi, thanks for the detailed analyses. We are aware of that problem and are looking for a fix. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sun May 17 13:04:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8E72106567A for ; Sun, 17 May 2009 13:04:40 +0000 (UTC) (envelope-from alleepsilonkleinereins@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBD28FC16 for ; Sun, 17 May 2009 13:04:40 +0000 (UTC) (envelope-from alleepsilonkleinereins@gmail.com) Received: by bwz9 with SMTP id 9so2720621bwz.43 for ; Sun, 17 May 2009 06:04: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 :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=7Ffq42xOb1V4MfH1IaGAKFmdsU0LyW/ot/jkpCoztCM=; b=jM8hLFdECPE6iAOCJo1HZ5F2yX87fNs/S2GptYWoDTjddAW3C61Nn6SoqBMm3RqnfS Z9rG884UpIzp4TmkVjGdGnKeY+SHrALGzqlDJCn+HFmKvaGznkNBScKjqnHfcxN4ulgV n6rayB8y/Op3rZhS93kZCwDZx8mA7beFVgZbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=vtc/HIupijpuptA8dW9kfwCidkqLPYUoLQCuqCZK5C3zsCna+9bc3IZkMk2+NBjLAT GW3T1aqJkoLcp2UPeFahw6Q2rehX7GQmsZUW4YtqTmKExsKhfS6oBTJ4NNAtpA1PLO9H hLm9siDfl38MKs5D6leivbI1LFU3hQ46o/1Ws= Received: by 10.204.67.66 with SMTP id q2mr5510710bki.161.1242563573695; Sun, 17 May 2009 05:32:53 -0700 (PDT) Received: from felix-stolbas-computer.local ([85.13.9.227]) by mx.google.com with ESMTPS id 13sm5436178fks.14.2009.05.17.05.32.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 05:32:53 -0700 (PDT) Message-ID: <4A1003EE.5010700@googlemail.com> Date: Sun, 17 May 2009 14:32:46 +0200 From: Felix Stolba User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: GELI Passphrase at boottime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 13:04:41 -0000 Hello, I guess this problem has persisted since 6.0 or probably earlier, at least this is where I encountered it first. The geli passphrase prompt (at boottime) doesn't detect keyboard input correctly, sometimes it will detect a key pressed, sometimes it won't etc. I know that disabling kbdmux helped with some people, here it doesn't change geli's behaviour. Also, having different keyboard mapping is out of the question. So, I helped myself with a little script in rc.conf: #!/bin/sh test -e /dev/ad0s2.eli if [ $? -ne 0 ] then geli attach /dev/ad0s2 fi Doing this plus removing the boot flag for the geli device did the trick, all input is detected when asked for passphrase. After being attached, the devices get checked for errors, fragmentation etc. and are mounted correctly as listed in /etc/fstab. Maybe this can help s/o with similiar problems. Felix From owner-freebsd-current@FreeBSD.ORG Sun May 17 13:48:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3851065672 for ; Sun, 17 May 2009 13:48:48 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id 28FE88FC20 for ; Sun, 17 May 2009 13:48:47 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by fxm12 with SMTP id 12so2758237fxm.43 for ; Sun, 17 May 2009 06:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=A3hcQL8hDNr5TtzPKKQNgfnInQtNJojwgIGeEf5t1/c=; b=ewrq9hKYppPcJV+Hm66vv9qaxIsE+pE1D4z/zccqHM7IEzJ6hcqAy58PU5FrCG8NeP mqlaKutW6u3ehxJSCmpasH5PSXoSLSo35Nj3OvpHiir4mc33PIIYSohLDu17TdkViDbQ Jsiy6Y324i4Eqgyq8lSnQ9mJ1C9FxTDl6/Qto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=m2brrd6mz3XUzfTGXz0jS9od33R7vX1bsCNwr2VPtyjW4/uY3N/OEH02qB/STyvZAt kUb/Ma1/BOsiZjjLxak6LwoSWY+Lfzo392mp70QakmX9CFjmL+J72xLImElCqD6QR8Ml nehXhns9mQSKiCI9DX4JsKKap3t3IXjqiXl0A= Received: by 10.103.160.9 with SMTP id m9mr3423918muo.96.1242566305847; Sun, 17 May 2009 06:18:25 -0700 (PDT) Received: from ?192.168.2.24? (p5486FB53.dip.t-dialin.net [84.134.251.83]) by mx.google.com with ESMTPS id 12sm835086muq.23.2009.05.17.06.18.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 06:18:25 -0700 (PDT) Message-ID: <4A100E9F.1020807@googlemail.com> Date: Sun, 17 May 2009 15:18:23 +0200 From: "army.of.root" User-Agent: Thunderbird 2.0.0.21 (X11/20090429) MIME-Version: 1.0 To: Felix Stolba References: <4A1003EE.5010700@googlemail.com> In-Reply-To: <4A1003EE.5010700@googlemail.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: GELI Passphrase at boottime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 13:48:49 -0000 Felix Stolba wrote: > Hello, > > I guess this problem has persisted since 6.0 or probably earlier, at > least this is where I encountered it first. > The geli passphrase prompt (at boottime) doesn't detect keyboard input > correctly, sometimes it > will detect a key pressed, sometimes it won't etc. > > I know that disabling kbdmux helped with some people, here it doesn't > change geli's behaviour. > Also, having different keyboard mapping is out of the question. > So, I helped myself with a little script in rc.conf: > > #!/bin/sh > test -e /dev/ad0s2.eli > if [ $? -ne 0 ] then > geli attach /dev/ad0s2 > fi > > Doing this plus removing the boot flag for the geli device did the > trick, all input is detected when asked for passphrase. > After being attached, the devices get checked for errors, fragmentation > etc. and are mounted correctly as listed in /etc/fstab. > > Maybe this can help s/o with similiar problems. > > Felix Hi, there is already a way to attach geli disks via the rc.conf: geli_devices="ad4" geli_ad4_flags="-k /boot/keys/ad4.key" regards From owner-freebsd-current@FreeBSD.ORG Sun May 17 14:33:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C6B1065680; Sun, 17 May 2009 14:33:54 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id 30DD48FC12; Sun, 17 May 2009 14:33:54 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail53.abv.bg (mail53.ni.bg [192.168.151.29]) by smtp-out.abv.bg (Postfix) with ESMTP id 256C287B64; Sun, 17 May 2009 17:16:37 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=Lmx7NW547QVCqK/ajTaOgqEmBwcK8ySvdGwBV0hUOdNzqLHtUUm0pjz0Lp8GJ5iRJ eV6FFUHNrRnoKXpOuKlLUDBMkhrWdR/NKvloZRhldR5uXVs7cmhGpNCW52SjqgmdvgO WILePWUrl7wSRLmuK1p3qlgE0VrNeOrEFX6aFMs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1242569797; bh=2kctKL6kjIfl74ejrWsFRju/QommEQpJc0Bcr2xCoC8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=bY3gtOboyyfc+g2nLLcgkgBoJplgflffg2mfZGLsoUmgzr0Esimhm0QC9MFxoX7HI bKy05oRolupwq2FUAJoxZdnRNARKdHNSe+4BjnPc8WQ+I1OAlZhAXe2Pm/zuwY/fHn sfK2ABAq8TkRp0KkSe12Oddce+htWZftpLctV9lU= Received: from mail53.abv.bg (localhost.localdomain [127.0.0.1]) by mail53.abv.bg (Postfix) with ESMTP id 3D36D1E4B0A; Sun, 17 May 2009 17:16:26 +0300 (EEST) Date: Sun, 17 May 2009 17:16:26 +0300 (EEST) From: Mario Pavlov To: freebsd-usb@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: Subject: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 14:33:59 -0000 Hi, I just got a CCID USB reader with my digital signature...unfortunately I can't make it work I installed pcsc-lite and libccid from ports... when I plug-in the reader I can see this: ugen0: on uhub4 then I do this: # pcscd -d -f 00000000 pcscdaemon.c:267:main() pcscd set to foreground with debug send to stderr 00000427 pcscdaemon.c:505:main() pcsc-lite 1.5.1 daemon ready. 00196162 hotplug_libusb.c:477:HPAddHotPluggable() Adding USB device: /dev/usb4:/dev/ugen0 00000043 readerfactory.c:1083:RFInitializeReader() Attempting startup of ACS ACR 38U-CCID 00 00 using /usr/local/lib/pcsc/drivers//ifd-ccid.bundle/Contents/FreeBSD/libccid.so 00000207 readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0 00000036 ifdhandler.c:1377:init_driver() Driver version: 1.3.9 00000285 ifdhandler.c:1390:init_driver() LogLevel: 0x0003 00000218 ifdhandler.c:1410:init_driver() DriverOptions: 0x0000 00000008 ifdhandler.c:81:IFDHCreateChannelByName() lun: 0, device: usb:072f/90cc:libusb:/dev/usb4:/dev/ugen0 00054635 ccid_usb.c:238:OpenUSBByName() Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr) 00000243 ccid_usb.c:248:OpenUSBByName() ProductString: Generic CCID driver 00000212 ccid_usb.c:254:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version. 00033042 ccid_usb.c:410:OpenUSBByName() Found Vendor/Product: 072F/90CC (ACS ACR 38U-CCID) 00000529 ccid_usb.c:412:OpenUSBByName() Using USB bus/device: /dev/usb4//dev/ugen0 00002242 ccid_usb.c:782:get_data_rates() IFD does not support GET_DATA_RATES request: Unknown error: 0 05104167 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 05104154 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 05103197 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 00000025 ifdhandler.c:122:IFDHCreateChannelByName() failed 00000058 readerfactory.c:1122:RFInitializeReader() Open Port 200000 Failed (usb:072f/90cc:libusb:/dev/usb4) 00000013 readerfactory.c:995:RFUnloadReader() Unloading reader driver. 00000065 readerfactory.c:249:RFAddReader() ACS ACR 38U-CCID init failed. apparently there is something wrong...looks like the ccid driver is trying to write to the USB device ? As far as I know you can't write to the reader, right ? And why is ccid trying to write at all ? I just plug-in the reader and start pcscd... Could you help me guys, I just need to use my digital signature with firefox... thank you Regards MGP P.S. # uname -a FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #5: Sat May 16 08:00:31 EEST 2009 myuser@home.mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE amd64 and ports from yesterday From owner-freebsd-current@FreeBSD.ORG Sun May 17 14:58:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53191065675; Sun, 17 May 2009 14:58:44 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 119E68FC16; Sun, 17 May 2009 14:58:43 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243010659; Sun, 17 May 2009 17:58:43 +0300 Message-ID: <4A10261B.5040601@FreeBSD.org> Date: Sun, 17 May 2009 17:58:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Matthias Apitz References: <1242469381.00112742.1242456003@10.7.7.3> <4A0F31F0.8090601@FreeBSD.org> <20090517091947.GA2887@current.Sisis.de> In-Reply-To: <20090517091947.GA2887@current.Sisis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: CURRENT && HDA Driver Revision: 20090401_0132 && no recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 14:58:45 -0000 Matthias Apitz wrote: > El día Sunday, May 17, 2009 a las 12:36:48AM +0300, Alexander Motin escribió: >> You have 3 recording sources available via 2 pcm devices. As I can see, >> your built-in mic assigned to pcm1 device. Have you tried to record from >> pcm1? > > It was even more simple. I was only thinking that recording was not > working because I could not hear my own voice while speaking in the > headset (what I can hear for example in the EeePC 900 using snd_hda > too); that's why I did not tried the Echo Service of Skype; later on I > did tried it and it records fine from 'mic': Some codecs (like mine ALC268) just unable to do echo in hardware. For some others, with recording from playback mixer, snd_hda just unable to configure such echo. Last could probably be fixed by adding some more logic to the parser, but I just don't see good reason for this, except probably just singing karaoke, which I don't like. :) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun May 17 17:08:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9D471065672 for ; Sun, 17 May 2009 17:08:15 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 940068FC12 for ; Sun, 17 May 2009 17:08:15 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n4HH8EML000893; Sun, 17 May 2009 10:08:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 17 May 2009 09:56:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: panic after dhclient in sys/net/if.c mtx_lock Thread-Index: AcnW3ssbJmoNTCX+RjCgtdNpjPU/CgAMPGQj References: <20090517200019.275f6c71.nork@FreeBSD.org> From: "Li, Qing" To: "Norikatsu Shigemura" , Cc: Subject: RE: panic after dhclient in sys/net/if.c mtx_lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 17:08:16 -0000 Hi, This is a known issue and is being actively investigated. There are 2 known crash instances related to this issue. As a workaround, include "VIMAGE_GLOBALS" in your kernel config file will resolve this issue (assuming you are not using VIMAGE). The problem is the V_loif interface pointer is reinitialized to another ifnet that is different from what V_loif is set to in "lo_clone_create()". -- Qing -----Original Message----- From: owner-freebsd-current@freebsd.org on behalf of Norikatsu Shigemura Sent: Sun 5/17/2009 4:00 AM To: freebsd-current@freebsd.org Cc: Norikatsu Shigemura Subject: panic after dhclient in sys/net/if.c mtx_lock =20 Hi. I got a panic after dhclient like following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - <118>re0: no link ... <118>. <118> got link <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPREQUEST on re0 to 255.255.255.255 port 67 <118> <118>DHCPACK from 192.168.36.1 <118> Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x288 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff802bb31e stack pointer =3D 0x28:0xffffff80ec9167e0 frame pointer =3D 0x28:0xffffff80ec916800 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 542 (ifconfig) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - According to backtrace, I got following list: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8019306c in db_fncall (dummy1=3DVariable "dummy1" is not = available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801933a1 in db_command (last_cmdp=3D0xffffffff8070c9a0, = cmd_table=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801935f0 in db_command_loop () at = /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff80195599 in db_trap (type=3DVariable "type" is not = available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff802f9000 in kdb_trap (type=3D12, code=3D0, = tf=3D0xffffff80ec916730) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8049e29d in trap_fatal (frame=3D0xffffff80ec916730, = eva=3DVariable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff8049e674 in trap_pfault (frame=3D0xffffff80ec916730, = usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:768 #8 0xffffffff8049f0bf in trap (frame=3D0xffffff80ec916730) at /usr/src/sys/amd64/amd64/trap.c:494 #9 0xffffffff80478d33 in calltrap () at = /usr/src/sys/amd64/amd64/exception.S:223 #10 0xffffffff802bb31e in _mtx_lock_sleep (m=3D0xffffff00050cae20,=20 tid=3D18446742974297508528, opts=3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:340 #11 0xffffffff8036f4ad in ifaof_ifpforaddr (addr=3D0xffffffff806e4800,=20 ifp=3D0xffffff00050caa00) at /usr/src/sys/net/if.c:1541 #12 0xffffffff8037b4d8 in rt_getifa_fib (info=3D0xffffff80ec9168d0, = fibnum=3D0) at /usr/src/sys/net/route.c:745 #13 0xffffffff8037bc8d in rtrequest1_fib (req=3DVariable "req" is not = available. ) at /usr/src/sys/net/route.c:1025 #14 0xffffffff8038650d in in_ifinit (ifp=3DVariable "ifp" is not = available. ) at /usr/src/sys/netinet/in.c:921 #15 0xffffffff80387aeb in in_control (so=3DVariable "so" is not = available. ) at /usr/src/sys/netinet/in.c:547 #16 0xffffffff80372d91 in ifioctl (so=3D0xffffff0005fa5510, = cmd=3D2151704858,=20 data=3D0xffffff000576bcc0 "re0", td=3D0xffffff0005ef8ab0) at = /usr/src/sys/net/if.c:2226 #17 0xffffffff80307c1f in kern_ioctl (td=3D0xffffff0005ef8ab0, = fd=3DVariable "fd" is not available. ) at file.h:262 #18 0xffffffff80307e51 in ioctl (td=3D0xffffff0005ef8ab0, = uap=3D0xffffff80ec916c00) at /usr/src/sys/kern/sys_generic.c:677 #19 0xffffffff8049e8e7 in syscall (frame=3D0xffffff80ec916c90) at /usr/src/sys/amd64/amd64/trap.c:984 #20 0xffffffff80478fc0 in Xfast_syscall () at = /usr/src/sys/amd64/amd64/exception.S:364 #21 0x0000000800a6d19c in ?? () Previous frame inner to this frame (corrupt stack?) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - So, I up 10 and print 'v' value: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - (kgdb) up 10 #10 0xffffffff802bb31e in _mtx_lock_sleep (m=3D0xffffff00050cae20,=20 tid=3D18446742974297508528, opts=3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:340 340 owner =3D (struct thread *)(v & = ~MTX_FLAGMASK); (kgdb) p v $1 =3D 0 (kgdb) p m $2 =3D (struct mtx *) 0xffffff00050cae20 (kgdb) p *m $3 =3D {lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0, lo_data =3D 0, = lo_witness =3D 0x0},=20 mtx_lock =3D 0} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - In this time, mtx_lock =3D=3D NULL. So more up: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - (kgdb) up #11 0xffffffff8036f4ad in ifaof_ifpforaddr (addr=3D0xffffffff806e4800,=20 ifp=3D0xffffff00050caa00) at /usr/src/sys/net/if.c:1541 1541 IF_ADDR_LOCK(ifp); (kgdb) p *ifp $4 =3D {if_softc =3D 0xffffff00050caa90, if_l2com =3D 0x0, if_vnet =3D = 0xffffffff80393b30,=20 if_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffffff80379700},=20 if_xname =3D "\000\000\000\000\000\000\000\000:9\200",=20 if_dname =3D 0xffffffff80379f20 "UH\211H\211H\203 = H\205H\211]L\211mH\211L\211eI\211u\025H\213]L\213eH\211L\213m?\001", = if_dunit =3D 0,=20 if_refcount =3D 0, if_addrhead =3D {tqh_first =3D 0xffffffff803790a0,=20 tqh_last =3D 0xffffffff80378f50}, if_klist =3D {kl_list =3D { slh_first =3D 0xffffffff80393700}, kl_lock =3D 0, kl_unlock =3D = 0xffffff0005f49b20,=20 kl_locked =3D 0x600ffdf, kl_lockarg =3D 0xffffff000516b180}, = if_pcount =3D 0,=20 if_carp =3D 0x0, if_bpf =3D 0x0, if_index =3D 43664, if_timer =3D = 1292,=20 if_vlantrunk =3D 0x6800020, if_flags =3D 4, if_capabilities =3D 0, = if_capenable =3D 99916576,=20 if_linkmib =3D 0xffffff000b1c8350, if_linkmiblen =3D 0, if_data =3D = {ifi_type =3D 80 'P',=20 ifi_physical =3D 131 '\203', ifi_addrlen =3D 28 '\034', ifi_hdrlen = =3D 11 '\v',=20 ifi_link_state =3D 0 '\0', ifi_spare_char1 =3D 255 '', = ifi_spare_char2 =3D 255 '',=20 ifi_datalen =3D 255 '', ifi_mtu =3D 100728799, ifi_metric =3D = 18446742974283297180,=20 ifi_baudrate =3D 0, ifi_ipackets =3D 0, ifi_ierrors =3D 1,=20 ifi_opackets =3D 18446744071567800714, ifi_oerrors =3D 69926912, = ifi_collisions =3D 0,=20 ifi_ibytes =3D 1, ifi_obytes =3D 0, ifi_imcasts =3D 0, ifi_omcasts = =3D 0, ifi_iqdrops =3D 0,=20 ifi_noproto =3D 0, ifi_hwassist =3D 0, ifi_epoch =3D 0, = ifi_lastchange =3D {tv_sec =3D 0,=20 tv_usec =3D 0}}, if_multiaddrs =3D {tqh_first =3D 0x0, tqh_last = =3D 0x0}, if_amcount =3D 0,=20 if_output =3D 0, if_input =3D 0, if_start =3D 0, if_ioctl =3D 0, = if_watchdog =3D 0, if_init =3D 0,=20 if_resolvemulti =3D 0, if_qflush =3D 0, if_transmit =3D 0, if_addr =3D = 0x0, if_llsoftc =3D 0x0,=20 if_drv_flags =3D 0, if_snd =3D {ifq_head =3D 0x0, ifq_tail =3D 0x0, = ifq_len =3D 0,=20 ifq_maxlen =3D 0, ifq_drops =3D 0, ifq_mtx =3D {lock_object =3D = {lo_name =3D 0x0,=20 lo_flags =3D 84716688, lo_data =3D 4294967040, lo_witness =3D = 0x0},=20 mtx_lock =3D 18446744071565818672}, ifq_drv_head =3D 0x0,=20 ifq_drv_tail =3D 0xffffffff80379700, ifq_drv_len =3D 0, = ifq_drv_maxlen =3D 0,=20 altq_type =3D -2143733008, altq_flags =3D -1, altq_disc =3D = 0xffffffff80379f20,=20 altq_ifp =3D 0x0, altq_enqueue =3D 0xffffffff803790a0 , = altq_dequeue =3D 0xffffffff80378f50 ,=20 altq_request =3D 0xffffffff80393700 , altq_clfier =3D = 0x0,=20 altq_classify =3D 0xffffff0005f49be8, altq_tbr =3D 0x600ffdf,=20 altq_cdnr =3D 0xffffff000516b180}, if_broadcastaddr =3D 0x0, = if_bridge =3D 0x0,=20 if_label =3D 0x0, if_prefixhead =3D {tqh_first =3D 0xffffff00050cac90, = tqh_last =3D 0x6800020}, if_afdata =3D {0x4, 0xffffff0005f49be8, = 0xffffff000b1c8418,=20 0x0, 0xffffff000b1c8418, 0x600ffdf, 0xffffff000516b19c, 0x0, 0x0, = 0x1,=20 0xffffffff8057798a, 0x42b0000, 0x0, 0xffffff0005ef8ab0, 0x0 },=20 if_afdata_initialized =3D 0, if_afdata_lock =3D {lock_object =3D = {lo_name =3D 0x0,=20 lo_flags =3D 0, lo_data =3D 0, lo_witness =3D 0x0}, rw_lock =3D = 0}, if_linktask =3D { ta_link =3D {stqe_next =3D 0x0}, ta_pending =3D 0, ta_priority =3D = 0, ta_func =3D 0,=20 ta_context =3D 0x0}, if_addr_mtx =3D {lock_object =3D {lo_name =3D = 0x0, lo_flags =3D 0,=20 lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}, if_clones =3D = {le_next =3D 0x0,=20 le_prev =3D 0x0}, if_groups =3D {tqh_first =3D 0x0, tqh_last =3D = 0x0}, if_pf_kif =3D 0x0,=20 if_lagg =3D 0x0, if_alloctype =3D 0 '\0', if_cspare =3D "\000\000", = if_pspare =3D {0x0, 0x0,=20 ---Type to continue, or q to quit--- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_ispare =3D {0, 0, 0, 0}} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - Sorry, I don't have any idea. Is above report OK? _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun May 17 17:34:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7117F106566B for ; Sun, 17 May 2009 17:34:05 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCA278FC19 for ; Sun, 17 May 2009 17:34:04 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 8852C1CC31; Sun, 17 May 2009 19:34:02 +0200 (CEST) Date: Sun, 17 May 2009 19:34:02 +0200 From: Michael Moll To: freebsd-current@freebsd.org Message-ID: <20090517173402.GI89114@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: padlock on amd64 does not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 17:34:05 -0000 Hi All, after migrating from i386 to amd64 on a VIA Nano, padlock is not working anymore. I use it to encrypt disks via GELI, this works fine when done in software: # /etc/rc.d/geli start Configuring Disk Encryption for ad4s1f. Enter passphrase: GEOM_ELI: Device ad4s1f.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software Now the same with the padlock module loaded: # kldload padlock padlock0: on motherboard # # /etc/rc.d/geli start Configuring Disk Encryption for ad4s1f. Enter passphrase: GEOM_ELI: Device ad4s1f.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: hardware fpudna in kernel mode! fpudna in kernel mode! fpudna in kernel mode! This message repeats forever. Any ideas on this one? Kind Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Sun May 17 18:09:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D6A1065672; Sun, 17 May 2009 18:09:25 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 26CC88FC1A; Sun, 17 May 2009 18:09:24 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 9553D4AC5D; Sun, 17 May 2009 20:09:20 +0200 (CEST) Date: Sun, 17 May 2009 20:09:20 +0200 From: Martin Wilke To: ports@FreeBSD.org Message-ID: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20090514191237.GD70242@bsdcrew.de> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 18:09:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We rolled a new tarball with the patch from Juergen Lock [1] with a posible fix for AMD64 users, tested on 3 machines which now works without problems. Many Thanks to him for his nice work! http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz Martin - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEARECAAYFAkoQUtAACgkQdLJIhLHm/OlY2QCg1KZW2YCvE1VhqKgSQ/xhjKIx U60Al2UMniKg+KvQ6m9RcP92eOMddfQ= =kB6c -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun May 17 18:46:28 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0F21065676; Sun, 17 May 2009 18:46:28 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 149338FC15; Sun, 17 May 2009 18:46:27 +0000 (UTC) (envelope-from bra@fsn.hu) Message-ID: <4A1057D2.5090800@fsn.hu> Date: Sun, 17 May 2009 20:30:42 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: current@FreeBSD.org, net@freebsd.org X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Sun, 17 May 2009 20:30:43 +0200 (CEST) Cc: Xin LI Subject: Routing related crash in -CURRENT, introduced between 5th May and yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 18:46:29 -0000 Hello, Somewhere between 5th May and yesterday there was a (routing related?) change, which causes this machine crash at boot: http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 The machine itself is an HP DL380G4 with bge interfaces and netbooted via PXE. A build, compiled on 5th May works fine, but this (compiled today, but with a yesterday build this is also the same) isn't. 7-STABLE also works fine on these kind of machines and this setup. Another interesting thing is while 7-STABLE (and from 5.x to 7-STABLE as of the start of May (that's the latest build we use, if there were bge related changes MFC-ed since that, I don't know)) can boot on this kind of machines with the default hw.bge.allow_asf=1, -CURRENT can't. It stops right after recognizing disk devices, even with verbose boot. That is the point, where DHCP (still netbooting) kicks in... I think these kind of machines are not rare (I admit that not everybody uses netbooting with them, but -CURRENT freezes even when installing from CD, when the installer tries to configure the interfaces), so it would be good to correct (and not MFC what is on HEAD until that) this regression. If I can do any debugging or give more information, please let me know! Thanks, From owner-freebsd-current@FreeBSD.ORG Sun May 17 18:59:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91EA4106564A for ; Sun, 17 May 2009 18:59:01 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4E32A8FC12 for ; Sun, 17 May 2009 18:59:00 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so1731580ywe.13 for ; Sun, 17 May 2009 11:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=9UiwPsmKRCkQHn2Q/OKbeuZNw0pSCwCd3VQyrbnk1W4=; b=qnGJ5exKTLo2uW1ZsvZ24cl3Z36raPLofWlJCJXq2YdHHF5xwrjU/IivHzzn5pZ1+P f9CgwVum4/KEohpPO4XfY0iBNEg1sRH4hbAph4W+RwtBtA1z9hFOVUT583xX/g1+CUNH Mym8QcM0IdE6EqZpWOaZt5vprhg0NPFdczrzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lakohHvjNugR7THoOYXP3HWYDGKA+pZUgGzXYzaGzxkYDvnY0BrDjpc07v5Uo6GRts CdM0SbC8I4ot9VE2DCk/VbQr87BfVUsE6sp3/g8pNeGDWeeJ1fzLcl/tzk0Qj0vof81V lZnXLmZnMCHc2vILdJ7yXyiEyIA//hcBFXXaU= MIME-Version: 1.0 Received: by 10.151.130.8 with SMTP id h8mr10660490ybn.247.1242586740398; Sun, 17 May 2009 11:59:00 -0700 (PDT) Date: Sun, 17 May 2009 20:59:00 +0200 Message-ID: <90a5caac0905171159g23198d7ej71afb349abe9ab79@mail.gmail.com> From: Lucius Windschuh To: current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: [lor] if_afdata and mld_mtx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 18:59:01 -0000 Hi. I didn't find this one in Bjoern's list: It happens when my uath device is pulled from its USB port while it is running. lock order reversal: 1st 0xc5a00214 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:990 2nd 0xc0b166a8 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:577 KDB: stack backtrace: db_trace_self_wrapper(c08fb92a,f3c4a9c0,c06693e5,c065b3db,c08fe70f,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065b3db,c08fe70f,c5109f38,c51059c0,f3c4aa1c,...) at kdb_backtrace+0x29 _witness_debugger(c08fe70f,c0b166a8,c08fe88b,c51059c0,c0910770,...) at _witness_debugger+0x25 witness_checkorder(c0b166a8,9,c0910770,241,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c0b166a8,0,c0910770,241,c8e79d40,...) at _mtx_lock_flags+0xc4 mld_domifdetach(c5a00000,c5a00214,c0968440,f3c4aac0,c06cf33c,...) at mld_domifdetach+0x2c in6_domifdetach(c5a00000,c8e79d40,3de,473,c5a00238,...) at in6_domifdetach+0x15 if_detach(c5a00000) at if_detach+0x8ec ether_ifdetach(c5a00000,0,c858f127,24a,c8aad014,...) at ether_ifdetach+0x3d ieee80211_vap_detach(c9133000,c09526a0,0,f3c4ab28,c06cff97,...) at ieee80211_vap_detach+0x191 uath_vap_delete(c9133000,c5a00000,c5a00000,c8592100,f3c4ab50,...) at uath_vap_delete+0x12 ifc_simple_destroy(c8592100,c5a00000,c0907832,d5,2d,...) at ifc_simple_destroy+0x27 if_clone_destroyif(c8592100,c5a00000,f3c4ab74,c8569f9c,c9133000,...) at if_clone_destroyif+0xe1 ieee80211_vap_destroy(c9133000,c84db00c,c84db000,f3c4ab9c,c84f23d8,...) at ieee80211_vap_destroy+0x1c ieee80211_ifdetach(c8aad000,f3c4ab94,c065b3db,c094ccb4,c5f44800,...) at ieee80211_ifdetach+0x1c uath_detach(c5fb9a00,c5ec3058,c094ccb4,9ed,c0651669,...) at uath_detach+0x48 device_detach(c5fb9a00,c08e2749,c5e2f2f0,2,2,...) at device_detach+0x8c usb2_detach_device(c5f4343c,0,c08e255a,187,18f29f2,...) at usb2_detach_device+0x178 usb2_unconfigure(c6790200,c0584830,c5eb82e0,7ba,0,...) at usb2_unconfigure+0x5a usb2_free_device(c5f43400,3,2,10,f3c4aca8,...) at usb2_free_device+0x1be uhub_explore(c5c05000,0,c08e10b0,cd,c58d8d34,...) at uhub_explore+0x2b2 usb2_bus_explore(c58d8d34,c58d8dac,c08ea550,51,c09a8e00,...) at usb2_bus_explore+0xbb usb2_process(c58d8cd4,f3c4ad38,c08f4097,336,c5be52a4,...) at usb2_process+0xde fork_exit(c058fde0,c58d8cd4,f3c4ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf3c4ad70, ebp = 0 --- From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:03:21 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057D21065672; Sun, 17 May 2009 19:03:21 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id B9EF08FC16; Sun, 17 May 2009 19:03:19 +0000 (UTC) (envelope-from bra@fsn.hu) Message-ID: <4A105F75.1000904@fsn.hu> Date: Sun, 17 May 2009 21:03:17 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: current@FreeBSD.org, net@freebsd.org References: <4A1057D2.5090800@fsn.hu> In-Reply-To: <4A1057D2.5090800@fsn.hu> X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Sun, 17 May 2009 21:03:18 +0200 (CEST) Cc: Xin LI Subject: Re: Routing related crash in -CURRENT, introduced between 5th May and yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:03:21 -0000 Attila Nagy wrote: > Hello, > > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 > > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 > > > The machine itself is an HP DL380G4 with bge interfaces and netbooted > via PXE. > > A build, compiled on 5th May works fine, but this (compiled today, but > with a yesterday build this is also the same) isn't. > > 7-STABLE also works fine on these kind of machines and this setup. > > Another interesting thing is while 7-STABLE (and from 5.x to 7-STABLE > as of the start of May (that's the latest build we use, if there were > bge related changes MFC-ed since that, I don't know)) can boot on this > kind of machines with the default hw.bge.allow_asf=1, -CURRENT can't. > It stops right after recognizing disk devices, even with verbose boot. > That is the point, where DHCP (still netbooting) kicks in... > > I think these kind of machines are not rare (I admit that not > everybody uses netbooting with them, but -CURRENT freezes even when > installing from CD, when the installer tries to configure the > interfaces), so it would be good to correct (and not MFC what is on > HEAD until that) this regression. > > If I can do any debugging or give more information, please let me know! I've found this: http://lists.freebsd.org/pipermail/svn-src-all/2009-May/008730.html which seems to be the place where the kernel dies according to the bt. I hope qingli will take care of it. And for the bge stuff, I've just noticed that allow_asf is off in 7-STABLE, so it's probably not a regression in code, but in behaviour. (which can be more easily fixed, but I don't know whether it worths to be on) From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:10:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA388106564A; Sun, 17 May 2009 19:10:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id B8E438FC12; Sun, 17 May 2009 19:10:47 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by fxm12 with SMTP id 12so2857759fxm.43 for ; Sun, 17 May 2009 12:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QHCQ5rHENOS44sQy0d/HgopwDoW9IZbeTcZVlbwGDEE=; b=QQNISyQBsg69mZ5xJpxbk2vHFjOZcrcGOJgBZWho5YGXvu83n0V9j+zYZHCZ/6tffM xvL7T20b7U80yRBpx/IXRc9zcyzzlLlORYIh56cmVLvEUP0pGAU3tVqoYWmmkV1bmlhP qAYGKY110Cou+xFSMOMkoefedeuBq69c0AiyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OVEavv8y/bYRD62erdZ8S9PC40u2xGnks//8GZL0SDaH2GRi3cmqs/TJn4SKSh47il Pl0mujiqStNIqfgJQGg701WxUeXyiZtuG9KHIObONneKuLYcIEIRv2f/nCcD+9KeT7k5 8RK1ulOEx3KJPqWNDhwpes4pLqBcdKOh6ZkBU= MIME-Version: 1.0 Received: by 10.239.164.83 with SMTP id s19mr407103hbd.110.1242587446579; Sun, 17 May 2009 12:10:46 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Sun, 17 May 2009 14:10:46 -0500 Message-ID: <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> From: "Sam Fourman Jr." To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:10:49 -0000 On Sun, May 17, 2009 at 1:09 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin Does this version still have the kernel module crashing at random on current? Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:14:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F8A106564A; Sun, 17 May 2009 19:14:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF1D8FC08; Sun, 17 May 2009 19:14:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C02FD41C6EA; Sun, 17 May 2009 20:55:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id eZ+LHDCXj6x0; Sun, 17 May 2009 20:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 60DA941C6BB; Sun, 17 May 2009 20:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B211A4448E6; Sun, 17 May 2009 18:52:55 +0000 (UTC) Date: Sun, 17 May 2009 18:52:55 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Attila Nagy In-Reply-To: <4A1057D2.5090800@fsn.hu> Message-ID: <20090517185206.S72053@maildrop.int.zabbadoz.net> References: <4A1057D2.5090800@fsn.hu> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Xin LI , FreeBSD current mailing list , net@freebsd.org Subject: Re: Routing related crash in -CURRENT, introduced between 5th May and yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:14:18 -0000 On Sun, 17 May 2009, Attila Nagy wrote: Hi, > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 > > The machine itself is an HP DL380G4 with bge interfaces and netbooted via > PXE. > > A build, compiled on 5th May works fine, but this (compiled today, but with a > yesterday build this is also the same) isn't. This one is known. People are working on it. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:18:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6AA4106566B; Sun, 17 May 2009 19:18:15 +0000 (UTC) (envelope-from lwindschuh@googlemail.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 4BDC98FC12; Sun, 17 May 2009 19:18:14 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so1735454ywe.13 for ; Sun, 17 May 2009 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=buGNP3cMvwRIhUMX6R3ehLFNa3cY8VDinqcra9TXQ1g=; b=N4kgIXPXWUJ74qpAODdpCHdlXmj5wH7spv9Stt9nurAerVN/gjtCWDkiEYrzl85i28 rOyr74oLDJcVvjy7EE5HtRxpdmedsBAyld90mV4vyMx5uX2X++/O814eUPOo4EQkB8GS QaBAjB0mJEt7He5kEkKwWautHEf7cefvgXFls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nt+yvv1rLydNs2q49D7T6iyx0T1nHAk+rp+Hztg1DQWIB3OIGtQpTvI49QdlFnczzl XVrwtrVTAWCiRNYrk2cDKLNAeLRNTGGSsbs+lZKew9/55+1xn2UFHyGmJMSMzBccBZwa 1Rtnf5eHbZ8DlAfyjMsMkRuD6rO5ooX1p3we4= MIME-Version: 1.0 Received: by 10.151.155.8 with SMTP id h8mr10627414ybo.308.1242587894510; Sun, 17 May 2009 12:18:14 -0700 (PDT) In-Reply-To: <4A0F419A.2020700@freebsd.org> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> Date: Sun, 17 May 2009 21:18:14 +0200 Message-ID: <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> From: Lucius Windschuh To: Sam Leffler Content-Type: multipart/mixed; boundary=0015175707f40df55e046a208abc Cc: Weongyo Jeong , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:18:15 -0000 --0015175707f40df55e046a208abc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/5/17 Sam Leffler : > Lucius Windschuh wrote: >> Thanks for porting the driver. > This is not a port of anyone else's driver. Sorry, my fault. I saw the comment in if_uath.c, but Damien's driver is very different, you are right. >> I tried it with a TRENDnet TEW-504UB/EU on CURRENT as of today. >> But there are a couple of problems with that device: >> 1. Different product ID >> My TEW-504UB/EU becomes 0x3207 after loading the firmware. OK, this one = is >> easy to fix: >> Index: sys/dev/usb/usbdevs >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/dev/usb/usbdevs (revision 192196) >> +++ sys/dev/usb/usbdevs (working copy) >> @@ -2425,6 +2425,7 @@ >> =A0product UMEDIA ALL0298V2 0x3204 ALL0298 v2 >> =A0product UMEDIA AR5523_2 0x3205 AR5523 >> =A0product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) >> +product UMEDIA AR5523_3 0x3207 AR5523 >> >> =A0/* Universal Access products */ >> =A0product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter >> Index: sys/dev/usb/wlan/if_uath.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/dev/usb/wlan/if_uath.c (revision 192196) >> +++ sys/dev/usb/wlan/if_uath.c (working copy) >> @@ -192,6 +192,7 @@ >> =A0 UATH_DEV(NETGEAR3, WPN111), >> =A0 UATH_DEV(UMEDIA, TEW444UBEU), >> =A0 UATH_DEV(UMEDIA, AR5523_2), >> + UATH_DEV(UMEDIA, AR5523_3), >> =A0 UATH_DEV(WISTRONNEWEB, AR5523_1), >> =A0 UATH_DEV(WISTRONNEWEB, AR5523_2), >> =A0 UATH_DEV(ZCOM, AR5523) >> >> I don't know why this device has another product ID with a loaded firmwa= re, >> but perhaps because it is an 802.11a capable device? > > The device works by changing identity once the firmware is downloaded. > One id is for the stick w/o fw and one for the stick w/ fw loaded and > running. I was a bit unclear, but what I meant to say: My device uses a different product ID in warm state (0x3207) than what the driver expects (0x3205). Interestingly, when booting the vendor's driver, the warm product ID is 0x3205. Anyway, with the extra ID, it works. >> >> So, now to the second problem: >> The device works like a charm in 802.11b/g mode (ifconfig wlan0 chanlist >> 1-13) with FreeBSD's firmware. >> But 802.11a scanning does not work. Without the chanlist restrictiong, I= get >> the following messages: >> (plug in the device) >> =A0 ugen4.2: at usbus4 >> (uathload) >> =A0 ugen4.2: at usbus4 (disconnected) >> =A0 ugen4.2: at usbus4 >> (ifconfig wlan create wlandev uath0) >> =A0 wlan0: Ethernet address: 00:14:d1:c0:23:5f >> (ifconfig wlan0 up) >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not init Tx queues, error 55 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not set channel, error 55 >> =A0 [...] >> =A0 uath0: could not set channel, error 55 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not write register 0x08 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not set channel, error 55 >> =A0 uath0: could not switch channel >> I'd like to provide additional debugging information. If you need more, >> please tell me what. > > Known problem. =A0Weongoy didn't have a dual-band stick and I never had > time to track down why 5Ghz channels failed. Set OFDM instead of no modulation when setting the 802.11a channel... See the attached mini patch. >> BTW: Could you add a message declaring the device when it is plugged in? >> Something like "uath0: on usbu= s?" >> and "uath0: ether aa:bb:cc:dd:ee:ff"? > > I thought it did this but perhaps not; we can try to add it. That would be nice. Unfortunately, I can provoke 3 different panics when detaching the running device. But this is sometimes mixed with data corruption on device removal -- on two different machines. I still have no clue which kernel part is guilty. More in a different mail to current@. Lucius --0015175707f40df55e046a208abc Content-Type: application/octet-stream; name="uath-11a-ofdm.patch" Content-Disposition: attachment; filename="uath-11a-ofdm.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fuu456340 SW5kZXg6IHN5cy9kZXYvdXNiL3dsYW4vaWZfdWF0aC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv dXNiL3dsYW4vaWZfdWF0aC5jCShyZXZpc2lvbiAxOTIxMDgpCisrKyBzeXMvZGV2L3VzYi93bGFu L2lmX3VhdGguYwkod29ya2luZyBjb3B5KQpAIC0xNDkyLDcgKzE0OTMsNyBAQAogCWlmIChJRUVF ODAyMTFfSVNfQ0hBTl81R0haKGMpKQogCQlyZXNldC5mbGFncyB8PSBodG9iZTMyKFVBVEhfQ0hB Tl81R0haKTsKIAkvKiBOQjogMTFnID0+J3MgMTFiIHNvIGRvbid0IHNwZWNpZnkgYm90aCBPRkRN IGFuZCBDQ0sgKi8KLQlpZiAoSUVFRTgwMjExX0lTX0NIQU5fRyhjKSkKKwlpZiAoSUVFRTgwMjEx X0lTX0NIQU5fRyhjKSB8fCBJRUVFODAyMTFfSVNfQ0hBTl9BKGMpKQogCQlyZXNldC5mbGFncyB8 PSBodG9iZTMyKFVBVEhfQ0hBTl9PRkRNKTsKIAllbHNlIGlmIChJRUVFODAyMTFfSVNfQ0hBTl9C KGMpKQogCQlyZXNldC5mbGFncyB8PSBodG9iZTMyKFVBVEhfQ0hBTl9DQ0spOwo= --0015175707f40df55e046a208abc-- From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:53:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6385106567C; Sun, 17 May 2009 19:53:46 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6E97E8FC1E; Sun, 17 May 2009 19:53:46 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4HJrj91035207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 12:53:46 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A106B49.4020809@freebsd.org> Date: Sun, 17 May 2009 12:53:45 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Lucius Windschuh References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> In-Reply-To: <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Weongyo Jeong , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:53:49 -0000 Lucius Windschuh wrote: > 2009/5/17 Sam Leffler : > >> Lucius Windschuh wrote: >> >>> Thanks for porting the driver. >>> >> This is not a port of anyone else's driver. >> > > Sorry, my fault. I saw the comment in if_uath.c, but Damien's driver > is very different, you are right. > > No problem; just trying to clarify since the history of this driver is complicated. >>> I tried it with a TRENDnet TEW-504UB/EU on CURRENT as of today. >>> But there are a couple of problems with that device: >>> 1. Different product ID >>> My TEW-504UB/EU becomes 0x3207 after loading the firmware. OK, this one is >>> easy to fix: >>> Index: sys/dev/usb/usbdevs >>> =================================================================== >>> --- sys/dev/usb/usbdevs (revision 192196) >>> +++ sys/dev/usb/usbdevs (working copy) >>> @@ -2425,6 +2425,7 @@ >>> product UMEDIA ALL0298V2 0x3204 ALL0298 v2 >>> product UMEDIA AR5523_2 0x3205 AR5523 >>> product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) >>> +product UMEDIA AR5523_3 0x3207 AR5523 >>> >>> /* Universal Access products */ >>> product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter >>> Index: sys/dev/usb/wlan/if_uath.c >>> =================================================================== >>> --- sys/dev/usb/wlan/if_uath.c (revision 192196) >>> +++ sys/dev/usb/wlan/if_uath.c (working copy) >>> @@ -192,6 +192,7 @@ >>> UATH_DEV(NETGEAR3, WPN111), >>> UATH_DEV(UMEDIA, TEW444UBEU), >>> UATH_DEV(UMEDIA, AR5523_2), >>> + UATH_DEV(UMEDIA, AR5523_3), >>> UATH_DEV(WISTRONNEWEB, AR5523_1), >>> UATH_DEV(WISTRONNEWEB, AR5523_2), >>> UATH_DEV(ZCOM, AR5523) >>> >>> I don't know why this device has another product ID with a loaded firmware, >>> but perhaps because it is an 802.11a capable device? >>> >> The device works by changing identity once the firmware is downloaded. >> One id is for the stick w/o fw and one for the stick w/ fw loaded and >> running. >> > > I was a bit unclear, but what I meant to say: My device uses a > different product ID in warm state (0x3207) than what the driver > expects (0x3205). Interestingly, when booting the vendor's driver, the > warm product ID is 0x3205. Anyway, with the extra ID, it works. > Ok, r192258. > >>> So, now to the second problem: >>> The device works like a charm in 802.11b/g mode (ifconfig wlan0 chanlist >>> 1-13) with FreeBSD's firmware. >>> But 802.11a scanning does not work. Without the chanlist restrictiong, I get >>> the following messages: >>> (plug in the device) >>> ugen4.2: at usbus4 >>> (uathload) >>> ugen4.2: at usbus4 (disconnected) >>> ugen4.2: at usbus4 >>> (ifconfig wlan create wlandev uath0) >>> wlan0: Ethernet address: 00:14:d1:c0:23:5f >>> (ifconfig wlan0 up) >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not init Tx queues, error 55 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not set channel, error 55 >>> [...] >>> uath0: could not set channel, error 55 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not write register 0x08 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not set channel, error 55 >>> uath0: could not switch channel >>> I'd like to provide additional debugging information. If you need more, >>> please tell me what. >>> >> Known problem. Weongoy didn't have a dual-band stick and I never had >> time to track down why 5Ghz channels failed. >> > > Set OFDM instead of no modulation when setting the 802.11a channel... > See the attached mini patch. > Great, thank you; committed as r192257 w/ a slight tweak. > >>> BTW: Could you add a message declaring the device when it is plugged in? >>> Something like "uath0: on usbus?" >>> and "uath0: ether aa:bb:cc:dd:ee:ff"? >>> >> I thought it did this but perhaps not; we can try to add it. >> > > That would be nice. > > Unfortunately, I can provoke 3 different panics when detaching the > running device. > But this is sometimes mixed with data corruption on device removal -- > on two different machines. > I still have no clue which kernel part is guilty. More in a different > mail to current@. > > I saw your other post; looks like it's outside net80211 so will let someone else handle it. Sam From owner-freebsd-current@FreeBSD.ORG Sun May 17 20:07:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E59D1065677; Sun, 17 May 2009 20:07:14 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 95D1F8FC24; Sun, 17 May 2009 20:07:13 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by mail-ew0-f159.google.com with SMTP id 3so3485005ewy.43 for ; Sun, 17 May 2009 13:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=FVkp8Co0WWMOXBsRAUECuR2mGS95pZlrjxr+3DSp4xQ=; b=fd65rrA7A6udwEETlsginKfFUGGgmC4z+/vSsJAozLODvnf4GqVitWwwW230D1q4lL JAd3OsvCBcDIYRhBo/hh/7BPA7vkNct454DzvYkQpximKZPPZThhZIQILkAsLthmFYNB Id4xBgij252Gs5iXNk5SnYc7u+i0V2w1gmZvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ulpA0C7p7BBB1sRJOu9QEPiupoU1QpVz/1PJyJi9V4H5l+CcR7K94Npg/E3Qesqq7w 3aM9AamoGk1E6qzS3h5fLR5Hei1tHNR8FYa8TOCphHZFUPTbcUxtWviz5k3TcAzRtuCP Y2NTrKYYjH0ZRguZTcBFSjgj9NN51hgxPVQ58= MIME-Version: 1.0 Sender: dzentoo@gmail.com Received: by 10.210.58.17 with SMTP id g17mr3577298eba.4.1242590833160; Sun, 17 May 2009 13:07:13 -0700 (PDT) In-Reply-To: <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> From: Benoit Calvez Date: Sun, 17 May 2009 22:06:52 +0200 X-Google-Sender-Auth: 65b21173f2ff3412 Message-ID: <3481d8e60905171306n35904a6boc74eed344505cb13@mail.gmail.com> To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 20:07:15 -0000 On Sun, May 17, 2009 at 9:10 PM, Sam Fourman Jr. wrote: > On Sun, May 17, 2009 at 1:09 PM, Martin Wilke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > We rolled a new tarball with the patch from Juergen Lock [1] > > with a posible fix for AMD64 users, tested on 3 machines > > which now works without problems. Many Thanks to him for > > his nice work! > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > > > Martin > > Does this version still have the kernel module crashing at random on > current? > > Sam Fourman Jr. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I uninstalled the last virtualbox (from virtualbox_1.tgz port). It compiled fine and I could start an opensolaris vm. It crashed cauz' I created the virtual hard drive in a smal partition. Since then I couldn't restart the vm. I got two Errors: "Kernel driver not instaled (rc =-1908) "Make sure the kernel module has beed loaded successfully" Sure it is. the other one is : Result Code: NS_ERROR_FAILURE (0x80004005) Component: Machine Interface: IMachine {4d1df26d-d9c1-4c7e-b689-15e85ecf8ffc} I could give more informations if needed -- Benoit C. From owner-freebsd-current@FreeBSD.ORG Sun May 17 20:22:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BFE81065672 for ; Sun, 17 May 2009 20:22:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B725F8FC0C for ; Sun, 17 May 2009 20:22:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M5msY-0000Zl-35 for freebsd-current@freebsd.org; Sun, 17 May 2009 20:22:38 +0000 Received: from 93-138-53-171.adsl.net.t-com.hr ([93.138.53.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 May 2009 20:22:38 +0000 Received: from ivoras by 93-138-53-171.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 May 2009 20:22:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 17 May 2009 22:22:26 +0200 Lines: 30 Message-ID: References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> <3481d8e60905171306n35904a6boc74eed344505cb13@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-53-171.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.19 (X11/20090222) In-Reply-To: <3481d8e60905171306n35904a6boc74eed344505cb13@mail.gmail.com> Sender: news Cc: freebsd-emulation@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 20:22:40 -0000 Benoit Calvez wrote: > > I uninstalled the last virtualbox (from virtualbox_1.tgz port). It compiled > fine and I could start an opensolaris vm. > It crashed cauz' I created the virtual hard drive in a smal partition. Since > then I couldn't restart the vm. > I got two Errors: > > "Kernel driver not instaled (rc =-1908) > "Make sure the kernel module has beed loaded successfully" > > Sure it is. > > the other one is : > > > Result Code: > > NS_ERROR_FAILURE (0x80004005) > > Component: > > Machine > > Interface: > > IMachine {4d1df26d-d9c1-4c7e-b689-15e85ecf8ffc} Same here, AMD64, 8-CURRENT. From owner-freebsd-current@FreeBSD.ORG Sun May 17 20:32:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25CBA106566C for ; Sun, 17 May 2009 20:32:00 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id A80038FC19 for ; Sun, 17 May 2009 20:31:59 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by fxm12 with SMTP id 12so2884491fxm.43 for ; Sun, 17 May 2009 13:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=HowBhK3SuLBCgTfbrbzIURcERiXTvwWvDGi+00Tt6k8=; b=uIH5uJOjnrh4C2iJz15VNbWIFOo2wc8MZjWyZGj46YiUfFrzLj4xE9/smanCCj9BYE qbpHorZKaLUfRlQ/F/EvZnjffu5tem9jBRX55NBzmkipMyyX/clvFDoryrit61OZAYRf O7byciBsaHMZOa7UPNXwG2BQZxMxo6IYWHx9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vXHdyVxeiwSVkGV9yqbx0PdBP0uMoSHPk5hR90mhi/ZD+n3xB1kYlqXnYxBis41FAC gVMBUYBq2+Kc0ifwt99zj1+WTLcWGx85RHp86/DV7bUphNxyOAsnfx5cdPGrFqf3v0aE mPC7pLRj60zuvFxVx8/WQAZNhdZubZHPhn9EQ= MIME-Version: 1.0 Received: by 10.204.116.9 with SMTP id k9mr5900143bkq.159.1242592318326; Sun, 17 May 2009 13:31:58 -0700 (PDT) In-Reply-To: <20090517103002.GB1271@hoeg.nl> References: <20090517103002.GB1271@hoeg.nl> From: Scott Ullrich Date: Sun, 17 May 2009 16:31:38 -0400 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Launching a CURSES based application on bootup and before getty launches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 20:32:00 -0000 On Sun, May 17, 2009 at 6:30 AM, Ed Schouten wrote: > Hi Scott, > > I'm a little lazy to experiment with your ISO, but I have two questions: > > - How are you launching the installer? /etc/rc? Is it a stripped down > =A0version of a FreeBSD install? If so, can you explain to me how the > =A0boot procedure works? /etc/rc launches /etc/rc.bootup (php, yeah, yeah I know) :) > - What version of FreeBSD are you using? Is it HEAD or RELENG_*? This is CURRENT. Everything is working great now after fixing a few obvious mistakes on my part. New TTY code is holding up great, nice work! Scott From owner-freebsd-current@FreeBSD.ORG Sun May 17 20:54:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1B38106566C for ; Sun, 17 May 2009 20:54:57 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 838728FC30 for ; Sun, 17 May 2009 20:54:57 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by gxk10 with SMTP id 10so1964290gxk.19 for ; Sun, 17 May 2009 13:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=nJa6Pergz10rJtSBjwi6acRpipISRmsBaxlzD2W44tI=; b=S38wRydiGAGlV+Vk7v1JBpsyW6izIWAZrVYKRlCZXNfJuJ/sawd4JJdvuFtZhnt1Fa AOugyxAUi8bNZ346KNqqK+/pEByc/XCvBfpFcRvMMSBlrGPmSeHQ0T3/PzttF8/PAmZB L3n/5bBESsOHR6bcLnz+zwIgkX+Qt+31KR0Hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=m62SLFEQexDX1XL5Ox67cUi5ENvO5HigC+qACImgS68fmLsvnFw7+rls++KmoT6z1t 7Pnx6NN1ze4j7qz77fOJ0oJr21aguzrg/ZVx7r6Gd4pCdcLg7YWpEzvtL5nNeWu4oPVt zbOLv1FjL7HMc7tUDtqyUTVMHIbBmlSmTXNsQ= MIME-Version: 1.0 Received: by 10.151.130.8 with SMTP id h8mr10856922ybn.247.1242593696755; Sun, 17 May 2009 13:54:56 -0700 (PDT) Date: Sun, 17 May 2009 22:54:56 +0200 Message-ID: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> From: Lucius Windschuh To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 20:54:58 -0000 With the newly imported uath driver, I was able to produce five different panics. Since four of them occur in unrelated kernel parts, this looks to me like some kernel part is corrupting memory. But since I am not an expert, here are backtraces for them: First, the one which seems to be without memory corruption (minidump availa= ble): panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04949c9 in db_fncall (dummy1=3D-979506816, dummy2=3D0, dummy3=3D-1068655593, dummy4=3D0xf3c47988 "@\231\235=EF=BF=BD001") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0494dc1 in db_command (last_cmdp=3D0xc0989c9c, cmd_table=3D0x0, dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc0494f1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc0496d7d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:229 #5 0xc06579d6 in kdb_trap (type=3D3, code=3D0, tf=3D0xf3c47b2c) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc088bdce in trap (frame=3D0xf3c47b2c) at /usr/src/sys/i386/i386/trap.= c:685 #7 0xc086f6fb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #8 0xc0657b5a in kdb_enter (why=3D0xc08f8592 "panic", msg=3D0xc08f8592 "panic") at cpufunc.h:71 #9 0xc062a1a6 in panic (fmt=3D0xc08f6f47 "mtx_lock() of destroyed mutex @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:559 #10 0xc061a925 in _mtx_lock_flags (m=3D0xc6af26b8, opts=3D0, file=3D0xc858faff "/usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c", line=3D1697) at /usr/src/sys/kern/kern_mutex.c:174 #11 0xc857445e in ieee80211_node_delucastkey (ni=3D0xc6af8000) at /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 #12 0xc85760d6 in node_free (ni=3D0xc6af8000) at /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:999 #13 0xc8573992 in _ieee80211_free_node (ni=3D0xc6af8000) at /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1622 #14 0xc84f5af0 in uath_bulk_tx_callback () from /boot/kernel/if_uath.ko #15 0xc0594d27 in usb2_callback_wrapper (pq=3D0xc9448030) at /usr/src/sys/dev/usb/usb_transfer.c:1962 #16 0xc0592716 in usb2_command_wrapper (pq=3D0xc9448030, xfer=3D0x0) at /usr/src/sys/dev/usb/usb_transfer.c:2538 #17 0xc05927f8 in usb2_callback_proc (_pm=3D0xc9448044) at /usr/src/sys/dev/usb/usb_transfer.c:1834 #18 0xc058febe in usb2_process (arg=3D0xc58d8ca4) at /usr/src/sys/dev/usb/usb_process.c:139 #19 0xc06036e8 in fork_exit (callout=3D0xc058fde0 , arg=3D0xc58d8ca4, frame=3D0xf3c47d38) at /usr/src/sys/kern/kern_fork.c:830 #20 0xc086f7a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 Now the strange faults: 2nd: (minidump available) Fatal trap 12: page fault while in kernel mode (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04949c9 in db_fncall (dummy1=3D-979506816, dummy2=3D0, dummy3=3D-1068655593, dummy4=3D0xc4eb3a20 "@\231\235=EF=BF=BD001") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0494dc1 in db_command (last_cmdp=3D0xc0989c9c, cmd_table=3D0x0, dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc0494f1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc0496d7d in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:229 #5 0xc06579d6 in kdb_trap (type=3D12, code=3D0, tf=3D0xc4eb3c08) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc088afcf in trap_fatal (frame=3D0xc4eb3c08, eva=3D3735929062) at /usr/src/sys/i386/i386/trap.c:924 #7 0xc088b963 in trap (frame=3D0xc4eb3c08) at /usr/src/sys/i386/i386/trap.= c:325 #8 0xc086f6fb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #9 0xc063cad1 in softclock (arg=3D0xc09a4ea0) at /usr/src/sys/kern/kern_timeout.c:335 #10 0xc0605975 in intr_event_execute_handlers (p=3D0xc516aa90, ie=3D0xc51aa000) at /usr/src/sys/kern/kern_intr.c:1134 #11 0xc06065df in ithread_loop (arg=3D0xc50e7ca0) at /usr/src/sys/kern/kern_intr.c:1147 #12 0xc06036e8 in fork_exit (callout=3D0xc0606540 , arg=3D0xc50e7ca0, frame=3D0xc4eb3d38) at /usr/src/sys/kern/kern_fork.c:830 #13 0xc086f7a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 3rd: (minidump available) panic: Bad tailq NEXT(0xe59b4e40->tqh_last) !=3D NULL (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04949c9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1061793024, dummy4=3D0xc4eb39d8 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0494dc1 in db_command (last_cmdp=3D0xc0989c9c, cmd_table=3D0x0, dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc0494f1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc0496d7d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:229 #5 0xc06579d6 in kdb_trap (type=3D3, code=3D0, tf=3D0xc4eb3b7c) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc088bdce in trap (frame=3D0xc4eb3b7c) at /usr/src/sys/i386/i386/trap.= c:685 #7 0xc086f6fb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #8 0xc0657b5a in kdb_enter (why=3D0xc08f8592 "panic", msg=3D0xc08f8592 "panic") at cpufunc.h:71 #9 0xc062a1a6 in panic (fmt=3D0xc08c0c8d "Bad tailq NEXT(%p->tqh_last) !=3D NULL") at /usr/src/sys/kern/kern_shutdown.c:559 #10 0xc063c780 in callout_reset_on (c=3D0xc09903a0, to_ticks=3D10, ftn=3D0xc04d9c20 , arg=3D0xc580ae00, cpu=3D0) at /usr/src/sys/kern/kern_timeout.c:626 #11 0xc04d9cf4 in dcons_timeout (v=3D0xc580ae00) at /usr/src/sys/dev/dcons/dcons_os.c:241 #12 0xc063ccd4 in softclock (arg=3D0xc09a4ea0) at /usr/src/sys/kern/kern_timeout.c:411 #13 0xc0605975 in intr_event_execute_handlers (p=3D0xc516aa90, ie=3D0xc51aa000) at /usr/src/sys/kern/kern_intr.c:1134 #14 0xc06065df in ithread_loop (arg=3D0xc50e7ca0) at /usr/src/sys/kern/kern_intr.c:1147 #15 0xc06036e8 in fork_exit (callout=3D0xc0606540 , arg=3D0xc50e7ca0, frame=3D0xc4eb3d38) at /usr/src/sys/kern/kern_fork.c:830 #16 0xc086f7a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 4th: (only textdump; PID 1368 is fsck_ufs) panic: Bad link elm 0xc67e5f28 prev->next !=3D elm db:0:kdb.enter.panic> bt Tracing pid 1368 tid 100086 td 0xc67e5d80 kdb_enter(c09c58b4,c09c58b4,c09875f4,eae86b50,0,...) at kdb_enter+0x3a panic(c09875f4,c67e5f28,100,c67e5d80,c67e5d80,...) at panic+0x136 _callout_stop_safe(c67e5f28,0,c09c9bf3,208,0,...) at _callout_stop_safe+0x3= 91 sleepq_check_timeout(b,c06d2380,c67e5d80,0,100,...) at sleepq_check_timeout= +0x73 sleepq_timedwait_sig(c0a7be84,5c,c09c6aa3,100,0,...) at sleepq_timedwait_sig+0x21 _sleep(c0a7be84,0,15c,c09c6aa3,b,...) at _sleep+0x30e kern_nanosleep(c67e5d80,eae86c64,eae86c6c,0,5dfc8c0,...) at kern_nanosleep+= 0xc1 nanosleep(c67e5d80,eae86cf8,8,c09cc50a,c0a2d800,...) at nanosleep+0x6f syscall(eae86d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip =3D 0x281724ef, esp =3D 0xbfbfda1c, ebp =3D 0xbfbfda48 --- 5th: (only textdump; PID 11 is "intr") panic: Bad link elm 0xc6f54568 next->prev !=3D elm db:0:kdb.enter.panic> bt Tracing pid 11 tid 100006 td 0xc6176480 kdb_enter(c09c58b4,c09c58b4,c09875d2,c5f3ec54,0,...) at kdb_enter+0x3a panic(c09875d2,c6f54568,c09c6bbc,145,c0a7bef4,...) at panic+0x136 softclock(c0a7bec0,c5f3ecc8,c068cda4,c0a7fe00,c61b5c38,...) at softclock+0x= 10a intr_event_execute_handlers(c6174a90,c61b5c00,c09c1671,4dd,c61b5c70,...) at intr_event_execute_handlers+0x125 ithread_loop(c610fba0,c5f3ed38,c09c13ec,336,c6174a90,...) at ithread_loop+0= x9f fork_exit(c0679190,c610fba0,c5f3ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5f3ed70, ebp =3D 0 --- The last two panics are from a differenct machine ("t400"), so I exclude faulty memory. The first three are from my machine "current". Kernel config, etc: http://sites.google.com/site/lwfreebsd/Home/files/ Kernel version: CURRENT r192252 Any ideas? Lucius From owner-freebsd-current@FreeBSD.ORG Sun May 17 21:28:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860671065673 for ; Sun, 17 May 2009 21:28:28 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 488DF8FC18 for ; Sun, 17 May 2009 21:28:27 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: by bwz9 with SMTP id 9so2872497bwz.43 for ; Sun, 17 May 2009 14:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :message-id; bh=mBjfhteRxEz/QhRtRfVfqERNRRSQhr27FM2e44PRcxU=; b=rd6T38YwR6fFaGA0rl3amPqK+i6N+kdZ4y7BM67nGmXobQz7bSTm09JKbCeYl1YDku 8rzOsW2xPvRegICklDAxT52SlBfoPyPIO803SnYW9l2rBKbr5szzvJ6nDXD4+zblhT8F 9H9oGonsUuk9r0wJWpb/o4LIShyzKD7xISu2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:message-id; b=g7R5UvHF4/FSydvza6qlv6gUuaVBb07/V8A0ofbHMs/WqYbcGQKHjKQhJUDSTzZNeV /EY4PsZ6t0EnzVm3aKSalRFbryi7PjPr3m48mUr36HsrGwm9ILz7Qb9jwsokVQcGlgPY gli5gkTLBaqeA8wo+slCGfDd76X2CpREdBEh8= Received: by 10.204.56.4 with SMTP id w4mr6017162bkg.17.1242595706243; Sun, 17 May 2009 14:28:26 -0700 (PDT) Received: from echo.hoth (host15-211-dynamic.0-79-r.retail.telecomitalia.it [79.0.211.15]) by mx.google.com with ESMTPS id f31sm6134809fkf.32.2009.05.17.14.28.21 (version=SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 14:28:25 -0700 (PDT) From: Alberto Villa To: freebsd-current@freebsd.org Date: Sun, 17 May 2009 23:28:18 +0200 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <20090514191237.GD70242@bsdcrew.de> <200905151149.12192.villa.alberto@gmail.com> In-Reply-To: <200905151149.12192.villa.alberto@gmail.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_zFIEK5gpfTuA9Oc" Message-Id: <200905172328.19175.villa.alberto@gmail.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 21:28:28 -0000 --Boundary-00=_zFIEK5gpfTuA9Oc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 15 May 2009 11:49:11 Alberto Villa wrote: > anyway i can't get to start a virtual machine. if i select a bootable iso > (ot doesn't show up in the file selection dialog, i have to write its name) > to boot from (it doesn't find my dvd device) the virtual machine starts > saying "running", but neither the session information dialog nor the log > show any activity. also tried using VBoxSDL tested again with virtualbox_2 on 7-stable, built right after the kernel: loading the module results in a kernel panic attached the `crashinfo` output -- Alberto Villa --Boundary-00=_zFIEK5gpfTuA9Oc-- From owner-freebsd-current@FreeBSD.ORG Sun May 17 22:10:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C46431065676; Sun, 17 May 2009 22:10:30 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAA28FC18; Sun, 17 May 2009 22:10:30 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by gxk10 with SMTP id 10so2014364gxk.19 for ; Sun, 17 May 2009 15:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PMRRzd1RAMlnkj+I4kiBwUdR7FycpcOIDTHfWu2t0MY=; b=FqSZO96LkKH04hRHtyoOb+tNY3bpKF1f0IKEVt1thz7jJkSMmHAiIucb2U6BQ2ZCcK Ute1hZHjuqTYVexxXiLoCYQiJakENI5iXLCMmF8++d8pmxqehddl8CXn+MPUST8fUQGO C2MG076sY621IixunDN44faAbFgz01LnfvTu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Cm1+q+k2n+1O4vDARCl+HnnqwAsoc55M7ccAKUWsLU58stfOMNFyQd2c/6HRXa5B3l KH8l+NACitMKBmrzo7JtBuJUQKSbW8uwxStLLaPje3kVGk3tCdYsULYI6m264b7YwFQr 5UIWJAjTBusbkm+4WY9lr6SfUsig5NliQGo6w= MIME-Version: 1.0 Received: by 10.151.137.7 with SMTP id p7mr11090061ybn.223.1242598227127; Sun, 17 May 2009 15:10:27 -0700 (PDT) In-Reply-To: <4A106B49.4020809@freebsd.org> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> <4A106B49.4020809@freebsd.org> Date: Mon, 18 May 2009 00:10:27 +0200 Message-ID: <90a5caac0905171510v17441d4na51a059f72f7ecae@mail.gmail.com> From: Lucius Windschuh To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Weongyo Jeong , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 22:10:31 -0000 Thanks for the commits. But... I forgot one thing: kldunload if_uath ; kldload if_uath on a firmware-loaded device leads to this output: uath0: timeout waiting for reply to cmd 0x1 (1) uath0: could not initialize adapter device_attach: uath0 attach returned 35 uath0: timeout waiting for reply to cmd 0x1 (1) uath0: could not initialize adapter device_attach: uath0 attach returned 35 Is this also a known problem? Lucius From owner-freebsd-current@FreeBSD.ORG Sun May 17 23:08:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36220106566B for ; Sun, 17 May 2009 23:08:17 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id D44D78FC0A for ; Sun, 17 May 2009 23:08:16 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1953571qwe.7 for ; Sun, 17 May 2009 16:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=/uitnVJx6D1VY+hPJ6adTbIJ0cOibr2RxNJBTgNlRD0=; b=MF1zPWnmplbr3ueDKhj7iV37JzOZGofOuEl+WKYh6YsNNA0tZ6LAxYehXiT7Htjm3G 22+qTr99pIAeBqEDOG3EiwWc3KCDxlNob1b38O5wUWseVHYSSbd0cg+h8l1LdyfAhmbO Ul1UJYEtmwxfRfW12TW9tzBW9zJytwVP/NB6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=TtZApyeSN93GMT98WhOoGX9+mdVizegcLAkzssdeD7pK5Mcvxjj4sqmNy9t44ySFOf NsYqfrXwtX0yzdKDaeMveXg4hWDo6mGlGVe5omtYiPPJy0Zdp/QJiSzKJCKwvJr6LBHj 0lm0vcKg4CCMav8SpwHqfqFogoGJVSFG2h81M= Received: by 10.224.73.213 with SMTP id r21mr5851275qaj.201.1242601696116; Sun, 17 May 2009 16:08:16 -0700 (PDT) Received: from cygnus.homeunix.com (201008164081.user.veloxzone.com.br [201.8.164.81]) by mx.google.com with ESMTPS id 26sm1518122qwa.48.2009.05.17.16.08.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 16:08:15 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 7AA62B8143; Sun, 17 May 2009 20:08:09 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Sun, 17 May 2009 20:08:09 -0300 (BRT) Message-ID: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> Date: Sun, 17 May 2009 20:08:09 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: is my slow for this ? hostap related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 23:08:17 -0000 hail, I have an atheros wlan card: ath0@pci0:0:11:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet and I'm having some problems with it: May 17 13:00:06 floyd kernel: ath0: stuck beacon; resetting (bmiss count 4) May 17 13:00:37 floyd last message repeated 18 times May 17 13:01:46 floyd last message repeated 47 times May 17 13:01:49 floyd kernel: lock order reversal: May 17 13:01:49 floyd kernel: 1st 0xc229e6b8 ath0_node_lock (ath0_node_lock) @ /usr/src/sys/net80211/ieee80211_ioctl.c:1315 May 17 13:01:49 floyd kernel: 2nd 0xc229d014 ath0_com_lock (ath0_com_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2458 May 17 13:01:49 floyd kernel: KDB: stack backtrace: May 17 13:01:49 floyd kernel: db_trace_self_wrapper(c0c7a11e,c826a934,c08d2a15,c08c491b,c0c7cf03,...) at db_trace_self_wrapper+0x26 May 17 13:01:49 floyd kernel: kdb_backtrace(c08c491b,c0c7cf03,c212c008,c212bfa0,c826a990,...) at kdb_backtrace+0x29 May 17 13:01:49 floyd kernel: _witness_debugger(c0c7cf03,c229d014,c229d004,c212bfa0,c0c8a7f4,...) at _witness_debugger+0x25 May 17 13:01:49 floyd kernel: witness_checkorder(c229d014,9,c0c8a7f4,99a,0,...) at witness_checkorder+0x839 May 17 13:01:49 floyd kernel: _mtx_lock_flags(c229d014,0,c0c8a7f4,99a,64,...) at _mtx_lock_flags+0xc4 May 17 13:01:49 floyd kernel: ieee80211_node_leave(c2791000,c0,2,c2791000,c229e6a4,...) at ieee80211_node_leave+0xa5 May 17 13:01:49 floyd kernel: domlme(c826aa2c,c2791000,c0c8a6b8,523,c826aa5e,...) at domlme+0x83 May 17 13:01:49 floyd kernel: setmlme_common(2,c826aa5a,2a,28033f0c,1a000002,...) at setmlme_common+0x115 May 17 13:01:49 floyd kernel: ieee80211_ioctl_setmlme(c23f6e00,c826aaa8,c08d4619,4,0,...) at ieee80211_ioctl_setmlme+0x74 May 17 13:01:49 floyd kernel: ieee80211_ioctl_set80211(c2444900,1b9,c08d27bb,c0c85956,c0c6f8cf,...) at ieee80211_ioctl_set80211+0x559 May 17 13:01:49 floyd kernel: ieee80211_ioctl(c23d2800,801c69ea,c23d79c0,c0f05ac0,c23d2800,...) at ieee80211_ioctl+0x2ea May 17 13:01:49 floyd kernel: in_control(c24727bc,801c69ea,c23d79c0,c23d2800,c2444900,...) at in_control+0x1e9 May 17 13:01:49 floyd kernel: ifioctl(c24727bc,801c69ea,c23d79c0,c2444900,801c69ea,...) at ifioctl+0x33e May 17 13:01:49 floyd kernel: soo_ioctl(c24054d0,801c69ea,c23d79c0,c2174400,c2444900,...) at soo_ioctl+0x397 May 17 13:01:49 floyd kernel: kern_ioctl(c2444900,3,801c69ea,c23d79c0,8cc370,...) at kern_ioctl+0x1dd May 17 13:01:49 floyd kernel: ioctl(c2444900,c826acf8,c,c0c7da08,c0d597b0,...) at ioctl+0x134 May 17 13:01:49 floyd kernel: syscall(c826ad38) at syscall+0x2a3 May 17 13:01:49 floyd kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 May 17 13:01:49 floyd kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281d78f3, esp = 0xbfbfeb7c, ebp = 0xbfbfebc8 --- May 17 13:01:50 floyd kernel: ath0: stuck beacon; resetting (bmiss count 4) May 17 13:02:21 floyd last message repeated 17 times May 17 13:04:22 floyd last message repeated 74 times May 17 13:14:23 floyd last message repeated 1540 times May 17 13:19:36 floyd last message repeated 996 times May 17 13:19:36 floyd su: matheus to root on /dev/pts/2 May 17 13:19:36 floyd kernel: ath0: stuck beacon; resetting (bmiss count 4) May 17 13:20:07 floyd last message repeated 89 times May 17 13:22:08 floyd last message repeated 376 times I've read this: http://www.nabble.com/ath0:-stuck-beacon--resetting-(bmiss-count-4)-td22359155.html and I'm thinking my pc is slow for the job, as said. floyd# cat dmesg.today Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Tue May 5 23:08:28 BRT 2009 root@floyd.apartnet:/usr/obj/usr/src/sys/Floyd8 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Transmeta(tm) Crusoe(tm) Processor TM5700 (798.13-MHz 586-class CPU) Origin = "GenuineTMx86" Id = 0x543 Stepping = 3 Features=0x84893f real memory = 136314880 (130 MB) avail memory = 95809536 (91 MB) kbd1 at kbdmux0 pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) uhci0: port 0xe000-0xe01f irq 11 at device 9.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x201a usbus0: on uhci0 uhci1: port 0xe100-0xe11f irq 15 at device 9.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2010 usbus1: on uhci1 ehci0: mem 0xe8192000-0xe81920ff irq 5 at device 9.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 atapci0: port 0xe200-0xe207,0xe300-0xe303,0xe400-0xe407,0xe500-0xe503,0xe600-0xe60f mem 0xe8190000-0xe81903ff irq 15 at device 11.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] vgapci0: port 0xe700-0xe7ff mem 0xe0000000-0xe7ffffff,0xe8180000-0xe818ffff irq 10 at device 13.0 on pci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 17.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 17.4 (no driver attached) vr0: port 0xeb00-0xebff mem 0xe8191000-0xe81910ff irq 11 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x51 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:13:21:ee:26:00 vr0: [ITHREAD] cpu0 on motherboard pmtimer0 on isa0 atrtc0: at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] unknown: can't assign resources (memory) orm0: at iomem 0xc0000-0xc8fff,0xcc000-0xcffff,0xd0000-0xd9fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. unknown: can't assign resources (memory) Timecounter "TSC" frequency 798131539 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered ad4: 6149MB at ata2-master SATA150 WARNING: WITNESS option enabled, expect reduced performance. GEOM: ad4s1: geometry does not match label (255h,63s != 15h,63s). GEOM: ad4s2: geometry does not match label (255h,63s != 15h,63s). GEOM_LABEL: Label for provider ad4s1a is ufsid/48a498393b6d8bea. Trying to mount root from ufs:/dev/ad4s1a ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 GEOM_LABEL: Label ufsid/48a498393b6d8bea removed. GEOM_LABEL: Label for provider ad4s1a is ufsid/48a498393b6d8bea. GEOM_LABEL: Label ufsid/48a498393b6d8bea removed. module_register: module uhub/u3g already exists! Module uhub/u3g failed to register: 17 u3g_huawei_init:252: usb2_alloc_device:1791: Found Huawei auto-install disk! ugen0.2: at usbus0 ugen0.2: at usbus0 (disconnected) uhub_reattach_port:417: could not allocate new device! ugen0.2: at usbus0 u3g0: on usbus0 u3g0: Found 2 ports. tun0: link state changed to UP vr0: promiscuous mode enabled vr0: promiscuous mode disabled tun0: promiscuous mode enabled tun0: promiscuous mode disabled tun0: promiscuous mode enabled tun0: promiscuous mode disabled ugen0.2: at usbus0 (disconnected) u3g0: at uhub0, port 2, addr 2 (disconnected) u3g_huawei_init:252: usb2_alloc_device:1791: Found Huawei auto-install disk! ugen1.3: at usbus1 ugen1.3: at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! ugen1.3: at usbus1 u3g0: on usbus1 u3g0: Found 2 ports. tun0: link state changed to DOWN tun0: link state changed to UP tun0: link state changed to DOWN tun0: link state changed to UP tun0: promiscuous mode enabled tun0: promiscuous mode disabled tun0: promiscuous mode enabled tun0: promiscuous mode disabled ugen1.3: at usbus1 (disconnected) u3g0: at uhub1, port 2, addr 3 (disconnected) ugen1.3: at usbus1 uark0: on usbus1 as soon as I installed the atheros card it was ok, slow but ok. now it doesn't even work. as was said to be slow, I recompiled kernel without debug stuff. same problem ... is this crusoe really slow for this ? I tried to compare this to geode from alix and soekris I've seen many people say to run as AP, but couldn't find any comparison. so now I'm asking here :) the box is used just as AP, 128MB ram and ide 44 pin to 40 pin ide disk. I'm running current i386 as of may 5. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Mon May 18 00:37:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89FC51065675; Mon, 18 May 2009 00:37:30 +0000 (UTC) (envelope-from sfourman@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 92F628FC13; Mon, 18 May 2009 00:37:29 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so946184fge.12 for ; Sun, 17 May 2009 17:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3UnGvnuZEHT/y1ljSF9IBpUXrpWOYy8iEGNZ1RJtq4Y=; b=h9H4/gx477SvdWSghFabgYPVJNCJjNKH4rE6eQkLt2fqblE5v12PvEzsyHykKadQ8c 1B4KEBRHeSHZpvstmDgJ/qhrZw4EK/Ss6TcFz5ILbLRTCMfUw+zeOXjZW28P5NK5RSfn BD2XSqhWiPjcqHjXx1cvUDjVSv74u7tlXlE0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ucabLmQ9Ao7uL8pRT5Zm+UU7IhAgQ+UYkLb2AZ4OrStIyou50eSHeuZvZC0IenExx7 LRqyOGqOhauhu6K5HRVCkZNHEHlr0qAwi9g4HGt9uMde/4x5NgaYokIkcMslTilmmVpN kes3QgcjxrYdli9sclbdP92N2qXbEoNFxunOM= MIME-Version: 1.0 Received: by 10.239.146.3 with SMTP id u3mr405563hba.52.1242607048417; Sun, 17 May 2009 17:37:28 -0700 (PDT) In-Reply-To: <20090518002528.GF2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> Date: Sun, 17 May 2009 19:37:28 -0500 Message-ID: <11167f520905171737q4f19a359id6b1af11e10d5184@mail.gmail.com> From: "Sam Fourman Jr." To: Greg Byshenk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 00:37:31 -0000 On Sun, May 17, 2009 at 7:25 PM, Greg Byshenk wrote: > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: >> >> We rolled a new tarball with the patch from Juergen Lock [1] >> with a posible fix for AMD64 users, tested on 3 machines >> which now works without problems. Many Thanks to him for >> his nice work! >> >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz Does the FreeBSD version have USB passthrough support like Linux? Sam Fourman From owner-freebsd-current@FreeBSD.ORG Mon May 18 00:41:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991E0106567A; Mon, 18 May 2009 00:41:18 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id A63A68FC21; Mon, 18 May 2009 00:41:17 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by ewy3 with SMTP id 3so3584357ewy.43 for ; Sun, 17 May 2009 17:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Df3UZTPsYG1QlE/ldliGsD9sL17XkJG2aQuZGv2Pyyk=; b=rGWxLysuldL3wdGwgFrmPWpJKHA+agMqF/xBTl123QKZI4Q6YIj6VFhS1dyO41iFny mc5aA7zr546lhMeGhrUiK0GEekFmrPyQWiJWJ4z/7DQoXkbODy/FEFGM6NkmpKOrrWbz IzjBG0sPuW9dqYLJ0y1meR8DT9TbpkiBxiqkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dA7Jl+F+UiwKaTCeuf7/cy5vcR4Ojc764kvYmTA/4/LNrJgUjv3muvuGH4vBo0VsfJ Go0i4++w4LqXFk8lw+n/pVoA4vgmOcspH95e39icY5nFhfSTjr9ftULjrpsF2B1Jv04F HE9F7oqd9PUXo2F9jf6qYxLwqH41tv2oCkO9c= MIME-Version: 1.0 Received: by 10.216.8.78 with SMTP id 56mr1874028weq.210.1242607276478; Sun, 17 May 2009 17:41:16 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Sun, 17 May 2009 20:41:16 -0400 Message-ID: <4ad871310905171741t55611cf7vc96e0086a371052@mail.gmail.com> From: Glen Barber To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 00:41:19 -0000 On Sun, May 17, 2009 at 2:09 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > Is there need for the i386 folks to rebuild, or does it only affect amd64? -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Mon May 18 00:25:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A5E1065670; Mon, 18 May 2009 00:25:30 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 03CDA8FC15; Mon, 18 May 2009 00:25:29 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4I0PSM0095291; Mon, 18 May 2009 02:25:28 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4I0PSLL095290; Mon, 18 May 2009 02:25:28 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 18 May 2009 02:25:28 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090518002528.GF2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090517180920.GY71804@bsdcrew.de> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-Mailman-Approved-At: Mon, 18 May 2009 00:59:28 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 00:25:31 -0000 On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz I've just updated my system (to 7-STABLE amd64 as of today) and installed the new version. It runs for me now. Tomorrow I will try to create virtual machine. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-current@FreeBSD.ORG Mon May 18 00:50:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6120B106564A; Mon, 18 May 2009 00:50:56 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id E4C1C8FC12; Mon, 18 May 2009 00:50:55 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4I0os07095605; Mon, 18 May 2009 02:50:54 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4I0osou095604; Mon, 18 May 2009 02:50:54 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 18 May 2009 02:50:54 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090518005054.GG2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090518002528.GF2571@core.byshenk.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-Mailman-Approved-At: Mon, 18 May 2009 00:59:39 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 00:50:57 -0000 On Mon, May 18, 2009 at 02:25:28AM +0200, Greg Byshenk wrote: > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > > > We rolled a new tarball with the patch from Juergen Lock [1] > > with a posible fix for AMD64 users, tested on 3 machines > > which now works without problems. Many Thanks to him for > > his nice work! > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > I've just updated my system (to 7-STABLE amd64 as of today) and > installed the new version. It runs for me now. Tomorrow I will > try to create virtual machine. As a followup, the 'virtualbox_2.tgz' version appears to work for me, at least minimally. I've just installed NetBSD4.1 virtual machine, and it appears to be working (even though NetBSD isn't listed as a supported guest -- I just happened to have the NetBSD install iso sitting on my hard drive). -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-current@FreeBSD.ORG Mon May 18 04:54:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9D6F106567F for ; Mon, 18 May 2009 04:54:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 91D568FC0A for ; Mon, 18 May 2009 04:54:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so5411652qyk.3 for ; Sun, 17 May 2009 21:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nWOac4TjGqCwXI49fcYGioRZzpknEuEXHYfDrU2aJgg=; b=AdSqapCtbMpe8Bcv11Zz7XBUWwwui4LTsIvAdtdG4hWfpOUljP7FqJ6UCjJ5w5uvEE jncnUcdNQCuPNU5jDQ20tYdr6Q9gE2O78cVegXbvrGEHYIsqRrlA18+3FE5ODceBriNr d70a4pxbZ4GMA7IK+V+1igKR1LuTBqrqdSyj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=EUtzNvhIO4AgaBay21tkmm3eibxkh68aEqZbDJuaWqpH5Z8E6muXr0EotQsglc2Oqe 6DjwailXVuABzKZKrtPOWUBL695FXhhFbLpwon94/s6n6CMW22nlSzVyJE8rPCNnGe0D UxVkcRfQfvZDfdLk3p2+oQjmycF3AI3PhP3R8= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.96.10 with SMTP id f10mr2883228qcn.72.1242622470955; Sun, 17 May 2009 21:54:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 May 2009 12:54:30 +0800 X-Google-Sender-Auth: 1843df3804de6968 Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Xen/FreeBSD-current issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 04:54:32 -0000 fwiw, this was due a bad merge which reverted the previously committed fix for this. FreeBSD-current Xen now seems to basically function. Adrian 2009/5/17 Adrian Chadd : > I've managed to build up a basic install of FreeBSD-current from > yesterday under Xen. > > The kernel unfortunately panics on startup when the network interface > is probed; it boots to completion fine when no interface is configured > in the Xen config file. > > Configuration file: > > kernel = "/home/adrian/xen/kernel.current" > memory = 256 > name = "freebsd" > vif = [ 'mac=00:bd:c4:12:00:ef,bridge=xenbr0' ] > disk = [ 'phy:/dev/hosting2_data2/XEN_freebsd,hda,w' ] > on_crash = 'preserve' > extra = "boot_verbose=1" > extra += ",vfs.root.mountfrom=ufs:/dev/ad0s1a" > extra += ",kern.hz=100" > > > Dmesg and stuff follows: > > [root@hosting-2 xen]# xm console freebsd > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0: Sun May 17 09:43:08 UTC 2009 > adrian@agnus.home.cacheboy.net:/home/adrian/work/freebsd/xen/obj/home/adrian/work/freebsd/xen/src/sys/XEN > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 1674.429 MHz processor. > Timecounter "ixen" frequency 1000000000 Hz quality 0 > CPU: AMD Athlon(tm) XP 2000+ (1674.43-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 > Features=0x383fbff > AMD Features=0xc0400800 > Data TLB: 32 entries, fully associative > Instruction TLB: 16 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative > real memory = 268435456 (256 MB) > Physical memory chunk(s): > 0x00000000006aa000 - 0x000000000fb3bfff, 256450560 bytes (62610 pages) > avail memory = 254377984 (242 MB) > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > ULE: setup cpu 0 > cpu=0 irq=0 vector=0 > cpu=0 irq=0 vector=1 > Event-channel device installed. > random: > kbd0 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > nfslock: pseudo-device > null: > io: > Grant table initialized > xenbus0: on motherboard > xc0: on motherboard > npx0: INT 16 interface > Device configuration finished. > procfs registered > Timecounters tick every 10.000 msec > lo0: bpf attached > xbd0: 10240MB at device/vbd/768 on xenbus0 > xbd0: attaching as ad0 > GEOM: new disk ad0 > xn0: at device/vif/0 on xenbus0 > xn0: bpf attached > xn0: Ethernet address: 00:bd:c4:12:00:ef > WARNING: WITNESS option enabled, expect reduced performance. > flowtable cleaner started > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex xennetif_rx (network receive lock) r = 0 > (0xc18580b4) locked @ > /home/adrian/work/freebsd/xen/src/sys/dev/xen/netfront/netfront.c:1123 > KDB: stack backtrace: > X_db_sym_numargs(c035ef81,cbe5daf0,c0111b25,c038262f,463,...) at > X_db_sym_numargs+0x146 > kdb_backtrace(c038262f,463,ffffffff,c05104fc,cbe5db28,...) at kdb_backtrace+0x29 > witness_display_spinlock(c03613ca,cbe5db3c,4,1,0,...) at > witness_display_spinlock+0x75 > witness_warn(5,0,c038acd6,c17d8b00,c,...) at witness_warn+0x1fd > trap(cbe5dbc4) at trap+0x13e > alltraps(c1858000,cbe5dcc8,c00c3854,c03d4200,c175a738,...) at alltraps+0x1b > intr_event_execute_handlers(c17097ec,c175a700,c03577af,4dd,c175a770,...) > at intr_event_execute_handlers+0x125 > intr_event_add_handler(c1768490,cbe5dd38,c03574ec,336,c17097ec,...) at > intr_event_add_handler+0x41f > fork_exit(c00afd10,c1768490,cbe5dd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xcbe5dd70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write, page not present > instruction pointer = 0x21:0xc0301037 > stack pointer = 0x29:0xcbe5dc04 > frame pointer = 0x29:0xcbe5dca0 > code segment = base 0x0, limit 0xf67ff, type 0x1b > = DPL 1, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq134: xn) > [thread pid 12 tid 100023 ] > Stopped at xlvbd_add+0x3747: movl %edx,0(%esi) > db> xccncheckc:155 > xccncheckc:155 > > > bt: > > Tracing pid 12 tid 100023 td 0xc175b000 > xlvbd_add(c1858000,cbe5dcc8,c00c3854,c03d4200,c175a738,...) at xlvbd_add+0x3747 > intr_event_execute_handlers(c17097ec,c175a700,c03577af,4dd,c175a770,...) > at intr_event_execute_handlers+0x125 > intr_event_add_handler(c1768490,cbe5dd38,c03574ec,336,c17097ec,...) at > intr_event_add_handler+0x41f > fork_exit(c00afd10,c1768490,cbe5dd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xcbe5dd70, ebp = 0 --- > > ps: > > pid ppid pgrp uid state wmesg wchan cmd > 20 0 0 0 SL flowclea 0xc03d00e4 [flowcleaner] > 19 0 0 0 SL sdflush 0xc05484e0 [softdepflush] > 18 0 0 0 SL vlruwt 0xc18867ec [vnlru] > 17 0 0 0 SL syncer 0xc053c750 [syncer] > 16 0 0 0 SL psleep 0xc053c488 [bufdaemon] > 9 0 0 0 SL pgzero 0xc0549164 [pagezero] > 8 0 0 0 SL psleep 0xc0548d3c [vmdaemon] > 7 0 0 0 SL psleep 0xc0548d04 [pagedaemon] > 6 0 0 0 SL waiting_ 0xc053e5bc [sctp_iterator] > 5 0 0 0 SL balloon 0xc02fc590 [balloon] > 15 0 0 0 SL xbread 0xc0621000 [xenbus] > 14 0 0 0 SL waitev 0xc054c000 [xenwatch] > 13 0 0 0 SL - 0xc03d00e4 [yarrow] > 4 0 0 0 SL - 0xc03cdea4 [g_down] > 3 0 0 0 SL - 0xc03cdea0 [g_up] > 2 0 0 0 RL [g_event] > 12 0 0 0 RL (threaded) intr > 100023 Run CPU 0 [irq134: xn] > 100022 I [irq133: xbd] > xccncheckc:155 > 100019 I [irq131: xencons] > xccncheckc:155 > 100016 I [irq130: xenbus] > 100015 I [swi6: Giant taskq] > 100013 I [swi5: +] > 100011 I [swi6: task queue] > 100006 I [swi3: vm] > 100005 I [swi1: net] > 100004 I [swi4: clock] > 11 0 0 0 RL [idle: cpu0] > 1 0 0 0 SL g_waitid 0xc03cdde4 [kernel] > 10 0 0 0 SL audit_wo 0xc0547e80 [audit] > 0 0 0 0 SLs (threaded) kernel > 100014 D - 0xc1747c80 [thread taskq] > 100012 D - 0xc1747d40 [kqueue taskq] > 100000 D sched 0xc03cdf40 [swapper] > From owner-freebsd-current@FreeBSD.ORG Mon May 18 05:36:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC4F1065672 for ; Mon, 18 May 2009 05:36:39 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 82AF38FC23 for ; Mon, 18 May 2009 05:36:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243034055; Mon, 18 May 2009 08:36:37 +0300 Message-ID: <4A10F3E3.40306@FreeBSD.org> Date: Mon, 18 May 2009 08:36:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> In-Reply-To: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 05:36:39 -0000 Hi. Magnus Kling wrote: > After having some trouble with ACPI kernel in 7.1, regarding booting > with a Promise SX4000 card in a RAID1 setup, I tried to upgrade to > CURRENT to test the bits that John Baldwin wrote and had commited to head. > > Result: > Well, it boots ok but on reboot I get a kernel panic after the disks > have made the sync. > > Attached is a bt and panic message. According to backtrace, system tried to reference address 0xc while sending final flush command to the drive. ATA has no other shutdown actions except this, so any contexts and states should not be lost in any case. And as soon as your drive was detected, the controller is probably operable. Haven't you seen any other ATA error messages during boot or later? If my i386 kernel is more or less coherent to your's, ata_promise_sx4_command+0x39 address where it have crashed means caddr_t window = rman_get_virtual(ctlr->r_res1); line, and especially 'ctlr->r_res1' part. So looks like struct ata_pci_controller *ctlr = device_get_softc(gparent); returned NULL there. But the same technique used by many other ATA drivers without problems, so I am a bit surprised. Is the problem continuously repeatable? Does the controller operates well all other time before shutdown? Are you sure that you have rebuilt your kernel correctly? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 18 07:25:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B82D1065670; Mon, 18 May 2009 07:25:15 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8F47A8FC15; Mon, 18 May 2009 07:25:14 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so3698199ewy.43 for ; Mon, 18 May 2009 00:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hXCOH2aqccm93OqD0rIk3IQD0WmIGdvo/kJYnE+8OTk=; b=CenC5ToHk/9EVIUlIt5SgMLKoWuP13Dxph9m2AH9nuD7ZAOr5EE7y6aK/Xh5OMZfs/ qBJH0EN0XnFcjQxmSQs4l3GVVtaEttH373YvBfMjVZB3O88/hv7m9botEeeUuCmWQCN7 7b4EPM1RnGzCBFbvBxz3fDN/c96SbQ7vXysSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W01LCltCIyYNJRF5Y80xBMdgyKtamHFXtu8X7EC60EK0W5W8l+wRu0K/JjUobwCLH3 tzgf557E5P9eRWDcnMx11kVIKFoW15K49d0s7ZMMQChNHpbZSNB98RTSBdrLflEc/AOq Wyv5zLhcDkn6wWO23oRRYX5iT53YJqirw3hMc= MIME-Version: 1.0 Received: by 10.216.20.8 with SMTP id o8mr2012044weo.112.1242631513099; Mon, 18 May 2009 00:25:13 -0700 (PDT) In-Reply-To: <4A10F3E3.40306@FreeBSD.org> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> Date: Mon, 18 May 2009 09:25:13 +0200 Message-ID: <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 07:25:15 -0000 2009/5/18 Alexander Motin > Hi. > > Magnus Kling wrote: > >> After having some trouble with ACPI kernel in 7.1, regarding booting with >> a Promise SX4000 card in a RAID1 setup, I tried to upgrade to CURRENT to >> test the bits that John Baldwin wrote and had commited to head. >> Result: >> Well, it boots ok but on reboot I get a kernel panic after the disks have >> made the sync. >> Attached is a bt and panic message. >> > > According to backtrace, system tried to reference address 0xc while sending > final flush command to the drive. ATA has no other shutdown actions except > this, so any contexts and states should not be lost in any case. And as soon > as your drive was detected, the controller is probably operable. Haven't you > seen any other ATA error messages during boot or later? > > If my i386 kernel is more or less coherent to your's, > ata_promise_sx4_command+0x39 address where it have crashed means > caddr_t window = rman_get_virtual(ctlr->r_res1); > line, and especially 'ctlr->r_res1' part. So looks like > struct ata_pci_controller *ctlr = device_get_softc(gparent); > returned NULL there. But the same technique used by many other ATA drivers > without problems, so I am a bit surprised. > > Is the problem continuously repeatable? Does the controller operates well > all other time before shutdown? Are you sure that you have rebuilt your > kernel correctly? > > -- > Alexander Motin > Yes it is repeatable. Happens every reboot or shutdown. Controller works ok all other time. (I have my homedir mounted to the raidarray.) The source was synced and then I did a normal: make buildworld make buildkernel make installkernel reboot to singel user mode and mergemaster -p + make installworld + mergemaster then reboot. I will try to compile it again... /Magnus From owner-freebsd-current@FreeBSD.ORG Mon May 18 08:34:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFE7F106566C for ; Mon, 18 May 2009 08:34:17 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 2829A8FC16 for ; Mon, 18 May 2009 08:34:16 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ezY8gES9d9YA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=RRgnrM4ICHkkUpFZu5kA:9 a=hTeHOaKq-z6AlGNJI1RKctCXjiEA:4 a=UlvUavXRAAAA:8 a=rL6TIayMHYZ-YPLjhE0A:9 a=_aIzSSXiGnr7tqotQBo1JtEGD3AA:4 a=6FRLwHsFNoYA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1241156808; Mon, 18 May 2009 10:34:15 +0200 Received-SPF: softfail receiver=mailfe07.swip.net; client-ip=81.191.55.181; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: gnome@FreeBSD.org, ports@freebsd.org, freebsd-usb@freebsd.org, freebsd-current@freebsd.org Date: Mon, 18 May 2009 10:36:50 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_j4REKGJO9Qvs4M9" Message-Id: <200905181036.51184.hselasky@freebsd.org> Cc: Subject: Minor USB related sysutils/hal patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 08:34:18 -0000 --Boundary-00=_j4REKGJO9Qvs4M9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've made some minor patches for sysutils/hal If the device is detached during config read, the config can be NULL. Check that. Make sure that we close the device handles as we go, to save number of open files. When the backend is freed any leftover file handles will get freed, so it is not absolutely needed to close the device handle in every case. --HPS --Boundary-00=_j4REKGJO9Qvs4M9 Content-Type: text/x-diff; charset="us-ascii"; name="files.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="files.diff" diff -u -r files.org/patch-configure files/patch-configure --- files.org/patch-configure 2009-05-18 09:35:47.000000000 +0200 +++ files/patch-configure 2009-05-18 10:23:05.000000000 +0200 @@ -286,7 +286,7 @@ +main () +{ +return libusb20_dev_get_info (); -+ ; ++ + return 0; +} +_ACEOF @@ -325,8 +325,8 @@ +if test $ac_cv_lib_usb_libusb20_dev_get_info = yes; then + USE_LIBUSB=yes +else -+ USE_LIBUSB=np ++ USE_LIBUSB=no +fi + +fi diff -u -r files.org/patch-hald_freebsd_probing_probe-usb2-device.c files/patch-hald_freebsd_probing_probe-usb2-device.c --- files.org/patch-hald_freebsd_probing_probe-usb2-device.c 2009-05-18 09:35:47.000000000 +0200 +++ files/patch-hald_freebsd_probing_probe-usb2-device.c 2009-05-18 09:45:27.000000000 +0200 @@ -96,9 +96,9 @@ + pcfg = libusb20_dev_alloc_config(pdev, curr_config); + cdesc = &(pcfg->desc); + -+ if (libusb20_dev_get_info(pdev, &di)) -+ { -+ free(pcfg); ++ if ((pcfg == NULL) || libusb20_dev_get_info(pdev, &di)) ++ { ++ if (pcfg != NULL) free(pcfg); + continue; + } + @@ -196,7 +196,7 @@ + libhal_device_set_property_string(hfp_ctx, hfp_udi, + "info.vendor", di.udi_vendor, &hfp_error); + -+ free(pcfg); ++ libusb20_dev_close(pdev); free(pcfg); + } +end: + if (pbe) --Boundary-00=_j4REKGJO9Qvs4M9-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 08:47:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 006841065672; Mon, 18 May 2009 08:47:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 35D878FC22; Mon, 18 May 2009 08:47:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=x01RqrcTYZgA:10 a=bYLFNfMPybAA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=6I5d2MoRAAAA:8 a=0SyfTw2qVp_3weSCohYA:9 a=KG7o6BNqDIQg79z-6V4A:7 a=ZHjOyVgRnGMO3rT5j2NDk6aTjSQA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 500280202; Mon, 18 May 2009 10:47:29 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 10:50:02 +0200 User-Agent: KMail/1.9.7 References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> In-Reply-To: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905181050.03154.hselasky@c2i.net> Cc: Lucius Windschuh , current@freebsd.org Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 08:47:34 -0000 On Sunday 17 May 2009, Lucius Windschuh wrote: > panic: mtx_lock() of destroyed mutex @ > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 > > (kgdb) bt > #0 =C2=A0doadump () at pcpu.h:246 > #1 =C2=A00xc04949c9 in db_fncall (dummy1=3D-979506816, dummy2=3D0, > dummy3=3D-1068655593, dummy4=3D0xf3c47988 "@\231\235=EF=BF=BD001") at > /usr/src/sys/ddb/db_command.c:548 > #2 =C2=A00xc0494dc1 in db_command (last_cmdp=3D0xc0989c9c, cmd_table=3D0x= 0, > dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > #3 =C2=A00xc0494f1a in db_command_loop () at /usr/src/sys/ddb/db_command.= c:498 > #4 =C2=A00xc0496d7d in db_trap (type=3D3, code=3D0) at > /usr/src/sys/ddb/db_main.c:229 #5 =C2=A00xc06579d6 in kdb_trap (type=3D3,= code=3D0, > tf=3D0xf3c47b2c) at > /usr/src/sys/kern/subr_kdb.c:534 > #6 =C2=A00xc088bdce in trap (frame=3D0xf3c47b2c) at > /usr/src/sys/i386/i386/trap.c:685 #7 =C2=A00xc086f6fb in calltrap () at > /usr/src/sys/i386/i386/exception.s:165 #8 =C2=A00xc0657b5a in kdb_enter > (why=3D0xc08f8592 "panic", msg=3D0xc08f8592 "panic") at cpufunc.h:71 > #9 =C2=A00xc062a1a6 in panic (fmt=3D0xc08f6f47 "mtx_lock() of destroyed m= utex > @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:559 > #10 0xc061a925 in _mtx_lock_flags (m=3D0xc6af26b8, opts=3D0, > file=3D0xc858faff > "/usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c", > line=3D1697) at /usr/src/sys/kern/kern_mutex.c:174 > #11 0xc857445e in ieee80211_node_delucastkey (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 > #12 0xc85760d6 in node_free (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:999 > #13 0xc8573992 in _ieee80211_free_node (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1622 > #14 0xc84f5af0 in uath_bulk_tx_callback () from /boot/kernel/if_uath.ko > #15 0xc0594d27 in usb2_callback_wrapper (pq=3D0xc9448030) at > /usr/src/sys/dev/usb/usb_transfer.c:1962 > #16 0xc0592716 in usb2_command_wrapper (pq=3D0xc9448030, xfer=3D0x0) at > /usr/src/sys/dev/usb/usb_transfer.c:2538 > #17 0xc05927f8 in usb2_callback_proc (_pm=3D0xc9448044) at > /usr/src/sys/dev/usb/usb_transfer.c:1834 > #18 0xc058febe in usb2_process (arg=3D0xc58d8ca4) at > /usr/src/sys/dev/usb/usb_process.c:139 > #19 0xc06036e8 in fork_exit (callout=3D0xc058fde0 , > arg=3D0xc58d8ca4, frame=3D0xf3c47d38) at /usr/src/sys/kern/kern_fork.c:830 > #20 0xc086f7a0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 Regarding the first panic, there seems to be a detach race in both upgt and= =20 uath, which is not USB related. Try this patch: http://perforce.freebsd.org/chv.cgi?CH=3D162250 =2D-HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 08:47:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 006841065672; Mon, 18 May 2009 08:47:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 35D878FC22; Mon, 18 May 2009 08:47:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=x01RqrcTYZgA:10 a=bYLFNfMPybAA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=6I5d2MoRAAAA:8 a=0SyfTw2qVp_3weSCohYA:9 a=KG7o6BNqDIQg79z-6V4A:7 a=ZHjOyVgRnGMO3rT5j2NDk6aTjSQA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 500280202; Mon, 18 May 2009 10:47:29 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 10:50:02 +0200 User-Agent: KMail/1.9.7 References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> In-Reply-To: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905181050.03154.hselasky@c2i.net> Cc: Lucius Windschuh , current@freebsd.org Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 08:47:34 -0000 On Sunday 17 May 2009, Lucius Windschuh wrote: > panic: mtx_lock() of destroyed mutex @ > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 > > (kgdb) bt > #0 =C2=A0doadump () at pcpu.h:246 > #1 =C2=A00xc04949c9 in db_fncall (dummy1=3D-979506816, dummy2=3D0, > dummy3=3D-1068655593, dummy4=3D0xf3c47988 "@\231\235=EF=BF=BD001") at > /usr/src/sys/ddb/db_command.c:548 > #2 =C2=A00xc0494dc1 in db_command (last_cmdp=3D0xc0989c9c, cmd_table=3D0x= 0, > dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > #3 =C2=A00xc0494f1a in db_command_loop () at /usr/src/sys/ddb/db_command.= c:498 > #4 =C2=A00xc0496d7d in db_trap (type=3D3, code=3D0) at > /usr/src/sys/ddb/db_main.c:229 #5 =C2=A00xc06579d6 in kdb_trap (type=3D3,= code=3D0, > tf=3D0xf3c47b2c) at > /usr/src/sys/kern/subr_kdb.c:534 > #6 =C2=A00xc088bdce in trap (frame=3D0xf3c47b2c) at > /usr/src/sys/i386/i386/trap.c:685 #7 =C2=A00xc086f6fb in calltrap () at > /usr/src/sys/i386/i386/exception.s:165 #8 =C2=A00xc0657b5a in kdb_enter > (why=3D0xc08f8592 "panic", msg=3D0xc08f8592 "panic") at cpufunc.h:71 > #9 =C2=A00xc062a1a6 in panic (fmt=3D0xc08f6f47 "mtx_lock() of destroyed m= utex > @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:559 > #10 0xc061a925 in _mtx_lock_flags (m=3D0xc6af26b8, opts=3D0, > file=3D0xc858faff > "/usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c", > line=3D1697) at /usr/src/sys/kern/kern_mutex.c:174 > #11 0xc857445e in ieee80211_node_delucastkey (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1697 > #12 0xc85760d6 in node_free (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:999 > #13 0xc8573992 in _ieee80211_free_node (ni=3D0xc6af8000) at > /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1622 > #14 0xc84f5af0 in uath_bulk_tx_callback () from /boot/kernel/if_uath.ko > #15 0xc0594d27 in usb2_callback_wrapper (pq=3D0xc9448030) at > /usr/src/sys/dev/usb/usb_transfer.c:1962 > #16 0xc0592716 in usb2_command_wrapper (pq=3D0xc9448030, xfer=3D0x0) at > /usr/src/sys/dev/usb/usb_transfer.c:2538 > #17 0xc05927f8 in usb2_callback_proc (_pm=3D0xc9448044) at > /usr/src/sys/dev/usb/usb_transfer.c:1834 > #18 0xc058febe in usb2_process (arg=3D0xc58d8ca4) at > /usr/src/sys/dev/usb/usb_process.c:139 > #19 0xc06036e8 in fork_exit (callout=3D0xc058fde0 , > arg=3D0xc58d8ca4, frame=3D0xf3c47d38) at /usr/src/sys/kern/kern_fork.c:830 > #20 0xc086f7a0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 Regarding the first panic, there seems to be a detach race in both upgt and= =20 uath, which is not USB related. Try this patch: http://perforce.freebsd.org/chv.cgi?CH=3D162250 =2D-HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 09:00:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4503106564A for ; Mon, 18 May 2009 09:00:55 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC4A8FC0C for ; Mon, 18 May 2009 09:00:54 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n4I90ruV078420 for ; Mon, 18 May 2009 10:00:53 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A1123C5.3070507@fletchermoorland.co.uk> Date: Mon, 18 May 2009 10:00:53 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 09:00:56 -0000 Hi, I am currently in the process of moving all my data around, going from a single zfs drive (ex-mirror) to a zfs raidz. I have used cpio to copy the data to the new pool, but a du shows a big difference in the results. Does anyone have any ideas, or does a "du -h ." not do what I think it should? Cheers Paul demophon# uname -a FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Fri May 15 16:48:17 BST 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 demophon# zpool status pool: DemoPool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM DemoPool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad20p3 ONLINE 0 0 0 ad18p3 ONLINE 0 0 0 ad16p4 ONLINE 0 0 0 errors: No known data errors pool: zfsroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zfsroot ONLINE 0 0 0 ad16p3 ONLINE 0 0 0 errors: No known data errors demophon# mount zfsroot/root on / (zfs, local) devfs on /dev (devfs, local) DemoPool on /DemoPool (zfs, local) DemoPool/root on /DemoPool/root (zfs, local) DemoPool/tmp on /DemoPool/tmp (zfs, local) DemoPool/usr on /DemoPool/usr (zfs, local) DemoPool/var on /DemoPool/var (zfs, local) zfsroot/tmp on /tmp (zfs, local) zfsroot/usr on /usr (zfs, local) zfsroot/var on /var (zfs, local) demophon# pwd /DemoPool/var/tmp/kdecache-paul/kpc demophon# ls -lah total 1282522 drwx------ 2 paul paul 25B May 15 19:35 . drwx------ 11 paul paul 16B May 15 19:36 .. -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index -rw-r--r-- 1 paul paul 15M May 15 17:52 kde-icon-cache.data -rw-r--r-- 1 paul paul 4.1M May 15 19:35 kde-icon-cache.index -rw-r--r-- 1 paul paul 0B May 15 19:35 kde-icon-cache.updated -rw-r--r-- 1 paul paul 5.0M May 6 16:48 kdiamond-cache.data -rw-r--r-- 1 paul paul 1.3M May 6 16:48 kdiamond-cache.index -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Atelier.data -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Atelier.index -rw-r--r-- 1 paul paul 120M May 4 18:18 plasma_theme_Aya.data -rw-r--r-- 1 paul paul 32M May 4 18:18 plasma_theme_Aya.index -rw-r--r-- 1 paul paul 120M May 15 18:20 plasma_theme_Elegance.data -rw-r--r-- 1 paul paul 32M May 15 19:01 plasma_theme_Elegance.index -rw-r--r-- 1 paul paul 120M Mar 22 19:17 plasma_theme_Glassified.data -rw-r--r-- 1 paul paul 32M Mar 22 20:05 plasma_theme_Glassified.index -rw-r--r-- 1 paul paul 120M Mar 20 08:53 plasma_theme_Led revolution.data -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Led revolution.index -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Oxyook.data -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_Oxyook.index -rw-r--r-- 1 paul paul 120M May 4 18:19 plasma_theme_default.data -rw-r--r-- 1 paul paul 32M May 4 18:19 plasma_theme_default.index -rw-r--r-- 1 paul paul 120M Mar 20 08:55 plasma_theme_spoons.data -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_spoons.index demophon# du -h . 1.2G . demophon# demophon# pwd /var/tmp/kdecache-paul/kpc demophon# ls -lah total 7833 drwx------ 2 paul paul 25B May 18 09:37 . drwx------ 11 paul paul 16B May 18 09:12 .. -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index -rw-r--r-- 1 paul paul 15M May 18 09:37 kde-icon-cache.data -rw-r--r-- 1 paul paul 4.1M May 18 09:37 kde-icon-cache.index -rw-r--r-- 1 paul paul 0B May 18 09:37 kde-icon-cache.updated -rw-r--r-- 1 paul paul 5.0M May 6 16:48 kdiamond-cache.data -rw-r--r-- 1 paul paul 1.3M May 6 16:48 kdiamond-cache.index -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Atelier.data -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Atelier.index -rw-r--r-- 1 paul paul 120M May 4 18:18 plasma_theme_Aya.data -rw-r--r-- 1 paul paul 32M May 4 18:18 plasma_theme_Aya.index -rw-r--r-- 1 paul paul 120M May 18 09:37 plasma_theme_Elegance.data -rw-r--r-- 1 paul paul 32M May 18 09:37 plasma_theme_Elegance.index -rw-r--r-- 1 paul paul 120M Mar 22 19:17 plasma_theme_Glassified.data -rw-r--r-- 1 paul paul 32M Mar 22 20:05 plasma_theme_Glassified.index -rw-r--r-- 1 paul paul 120M Mar 20 08:53 plasma_theme_Led revolution.data -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Led revolution.index -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Oxyook.data -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_Oxyook.index -rw-r--r-- 1 paul paul 120M May 4 18:19 plasma_theme_default.data -rw-r--r-- 1 paul paul 32M May 4 18:19 plasma_theme_default.index -rw-r--r-- 1 paul paul 120M Mar 20 08:55 plasma_theme_spoons.data -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_spoons.index demophon# du -h . 7.6M . demophon# demophon# zfs list NAME USED AVAIL REFER MOUNTPOINT DemoPool 66.8G 382G 30.6K /DemoPool DemoPool/root 1.67G 382G 1.67G /DemoPool/root DemoPool/tmp 3.03G 382G 3.03G /DemoPool/tmp DemoPool/usr 59.6G 382G 59.6G /DemoPool/usr DemoPool/var 2.51G 382G 2.51G /DemoPool/var zfsroot 79.0G 145G 18K none zfsroot/root 1.78G 145G 1.78G / zfsroot/tmp 3.67G 145G 3.67G /tmp zfsroot/usr 72.1G 145G 59.2G /usr zfsroot/usr@auto.... (removed huge list for email) zfsroot/var 1.50G 145G 1.18G /var zfsroot/var@auto.... (removed huge list for email) demophon# From owner-freebsd-current@FreeBSD.ORG Mon May 18 09:19:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EB3B106564A for ; Mon, 18 May 2009 09:19:51 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 51AFD8FC19 for ; Mon, 18 May 2009 09:19:51 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:38063 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M5z0e-0005tj-ED for freebsd-current@freebsd.org; Mon, 18 May 2009 04:19:50 -0500 Date: Mon, 18 May 2009 04:19:35 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3935026275-1176285825-1242638388=:2825" X-Spam-Score: 0.0 (/) X-LERCTR-Spam-Score: 0.0 (/) X-Spam-Report: SpamScore (0.0/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_BD=0.077, TW_BF=0.077, TW_DR=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_XB=0.077 X-LERCTR-Spam-Report: SpamScore (0.0/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_BD=0.077, TW_BF=0.077, TW_DR=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_XB=0.077 DomainKey-Status: no signature Subject: Crash with heavy ZFS I/O (current of today) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 09:19:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3935026275-1176285825-1242638388=:2825 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Greetings, I seem to have found an issue with a kernel from today. Last "good" kernel was from 2009-05-08 or so. What I see is while Bacula is doing a differential backup the wired memory goes up to 3.3G (I have 4G real), and we start paging like crazy, and then we panic in ZFS's write routine. The system doesn't get all the way into the debugger, and doesn't get the entire panic out, nor does it cut a dump. Any ideas? dmesg attached. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 --3935026275-1176285825-1242638388=:2825 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg.boot Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Current dmesg Content-Disposition: attachment; filename=dmesg.boot Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4wLUNVUlJFTlQg IzE3OiBNb24gTWF5IDE4IDAzOjE0OjQxIENEVCAyMDA5DQogICAgcm9vdEBi b3JnLmxlcmN0ci5vcmc6L3Vzci9vYmovdXNyL3NyYy9zeXMvQk9SRw0KVGlt ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5 IDANCkNQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgICA1MTIw ICBAIDEuODZHSHogKDE4NjIuMDEtTUh6IEs4LWNsYXNzIENQVSkNCiAgT3Jp Z2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ZjYgIFN0ZXBwaW5nID0g Ng0KICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxN U1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1Ms SFRULFRNLFBCRT4NCiAgRmVhdHVyZXMyPTB4NGUzYmQ8U1NFMyxEVEVTNjQs TU9OLERTX0NQTCxWTVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxE Q0E+DQogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+ DQogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+DQogIFRTQzogUC1zdGF0ZSBp bnZhcmlhbnQNCnJlYWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIp DQphdmFpbCBtZW1vcnkgPSA0MTE5NzAzNTUyICgzOTI4IE1CKQ0KQUNQSSBB UElDIFRhYmxlOiA8UFRMVEQgIAkgQVBJQyAgPg0KRnJlZUJTRC9TTVA6IE11 bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzDQpGcmVlQlNE L1NNUDogMiBwYWNrYWdlKHMpIHggMiBjb3JlKHMpDQogY3B1MCAoQlNQKTog QVBJQyBJRDogIDANCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxDQogY3B1MiAo QVApOiBBUElDIElEOiAgNg0KIGNwdTMgKEFQKTogQVBJQyBJRDogIDcNClRo aXMgbW9kdWxlIChvcGVuc29sYXJpcykgY29udGFpbnMgY29kZSBjb3ZlcmVk IGJ5IHRoZQ0KQ29tbW9uIERldmVsb3BtZW50IGFuZCBEaXN0cmlidXRpb24g TGljZW5zZSAoQ0RETCkNCnNlZSBodHRwOi8vb3BlbnNvbGFyaXMub3JnL29z L2xpY2Vuc2luZy9vcGVuc29sYXJpc19saWNlbnNlLw0KaW9hcGljMCA8VmVy c2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZA0KaW9hcGljMSA8 VmVyc2lvbiAyLjA+IGlycXMgMjQtNDcgb24gbW90aGVyYm9hcmQNCmtiZDEg YXQga2JkbXV4MA0Kc21iaW9zMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJJT1M+ IGF0IGlvbWVtIDB4ZjYwYzAtMHhmNjBkZSBvbiBtb3RoZXJib2FyZA0Kc21i aW9zMDogVmVyc2lvbjogMi41DQpjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNy eXB0bz4gb24gbW90aGVyYm9hcmQNCmFjcGkwOiA8U01DSSBTTUNJU0xQMj4g b24gbW90aGVyYm9hcmQNCmFjcGkwOiBbSVRIUkVBRF0NCmFjcGkwOiBQb3dl ciBCdXR0b24gKGZpeGVkKQ0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJl cXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwDQphY3BpX3RpbWVyMDog PDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgx MDBiIG9uIGFjcGkwDQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZl bnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3Bp MA0KVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBx dWFsaXR5IDkwMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9y dCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjANCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDIuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MQ0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kxDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li Mg0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kyDQpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li Mw0KcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4w IG9uIHBjaTMNCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0DQpwY2li NTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIgb24gcGNp Mw0KcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUNCnBjaWI2OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE4IGF0IGRldmljZSAyLjAgb24gcGNp Mg0KcGNpNjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjYNCmVtMDogPEludGVs KFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuOT4gcG9ydCAw eDIwMDAtMHgyMDFmIG1lbSAweGQ4MDAwMDAwLTB4ZDgwMWZmZmYgaXJxIDE4 IGF0IGRldmljZSAwLjAgb24gcGNpNg0KZW0wOiBVc2luZyBNU0kgaW50ZXJy dXB0DQplbTA6IFtGSUxURVJdDQplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjMwOjQ4OjhlOjlmOmYzDQplbTE6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3 b3JrIENvbm5lY3Rpb24gNi45Ljk+IHBvcnQgMHgyMDIwLTB4MjAzZiBtZW0g MHhkODAyMDAwMC0weGQ4MDNmZmZmIGlycSAxOSBhdCBkZXZpY2UgMC4xIG9u IHBjaTYNCmVtMTogVXNpbmcgTVNJIGludGVycnVwdA0KZW0xOiBbRklMVEVS XQ0KZW0xOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODo4ZTo5ZjpmMg0K cGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4zIG9u IHBjaTENCnBjaTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3DQpwY2liODog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMA0K cGNpODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgNCnBjaWI5OiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwDQpwY2k5OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQ0KcGNpMDogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDguMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpYjEw OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4w IG9uIHBjaTANCnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTANCnVo Y2kwOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xs ZXIgVVNCLTE+IHBvcnQgMHgxODAwLTB4MTgxZiBpcnEgMTcgYXQgZGV2aWNl IDI5LjAgb24gcGNpMA0KdWhjaTA6IFtJVEhSRUFEXQ0KdWhjaTA6IExlZ1N1 cCA9IDB4MDAzYg0KdXNidXMwOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMx MDAgVVNCIGNvbnRyb2xsZXIgVVNCLTE+IG9uIHVoY2kwDQp1aGNpMTogPElu dGVsIDYzMVhFU0IvNjMyWEVTQi8zMTAwIFVTQiBjb250cm9sbGVyIFVTQi0y PiBwb3J0IDB4MTgyMC0weDE4M2YgaXJxIDE5IGF0IGRldmljZSAyOS4xIG9u IHBjaTANCnVoY2kxOiBbSVRIUkVBRF0NCnVoY2kxOiBMZWdTdXAgPSAweDAw MTANCnVzYnVzMTogPEludGVsIDYzMVhFU0IvNjMyWEVTQi8zMTAwIFVTQiBj b250cm9sbGVyIFVTQi0yPiBvbiB1aGNpMQ0KdWhjaTI6IDxJbnRlbCA2MzFY RVNCLzYzMlhFU0IvMzEwMCBVU0IgY29udHJvbGxlciBVU0ItMz4gcG9ydCAw eDE4NDAtMHgxODVmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwDQp1 aGNpMjogW0lUSFJFQURdDQp1aGNpMjogTGVnU3VwID0gMHgwMDEwDQp1c2J1 czI6IDxJbnRlbCA2MzFYRVNCLzYzMlhFU0IvMzEwMCBVU0IgY29udHJvbGxl ciBVU0ItMz4gb24gdWhjaTINCmVoY2kwOiA8SW50ZWwgNjNYWEVTQiBVU0Ig Mi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTAwNDAwLTB4ZDg1MDA3ZmYgaXJx IDE3IGF0IGRldmljZSAyOS43IG9uIHBjaTANCmVoY2kwOiBbSVRIUkVBRF0N CnVzYnVzMzogRUhDSSB2ZXJzaW9uIDEuMA0KdXNidXMzOiA8SW50ZWwgNjNY WEVTQiBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwDQpwY2liMTE6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwDQpw Y2kxMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjExDQp2Z2FwY2kwOiA8VkdB LWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDMwMDAtMHgzMGZmIG1lbSAw eGQwMDAwMDAwLTB4ZDdmZmZmZmYsMHhkODIwMDAwMC0weGQ4MjBmZmZmIGly cSAxOCBhdCBkZXZpY2UgMS4wIG9uIHBjaTExDQpkcm0wOiA8QVRJIEVTMTAw MCBSTjUwPiBvbiB2Z2FwY2kwDQp2Z2FwY2kwOiBjaGlsZCBkcm0wIHJlcXVl c3RlZCBwY2lfZW5hYmxlX2J1c21hc3Rlcg0KaW5mbzogW2RybV0gSW5pdGlh bGl6ZWQgcmFkZW9uIDEuMjkuMCAyMDA4MDUyOA0KaXNhYjA6IDxQQ0ktSVNB IGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMA0KaXNhMDogPElTQSBi dXM+IG9uIGlzYWIwDQphdGFwY2kwOiA8SW50ZWwgNjNYWEVTQjIgVURNQTEw MCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4 MTc3LDB4Mzc2LDB4MTg2MC0weDE4NmYgYXQgZGV2aWNlIDMxLjEgb24gcGNp MA0KYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTANCmF0YTA6IFtJ VEhSRUFEXQ0KYXRhcGNpMTogPEludGVsIDYzWFhFU0IyIFNBVEEzMDAgY29u dHJvbGxlcj4gcG9ydCAweDE4YTAtMHgxOGE3LDB4MTg3NC0weDE4NzcsMHgx ODc4LTB4MTg3ZiwweDE4NzAtMHgxODczLDB4MTg4MC0weDE4OWYgbWVtIDB4 ZDg1MDA4MDAtMHhkODUwMGJmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24g cGNpMA0KYXRhcGNpMTogW0lUSFJFQURdDQphdGFwY2kxOiBBSENJIGNhbGxl ZCBmcm9tIHZlbmRvciBzcGVjaWZpYyBkcml2ZXINCmF0YXBjaTE6IEFIQ0kg VmVyc2lvbiAwMS4xMCBjb250cm9sbGVyIHdpdGggNiBwb3J0cyBQTSBzdXBw b3J0ZWQNCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxDQphdGEy OiBbSVRIUkVBRF0NCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kx DQphdGEzOiBbSVRIUkVBRF0NCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBvbiBh dGFwY2kxDQphdGE0OiBbSVRIUkVBRF0NCmF0YTU6IDxBVEEgY2hhbm5lbCAz PiBvbiBhdGFwY2kxDQphdGE1OiBbSVRIUkVBRF0NCmF0YTY6IDxBVEEgY2hh bm5lbCA0PiBvbiBhdGFwY2kxDQphdGE2OiBbSVRIUkVBRF0NCmF0YTc6IDxB VEEgY2hhbm5lbCA1PiBvbiBhdGFwY2kxDQphdGE3OiBbSVRIUkVBRF0NCmlj aHNtYjA6IDxJbnRlbCA2MzF4RVNCLzYzMjFFU0IgKEVTQjIpIFNNQnVzIGNv bnRyb2xsZXI+IHBvcnQgMHgxMTAwLTB4MTExZiBpcnEgMTkgYXQgZGV2aWNl IDMxLjMgb24gcGNpMA0KaWNoc21iMDogW0lUSFJFQURdDQpzbWJ1czA6IDxT eXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjANCnNtYjA6IDxTTUJ1 cyBnZW5lcmljIEkvTz4gb24gc21idXMwDQphY3BpX2J1dHRvbjA6IDxQb3dl ciBCdXR0b24+IG9uIGFjcGkwDQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9j az4gcG9ydCAweDcwLTB4NzEgb24gYWNwaTANCmF0a2JkYzA6IDxLZXlib2Fy ZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9u IGFjcGkwDQphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MA0Ka2JkMCBhdCBhdGtiZDANCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NCmF0 a2JkMDogW0lUSFJFQURdDQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9u IGF0a2JkYzANCnBzbTA6IFtHSUFOVC1MT0NLRURdDQpwc20wOiBbSVRIUkVB RF0NCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMNCnVh cnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBp cnEgNCBmbGFncyAweDEwIG9uIGFjcGkwDQp1YXJ0MDogW0ZJTFRFUl0NCnVh cnQxOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDJmOC0weDJmZiBp cnEgMyBvbiBhY3BpMA0KdWFydDE6IFtGSUxURVJdDQpmZGMwOiA8ZmxvcHB5 IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJx IDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IFtGSUxURVJdDQpmZDA6IDwxNDQw LUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMA0KcHBjMDogPFBhcmFs bGVsIHBvcnQ+IHBvcnQgMHgzNzgtMHgzN2YsMHg3NzgtMHg3N2YgaXJxIDcg ZHJxIDMgb24gYWNwaTANCnBwYzA6IFNNQy1saWtlIGNoaXBzZXQgKEVDUC9F UFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlDQpwcGMwOiBGSUZP IHdpdGggMTYvMTYvOSBieXRlcyB0aHJlc2hvbGQNCnBwYzA6IFtJVEhSRUFE XQ0KcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzANCmxwdDA6 IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IFtJVEhSRUFEXQ0KbHB0MDog SW50ZXJydXB0LWRyaXZlbiBwb3J0DQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBv biBwcGJ1czANCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTANCmNvcmV0ZW1w MDogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwDQplc3Qw OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBj cHUwDQpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4g b24gY3B1MA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY29yZXRlbXAx OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTENCmVzdDE6 IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNw dTENCnA0dGNjMTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHUxDQpjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpjb3JldGVtcDI6 IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Mg0KZXN0Mjog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1 Mg0KcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9u IGNwdTINCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTANCmNvcmV0ZW1wMzog PENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUzDQplc3QzOiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUz DQpwNHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24g Y3B1Mw0KaXBtaTA6IDxJUE1JIFN5c3RlbSBJbnRlcmZhY2U+IG9uIGlzYTAN CmlwbWkwOiBLQ1MgbW9kZSBmb3VuZCBhdCBpbyAweGNhMiBhbGlnbm1lbnQg MHgxIG9uIGlzYQ0Kb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21lbSAw eGMwMDAwLTB4Y2FmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+ IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwxNiB2aXJ0dWFs IGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnZnYTA6IDxHZW5lcmljIElTQSBW R0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZm IG9uIGlzYTANCldBUk5JTkc6IFpGUyBpcyBjb25zaWRlcmVkIHRvIGJlIGFu IGV4cGVyaW1lbnRhbCBmZWF0dXJlIGluIEZyZWVCU0QuDQpUaW1lY291bnRl cnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQp1c2J1czA6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wDQp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wDQp1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wDQp1 c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMA0KWkZTIGZpbGVz eXN0ZW0gdmVyc2lvbiAxMw0KWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDEz DQp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMA0KdWh1YjA6IDxJbnRlbCBV SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMwDQp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQ0KdWh1 YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXMxDQp1Z2VuMi4xOiA8SW50ZWw+IGF0 IHVzYnVzMg0KdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyDQp1Z2VuMy4x OiA8SW50ZWw+IGF0IHVzYnVzMw0KdWh1YjM6IDxJbnRlbCBFSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMzDQphY2QwOiBETUEgbGltaXRlZCB0byBVRE1BMzMsIGNvbnRyb2xsZXIg Zm91bmQgbm9uLUFUQTY2IGNhYmxlDQphY2QwOiBEVkRSIDxNZW1vcmV4IERW RCstUkFNIDUxMEwgdjEvTVdTNz4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzDQph ZDQ6IDM4MTU1NE1CIDxTZWFnYXRlIFNUMzQwMDYyMEFTIDMuQUFKPiBhdCBh dGEyLW1hc3RlciBTQVRBMzAwDQphZDY6IDM4MTU1NE1CIDxTZWFnYXRlIFNU MzQwMDYyMEFTIDMuQUFKPiBhdCBhdGEzLW1hc3RlciBTQVRBMzAwDQphZDg6 IDQ3Njk0ME1CIDxTZWFnYXRlIFNUMzUwMDYzMEFTIDMuQUFFPiBhdCBhdGE0 LW1hc3RlciBTQVRBMzAwDQphZDEwOiAzODE1NTRNQiA8U2VhZ2F0ZSBTVDM0 MDA2MjBBUyAzLkFBSj4gYXQgYXRhNS1tYXN0ZXIgU0FUQTMwMA0KYWQxMjog MzgxNTU0TUIgPFNlYWdhdGUgU1QzNDAwNjIwQVMgMy5BQUo+IGF0IGF0YTYt bWFzdGVyIFNBVEEzMDANCmFkMTQ6IDM4MTU1NE1CIDxTZWFnYXRlIFNUMzQw MDYyMEFTIDMuQUFKPiBhdCBhdGE3LW1hc3RlciBTQVRBMzAwDQppcG1pMDog SVBNSSBkZXZpY2UgcmV2LiAxLCBmaXJtd2FyZSByZXYuIDEuMiwgdmVyc2lv biAyLjANCmlwbWkwOiBOdW1iZXIgb2YgY2hhbm5lbHMgOA0KaXBtaTA6IEF0 dGFjaGVkIHdhdGNoZG9nDQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQNCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQpHRU9NOiBhZDRzMTogZ2VvbWV0cnkg ZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1NWgsNjNzICE9IDE2aCw2M3MpLg0K R0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkNHMxYSBpcyB1ZnNp ZC80NjFhZGI3NDRiMzI4OGE0Lg0KdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1Z2VuMy4yOiA8UGVwcGVyY29uIEFH PiBhdCB1c2J1czMNCnVtczA6IDxQZXBwZXJjb24gQUcgTXVsdGlkZXZpY2Us IGNsYXNzIDAvMCwgcmV2IDIuMDAvMC4wMSwgYWRkciAyPiBvbiB1c2J1czMN CnVtczA6IDMgYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9MA0K dWtiZDA6IDxQZXBwZXJjb24gQUcgTXVsdGlkZXZpY2UsIGNsYXNzIDAvMCwg cmV2IDIuMDAvMC4wMSwgYWRkciAyPiBvbiB1c2J1czMNCmtiZDIgYXQgdWti ZDANCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBh c2M9MHgyNCBhc2NxPTB4MDAgDQoocHJvYmUwOmF0YTA6MDowOjApOiBURVNU IFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgDQoocHJvYmUwOmF0YTA6 MDowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcg0KKHByb2Jl MDphdGEwOjA6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbg0K KHByb2JlMDphdGEwOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQoocHJv YmUwOmF0YTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQNCihwcm9iZTA6 YXRhMDowOjA6MCk6IFVucmV0cnlhYmxlIGVycm9yDQphY2QwOiBGQUlMVVJF IC0gSU5RVUlSWSBJTExFR0FMIFJFUVVFU1QgYXNjPTB4MjQgYXNjcT0weDAw IA0KY2QwIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCmNkMDogPE1l bW9yZXggRFZEKy1SQU0gNTEwTCB2MSBNV1M3PiBSZW1vdmFibGUgQ0QtUk9N IFNDU0ktMCBkZXZpY2UgDQpjZDA6IDMzLjAwME1CL3MgdHJhbnNmZXJzDQpj ZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1Qg UkVBRFksIE1lZGl1bSBub3QgcHJlc2VudA0KU01QOiBBUCBDUFUgIzEgTGF1 bmNoZWQhDQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCENClNNUDogQVAgQ1BV ICMzIExhdW5jaGVkIQ0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6 L2Rldi9hZDRzMWENCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJseSBkaXNt b3VudGVkDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80NjFhZGI3NDRiMzI4 OGE0IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIg YWQ0czFhIGlzIHVmc2lkLzQ2MWFkYjc0NGIzMjg4YTQuDQpHRU9NX0xBQkVM OiBMYWJlbCB1ZnNpZC80NjFhZGI3NDRiMzI4OGE0IHJlbW92ZWQuDQplbTA6 IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0K --3935026275-1176285825-1242638388=:2825-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 11:28:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4967410656B6 for ; Mon, 18 May 2009 11:28:25 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 12E0B8FC14 for ; Mon, 18 May 2009 11:28:23 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by ewy3 with SMTP id 3so3811968ewy.43 for ; Mon, 18 May 2009 04:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=akA9+3p2x2BOixgiOPwcfh7rmDXmnGEMSCf4+Wzrrnw=; b=oO5tLGlh0j+drRAgG656jy0riDWDXIbJDwyPjI1K8Mre5qSBvCoJHaZGCdwxzEN595 0VOvT8gYziqmlvMRExQ1jRQz8KNmyErCUpGuCibC5BJ0fPYwiqa810/nHsNCLQpSdMPr Dusm6EPRZIoP7NiU/nLPRZfnAehHYqIdmQglo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zs8tTYuo7wypMTydfoPRmJj6keulHxUImVEulUzCkB2luObcH19deumeH+NCcT8I7u rlhqCQbv1K7fU/8Sj7Z9YJrBJYLm0/vpRO387rUKe0yv5+Ba3ofbcV+6RPs76eUVXRN6 7nSzdVGy4tEIYqzFK2stLcol8obJpE7B6eEd4= MIME-Version: 1.0 Received: by 10.216.53.12 with SMTP id f12mr2027252wec.72.1242646102524; Mon, 18 May 2009 04:28:22 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Mon, 18 May 2009 15:28:22 +0400 Message-ID: <19e7832a0905180428l564f4e74s9d8ce3213228b08e@mail.gmail.com> From: Andrey Fesenko To: Martin Wilke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 11:28:25 -0000 On Sun, May 17, 2009 at 10:09 PM, Martin Wilke wrote: > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin > FreeBSD 8.0-CURRENT #0: Sun May 17 07:56:14 MSD 2009 amd64 new port virtualbox_2.tgz make - OK install - OK load module - OK run -OK run VM - crush :( only 1 time. more have not yet tried. From owner-freebsd-current@FreeBSD.ORG Mon May 18 12:12:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEF0106564A for ; Mon, 18 May 2009 12:12:19 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1879D8FC17 for ; Mon, 18 May 2009 12:12:18 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: (qmail invoked by alias); 18 May 2009 12:12:16 -0000 Received: from f053098008.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [78.53.98.8] by mail.gmx.net (mp069) with SMTP; 18 May 2009 14:12:16 +0200 X-Authenticated: #3549759 X-Provags-ID: V01U2FsdGVkX1+X2gI7/6iXGgDbHqzHIcq5opszvSxg1O/OwoTEnJ X+42DbzIJaw2KS Received: by myhost.mydomain.de (Postfix, from userid 1001) id DC9EE41; Mon, 18 May 2009 14:12:11 +0200 (CEST) From: Christof Schulze To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 14:12:08 +0200 User-Agent: KMail/1.11.1 (FreeBSD/7.2-RELEASE; KDE/4.2.3; amd64; ; ) References: <4A1123C5.3070507@fletchermoorland.co.uk> In-Reply-To: <4A1123C5.3070507@fletchermoorland.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1432878.lPTJxlB0vN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905181412.11460.christof.schulze@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 12:12:19 -0000 --nextPart1432878.lPTJxlB0vN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag 18 Mai 2009 11:00:53 schrieb Paul Wootton: > Hi, > > I am currently in the process of moving all my data around, going from a > single zfs drive (ex-mirror) to a zfs raidz. > I have used cpio to copy the data to the new pool, but a du shows a big > difference in the results. > > Does anyone have any ideas, or does a "du -h ." not do what I think it > should? it is a known bug (at least for the solaris folks) that du does not display= =20 disk usage correctly on raidz. But of course different compression algorithms come into play as well. Regards, Christof > > Cheers > Paul > > > > demophon# uname -a > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Fri May 15 > 16:48:17 BST 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > > > demophon# zpool status > pool: DemoPool > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > DemoPool ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad20p3 ONLINE 0 0 0 > ad18p3 ONLINE 0 0 0 > ad16p4 ONLINE 0 0 0 > > errors: No known data errors > > pool: zfsroot > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > zfsroot ONLINE 0 0 0 > ad16p3 ONLINE 0 0 0 > > errors: No known data errors > > > > demophon# mount > zfsroot/root on / (zfs, local) > devfs on /dev (devfs, local) > DemoPool on /DemoPool (zfs, local) > DemoPool/root on /DemoPool/root (zfs, local) > DemoPool/tmp on /DemoPool/tmp (zfs, local) > DemoPool/usr on /DemoPool/usr (zfs, local) > DemoPool/var on /DemoPool/var (zfs, local) > zfsroot/tmp on /tmp (zfs, local) > zfsroot/usr on /usr (zfs, local) > zfsroot/var on /var (zfs, local) > > > > demophon# pwd > /DemoPool/var/tmp/kdecache-paul/kpc > demophon# ls -lah > total 1282522 > drwx------ 2 paul paul 25B May 15 19:35 . > drwx------ 11 paul paul 16B May 15 19:36 .. > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index > -rw-r--r-- 1 paul paul 15M May 15 17:52 kde-icon-cache.data > -rw-r--r-- 1 paul paul 4.1M May 15 19:35 kde-icon-cache.index > -rw-r--r-- 1 paul paul 0B May 15 19:35 kde-icon-cache.updated > -rw-r--r-- 1 paul paul 5.0M May 6 16:48 kdiamond-cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:48 kdiamond-cache.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Atelier.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Atelier.index > -rw-r--r-- 1 paul paul 120M May 4 18:18 plasma_theme_Aya.data > -rw-r--r-- 1 paul paul 32M May 4 18:18 plasma_theme_Aya.index > -rw-r--r-- 1 paul paul 120M May 15 18:20 plasma_theme_Elegance.data > -rw-r--r-- 1 paul paul 32M May 15 19:01 > plasma_theme_Elegance.index -rw-r--r-- 1 paul paul 120M Mar 22 > 19:17 plasma_theme_Glassified.data -rw-r--r-- 1 paul paul 32M Mar > 22 20:05 plasma_theme_Glassified.index -rw-r--r-- 1 paul paul 120M > Mar 20 08:53 plasma_theme_Led > revolution.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Led > revolution.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Oxyook.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_Oxyook.index > -rw-r--r-- 1 paul paul 120M May 4 18:19 plasma_theme_default.data > -rw-r--r-- 1 paul paul 32M May 4 18:19 plasma_theme_default.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:55 plasma_theme_spoons.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_spoons.index > demophon# du -h . > 1.2G . > demophon# > > > > demophon# pwd > /var/tmp/kdecache-paul/kpc > demophon# ls -lah > total 7833 > drwx------ 2 paul paul 25B May 18 09:37 . > drwx------ 11 paul paul 16B May 18 09:12 .. > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index > -rw-r--r-- 1 paul paul 15M May 18 09:37 kde-icon-cache.data > -rw-r--r-- 1 paul paul 4.1M May 18 09:37 kde-icon-cache.index > -rw-r--r-- 1 paul paul 0B May 18 09:37 kde-icon-cache.updated > -rw-r--r-- 1 paul paul 5.0M May 6 16:48 kdiamond-cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:48 kdiamond-cache.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Atelier.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Atelier.index > -rw-r--r-- 1 paul paul 120M May 4 18:18 plasma_theme_Aya.data > -rw-r--r-- 1 paul paul 32M May 4 18:18 plasma_theme_Aya.index > -rw-r--r-- 1 paul paul 120M May 18 09:37 plasma_theme_Elegance.data > -rw-r--r-- 1 paul paul 32M May 18 09:37 > plasma_theme_Elegance.index -rw-r--r-- 1 paul paul 120M Mar 22 > 19:17 plasma_theme_Glassified.data -rw-r--r-- 1 paul paul 32M Mar > 22 20:05 plasma_theme_Glassified.index -rw-r--r-- 1 paul paul 120M > Mar 20 08:53 plasma_theme_Led > revolution.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:54 plasma_theme_Led > revolution.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:54 plasma_theme_Oxyook.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_Oxyook.index > -rw-r--r-- 1 paul paul 120M May 4 18:19 plasma_theme_default.data > -rw-r--r-- 1 paul paul 32M May 4 18:19 plasma_theme_default.index > -rw-r--r-- 1 paul paul 120M Mar 20 08:55 plasma_theme_spoons.data > -rw-r--r-- 1 paul paul 32M Mar 20 08:55 plasma_theme_spoons.index > demophon# du -h . > 7.6M . > demophon# > > > > demophon# zfs > list > NAME USED AVAIL REFER > MOUNTPOINT > DemoPool 66.8G 382G 30.6K > /DemoPool > DemoPool/root 1.67G 382G 1.67G /DemoPool/root > DemoPool/tmp 3.03G 382G 3.03G /DemoPool/tmp > DemoPool/usr 59.6G 382G 59.6G /DemoPool/usr > DemoPool/var 2.51G 382G 2.51G /DemoPool/var > zfsroot 79.0G 145G 18K > none > zfsroot/root 1.78G 145G 1.78G > / > zfsroot/tmp 3.67G 145G 3.67G > /tmp > zfsroot/usr 72.1G 145G 59.2G > /usr > zfsroot/usr@auto.... (removed huge list for email) > zfsroot/var 1.50G 145G 1.18G /var > zfsroot/var@auto.... (removed huge list for email) > demophon# > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" --nextPart1432878.lPTJxlB0vN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoRUJsACgkQpZfyPAmdZJkPGgCgkSs3EY3DBMZnvgU6Hcho0cik QaEAoPdoc08cBMHTU2/DamiNA+rQgjQW =+jfq -----END PGP SIGNATURE----- --nextPart1432878.lPTJxlB0vN-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 12:55:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E537106566C for ; Mon, 18 May 2009 12:55:28 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 94B258FC1D for ; Mon, 18 May 2009 12:55:27 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n4ICtQex083533; Mon, 18 May 2009 13:55:26 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A115ABE.6070904@fletchermoorland.co.uk> Date: Mon, 18 May 2009 13:55:26 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A1123C5.3070507@fletchermoorland.co.uk> <200905181412.11460.christof.schulze@gmx.net> In-Reply-To: <200905181412.11460.christof.schulze@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christof Schulze Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 12:55:28 -0000 Christof Schulze wrote: > Am Montag 18 Mai 2009 11:00:53 schrieb Paul Wootton: > >> Hi, >> >> I am currently in the process of moving all my data around, going from a >> single zfs drive (ex-mirror) to a zfs raidz. >> I have used cpio to copy the data to the new pool, but a du shows a big >> difference in the results. >> >> Does anyone have any ideas, or does a "du -h ." not do what I think it >> should? >> > it is a known bug (at least for the solaris folks) that du does not display > disk usage correctly on raidz. > > But of course different compression algorithms come into play as well. > > Regards, > > Christof > In this instance, the du from the raidz pool is actually correct. A zfs list shows less space (incorrect) on the single drive compared to the raidz. Doing a tar on both directories gives 2 1.2G files so the data is actually present on both packs (plus I used CPIO to copy the data from the single to the raidz) Is it possible for data corruption on the single drive to not show the extra space as being used? From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:00:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44528106564A for ; Mon, 18 May 2009 13:00:21 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id C25988FC14 for ; Mon, 18 May 2009 13:00:20 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n4ID0HH5079992; Mon, 18 May 2009 17:00:17 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 18 May 2009 17:00:17 +0400 (MSD) From: Dmitry Morozovsky To: Paul Wootton In-Reply-To: <4A115ABE.6070904@fletchermoorland.co.uk> Message-ID: References: <4A1123C5.3070507@fletchermoorland.co.uk> <200905181412.11460.christof.schulze@gmx.net> <4A115ABE.6070904@fletchermoorland.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Mon, 18 May 2009 17:00:17 +0400 (MSD) Cc: freebsd-current@freebsd.org, Christof Schulze Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:00:21 -0000 On Mon, 18 May 2009, Paul Wootton wrote: PW> > > I am currently in the process of moving all my data around, going from a PW> > > single zfs drive (ex-mirror) to a zfs raidz. PW> > > I have used cpio to copy the data to the new pool, but a du shows a big PW> > > difference in the results. PW> > > PW> > > Does anyone have any ideas, or does a "du -h ." not do what I think it PW> > > should? PW> > > PW> > it is a known bug (at least for the solaris folks) that du does not PW> > display disk usage correctly on raidz. PW> > PW> > But of course different compression algorithms come into play as well. PW> > PW> In this instance, the du from the raidz pool is actually correct. PW> A zfs list shows less space (incorrect) on the single drive compared to the PW> raidz. PW> Doing a tar on both directories gives 2 1.2G files so the data is actually PW> present on both packs (plus I used CPIO to copy the data from the single to PW> the raidz) PW> PW> Is it possible for data corruption on the single drive to not show the extra PW> space as being used? Ehmm, possibly stupid question: sparse files? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:02:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58BEF106564A for ; Mon, 18 May 2009 13:02:34 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id D90318FC18 for ; Mon, 18 May 2009 13:02:33 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 14682 invoked by uid 1002); 18 May 2009 13:02:31 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.92.165.253) by s217.sureserver.com with ESMTPA; 18 May 2009 13:02:31 -0000 Date: Mon, 18 May 2009 18:34:58 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: Ruben de Groot In-Reply-To: <20090518112739.GA97602@ei.bzerk.org> Message-ID: References: <20090518112739.GA97602@ei.bzerk.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: USB-to-serial adapter configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:02:34 -0000 On Mon, 18 May 2009, Ruben de Groot wrote: > On Mon, May 18, 2009 at 04:07:09PM +0000, Saifi Khan typed: > > Hi all: > > > > How does one configure settings for USB-to-serial adapter in FreeBSD ? > > > > The one i have purchased is > > http://www.usbgear.com/computer_cable_details.cfm?sku=CHEAP-SERIAL&cats=199&catid=482%2C1303%2C199%2C461%2C106%2C1009%2C601 > > > > On the Gentoo box, 'lsusb' displays it as: > > Bus 002 Device 003: ID 067b:2303 > > Prolific Technology, Inc. PL2303 Serial Port > > Your adapter should be recognised by the uplcom driver. put uplcom_load="YES" in loader.conf > or load manually. Check dmesg for the device name. > Also, I think cu is "good enough" ;) > > Ruben > This is the error shown in 'dmesg' log ugen0.2: at usbus0 uplcom0: on usbus0 uplcom0: init failed! device_attach: uplcom0 attach returned 6 uplcom0: on usbus0 uplcom0: init failed! device_attach: uplcom0 attach returned 6 Scenarios: 1. kldstat -v | grep uplcom shows 303 uhub/uplcom 2. uplcom_load="YES" in /boot/loader.conf with a reboot In both the scenarios, 'dmesg' shows the same error. On re-attaching the device, the following error is shown. usb2_alloc_device:1574: set address 2 failed (USB_ERR_STALLED, ignored) usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_STALLED! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:417: could not allocate new device! The output from 'usbconfig dump_info' shows ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON The 'dmesg' extract of USB is as follows: usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 uhub0: on usbus3 ugen4.1: at usbus4 uhub1: on usbus4 ugen0.1: at usbus0 uhub2: on usbus0 ugen1.1: at usbus1 uhub3: on usbus1 ugen2.1: at usbus2 uhub4: on usbus2 Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub1: 8 ports with 8 removable, self powered Here is the system information. FreeBSD bsd 8.0-CURRENT-200905 FreeBSD 8.0-CURRENT-200905 #0: Mon May 4 23:25:09 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Any suggestions on how i can get uplcom drive to work ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:07:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1A6B1065742; Mon, 18 May 2009 13:07:36 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6038FC2F; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICpxmi033977; Mon, 18 May 2009 07:51:59 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICpxYG033976; Mon, 18 May 2009 07:51:59 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4HI9kEs064315 for ; Sun, 17 May 2009 13:09:46 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 131EC154D59; Sun, 17 May 2009 18:09:35 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 51B9C10656D7; Sun, 17 May 2009 18:09:34 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D6A1065672; Sun, 17 May 2009 18:09:25 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 26CC88FC1A; Sun, 17 May 2009 18:09:24 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 9553D4AC5D; Sun, 17 May 2009 20:09:20 +0200 (CEST) Date: Sun, 17 May 2009 20:09:20 +0200 From: Martin Wilke To: ports@freebsd.org Message-ID: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20090514191237.GD70242@bsdcrew.de> User-Agent: Mutt/1.5.19 (2009-01-05) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:51:59 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 13:09:47 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 13:09:46 -0500 X-Spam-Status: NO, hits=-100.00 required=4.50 X-Spam-Report: Content analysis details: (-100.0 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | -100 USER_IN_WHITELIST From: address is in the user's white-list | Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We rolled a new tarball with the patch from Juergen Lock [1] with a posible fix for AMD64 users, tested on 3 machines which now works without problems. Many Thanks to him for his nice work! http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz Martin - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEARECAAYFAkoQUtAACgkQdLJIhLHm/OlY2QCg1KZW2YCvE1VhqKgSQ/xhjKIx U60Al2UMniKg+KvQ6m9RcP92eOMddfQ= =kB6c -----END PGP SIGNATURE----- _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:07:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9ECB1065749; Mon, 18 May 2009 13:07:36 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id ED0788FC2C; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICqUgg034630; Mon, 18 May 2009 07:52:30 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICqU76034629; Mon, 18 May 2009 07:52:30 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4IBsCXn023261 for ; Mon, 18 May 2009 06:54:12 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 21D291614F3; Mon, 18 May 2009 11:53:50 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D4D9F10656E4; Mon, 18 May 2009 11:53:49 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0594D1065670; Mon, 18 May 2009 11:53:42 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 347AA8FC1F; Mon, 18 May 2009 11:53:40 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by ewy3 with SMTP id 3so3825749ewy.43 for ; Mon, 18 May 2009 04:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=akA9+3p2x2BOixgiOPwcfh7rmDXmnGEMSCf4+Wzrrnw=; b=oO5tLGlh0j+drRAgG656jy0riDWDXIbJDwyPjI1K8Mre5qSBvCoJHaZGCdwxzEN595 0VOvT8gYziqmlvMRExQ1jRQz8KNmyErCUpGuCibC5BJ0fPYwiqa810/nHsNCLQpSdMPr Dusm6EPRZIoP7NiU/nLPRZfnAehHYqIdmQglo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zs8tTYuo7wypMTydfoPRmJj6keulHxUImVEulUzCkB2luObcH19deumeH+NCcT8I7u rlhqCQbv1K7fU/8Sj7Z9YJrBJYLm0/vpRO387rUKe0yv5+Ba3ofbcV+6RPs76eUVXRN6 7nSzdVGy4tEIYqzFK2stLcol8obJpE7B6eEd4= MIME-Version: 1.0 Received: by 10.216.53.12 with SMTP id f12mr2027252wec.72.1242646102524; Mon, 18 May 2009 04:28:22 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Mon, 18 May 2009 15:28:22 +0400 Message-ID: <19e7832a0905180428l564f4e74s9d8ce3213228b08e@mail.gmail.com> From: Andrey Fesenko To: Martin Wilke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:30 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Mon, 18 May 2009 06:54:18 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Mon, 18 May 2009 06:54:12 -0500 X-Spam-Status: NO, hits=-2.20 required=4.50 X-Spam-Report: Content analysis details: (-2.2 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:07:49 -0000 On Sun, May 17, 2009 at 10:09 PM, Martin Wilke wrote: > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin > FreeBSD 8.0-CURRENT #0: Sun May 17 07:56:14 MSD 2009 amd64 new port virtualbox_2.tgz make - OK install - OK load module - OK run -OK run VM - crush :( only 1 time. more have not yet tried. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:07:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07A9410656A8; Mon, 18 May 2009 13:07:36 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0FC8FC3F; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICptQn033896; Mon, 18 May 2009 07:51:55 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICptUL033895; Mon, 18 May 2009 07:51:55 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4HEYfGP054993 for ; Sun, 17 May 2009 09:34:41 -0500 (CDT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 79BC7178126; Sun, 17 May 2009 14:34:21 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6C0E21065709; Sun, 17 May 2009 14:34:21 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C6B1065680; Sun, 17 May 2009 14:33:54 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id 30DD48FC12; Sun, 17 May 2009 14:33:54 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail53.abv.bg (mail53.ni.bg [192.168.151.29]) by smtp-out.abv.bg (Postfix) with ESMTP id 256C287B64; Sun, 17 May 2009 17:16:37 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=Lmx7NW547QVCqK/ajTaOgqEmBwcK8ySvdGwBV0hUOdNzqLHtUUm0pjz0Lp8GJ5iRJ eV6FFUHNrRnoKXpOuKlLUDBMkhrWdR/NKvloZRhldR5uXVs7cmhGpNCW52SjqgmdvgO WILePWUrl7wSRLmuK1p3qlgE0VrNeOrEFX6aFMs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1242569797; bh=2kctKL6kjIfl74ejrWsFRju/QommEQpJc0Bcr2xCoC8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=bY3gtOboyyfc+g2nLLcgkgBoJplgflffg2mfZGLsoUmgzr0Esimhm0QC9MFxoX7HI bKy05oRolupwq2FUAJoxZdnRNARKdHNSe+4BjnPc8WQ+I1OAlZhAXe2Pm/zuwY/fHn sfK2ABAq8TkRp0KkSe12Oddce+htWZftpLctV9lU= Received: from mail53.abv.bg (localhost.localdomain [127.0.0.1]) by mail53.abv.bg (Postfix) with ESMTP id 3D36D1E4B0A; Sun, 17 May 2009 17:16:26 +0300 (EEST) Date: Sun, 17 May 2009 17:16:26 +0300 (EEST) From: Mario Pavlov To: freebsd-usb@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:51:55 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 09:35:11 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 09:34:41 -0500 X-Spam-Status: NO, hits=-2.20 required=4.50 X-Spam-Report: Content analysis details: (-2.2 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 0.0 DK_POLICY_TESTING Domain Keys: policy says domain is testing DK | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5690] | Cc: Subject: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:07:56 -0000 Hi, I just got a CCID USB reader with my digital signature...unfortunately I can't make it work I installed pcsc-lite and libccid from ports... when I plug-in the reader I can see this: ugen0: on uhub4 then I do this: # pcscd -d -f 00000000 pcscdaemon.c:267:main() pcscd set to foreground with debug send to stderr 00000427 pcscdaemon.c:505:main() pcsc-lite 1.5.1 daemon ready. 00196162 hotplug_libusb.c:477:HPAddHotPluggable() Adding USB device: /dev/usb4:/dev/ugen0 00000043 readerfactory.c:1083:RFInitializeReader() Attempting startup of ACS ACR 38U-CCID 00 00 using /usr/local/lib/pcsc/drivers//ifd-ccid.bundle/Contents/FreeBSD/libccid.so 00000207 readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0 00000036 ifdhandler.c:1377:init_driver() Driver version: 1.3.9 00000285 ifdhandler.c:1390:init_driver() LogLevel: 0x0003 00000218 ifdhandler.c:1410:init_driver() DriverOptions: 0x0000 00000008 ifdhandler.c:81:IFDHCreateChannelByName() lun: 0, device: usb:072f/90cc:libusb:/dev/usb4:/dev/ugen0 00054635 ccid_usb.c:238:OpenUSBByName() Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr) 00000243 ccid_usb.c:248:OpenUSBByName() ProductString: Generic CCID driver 00000212 ccid_usb.c:254:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version. 00033042 ccid_usb.c:410:OpenUSBByName() Found Vendor/Product: 072F/90CC (ACS ACR 38U-CCID) 00000529 ccid_usb.c:412:OpenUSBByName() Using USB bus/device: /dev/usb4//dev/ugen0 00002242 ccid_usb.c:782:get_data_rates() IFD does not support GET_DATA_RATES request: Unknown error: 0 05104167 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 05104154 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 05103197 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out 00000025 ifdhandler.c:122:IFDHCreateChannelByName() failed 00000058 readerfactory.c:1122:RFInitializeReader() Open Port 200000 Failed (usb:072f/90cc:libusb:/dev/usb4) 00000013 readerfactory.c:995:RFUnloadReader() Unloading reader driver. 00000065 readerfactory.c:249:RFAddReader() ACS ACR 38U-CCID init failed. apparently there is something wrong...looks like the ccid driver is trying to write to the USB device ? As far as I know you can't write to the reader, right ? And why is ccid trying to write at all ? I just plug-in the reader and start pcscd... Could you help me guys, I just need to use my digital signature with firefox... thank you Regards MGP P.S. # uname -a FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #5: Sat May 16 08:00:31 EEST 2009 myuser@home.mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE amd64 and ports from yesterday _______________________________________________ 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-current@FreeBSD.ORG Mon May 18 13:08:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2231F10656B9; Mon, 18 May 2009 13:07:37 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 43EA98FC47; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICqO6w034477; Mon, 18 May 2009 07:52:24 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICqOXP034474; Mon, 18 May 2009 07:52:24 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4I9ZEw0005478 for ; Mon, 18 May 2009 04:35:15 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2ED33176A86; Mon, 18 May 2009 09:34:33 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D188A10656E4; Mon, 18 May 2009 09:34:32 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4046B1065674; Mon, 18 May 2009 09:34:19 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 496EB8FC2B; Mon, 18 May 2009 09:34:18 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ezY8gES9d9YA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=RRgnrM4ICHkkUpFZu5kA:9 a=hTeHOaKq-z6AlGNJI1RKctCXjiEA:4 a=UlvUavXRAAAA:8 a=rL6TIayMHYZ-YPLjhE0A:9 a=_aIzSSXiGnr7tqotQBo1JtEGD3AA:4 a=6FRLwHsFNoYA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1241156808; Mon, 18 May 2009 10:34:15 +0200 Received-SPF: softfail receiver=mailfe07.swip.net; client-ip=81.191.55.181; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: gnome@freebsd.org, ports@freebsd.org, freebsd-usb@freebsd.org, freebsd-current@freebsd.org Date: Mon, 18 May 2009 10:36:50 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_j4REKGJO9Qvs4M9" Message-Id: <200905181036.51184.hselasky@freebsd.org> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:24 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Mon, 18 May 2009 04:35:16 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Mon, 18 May 2009 04:35:15 -0500 X-Spam-Status: NO, hits=-100.00 required=4.50 X-Spam-Report: Content analysis details: (-100.0 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | -100 USER_IN_WHITELIST From: address is in the user's white-list | Cc: Subject: Minor USB related sysutils/hal patch X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:08 -0000 --Boundary-00=_j4REKGJO9Qvs4M9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've made some minor patches for sysutils/hal If the device is detached during config read, the config can be NULL. Check that. Make sure that we close the device handles as we go, to save number of open files. When the backend is freed any leftover file handles will get freed, so it is not absolutely needed to close the device handle in every case. --HPS --Boundary-00=_j4REKGJO9Qvs4M9 Content-Type: text/x-diff; charset="us-ascii"; name="files.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="files.diff" diff -u -r files.org/patch-configure files/patch-configure --- files.org/patch-configure 2009-05-18 09:35:47.000000000 +0200 +++ files/patch-configure 2009-05-18 10:23:05.000000000 +0200 @@ -286,7 +286,7 @@ +main () +{ +return libusb20_dev_get_info (); -+ ; ++ + return 0; +} +_ACEOF @@ -325,8 +325,8 @@ +if test $ac_cv_lib_usb_libusb20_dev_get_info = yes; then + USE_LIBUSB=yes +else -+ USE_LIBUSB=np ++ USE_LIBUSB=no +fi + +fi diff -u -r files.org/patch-hald_freebsd_probing_probe-usb2-device.c files/patch-hald_freebsd_probing_probe-usb2-device.c --- files.org/patch-hald_freebsd_probing_probe-usb2-device.c 2009-05-18 09:35:47.000000000 +0200 +++ files/patch-hald_freebsd_probing_probe-usb2-device.c 2009-05-18 09:45:27.000000000 +0200 @@ -96,9 +96,9 @@ + pcfg = libusb20_dev_alloc_config(pdev, curr_config); + cdesc = &(pcfg->desc); + -+ if (libusb20_dev_get_info(pdev, &di)) -+ { -+ free(pcfg); ++ if ((pcfg == NULL) || libusb20_dev_get_info(pdev, &di)) ++ { ++ if (pcfg != NULL) free(pcfg); + continue; + } + @@ -196,7 +196,7 @@ + libhal_device_set_property_string(hfp_ctx, hfp_udi, + "info.vendor", di.udi_vendor, &hfp_error); + -+ free(pcfg); ++ libusb20_dev_close(pdev); free(pcfg); + } +end: + if (pbe) --Boundary-00=_j4REKGJO9Qvs4M9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" --Boundary-00=_j4REKGJO9Qvs4M9-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D9410656CA; Mon, 18 May 2009 13:07:37 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 439968FC45; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICqA6N034206; Mon, 18 May 2009 07:52:10 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICqAo6034205; Mon, 18 May 2009 07:52:10 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4I0fZfY081677 for ; Sun, 17 May 2009 19:41:35 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E8AA81552DF; Mon, 18 May 2009 00:41:27 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7C0D610656F6; Mon, 18 May 2009 00:41:27 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991E0106567A; Mon, 18 May 2009 00:41:18 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id A63A68FC21; Mon, 18 May 2009 00:41:17 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by ewy3 with SMTP id 3so3584357ewy.43 for ; Sun, 17 May 2009 17:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Df3UZTPsYG1QlE/ldliGsD9sL17XkJG2aQuZGv2Pyyk=; b=rGWxLysuldL3wdGwgFrmPWpJKHA+agMqF/xBTl123QKZI4Q6YIj6VFhS1dyO41iFny mc5aA7zr546lhMeGhrUiK0GEekFmrPyQWiJWJ4z/7DQoXkbODy/FEFGM6NkmpKOrrWbz IzjBG0sPuW9dqYLJ0y1meR8DT9TbpkiBxiqkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dA7Jl+F+UiwKaTCeuf7/cy5vcR4Ojc764kvYmTA/4/LNrJgUjv3muvuGH4vBo0VsfJ Go0i4++w4LqXFk8lw+n/pVoA4vgmOcspH95e39icY5nFhfSTjr9ftULjrpsF2B1Jv04F HE9F7oqd9PUXo2F9jf6qYxLwqH41tv2oCkO9c= MIME-Version: 1.0 Received: by 10.216.8.78 with SMTP id 56mr1874028weq.210.1242607276478; Sun, 17 May 2009 17:41:16 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Sun, 17 May 2009 20:41:16 -0400 Message-ID: <4ad871310905171741t55611cf7vc96e0086a371052@mail.gmail.com> From: Glen Barber To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:11 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:41:41 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:41:35 -0500 X-Spam-Status: NO, hits=-3.20 required=4.50 X-Spam-Report: Content analysis details: (-3.2 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | -1.0 AWL AWL: From: address is in the auto white-list | Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:11 -0000 On Sun, May 17, 2009 at 2:09 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > Is there need for the i386 folks to rebuild, or does it only affect amd64? -- Glen Barber _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B446010656F8; Mon, 18 May 2009 13:07:39 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 445D18FC48; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICq0oo034002; Mon, 18 May 2009 07:52:00 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICpxTV034001; Mon, 18 May 2009 07:51:59 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4HJBOjx067737 for ; Sun, 17 May 2009 14:11:25 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 37D1B16074D; Sun, 17 May 2009 19:11:02 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7F4CB10656F4; Sun, 17 May 2009 19:11:01 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA388106564A; Sun, 17 May 2009 19:10:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id B8E438FC12; Sun, 17 May 2009 19:10:47 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by fxm12 with SMTP id 12so2857759fxm.43 for ; Sun, 17 May 2009 12:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QHCQ5rHENOS44sQy0d/HgopwDoW9IZbeTcZVlbwGDEE=; b=QQNISyQBsg69mZ5xJpxbk2vHFjOZcrcGOJgBZWho5YGXvu83n0V9j+zYZHCZ/6tffM xvL7T20b7U80yRBpx/IXRc9zcyzzlLlORYIh56cmVLvEUP0pGAU3tVqoYWmmkV1bmlhP qAYGKY110Cou+xFSMOMkoefedeuBq69c0AiyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OVEavv8y/bYRD62erdZ8S9PC40u2xGnks//8GZL0SDaH2GRi3cmqs/TJn4SKSh47il Pl0mujiqStNIqfgJQGg701WxUeXyiZtuG9KHIObONneKuLYcIEIRv2f/nCcD+9KeT7k5 8RK1ulOEx3KJPqWNDhwpes4pLqBcdKOh6ZkBU= MIME-Version: 1.0 Received: by 10.239.164.83 with SMTP id s19mr407103hbd.110.1242587446579; Sun, 17 May 2009 12:10:46 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Sun, 17 May 2009 14:10:46 -0500 Message-ID: <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> From: "Sam Fourman Jr." To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:00 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 14:11:31 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 14:11:25 -0500 X-Spam-Status: NO, hits=-1.90 required=4.50 X-Spam-Report: Content analysis details: (-1.9 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | 0.3 AWL AWL: From: address is in the auto white-list | Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:20 -0000 On Sun, May 17, 2009 at 1:09 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin Does this version still have the kernel module crashing at random on current? Sam Fourman Jr. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:07:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1452810656B0; Mon, 18 May 2009 13:07:37 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBED8FC3E; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICpRoq033481; Mon, 18 May 2009 07:51:27 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICpRMq033480; Mon, 18 May 2009 07:51:27 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4GHGqu8002213 for ; Sat, 16 May 2009 12:16:52 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D711E156174; Sat, 16 May 2009 17:16:48 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1508910656D5; Sat, 16 May 2009 17:16:48 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67B5106564A; Sat, 16 May 2009 17:16:38 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0538FC16; Sat, 16 May 2009 17:16:34 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1078961mue.3 for ; Sat, 16 May 2009 10:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=G0eyU9Ee+p4FzD7qagGsGJYKljF9/Ax8fze3WprYAt4=; b=fPZw+FxZwb0GLdmRYeA5Szc0S2z2ekVZ6H8affnBqKgDtGoGWeuKtaUGPfJkNZ+FHQ 1M03nAFXWW+xiZBcxqghpJssltXdZsB4hnGcq/5C0SDPnV/y4ndIFZBWnk72hVpT7j08 BcmQfI33f5qjDqlbmOoRTt//AWti9DQ9sgleI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Vd2HlkcHSLf/P088fO78xPAd1Oryd+UPaABJjIIx+3T8mDUNvMcQ+gbbdYc4Oh0/dG 9if0Ntt2Me0kVSgMZaziTzvQRP2vOAZt6uu+ut8DQupthV/yTqp3kl4we8hNFiMx/mQO XKvwsxzaxxqWXVvquxtHiQ76874wXpht37JU0= MIME-Version: 1.0 Received: by 10.103.11.7 with SMTP id o7mr3029923mui.95.1242494193262; Sat, 16 May 2009 10:16:33 -0700 (PDT) In-Reply-To: <3481d8e60905141449qfcf5da8r95d54281206304a4@mail.gmail.com> References: <20090514191237.GD70242@bsdcrew.de> <3481d8e60905141449qfcf5da8r95d54281206304a4@mail.gmail.com> From: Benoit Calvez Date: Sat, 16 May 2009 19:16:13 +0200 X-Google-Sender-Auth: 5bbd5833ee395da6 Message-ID: <3481d8e60905161016k3de535e3n9a570c5bee6ba517@mail.gmail.com> To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:51:27 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sat, 16 May 2009 12:16:59 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sat, 16 May 2009 12:16:52 -0500 X-Spam-Status: NO, hits=-2.20 required=4.50 X-Spam-Report: Content analysis details: (-2.2 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | X-Mailman-Approved-At: Mon, 18 May 2009 13:15:50 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:03 -0000 On Thu, May 14, 2009 at 11:49 PM, Benoit Calvez wrote: > > > On Thu, May 14, 2009 at 9:12 PM, Martin Wilke wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Howdy Guys, >> >> After the announcement from Alexander Eichner about >> Virtualbox on FreeBSD, we started the work on a port >> for FreeBSD. Now we think that we solved the most >> problems and are ready for the first Call for Testing. >> >> Some notes before you can test the port: >> Make sure you are using RELENG_7 or higher. You have >> to use a fresh portstree with uptodate ports!! Please >> read carefully the pkg-messages. >> >> Some known issues / Troubleshooting: >> Sometimes the kernel on HEAD coredumps when loading >> or unloading the kernel module. A small workaround >> to prevent the crash is to not start X, mount proc, >> then load the kernel module and start X from the >> console. That helped me and some testers, maybe you >> too. :P AMD64 should be work in general, it builds >> and start. But not right tested at the moment. We >> want here also some feedback. >> >> Some Thanks: >> First of all we'd like to say many thanks to _ALL_ >> vbox developers. Next people are Bernhard Froehlich >> (aka decke), Beat Gaetzi (beat@), Dennis Herrmann >> (dhn@), Pietro Cerutti (gahr@), myself (*gg*), >> and _ALL_ who helped and provided feedback. >> >> Happy Testing :-) >> >> Download: >> >> http://people.freebsd.org/~miwi/vbox/vboxport.tgz >> >> Wiki Page: >> http://wiki.freebsd.org/VirtualBox >> >> - Martin >> >> - -- >> >> +-----------------------+-------------------------------+ >> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | >> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | >> +-----------------------+-------------------------------+ >> | Mess with the Best, Die like the Rest! | >> +-----------------------+-------------------------------+ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.11 (FreeBSD) >> >> iEYEARECAAYFAkoMbSUACgkQdLJIhLHm/OnNnACeJsT7H9hW1J7CV70P3Ty+q0CA >> kD8AoMLCPbltY999/8qO6fnaqv4UQ9QT >> =LcoD >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > I'm trying to build from amd64, but got the following error. Sorry but I > didn't look, and it's a fresh paste: > ===> Configuring for virtualbox-2.2.2r19673 > Checking for environment: Determined build machine: freebsd.amd64, target > machine: freebsd.amd64, OK. > Checking for kBuild: found, OK. > Checking for gcc: found version 4.2.1, OK. > Checking for as86: found version 0.16.17, OK. > Checking for bcc: found version 0.16.17, OK. > Checking for iasl: found version 20070320, OK. > Checking for xslt: found, OK. > Checking for pthread: found, OK. > Checking for libxml2: found version 2.7.3, OK. > Checking for libxslt: found version 1.1.24, OK. > Checking for libIDL: found version 0.8.13, OK. > Checking for zlib: found version 1.2.3, OK. > Checking for SDL: found version 1.2.13, OK. > Checking for X libraries: found, OK. > Checking for Xcursor: found, OK. > Checking for Xmu: found, OK. > Checking for Mesa / GLU: Xlib: extension "Generic Event Extension" missing > on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > found version 1.2, OK. > Checking for Qt4: found version 4.4.3, OK. > Checking for Qt4 devtools: found version 4.4.3, OK. > Checking for python support: found version 2.5.4, OK. > > Successfully generated > '/usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/AutoConfig.kmk' > and '/usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/env.sh'. > Source '/usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/env.sh' > once before you start to build VBox: > > source /usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/env.sh > kmk > > > +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING > +++ > Hardening is enabled which means that the VBox binaries will not run from > the binary directory. The binaries have to be installed suid root and > some > more prerequisites have to be fulfilled which is normally done by > installing > the final package. For development, the hardening feature can be disabled > by specifying the --disable-hardening parameter. Please never disable > that > feature for the final distribution! > +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING > +++ > > Enjoy! > ===> Building for virtualbox-2.2.2r19673 > cd /usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673 && /bin/sh > env.sh && VBOX_LIBPATH_X11=/usr/local > /usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/kBuild/bin/freebsd.amd64/kmk > Config.kmk:1664: > /usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/GCCConfig.kmk: > No such file or directory > Config.kmk:3789: > /usr/home/benoit/src/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/revision.kmk: > No such file or directory > Fatal error 'kse_create() failed > ' at line 469 in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 2) > *** Error code 1 > > > > > -- > Benoit C. > > I just tryed with the last tarball ( http://people.freebsd.org/~miwi/vbox/virtualbox_1.tgz) and it compiles fine. the kernel module loads, and I'll try to boot an opensolaris in a few moments. Nice job everyone ! -- Benoit C. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D8B10656C5; Mon, 18 May 2009 13:07:39 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDE08FC40; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICq91P034196; Mon, 18 May 2009 07:52:09 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICq9XM034195; Mon, 18 May 2009 07:52:09 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4I0QQqq080899 for ; Sun, 17 May 2009 19:26:26 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0723F1645D8; Mon, 18 May 2009 00:25:51 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E470210656DC; Mon, 18 May 2009 00:25:49 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A5E1065670; Mon, 18 May 2009 00:25:30 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 03CDA8FC15; Mon, 18 May 2009 00:25:29 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4I0PSM0095291; Mon, 18 May 2009 02:25:28 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4I0PSLL095290; Mon, 18 May 2009 02:25:28 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 18 May 2009 02:25:28 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090518002528.GF2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090517180920.GY71804@bsdcrew.de> User-Agent: Mutt/1.4.2.3i X-Spam-Status: NO, hits=-2.70 required=4.50 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:09 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:26:32 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:26:26 -0500 X-Spam-Report: Content analysis details: (-2.7 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | -0.5 AWL AWL: From: address is in the auto white-list | X-Mailman-Approved-At: Mon, 18 May 2009 13:15:59 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:13 -0000 On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz I've just updated my system (to 7-STABLE amd64 as of today) and installed the new version. It runs for me now. Tomorrow I will try to create virtual machine. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6373010656C8; Mon, 18 May 2009 13:07:39 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7AD8FC3D; Mon, 18 May 2009 13:07:35 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICq14c034023; Mon, 18 May 2009 07:52:01 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICq1bG034022; Mon, 18 May 2009 07:52:01 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4HK967Z070370 for ; Sun, 17 May 2009 15:09:06 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 65C5E1A8098; Sun, 17 May 2009 20:07:35 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 877E31065784; Sun, 17 May 2009 20:07:34 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E59D1065677; Sun, 17 May 2009 20:07:14 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 95D1F8FC24; Sun, 17 May 2009 20:07:13 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by mail-ew0-f159.google.com with SMTP id 3so3485005ewy.43 for ; Sun, 17 May 2009 13:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=FVkp8Co0WWMOXBsRAUECuR2mGS95pZlrjxr+3DSp4xQ=; b=fd65rrA7A6udwEETlsginKfFUGGgmC4z+/vSsJAozLODvnf4GqVitWwwW230D1q4lL JAd3OsvCBcDIYRhBo/hh/7BPA7vkNct454DzvYkQpximKZPPZThhZIQILkAsLthmFYNB Id4xBgij252Gs5iXNk5SnYc7u+i0V2w1gmZvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ulpA0C7p7BBB1sRJOu9QEPiupoU1QpVz/1PJyJi9V4H5l+CcR7K94Npg/E3Qesqq7w 3aM9AamoGk1E6qzS3h5fLR5Hei1tHNR8FYa8TOCphHZFUPTbcUxtWviz5k3TcAzRtuCP Y2NTrKYYjH0ZRguZTcBFSjgj9NN51hgxPVQ58= MIME-Version: 1.0 Received: by 10.210.58.17 with SMTP id g17mr3577298eba.4.1242590833160; Sun, 17 May 2009 13:07:13 -0700 (PDT) In-Reply-To: <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <11167f520905171210t2c5c2623o386f00745b4f9aed@mail.gmail.com> From: Benoit Calvez Date: Sun, 17 May 2009 22:06:52 +0200 X-Google-Sender-Auth: 65b21173f2ff3412 Message-ID: <3481d8e60905171306n35904a6boc74eed344505cb13@mail.gmail.com> To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:01 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 15:09:12 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 15:09:06 -0500 X-Spam-Status: NO, hits=-1.60 required=4.50 X-Spam-Report: Content analysis details: (-1.6 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 1.1 SARE_TOCC_MANY Faulty ratware: Cc with multiple addresses | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 0.0 DK_SIGNED Domain Keys: message has a signature | 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | -0.6 AWL AWL: From: address is in the auto white-list | X-Mailman-Approved-At: Mon, 18 May 2009 13:16:26 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:15 -0000 On Sun, May 17, 2009 at 9:10 PM, Sam Fourman Jr. wrote: > On Sun, May 17, 2009 at 1:09 PM, Martin Wilke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > We rolled a new tarball with the patch from Juergen Lock [1] > > with a posible fix for AMD64 users, tested on 3 machines > > which now works without problems. Many Thanks to him for > > his nice work! > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > > > Martin > > Does this version still have the kernel module crashing at random on > current? > > Sam Fourman Jr. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I uninstalled the last virtualbox (from virtualbox_1.tgz port). It compiled fine and I could start an opensolaris vm. It crashed cauz' I created the virtual hard drive in a smal partition. Since then I couldn't restart the vm. I got two Errors: "Kernel driver not instaled (rc =-1908) "Make sure the kernel module has beed loaded successfully" Sure it is. the other one is : Result Code: NS_ERROR_FAILURE (0x80004005) Component: Machine Interface: IMachine {4d1df26d-d9c1-4c7e-b689-15e85ecf8ffc} I could give more informations if needed -- Benoit C. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8883F10656E9; Mon, 18 May 2009 13:07:39 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id ACE2B8FC1B; Mon, 18 May 2009 13:07:36 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICpinm033734; Mon, 18 May 2009 07:51:44 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICpiGS033733; Mon, 18 May 2009 07:51:44 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4H9KDML041643 for ; Sun, 17 May 2009 04:20:14 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5932A157E1E; Sun, 17 May 2009 09:19:25 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 848601065694; Sun, 17 May 2009 09:19:24 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9906106564A; Sun, 17 May 2009 09:19:04 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6318FC16; Sun, 17 May 2009 09:19:04 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4H8uQxB074884; Sun, 17 May 2009 10:56:26 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4H8uQwV074883; Sun, 17 May 2009 10:56:26 +0200 (CEST) (envelope-from byshenknet) Date: Sun, 17 May 2009 10:56:26 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090517085626.GD2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <3481d8e60905141449qfcf5da8r95d54281206304a4@mail.gmail.com> <3481d8e60905161016k3de535e3n9a570c5bee6ba517@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3481d8e60905161016k3de535e3n9a570c5bee6ba517@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: NO, hits=-2.20 required=4.50 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:51:44 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 04:20:21 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 04:20:14 -0500 X-Spam-Report: Content analysis details: (-2.2 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 1.1 SARE_TOCC_MANY Faulty ratware: Cc with multiple addresses | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | -1.1 AWL AWL: From: address is in the auto white-list | X-Mailman-Approved-At: Mon, 18 May 2009 13:16:39 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Benoit Calvez Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:16 -0000 On Sat, May 16, 2009 at 07:16:13PM +0200, Benoit Calvez wrote: > On Thu, May 14, 2009 at 11:49 PM, Benoit Calvez wrote: > > On Thu, May 14, 2009 at 9:12 PM, Martin Wilke wrote: > >> After the announcement from Alexander Eichner about > >> Virtualbox on FreeBSD, we started the work on a port > >> for FreeBSD. Now we think that we solved the most > >> problems and are ready for the first Call for Testing. > >> > >> Some notes before you can test the port: > >> Make sure you are using RELENG_7 or higher. You have > >> to use a fresh portstree with uptodate ports!! Please > >> read carefully the pkg-messages. > >> > >> Some known issues / Troubleshooting: > >> Sometimes the kernel on HEAD coredumps when loading > >> or unloading the kernel module. A small workaround > >> to prevent the crash is to not start X, mount proc, > >> then load the kernel module and start X from the > >> console. That helped me and some testers, maybe you > >> too. :P AMD64 should be work in general, it builds > >> and start. But not right tested at the moment. We > >> want here also some feedback. > >> > >> Some Thanks: > >> First of all we'd like to say many thanks to _ALL_ > >> vbox developers. Next people are Bernhard Froehlich > >> (aka decke), Beat Gaetzi (beat@), Dennis Herrmann > >> (dhn@), Pietro Cerutti (gahr@), myself (*gg*), > >> and _ALL_ who helped and provided feedback. > >> > >> Happy Testing :-) > >> > >> Download: > >> > >> http://people.freebsd.org/~miwi/vbox/vboxport.tgz > >> > >> Wiki Page: > >> http://wiki.freebsd.org/VirtualBox > >> > >> - Martin > > I'm trying to build from amd64, but got the following error. Sorry but I > > didn't look, and it's a fresh paste: > > [...] > I just tryed with the last tarball ( > http://people.freebsd.org/~miwi/vbox/virtualbox_1.tgz) and it compiles fine. > > the kernel module loads, and I'll try to boot an opensolaris in a few > moments. I've just tried with virtualbox_1.tgz, and it builds without a problem, the module installs without a problem, but attempting to start VirtualBox fails. I get no error at all, VirtualBox just hangs. If I attempt to run 'truss VirtualBox', I get the error: Effective UID is not root (euid=1001 egid=1001 uid=1001 gid=1001) (rc=-10) It may help to reinstall VirtualBox. But checking shows that VirtualBox is SUID root: $ ls -l /usr/local/lib/virtualbox/VirtualBox -r-s--x--x 1 root vboxusers 21016 May 17 10:21 /usr/local/lib/virtualbox/VirtualBox It seems that I can create a vm: $ VBoxManage createvm --name test VirtualBox Command Line Management Interface Version 2.2.51_OSE (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Virtual machine 'test' is created. UUID: 9be28271-55c2-4299-b69a-266c58716db7 Settings file: '/home/gbyshenk/.VirtualBox/Machines/test/test.xml' $ VirtualBox $ ls -l /home/gbyshenk/.VirtualBox/Machines/test/test.xml -rw------- 1 gbyshenk gbyshenk 2302 May 17 10:37 /home/gbyshenk/.VirtualBox/Machines/test/test.xml But VirtualBox itself fails to start -- even if I run as root. System is amd64, 7-STABLE as of 26-04-2009. Does it need to be more recent...? -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:08:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1C9110656F7; Mon, 18 May 2009 13:07:39 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (mail.sagedata.net [63.214.156.21]) by mx1.freebsd.org (Postfix) with ESMTP id C21BD8FC2D; Mon, 18 May 2009 13:07:36 +0000 (UTC) (envelope-from root@mail.sagedata.net) Received: from mail.sagedata.net (localhost [127.0.0.1]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4ICqB18034210; Mon, 18 May 2009 07:52:11 -0500 (CDT) (envelope-from root@mail.sagedata.net) Received: (from root@localhost) by mail.sagedata.net (8.14.3/8.14.3/Submit) id n4ICqBjr034209; Mon, 18 May 2009 07:52:11 -0500 (CDT) (envelope-from root) X-Envelope-Sender: owner-freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.sagedata.net (8.14.3/8.14.3) with ESMTP id n4I0pNJa081948 for ; Sun, 17 May 2009 19:51:24 -0500 (CDT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A3C30157E58; Mon, 18 May 2009 00:51:18 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E0CC710656D7; Mon, 18 May 2009 00:51:16 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6120B106564A; Mon, 18 May 2009 00:50:56 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id E4C1C8FC12; Mon, 18 May 2009 00:50:55 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n4I0os07095605; Mon, 18 May 2009 02:50:54 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n4I0osou095604; Mon, 18 May 2009 02:50:54 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 18 May 2009 02:50:54 +0200 From: Greg Byshenk To: Martin Wilke Message-ID: <20090518005054.GG2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090518002528.GF2571@core.byshenk.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: NO, hits=-2.70 required=4.50 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-Scanned-By: milter-sender/1.16.915 (localhost [0.0.0.0]); Mon, 18 May 2009 07:52:11 -0500 X-Scanned-By: milter-spamc/1.13.385 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:51:29 -0500 X-Scanned-By: milter-sender/1.16.915 (mail.sagedata.net [63.214.156.21]); Sun, 17 May 2009 19:51:24 -0500 X-Spam-Report: Content analysis details: (-2.7 points, 4.5 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.3 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails | -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' | 1.5 BOTNET_SERVERWORDS Hostname contains server-like substrings | [botnet_serverwords, ip=69.147.83.53, rdns=mx2.freebsd.org] | 2.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60p | [score: 0.5000] | -0.5 AWL AWL: From: address is in the auto white-list | X-Mailman-Approved-At: Mon, 18 May 2009 13:16:55 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:08:18 -0000 On Mon, May 18, 2009 at 02:25:28AM +0200, Greg Byshenk wrote: > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > > > We rolled a new tarball with the patch from Juergen Lock [1] > > with a posible fix for AMD64 users, tested on 3 machines > > which now works without problems. Many Thanks to him for > > his nice work! > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > I've just updated my system (to 7-STABLE amd64 as of today) and > installed the new version. It runs for me now. Tomorrow I will > try to create virtual machine. As a followup, the 'virtualbox_2.tgz' version appears to work for me, at least minimally. I've just installed NetBSD4.1 virtual machine, and it appears to be working (even though NetBSD isn't listed as a supported guest -- I just happened to have the NetBSD install iso sitting on my hard drive). -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:27:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E96C2106574A for ; Mon, 18 May 2009 13:27:27 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id A3E558FC0A for ; Mon, 18 May 2009 13:27:27 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by qyk3 with SMTP id 3so5668701qyk.3 for ; Mon, 18 May 2009 06:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=kwhJl5lrZXO2LM7cWpPMb+f9rzUmJNhde6SVp8RrD5s=; b=AuK7csS/bhVVhTV/D6CqLs8X8NetM/XllQV6albNbF12Jcho+eA79z9zW36d/B4Rf6 u5YV9dBMcHpXqDOtoAOnQWqGJrOgU1ozlZ5/cL9W4oiTtKqrpYrux5dVnE/hP0cD5fzp mNVRX2XBClOYlNMto1B6ZbDyTjl51OZnVUcrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=KG+aUyCun6qyMd67U+97EVfaeWnZ/GWvSJD89SPE+Jjm3oFfVGfWsXcB2XEqpRvEPC jmTV97ldpc1L70OzzCJdLyko+C9HIPFAWz1W4oqmZYhv3cUpZ8ZvGbh6eNsNY19ZRYbw kzS8maCCZjMXV3iC5aVfpnc81r6vcoj5azarM= MIME-Version: 1.0 Received: by 10.220.46.85 with SMTP id i21mr6441037vcf.19.1242653245269; Mon, 18 May 2009 06:27:25 -0700 (PDT) From: Renato Botelho Date: Mon, 18 May 2009 10:27:05 -0300 Message-ID: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [new-usb] - USB_ERR_NO_POWER on keyboard hub X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:27:28 -0000 I have a Sun USB Type 7 keyboard, and this keyboard has an USB hub with 3 ports on it. I'm using one of those 3 ports to plug the mouse and it's working fine. uhub5: 4 ports with 3 removable, bus powered ugen0.3: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen0.4: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 When I tried to plug a pen drive on anothe one, I got this: usb2_set_config_index:531: power exceeded 500 > 100 usb2_set_config_index:531: power exceeded 500 > 100 usb2_alloc_device:1755: Failure selecting configuration index 0: USB_ERR_NO_POWER, port 2, addr 5 (ignored) ugen0.5: at usbus0 pid 3705 (hald-probe-usb2-dev), uid 0: exited on signal 11 ugen0.5: at usbus0 (disconnected) usb2_set_config_index:531: power exceeded 500 > 100 usb2_set_config_index:531: power exceeded 500 > 100 usb2_alloc_device:1755: Failure selecting configuration index 0: USB_ERR_NO_POWER, port 1, addr 5 (ignored) ugen0.5: at usbus0 pid 3886 (hald-probe-usb2-dev), uid 0: exited on signal 11 ugen0.5: at usbus0 (disconnected) I'm using FreeBSD 8.0-current r192140. Let me know if there is more information i need to provide. Thanks -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:43:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779C81065673 for ; Mon, 18 May 2009 13:43:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABAA8FC24 for ; Mon, 18 May 2009 13:43:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=5Z1tN9aDy1AA:10 a=XeTYFPXcjFYA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=DloDR1Z0zDbXHhugJkgA:9 a=bV64Yx89F7r-x3D_5IgA:7 a=sa5JJXWh0UUdU4XRfXlV_egYfngA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1244190581; Mon, 18 May 2009 15:43:27 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 15:46:01 +0200 User-Agent: KMail/1.9.7 References: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> In-Reply-To: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181546.02302.hselasky@c2i.net> Cc: Renato Botelho Subject: Re: [new-usb] - USB_ERR_NO_POWER on keyboard hub X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:43:29 -0000 On Monday 18 May 2009, Renato Botelho wrote: > I have a Sun USB Type 7 keyboard, and this keyboard has an USB hub > with 3 ports on it. I'm using one of those 3 ports to plug the mouse and > it's working fine. > > uhub5: 4 ports with 3 removable, bus powered > ugen0.3: at usbus0 > ums0: on usbus0 > ums0: 3 buttons and [XYZ] coordinates ID=0 > ugen0.4: at usbus0 > ukbd0: 2.00/1.04, addr 4> on usbus0 > kbd2 at ukbd0 > > When I tried to plug a pen drive on anothe one, I got this: > > usb2_set_config_index:531: power exceeded 500 > 100 > usb2_set_config_index:531: power exceeded 500 > 100 > usb2_alloc_device:1755: Failure selecting configuration index 0: > USB_ERR_NO_POWER, port 2, addr 5 (ignored) > ugen0.5: at usbus0 > pid 3705 (hald-probe-usb2-dev), uid 0: exited on signal 11 > ugen0.5: at usbus0 (disconnected) > > usb2_set_config_index:531: power exceeded 500 > 100 > usb2_set_config_index:531: power exceeded 500 > 100 > usb2_alloc_device:1755: Failure selecting configuration index 0: > USB_ERR_NO_POWER, port 1, addr 5 (ignored) > ugen0.5: at usbus0 > pid 3886 (hald-probe-usb2-dev), uid 0: exited on signal 11 > ugen0.5: at usbus0 (disconnected) > > I'm using FreeBSD 8.0-current r192140. > > Let me know if there is more information i need to provide. > > Thanks Hi, Your Keyboard HUB technically does not allow current consumption above 100mA per port. Your memstick reports it needs 500mA. Probably you can hack around it, but then your hardware might break ... --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:45:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E81AF10656A5; Mon, 18 May 2009 13:45:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id E842C8FC16; Mon, 18 May 2009 13:45:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=_BEwgaXNDRcA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=9QB6Yr9kmXFhgbQMM1gA:9 a=pzKaqVQ5Kkn8zZqeWifTCaHou6oA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1142225861; Mon, 18 May 2009 15:45:26 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Mon, 18 May 2009 15:48:01 +0200 User-Agent: KMail/1.9.7 References: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg> In-Reply-To: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181548.01967.hselasky@c2i.net> Cc: Mario Pavlov , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:45:29 -0000 On Sunday 17 May 2009, Mario Pavlov wrote: > Hi, > I just got a CCID USB reader with my digital signature...unfortunately I > can't make it work I installed pcsc-lite and libccid from ports... > when I plug-in the reader I can see this: > > ugen0: on > uhub4 > > then I do this: > Is the problem the same on -current? --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:48:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 682D1106566B for ; Mon, 18 May 2009 13:48:11 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 219B58FC12 for ; Mon, 18 May 2009 13:48:10 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by qyk3 with SMTP id 3so5689642qyk.3 for ; Mon, 18 May 2009 06:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xMJR2RfZfs7/d+ojBCFzLfI3vMroYcs9lotVlzlcisk=; b=eY3u/iHD91OAgrCoWX8MHdYBWWChT+517/F6yDI+aLX6omUkCFZL87g1iktMcNuxF+ Bg3eXOaMHLDDzHsFMuTpbmyC0ZpaYd/uUBljpv6pS3AMuXA8VPYWCMs100nFcS2sPP3N 52V4D8LWGlC54n5/FZ+0tl4zQKZC3pr26tw70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=oNB6q3kESffSq/p5LiN0I7scSbbfQmiqOSRVw+IaSMTk87HF/PFzf86/ct6cK5rfII QAn+HaoT+wl15AnqEFWkPS3nTKvRJlcaQT3k6nCDA5BncIIL4Oeno94dPRxpY72aLxbu i5i55w9x+p3l2KL69ZqC53AMUsP2gwWpKj/aU= MIME-Version: 1.0 Received: by 10.220.76.212 with SMTP id d20mr6605394vck.26.1242654490196; Mon, 18 May 2009 06:48:10 -0700 (PDT) In-Reply-To: <200905181546.02302.hselasky@c2i.net> References: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> <200905181546.02302.hselasky@c2i.net> From: Renato Botelho Date: Mon, 18 May 2009 10:47:50 -0300 Message-ID: <747dc8f30905180647r76ec74b5ud90eb2c062aef988@mail.gmail.com> To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [new-usb] - USB_ERR_NO_POWER on keyboard hub X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:48:11 -0000 On Mon, May 18, 2009 at 10:46 AM, Hans Petter Selasky wrote: > On Monday 18 May 2009, Renato Botelho wrote: >> I have a Sun USB Type 7 keyboard, and this keyboard has an USB hub >> with 3 ports on it. I'm using one of those 3 ports to plug the mouse and >> it's working fine. >> >> uhub5: 4 ports with 3 removable, bus powered >> ugen0.3: at usbus0 >> ums0: on usbus0 >> ums0: 3 buttons and [XYZ] coordinates ID=0 >> ugen0.4: at usbus0 >> ukbd0: > 2.00/1.04, addr 4> on usbus0 >> kbd2 at ukbd0 >> >> When I tried to plug a pen drive on anothe one, I got this: >> >> usb2_set_config_index:531: power exceeded 500 > 100 >> usb2_set_config_index:531: power exceeded 500 > 100 >> usb2_alloc_device:1755: Failure selecting configuration index 0: >> USB_ERR_NO_POWER, port 2, addr 5 (ignored) >> ugen0.5: at usbus0 >> pid 3705 (hald-probe-usb2-dev), uid 0: exited on signal 11 >> ugen0.5: at usbus0 (disconnected) >> >> usb2_set_config_index:531: power exceeded 500 > 100 >> usb2_set_config_index:531: power exceeded 500 > 100 >> usb2_alloc_device:1755: Failure selecting configuration index 0: >> USB_ERR_NO_POWER, port 1, addr 5 (ignored) >> ugen0.5: at usbus0 >> pid 3886 (hald-probe-usb2-dev), uid 0: exited on signal 11 >> ugen0.5: at usbus0 (disconnected) >> >> I'm using FreeBSD 8.0-current r192140. >> >> Let me know if there is more information i need to provide. >> >> Thanks > > Hi, > > Your Keyboard HUB technically does not allow current consumption above 100mA > per port. Your memstick reports it needs 500mA. Probably you can hack around > it, but then your hardware might break ... Yep, I found now this text on Sun FAQ: What is power budget control? Power budget control is specified in USB spec to limit device connections to a hub to avoid overcurrent condition. A self-powered hub can supply a maximum of 500mA to each port, while a bus-powered hub should only supply a maximum of 100mA to each port. With power budget control, devices consuming power more than 100mA will be denied connection to a bus-powered hub. And two bus-powered hubs are not allowed to be concatenated. I can live without it, prefer to keep my kbd working :) Thank you -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:53:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD441065680 for ; Mon, 18 May 2009 13:53:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5FC8FC1A for ; Mon, 18 May 2009 13:53:38 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=CIEzdh-eAAAA:8 a=KIphsAs2N4UY2EQtaJUA:9 a=w_Vsbb3nMPXF2jfSPfWN3fM1AVEA:4 a=gpo68xK-DQSA77ag:21 a=Mn0Lgkzf7K8vBWp7:21 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1071149082; Mon, 18 May 2009 15:53:37 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 15:56:12 +0200 User-Agent: KMail/1.9.7 References: <20090518112739.GA97602@ei.bzerk.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181556.13116.hselasky@c2i.net> Cc: Ruben de Groot , Saifi Khan , freebsd-questions@freebsd.org Subject: Re: USB-to-serial adapter configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:53:40 -0000 On Monday 18 May 2009, Saifi Khan wrote: > On Mon, 18 May 2009, Ruben de Groot wrote: > > On Mon, May 18, 2009 at 04:07:09PM +0000, Saifi Khan typed: > > > Hi all: > > > > > > How does one configure settings for USB-to-serial adapter in FreeBSD ? > > > > > > The one i have purchased is > > > http://www.usbgear.com/computer_cable_details.cfm?sku=CHEAP-SERIAL&cats > > >=199&catid=482%2C1303%2C199%2C461%2C106%2C1009%2C601 > > > > > > On the Gentoo box, 'lsusb' displays it as: > > > Bus 002 Device 003: ID 067b:2303 > > > Prolific Technology, Inc. PL2303 Serial Port > > > > Your adapter should be recognised by the uplcom driver. put > > uplcom_load="YES" in loader.conf or load manually. Check dmesg for the > > device name. > > Also, I think cu is "good enough" ;) > > > > Ruben > > This is the error shown in 'dmesg' log > > ugen0.2: at usbus0 > uplcom0: 0/0, rev 1.10/3.00, addr 2> on usbus0 uplcom0: init failed! > device_attach: uplcom0 attach returned 6 > uplcom0: 0/0, rev 1.10/3.00, addr 2> on usbus0 uplcom0: init failed! > device_attach: uplcom0 attach returned 6 > > Scenarios: > > 1. kldstat -v | grep uplcom shows > 303 uhub/uplcom > > 2. uplcom_load="YES" in /boot/loader.conf > with a reboot > > In both the scenarios, 'dmesg' shows the same error. > > On re-attaching the device, the following error is shown. Hi, > > usb2_alloc_device:1574: set address 2 failed (USB_ERR_STALLED, ignored) > usb2_alloc_device:1612: getting device descriptor at addr 2 failed, > USB_ERR_STALLED! ugen0.2: <> at usbus0 (disconnected) > uhub_reattach_port:417: could not allocate new device! Looks like the firmware crashed if it does not re-enumrate. > > Any suggestions on how i can get uplcom drive to work ? > Try looking up the USB-ID line for your device and modify the uplcom flags (TYPE_XXX) for your device so that it does not require init for example. /* TrendNet TU-S9 */ {USB_UPL(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303, 0x0400, 0xFFFF, TYPE_PL2303X)}, /* ST Lab USB-SERIAL-4 */ {USB_UPL(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303, 0x0300, 0x03FF, TYPE_PL2303X)}, /* IOGEAR/ATEN UC-232A (also ST Lab USB-SERIAL-1) */ {USB_UPL(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303, 0, 0x02FF, TYPE_PL2303)}, Use: usbconfig dump_device_desc To get the version number for your chip (See "0, 0x02FF" above) Make sure that the TYPE flag is correct. Also see: /sys/dev/usb/serial/uplcom.c Then: make -C /sys/modules/usb/uplcom clean all install kldunload uplcom kldload uplcom --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 13:57:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16E6010657A6; Mon, 18 May 2009 13:57:15 +0000 (UTC) (envelope-from doug@polands.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id D80868FC15; Mon, 18 May 2009 13:57:14 +0000 (UTC) (envelope-from doug@polands.org) Received: from haran.polands.org ([75.87.219.217]) by hrndva-omta03.mail.rr.com with ESMTP id <20090518133819564.MOZR24043@hrndva-omta03.mail.rr.com>; Mon, 18 May 2009 13:38:19 +0000 Received: from email.polands.org (moab.polands.org [172.16.1.8]) by haran.polands.org (8.14.3/8.14.3) with ESMTP id n4IDcI2o056002; Mon, 18 May 2009 08:38:18 -0500 (CDT) (envelope-from doug@polands.org) Received: from 209.103.215.99 (SquirrelMail authenticated user djp) by email.polands.org with HTTP; Mon, 18 May 2009 08:38:18 -0500 (CDT) Message-ID: <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> In-Reply-To: <20090518002528.GF2571@core.byshenk.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> Date: Mon, 18 May 2009 08:38:18 -0500 (CDT) From: "Doug Poland" To: "Greg Byshenk" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:57:21 -0000 On Sun, May 17, 2009 19:25, Greg Byshenk wrote: > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: >> >> We rolled a new tarball with the patch from Juergen Lock [1] >> with a posible fix for AMD64 users, tested on 3 machines >> which now works without problems. Many Thanks to him for >> his nice work! >> >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > Working for me with a fresh cvsup of 7.2-STABLE (17 May 09). Installing a 7.2-RELEASE amd64 guest as I write this. -- Regards, Doug From owner-freebsd-current@FreeBSD.ORG Mon May 18 14:43:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BE91065675; Mon, 18 May 2009 14:43:22 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id D712A8FC12; Mon, 18 May 2009 14:43:21 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail53.abv.bg (mail53.ni.bg [192.168.151.29]) by smtp-out.abv.bg (Postfix) with ESMTP id 42EA587B01; Mon, 18 May 2009 17:43:30 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=zfR7JSTtStFCL2UFLmPH6Tl0mV2XpKdm3hIR1uCg0EwLBzNlLlK2LnNIz7K5ZaB/m knh0M0vJUIe/SAnzRruG0oAzyiSLFkNKaLCwzDC0NNbnzoN4LvqSHyXZA4DNd91XdZi JxpvQPZd4calQjT6/mpHy5K7JQ/Lcwv8RGD2rdA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1242657810; bh=b0VoRiqc1tnEAsbmFqfj6ujqek1sn/Rfhryamg9U120=; h=Date:From:To:Cc:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=FeLyvm95xgqBE+84aq4fx7310KXmYRxLzt0vbhQyQDOWTez8Oh3CzM2uenP85sCat PlGy+inbH5GVM+LEK3a++2sEpxkhtWebFhxAtZgzKUrFHIUi3zsB9xNU/LxPmIkKh0 ptSFyVBOZOFFnIjMwy+oRRTfqdLmE1w8BJXFqXuQ= Received: from mail53.abv.bg (localhost.localdomain [127.0.0.1]) by mail53.abv.bg (Postfix) with ESMTP id 298DE1E4B0A; Mon, 18 May 2009 17:43:19 +0300 (EEST) Date: Mon, 18 May 2009 17:43:19 +0300 (EEST) From: Mario Pavlov To: Hans Petter Selasky Message-ID: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Re: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 14:43:23 -0000 Hi, no I haven't tried it on CURRENT should I do that ? is there something new in the USB stuff there ? thank you regards, mgp >On Sunday 17 May 2009, Mario Pavlov wrote: >> Hi, >> I just got a CCID USB reader with my digital signature...unfortunately I >> can't make it work I installed pcsc-lite and libccid from ports... >> when I plug-in the reader I can see this: >> >> ugen0: on >> uhub4 >> >> then I do this: >> > >Is the problem the same on -current? > >--HPS >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon May 18 14:48:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87332106568C; Mon, 18 May 2009 14:48:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9167E8FC24; Mon, 18 May 2009 14:48:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=_BEwgaXNDRcA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=qEmZkb-KXYhecAtQk-QA:9 a=4cYV6oinmLXK2LUBHfRiNdivaNwA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1142263872; Mon, 18 May 2009 16:48:51 +0200 From: Hans Petter Selasky To: Mario Pavlov Date: Mon, 18 May 2009 16:51:25 +0200 User-Agent: KMail/1.9.7 References: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg> In-Reply-To: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181651.26773.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 14:48:54 -0000 On Monday 18 May 2009, Mario Pavlov wrote: > Hi, > no I haven't tried it on CURRENT > should I do that ? > is there something new in the USB stuff there ? There is a new USB stack in 8-current and a new libusb which is installed as a part of the base system. --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 15:12:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A96210656CD for ; Mon, 18 May 2009 15:12:39 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id E71A88FC12 for ; Mon, 18 May 2009 15:12:38 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id B2B2171F408 for ; Mon, 18 May 2009 10:56:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7YCcS4i8Gq0 for ; Mon, 18 May 2009 10:56:15 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 9186571F2BD for ; Mon, 18 May 2009 10:56:15 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 5B812CB4; Mon, 18 May 2009 10:56:15 -0400 (EDT) Date: Mon, 18 May 2009 10:56:15 -0400 From: Adam McDougall To: current@freebsd.org Message-ID: <20090518145614.GF82547@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:12:39 -0000 I'm not sure if this is related to recent kernel memory code changes or what, but it hasn't happened with code from earlier than a couple days ago. I had this happen twice, I think the first time was with arc max set to 1024M, the second time was when arc max was unset in loader.conf and the system had been up a few hours but the arc hadn't been squeezed down to a small number yet: Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M Free I've deleted the kernel since then but I did not change my sources, I could build a new one and check where the pointers point to I think? If needed. Or I could reproduce the panic if needed. It doesn't dump, it just gets stuck after printing the panic. Transcribed by hand to save bandwidth: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xffff804000000000 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804a4d4e stack pointer = 0x28:0xffffff80000c3900 frame pointer = 0x28:0xffffff80000c3910 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) trap number = 12 panic: page fault cpuid = 0 Uptime: 2h40m14s From owner-freebsd-current@FreeBSD.ORG Mon May 18 15:31:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8441065689 for ; Mon, 18 May 2009 15:31:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D0FC18FC21 for ; Mon, 18 May 2009 15:31:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n4IFDEjd016875 for ; Mon, 18 May 2009 11:13:14 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 18 May 2009 11:13:14 -0400 (EDT) Date: Mon, 18 May 2009 11:13:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1242659594=:20092" Subject: USB umass external drive problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:31:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1242659594=:20092 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, I have an external USB SATA drive chassis but the drive is only seen(*) if it is connected at bootup. Regardless of whether it was connected at bootup time or not, if it is reconnected after the system is up it will not be seen. (*) /dev/da0 will be created, but no entries for da0s1, da0s2, da0s3[a-g]. s1 is FAT16, s2 is NTFS, s2 is FreeBSD with partitions a-g. s1, s2, and s3[a-g] entries are only created if the device is attached at bootup. Before the drive was formatted as above (it was new without any slice/partitioning), fdisk and disklabel would also be unable to see the drive unless it was attached at bootup time. # uname -a FreeBSD rigel 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r191822: Wed May 6 02:44:45 EDT 2009 root@rigel:/opt/FreeBSD/svn/obj/opt/FreeBSD/svn/src/sys/rigel i386 Attach messages from log: root: Unknown USB device: vendor 0x04fc product 0x0c15 bus uhub4 kernel: ugen4.2: at usbus4 kernel: umass0: on usbus4 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 kernel: umass0:3:0:-1: Attached to scbus3 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 kernel: da0: < > Fixed Direct Access SCSI-2 device kernel: da0: 40.000MB/s transfers kernel: da0: 55796MB (114270345 512 byte sectors: 255H 63S/T 7113C) Full dmesg is attached. -- DE ---559023410-758783491-1242659594=:20092 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=dmesg.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KVGhlIFJlZ2VudHMgb2Yg dGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNl cnZlZC4NCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBU aGUgRnJlZUJTRCBGb3VuZGF0aW9uLg0KRnJlZUJTRCA4LjAtQ1VSUkVOVCAj MSByMTkxODIyOiBXZWQgTWF5ICA2IDAyOjQ0OjQ1IEVEVCAyMDA5DQpyb290 QHJpZ2VsOi9vcHQvRnJlZUJTRC9zdm4vb2JqL29wdC9GcmVlQlNEL3N2bi9z cmMvc3lzL3JpZ2VsDQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVk LCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NClRpbWVjb3VudGVyICJp ODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQpDUFU6IEdl bnVpbmUgSW50ZWwoUikgQ1BVCSAgICBUMjUwMCAgQCAyLjAwR0h6ICgxOTk3 LjM0LU1IeiA2ODYtY2xhc3MgQ1BVKQ0KT3JpZ2luID0gIkdlbnVpbmVJbnRl bCIgIElkID0gMHg2ZTggIFN0ZXBwaW5nID0gOA0KRmVhdHVyZXM9MHhiZmU5 ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMs U0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJLE1N WCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+DQpGZWF0dXJlczI9MHhj MWE5PFNTRTMsTU9OLFZNWCxFU1QsVE0yLHhUUFIsUERDTT4NCkFNRCBGZWF0 dXJlcz0weDEwMDAwMDxOWD4NClRTQzogUC1zdGF0ZSBpbnZhcmlhbnQNCnJl YWwgbWVtb3J5ICA9IDEwNzM3NDE4MjQgKDEwMjQgTUIpDQphdmFpbCBtZW1v cnkgPSAxMDI3OTI4MDY0ICg5ODAgTUIpDQpBQ1BJIEFQSUMgVGFibGU6IDxE RUxMICAgTTA3CT4NCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0 ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcw0KRnJlZUJTRC9TTVA6IDEgcGFja2FnZShz KSB4IDIgY29yZShzKQ0KY3B1MCAoQlNQKTogQVBJQyBJRDogIDANCmNwdTEg KEFQKTogQVBJQyBJRDogIDENCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQg dG8gMg0KaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3Ro ZXJib2FyZA0KYWNwaTA6IDxERUxMIE0wNyAgICA+IG9uIG1vdGhlcmJvYXJk DQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwg OWZjMDAgKDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAw MCwgM2Y1ZDM0MDAgKDMpIGZhaWxlZA0KVGltZWNvdW50ZXIgIkFDUEktZmFz dCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwDQphY3BpX3Rp bWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEw MDgtMHgxMDBiIG9uIGFjcGkwDQphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4g b24gYWNwaTANCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0 ZXJ5PiBvbiBhY3BpMA0KYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlk IFN3aXRjaD4gb24gYWNwaTANCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRv bj4gb24gYWNwaTANCmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24g YWNwaTANCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhj ZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIwDQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAw eGVmZjgtMHhlZmZmIG1lbSAweGRmZjAwMDAwLTB4ZGZmN2ZmZmYsMHhjMDAw MDAwMC0weGNmZmZmZmZmLDB4ZGZlYzAwMDAtMHhkZmVmZmZmZiBpcnEgMTYg YXQgZGV2aWNlIDIuMCBvbiBwY2kwDQphZ3AwOiA8SW50ZWwgODI5NDVHTSAo OTQ1R00gR01DSCkgU1ZHQSBjb250cm9sbGVyPiBvbiB2Z2FwY2kwDQphZ3Aw OiBkZXRlY3RlZCA3OTMyayBzdG9sZW4gbWVtb3J5DQphZ3AwOiBhcGVydHVy ZSBzaXplIGlzIDI1Nk0NCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBkaXNw bGF5PiBtZW0gMHhkZmY4MDAwMC0weGRmZmZmZmZmIGF0IGRldmljZSAyLjEg b24gcGNpMA0KaGRhYzA6IDxJbnRlbCA4MjgwMUcgSGlnaCBEZWZpbml0aW9u IEF1ZGlvIENvbnRyb2xsZXI+IG1lbSAweGRmZWJjMDAwLTB4ZGZlYmZmZmYg aXJxIDIxIGF0IGRldmljZSAyNy4wIG9uIHBjaTANCmhkYWMwOiBIREEgRHJp dmVyIFJldmlzaW9uOiAyMDA5MDQwMV8wMTMyDQpoZGFjMDogW0lUSFJFQURd DQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4w IG9uIHBjaTANCnBjaTExOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQ0KcGNp YjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMSBvbiBw Y2kwDQpwY2kxMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjINCmF0aDA6IDxB dGhlcm9zIDU0MjQvMjQyND4gbWVtIDB4ZGZkZjAwMDAtMHhkZmRmZmZmZiBp cnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kxMg0KYXRoMDogW0lUSFJFQURd DQphdGgwOiBBUjU0MTMgbWFjIDEwLjIgUkY1NDI0IHBoeSA2LjENCnBjaWIz OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjMgb24gcGNp MA0KcGNpMTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzDQp1aGNpMDogPFVI Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YmY4MC0weGJm OWYgaXJxIDIwIGF0IGRldmljZSAyOS4wIG9uIHBjaTANCnVoY2kwOiBbSVRI UkVBRF0NCnVoY2kwOiBMZWdTdXAgPSAweDAwMDANCnVzYnVzMDogPFVIQ0kg KGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMA0KdWhjaTE6IDxV SENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGJmNjAtMHhi ZjdmIGlycSAyMSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwDQp1aGNpMTogW0lU SFJFQURdDQp1aGNpMTogTGVnU3VwID0gMHgwMDAwDQp1c2J1czE6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTENCnVoY2kyOiA8 VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiZjQwLTB4 YmY1ZiBpcnEgMjIgYXQgZGV2aWNlIDI5LjIgb24gcGNpMA0KdWhjaTI6IFtJ VEhSRUFEXQ0KdWhjaTI6IExlZ1N1cCA9IDB4MDAwMA0KdXNidXMyOiA8VUhD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyDQp1aGNpMzog PFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YmYyMC0w eGJmM2YgaXJxIDIzIGF0IGRldmljZSAyOS4zIG9uIHBjaTANCnVoY2kzOiBb SVRIUkVBRF0NCnVoY2kzOiBMZWdTdXAgPSAweDAwMDANCnVzYnVzMzogPFVI Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMw0KZWhjaTA6 IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4g bWVtIDB4ZmZhODAwMDAtMHhmZmE4MDNmZiBpcnEgMjAgYXQgZGV2aWNlIDI5 Ljcgb24gcGNpMA0KZWhjaTA6IFtJVEhSRUFEXQ0KdXNidXM0OiBFSENJIHZl cnNpb24gMS4wDQp1c2J1czQ6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVT QiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTANCnBjaWI0OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMA0KcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjQNCmJmZTA6IDxCcm9hZGNvbSBCQ000NDAx LUIwIEZhc3QgRXRoZXJuZXQ+IG1lbSAweGRmOWZlMDAwLTB4ZGY5ZmZmZmYg aXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMg0KbWlpYnVzMDogPE1JSSBi dXM+IG9uIGJmZTANCmJtdHBoeTA6IDxCQ000NDAxIDEwLzEwMGJhc2VUWCBQ SFk+IFBIWSAxIG9uIG1paWJ1czANCmJtdHBoeTA6ICAxMGJhc2VULCAxMGJh c2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQpiZmUw OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxNDoyMjphZTpiYzo5OA0KYmZlMDog W0lUSFJFQURdDQpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJvbGxl ciBJbnRlcmZhY2U+IG1lbSAweGRmOWZkODAwLTB4ZGY5ZmRmZmYgaXJxIDE5 IGF0IGRldmljZSAxLjAgb24gcGNpMg0KZndvaGNpMDogW0lUSFJFQURdDQpm d29oY2kwOiBPSENJIHZlcnNpb24gMS4xMCAoUk9NPTApDQpmd29oY2kwOiBO by4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4NCmZ3b2hjaTA6IEVV STY0IDMyOjRmOmMwOjAwOjI5OmE3OjFkOjQxDQpmd29oY2kwOiBQaHkgMTM5 NGEgYXZhaWxhYmxlIFM0MDAsIDEgcG9ydHMuDQpmd29oY2kwOiBMaW5rIFM0 MDAsIG1heF9yZWMgMjA0OCBieXRlcy4NCmZpcmV3aXJlMDogPElFRUUxMzk0 KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTANCmRjb25zX2Nyb20wOiA8ZGNv bnMgY29uZmlndXJhdGlvbiBST00+IG9uIGZpcmV3aXJlMA0KZGNvbnNfY3Jv bTA6IGJ1c19hZGRyIDB4MTA4ODAwMA0KZndlMDogPEV0aGVybmV0IG92ZXIg RmlyZVdpcmU+IG9uIGZpcmV3aXJlMA0KaWZfZndlMDogRmFrZSBFdGhlcm5l dCBhZGRyZXNzOiAzMjo0ZjpjMDphNzoxZDo0MQ0KZndlMDogRXRoZXJuZXQg YWRkcmVzczogMzI6NGY6YzA6YTc6MWQ6NDENCmZ3aXAwOiA8SVAgb3ZlciBG aXJlV2lyZT4gb24gZmlyZXdpcmUwDQpmd2lwMDogRmlyZXdpcmUgYWRkcmVz czogMzI6NGY6YzA6MDA6Mjk6YTc6MWQ6NDEgQCAweGZmZmUwMDAwMDAwMCwg UzQwMCwgbWF4cmVjIDIwNDgNCnNicDA6IDxTQlAtMi9TQ1NJIG92ZXIgRmly ZVdpcmU+IG9uIGZpcmV3aXJlMA0KZndvaGNpMDogSW5pdGlhdGUgYnVzIHJl c2V0DQpmd29oY2kwOiBmd29oY2lfaW50cl9jb3JlOiBCVVMgcmVzZXQNCmZ3 b2hjaTA6IGZ3b2hjaV9pbnRyX2NvcmU6IG5vZGVfaWQ9MHgwMDAwMDAwMCwg U2VsZklEIENvdW50PTEsIENZQ0xFTUFTVEVSIG1vZGUNCnBjaTI6IDxiYXNl IHBlcmlwaGVyYWwsIFNEIGhvc3QgY29udHJvbGxlcj4gYXQgZGV2aWNlIDEu MSAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMjogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDEuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMjog PGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDEuMyAobm8gZHJpdmVyIGF0 dGFjaGVkKQ0KcGNpMjogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDEu NCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRn ZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9u IGlzYWIwDQphdGFwY2kwOiA8SW50ZWwgSUNIN00gU0FUQTMwMCBjb250cm9s bGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2 LDB4YmZhMC0weGJmYWYgaXJxIDE3IGF0IGRldmljZSAzMS4yIG9uIHBjaTAN CmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGEwOiBbSVRI UkVBRF0NCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwDQphdGEx OiBbSVRIUkVBRF0NCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2 aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmFjcGlfdHowOiA8VGhl cm1hbCBab25lPiBvbiBhY3BpMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQsMHg2MiwweDY2IGlycSAx IG9uIGFjcGkwDQphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMA0Ka2JkMCBhdCBhdGtiZDANCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0N CmF0a2JkMDogW0lUSFJFQURdDQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEy IG9uIGF0a2JkYzANCnBzbTA6IFtHSUFOVC1MT0NLRURdDQpwc20wOiBbSVRI UkVBRF0NCnBzbTA6IG1vZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNl IElEIDANCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAt MHg3MSwweDcyLTB4NzcgaXJxIDggb24gYWNwaTANCmNwdTA6IDxBQ1BJIENQ VT4gb24gYWNwaTANCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTANCnA0dGNjMDogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHUwDQpjcHUxOiA8QUNQSSBDUFU+IG9u IGFjcGkwDQplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBD b250cm9sPiBvbiBjcHUxDQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJt YWwgQ29udHJvbD4gb24gY3B1MQ0KcG10aW1lcjAgb24gaXNhMA0Kb3JtMDog PElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNlN2ZmLDB4 Y2U4MDAtMHhjZmZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTANCnNjMDogPFN5 c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZH QSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+DQp2Z2EwOiA8 R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4 YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5v dCBmb3VuZC4NClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMN CmZpcmV3aXJlMDogMSBub2RlcywgbWF4aG9wIDw9IDAgY2FibGUgSVJNIGly bSgwKSAgKG1lKSANCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCANCnVzYnVz MDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMTogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMjogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjANCnVzYnVzMzogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjANCnVzYnVzNDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQp1Z2Vu MC4xOiA8SW50ZWw+IGF0IHVzYnVzMA0KdWh1YjA6IDxJbnRlbCBVSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwDQp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQ0KdWh1YjE6IDxJ bnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxDQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVz Mg0KdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyDQp1Z2VuMy4xOiA8SW50 ZWw+IGF0IHVzYnVzMw0KdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzDQp1 Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNA0KdWh1YjQ6IDxJbnRlbCBFSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXM0DQpkcml2ZXIgYnVnOiBVbmFibGUgdG8gc2V0IGRldmNsYXNz IChkZXZuYW1lOiAobnVsbCkpDQphZDA6IDMwNTI0NU1CIDxXREMgV0QzMjAw QkVLVC0wMEYzVDAgMTEuMDFBMTE+IGF0IGF0YTAtbWFzdGVyIFNBVEExNTAN CmFjZDA6IERWRFIgPFNPTlkgRFZEKy8tUlcgRFctUTU4QS9VRFMxPiBhdCBh dGExLW1hc3RlciBVRE1BMzMNCmhkYWMwOiBIREEgQ29kZWMgIzA6IFNpZ21h dGVsIFNUQUM5MjIwDQpoZGFjMDogSERBIENvZGVjICMxOiBDb25leGFudCAo VW5rbm93bikNCnBjbTA6IDxIREEgU2lnbWF0ZWwgU1RBQzkyMjAgUENNICMw IEFuYWxvZz4gYXQgY2FkIDAgbmlkIDEgb24gaGRhYzANCkdFT01fTEFCRUw6 IExhYmVsIGZvciBwcm92aWRlciBhZDBzMSBpcyBtc2Rvc2ZzL0RlbGxVdGls aXR5Lg0KR0VPTTogYWQwczM6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxh YmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4NCkdFT01fTEFCRUw6IExhYmVs IGZvciBwcm92aWRlciBhZDBzM2EgaXMgdWZzaWQvNGExMGMxYzY2MzVhYTZl NS4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzM2IgaXMg dWZzaWQvNGExMGMxYzY1YmFlNmEzMS4NCkdFT01fTEFCRUw6IExhYmVsIGZv ciBwcm92aWRlciBhZDBzM2QgaXMgdWZzaWQvNGExMGMxYzczOWM2ZGI5Mi4N CkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzM2UgaXMgdWZz aWQvNGExMGMxYzc5M2Q5ZDk4Ny4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBw cm92aWRlciBhZDBzM2YgaXMgdWZzaWQvNGExMGMxYzdhNzNmODFmNC4NCkdF T01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzM2cgaXMgdWZzaWQv NGExMGNmMjhhYzZmMWE2Ny4NCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1aHViMjogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVodWIzOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjQ6IDggcG9ydHMgd2l0 aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQphY2QwOiBGQUlMVVJFIC0g SU5RVUlSWSBJTExFR0FMIFJFUVVFU1QgYXNjPTB4MjQgYXNjcT0weDAwIA0K KHByb2JlMDphdGExOjA6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAg MCAwIDAgMCAwIA0KKHByb2JlMDphdGExOjA6MDowKTogQ0FNIFN0YXR1czog U0NTSSBTdGF0dXMgRXJyb3INCihwcm9iZTA6YXRhMTowOjA6MCk6IFNDU0kg U3RhdHVzOiBDaGVjayBDb25kaXRpb24NCihwcm9iZTA6YXRhMTowOjA6MCk6 IE5PVCBSRUFEWSBhc2M6M2EsMA0KKHByb2JlMDphdGExOjA6MDowKTogTWVk aXVtIG5vdCBwcmVzZW50DQoocHJvYmUwOmF0YTE6MDowOjApOiBVbnJldHJ5 YWJsZSBlcnJvcg0KYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBS RVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCANCmNkMCBhdCBhdGExIGJ1cyAw IHRhcmdldCAwIGx1biAwDQpjZDA6IDxTT05ZIERWRCstUlcgRFctUTU4QSBV RFMxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgDQpjZDA6IDMz LjAwME1CL3MgdHJhbnNmZXJzDQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2 aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2Vu dA0KU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhDQpXQVJOSU5HOiBXSVRORVNT IG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4N ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczNhDQpH RU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwYzFjNjViYWU2YTMxIHJlbW92 ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwYzFjNjYzNWFhNmU1 IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQw czNhIGlzIHVmc2lkLzRhMTBjMWM2NjM1YWE2ZTUuDQpHRU9NX0xBQkVMOiBM YWJlbCB1ZnNpZC80YTEwY2YyOGFjNmYxYTY3IHJlbW92ZWQuDQpHRU9NX0xB QkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczNnIGlzIHVmc2lkLzRhMTBj ZjI4YWM2ZjFhNjcuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwYzFj NzkzZDlkOTg3IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJv dmlkZXIgYWQwczNlIGlzIHVmc2lkLzRhMTBjMWM3OTNkOWQ5ODcuDQpHRU9N X0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwYzFjN2E3M2Y4MWY0IHJlbW92ZWQu DQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczNmIGlzIHVm c2lkLzRhMTBjMWM3YTczZjgxZjQuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNp ZC80YTEwYzFjNzM5YzZkYjkyIHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJl bCBmb3IgcHJvdmlkZXIgYWQwczNkIGlzIHVmc2lkLzRhMTBjMWM3MzljNmRi OTIuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwYzFjNjYzNWFhNmU1 IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEwY2YyOGFj NmYxYTY3IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTEw YzFjNzkzZDlkOTg3IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNp ZC80YTEwYzFjN2E3M2Y4MWY0IHJlbW92ZWQuDQpHRU9NX0xBQkVMOiBMYWJl bCB1ZnNpZC80YTEwYzFjNzM5YzZkYjkyIHJlbW92ZWQuDQp3bGFuMDogRXRo ZXJuZXQgYWRkcmVzczogMDA6MTQ6MjI6YWU6YmM6OTgNCmJmZTA6IGxpbmsg c3RhdGUgY2hhbmdlZCB0byBVUA0KbGFnZzA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUA0KbG9jayBvcmRlciByZXZlcnNhbDoNCjFzdCAweGQ4MTBlMzkw IGJ1ZndhaXQgKGJ1ZndhaXQpIEAgL29wdC9GcmVlQlNEL3N2bi9zcmMvc3lz L2tlcm4vdmZzX2Jpby5jOjI1NTUNCjJuZCAweGM0NmMzYTAwIGRpcmhhc2gg KGRpcmhhc2gpIEAgL29wdC9GcmVlQlNEL3N2bi9zcmMvc3lzL3Vmcy91ZnMv dWZzX2Rpcmhhc2guYzoyNzUNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJf dHJhY2Vfc2VsZl93cmFwcGVyKGMwOWNiYjUxLGU2NmM0Nzc4LGMwNmRjNTM1 LGMwNmNlNDNiLGMwOWNlOWM2LC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93cmFw cGVyKzB4MjYNCmtkYl9iYWNrdHJhY2UoYzA2Y2U0M2IsYzA5Y2U5YzYsYzQx MjBiNTAsYzQxMjQ1MDAsZTY2YzQ3ZDQsLi4uKSBhdCBrZGJfYmFja3RyYWNl KzB4MjkNCl93aXRuZXNzX2RlYnVnZ2VyKGMwOWNlOWM2LGM0NmMzYTAwLGMw OWVlYzkwLGM0MTI0NTAwLGMwOWVlOTFkLC4uLikgYXQgX3dpdG5lc3NfZGVi dWdnZXIrMHgyNQ0Kd2l0bmVzc19jaGVja29yZGVyKGM0NmMzYTAwLDksYzA5 ZWU5MWQsMTEzLDAsLi4uKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MzkN Cl9zeF94bG9jayhjNDZjM2EwMCwwLGMwOWVlOTFkLDExMyxjNDk2N2QyNCwu Li4pIGF0IF9zeF94bG9jaysweDg1DQp1ZnNkaXJoYXNoX2FjcXVpcmUoZDgx MGUzMzAsZDhhZTdhNzAsMTkwLGQ4YWU3YThjLGU2NmM0OGE0LC4uLikgYXQg dWZzZGlyaGFzaF9hY3F1aXJlKzB4MzUNCnVmc2Rpcmhhc2hfYWRkKGM0OTY3 ZDI0LGU2NmM0OGVjLDFjYThjLGU2NmM0ODkwLGU2NmM0ODk0LC4uLikgYXQg dWZzZGlyaGFzaF9hZGQrMHgxMw0KdWZzX2RpcmVudGVyKGM0OTY2MzI0LGM0 OTViYTc4LGU2NmM0OGVjLGU2NmM0YmQ0LDAsLi4uKSBhdCB1ZnNfZGlyZW50 ZXIrMHg3MjkNCnVmc19tYWtlaW5vZGUoZTY2YzRiZDQsMCxlNjZjNGFjYyxl NjZjNGEzNCxjMDk0NjZlNSwuLi4pIGF0IHVmc19tYWtlaW5vZGUrMHg0YWYN CnVmc19jcmVhdGUoZTY2YzRhY2MsZTY2YzRhZTQsMCwwLGU2NmM0YmE4LC4u LikgYXQgdWZzX2NyZWF0ZSsweDMwDQpWT1BfQ1JFQVRFX0FQVihjMGE3ZWI4 MCxlNjZjNGFjYywyLGMwOWMwZmFhLDMsLi4uKSBhdCBWT1BfQ1JFQVRFX0FQ VisweGE1DQp2bl9vcGVuX2NyZWQoZTY2YzRiYTgsZTY2YzRjNWMsMWIwLGM0 N2YyMTAwLGM0NmVlYzA4LC4uLikgYXQgdm5fb3Blbl9jcmVkKzB4MTllDQp2 bl9vcGVuKGU2NmM0YmE4LGU2NmM0YzVjLDFiMCxjNDZlZWMwOCw0YTEwYzM2 ZSwuLi4pIGF0IHZuX29wZW4rMHgzMw0Ka2Vybl9vcGVuYXQoYzQ2Y2RkODAs ZmZmZmZmOWMsMjg0MzZmYzAsMCxhMDMsLi4uKSBhdCBrZXJuX29wZW5hdCsw eDEwOA0Ka2Vybl9vcGVuKGM0NmNkZDgwLDI4NDM2ZmMwLDAsYTAyLDFiMCwu Li4pIGF0IGtlcm5fb3BlbisweDM1DQpvcGVuKGM0NmNkZDgwLGU2NmM0Y2Y4 LGMsYzA5Y2YyOTcsYzBhNWZhNTgsLi4uKSBhdCBvcGVuKzB4MzANCnN5c2Nh bGwoZTY2YzRkMzgpIGF0IHN5c2NhbGwrMHgyYTMNClhpbnQweDgwX3N5c2Nh bGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjANCi0tLSBzeXNjYWxsICg1 LCBGcmVlQlNEIEVMRjMyLCBvcGVuKSwgZWlwID0gMHgyODNiOGY5MywgZXNw ID0gMHhiZmJmYzUxYywgZWJwID0gMHhiZmJmYzVhOCAtLS0NCg0KLyogVVNC IGRyaXZlIGF0dGFjaGVkIGhlcmUgKi8NClVua25vd24gVVNCIGRldmljZTog dmVuZG9yIDB4MDRmYyBwcm9kdWN0IDB4MGMxNSBidXMgdWh1YjQNCnVnZW40 LjI6IDxTdW5wbHVzIFRlY2hub2xvZ3kgSW5jLj4gYXQgdXNidXM0DQp1bWFz czA6IDxCdWxrIE9ubHkgSW50ZXJmYWNlPiBvbiB1c2J1czQNCnVtYXNzMDog IFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAwMA0KdW1hc3Mw OjM6MDotMTogQXR0YWNoZWQgdG8gc2NidXMzDQpkYTAgYXQgdW1hc3Mtc2lt MCBidXMgMCB0YXJnZXQgMCBsdW4gMA0KZGEwOiA8ICA+IEZpeGVkIERpcmVj dCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRhMDogNDAuMDAwTUIvcyB0cmFu c2ZlcnMNCmRhMDogNTU3OTZNQiAoMTE0MjcwMzQ1IDUxMiBieXRlIHNlY3Rv cnM6IDI1NUggNjNTL1QgNzExM0MpDQoNCi8qIGNhbWNvbnRyb2wgcmVzY2Fu IDMgaGVyZSAqLw0KKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogbG9zdCBkZXZp Y2UNCihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IHJlbW92aW5nIGRldmljZSBl bnRyeQ0KZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAN CmRhMDogPCA1UEoyUlYzNFwwMDBcMDAwQFwwMDBcMDAwXDAwNCA4LjAzPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTA6IDQwLjAw ME1CL3MgdHJhbnNmZXJzDQpkYTA6IDU1Nzk2TUIgKDExNDI3MDM0NSA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDcxMTNDKQ0KKGRhMDp1bWFzcy1z aW0wOjA6MDowKTogU3luY2hyb25pemUgY2FjaGUgZmFpbGVkLCBzdGF0dXMg PT0gMHg0LCBzY3NpIHN0YXR1cyA9PSAweDANCg== ---559023410-758783491-1242659594=:20092-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 15:48:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64DE106567A for ; Mon, 18 May 2009 15:48:53 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8458FC22 for ; Mon, 18 May 2009 15:48:53 +0000 (UTC) (envelope-from ler@lerctr.org) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=NVFdmQBJRweNl7PM7/SJnmqM6K2e2r7TrfdtPdqohK0I4r8cXX0fMoB2C/DmD4M2ejdNIgw1Q3nkISCaIJLmZtK4TcVLrllWK2RKA5Qmqgqr73Qw9MQf569/t4LBQ7JxkYRN48yCxDe7IQQvi2wMChG23/jSFk6stE+5L2cbGIk=; Received: from thebighonker.lerctr.org ([192.147.25.65]:50205) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M64p6-0009Jb-OP; Mon, 18 May 2009 10:32:18 -0500 Date: Mon, 18 May 2009 10:32:14 -0500 (CDT) From: Larry Rosenman To: Adam McDougall In-Reply-To: <20090518145614.GF82547@egr.msu.edu> Message-ID: References: <20090518145614.GF82547@egr.msu.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.3 (----) X-LERCTR-Spam-Score: -4.3 (----) X-Spam-Report: SpamScore (-4.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135 X-LERCTR-Spam-Report: SpamScore (-4.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135 DomainKey-Status: no signature Cc: current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:48:55 -0000 On Mon, 18 May 2009, Adam McDougall wrote: > I'm not sure if this is related to recent kernel memory code changes > or what, but it hasn't happened with code from earlier than a couple > days ago. I had this happen twice, I think the first time was with > arc max set to 1024M, the second time was when arc max was unset in > loader.conf and the system had been up a few hours but the arc hadn't > been squeezed down to a small number yet: > Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M Free > > I've deleted the kernel since then but I did not change my sources, > I could build a new one and check where the pointers point to I think? > If needed. Or I could reproduce the panic if needed. It doesn't dump, > it just gets stuck after printing the panic. I wonder if this is the same crash I saw without getting all the info. What I saw was the wired memory getting to be most of the memory on the box, and then boom. see my post a few above this. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon May 18 16:18:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDCCA106566B for ; Mon, 18 May 2009 16:18:55 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id A6C658FC15 for ; Mon, 18 May 2009 16:18:55 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:33088 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M65Y5-00052e-5x; Mon, 18 May 2009 18:18:48 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id BF14A3A611; Mon, 18 May 2009 18:18:38 +0200 (CEST) Message-Id: From: Thomas Backman To: Wesley Shields In-Reply-To: <20090518161148.GA56646@atarininja.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 18:18:38 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <20090518161148.GA56646@atarininja.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M65Y5-00052e-5x. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M65Y5-00052e-5x b95cf2d2aa4db49689fcb89f034cc292 Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:18:56 -0000 On May 18, 2009, at 06:11 PM, Wesley Shields wrote: > On Wed, May 13, 2009 at 03:19:05PM +0200, Thomas Backman wrote: >> OK, so I first posted a thread on the forums about this in 7.2- >> RELEASE: >> http://forums.freebsd.org/showthread.php?t=3834 >> Then filed a PR, kern/134408: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 >> >> The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) >> GMT+2. >> >> Steps to reproduce: >> 1) Build DTrace capable kernel (I followed the wiki DTrace >> instructions) >> 2) Reboot; kldload dtraceall >> 3) dtrace -n 'syscall::open:entry { self->path = arg0; } >> syscall::open:return { printf("%s\n", copyinstr(self->path)); }' >> 4) Crash. >> >> Backtrace: >> [...] > > It's not the probe that is the problem. I suspect it's the copyinstr. > >> Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB >> RAM; >> and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and >> 8.0. > > I can easily reproduce this also. > > -- WXS Yup, it's copyinstr() crashing. It works if you simply replace printf(...) with printf("file opened\n") which doesn't copy anything in, and the backtrace seems (even to me ;) to point towards it. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Mon May 18 16:29:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F007E106564A for ; Mon, 18 May 2009 16:29:38 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id C545C8FC08 for ; Mon, 18 May 2009 16:29:38 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id E81FC5C34; Mon, 18 May 2009 12:11:48 -0400 (EDT) Date: Mon, 18 May 2009 12:11:48 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090518161148.GA56646@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:29:39 -0000 On Wed, May 13, 2009 at 03:19:05PM +0200, Thomas Backman wrote: > OK, so I first posted a thread on the forums about this in 7.2-RELEASE: > http://forums.freebsd.org/showthread.php?t=3834 > Then filed a PR, kern/134408: > http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 > > The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) > GMT+2. > > Steps to reproduce: > 1) Build DTrace capable kernel (I followed the wiki DTrace instructions) > 2) Reboot; kldload dtraceall > 3) dtrace -n 'syscall::open:entry { self->path = arg0; } > syscall::open:return { printf("%s\n", copyinstr(self->path)); }' > 4) Crash. > > Backtrace: > [root@vmware /usr/obj/usr/src/sys/DTRACE]# kgdb kernel.debug /var/ > crash/vmcore.3 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: from debugger > cpuid = 0 > Uptime: 3m10s > Physical memory: 368 MB > Dumping 81 MB: 66 50 34 18 2 > > Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from / > boot/kernel/dtraceall.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtraceall.ko > Reading symbols from /boot/kernel/profile.ko...Reading symbols from / > boot/kernel/profile.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/profile.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols > from /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from / > boot/kernel/cyclic.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/cyclic.ko > Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from / > boot/kernel/dtrace.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtrace.ko > Reading symbols from /boot/kernel/systrace.ko...Reading symbols from / > boot/kernel/systrace.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/systrace.ko > Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /boot/ > kernel/sdt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sdt.ko > Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /boot/ > kernel/fbt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/fbt.ko > Reading symbols from /boot/kernel/dtnfsclient.ko...Reading symbols > from /boot/kernel/dtnfsclient.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtnfsclient.ko > Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from / > boot/kernel/dtmalloc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtmalloc.ko > #0 doadump () at pcpu.h:223 > 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff80566b23 in boot (howto=260) at /usr/src/sys/kern/ > kern_shutdown.c:420 > #2 0xffffffff80566fac in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xffffffff801d3ef7 in db_panic (addr=Variable "addr" is not > available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801d43a1 in db_command (last_cmdp=0xffffffff80bd3620, > cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801d45f0 in db_command_loop () at /usr/src/sys/ddb/ > db_command.c:498 > #6 0xffffffff801d6599 in db_trap (type=Variable "type" is not > available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff80597135 in kdb_trap (type=10, code=0, > tf=0xfffffffe4e64e450) at /usr/src/sys/kern/subr_kdb.c:534 > #8 0xffffffff80843f81 in trap (frame=0xfffffffe4e64e450) at /usr/src/ > sys/amd64/amd64/trap.c:606 > #9 0xffffffff8081edc7 in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:223 > #10 0xffffffff8123c128 in dtrace_panic (format=Variable "format" is > not available. > ) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:601 > #11 0xffffffff8123c200 in dtrace_copycheck > (uaddr=18446744071581326184, kaddr=Variable "kaddr" is not available. > ) at dtrace_isa.c:527 > #12 0xffffffff8123c2bc in dtrace_copyinstr (uaddr=34365395808, > kaddr=18446744066201920856, size=256, > flags=0xffffffff8122f120) at dtrace_isa.c:558 > #13 0xffffffff81249e84 in dtrace_dif_emulate (difo=0xffffff00026a2d80, > mstate=0xfffffffe4e64ea00, > vstate=0xffffff0002548838, state=0xffffff0002548800) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:3446 > #14 0xffffffff8124b20a in dtrace_probe (id=Variable "id" is not > available. > ) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:6220 > #15 0xffffffff8137b155 in systrace_probe () from /boot/kernel/ > systrace.ko > #16 0xffffffff80843c4d in syscall (frame=0xfffffffe4e64ec90) at /usr/ > src/sys/amd64/amd64/trap.c:990 > #17 0xffffffff8081f050 in Xfast_syscall () at /usr/src/sys/amd64/amd64/ > exception.S:364 > #18 0x00000008005411fc in ?? () > Previous frame inner to this frame (corrupt stack?) > > Hope this helps to fix this bug - I assume syscall::open isn't the > only probe > affected as it's simply the very first one I tried. It's not the probe that is the problem. I suspect it's the copyinstr. > Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB RAM; > and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and 8.0. I can easily reproduce this also. -- WXS From owner-freebsd-current@FreeBSD.ORG Mon May 18 16:40:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE751065680 for ; Mon, 18 May 2009 16:40:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id A0B478FC19 for ; Mon, 18 May 2009 16:40:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 8288AFF12; Tue, 19 May 2009 04:22:59 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFoUr-rbyHsi; Tue, 19 May 2009 04:22:55 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 19 May 2009 04:22:55 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 457ED11432; Tue, 19 May 2009 04:22:54 +1200 (NZST) Date: Mon, 18 May 2009 09:22:54 -0700 From: Andrew Thompson To: Marcel Moolenaar Message-ID: <20090518162253.GA78829@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:41:00 -0000 Hi, I used gpart for the first time today and a few things came to mind. - The -s option doesnt take a humanised size, such as 256M - In a lot of cases the offset can be handled, ie 34 126090653 ad3 GPT (60G) 34 6 - free - (3.0K) 40 409600 1 efi (200M) 409640 41943040 2 freebsd-zfs (20G) 42352680 83738007 - free - (40G) If I was to do 'gpart add -s 10G -t freebsd-ufs ad3' then I would expect the utility to search for 20971520 free sectors and place the new partition at offset 42352680 automagically. - I cant see how to use wildcard to take all the remaining space. This would make scripting much easier as it wouldnt need to grok the geometry first. gpart create -s GPT ad3 gpart add -s 256M -t freebsd-ufs ad3 gpart add -s 2G -t freebsd-swap ad3 gpart add -s max -t freebsd-ufs ad3 cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon May 18 16:58:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E131065677 for ; Mon, 18 May 2009 16:58:41 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id F134E8FC08 for ; Mon, 18 May 2009 16:58:40 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5BCE7199087; Mon, 18 May 2009 18:58:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4D789199081; Mon, 18 May 2009 18:58:39 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 37A3C199074; Mon, 18 May 2009 18:58:39 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF166) with ESMTP id 2009051818583809-3692 ; Mon, 18 May 2009 18:58:38 +0200 Received: by wep4035 (sSMTP sendmail emulation); Mon, 18 May 2009 18:58:38 +0200 Date: Mon, 18 May 2009 18:58:38 +0200 From: Alexey Shuvaev To: Hans Petter Selasky Message-ID: <20090518165838.GA8670@wep4035.physik.uni-wuerzburg.de> References: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> <200905181546.02302.hselasky@c2i.net> MIME-Version: 1.0 In-Reply-To: <200905181546.02302.hselasky@c2i.net> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.19 (2009-01-05) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF166 | March 12, 2009) at 05/18/2009 06:58:38 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF166 | March 12, 2009) at 05/18/2009 06:58:38 PM, Serialize complete at 05/18/2009 06:58:38 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Setting max 500 mA (Was Re: [new-usb] - USB_ERR_NO_POWER on keyboard hub) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:58:42 -0000 On Mon, May 18, 2009 at 03:46:01PM +0200, Hans Petter Selasky wrote: > On Monday 18 May 2009, Renato Botelho wrote: > > I have a Sun USB Type 7 keyboard, and this keyboard has an USB hub > > with 3 ports on it. I'm using one of those 3 ports to plug the mouse and > > it's working fine. > > > > uhub5: 4 ports with 3 removable, bus powered > > ugen0.3: at usbus0 > > ums0: on usbus0 > > ums0: 3 buttons and [XYZ] coordinates ID=0 > > ugen0.4: at usbus0 > > ukbd0: > 2.00/1.04, addr 4> on usbus0 > > kbd2 at ukbd0 > > > > When I tried to plug a pen drive on anothe one, I got this: > > > > usb2_set_config_index:531: power exceeded 500 > 100 > > usb2_set_config_index:531: power exceeded 500 > 100 > > usb2_alloc_device:1755: Failure selecting configuration index 0: > > USB_ERR_NO_POWER, port 2, addr 5 (ignored) > > ugen0.5: at usbus0 > > pid 3705 (hald-probe-usb2-dev), uid 0: exited on signal 11 > > ugen0.5: at usbus0 (disconnected) > > > > usb2_set_config_index:531: power exceeded 500 > 100 > > usb2_set_config_index:531: power exceeded 500 > 100 > > usb2_alloc_device:1755: Failure selecting configuration index 0: > > USB_ERR_NO_POWER, port 1, addr 5 (ignored) > > ugen0.5: at usbus0 > > pid 3886 (hald-probe-usb2-dev), uid 0: exited on signal 11 > > ugen0.5: at usbus0 (disconnected) > > > > I'm using FreeBSD 8.0-current r192140. > > > > Let me know if there is more information i need to provide. > > > > Thanks > > Hi, > > Your Keyboard HUB technically does not allow current consumption above 100mA > per port. Your memstick reports it needs 500mA. Probably you can hack around > it, but then your hardware might break ... > Hello! Somewhat not directly related. Is it possible (in a not too intrusive way) to allow max 500mA current for a device on a root HUB? This is to allow fast charging of mini-usb connected handy. (If something dies, I knew what I was doing :) Thanks, Alexey. From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:07:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F111065750 for ; Mon, 18 May 2009 17:07:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 952388FC21 for ; Mon, 18 May 2009 17:07:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 46A5C46B2A; Mon, 18 May 2009 13:07:38 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 352468A026; Mon, 18 May 2009 13:07:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 11:29:51 -0400 User-Agent: KMail/1.9.7 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <20090516031332.GG82547@egr.msu.edu> <5D988481-068A-4AB3-952E-255BEA1D9DA7@wanderview.com> In-Reply-To: <5D988481-068A-4AB3-952E-255BEA1D9DA7@wanderview.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181129.51526.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 18 May 2009 13:07:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Adam McDougall , Artem Belevich , Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:07:39 -0000 On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: > 1) It changes the kproc(9) API by adding a kproc_create_priority() > function that allows you to set the priority of the newly created > thread. I'm not sure how people feel about this. Actually, I almost think we should just add a priority argument to each of the routines that creates a new kthread/kproc. Perhaps allow a priority of 0 to let the thread run with the default priority. Hmm, it looks like kthreads default to running with whatever thread0 runs at (PVM) which is probably not really ideal. Having an explicit priority for every kthread would probably be best. Most kthreads should probably be at PZERO by default I think. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:07:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3C771065757 for ; Mon, 18 May 2009 17:07:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7419B8FC18 for ; Mon, 18 May 2009 17:07:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2951246B03; Mon, 18 May 2009 13:07:40 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B3F558A028; Mon, 18 May 2009 13:07:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 11:34:28 -0400 User-Agent: KMail/1.9.7 References: <3c0b01820905141202w113966dp4bfbab73d84d585@mail.gmail.com> <3c0b01820905141603g59e439c1y7202532bc1f4f87@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181134.29076.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 18 May 2009 13:07:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Sack , d@delphij.net, Ryan Stone Subject: Re: Broadcom bge(4) panics while shutting down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:07:41 -0000 On Thursday 14 May 2009 7:45:21 pm Ryan Stone wrote: > This is hopefully a stupid question, but what's stopping bge(or em, or any > driver) from unloading and freeing the ifp(and blowing away the module's > .text section) after we drop the sc lock? The detach routine is supposed to handle that by blocking until any other contexts which can call into the driver are finished. So, for example, bus_teardown_intr() will block if a device's interrupt handler is currently running and not return until the handler is fully detached from the interrupt resource and when the system knows that the handler is finished executing. Similarly with callout_drain() for callout routines and taskqueue_drain() for asynchronous tasks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:14:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936D0106564A for ; Mon, 18 May 2009 17:14:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id EE3D38FC12 for ; Mon, 18 May 2009 17:14:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=LqFJ_cFnVGsA:10 a=twbyJQYelQEA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=qHjUS2GN3Qx09gxOFq0A:9 a=FSr0n8mdybiS0XPcankA:7 a=S5x0yqKE4xTKpaudH7PzwwcVfhsA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1244305099; Mon, 18 May 2009 19:14:44 +0200 From: Hans Petter Selasky To: Alexey Shuvaev Date: Mon, 18 May 2009 19:17:14 +0200 User-Agent: KMail/1.9.7 References: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> <200905181546.02302.hselasky@c2i.net> <20090518165838.GA8670@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090518165838.GA8670@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181917.16039.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: Setting max 500 mA (Was Re: [new-usb] - USB_ERR_NO_POWER on keyboard hub) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:14:46 -0000 On Monday 18 May 2009, Alexey Shuvaev wrote: > On Mon, May 18, 2009 at 03:46:01PM +0200, Hans Petter Selasky wrote: > > On Monday 18 May 2009, Renato Botelho wrote: > > > I have a Sun USB Type 7 keyboard, and this keyboard has an USB hub > > > with 3 ports on it. I'm using one of those 3 ports to plug the mouse > > > and it's working fine. > > > > > > uhub5: 4 ports with 3 removable, bus powered > > > ugen0.3: at usbus0 > > > ums0: on > > > usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 > > > ugen0.4: at usbus0 > > > ukbd0: > > 2.00/1.04, addr 4> on usbus0 > > > kbd2 at ukbd0 > > > > > > When I tried to plug a pen drive on anothe one, I got this: > > > > > > usb2_set_config_index:531: power exceeded 500 > 100 > > > usb2_set_config_index:531: power exceeded 500 > 100 > > > usb2_alloc_device:1755: Failure selecting configuration index 0: > > > USB_ERR_NO_POWER, port 2, addr 5 (ignored) > > > ugen0.5: at usbus0 > > > pid 3705 (hald-probe-usb2-dev), uid 0: exited on signal 11 > > > ugen0.5: at usbus0 (disconnected) > > > > > > usb2_set_config_index:531: power exceeded 500 > 100 > > > usb2_set_config_index:531: power exceeded 500 > 100 > > > usb2_alloc_device:1755: Failure selecting configuration index 0: > > > USB_ERR_NO_POWER, port 1, addr 5 (ignored) > > > ugen0.5: at usbus0 > > > pid 3886 (hald-probe-usb2-dev), uid 0: exited on signal 11 > > > ugen0.5: at usbus0 (disconnected) > > > > > > I'm using FreeBSD 8.0-current r192140. > > > > > > Let me know if there is more information i need to provide. > > > > > > Thanks > > > > Hi, > > > > Your Keyboard HUB technically does not allow current consumption above > > 100mA per port. Your memstick reports it needs 500mA. Probably you can > > hack around it, but then your hardware might break ... > > Hello! > > Somewhat not directly related. > Is it possible (in a not too intrusive way) to allow max 500mA current > for a device on a root HUB? This is to allow fast charging of mini-usb > connected handy. > > (If something dies, I knew what I was doing :) Hi, There is a quirk to do the opposite of what you want, to force the device BUS-powered. But not to force it self powered. Look in: /sys/dev/usb/usb_device.c And the set_config_index function. --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:15:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 298861065674 for ; Mon, 18 May 2009 17:15:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id B43908FC18 for ; Mon, 18 May 2009 17:15:55 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=LqFJ_cFnVGsA:10 a=twbyJQYelQEA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=QQr4hZsIjlS_HkYgLhQA:9 a=sHCsdQB5QB8uv0c4fSl2cQmrh2sA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 901843661; Mon, 18 May 2009 19:15:54 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 19:18:23 +0200 User-Agent: KMail/1.9.7 References: <747dc8f30905180627h25c83dbt8b5fd8527bad6f15@mail.gmail.com> <200905181546.02302.hselasky@c2i.net> <20090518165838.GA8670@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090518165838.GA8670@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905181918.24401.hselasky@c2i.net> Cc: Alexey Shuvaev Subject: Re: Setting max 500 mA (Was Re: [new-usb] - USB_ERR_NO_POWER on keyboard hub) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:15:56 -0000 On Monday 18 May 2009, Alexey Shuvaev wrote: > > Hello! > > Somewhat not directly related. > Is it possible (in a not too intrusive way) to allow max 500mA current > for a device on a root HUB? This is to allow fast charging of mini-usb > connected handy. > > (If something dies, I knew what I was doing :) It won't die. It might burn your house :-) --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 15:56:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B382106564A; Mon, 18 May 2009 15:56:21 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132::1]) by mx1.freebsd.org (Postfix) with ESMTP id EAA1A8FC1E; Mon, 18 May 2009 15:56:20 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1M65CH-000My9-4i; Mon, 18 May 2009 16:56:13 +0100 Date: Mon, 18 May 2009 16:56:13 +0100 From: Tim Bishop To: Martin Wilke Message-ID: <20090518155613.GT86061@carrick.bishnet.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.13 (2006-08-11) X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.6, required 5, autolearn=not spam, BAYES_00 -2.60, NO_RELAYS -0.00) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net X-Mailman-Approved-At: Mon, 18 May 2009 17:24:22 +0000 Cc: Doug Poland , ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Greg Byshenk Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:56:21 -0000 On Mon, May 18, 2009 at 08:38:18AM -0500, Doug Poland wrote: > On Sun, May 17, 2009 19:25, Greg Byshenk wrote: > > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > >> > >> We rolled a new tarball with the patch from Juergen Lock [1] > >> with a posible fix for AMD64 users, tested on 3 machines > >> which now works without problems. Many Thanks to him for > >> his nice work! > >> > >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Working for me with a fresh cvsup of 7.2-STABLE (17 May 09). > Installing a 7.2-RELEASE amd64 guest as I write this. Works for me, but I've not been able to get a 64 bit guest to work. I get the following error when booting the installer: CPU doesn't support long mode I think I've got all the right options set. Maybe my CPU doesn't support the necessary VM stuff to let a 64 bit guest work? I'm also still seeing the following on loading vboxdrv: kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 kldload: unexpected relocation type 10 vboxdrv: fAsync=0 offMin=0x41f offMax=0x53b Are others still seeing that on amd64? Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F1821065670; Mon, 18 May 2009 17:31:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0658FC2C; Mon, 18 May 2009 17:31:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B206546B23; Mon, 18 May 2009 13:31:18 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6D4A48A026; Mon, 18 May 2009 13:31:17 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Mon, 18 May 2009 13:31:10 -0400 User-Agent: KMail/1.9.7 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> In-Reply-To: <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905181331.11174.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 18 May 2009 13:31:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich , Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:31:19 -0000 On Monday 18 May 2009 1:12:59 pm Attilio Rao wrote: > 2009/5/18 John Baldwin : > > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: > >> =C2=A0 =C2=A01) It changes the kproc(9) API by adding a kproc_create_p= riority() > >> function that allows you to set the priority of the newly created > >> thread. =C2=A0I'm not sure how people feel about this. > > > > Actually, I almost think we should just add a priority argument to each= of=20 the > > routines that creates a new kthread/kproc. =C2=A0Perhaps allow a priori= ty of 0=20 to > > let the thread run with the default priority. =C2=A0Hmm, it looks like = kthreads > > default to running with whatever thread0 runs at (PVM) which is probabl= y=20 not > > really ideal. =C2=A0Having an explicit priority for every kthread would= =20 probably > > be best. =C2=A0Most kthreads should probably be at PZERO by default I t= hink. >=20 > I'm not sure I agree here. > 1) Maybe I missed it (so please point me to the right one) but I > didn't see a deep analysis of what messed up with the priorities there Solaris makes certain assumptions about the relative priorities of ZFS thre= ads=20 and our ZFS doesn't set the priorities the same. I think specifically ther= e=20 are "cleaner" threads which have a higher priority on Solaris than other ZF= S=20 threads and Solaris depends on that to avoid deadlocks. > 2) I think this KPI can be dangerous and lead to problems. Priority is > something highly fragile. All the more reason to make developers _think_ about the priority of each=20 kthread they create. Right now all these threads start out with a priority= =20 of PVM since that is what thread0 runs at. Does that sound right to you? = Do=20 you think many folks realize that? It sounds very bogus to me. I think=20 forcing people to pick a sensible priority for each thread is far better th= an=20 the complete lack of thought that often happens now. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:35:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 623D1106566B; Mon, 18 May 2009 17:35:15 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 616158FC1C; Mon, 18 May 2009 17:35:14 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by ewy3 with SMTP id 3so4082341ewy.43 for ; Mon, 18 May 2009 10:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=K8zXvLp7MuqdyJt5Y+BYEriYpwWeE8SO1gctehyJZWU=; b=Uh3cWIoxm7Qo3Qho1GWf9IUyz2ry1HH+lXJcK1xEqiiH8dgVghO3Gz7oODtKbioYcj YUAKPwHBjSTElGTJDaUrDv9xZ9LsAHm05Pw6TlRid4QeTnrC3pAZ4zidfJkPLuz5TlAZ NPlN3qKFerxJh6A4KcfYi7SmU0ILBTjmYYbwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Ju2UaZTdoeb5uZUzZ6Zzy1DKaLy5l5zL5zRaw13oSw6IE76Ug53H8Kzs77+TTxgLQE 5Y1fkAMJiqbnbS8b5dPZVMruEniljTJMmtQs7AArw5F9keNLabd9zcBmw2jsh812XJRT ucty2ULood4SCGB8GdmWPvqzqenuKVQ2s3EQo= MIME-Version: 1.0 Sender: dzentoo@gmail.com Received: by 10.210.134.6 with SMTP id h6mr4686737ebd.47.1242668113091; Mon, 18 May 2009 10:35:13 -0700 (PDT) In-Reply-To: <20090518155613.GT86061@carrick.bishnet.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> <20090518155613.GT86061@carrick.bishnet.net> From: Benoit Calvez Date: Mon, 18 May 2009 19:34:53 +0200 X-Google-Sender-Auth: 2f4d48afb46d350e Message-ID: <3481d8e60905181034l20a5d722m2ca340577a71d0f7@mail.gmail.com> To: Tim Bishop Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Poland , Martin Wilke , ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Greg Byshenk Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:35:16 -0000 On Mon, May 18, 2009 at 5:56 PM, Tim Bishop wrote: > On Mon, May 18, 2009 at 08:38:18AM -0500, Doug Poland wrote: > > On Sun, May 17, 2009 19:25, Greg Byshenk wrote: > > > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > >> > > >> We rolled a new tarball with the patch from Juergen Lock [1] > > >> with a posible fix for AMD64 users, tested on 3 machines > > >> which now works without problems. Many Thanks to him for > > >> his nice work! > > >> > > >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > > > Working for me with a fresh cvsup of 7.2-STABLE (17 May 09). > > Installing a 7.2-RELEASE amd64 guest as I write this. > > Works for me, but I've not been able to get a 64 bit guest to work. I > get the following error when booting the installer: > > CPU doesn't support long mode > > I think I've got all the right options set. Maybe my CPU doesn't support > the necessary VM stuff to let a 64 bit guest work? > > I'm also still seeing the following on loading vboxdrv: > > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > vboxdrv: fAsync=0 offMin=0x41f offMax=0x53b > > Are others still seeing that on amd64? > got the same in dmesg: kldload: unexpected relocation type 10 vboxdrv: fAsync=1 offMin=0xff94c offMax=0xff94c supdrvGipCreate: omni timer not supported, falling back to synchronous mode > > Tim. > > -- > Tim Bishop > http://www.bishnet.net/tim/ > PGP Key: 0x5AE7D984 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Benoit Calvez. From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:35:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A0F2106566B for ; Mon, 18 May 2009 17:35:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id F21798FC08 for ; Mon, 18 May 2009 17:35:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz9 with SMTP id 9so3339577bwz.43 for ; Mon, 18 May 2009 10:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=PYfZ/UALqdApvUkTH4nWzOtq9DW8wtFqdabzQDGcRVI=; b=n8IZd2afQewwmNmlnsvmakjGUbgB7Qeum7p97WsTw4DAp/isIUtYF8Spbo2mZVUehN 20bzSO0/f0zQuVfZmzvXi4YaiqtEbziBm1O4vE5stzHQfFokQ+QJUR927n7+zGLNYNd3 dLCCOlB65yJM/CrDm2xQAJs46YVc2mM8qJyfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iBZrE6CB+0jkPPXCgXlx/1h+0R65zsFI7vr+dGAaSiEsoxaBh8jDFVA1X/Ttq3Ovz8 S6XADCaVeIuNSX0HJdn59iZQayQMuEn5v/xn9j4E1fYwqhuyqOcJhsNzO+yuduAe0deF eq+1D39WzfIIT7qC+TdEk9vrumEJk77yYzUTM= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.122.15 with SMTP id j15mr4525266far.10.1242666779855; Mon, 18 May 2009 10:12:59 -0700 (PDT) In-Reply-To: <200905181129.51526.jhb@freebsd.org> References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <20090516031332.GG82547@egr.msu.edu> <5D988481-068A-4AB3-952E-255BEA1D9DA7@wanderview.com> <200905181129.51526.jhb@freebsd.org> Date: Mon, 18 May 2009 19:12:59 +0200 X-Google-Sender-Auth: 8a0e94ef28d1601d Message-ID: <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich , Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:35:25 -0000 2009/5/18 John Baldwin : > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: >> =C2=A0 =C2=A01) It changes the kproc(9) API by adding a kproc_create_pri= ority() >> function that allows you to set the priority of the newly created >> thread. =C2=A0I'm not sure how people feel about this. > > Actually, I almost think we should just add a priority argument to each o= f the > routines that creates a new kthread/kproc. =C2=A0Perhaps allow a priority= of 0 to > let the thread run with the default priority. =C2=A0Hmm, it looks like kt= hreads > default to running with whatever thread0 runs at (PVM) which is probably = not > really ideal. =C2=A0Having an explicit priority for every kthread would p= robably > be best. =C2=A0Most kthreads should probably be at PZERO by default I thi= nk. I'm not sure I agree here. 1) Maybe I missed it (so please point me to the right one) but I didn't see a deep analysis of what messed up with the priorities there 2) I think this KPI can be dangerous and lead to problems. Priority is something highly fragile. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon May 18 17:38:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74921065770; Mon, 18 May 2009 17:38:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5298FC16; Mon, 18 May 2009 17:38:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm12 with SMTP id 12so3380129fxm.43 for ; Mon, 18 May 2009 10:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Iwijg4t5QZUMtH35PCYnaID0rf5Jcyt66A5xz9YDjvM=; b=Pdv1DvBNTWAulLxvbabhMLm+xhzunZzt5nrljlComlPJd+3JSfcdZnePrfOT6tLOoi QPS2OMN0IpSPQAWflJ0QhROWYhb5/63mEGGAoEbBdFC+7EXfsJvoE6g09FQXYlEN2Vra Jp+g7HDKxZQCCkHZOcGgVo06UCXnhhwHnNVks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DPVy8R69wJuwOptEhC+WzOcFkaOi+7E17PfnMCB3UpjfpI7t1vEqKfIcoPf+9WI4Ch /SDSGBulDppNAIxxsK++EnfcW/Ce4gP28Vqj1+NHsVJj0yhE29Ls0XCKXcxVPrt9+xoe 2VIIuCYUvWB9rN/7vEun4t0IB2YOEh2ZpEYHc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.113.68 with SMTP id z4mr4502847fap.72.1242668284002; Mon, 18 May 2009 10:38:04 -0700 (PDT) In-Reply-To: <200905181331.11174.jhb@freebsd.org> References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org> Date: Mon, 18 May 2009 19:38:03 +0200 X-Google-Sender-Auth: b5ce08f50f9124d3 Message-ID: <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich , Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 17:38:06 -0000 2009/5/18 John Baldwin : > On Monday 18 May 2009 1:12:59 pm Attilio Rao wrote: >> 2009/5/18 John Baldwin : >> > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: >> >> =C2=A0 =C2=A01) It changes the kproc(9) API by adding a kproc_create_= priority() >> >> function that allows you to set the priority of the newly created >> >> thread. =C2=A0I'm not sure how people feel about this. >> > >> > Actually, I almost think we should just add a priority argument to eac= h of > the >> > routines that creates a new kthread/kproc. =C2=A0Perhaps allow a prior= ity of 0 > to >> > let the thread run with the default priority. =C2=A0Hmm, it looks like= kthreads >> > default to running with whatever thread0 runs at (PVM) which is probab= ly > not >> > really ideal. =C2=A0Having an explicit priority for every kthread woul= d > probably >> > be best. =C2=A0Most kthreads should probably be at PZERO by default I = think. >> >> I'm not sure I agree here. >> 1) Maybe I missed it (so please point me to the right one) but I >> didn't see a deep analysis of what messed up with the priorities there > > Solaris makes certain assumptions about the relative priorities of ZFS th= reads > and our ZFS doesn't set the priorities the same. =C2=A0I think specifical= ly there > are "cleaner" threads which have a higher priority on Solaris than other = ZFS > threads and Solaris depends on that to avoid deadlocks. OMG. This still doesn't explain priorities like 49 or such seen in the first report as long as we don't set priorities by hand, >> 2) I think this KPI can be dangerous and lead to problems. Priority is >> something highly fragile. > > All the more reason to make developers _think_ about the priority of each > kthread they create. =C2=A0Right now all these threads start out with a p= riority > of PVM since that is what thread0 runs at. =C2=A0Does that sound right to= you? =C2=A0Do > you think many folks realize that? =C2=A0It sounds very bogus to me. =C2= =A0I think > forcing people to pick a sensible priority for each thread is far better = than > the complete lack of thought that often happens now. At least, we could leave the default version not accepting any priority for threads which are not interested on that and trying to move people to the new KPI _only and if only_ they need real boosts or lay down. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon May 18 18:12:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1D861065672; Mon, 18 May 2009 18:12:50 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id C13208FC1A; Mon, 18 May 2009 18:12:49 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by ewy3 with SMTP id 3so4111123ewy.43 for ; Mon, 18 May 2009 11:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=n8vve8n9v4VuvhpG3w1wdtzfZUQrrgTyZ0x++NBk5Rw=; b=hDqxzrmGcKo+OkWjkeZ0sK0vH+w+Xiisuq8sLXCT4EKXCQquC5+B4NM7zaQ7Yrx0mm 3nR3eqRjbUfGFWSluvbQ6DAi0Ypg5NPe8e0SggN3vvb2y4IBqJXmEleHrdVHQWxaaMyv ih8yfjyTWmIGZvN8CRyYRBy/Sn2b1RJdYBEDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LQAHG5B6C88VObdj6iGojjIbCkkXy6laOhq4YenZQYxkuQMl/s7/Ag3lbqx0oJcDZU 8obId7j132ezaokXZ3phzGTCtgKROWJnwo0THI8coBXEJUek594o8X/dLP6xB8W9nYcY OBchO19BiOSaW+ed9lJTQU6Kj+KJIPqwfcp/M= MIME-Version: 1.0 Received: by 10.216.11.138 with SMTP id 10mr2132755wex.51.1242670368536; Mon, 18 May 2009 11:12:48 -0700 (PDT) In-Reply-To: <20090518155613.GT86061@carrick.bishnet.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> <20090518155613.GT86061@carrick.bishnet.net> Date: Mon, 18 May 2009 22:12:48 +0400 Message-ID: <19e7832a0905181112h3470a327i45d81abda65b5de9@mail.gmail.com> From: Andrey Fesenko To: Tim Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:12:51 -0000 On Mon, May 18, 2009 at 7:56 PM, Tim Bishop wrote: > On Mon, May 18, 2009 at 08:38:18AM -0500, Doug Poland wrote: > > On Sun, May 17, 2009 19:25, Greg Byshenk wrote: > > > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > >> > > >> We rolled a new tarball with the patch from Juergen Lock [1] > > >> with a posible fix for AMD64 users, tested on 3 machines > > >> which now works without problems. Many Thanks to him for > > >> his nice work! > > >> > > >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > > > Working for me with a fresh cvsup of 7.2-STABLE (17 May 09). > > Installing a 7.2-RELEASE amd64 guest as I write this. > > Works for me, but I've not been able to get a 64 bit guest to work. I > get the following error when booting the installer: > > CPU doesn't support long mode > > I think I've got all the right options set. Maybe my CPU doesn't support > the necessary VM stuff to let a 64 bit guest work? > > I'm also still seeing the following on loading vboxdrv: > > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > vboxdrv: fAsync=0 offMin=0x41f offMax=0x53b > > Are others still seeing that on amd64? > > FreeBSD 8.0-CURRENT #0: Sun May 17 07:56:14 MSD 2009 amd64 got the same in/var/log/messages May 18 22:00:02 my_book newsyslog[25948]: logfile turned over due to size>100K May 18 22:07:28 my_book kernel: kldload: unexpected relocation type 10 May 18 22:07:28 my_book last message repeated 11 times May 18 22:07:28 my_book kernel: vboxdrv: fAsync=0 offMin=0x499 offMax=0x8744 From owner-freebsd-current@FreeBSD.ORG Mon May 18 18:16:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C3F0106567A for ; Mon, 18 May 2009 18:16:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 574408FC2E for ; Mon, 18 May 2009 18:16:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4IHrFnM043180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 May 2009 10:53:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A11A08B.6090309@errno.com> Date: Mon, 18 May 2009 10:53:15 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: Subject: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:16:57 -0000 The patch here: http://people.freebsd.org/~sam/monitor-20090518.patch has significant changes to monitor mode operation. Most importantly it replaces DLT_IEEE802_11 support in net80211 by DLT_IEEE802_11_RADIO and removes the latter from the underlying device. The upshot is that you can no longer do: tcpdump -i ath0 instead you will now need a wlanX ifnet; e.g. ifconfig wlan create wlandev ath0 wlanmode monitor channel 6 up tcpdump -i wlan0 -y IEEE802_11_RADIO This addresses the longstanding issue that applications like kismet that want radiotap data needed to open two ifnets, one to receive data and one to do channel changes. My main concern is whether losing DLT_IEEE802_11 support will affect any apps. Those that depend on it should be easy to change; you just request a different DLT and strip the radiotap header from tap'd frames (or similar). In sweeping the drivers to do these changes I've made radiotap support more consistent and improved some drivers. Drivers not tested so far: malo, ipw, wpi, and upgt. I tested iwi and it appears broken in that no frames are rx'd but I'm not sure I'll look at it before 8.0. I plan to commit these changes by the end of the week. Sam From owner-freebsd-current@FreeBSD.ORG Mon May 18 19:05:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A40F0106564A; Mon, 18 May 2009 19:05:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 46F118FC0C; Mon, 18 May 2009 19:05:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2250179qwe.7 for ; Mon, 18 May 2009 12:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=9RUDr08hQeiL0STeG3j7Mc5/8ll27jatqgjhw8y2VSo=; b=UdHbPxbZHG/Ti9dt1d0YsB+HUDAQQQI26JeFgQEgW0WG8jLpXjHXt9oJOyIZwZ9308 /i06YPa0mrxg0wHv3vyCmzhMStHysCLt/1IcvTD8XoCWFMg240VpG20bZOZxVVj8lgNJ D3UUy4coAFpOLecjp212yoSC1SwtI5jdV0+w0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FVwhnrm3jCemZr6Mt4Y9eQtDFjPPeTEP8u381DO0lARmUMJF6+yZ053r5+cyGt+DIe Wm4C+eDe8P/p+JDlrjpe8XtBH2oTlHeFusqVoJdsqG7W/J63w0ww82UiQ1/pgXwk/rtF qtRXTy5puukvkkzF+cIyyxQdGoQenovkEi9Uw= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.84.82 with SMTP id i18mr2999987qcl.90.1242673509896; Mon, 18 May 2009 12:05:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2009 03:05:09 +0800 X-Google-Sender-Auth: 63944ac50c6858bd Message-ID: From: Adrian Chadd To: freebsd-xen@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-current/Xen and block device enumeration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:05:12 -0000 (Cross-posting to -current because of the way a badly confused Xen DomU confuses GEOM and populates invalid stuff.) 2009/5/19 Adrian Chadd : > This config: > > disk =3D [ > =A0 =A0 =A0 =A0'phy:/dev/hosting2_data2/XEN_freebsd_root,0x01,w', > =A0 =A0 =A0 =A0'phy:/dev/hosting2_data2/XEN_freebsd_swap,0x02,w' > =A0 =A0 =A0 =A0] Confuses some "linux" device unit naming type magic in the blkfront device = code. Anyway. To get xbd0 and xbd1 I need to use 0xCA00 and 0xCA10. The code matches on major 202 (0xca) and shifts the minor bits right to get partition ids (which I'm not using here.) This outlines some sanity checking and debugging which should be improved a little. > Gives this output in dmesg: > > xbd0: 10240MB at device/vbd/1 on xenbus0 > GEOM: new disk xbd0 > xbd1: 512MB at device/vbd/2 on xenbus0 > WARNING: WITNESS option enabled, expect reduced performance. > GEOM: new disk xbd0 .. since I shouldn't be able to do that. > > and then ls -l /dev/xbd* : > > freebsd_domu# ls -l /dev/xbd* > crw-r----- =A01 root =A0operator =A0 =A00, =A041 May 18 02:51 /dev/xbd0 > crw-r----- =A01 root =A0operator =A0 =A00, =A041 May 18 02:51 /dev/xbd0 .. or that. Adrian From owner-freebsd-current@FreeBSD.ORG Mon May 18 19:06:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C37D11065674; Mon, 18 May 2009 19:06:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 934AF8FC28; Mon, 18 May 2009 19:06:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 422A946B0C; Mon, 18 May 2009 15:06:01 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A38008A026; Mon, 18 May 2009 15:05:59 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Mon, 18 May 2009 14:57:24 -0400 User-Agent: KMail/1.9.7 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181331.11174.jhb@freebsd.org> <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> In-Reply-To: <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905181457.25238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 18 May 2009 15:06:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich , Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:06:02 -0000 On Monday 18 May 2009 1:38:03 pm Attilio Rao wrote: > 2009/5/18 John Baldwin : > > On Monday 18 May 2009 1:12:59 pm Attilio Rao wrote: > >> 2009/5/18 John Baldwin : > >> > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: > >> 2) I think this KPI can be dangerous and lead to problems. Priority is > >> something highly fragile. > > > > All the more reason to make developers _think_ about the priority of ea= ch > > kthread they create. =C2=A0Right now all these threads start out with a= priority > > of PVM since that is what thread0 runs at. =C2=A0Does that sound right = to you? =C2=A0Do > > you think many folks realize that? =C2=A0It sounds very bogus to me. = =C2=A0I think > > forcing people to pick a sensible priority for each thread is far bette= r than > > the complete lack of thought that often happens now. >=20 > At least, we could leave the default version not accepting any > priority for threads which are not interested on that and trying to > move people to the new KPI _only and if only_ they need real boosts or > lay down. I would rather force people to think. We've had problems in the past with folks not thinking clearly enough (e.g. just using a constant to tsleep() instead of figuring out a real timeout value to use). =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 18 16:49:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B450A106564A; Mon, 18 May 2009 16:49:55 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDC38FC0A; Mon, 18 May 2009 16:49:55 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1M6625-000OKf-Qn; Mon, 18 May 2009 17:49:45 +0100 Date: Mon, 18 May 2009 17:49:45 +0100 From: Tim Bishop To: Martin Wilke Message-ID: <20090518164945.GU86061@carrick.bishnet.net> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090518002528.GF2571@core.byshenk.net> <532cb0d675c7f20c60fcc2e8e4c1a558.squirrel@email.polands.org> <20090518155613.GT86061@carrick.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090518155613.GT86061@carrick.bishnet.net> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.13 (2006-08-11) X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, AWL -0.30, BAYES_00 -2.60, NO_RELAYS -0.00) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net X-Mailman-Approved-At: Mon, 18 May 2009 19:38:20 +0000 Cc: Doug Poland , ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Greg Byshenk Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:49:56 -0000 On Mon, May 18, 2009 at 04:56:13PM +0100, Tim Bishop wrote: > On Mon, May 18, 2009 at 08:38:18AM -0500, Doug Poland wrote: > > On Sun, May 17, 2009 19:25, Greg Byshenk wrote: > > > On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: > > >> > > >> We rolled a new tarball with the patch from Juergen Lock [1] > > >> with a posible fix for AMD64 users, tested on 3 machines > > >> which now works without problems. Many Thanks to him for > > >> his nice work! > > >> > > >> http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > > > Working for me with a fresh cvsup of 7.2-STABLE (17 May 09). > > Installing a 7.2-RELEASE amd64 guest as I write this. > > Works for me, but I've not been able to get a 64 bit guest to work. I > get the following error when booting the installer: > > CPU doesn't support long mode > > I think I've got all the right options set. Maybe my CPU doesn't support > the necessary VM stuff to let a 64 bit guest work? I'm getting good at answering my own questions :D Yes, it's my CPU. Found a different machine and confirmed it has the VMX extension, and all is fine. > I'm also still seeing the following on loading vboxdrv: > > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > kldload: unexpected relocation type 10 > vboxdrv: fAsync=0 offMin=0x41f offMax=0x53b > > Are others still seeing that on amd64? Not that I thought it'd make any difference, but I can confirm those still happen even with the VMX extension. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Mon May 18 18:51:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0973106564A for ; Mon, 18 May 2009 18:51:56 +0000 (UTC) (envelope-from matheusber@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 400B18FC0A for ; Mon, 18 May 2009 18:51:54 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1105643fge.12 for ; Mon, 18 May 2009 11:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:x-priority:importance; bh=KHofE3FHKVwCoF1d0jFHuaALBqPEPcsEtQqPBquPSNY=; b=c91Qy+1LZYW5cjM1zpgdv38d6rSzpc3QzJzB/5edEmj2kKHtRrLGROiD1z/nyK2dTH zk044soY647Cvm+/07O1fLtkX3/WNsUFNdcffgjLRSp6gN4/JKw0IoNMWZzzRa9w7v20 W6RjpoPX1S4sNAx2VfcakI9g7VOaslWV22jlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:x-priority:importance; b=yEaNUUFBnBuyF1WnNuFFX/UW6/Q8exed01VSMePeOeyiin2Zq0AdTm2QlDoH8Q31Y2 cZfjYo6gRvcmisMqvcXuZRJ6aGRTMpa6RDFWuEQi+/MVT0/7bHVVC5IEQ1w9spnt7eaS 5LfT+m87Iy7uTJ64g8mcRTip3s1BX/j0qbXhM= Received: by 10.86.96.12 with SMTP id t12mr7065244fgb.77.1242672714047; Mon, 18 May 2009 11:51:54 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.22.21]) by mx.google.com with ESMTPS id d4sm8277115fga.19.2009.05.18.11.51.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 11:51:52 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 2E8D4B8143; Mon, 18 May 2009 15:51:28 -0300 (BRT) Received: from 189.93.9.212 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Mon, 18 May 2009 15:51:28 -0300 (BRT) Message-ID: <3ecc0aab973682242b4137cb770f6277.squirrel@cygnus.homeunix.com> Date: Mon, 18 May 2009 15:51:28 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20090518155128_91725" X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 18 May 2009 19:47:34 +0000 Subject: huawei E226 + u3g + umass X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:51:57 -0000 ------=_20090518155128_91725 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit hail, I've read about this combo and HPS said to be ok to the three coexist. it is true for me if both u3g and huawei are there before umass. if not, the system died right away :( vmcore.1 is 400MB, and I can't send here :( on bz2 is 99MB :) was it supposed to be this way ? thanks, FreeBSD harry.tre-pb.gov.br 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri May 15 11:52:03 BRT 2009 root@harry.tre-pb.gov.br:/usr/obj/usr/src/sys/Core2Duo8 amd64 matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ------=_20090518155128_91725 Content-Type: application/octet-stream; name="info.1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="info.1" ------=_20090518155128_91725 Content-Type: application/octet-stream; name="core.txt.1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="core.txt.1" aGFycnkudHJlLXBiLmdvdi5iciBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS4x CgpNb24gTWF5IDE4IDE0OjM1OjEzIEJSVCAyMDA5CgpGcmVlQlNEIGhhcnJ5LnRyZS1wYi5nb3Yu YnIgOC4wLUNVUlJFTlQgRnJlZUJTRCA4LjAtQ1VSUkVOVCAjMTogRnJpIE1heSAxNSAxMTo1Mjow MyBCUlQgMjAwOSAgICAgcm9vdEBoYXJyeS50cmUtcGIuZ292LmJyOi91c3Ivb2JqL3Vzci9zcmMv c3lzL0NvcmUyRHVvOCAgYW1kNjQKCnBhbmljOiBrbWVtX21hbGxvYygtODQ1NDE0NCk6IGttZW1f bWFwIHRvbyBzbWFsbDogODkxNjE3MjggdG90YWwgYWxsb2NhdGVkCgpHTlUgZ2RiIDYuMS4xIFtG cmVlQlNEXQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KR0RC IGlzIGZyZWUgc29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlLCBhbmQgeW91IGFyZQp3ZWxjb21lIHRvIGNoYW5nZSBpdCBhbmQvb3IgZGlzdHJpYnV0ZSBj b3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zLgpUeXBlICJzaG93IGNvcHlpbmci IHRvIHNlZSB0aGUgY29uZGl0aW9ucy4KVGhlcmUgaXMgYWJzb2x1dGVseSBubyB3YXJyYW50eSBm b3IgR0RCLiAgVHlwZSAic2hvdyB3YXJyYW50eSIgZm9yIGRldGFpbHMuClRoaXMgR0RCIHdhcyBj b25maWd1cmVkIGFzICJhbWQ2NC1tYXJjZWwtZnJlZWJzZCIuLi4KClVucmVhZCBwb3J0aW9uIG9m IHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6CnBhbmljOiBrbWVtX21hbGxvYygtODQ1NDE0NCk6 IGttZW1fbWFwIHRvbyBzbWFsbDogODkxNjE3MjggdG90YWwgYWxsb2NhdGVkCmNwdWlkID0gMApV cHRpbWU6IDNkMmgzM20zMXMKUGh5c2ljYWwgbWVtb3J5OiAyMDA2IE1CCkR1bXBpbmcgNDA5IE1C OiAzOTQgKENUUkwtQyB0byBhYm9ydCkgIDM3OCAzNjIgMzQ2IDMzMCAoQ1RSTC1DIHRvIGFib3J0 KSAgMzE0IDI5OCAyODIgKENUUkwtQyB0byBhYm9ydCkgIDI2NiAoQ1RSTC1DIHRvIGFib3J0KSAg MjUwIChDVFJMLUMgdG8gYWJvcnQpICAoQ1RSTC1DIHRvIGFib3J0KSAgMjM0IChDVFJMLUMgdG8g YWJvcnQpICAyMTggKENUUkwtQyB0byBhYm9ydCkgIChDVFJMLUMgdG8gYWJvcnQpICAyMDIgKENU UkwtQyB0byBhYm9ydCkgIChDVFJMLUMgdG8gYWJvcnQpICAxODYgKENUUkwtQyB0byBhYm9ydCkg IDE3MCAoQ1RSTC1DIHRvIGFib3J0KSAgKENUUkwtQyB0byBhYm9ydCkgIDE1NCAoQ1RSTC1DIHRv IGFib3J0KSAgMTM4IDEyMiAxMDYgOTAgNzQgNTggNDIgMjYgMTAKClJlYWRpbmcgc3ltYm9scyBm cm9tIC9ib290L2tlcm5lbC9zbmRfaGRhLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qv a2VybmVsL3NuZF9oZGEua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZv ciAvYm9vdC9rZXJuZWwvc25kX2hkYS5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvc291bmQua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvc291bmQua28u c3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvc291 bmQua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3UzZy5rby4uLlJlYWRpbmcg c3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC91M2cua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxv YWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvdTNnLmtvClJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L2tlcm5lbC96ZnMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwv emZzLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2Vy bmVsL3pmcy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMu a28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uc3lt Ym9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvb3BlbnNv bGFyaXMua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnV4LmtvLi4uUmVh ZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnV4LmtvLnN5bWJvbHMuLi5kb25lLgpk b25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2xpbnV4LmtvClJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9ncmVlbl9zYXZlci5rby4uLlJlYWRpbmcgc3ltYm9scyBm cm9tIC9ib290L2tlcm5lbC9ncmVlbl9zYXZlci5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9h ZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9ncmVlbl9zYXZlci5rbwpSZWFkaW5nIHN5bWJv bHMgZnJvbSAvYm9vdC9rZXJuZWwvd2xhbl94YXV0aC5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L2tlcm5lbC93bGFuX3hhdXRoLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQg c3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3dsYW5feGF1dGgua28KUmVhZGluZyBzeW1ib2xzIGZy b20gL2Jvb3Qva2VybmVsL2k5MTUua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvaTkxNS5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290 L2tlcm5lbC9pOTE1LmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9kcm0ua28u Li5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZHJtLmtvLnN5bWJvbHMuLi5kb25l Lgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2RybS5rbwpSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvdW1hc3Mua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAv Ym9vdC9rZXJuZWwvdW1hc3Mua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xz IGZvciAvYm9vdC9rZXJuZWwvdW1hc3Mua28KIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjIyMwoy MjMJcGNwdS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5LgoJaW4gcGNwdS5oCihrZ2RiKSAj MCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MjIzCiMxICAweGZmZmZmZmZmODA1ODNkYzkgaW4gYm9v dCAoaG93dG89MjYwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQy MAojMiAgMHhmZmZmZmZmZjgwNTg0MWZjIGluIHBhbmljICgKICAgIGZtdD0weGZmZmZmZmZmODA5 N2MxNTggImttZW1fbWFsbG9jKCVsZCk6IGttZW1fbWFwIHRvbyBzbWFsbDogJWxkIHRvdGFsIGFs bG9jYXRlZCIpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NzYKIzMgIDB4 ZmZmZmZmZmY4MDdiYjY5ZSBpbiBrbWVtX21hbGxvYyAobWFwPTB4ZmZmZmZmMDAwMTAwMDBlMCwg CiAgICBzaXplPTE4NDQ2NzQ0MDczNzAxMDk3NDcyLCBmbGFncz0yKSBhdCAvdXNyL3NyYy9zeXMv dm0vdm1fa2Vybi5jOjMwNAojNCAgMHhmZmZmZmZmZjgwN2IzOGZhIGluIHVtYV9sYXJnZV9tYWxs b2MgKHNpemU9LTg0NTQxNDQsIHdhaXQ9MikKICAgIGF0IC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjMwMDEKIzUgIDB4ZmZmZmZmZmY4MDU3MmFhNyBpbiBtYWxsb2MgKHNpemU9MTg0NDY3NDQw NzM3MDEwOTc0NzIsIAogICAgbXRwPTB4ZmZmZmZmZmY4MGI0ZDkyMCwgZmxhZ3M9MikgYXQgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9tYWxsb2MuYzozOTEKIzYgIDB4ZmZmZmZmZmY4MDUyZDUyYSBp biBnX3JlYWRfZGF0YSAoY3A9MHhmZmZmZmYwMDA1MmU5YjAwLCAKICAgIG9mZnNldD03ODMxNzk0 NDg5NzAxMjM2NzM2LCBsZW5ndGg9NDI4NjUxMzE1MiwgZXJyb3I9MHhmZmZmZmZmZTQwMDNmYjBj KQogICAgYXQgZ2VvbS5oOjMwMQojNyAgMHhmZmZmZmZmZjgwNTMxNTQ3IGluIGdfbGFiZWxfdGFz dGUgKG1wPTB4ZmZmZmZmZmY4MGI0ZGZlMCwgCiAgICBwcD0weGZmZmZmZjAwMDFjYjI1MDAsIGZs YWdzPVZhcmlhYmxlICJmbGFncyIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3NyYy9zeXMv Z2VvbS9sYWJlbC9nX2xhYmVsLmM6MjI0CiM4ICAweGZmZmZmZmZmODA1MmVjYjUgaW4gZ19uZXdf cHJvdmlkZXJfZXZlbnQgKGFyZz0weGZmZmZmZjAwMDFjYjI1MDAsIGZsYWc9VmFyaWFibGUgImZs YWciIGlzIG5vdCBhdmFpbGFibGUuCikKICAgIGF0IC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fc3Vi ci5jOjU0NQojOSAgMHhmZmZmZmZmZjgwNTJjOTA4IGluIGdfcnVuX2V2ZW50cyAoKQogICAgYXQg L3Vzci9zcmMvc3lzL2dlb20vZ2VvbV9ldmVudC5jOjIxMQojMTAgMHhmZmZmZmZmZjgwNTJkZGE1 IGluIGdfZXZlbnRfcHJvY2JvZHkgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fa2Vy bi5jOjE0MQojMTEgMHhmZmZmZmZmZjgwNTVmODM4IGluIGZvcmtfZXhpdCAoCiAgICBjYWxsb3V0 PTB4ZmZmZmZmZmY4MDUyZGQ1MCA8Z19ldmVudF9wcm9jYm9keT4sIGFyZz0weDAsIAogICAgZnJh bWU9MHhmZmZmZmZmZTQwMDNmYzkwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo4 MzAKIzEyIDB4ZmZmZmZmZmY4MDgzOTQzZSBpbiBmb3JrX3RyYW1wb2xpbmUgKCkKICAgIGF0IC91 c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzo1NTIKIzEzIDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQojMTQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMxNSAweDAwMDAw MDAwMDAwMDAwMDEgaW4gPz8gKCkKIzE2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMTcg MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMxOCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8g KCkKIzE5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjAgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpCiMyMSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzIyIDB4MDAwMDAwMDAw MDAwMDAwMCBpbiA/PyAoKQojMjMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyNCAweDAw MDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQoj MjYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyNyAweDAwMDAwMDAwMDAwMDAwMDAgaW4g Pz8gKCkKIzI4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjkgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpCiMzMCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzMxIDB4MDAwMDAw MDAwMDAwMDAwMCBpbiA/PyAoKQojMzIgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzMyAw eDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAo KQojMzUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNiAweDAwMDAwMDAwMDAwMDAwMDAg aW4gPz8gKCkKIzM3IDB4MDAwMDAwMDAwMGViNjAwMCBpbiA/PyAoKQojMzggMHhmZmZmZmZmZjAw ZmZmZmZmIGluID8/ICgpCiMzOSAweGZmZmZmZmZmODBiZTQzNDAgaW4gdGRxX2NwdSAoKQojNDAg MHhmZmZmZmZmZjgwYmZlYmIwIGluIHNsZWVwcV9jaGFpbnMgKCkKIzQxIDB4ZmZmZmZmMDAwMTNm NTcyMCBpbiA/PyAoKQojNDIgMHhmZmZmZmZmZTQwMDNmOGIwIGluID8/ICgpCiM0MyAweGZmZmZm ZmZlNDAwM2Y4NjggaW4gPz8gKCkKIzQ0IDB4ZmZmZmZmMDA1NjNiODM5MCBpbiA/PyAoKQojNDUg MHhmZmZmZmZmZjgwNWE2ZDJkIGluIHNjaGVkX3N3aXRjaCAodGQ9MHhmZmZmZmZmZjgwNTJkZDUw LCBuZXd0ZD0weDAsIAogICAgZmxhZ3M9VmFyaWFibGUgImZsYWdzIiBpcyBub3QgYXZhaWxhYmxl LgopIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NTgKUHJldmlvdXMgZnJhbWUg aW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pCihrZ2RiKSAKCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpwcyAtYXhsCgogIFVJRCAgIFBJRCAgUFBJRCBDUFUgUFJJIE5JICAgVlNaICAgUlNTIE1X Q0hBTiBTVEFUICBUVCAgICAgICBUSU1FIENPTU1BTkQKICAgIDAgICAgIDAgICAgIDAgICAwIC02 OCAgMCAgICAgMCAgICAgMCAtICAgICAgRExzICAgPz8gIDg3NzU5MzQ0MTo0NC4wMCBba2VybmVs XQogICAgMCAgICAgMSAgICAgMCAgIDAgIDQ3ICAwICAyMTgwICAgICAwIHdhaXQgICBETHMgICA/ PyAgMTk3OTI3OjI4LjAwIFtpbml0XQogICAgMCAgICAgMiAgICAgMCAgIDAgIC04ICAwICAgICAw ICAgICAwIC0gICAgICBSTCAgICA/PyAgNDg5NTc0NDAzOjEyLjAwIFtnX2V2ZW50XQogICAgMCAg ICAgMyAgICAgMCAgIDAgIC04ICAwICAgICAwICAgICAwIC0gICAgICBETCAgICA/PyAgMzk5MDI2 OTY4OjMyLjAwIFtnX3VwXQogICAgMCAgICAgNCAgICAgMCAgIDAgIC04ICAwICAgICAwICAgICAw IC0gICAgICBETCAgICA/PyAgNDk3MzY1NTE3OjUyLjAwIFtnX2Rvd25dCiAgICAwICAgICA1ICAg ICAwICAgMCAtMTYgIDAgICAgIDAgICAgIDAgY2NiX3NjIERMICAgID8/ICAgIDA6MDAuMDAgW3hw dF90aHJkXQogICAgMCAgICAgNiAgICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIC0gICAgICBE TCAgICA/PyAgICAwOjAwLjAwIFtmdzBfcHJvYmVdCiAgICAwICAgICA3ICAgICAwICAgMCAtMTYg IDAgICAgIDAgICAgIDAgd2FpdGluIERMICAgID8/ICAzNzQ6MDAuMDAgW3NjdHBfaXRlcmEKICAg IDAgICAgIDggICAgIDAgICAwIC0xNiAgMCAgICAgMCAgICAgMCBwZnRtICAgREwgICAgPz8gIDQ2 ODQyMjQ3OjEyLjAwIFtwZnB1cmdlXQogICAgMCAgICAgOSAgICAgMCAgIDAgIDc2ICAwICAgICAw ICAgICAwIHBzbGVlcCBETCAgICA/PyAgMTA3MjcxMzQ6NDAuMDAgW3BhZ2VkYWVtb24KICAgIDAg ICAgMTAgICAgIDAgICAwIC0xNiAgMCAgICAgMCAgICAgMCBhdWRpdF8gREwgICAgPz8gICAgMDow MC4wMCBbYXVkaXRdCiAgICAwICAgIDExICAgICAwICAgMCAxNzEgIDAgICAgIDAgICAgIDAgLSAg ICAgIFJMICAgID8/ICAxMzU2NDE2NTY5MDE6MjguMDAgW2lkbGVdCiAgICAwICAgIDEyICAgICAw ICAgMCAtNjAgIDAgICAgIDAgICAgIDAgLSAgICAgIFdMICAgID8/ICA5OTgxNjYzNzM3OjEyLjAw IFtpbnRyXQogICAgMCAgICAxMyAgICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIC0gICAgICBE TCAgICA/PyAgNDM4MDMzMDkwOjA4LjAwIFt5YXJyb3ddCiAgICAwICAgIDE0ICAgICAwICAgMCAt NjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAgIDA6MDAuMDAgW3VzYnVzMF0KICAg IDAgICAgMTUgICAgIDAgICAwIC02OCAgMCAgICAgMCAgICAgMCB3bXNnICAgREwgICAgPz8gIDIw NjUyMjg4OjAwLjAwIFt1c2J1czBdCiAgICAwICAgIDE2ICAgICAwICAgMCAtNjQgIDAgICAgIDAg ICAgIDAgd21zZyAgIERMICAgID8/ICA0MTg3MDQzOToyMC4wMCBbdXNidXMwXQogICAgMCAgICAx NyAgICAgMCAgIDAgLTY0ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAgMTMyNjY6MTYu MDAgW3VzYnVzMF0KICAgIDAgICAgMTggICAgIDAgICAwIC02NCAgMCAgICAgMCAgICAgMCB3bXNn ICAgREwgICAgPz8gICAgMDowMC4wMCBbdXNidXMxXQogICAgMCAgICAxOSAgICAgMCAgIDAgLTY4 ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1c2J1czFdCiAgICAw ICAgIDIwICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAyNjg0 MDk3MzozNi4wMCBbdXNidXMxXQogICAgMCAgICAyMSAgICAgMCAgIDAgLTY0ICAwICAgICAwICAg ICAwIHdtc2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1c2J1czFdCiAgICAwICAgIDIyICAgICAw ICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAgIDA6MDAuMDAgW3VzYnVz Ml0KICAgIDAgICAgMjMgICAgIDAgICAwIC02OCAgMCAgICAgMCAgICAgMCB3bXNnICAgREwgICAg Pz8gIDEyNjk1NzQ6MjQuMDAgW3VzYnVzMl0KICAgIDAgICAgMjQgICAgIDAgICAwIC02NCAgMCAg ICAgMCAgICAgMCB3bXNnICAgREwgICAgPz8gIDI0NjUwNjI5OjUyLjAwIFt1c2J1czJdCiAgICAw ICAgIDI1ICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAxNjA0 OjQ4LjAwIFt1c2J1czJdCiAgICAwICAgIDI2ICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAg d21zZyAgIERMICAgID8/ICAgIDA6MDAuMDAgW3VzYnVzM10KICAgIDAgICAgMjcgICAgIDAgICAw IC02OCAgMCAgICAgMCAgICAgMCB3bXNnICAgREwgICAgPz8gICAgMDowMC4wMCBbdXNidXMzXQog ICAgMCAgICAyOCAgICAgMCAgIDAgLTY0ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAg NTI4NDgxMzk6MTIuMDAgW3VzYnVzM10KICAgIDAgICAgMjkgICAgIDAgICAwIC02NCAgMCAgICAg MCAgICAgMCB3bXNnICAgREwgICAgPz8gICAgMDowMC4wMCBbdXNidXMzXQogICAgMCAgICAzMCAg ICAgMCAgIDAgLTY0ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1 c2J1czRdCiAgICAwICAgIDMxICAgICAwICAgMCAtNjggIDAgICAgIDAgICAgIDAgd21zZyAgIERM ICAgID8/ICAgIDA6MDAuMDAgW3VzYnVzNF0KICAgIDAgICAgMzIgICAgIDAgICAwIC02NCAgMCAg ICAgMCAgICAgMCB3bXNnICAgREwgICAgPz8gIDIyNzgzMTU4OjQ4LjAwIFt1c2J1czRdCiAgICAw ICAgIDMzICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAgIDA6 MDAuMDAgW3VzYnVzNF0KICAgIDAgICAgMzQgICAgIDAgICAwIC02NCAgMCAgICAgMCAgICAgMCB3 bXNnICAgREwgICAgPz8gICAgMDowMC4wMCBbdXNidXM1XQogICAgMCAgICAzNSAgICAgMCAgIDAg LTY4ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1c2J1czVdCiAg ICAwICAgIDM2ICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAy MjI1MjU3Mzo1Mi4wMCBbdXNidXM1XQogICAgMCAgICAzNyAgICAgMCAgIDAgLTY0ICAwICAgICAw ICAgICAwIHdtc2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1c2J1czVdCiAgICAwICAgIDM4ICAg ICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICAgIDA6MDAuMDAgW3Vz YnVzNl0KICAgIDAgICAgMzkgICAgIDAgICAwIC02OCAgMCAgICAgMCAgICAgMCB3bXNnICAgREwg ICAgPz8gICAgMDowMC4wMCBbdXNidXM2XQogICAgMCAgICA0MCAgICAgMCAgIDAgLTY0ICAwICAg ICAwICAgICAwIHdtc2cgICBETCAgICA/PyAgMjI0MTA4Nzk6MDQuMDAgW3VzYnVzNl0KICAgIDAg ICAgNDEgICAgIDAgICAwIC02NCAgMCAgICAgMCAgICAgMCB3bXNnICAgREwgICAgPz8gICAgMDow MC4wMCBbdXNidXM2XQogICAgMCAgICA0MiAgICAgMCAgIDAgLTY0ICAwICAgICAwICAgICAwIHdt c2cgICBETCAgICA/PyAgICAwOjAwLjAwIFt1c2J1czddCiAgICAwICAgIDQzICAgICAwICAgMCAt NjggIDAgICAgIDAgICAgIDAgd21zZyAgIERMICAgID8/ICA0NDA5MjozMi4wMCBbdXNidXM3XQog ICAgMCAgICA0NCAgICAgMCAgIDAgLTY0ICAwICAgICAwICAgICAwIHdtc2cgICBETCAgICA/PyAg MzcyNTI5OTI6MjQuMDAgW3VzYnVzN10KICAgIDAgICAgNDUgICAgIDAgICAwIC02NCAgMCAgICAg MCAgICAgMCB3bXNnICAgREwgICAgPz8gIDQwMjE6MjguMDAgW3VzYnVzN10KICAgIDAgICAgNDYg ICAgIDAgICAwICA3NiAgMCAgICAgMCAgICAgMCBwc2xlZXAgREwgICAgPz8gIDEzNjozMi4wMCBb dm1kYWVtb25dCiAgICAwICAgIDQ3ICAgICAwICAgMCAgNzYgIDAgICAgIDAgICAgIDAgcGd6ZXJv IERMICAgID8/ICAxNjQ5MjY6NTYuMDAgW3BhZ2V6ZXJvXQogICAgMCAgICA0OCAgICAgMCAgIDAg IDQ0ICAwICAgICAwICAgICAwIHBzbGVlcCBETCAgICA/PyAgNDY3NjIzNDE6MTIuMDAgW2J1ZmRh ZW1vbl0KICAgIDAgICAgNDkgICAgIDAgICAwICA3NiAgMCAgICAgMCAgICAgMCB2bHJ1d3QgREwg ICAgPz8gIDU0MTE1MDYzOjQ0LjAwIFt2bmxydV0KICAgIDAgICAgNTAgICAgIDAgICAwICA0NCAg MCAgICAgMCAgICAgMCBzeW5jZXIgREwgICAgPz8gIDEyMjk1NTc4NDIwOjI0LjAwIFtzeW5jZXJd CiAgICAwICAgIDUxICAgICAwICAgMCAgNDQgIDAgICAgIDAgICAgIDAgc2RmbHVzIERMICAgID8/ ICA5ODk3NTUwNjo0OC4wMCBbc29mdGRlcGZsdQogICAgMCAgICA1MiAgICAgMCAgIDAgIDc2ICAw ICAgICAwICAgICAwIGZsb3djbCBETCAgICA/PyAgNTM5MDQ0ODoxNi4wMCBbZmxvd2NsZWFuZQog ICAgMCAgIDEyMyAgICAgMCAgIDAgIDQ3ICAwICAgICAwICAgICAwIHRxLT50cSBETCAgICA/PyAg MjY5OjIwLjAwIFtzeXN0ZW1fdGFzCiAgICAwICAgMTI0ICAgICAwICAgMCAgNDcgIDAgICAgIDAg ICAgIDAgdHEtPnRxIERMICAgID8/ICAgODQ6NDguMDAgW3N5c3RlbV90YXMKICAgIDAgICAxMjUg ICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB2YWN2ICAgREwgICAgPz8gIDQ2MDgzNDcwNjow MC4wMCBbdmFjbGVhbl0KICAgIDAgICAxMjggICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCAt ICAgICAgUkwgICAgPz8gIDYzNDczNDgyOjA4LjAwIFthcmNfcmVjbGFpCiAgICAwICAgMTI5ICAg ICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgZmZmZmZmZmY4MTExMWMwMCBETCAgICA/PyAgNTIw NDc2MjY6MzIuMDAgW2wyYXJjX2ZlZWQKICAgIDAgICAxNTkgICAgIDAgICAwICA0NyAgMCAgICAg MCAgICAgMCB0cS0+dHEgREwgICAgPz8gIDM0MjAyNDowMC4wMCBbc3BhX3ppb10KICAgIDAgICAx NjAgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0cS0+dHEgREwgICAgPz8gIDIyMzk5ODox Ni4wMCBbc3BhX3ppb10KICAgIDAgICAxNjEgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0 cS0+dHEgREwgICAgPz8gIDMyNDA6MDguMDAgW3NwYV96aW9dCiAgICAwICAgMTYyICAgICAwICAg MCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICAzMzAyODQ6NDguMDAgW3NwYV96 aW9dCiAgICAwICAgMTYzICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAg ID8/ICA0MzcyNDA6MDAuMDAgW3NwYV96aW9dCiAgICAwICAgMTY0ICAgICAwICAgMCAgNDcgIDAg ICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICAzMTQ1Mjk6MzYuMDAgW3NwYV96aW9dCiAgICAw ICAgMTY1ICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICAzODQx NjQ6MTYuMDAgW3NwYV96aW9dCiAgICAwICAgMTY2ICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAg IDAgdHEtPnRxIERMICAgID8/ICAzMjE4ODA6MTYuMDAgW3NwYV96aW9dCiAgICAwICAgMTY3ICAg ICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICA0NTA1NDA6NTYuMDAg W3NwYV96aW9dCiAgICAwICAgMTY4ICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRx IERMICAgID8/ICAzMDQzNDE6NDQuMDAgW3NwYV96aW9dCiAgICAwICAgMTY5ICAgICAwICAgMCAg NDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICAzMDQ5NjU6MjAuMDAgW3NwYV96aW9d CiAgICAwICAgMTcwICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ ICA3MDg2MDA6MDAuMDAgW3NwYV96aW9dCiAgICAwICAgMTcxICAgICAwICAgMCAgNDcgIDAgICAg IDAgICAgIDAgdHEtPnRxIERMICAgID8/ICA5ODE2NzE6NTIuMDAgW3NwYV96aW9dCiAgICAwICAg MTcyICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICA2NDY4MDg6 NTYuMDAgW3NwYV96aW9dCiAgICAwICAgMTczICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAg dHEtPnRxIERMICAgID8/ICA1MzkwNTQ6NDAuMDAgW3NwYV96aW9dCiAgICAwICAgMTc0ICAgICAw ICAgMCAgNDQgIDAgICAgIDAgICAgIDAgdHEtPnRxIERMICAgID8/ICAxNzQ5NDgyOjMyLjAwIFtz cGFfemlvXQogICAgMCAgIDE3NSAgICAgMCAgIDAgIDQ3ICAwICAgICAwICAgICAwIHRxLT50cSBE TCAgICA/PyAgNzE4MjU4OjQ4LjAwIFtzcGFfemlvXQogICAgMCAgIDE3NiAgICAgMCAgIDAgIDQ3 ICAwICAgICAwICAgICAwIHRxLT50cSBETCAgICA/PyAgNTUyNjcyOjMyLjAwIFtzcGFfemlvXQog ICAgMCAgIDE3NyAgICAgMCAgIDAgIDQ3ICAwICAgICAwICAgICAwIHRxLT50cSBETCAgICA/PyAg NDkyNzg2OjMyLjAwIFtzcGFfemlvXQogICAgMCAgIDE3OCAgICAgMCAgIDAgIDQ3ICAwICAgICAw ICAgICAwIHRxLT50cSBETCAgICA/PyAgNTEwOTM4NzoyMC4wMCBbc3BhX3ppb10KICAgIDAgICAx NzkgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0cS0+dHEgREwgICAgPz8gICA0MTowNC4w MCBbc3BhX3ppb10KICAgIDAgICAxODAgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0cS0+ dHEgREwgICAgPz8gICA0NTo1Mi4wMCBbc3BhX3ppb10KICAgIDAgICAxODEgICAgIDAgICAwICA0 NyAgMCAgICAgMCAgICAgMCB0cS0+dHEgREwgICAgPz8gICAzODo0MC4wMCBbc3BhX3ppb10KICAg IDAgICAxODIgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0cS0+dHEgREwgICAgPz8gICA0 MDowMC4wMCBbc3BhX3ppb10KICAgIDAgICAxODMgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAg MCB0cS0+dHEgREwgICAgPz8gICA0Njo0MC4wMCBbc3BhX3ppb10KICAgIDAgICAxODQgICAgIDAg ICAwICA0NyAgMCAgICAgMCAgICAgMCB0cS0+dHEgREwgICAgPz8gIDEzMDcwMTowNC4wMCBbc3Bh X3ppb10KICAgIDAgICAxODUgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB2Z2VvbTogREwg ICAgPz8gIDMzNzI0OTowNC4wMCBbdmRldjp3b3JrZQogICAgMCAgIDE4NiAgICAgMCAgIDAgIDQ3 ICAwICAgICAwICAgICAwIHZnZW9tOiBETCAgICA/PyAgMzI0MTA0OjQwLjAwIFt2ZGV2Ondvcmtl CiAgICAwICAgMTg3ICAgICAwICAgMCAgNDcgIDAgICAgIDAgICAgIDAgdmdlb206IERMICAgID8/ ICAzMzU4Mjg6MzIuMDAgW3ZkZXY6d29ya2UKICAgIDAgICAxODggICAgIDAgICAwICA0NyAgMCAg ICAgMCAgICAgMCB0eC0+dHggREwgICAgPz8gIDIwMjMwOTk6MzYuMDAgW3R4Z190aHJlYWQKICAg IDAgICAxODkgICAgIDAgICAwICA0NyAgMCAgICAgMCAgICAgMCB0eC0+dHggREwgICAgPz8gIDE0 MjM5MTIzOjIwLjAwIFt0eGdfdGhyZWFkCiAgICAwICAgMTkxICAgICAwICAgMCAgNDcgIDAgICAg IDAgICAgIDAgdHEtPnRxIERMICAgID8/ICA4MzM2MzowNC4wMCBbemlsX2NsZWFuXQogICAgMCAg IDE5MiAgICAgMCAgIDAgIDQ3ICAwICAgICAwICAgICAwIHRxLT50cSBETCAgICA/PyAgIDg0OjA4 LjAwIFt6aWxfY2xlYW5dCiAgICAwICAgMjU4ICAgICAxICAgMCAgNzYgIDAgIDI2NjggICAgIDAg cGF1c2UgIERzICAgID8/ICA2ODA2OjAwLjAwIFthZGprZXJudHpdCiAgICAwICAxMDg5ICAgICAx ICAgMCAgNDQgIDAgIDY5NDQgICAgIDAgc2VsZWN0IERzICAgID8/ICA1MjA0ODAyOjA4LjAwIFtt b3VzZWRdCiAgICAwICAxMTA2ICAgICAxICAgMCAgNDQgIDAgIDIxNzYgICAgIDAgc2VsZWN0IERz ICAgID8/ICA3MDI4Njk6MDQuMDAgW2RldmRdCiAgICAwICAxMjc5ICAgICAxICAgMCAgIDEgIDAg IDU3OTYgICAgIDAgc2VsZWN0IERzICAgID8/ICAxNjQwNTkwNDoyNC4wMCBbc3lzbG9nZF0KICAg IDAgIDEzMDAgICAgIDEgICAwICA0NCAgMCAgNjg1NiAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDkz NTIyOTk6MDQuMDAgW3JwY2JpbmRdCiAgICAwICAxMzcwICAgICAxICAgMCAgNzYgIDAgIDU3OTIg ICAgIDAgc2VsZWN0IERzICAgID8/ICA0NTMwMjoyNC4wMCBbbW91bnRkXQogICAgMCAgMTM3OCAg ICAgMSAgIDAgIDc2ICAwICA0NzA4ICAgICAwIHNlbGVjdCBEcyAgICA/PyAgNzc3MDkzOjEyLjAw IFtuZnNkXQogICAgMCAgMTM3OSAgMTM3OCAgIDAgIDc2ICAwICA0NzA4ICAgICAwIHJwY3N2YyBE ICAgICA/PyAgNTI3ODM1MDE6NTIuMDAgW25mc2RdCiAgICAwICAxNjAwICAgICAxICAgMCAgNDQg IDAgMjQ4OTYgICAgIDAgc2VsZWN0IERzICAgID8/ICA0ODY3Njo0MC4wMCBbc3NoZF0KICAgIDAg IDE2MDcgICAgIDEgICAwICA0NCAgMCAxMDgxMiAgICAgMCAtICAgICAgUnMgICAgPz8gIDE0NjYy NTEzODowMC4wMCBbc2VuZG1haWxdCiAgIDI1ICAxNjExICAgICAxICAgMCAgNDQgIDAgMTA4MTIg ICAgIDAgcGF1c2UgIERzICAgID8/ICAxOTkyMTYxOjUyLjAwIFtzZW5kbWFpbF0KICAgIDAgIDE2 MTcgICAgIDEgICAwICA2OSAgMCAgNjg1MiAgICAgMCBuYW5zbHAgRHMgICAgPz8gIDIyMDgyMjUy OjAwLjAwIFtjcm9uXQogICAgMCAgMTY3OCAgICAgMSAgIDAgIDQ3ICAwIDIwNTc2ICAgICAwIHdh aXQgICBEcyAgICA/PyAgNDUyMDI5OjUyLjAwIFtsb2dpbl0KICAgIDAgIDE2NzkgICAgIDEgICAw ICA3NiAgMCAgNTc5MiAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDg5NDMxOjQ0LjAwIFtnZXR0eV0K ICAgIDAgIDE2ODAgICAgIDEgICAwICA3NiAgMCAgNTc5MiAgICAgMCB0dHlpbiAgRHMrICAgPz8g IDQ3NzQ0OjQwLjAwIFtnZXR0eV0KICAgIDAgIDE2ODEgICAgIDEgICAwICA3NiAgMCAgNTc5MiAg ICAgMCB0dHlpbiAgRHMrICAgPz8gIDQzODgxOjM2LjAwIFtnZXR0eV0KICAgIDAgIDE2ODIgICAg IDEgICAwICA3NiAgMCAgNTc5MiAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQ1MTYyOjQwLjAwIFtn ZXR0eV0KICAgIDAgIDE2ODMgICAgIDEgICAwICA3NiAgMCAgNTc5MiAgICAgMCB0dHlpbiAgRHMr ICAgPz8gIDQzNjQzOjIwLjAwIFtnZXR0eV0KICAgIDAgIDE2ODQgICAgIDEgICAwICA3NiAgMCAg NTc5MiAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQ0MzcwOjQwLjAwIFtnZXR0eV0KICAgIDAgIDE2 ODUgICAgIDEgICAwICA3NiAgMCAgNTc5MiAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQ0MDA2OjQw LjAwIFtnZXR0eV0KIDIxMTIgIDE3MjcgIDE2NzggICAwICA0NSAgMCAgNzE2NCAgICAgMCB3YWl0 ICAgRCAgICAgPz8gIDEyOTc4MDoxNi4wMCBbc2hdCiAyMTEyICAxNzI5ICAxNzI3ICAgMCAgNDQg IDAgIDkxMTYgICAgIDAgd2FpdCAgIEQgICAgID8/ICAyNTA3Mzg6MDguMDAgW2Jhc2hdCiAyMTEy ICAxNzMwICAxNzI5ICAgMCAgNzYgIDAgIDcxNjQgICAgIDAgd2FpdCAgIEQrICAgID8/ICAxMTgy Mzg6NDguMDAgW3NoXQogMjExMiAgMTc0OCAgMTczMCAgIDAgIDUyICAwIDExMjA4ICAgICAwIHdh aXQgICBEKyAgICA/PyAgNzUyMzM6MjguMDAgW3hpbml0XQogICAgMCAgMTc0OSAgMTc0OCAgIDAg IDQ0ICAwIDMyMDA2MCAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDM2MzE2NTczNDM4OjQwLjAwIFtY b3JnXQogMjExMiAgMTc1NCAgMTc0OCAgIDAgIDUyICAwICA3MTY0ICAgICAwIHdhaXQgICBEICAg ICA/PyAgNDg3Njc6MjAuMDAgW3NoXQogMjExMiAgMTc1NSAgMTc1NCAgIDAgIDUxICAwIDI5ODA0 ICAgICAwIHdhaXQgICBEICAgICA/PyAgMTc1MTE2OjQ4LjAwIFt3bWFrZXJdCiAyMTEyICAxNzU2 ICAxNzU1ICAgMCAgNDQgIDAgMzUxMzYgICAgIDAgc2VsZWN0IEQgICAgID8/ICAyMjM0MzA3MDM1 OjIwLjAwIFt3bWFrZXJdCiAyMTEyICAxNzU5ICAxNzU2ICAgMCAgNDQgIDAgNzE0MTIgICAgIDAg c2VsZWN0IERzICAgID8/ICAxMTQ5NTg3NjIyNjk6MjAuMDAgW2drcmVsbG1dCiAgICAwICAxODU1 ICAgICAxICAgMCAgNDQgIDAgIDgyODQgICAgIDAgc2VsZWN0IERzICAgID8/ICAzNDEzMTAzOjA0 LjAwIFtzY3JlZW5dCiAyMTEyICAxODU3ICAxODU1ICAgMCAgNDUgIDAgIDcxNjQgICAgIDAgd2Fp dCAgIERzICAgID8/ICAyOTQ1NzM6MjAuMDAgW3NoXQogMjExMiAgMTg1OCAgMTg1NyAgIDAgIDcz ICAwICA5MTE2ICAgICAwIHR0eWluICBEKyAgICA/PyAgMzE2MzYyOjE2LjAwIFtiYXNoXQogMjEx MiAgMTg3MCAgMTg1NSAgIDAgIDQ0ICAwICA3MTY0ICAgICAwIHdhaXQgICBEcyAgICA/PyAgMzAw ODg4OjQ4LjAwIFtzaF0KIDIxMTIgIDE4NzEgIDE4NzAgICAwICA0NCAgMCAgOTExNiAgICAgMCB3 YWl0ICAgRCAgICAgPz8gIDM5Mzg0NjozMi4wMCBbYmFzaF0KIDIxMTIgIDE5NDkgIDE4NzEgICAw ICA0NCAgMCAgOTExNiAgICAgMCB3YWl0ICAgRCsgICAgPz8gIDMyODQxOjQ0LjAwIFtiYXNoXQog MjExMiAgMTk1MCAgMTk0OSAgIDAgIDQ0ICAwIDMyOTY4MCAgICAgMCBuYW5zbHAgRCsgICAgPz8g IDEzMjI0OToyOC4wMCBbZmFoNl0KIDIxMTIgIDE5NTEgIDE5NDkgICAwICA0NCAgMCAzMjk2ODAg ICAgIDAgd2FpdCAgIEQrICAgID8/ICAxMjY3NTU4OjU2LjAwIFtmYWg2XQogMjExMiAgMTk1MiAg MTk0OSAgIDAgIDQ0ICAwIDMyOTY4MCAgICAgMCBuYW5zbHAgRCsgICAgPz8gIDUyOTkzOjEyLjAw IFtmYWg2XQogMjExMiAgMTk1NSAgMTg1NSAgIDAgIDQ0ICAwICA3MTY0ICAgICAwIHdhaXQgICBE cyAgICA/PyAgMzAxMjQ4OjQ4LjAwIFtzaF0KIDIxMTIgIDE5NTYgIDE5NTUgICAwICA0NCAgMCAg OTExNiAgICAgMCB3YWl0ICAgRCAgICAgPz8gIDIxODc0MjoxNi4wMCBbYmFzaF0KIDIxMTIgIDE5 NTggIDE5NTYgICAwICA0NCAgMCAgOTExNiAgICAgMCB3YWl0ICAgRCsgICAgPz8gIDMzNzcwOjQw LjAwIFtiYXNoXQogMjExMiAgMTk1OSAgMTk1OCAgIDAgIDQ0ICAwIDMyOTY4MCAgICAgMCBuYW5z bHAgRCsgICAgPz8gIDEwMzE0MDozMi4wMCBbZmFoNl0KIDIxMTIgIDE5NjAgIDE5NTggICAwICA0 NCAgMCAzMjk2ODAgICAgIDAgd2FpdCAgIEQrICAgID8/ICAxMjYzNDcxOjEyLjAwIFtmYWg2XQog MjExMiAgMTk2MSAgMTk1OCAgIDAgIDQ0ICAwIDMyOTY4MCAgICAgMCBuYW5zbHAgRCsgICAgPz8g IDUzNDIxOjIwLjAwIFtmYWg2XQogMjExMiAxMTY5NCAgMTk1OCAgIDAgIDQ0ICAwIDMyOTY4MCAg ICAgMCAtICAgICAgUisgICAgPz8gIDE0Nzg4NjU0Nzo0NC4wMCBbZmFoNl0KIDIxMTIgMTE2OTUg IDE5NjAgICAwICA0NCAyMCAyMDE3NiAgICAgMCBuYW5zbHAgRE4rICAgPz8gIDEwODI5OTAxOjM2 LjAwIFtGYWhDb3JlXzc4CiAyMTEyIDExNjk2IDExNjk1ICAgMCAgNDQgMjAgMjAxNzYgICAgIDAg c2VsZWN0IEROKyAgID8/ICAxODU2MzMxNDowMC4wMCBbRmFoQ29yZV83OAogMjExMiAxMTY5NyAx MTY5NiAgIDAgMTM2IDIwIDIwMTc2ICAgICAwIC0gICAgICBSTisgICA/PyAgMjA1MTQ3NzQ2NDU0 OjUxLjU5IFtGYWhDb3JlXzc4CiAyMTEyIDExNjk4IDExNjk2ICAgMCAgNDQgMjAgMjAxNzYgICAg IDAgbmFuc2xwIEROKyAgID8/ICAxMTM4NjA6NDAuMDAgW0ZhaENvcmVfNzgKIDIxMTIgMTE3MTIg IDE5NDkgICAwICA0NCAgMCAzMjk2ODAgICAgIDAgbmFuc2xwIEQrICAgID8/ICAxNDY4MDY2NjU6 MjAuMDAgW2ZhaDZdCiAyMTEyIDExNzEzICAxOTUxICAgMCAgNDQgMjAgMjAwNzYgICAgIDAgbmFu c2xwIEROKyAgID8/ICAxMDY4NDExODowMC4wMCBbRmFoQ29yZV83OAogMjExMiAxMTcxNCAxMTcx MyAgIDAgIDQ0IDIwIDIwMDc2ICAgICAwIC0gICAgICBSTisgICA/PyAgMTgxNzA1NTk6MjguMDAg W0ZhaENvcmVfNzgKIDIxMTIgMTE3MTUgMTE3MTQgICAwIDEzOCAyMCAyMDA3NiAgICAgMCAtICAg ICAgUk4rICAgPz8gIDE4MTYxMTU4MzUxNToyMy41OSBbRmFoQ29yZV83OAogMjExMiAxMTcxNiAx MTcxNCAgIDAgIDQ0IDIwIDIwMDc2ICAgICAwIG5hbnNscCBETisgICA/PyAgMTEwMjUyOjQ4LjAw IFtGYWhDb3JlXzc4CiAyMTEyIDE0NjI3ICAxNzU2ICAgMCAgNDQgIDAgMzMzMzIgICAgIDAgc2Vs ZWN0IERzICAgID8/ICA5ODU0MjY6MDguMDAgW3h0ZXJtXQogMjExMiAxNDYyOSAxNDYyNyAgIDAg IDQ2ICAwICA3MTY0ICAgICAwIHdhaXQgICBEcyAgICA/PyAgMTMxODIxOjI4LjAwIFtzaF0KIDIx MTIgMTQ2MzEgMTQ2MjkgICAwICA0NCAgMCAgOTExNiAgICAgMCB3YWl0ICAgRCAgICAgPz8gIDI2 MDA1ODo0OC4wMCBbYmFzaF0KICAgIDAgMTQ2NDkgICAgIDAgICAwIC02NCAgMCAgICAgMCAgICAg MCB3bXNnICAgREwgICAgPz8gICA4MzoyOC4wMCBbdWNvbV0KICAgIDAgMTQ2NTMgMTQ2MzEgICAw ICA0NCAgMCAyMDU2OCAgICAgMCB3YWl0ICAgRCAgICAgPz8gIDE4MjIwMToyOC4wMCBbc3VdCiAg ICAwIDE0NjU0IDE0NjUzICAgMCAgNDcgIDAgMTAyMDQgICAgIDAgcGF1c2UgIEQgICAgID8/ICAz MTE1NzU6MDQuMDAgW2NzaF0KICAgIDAgMTQ2NTggMTQ2NTQgICAwICA0NCAgMCAgOTExNiAgICAg MCB0dHlpbiAgRCsgICAgPz8gIDIxNjMxOTowNC4wMCBbYmFzaF0KCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2 bXN0YXQgLXMKCiAgICAgICAgMCBjcHUgY29udGV4dCBzd2l0Y2hlcwogICAgICAgIDAgZGV2aWNl IGludGVycnVwdHMKICAgICAgICAwIHNvZnR3YXJlIGludGVycnVwdHMKICAgICAgICAwIHRyYXBz CiAgICAgICAgMCBzeXN0ZW0gY2FsbHMKICAgICAgICAwIGtlcm5lbCB0aHJlYWRzIGNyZWF0ZWQK ICAgICAgICAwICBmb3JrKCkgY2FsbHMKICAgICAgICAwIHZmb3JrKCkgY2FsbHMKICAgICAgICAw IHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZWlucwogICAgICAgIDAgc3dh cCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlb3V0cwogICAg ICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBvdXQKICAgICAgICAwIHZub2RlIHBhZ2VyIHBh Z2VpbnMKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAgICAgMCB2bm9k ZSBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAg ICAgICAgMCBwYWdlIGRhZW1vbiB3YWtldXBzCiAgICAgICAgMCBwYWdlcyBleGFtaW5lZCBieSB0 aGUgcGFnZSBkYWVtb24KICAgICAxMTkzIHBhZ2VzIHJlYWN0aXZhdGVkCiAgICAgICAgMCBjb3B5 LW9uLXdyaXRlIGZhdWx0cwogICAgICAgIDAgY29weS1vbi13cml0ZSBvcHRpbWl6ZWQgZmF1bHRz CiAgICAgICAgMCB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAgMCB6ZXJvIGZpbGwgcGFn ZXMgcHJlemVyb2VkCiAgICAgICAgMCBpbnRyYW5zaXQgYmxvY2tpbmcgcGFnZSBmYXVsdHMKICAg ICAgICAwIHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkg a2VybmVsIHRocmVhZCBjcmVhdGlvbgogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkgIGZvcmso KQogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAgcGFnZXMgYWZm ZWN0ZWQgYnkgcmZvcmsoKQogICAgIDE1MjQgcGFnZXMgY2FjaGVkCiAgICAgICAgMCBwYWdlcyBm cmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgIDkxOTY2NSBwYWdlcyBmcmVl ZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICAgMTY3NDMgcGFnZXMgYWN0aXZlCiAgICA3MDY2OCBw YWdlcyBpbmFjdGl2ZQogICAgICAgODIgcGFnZXMgaW4gVk0gY2FjaGUKICAgIDk4OTI0IHBhZ2Vz IHdpcmVkIGRvd24KICAgMzEyODcwIHBhZ2VzIGZyZWUKICAgICA0MDk2IGJ5dGVzIHBlciBwYWdl CiAgNjg4ODY1MCB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNhY2hlIGhpdHMgKDc3JSBw b3MgKyAyJSBuZWcpIHN5c3RlbSAyJSBwZXItZGlyZWN0b3J5CiAgICAgICAgICBkZWxldGlvbnMg MCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZtc3RhdCAtbQoK ICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQpDQU0g ZGV2IHF1ZXVlICAgMjUxICAgICAwSyAgICAgICAtICAgICAgMjU2ICAxNgogICAgICAgaXNhZGV2 ICAgIC02ICAgICAwSyAgICAgICAtICAgICAgICAwICAKICAgICAgICAgIHNicCAgIC05NiAgIC0x MksgICAgICAgLSAgICAgICAgMCAgCiAgICAgICBhY3BpY2EgMjYzMzE2OCAtMjc4NksgICAgICAg LSAgMjY3NzI2NCAgMzIsNjQsMTI4LDUxMiwyMDQ4LDE2Mzg0LDEzMTA3Miw1MjQyODgKICAgICBh Y3BpdGFzayAgIDE4OSAgICAgMEsgICAgICAgLSAgICAgIDE5MiAgMTYsMzIKICAgICAgICAgY2Rl diAgIC0xMiAgICAtMksgICAgICAgLSAgICAgICAgMCAgCiAgICAgICAgICBhZ3AgICAgLTYgICAg IDBLICAgICAgIC0gICAgICAgIDAgIAogICAgQ0FNIHF1ZXVlICAyNjIzICAgIC0xSyAgICAgICAt ICAgICAyNzUyICAxNiwzMiw2NCwyNTYsNTEyLDEwMjQKICAgICAgICBzaWdpbyAgICAtMyAgICAg MEsgICAgICAgLSAgICAgICAgMCAgCmZpbGVkZXNjX3RvX2xlYWRlciAgMTI0NCAgICAtMUsgICAg ICAgLSAgICAgMTI4MCAgMzIsMTI4CiAgICAgZmlsZWRlc2MgNzUzMzY2NCAtNzQ4OUsgICAgICAg LSAgNzU0ODM4NCAgMTYsMzIsMTI4LDI1NiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2Mzg0LDMyNzY4 LDY1NTM2CiAgICAgICAgIGtlbnYgICAgNDAgICAgLTlLICAgICAgIC0gICAgICAxMTIgIDMyCiAg ICAgICBrcXVldWUgMTg0OTczICAtMTgwSyAgICAgICAtICAgMTg1NjAwICAxNiwzMiwyNTYsNTEy LDEwMjQsODE5MgogICAgcHJvYy1hcmdzIDQ3MjExNTIgLTQ2NzhLICAgICAgIC0gIDQ3ODg5OTIg IDE2LDY0LDEyOCwyNTYsNTEyLDIwNDgsNDA5Niw4MTkyLDE2Mzg0LDMyNzY4LDY1NTM2LDEzMTA3 MiwyNjIxNDQsNTI0Mjg4CiAgICAgIENBTSBTSU0gICA1MDcgICAgIDBLICAgICAgIC0gICAgICA1 MTIgIDE2CiAgICAgIGl0aHJlYWQgICAtODIgICAtMTFLICAgICAgIC0gICAgICAgIDAgIAogICAg ICBhY3Bpc2VtICAgLTEzICAgICAwSyAgICAgICAtICAgICAgICAwICAKICAgICAgIEtUUkFDRSAg LTEwMCAgIC0xMUsgICAgICAgLSAgICAgICAgMCAgCiAgICAgICBsaW5rZXIgIDI0NjMgIC04OTNL ICAgICAgIC0gICAgIDI4MTYgIDE2LDMyLDY0LDI1NiwxMDI0CiAgICAgICAgbG9ja2YgMTQ1MjYy OSAtMTQzMUsgICAgICAgLSAgMTQ2NTcyOCAgNjQsMTI4LDI1NiwyMDQ4LDgxOTIsNjU1MzYsMTMx MDcyCiAgICAgICBpcDZuZHAgICAyNDUgICAgIDBLICAgICAgIC0gICAgICAyNTYgIDMyCiAgICAg ICAgIHRlbXAgMjAyODgxNzM3IC0xOTgzMTNLICAgICAgIC0gMjAzMDU2NDAwICAzMiw2NCwyNTYs NTEyLDEwMjQsMjA0OCw0MDk2LDgxOTIsMTYzODQsMTMxMDcyLDI2MjE0NCwxMDQ4NTc2CiAgICAg ICBkZXZidWYgODY1NjM4IC03NTY4SyAgICAgICAtICAgODcxNDI0ICAxNiw2NCwxMjgsMjU2LDEw MjQsNDA5NgogICAgICAgbW9kdWxlICAtNDI1ICAgLTUySyAgICAgICAtICAgICAgICAwICAKICAg ICAgc2NzaV9kYSAgICA5MCAgICAgMEsgICAgICAgLSAgICAgICA5NiAgMTYsNjQKICAgICBtdHhf cG9vbCAgICAtMSAgICAtN0sgICAgICAgLSAgICAgICAgMCAgCiAgICAgICBrYmRtdXggICAgLTYg ICAgLTdLICAgICAgIC0gICAgICAgIDAgIAogICAgICAgICAgb3NkICAgMTIwICAgICAwSyAgICAg ICAtICAgICAgMTI4ICAxNiwzMgogICAgICBzdWJwcm9jIDU5MzQ4NDg0IC01ODYzNksgICAgICAg LSA1OTM2MzMyOCAgMTYsMzIsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYsODE5MiwxNjM4NCwz Mjc2OCw2NTUzNgogICAgICAgICBwcm9jICAgIC0yICAgLTE1SyAgICAgICAtICAgICAgICAwICAK ICAgICAgc2Vzc2lvbiAzMDE1OTggIC0yOTlLICAgICAgIC0gICAzMDQwMDAgIDE2LDMyLDY0LDI1 Niw1MTIsNDA5NiwxNjM4NAogICAgICAgICBwZ3JwIDMxNjA2MiAgLTMxNUsgICAgICAgLSAgIDMx ODU5MiAgMTYsMTI4LDI1Niw1MTIsMTAyNCw0MDk2LDE2Mzg0CiAgICAgICAgIGNyZWQgMTY2NjA2 NDYgLTE2MzQxSyAgICAgICAtIDE2NzI2MDE2ICA2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsODE5 MiwxNjM4NCwzMjc2OCw2NTUzNiwxMzEwNzIsMjYyMTQ0LDUyNDI4OAogICAgICB1aWRpbmZvIDg1 MTA5ICAgLTg1SyAgICAgICAtICAgIDg2NDY0ICAxNiwzMiw2NCwyNTYsNTEyLDEwMjQsMjA0OCw4 MTkyCiAgICAgICBwbGltaXQgNzI2ODUwNCAtNzEyOUsgICAgICAgLSAgNzI5NzAyNCAgMTYsMzIs NjQsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NiwxNjM4NCwzMjc2OCwxMzEwNzIsMjYyMTQ0CiAgICBz eXNjdGx0bXAgNDU1MDAgICAtNDRLICAgICAgIC0gICAgNDY5NDQgIDE2LDMyLDY0LDEyOCwyNTYs MjA0OCw0MDk2LDgxOTIKICAgIHN5c2N0bG9pZCAgMjE0NCAgLTIwNksgICAgICAgLSAgICAgNjQ2 NCAgMzIsNjQsMTI4LDI1Niw1MTIsMjA0OAogICAgICAgc3lzY3RsIDg1NTQ2MTgzIC04NjIzN0sg ICAgICAgLSA4ODMwODQ2NCAgMTYsMzIsNjQsNTEyLDEwMjQsMjA0OCw0MDk2LDgxOTIsMzI3Njgs NjU1MzYsMjA5NzE1Miw0MTk0MzA0LDE2Nzc3MjE2CiAgICAgIGNhbGxvdXQgICAgLTEgIC01MTFL ICAgICAgIC0gICAgICAgIDAgIAogICAgICAgICB1bXR4ICAtMjQ4ICAgLTMwSyAgICAgICAtICAg ICAgICAwICAKICAgICAgIHZpbWFnZSAgIC0xMyAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAg ICAgcDEwMDMuMWIgICAgLTEgICAgIDBLICAgICAgIC0gICAgICAgIDAgIAogICAgICAgICBTV0FQ ICAgIC0yICAtMTM5SyAgICAgICAtICAgICAgICAwICAKICAgICAgIGJ1cy1zYyAxODIxOTQ5MyAt MTgxOTNLICAgICAgIC0gMTgyMjI4MzIgIDE2LDMyLDY0LDI1Niw1MTIsMjA0OCwxNjM4NCwzMjc2 OAogICAgICAgICAgYnVzIDEyMzg1NDMgLTEzMDVLICAgICAgIC0gIDEyNDUxNTIgIDY0LDEyOCwy NTYsNTEyLDIwNDgsNDA5Niw4MTkyLDY1NTM2CiAgICAgICAgY2xpc3QgICAgLTQgICAgIDBLICAg ICAgIC0gICAgICAgIDAgIAogICAgICBkZXZzdGF0ICAgLTEyICAgLTIzSyAgICAgICAtICAgICAg ICAwICAKIGV2ZW50aGFuZGxlciAgIC04NiAgICAtNUsgICAgICAgLSAgICAgICAgMCAgCiAgICAg ICAgIGtvYmogODA2NDIyIC0xOTU5SyAgICAgICAtICAgODA2OTEyICAxNiw2NCwxMDI0LDIwNDgK ICAgQ0FNIHBlcmlwaCAgMzg5NSAgICAtM0sgICAgICAgLSAgICAgMzkyMCAgMTYsMzIsMjU2CiAg ICAgIENBTSBYUFQgNDcyNzYgICAtNjFLICAgICAgIC0gICAgNDc0MjQgIDE2LDMyLDY0LDEyOCwy NTYsMTAyNAogICAgICAgICBybWFuIDY0MjIzICAgLTgySyAgICAgICAtICAgIDY0ODk2ICAxNiwz MiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICBzYnVmIDQ4MDA3NiAgLTQ2OEsg ICAgICAgLSAgIDQ4MDYwOCAgMTYsMzIsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogIGF0YV9nZW5l cmljICAgIC01ICAgIC00SyAgICAgICAtICAgICAgICAwICAKICAgICAgICBzdGFjayAgIDUxMCAg ICAgMEsgICAgICAgLSAgICAgIDUxMiAgMzIKICAgIHRhc2txdWV1ZSAgIC0xNyAgICAgMEsgICAg ICAgLSAgICAgICAgMCAgCiAgICAgICBVbml0bm8gIDQ1NzMgICAgLTRLICAgICAgIC0gICAgIDQ3 MzYgIDY0LDI1NiwxMDI0CiAgICAgICAgICBpb3YgNjM0MzE3NTE1IC02MjUwMDdLICAgICAgIC0g NjQwMDA4NTc2ICAxNiw2NCwyNTYsNTEyLDIwNDgsODE5MiwxNjM4NCwzMjc2OCw2NTUzNiwxMzEw NzIsMjYyMTQ0LDUyNDI4OCwxMDQ4NTc2LDQxOTQzMDQsODM4ODYwOCwzMzU1NDQzMgogICAgICAg c2VsZWN0ICAgLTU1ICAgIC01SyAgICAgICAtICAgICAgICAwICAKICAgICBpb2N0bG9wcyAyMTk1 MzAwMzAgLTIyNTY2M0sgICAgICAgLSAyMzEwODA1NDQgIDE2LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OCw0MDk2LDE2Mzg0LDMyNzY4LDY1NTM2LDEzMTA3MiwxMDQ4NTc2LDIwOTcxNTIsNDE5NDMwNCw4 Mzg4NjA4LDE2Nzc3MjE2LDY3MTA4ODY0CiAgICAgICAgICBtc2cgICAgLTQgICAtMjlLICAgICAg IC0gICAgICAgIDAgIAogICAgICAgICAgc2VtICAgIC00ICAgLTEwSyAgICAgICAtICAgICAgICAw ICAKICAgICAgICAgIHNobSAyNjYwNyAgIC01MUsgICAgICAgLSAgICAyNjYyNCAgMTYsNjQsMTI4 CiAgICAgICAgICB0dHkgIDYxMTEgICAtMzJLICAgICAgIC0gICAgIDYxNDQgIDMyLDY0CiAgICAg ICAgICBwdHMgIDEwMTYgICAgLTFLICAgICAgIC0gICAgIDEwMjQgIDMyCiAgICAgbWJ1Zl90YWcg IDIyMDEgICAgLTFLICAgICAgIC0gICAgIDIyNzIgIDE2LDMyLDY0LDUxMgogICAgICAgIHNobWZk ICAgIC0xICAgIC03SyAgICAgICAtICAgICAgICAwICAKICAgICAgICAgIHBjYiAzOTc4MCAgLTE5 NUsgICAgICAgLSAgICA0MTA4OCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYs ODE5MgogICAgICAgc29uYW1lIDYwMjM3MDIgLTU5NThLICAgICAgIC0gIDYxMDE2NDggIDE2LDY0 LDEyOCwyNTYsNTEyLDQwOTYsODE5MiwxNjM4NCwzMjc2OCw2NTUzNiw1MjQyODgKICAgICAgIGJp b2J1ZiAxNjM3NiAgIC0xNUsgICAgICAgLSAgICAxNjM4NCAgMTI4CiAgICAgdmZzY2FjaGUgICAg LTEgLTEwMjNLICAgICAgIC0gICAgICAgIDAgIAogICBjbF9zYXZlYnVmIDkzNjA3NCAgLTkyMUsg ICAgICAgLSAgIDk0NDY0MCAgMTYsMzIsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2Mzg0 LDMyNzY4LDY1NTM2CiAgICAgdmZzX2hhc2ggICAgLTEgIC01MTFLICAgICAgIC0gICAgICAgIDAg IAogICAgICAgdm5vZGVzICAgLTEyICAgICAwSyAgICAgICAtICAgICAgICAwICAKICAgIGFkX2Ry aXZlciAgICAtNCAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAgdm5vZGVtYXJrZXIgNTcwMzc4 MjAgLTU1ODA5SyAgICAgICAtIDU3MTQ5NDQwICAzMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDY1NTM2 LDEzMTA3MiwyNjIxNDQsNTI0Mjg4CiAgICAgICAgbW91bnQgMTM3NTYgICAtMjBLICAgICAgIC0g ICAgMTQxOTIgIDE2LDMyLDY0LDUxMiw0MDk2CiAgICBhcl9kcml2ZXIgNzc4MDAgICAtNzVLICAg ICAgIC0gICAgNzc4MjQgIDEyOCwyNTYKICAgICAgICAgIEJQRiAgODk0NyAgICAtOEsgICAgICAg LSAgICAgODk2MCAgMTYsNjQKICBldGhlcl9tdWx0aSAgMTE2MCAgICAgMEsgICAgICAgLSAgICAg MTIwMCAgMTYsMzIsNjQsMjU2CiAgICAgICBpZmFkZHIgIDE3NzggICAtMzBLICAgICAgIC0gICAg IDIwNDggIDMyCiAgICAgICAgaWZuZXQgICAgLTkgICAtMTVLICAgICAgIC0gICAgICAgIDAgIAog ICAgICAgIGNsb25lICAgIC04ICAgLTMxSyAgICAgICAtICAgICAgICAwICAKICAgICAgIGFycGNv bSAgICAtMiAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAgICAgICBmd19jb20gICAgLTEgICAg IDBLICAgICAgIC0gICAgICAgIDAgIAogICAgICBsbHRhYmxlICAgNDg0ICAgLTEwSyAgICAgICAt ICAgICAgNTEyICAzMgogICBhY2RfZHJpdmVyICAgIC0xICAgIC0xSyAgICAgICAtICAgICAgICAw ICAKICAgICAgICAgIHR1biAgICAtMSAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAgICAgcm91 dGV0YmwgMTQwNjAxNTc3NiAtMTM3ODQ4MUsgICAgICAgLSAxNDExNTI5NTY4ICAxNiwzMiw2NCw1 MTIsMTAyNCwyMDQ4LDQwOTYsODE5MiwxNjM4NCwzMjc2OCw2NTUzNiwxMzEwNzIsMjYyMTQ0LDUy NDI4OCwxMDQ4NTc2LDIwOTcxNTIsODM4ODYwOCwzMzU1NDQzMgogICAgIDgwMjExY29tICAgIC0x ICAgIC03SyAgICAgICAtICAgICAgICAwICAKICAgIDgwMjExc2NhbiAgICAtMSAgICAtM0sgICAg ICAgLSAgICAgICAgMCAgCiAgICAgICAgIGlnbXAgICAgLTggICAgLTFLICAgICAgIC0gICAgICAg IDAgIAogICAgICBhY3BpZGV2ICAgLTY4ICAgIC0zSyAgICAgICAtICAgICAgICAwICAKICAgICBp bl9tdWx0aSAgIDc2MyAgICAgMEsgICAgICAgLSAgICAgIDc2OCAgMTYsMzIKICAgIHNjdHBfaXRl ciAgIDUxMCAgICAgMEsgICAgICAgLSAgICAgIDUxMiAgMzIKICAgICBzY3RwX2lmbiAgIDEyNSAg ICAgMEsgICAgICAgLSAgICAgIDEyOCAgMTYKICAgICBzY3RwX2lmYSAgIDEyMyAgICAgMEsgICAg ICAgLSAgICAgIDEyOCAgMTYKICAgICBzY3RwX3ZyZiAgICAtMSAgICAgMEsgICAgICAgLSAgICAg ICAgMCAgCiAgICBzY3RwX2FfaXQgICAgMzAgICAgIDBLICAgICAgIC0gICAgICAgMzIgIDMyCiAg ICBob3N0Y2FjaGUgICAgLTEgICAtMjdLICAgICAgIC0gICAgICAgIDAgIAogICAgIHN5bmNhY2hl ICAgIC0xICAgLTk1SyAgICAgICAtICAgICAgICAwICAKICAgICBwY2lfbGluayAgIC0xNiAgICAg MEsgICAgICAgLSAgICAgICAgMCAgCiBpcDZfbW9wdGlvbnMgICAgLTIgICAgIDBLICAgICAgIC0g ICAgICAgIDAgIAogICAgaW42X211bHRpICAxMTMxICAgIC0xSyAgICAgICAtICAgICAxMTUyICAx MjgKICBpbjZfbWZpbHRlciAgICAtMSAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAgICAgICAg ICBtbGQgICAgLTggICAgIDBLICAgICAgIC0gICAgICAgIDAgIAogICAgICBORlMgRkhBICAgIC0x ICAgIC0xSyAgICAgICAtICAgICAgICAwICAKICAgICAgICAgIHJwYyAgIC0xMiAgICAtOEsgICAg ICAgLSAgICAgICAgMCAgCmF1ZGl0X2V2Y2xhc3MgIDEwMzkgICAgLTVLICAgICAgIC0gICAgIDEy NDggIDE2LDMyLDY0LDUxMgogICAgIHNhdmVkaW5vIDg4MjMwMCAgLTg2NEsgICAgICAgLSAgIDg4 NTc2MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCw0MDk2LDE2Mzg0LDMyNzY4CiAgICAgICBk aXJyZW0gMzc3NTUxICAtMzc0SyAgICAgICAtICAgMzgzNTUyICAxNiwxMjgsMjU2LDEwMjQsNDA5 Niw4MTkyLDE2Mzg0LDMyNzY4CiAgICAgICAgbWtkaXIgIDEwMDggICAgIDBLICAgICAgIC0gICAg IDEwMjQgIDE2LDMyLDY0LDEyOAogICAgICAgZGlyYWRkIDM4MDA3MSAgLTM3NksgICAgICAgLSAg IDM4NjExMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYsMTYzODQsNjU1MzYK ICAgICBmcmVlZmlsZSAxMDg5MjcgIC0xMDdLICAgICAgIC0gICAxMTA2NTYgIDE2LDMyLDY0LDEy OCwyNTYsNTEyLDEwMjQsNDA5Niw4MTkyCiAgICAgZnJlZWJsa3MgMTc2NjM4NSAtMTczMEsgICAg ICAgLSAgMTc3MzMxMiAgMTYsMzIsNjQsMTI4LDUxMiwxMDI0LDIwNDgsODE5MiwxNjM4NCw2NTUz NgogICAgIGZyZWVmcmFnIDMxNDUyNzUgLTMxMTlLICAgICAgIC0gIDMxOTUyMDAgIDE2LDMyLDEy OCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2LDgxOTIsMTYzODQsMzI3NjgsNjU1MzYsMTMxMDcyLDI2 MjE0NAogICBhbGxvY2luZGlyIDE1NDgzODQgLTE1MjNLICAgICAgIC0gIDE1NjA1NzYgIDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsNDA5Niw4MTkyLDE2Mzg0LDMyNzY4LDEzMTA3MgogICAgIGluZGly ZGVwIDQwMjUwMSAgLTM5M0sgICAgICAgLSAgIDQwMzk2OCAgMTYsMzIsNjQsMTI4LDUxMiwxMDI0 LDIwNDgsODE5MgogIGFsbG9jZGlyZWN0IDIzMTE0MjE5IC0yMjY2MEsgICAgICAgLSAyMzIwNDg2 NCAgMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYsMTYzODQsMzI3NjgsNjU1MzYsMjYy MTQ0LDUyNDI4OAogICAgYm1zYWZlbWFwIDMyMzg0OSAgLTMxN0sgICAgICAgLSAgIDMyNjQwMCAg MzIsNjQsMTI4LDI1Niw1MTIsMjA0OCw0MDk2LDMyNzY4CiAgICAgICBuZXdibGsgNjQ3ODczMCAt NjQyNksgICAgICAgLSAgNjU4MTU2OCAgMTYsNjQsMTI4LDUxMiwyMDQ4LDQwOTYsMTYzODQsMzI3 NjgsNjU1MzYsMTMxMDcyLDI2MjE0NCw1MjQyODgKICAgICBpbm9kZWRlcCAzMTkwNTUwIC0zNjQx SyAgICAgICAtICAzMjAzMDcyICAxNiwzMiw2NCwxMjgsMjU2LDEwMjQsMjA0OCw0MDk2LDgxOTIs MTYzODQsMzI3NjgsMTMxMDcyCiAgICAgIHBhZ2VkZXAgMzM0NjQzICAtNDU2SyAgICAgICAtICAg MzM3MjgwICAxNiwzMiwxMjgsMjU2LDUxMiw4MTkyLDMyNzY4CiAgdWZzX2Rpcmhhc2ggMjY5MTYy MDUgLTI2NTY0SyAgICAgICAtIDI2OTcxMzkyICAxNiwzMiwxMjgsMjU2LDUxMiwyMDQ4LDQwOTYs ODE5MiwxNjM4NCwzMjc2OCwyNjIxNDQsNTI0Mjg4CiAgICB1ZnNfbW91bnQgICAtMTIgICAtMjVL ICAgICAgIC0gICAgICAgIDAgIAogICAgICBVTUFIYXNoICA3Njc1ICAgLTE0SyAgICAgICAtICAg ICA3NjgwICA2NAogICAgICBmd194ZmVyICAgMjU1ICAgICAwSyAgICAgICAtICAgICAgMjU2ICAx NgogICAgdm1fcGdkYXRhICAgIC0yICAtMTI3SyAgICAgICAtICAgICAgICAwICAKICAgICAgZW50 cm9weSAtMTAyNCAgIC02M0sgICAgICAgLSAgICAgICAgMCAgCiAgICAgZmlyZXdpcmUgIDQwODIg ICAtMzdLICAgICAgIC0gICAgIDQwOTYgIDE2LDMyCiAgICBhY3BpX3BlcmYgICAgLTIgICAgIDBL ICAgICAgIC0gICAgICAgIDAgIAogICAgICBzY3NpX2NkICAgMTA1ICAgICAwSyAgICAgICAtICAg ICAgMTEyICAxNiwzMiw2NAogICAgICBpb19hcGljICAgIC0xICAgIC0xSyAgICAgICAtICAgICAg ICAwICAKICAgICAgICAgVUFSVCAgICAtMyAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiAgICAg IG1lbWRlc2MgMTY0MTAgICAtMTlLICAgICAgIC0gICAgMTY0MTYgIDE2LDY0CiAgICAgICAgICBt c2kgICAgLTMgICAgIDBLICAgICAgIC0gICAgICAgIDAgIAogICAgIG5leHVzZGV2ICAgIC0zICAg ICAwSyAgICAgICAtICAgICAgICAwICAKICAgICAgIFVTQmRldiAgNDE1OCAgIC0xOUsgICAgICAg LSAgICAgNDIyNCAgMTYsNjQsMTI4CiAgICAgICAgICBVU0IgODk2MDU0IC0xNTc0SyAgICAgICAt ICAgODk2MTI4ICAxNiwzMiwxMjgsMjU2CiAgICAgICBERVZGUzEgMjY5MjIgIC0xMDZLICAgICAg IC0gICAgMjcxMzYgIDE2LDY0LDI1Niw1MTIKICAgICAgIERFVkZTMyAxMTc5NSAgIC01OEsgICAg ICAgLSAgICAxMjAzMiAgMTYsMzIsNjQsMTI4LDUxMgogICAgIGF0a2JkZGV2ICAgIC0yICAgICAw SyAgICAgICAtICAgICAgICAwICAKICAgICAgICBERVZGUyAgICAxNSAgICAgMEsgICAgICAgLSAg ICAgICA0OCAgMTYsMzIKICAgICAgIERFVkZTUCAgICA2MSAgICAgMEsgICAgICAgLSAgICAgICA2 NCAgMTYKICAgIHBmc19ub2RlcyAgIC0yMCAgICAtNEsgICAgICAgLSAgICAgICAgMCAgCiAgICAg ICAgIEdFT00gMTg4NTgyMDcgLTE4NDQ4SyAgICAgICAtIDE4ODU5MzI4ICAxNiwzMiw2NCwyNTYs MTAyNCwyMDQ4LDQwOTYsODE5MgogICAgICAgZmVlZGVyIDIzMjEyICAgLTM2SyAgICAgICAtICAg IDIzODA4ICAzMiwxMjgsMjU2LDUxMiwyMDQ4CiAgICAgcmF0ZWZlZWQgNTE1MTQ4ICAtNTIySyAg ICAgICAtICAgNTE1MjAwICAzMiwyNTYsNTEyCiAgICAgICAgbWl4ZXIgICAgLTIgICAgLTdLICAg ICAgIC0gICAgICAgIDAgIAogICAgICAgICBoZGFjICAgIC03ICAgLTIySyAgICAgICAtICAgICAg ICAwICAKICAgICAgc29sYXJpcyAzMjQ4MTUyMzcgLTM5OTczMksgICAgICAgLSAzMjU1NjY2NDAg IDMyLDY0LDEyOCwyNTYsMTAyNCwyMDQ4LDQwOTYsODE5MiwxNjM4NCw2NTUzNiwyNjIxNDQsNTI0 Mjg4LDIwOTcxNTIsNDE5NDMwNAogICBrc3RhdF9kYXRhICAgIC0yICAgICAwSyAgICAgICAtICAg ICAgICAwICAKICAgICAgICBsaW51eCAgMTc3NCAgICAtMksgICAgICAgLSAgICAgMTg1NiAgMTYs MzIsMTI4LDI1Ngpkcm1fY3R4Yml0bWFwICAgIC0xICAgIC0zSyAgICAgICAtICAgICAgICAwICAK IGRybV9hZ3BsaXN0cyAgICAtMSAgICAgMEsgICAgICAgLSAgICAgICAgMCAgCiBkcm1fYnVmbGlz dHMgICAgLTIgICAgIDBLICAgICAgIC0gICAgICAgIDAgIAogICAgZHJtX2ZpbGVzICAgIC0xICAg ICAwSyAgICAgICAtICAgICAgICAwICAKICAgICBkcm1fbWFwcyAgICAtOCAgICAtN0sgICAgICAg LSAgICAgICAgMCAgCiAgIGRybV9kcml2ZXIgICAgLTUgICAgLTNLICAgICAgIC0gICAgICAgIDAg IAogICAgZHJtX3NhcmVhICAgIC0xICAgICAwSyAgICAgICAtICAgICAgICAwICAKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAgICAgICAgICAgICAgICBTSVpFICAgICBMSU1J VCAgICAgIFVTRUQgICAgICBGUkVFICBSRVFVRVNUUyAgRkFJTFVSRVMKClVNQSBLZWdzOiAgICAg ICAgICAgICAgICAgMjA4LCAgICAgICAgMCwgICAgICAxMTAsICAgICAgICA5LCAgICAgIDExMCwg ICAgICAgIDAKVU1BIFpvbmVzOiAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgIDEx MCwgICAgICAgMTAsICAgICAgMTEwLCAgICAgICAgMApVTUEgU2xhYnM6ICAgICAgICAgICAgICAg IDU2OCwgICAgICAgIDAsICAgICAyNzg1LCAgICAgIDM1OCwgICAgIDg5MTgsICAgICAgICAwClVN QSBSQ250U2xhYnM6ICAgICAgICAgICAgNTY4LCAgICAgICAgMCwgICAgICA0MTUsICAgICAgIDMz LCAgICAgIDQ0NSwgICAgICAgIDAKVU1BIEhhc2g6ICAgICAgICAgICAgICAgICAyNTYsICAgICAg ICAwLCAgICAgICAgMSwgICAgICAgMTQsICAgICAgICAyLCAgICAgICAgMAoxNiBCdWNrZXQ6ICAg ICAgICAgICAgICAgIDE1MiwgICAgICAgIDAsICAgICAgIDQxLCAgICAgICA1OSwgICAgICAgOTMs ICAgICAgICAwCjMyIEJ1Y2tldDogICAgICAgICAgICAgICAgMjgwLCAgICAgICAgMCwgICAgICAg NTMsICAgICAgIDQ1LCAgICAgICA5MiwgICAgICAgIDIKNjQgQnVja2V0OiAgICAgICAgICAgICAg ICA1MzYsICAgICAgICAwLCAgICAgICA0MywgICAgICAgNDgsICAgICAgMTI5LCAgICAgICAyMgox MjggQnVja2V0OiAgICAgICAgICAgICAgMTA0OCwgICAgICAgIDAsICAgICAgMTAwLCAgICAgICA4 NiwgICAgICA2MzIsICAgICAgMzY0ClZNIE9CSkVDVDogICAgICAgICAgICAgICAgMjAwLCAgICAg ICAgMCwgICAgNTQ0NzQsICAgICAgMjA4LCAgIDM2NTQ0NiwgICAgICAgIDAKTUFQOiAgICAgICAg ICAgICAgICAgICAgICAyMjQsICAgICAgICAwLCAgICAgICAgNywgICAgICAgMjcsICAgICAgICA3 LCAgICAgICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAgIDExMiwgICAgODcxMjAsICAgICAg MTA5LCAgICAgIDEyMiwgICAgMTYwOTEsICAgICAgICAwCk1BUCBFTlRSWTogICAgICAgICAgICAg ICAgMTEyLCAgICAgICAgMCwgICAgIDE4NDAsICAgICAgNzY3LCAgNjEzMzY5MiwgICAgICAgIDAK RFAgZmFrZXBnOiAgICAgICAgICAgICAgICAxMTIsICAgICAgICAwLCAgICAgICAyOSwgICAgICAg MzcsICAgICAgIDc0LCAgICAgICAgMAptdF96b25lOiAgICAgICAgICAgICAgICAgMjA1NiwgICAg ICAgIDAsICAgICAgMjkwLCAgICAgICAzMSwgICAgICAyOTAsICAgICAgICAwCjE2OiAgICAgICAg ICAgICAgICAgICAgICAgIDE2LCAgICAgICAgMCwgICAgIDI5NTMsICAgICAgNDA3LCAgODc5NzI5 NSwgICAgICAgIDAKMzI6ICAgICAgICAgICAgICAgICAgICAgICAgMzIsICAgICAgICAwLCAgICAg MzczNCwgICAgICA0MDcsICA1NjQ0MzUyLCAgICAgICAgMAo2NDogICAgICAgICAgICAgICAgICAg ICAgICA2NCwgICAgICAgIDAsICAgICAzMTMyLCAgICAgIDYyMCwgIDE5Njc0MjAsICAgICAgICAw CjEyODogICAgICAgICAgICAgICAgICAgICAgMTI4LCAgICAgICAgMCwgICAgIDg5MjcsICAgICAg NDY5LCAgNDUzNTkyNSwgICAgICAgIDAKMjU2OiAgICAgICAgICAgICAgICAgICAgICAyNTYsICAg ICAgICAwLCAgICAgMTUzMywgICAgIDE3ODIsICA1OTMzMzEwLCAgICAgICAgMAo1MTI6ICAgICAg ICAgICAgICAgICAgICAgIDUxMiwgICAgICAgIDAsICAgICAzNjA2LCAgICAgIDEzOSwgICAyNDAy MjksICAgICAgICAwCjEwMjQ6ICAgICAgICAgICAgICAgICAgICAxMDI0LCAgICAgICAgMCwgICAg ICAxNTUsICAgICAgMzg1LCAgICA5NTY1OCwgICAgICAgIDAKMjA0ODogICAgICAgICAgICAgICAg ICAgIDIwNDgsICAgICAgICAwLCAgICAgIDE5NiwgICAgICAgNTAsICAgIDM0MjA4LCAgICAgICAg MAo0MDk2OiAgICAgICAgICAgICAgICAgICAgNDA5NiwgICAgICAgIDAsICAgICAgNzc4LCAgICAg ICA3OCwgICAgMjY5MDksICAgICAgICAwCkZpbGVzOiAgICAgICAgICAgICAgICAgICAgIDgwLCAg ICAgICAgMCwgICAgICAxMzcsICAgICAgMzEzLCAgIDUyOTc4NywgICAgICAgIDAKVFVSTlNUSUxF OiAgICAgICAgICAgICAgICAxMzYsICAgICAgICAwLCAgICAgIDI0OSwgICAgICAgNTEsICAgICAg MjQ5LCAgICAgICAgMAp1bXR4IHBpOiAgICAgICAgICAgICAgICAgICA5NiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwClBST0M6ICAgICAgICAgICAgICAg ICAgICAxMTEyLCAgICAgICAgMCwgICAgICAxNTEsICAgICAgIDU5LCAgICAxNDY2MCwgICAgICAg IDAKVEhSRUFEOiAgICAgICAgICAgICAgICAgICA5MTIsICAgICAgICAwLCAgICAgIDI0MSwgICAg ICAgIDcsICAgICAgMjYxLCAgICAgICAgMApTTEVFUFFVRVVFOiAgICAgICAgICAgICAgICA2NCwg ICAgICAgIDAsICAgICAgMjQ5LCAgICAgICA4NywgICAgICAyNDksICAgICAgICAwClZNU1BBQ0U6 ICAgICAgICAgICAgICAgICAgMzg0LCAgICAgICAgMCwgICAgICAgNDksICAgICAgIDUxLCAgICAx NDUxNCwgICAgICAgIDAKY3B1c2V0OiAgICAgICAgICAgICAgICAgICAgNzIsICAgICAgICAwLCAg ICAgICAgMiwgICAgICAgOTgsICAgICAgICAyLCAgICAgICAgMAphdWRpdF9yZWNvcmQ6ICAgICAg ICAgICAgIDk4NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgICAzMjMsICAg ICAgNTkyLCAgMjk1NTYxNiwgICAgICAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgICAyNTYs ICAgICAgICAwLCAgICAgICAgMSwgICAgICA2NDIsICAzMTU1MzQ0LCAgICAgICAgMAptYnVmX2Ns dXN0ZXI6ICAgICAgICAgICAgMjA0OCwgICAgMjU2MDAsICAgICAgNTEyLCAgICAgIDI0MiwgICAg ICA3NjgsICAgICAgICAwCm1idWZfanVtYm9fcGFnZTogICAgICAgICA0MDk2LCAgICAxMjgwMCwg ICAgICAgIDAsICAgICAgIDM4LCAgIDI3NjYwOCwgICAgICAgIDAKbWJ1Zl9qdW1ib185azogICAg ICAgICAgIDkyMTYsICAgIDE5MjAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAptYnVmX2p1bWJvXzE2azogICAgICAgICAxNjM4NCwgICAgMTI4MDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm1idWZfZXh0X3JlZmNudDogICAgICAgICAgICA0 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKdHR5aW5x OiAgICAgICAgICAgICAgICAgICAxNjAsICAgICAgICAwLCAgICAgIDIyNSwgICAgICAxMzUsICAg ICAxMDUwLCAgICAgICAgMAp0dHlvdXRxOiAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAgIDAs ICAgICAgMTEyLCAgICAgICA2OCwgICAgICA1NDMsICAgICAgICAwCmdfYmlvOiAgICAgICAgICAg ICAgICAgICAgMjE2LCAgICAgICAgMCwgICAgICAgIDEsICAgICAzMjM5LCAgIDYxMzcxMywgICAg ICAgIDAKYXRhX3JlcXVlc3Q6ICAgICAgICAgICAgICAzMTIsICAgICAgICAwLCAgICAgICAgMSwg ICAgICA3NzAsICAgMTcwNTgxLCAgICAgICAgMAphdGFfY29tcG9zaXRlOiAgICAgICAgICAgIDMz NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwClZOT0RF OiAgICAgICAgICAgICAgICAgICAgNDcyLCAgICAgICAgMCwgICAgNzc4OTEsICAgICAgMjY5LCAg MTMyNzM5OCwgICAgICAgIDAKVk5PREVQT0xMOiAgICAgICAgICAgICAgICAxMDQsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApOQU1FSTogICAgICAgICAg ICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAzNiwgIDM1NDAxMDAsICAg ICAgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgICAgMTA4LCAgICAgICAgMCwgICAgNjI2ODUs ICAgIDIyMzU2LCAgMTI4NDMzMywgICAgICAgIDAKTCBWRlMgQ2FjaGU6ICAgICAgICAgICAgICAz MjgsICAgICAgICAwLCAgICAyMTI2MCwgICAgICAzNjQsICAgIDg1Nzk4LCAgICAgICAgMApORlNN T1VOVDogICAgICAgICAgICAgICAgIDc0NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCk5GU05PREU6ICAgICAgICAgICAgICAgICAgNzYwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKRElSSEFTSDogICAgICAg ICAgICAgICAgIDEwMjQsICAgICAgICAwLCAgICAgMTkxMywgICAgICAxMzUsICAgICA3NDUwLCAg ICAgICAgMApwaXBlOiAgICAgICAgICAgICAgICAgICAgIDcxMiwgICAgICAgIDAsICAgICAgICAz LCAgICAgICAzNywgICAgIDY2NjAsICAgICAgICAwCmtzaWdpbmZvOiAgICAgICAgICAgICAgICAg MTEyLCAgICAgICAgMCwgICAgICAyMDAsICAgICAgIDMxLCAgICAgIDIwMCwgICAgICAgIDAKaXRp bWVyOiAgICAgICAgICAgICAgICAgICAzNDQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMApLTk9URTogICAgICAgICAgICAgICAgICAgIDEyMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICA5MywgICAgICAgMjgsICAgICAgICAwCnNvY2tldDogICAgICAg ICAgICAgICAgICAgNjQ4LCAgICAyNTYwMiwgICAgICAgNTgsICAgICAgMjE4LCAgICAzNDQzNiwg ICAgICAgIDAKaXBxOiAgICAgICAgICAgICAgICAgICAgICAgNTYsICAgICAgODE5LCAgICAgICAg MCwgICAgICAxMjYsICAgICAgIDY1LCAgICAgICAgMAp1ZHBjYjogICAgICAgICAgICAgICAgICAg IDMwNCwgICAgMjU2MDgsICAgICAgIDExLCAgICAgICAyNSwgICAgIDI3MTksICAgICAgICAwCmlu cGNiOiAgICAgICAgICAgICAgICAgICAgMzA0LCAgICAyNTYwOCwgICAgICAgMTEsICAgICAgMjc3 LCAgICAgMjM1OSwgICAgICAgIDAKdGNwY2I6ICAgICAgICAgICAgICAgICAgICA3NDQsICAgIDI1 NjAwLCAgICAgICAxMSwgICAgICAyMjQsICAgICAyMzU5LCAgICAgICAgMAp0Y3B0dzogICAgICAg ICAgICAgICAgICAgICA4OCwgICAgIDUxMjQsICAgICAgICAwLCAgICAgIDI1MiwgICAgICA1Mzgs ICAgICAgICAwCnN5bmNhY2hlOiAgICAgICAgICAgICAgICAgMTM2LCAgICAxNTM3MiwgICAgICAg IDAsICAgICAgIDg0LCAgICAgIDE3NSwgICAgICAgIDAKaG9zdGNhY2hlOiAgICAgICAgICAgICAg ICAxMzYsICAgIDE1MzcyLCAgICAgICAgMCwgICAgICA3MjgsICAgICAgOTcxLCAgICAgICAgMAp0 Y3ByZWFzczogICAgICAgICAgICAgICAgICA0MCwgICAgIDE2ODAsICAgICAgICAwLCAgICAgIDI1 MiwgICAgIDEwOTEsICAgICAgICAwCnNhY2tob2xlOiAgICAgICAgICAgICAgICAgIDMyLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgMzAzLCAgICAgIDIwMywgICAgICAgIDAKc2N0cF9lcDogICAg ICAgICAgICAgICAgIDEyMTYsICAgIDI1NjAyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMApzY3RwX2Fzb2M6ICAgICAgICAgICAgICAgMjE3NiwgICAgNDAwMDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfbGFkZHI6ICAgICAgICAgICAg ICAgIDQ4LCAgICA4MDA2NCwgICAgICAgIDAsICAgICAgMTQ0LCAgICAgICAgMywgICAgICAgIDAK c2N0cF9yYWRkcjogICAgICAgICAgICAgICA1OTIsICAgIDgwMDA0LCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2NodW5rOiAgICAgICAgICAgICAgIDE0NCwgICA0 MDAwMTAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfcmVhZHE6 ICAgICAgICAgICAgICAgMTA0LCAgIDQwMDAzMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAKc2N0cF9zdHJlYW1fbXNnX291dDogICAgICAgOTYsICAgNDAwMDI2LCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2FzY29uZjogICAgICAgICAg ICAgICA0MCwgICA0MDAwMDgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw CnNjdHBfYXNjb25mX2FjazogICAgICAgICAgIDQ4LCAgIDQwMDAzMiwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAKcmlwY2I6ICAgICAgICAgICAgICAgICAgICAzMDQsICAg IDI1NjA4LCAgICAgICAgMCwgICAgICAgMzYsICAgICAgICAzLCAgICAgICAgMAp1bnBjYjogICAg ICAgICAgICAgICAgICAgIDI0MCwgICAgMjU2MDAsICAgICAgIDM2LCAgICAgICA0NCwgICAgMjkz MzUsICAgICAgICAwCnJ0ZW50cnk6ICAgICAgICAgICAgICAgICAgMjAwLCAgICAgICAgMCwgICAg ICAgIDcsICAgICAgIDUwLCAgICAgICAxNywgICAgICAgIDAKcGZzcmN0cnBsOiAgICAgICAgICAg ICAgICAxNTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MApwZnJ1bGVwbDogICAgICAgICAgICAgICAgIDkxMiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmc3RhdGVwbDogICAgICAgICAgICAgICAgMzkyLCAg ICAxMDAwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZhbHRxcGw6 ICAgICAgICAgICAgICAgICAyNDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMApwZnBvb2xhZGRycGw6ICAgICAgICAgICAgICA4OCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmcmt0YWJsZTogICAgICAgICAg ICAgICAxMjk2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKcGZya2VudHJ5OiAgICAgICAgICAgICAgICAyMTYsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZnJrZW50cnkyOiAgICAgICAgICAgICAgIDIxNiwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmZnJlbnQ6 ICAgICAgICAgICAgICAgICAgIDMyLCAgICAgNTA1MCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKcGZmcmFnOiAgICAgICAgICAgICAgICAgICAgODAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmZyY2FjaGU6ICAgICAgICAg ICAgICAgICA4MCwgICAgMTAwMzUsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwCnBmZnJjZW50OiAgICAgICAgICAgICAgICAgIDI0LCAgICA1MDAyMiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZzdGF0ZXNjcnViOiAgICAgICAgICAgICAgNDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmlhZGRy cGw6ICAgICAgICAgICAgICAgIDEyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBmb3NwZmVuOiAgICAgICAgICAgICAgICAgMTEyLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZvc2ZwOiAgICAgICAgICAg ICAgICAgICAgNDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgICA1NiwgICAgICAgIDAsICAgICAgMTAyLCAg ICAgIDQ2NSwgNTMxODUxNTQsICAgICAgICAwCmlwNGZsb3c6ICAgICAgICAgICAgICAgICAgIDU2 LCAgICAgNDE1OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKaXA2Zmxv dzogICAgICAgICAgICAgICAgICAgODAsICAgICA0MTQwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMApNb3VudHBvaW50czogICAgICAgICAgICAgIDc1MiwgICAgICAgIDAs ICAgICAgICA3LCAgICAgICAgOCwgICAgICAgIDcsICAgICAgICAwClNXQVBNRVRBOiAgICAgICAg ICAgICAgICAgMjg4LCAgIDExNjUxOSwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAKRkZTIGlub2RlOiAgICAgICAgICAgICAgICAxNjgsICAgICAgICAwLCAgICA3NTUzOSwg ICAgIDIyMDksICAxMzE2NjE5LCAgICAgICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAgIDEy OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCkZGUzIg ZGlub2RlOiAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgNzU1MzksICAgICAyMTc2LCAg MTMxNjYxOSwgICAgICAgIDAKdGFza3FfZW50X2NhY2hlOiAgICAgICAgICAgNjQsICAgICAgICAw LCAgICAgIDYwOCwgICAgICAyMzIsICAgICAxMzU4LCAgICAgICAgMAp0YXNrcV9jYWNoZTogICAg ICAgICAgICAgIDI4OCwgICAgICAgIDAsICAgICAgIDE1LCAgICAgICAyNCwgICAgICAgMjcsICAg ICAgICAwCnppb19jYWNoZTogICAgICAgICAgICAgICAgNzIwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgODI1LCAgIDEwMjUzNywgICAgICAgIDAKZG11X2J1Zl9pbXBsX3Q6ICAgICAgICAgICAy MjQsICAgICAgICAwLCAgICAgMzEwNywgICAgICAyMjUsICAgICA0MzU3LCAgICAgICAgMApkbm9k ZV90OiAgICAgICAgICAgICAgICAgIDc2OCwgICAgICAgIDAsICAgICAyNTM4LCAgICAgICA4Miwg ICAgIDI3OTEsICAgICAgICAwCmFyY19idWZfaGRyX3Q6ICAgICAgICAgICAgMjA4LCAgICAgICAg MCwgICAgICA4NjksICAgICAgIDQ5LCAgICAgMTkyNCwgICAgICAgIDAKYXJjX2J1Zl90OiAgICAg ICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgIDc3MSwgICAgICAxNzksICAgICAxOTI0LCAg ICAgICAgMAp6aWxfbHdiX2NhY2hlOiAgICAgICAgICAgIDIwMCwgICAgICAgIDAsICAgICAgICAx LCAgICAgIDExMywgICAgICAyNzIsICAgICAgICAwCnpmc196bm9kZV9jYWNoZTogICAgICAgICAg Mzc2LCAgICAgICAgMCwgICAgIDIzMDMsICAgICAgMjY3LCAgICAxMDY3MywgICAgICAgIDAKCgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgppbnRlcnJ1cHQgICAgICAgICAgICAgICAgICAgICAg ICAgIHRvdGFsICAgICAgIHJhdGUKaXJxMTogYXRrYmQwICAgICAgICAgICAgICAgICAgICAgICAg MTQ3MSAgICAgICAgIDM0CmlycTE3OiB1aGNpMiBlaGNpKyAgICAgICAgICAgICAgICAgIDM3MDUg ICAgICAgICA4NgppcnExODogdWhjaTAgdWhjaTUgICAgICAgICAgICAgICAgIDUwMzc4ICAgICAg IDExNzEKaXJxMTk6IGZ3b2hjaTArICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAw CmlycTIxOiB1aGNpMSsrICAgICAgICAgICAgICAgICAgICAxNjEzMDMgICAgICAgMzc1MQppcnEy MzogdWhjaTMgZWhjaTEgICAgICAgICAgICAgICAgICAgMjc3ICAgICAgICAgIDYKY3B1MDogdGlt ZXIgICAgICAgICAgICAgICAgICAgIDUzMjUxNDc5NCAgIDEyMzg0MDY0CmlycTI1NjogZW0wICAg ICAgICAgICAgICAgICAgICAgICAzMDY3ODEgICAgICAgNzEzNAppcnEyNTc6IGhkYWMwICAgICAg ICAgICAgICAgICAgICAgIDk5OTU0ICAgICAgIDIzMjQKY3B1MTogdGltZXIgICAgICAgICAgICAg ICAgICAgIDUzMjUwNDgxMiAgIDEyMzgzODMyCmlycTI1ODogdmdhcGNpMCAgICAgICAgICAgICAg ICAgICAxNDQ4NjkgICAgICAgMzM2OQpUb3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAxMDY1 Nzg4MzQ1ICAgMjQ3ODU3NzUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtVAoKMTM3LzEyMzI4IGZp bGVzCjBNLzEwMjNNIHN3YXAgc3BhY2UKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNl ICAgICAgICAgIDUxMi1ibG9ja3MgICAgIFVzZWQgICAgQXZhaWwgQ2FwYWNpdHkKL2Rldi9hZDZz MmIgICAgICAgIDIwOTY4OTYgICAgICAgIDAgIDIwOTY4OTYgICAgIDAlCgotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KaW9zdGF0Cgppb3N0YXQ6IGt2bV9yZWFkKF90a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4 MCkKaW9zdGF0OiBkaXNhYmxpbmcgVFRZIHN0YXRpc3RpY3MKaW9zdGF0OiBrdm1fZ2V0Y3B0aW1l OiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgQ1BVIHRpbWUgc3RhdGlz dGljcwogICAgICAgICAgICAgYWQ2ICAgICAgICAgICAgICBhZDggICAgICAgICAgICAgYWQxMCAK ICBLQi90IHRwcyAgTUIvcyAgIEtCL3QgdHBzICBNQi9zICAgS0IvdCB0cHMgIE1CL3MgCiAxMi4x NiAzNDMyIDQwLjc3ICAxNS44OSAgODQgIDEuMzEgIDE1LjkxICA4NCAgMS4zMSAKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQppcGNzIC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQgICAgICAgICAg S0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAg ICAgICAgICAgQ0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAgICAgUUJZVEVT ICAgICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJTUUgICAKClNo YXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAgICBPV05F UiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICBOQVRUQ0ggICAgICAgIFNFR1Na ICAgICAgICAgQ1BJRCAgICAgICAgIExQSUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJTUUgICAKbSAg ICAgIDE3MDM5MzYgICAgICAgICAgICAwIC0tcnctLS0tLS0tIG1hdGhldXMgIHdoZWVsICAgIG1h dGhldXMgIHdoZWVsICAgICAgICAgICAgICAgMiAgICAgICAzOTMyMTYgICAgICAgICAxNzU5ICAg ICAgICAgMTc0OSAxMjowMDoyMiBuby1lbnRyeSAxMjowMDoyMgptICAgICAgMTkwMDU0NSAgICAg ICAgICAgIDAgLS1ydy0tLS0tLS0gbWF0aGV1cyAgd2hlZWwgICAgbWF0aGV1cyAgd2hlZWwgICAg ICAgICAgICAgICAyICAgICAgIDM5MzIxNiAgICAgICAgIDE3NTkgICAgICAgICAxNzQ5IDEyOjAw OjIyIDEyOjAwOjIyIDEyOjAwOjIyCgpTZW1hcGhvcmVzOgpUICAgICAgICAgICBJRCAgICAgICAg ICBLRVkgTU9ERSAgICAgICAgT1dORVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAg ICAgIE5TRU1TIE9USU1FICAgIENUSU1FICAgCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlwY3MgLVQKCm1z Z2luZm86Cgltc2dtYXg6ICAgICAgICAxNjM4NAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdl KQoJbXNnbW5pOiAgICAgICAgICAgNDAJKCMgb2YgbWVzc2FnZSBxdWV1ZXMpCgltc2dtbmI6ICAg ICAgICAgMjA0OAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlIHF1ZXVlKQoJbXNndHFsOiAg ICAgICAgICAgNDAJKG1heCAjIG9mIG1lc3NhZ2VzIGluIHN5c3RlbSkKCW1zZ3NzejogICAgICAg ICAgICA4CShzaXplIG9mIGEgbWVzc2FnZSBzZWdtZW50KQoJbXNnc2VnOiAgICAgICAgIDIwNDgJ KCMgb2YgbWVzc2FnZSBzZWdtZW50cyBpbiBzeXN0ZW0pCgpzaG1pbmZvOgoJc2htbWF4OiAgICAg MzM1NTQ0MzIJKG1heCBzaGFyZWQgbWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1pbjogICAgICAg ICAgICAxCShtaW4gc2hhcmVkIG1lbW9yeSBzZWdtZW50IHNpemUpCglzaG1tbmk6ICAgICAgICAg IDE5MgkobWF4IG51bWJlciBvZiBzaGFyZWQgbWVtb3J5IGlkZW50aWZpZXJzKQoJc2htc2VnOiAg ICAgICAgICAxMjgJKG1heCBzaGFyZWQgbWVtb3J5IHNlZ21lbnRzIHBlciBwcm9jZXNzKQoJc2ht YWxsOiAgICAgICAgIDgxOTIJKG1heCBhbW91bnQgb2Ygc2hhcmVkIG1lbW9yeSBpbiBwYWdlcykK CnNlbWluZm86CglzZW1tYXA6ICAgICAgICAgICAzMAkoIyBvZiBlbnRyaWVzIGluIHNlbWFwaG9y ZSBtYXApCglzZW1tbmk6ICAgICAgICAgICAxMAkoIyBvZiBzZW1hcGhvcmUgaWRlbnRpZmllcnMp CglzZW1tbnM6ICAgICAgICAgICA2MAkoIyBvZiBzZW1hcGhvcmVzIGluIHN5c3RlbSkKCXNlbW1u dTogICAgICAgICAgIDMwCSgjIG9mIHVuZG8gc3RydWN0dXJlcyBpbiBzeXN0ZW0pCglzZW1tc2w6 ICAgICAgICAgICA2MAkobWF4ICMgb2Ygc2VtYXBob3JlcyBwZXIgaWQpCglzZW1vcG06ICAgICAg ICAgIDEwMAkobWF4ICMgb2Ygb3BlcmF0aW9ucyBwZXIgc2Vtb3AgY2FsbCkKCXNlbXVtZTogICAg ICAgICAgIDEwCShtYXggIyBvZiB1bmRvIGVudHJpZXMgcGVyIHByb2Nlc3MpCglzZW11c3o6ICAg ICAgICAgIDE1Mgkoc2l6ZSBpbiBieXRlcyBvZiB1bmRvIHN0cnVjdHVyZSkKCXNlbXZteDogICAg ICAgIDMyNzY3CShzZW1hcGhvcmUgbWF4aW11bSB2YWx1ZSkKCXNlbWFlbTogICAgICAgIDE2Mzg0 CShhZGp1c3Qgb24gZXhpdCBtYXggdmFsdWUpCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5mc3N0YXQKCkNs aWVudCBJbmZvOgpScGMgQ291bnRzOgogIEdldGF0dHIgICBTZXRhdHRyICAgIExvb2t1cCAgUmVh ZGxpbmsgICAgICBSZWFkICAgICBXcml0ZSAgICBDcmVhdGUgICAgUmVtb3ZlCiAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAg MCAgICAgICAgIDAKICAgUmVuYW1lICAgICAgTGluayAgIFN5bWxpbmsgICAgIE1rZGlyICAgICBS bWRpciAgIFJlYWRkaXIgIFJkaXJQbHVzICAgIEFjY2VzcwogICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw CiAgICBNa25vZCAgICBGc3N0YXQgICAgRnNpbmZvICBQYXRoQ29uZiAgICBDb21taXQKICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMApScGMgSW5mbzoKIFRp bWVkT3V0ICAgSW52YWxpZCBYIFJlcGxpZXMgICBSZXRyaWVzICBSZXF1ZXN0cwogICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCkNhY2hlIEluZm86CkF0dHIg SGl0cyAgICBNaXNzZXMgTGt1cCBIaXRzICAgIE1pc3NlcyBCaW9SIEhpdHMgICAgTWlzc2VzIEJp b1cgSGl0cyAgICBNaXNzZXMKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMApCaW9STEhpdHMgICAgTWlz c2VzIEJpb0QgSGl0cyAgICBNaXNzZXMgRGlyRSBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAoKU2VydmVyIElu Zm86CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAg IFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICBSZW5h bWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRp clBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3Rh dCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZlciBSZXQtRmFpbGVkCiAgICAgICAgICAgICAg ICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAgMApTZXJ2ZXIgQ2FjaGUgU3RhdHM6CiAgIElu cHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAKU2VydmVyIFdyaXRlIEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0 ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpuZXRzdGF0IC1zCgpuZXRzdGF0OiAvYm9vdC9rZXJuZWwva2VybmVsOiBubyBuYW1lbGlz dAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLW0KCm5ldHN0YXQ6IC9ib290L2tlcm5lbC9rZXJu ZWw6IG5vIG5hbWVsaXN0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtaWQKCm5ldHN0YXQ6IC9i b290L2tlcm5lbC9rZXJuZWw6IG5vIG5hbWVsaXN0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAt YW5yCgpuZXRzdGF0OiAvYm9vdC9rZXJuZWwva2VybmVsOiBubyBuYW1lbGlzdAoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCm5ldHN0YXQgLWFuQQoKbmV0c3RhdDogL2Jvb3Qva2VybmVsL2tlcm5lbDogbm8gbmFt ZWxpc3QKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hTAoKbmV0c3RhdDogL2Jvb3Qva2VybmVs L2tlcm5lbDogbm8gbmFtZWxpc3QKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKVVNFUiAgICAgQ01E ICAgICAgICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9X CnJvb3QgICAgIGJhc2ggICAgICAgMTQ2NTggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByCnJvb3QgICAgIGJhc2ggICAgICAgMTQ2NTggICB3ZCAvICAgICAgICAgNDkz NTYgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGJhc2ggICAgICAgMTQ2NTggdGV4dCAv dXNyICAgICAxNDQzMzQzIC1yd3hyLXhyLXggIDczMjA2NCAgcgpyb290ICAgICBiYXNoICAgICAg IDE0NjU4ICAgIDAgL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAg ICBiYXNoICAgICAgIDE0NjU4ICAgIDEgL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMv MCBydwpyb290ICAgICBiYXNoICAgICAgIDE0NjU4ICAgIDIgL2RldiAgICAgICAgMTMyIGNydy0t dy0tLS0gICBwdHMvMCBydwpyb290ICAgICBiYXNoICAgICAgIDE0NjU4ICAyNTUgL2RldiAgICAg ICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgIDE0NjU0IHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBjc2ggICAg ICAgIDE0NjU0ICAgd2QgLyAgICAgICAgIDQ5MzU2IGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290 ICAgICBjc2ggICAgICAgIDE0NjU0IHRleHQgLyAgICAgICAgICAgMTM4IC1yLXhyLXhyLXggIDM1 NDY3MiAgcgpyb290ICAgICBjc2ggICAgICAgIDE0NjU0ICAgMTUgL2RldiAgICAgICAgMTMyIGNy dy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgIDE0NjU0ICAgMTYgL2RldiAg ICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgIDE0NjU0 ICAgMTcgL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2gg ICAgICAgIDE0NjU0ICAgMTggL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpy b290ICAgICBjc2ggICAgICAgIDE0NjU0ICAgMTkgL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0g ICBwdHMvMCBydwpyb290ICAgICBzdSAgICAgICAgIDE0NjUzIHJvb3QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBzdSAgICAgICAgIDE0NjUzICAgd2QgL3Vz ciAgICAgNjEyMzUzIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBzdSAgICAgICAgIDE0 NjUzIHRleHQgL3VzciAgICAgIDI0MDkyIC1yLXNyLXhyLXggICAxNjg5NiAgcgpyb290ICAgICBz dSAgICAgICAgIDE0NjUzICAgIDAgL2RldiAgICAgICAgMTMyIGNydy0tdy0tLS0gICBwdHMvMCBy dwpyb290ICAgICBzdSAgICAgICAgIDE0NjUzICAgIDEgL2RldiAgICAgICAgMTMyIGNydy0tdy0t LS0gICBwdHMvMCBydwpyb290ICAgICBzdSAgICAgICAgIDE0NjUzICAgIDIgL2RldiAgICAgICAg MTMyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBzdSAgICAgICAgIDE0NjUzICAgIDUg LSAgICAgICAgIC0gICAgICAgICBiYWQgICAgLQpyb290ICAgICB1Y29tICAgICAgIDE0NjQ5IHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICB1Y29tICAg ICAgIDE0NjQ5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRo ZXVzICBiYXNoICAgICAgIDE0NjMxIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcgptYXRoZXVzICBiYXNoICAgICAgIDE0NjMxICAgd2QgL3VzciAgICAgNjEyMzUzIGRy d3hyLXhyLXggICAgMTAyNCAgcgptYXRoZXVzICBiYXNoICAgICAgIDE0NjMxIHRleHQgL3VzciAg ICAgMTQ0MzM0MyAtcnd4ci14ci14ICA3MzIwNjQgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAxNDYz MSAgICAwIC9kZXYgICAgICAgIDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncKbWF0aGV1cyAgYmFz aCAgICAgICAxNDYzMSAgICAxIC9kZXYgICAgICAgIDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncK bWF0aGV1cyAgYmFzaCAgICAgICAxNDYzMSAgICAyIC9kZXYgICAgICAgIDEzMiBjcnctLXctLS0t ICAgcHRzLzAgcncKbWF0aGV1cyAgYmFzaCAgICAgICAxNDYzMSAgICA1IC0gICAgICAgICAtICAg ICAgICAgYmFkICAgIC0KbWF0aGV1cyAgYmFzaCAgICAgICAxNDYzMSAgMjU1IC9kZXYgICAgICAg IDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncKbWF0aGV1cyAgc2ggICAgICAgICAxNDYyOSByb290 IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgc2ggICAgICAg ICAxNDYyOSAgIHdkIC91c3IgICAgIDYxMjM1MyBkcnd4ci14ci14ICAgIDEwMjQgIHIKbWF0aGV1 cyAgc2ggICAgICAgICAxNDYyOSB0ZXh0IC8gICAgICAgICAgIDE0MCAtci14ci14ci14ICAxMzMx MjAgIHIKbWF0aGV1cyAgc2ggICAgICAgICAxNDYyOSAgICAwIC9kZXYgICAgICAgIDEzMiBjcnct LXctLS0tICAgcHRzLzAgcncKbWF0aGV1cyAgc2ggICAgICAgICAxNDYyOSAgICAxIC9kZXYgICAg ICAgIDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncKbWF0aGV1cyAgc2ggICAgICAgICAxNDYyOSAg ICAyIC9kZXYgICAgICAgIDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncKbWF0aGV1cyAgc2ggICAg ICAgICAxNDYyOSAgICA1IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0KbWF0aGV1cyAgc2gg ICAgICAgICAxNDYyOSAgIDEwIC9kZXYgICAgICAgIDEzMiBjcnctLXctLS0tICAgcHRzLzAgcncK bWF0aGV1cyAgeHRlcm0gICAgICAxNDYyNyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgICA1MTIgIHIKbWF0aGV1cyAgeHRlcm0gICAgICAxNDYyNyAgIHdkIC91c3IgICAgIDYxMjM1 MyBkcnd4ci14ci14ICAgIDEwMjQgIHIKbWF0aGV1cyAgeHRlcm0gICAgICAxNDYyNyB0ZXh0IC91 c3IgICAgIDE0NDcyODggLXJ3cy0teC0teCAgMzA5MDI0ICByCm1hdGhldXMgIHh0ZXJtICAgICAg MTQ2MjcgICAgMCAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3Cm1hdGhldXMg IHh0ZXJtICAgICAgMTQ2MjcgICAgMSAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYw IHJ3Cm1hdGhldXMgIHh0ZXJtICAgICAgMTQ2MjcgICAgMiAvZGV2ICAgICAgICAgNTkgY3J3LS0t LS0tLSAgIHR0eXYwIHJ3Cm1hdGhldXMgIHh0ZXJtICAgICAgMTQ2MjcgICAgMyogbG9jYWwgc3Ry ZWFtIGZmZmZmZjAwMDUxOGExZTAgPC0+IGZmZmZmZjAwMDUyNWU1YTAKbWF0aGV1cyAgeHRlcm0g ICAgICAxNDYyNyAgICA0KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRzLzAgcncKbWF0 aGV1cyAgeHRlcm0gICAgICAxNDYyNyAgICA1IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0K bWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE2ICAgd2QgL3VzciAg ICAgNjU5NzQ5IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAx MTcxNiB0ZXh0IC91c3IgICAgIDY1OTQ4MyAtcnd4ci14LS0tICAzNDM1Mjk2ICByCm1hdGhldXMg IEZhaENvcmVfNzguZXhlIDExNzE2ICAgIDAgL2RldiAgICAgICAgMTY4IGNydy0tdy0tLS0gICBw dHMvMyBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNiAgICAxIC9kZXYgICAgICAgIDE2 OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTYgICAg MiAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIEZhaENvcmVf NzguZXhlIDExNzE2ICAgIDMgL3VzciAgICAgNjU5NDYxIC1ydy1yLS1yLS0gICA0OTAxNiBydwpt YXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNiAgICA0IC91c3IgICAgIDY1OTUwMyAtcnd4ci14 LS0tICAgIDUwNDQgIHcKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTYgICAgNSogcGlwZSBm ZmZmZmYwMDA1MTQ3YjIwIDwtPiBmZmZmZmYwMDA1MTQ3YzcwICAgICAgMCBydwptYXRoZXVzICBG YWhDb3JlXzc4LmV4ZSAxMTcxNiAgICA2KiBwaXBlIGZmZmZmZjAwMDUxNDdjNzAgPC0+IGZmZmZm ZjAwMDUxNDdiMjAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE2ICAgIDcg L3VzciAgICAgNjU5NTQ3IC1ydy1yLS1yLS0gICAzMzQzNCAgdwptYXRoZXVzICBGYWhDb3JlXzc4 LmV4ZSAxMTcxNiAgICA4IC91c3IgICAgIDY1OTUwOSAtcnctci0tci0tICAgICAgIDAgcncKbWF0 aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTYgICAgOSAvdXNyICAgICA2NTk1MzkgLXJ3LXItLXIt LSAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE2ICAgMTAgL3VzciAgICAg NjU5NTQ0IC1ydy1yLS1yLS0gICAgNTE5NiBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcx NiAgIDExIC91c3IgICAgIDY1OTUxMyAtcnctci0tci0tICAgICAgIDAgcncKbWF0aGV1cyAgRmFo Q29yZV83OC5leGUgMTE3MTYgICAxMiAvdXNyICAgICA2NTk1MTEgLXJ3LXItLXItLSAgIDExNzgw IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE1IHJvb3QgLyAgICAgICAgICAgICAyIGRy d3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNSAgIHdkIC91 c3IgICAgIDY1OTc0OSBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgRmFoQ29yZV83OC5l eGUgMTE3MTUgdGV4dCAvdXNyICAgICA2NTk0ODMgLXJ3eHIteC0tLSAgMzQzNTI5NiAgcgptYXRo ZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNSAgICAwIC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0t ICAgcHRzLzMgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTUgICAgMSAvZGV2ICAgICAg ICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE1 ICAgIDIgL2RldiAgICAgICAgMTY4IGNydy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBGYWhD b3JlXzc4LmV4ZSAxMTcxNSAgICAzIC91c3IgICAgIDY1OTQ2MSAtcnctci0tci0tICAgNDkwMTYg cncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTUgICAgNCAvdXNyICAgICA2NTk1MDMgLXJ3 eHIteC0tLSAgICA1MDQ0ICB3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE1ICAgIDUqIHBp cGUgZmZmZmZmMDAwNTE0N2IyMCA8LT4gZmZmZmZmMDAwNTE0N2M3MCAgICAgIDAgcncKbWF0aGV1 cyAgRmFoQ29yZV83OC5leGUgMTE3MTUgICAgNiogcGlwZSBmZmZmZmYwMDA1MTQ3YzcwIDwtPiBm ZmZmZmYwMDA1MTQ3YjIwICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNSAg ICA3IC91c3IgICAgIDY1OTU0NyAtcnctci0tci0tICAgMzM0MzQgIHcKbWF0aGV1cyAgRmFoQ29y ZV83OC5leGUgMTE3MTUgICAgOCAvdXNyICAgICA2NTk1MDkgLXJ3LXItLXItLSAgICAgICAwIHJ3 Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE1ICAgIDkgL3VzciAgICAgNjU5NTM5IC1ydy1y LS1yLS0gICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNSAgIDEwIC91c3Ig ICAgIDY1OTU0NCAtcnctci0tci0tICAgIDUxOTYgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUg MTE3MTUgICAxMSAvdXNyICAgICA2NTk1MTMgLXJ3LXItLXItLSAgICAgICAwIHJ3Cm1hdGhldXMg IEZhaENvcmVfNzguZXhlIDExNzE1ICAgMTIgL3VzciAgICAgNjU5NTExIC1ydy1yLS1yLS0gICAx MTc4MCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTQgICB3 ZCAvdXNyICAgICA2NTk3NDkgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIEZhaENvcmVf NzguZXhlIDExNzE0IHRleHQgL3VzciAgICAgNjU5NDgzIC1yd3hyLXgtLS0gIDM0MzUyOTYgIHIK bWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTQgICAgMCAvZGV2ICAgICAgICAxNjggY3J3LS13 LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE0ICAgIDEgL2RldiAg ICAgICAgMTY4IGNydy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAx MTcxNCAgICAyIC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAg RmFoQ29yZV83OC5leGUgMTE3MTQgICAgMyAvdXNyICAgICA2NTk0NjEgLXJ3LXItLXItLSAgIDQ5 MDE2IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE0ICAgIDQgL3VzciAgICAgNjU5NTAz IC1yd3hyLXgtLS0gICAgNTA0NCAgdwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNCAgICA1 KiBwaXBlIGZmZmZmZjAwMDUxNDdiMjAgPC0+IGZmZmZmZjAwMDUxNDdjNzAgICAgICAwIHJ3Cm1h dGhldXMgIEZhaENvcmVfNzguZXhlIDExNzE0ICAgIDYqIHBpcGUgZmZmZmZmMDAwNTE0N2M3MCA8 LT4gZmZmZmZmMDAwNTE0N2IyMCAgICAgIDAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3 MTQgICAgNyAvdXNyICAgICA2NTk1NDcgLXJ3LXItLXItLSAgIDMzNDM0ICB3Cm1hdGhldXMgIEZh aENvcmVfNzguZXhlIDExNzE0ICAgIDggL3VzciAgICAgNjU5NTA5IC1ydy1yLS1yLS0gICAgICAg MCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNCAgICA5IC91c3IgICAgIDY1OTUzOSAt cnctci0tci0tICAgICAgIDAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTQgICAxMCAv dXNyICAgICA2NTk1NDQgLXJ3LXItLXItLSAgICA1MTk2IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzgu ZXhlIDExNzE0ICAgMTEgL3VzciAgICAgNjU5NTEzIC1ydy1yLS1yLS0gICAgICAgMCBydwptYXRo ZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxNCAgIDEyIC91c3IgICAgIDY1OTUxMSAtcnctci0tci0t ICAgMTE3ODAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTMgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzEz ICAgd2QgL3VzciAgICAgNjU5NzQ5IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhD b3JlXzc4LmV4ZSAxMTcxMyB0ZXh0IC91c3IgICAgIDY1OTQ4MyAtcnd4ci14LS0tICAzNDM1Mjk2 ICByCm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzEzICAgIDAgL2RldiAgICAgICAgMTY4IGNy dy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxMyAgICAxIC9k ZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5l eGUgMTE3MTMgICAgMiAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhl dXMgIEZhaENvcmVfNzguZXhlIDExNzEzICAgIDMgL3VzciAgICAgNjU5NDYxIC1ydy1yLS1yLS0g ICA0OTAxNiBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxMyAgICA0IC91c3IgICAgIDY1 OTUwMyAtcnd4ci14LS0tICAgIDUwNDQgIHcKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTMg ICAgNSogcGlwZSBmZmZmZmYwMDA1MTQ3YjIwIDwtPiBmZmZmZmYwMDA1MTQ3YzcwICAgICAgMCBy dwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTcxMyAgICA2KiBwaXBlIGZmZmZmZjAwMDUxNDdj NzAgPC0+IGZmZmZmZjAwMDUxNDdiMjAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhl IDExNzEzICAgIDcgL3VzciAgICAgNjU5NTQ3IC1ydy1yLS1yLS0gICAzMzQzNCAgdwptYXRoZXVz ICBGYWhDb3JlXzc4LmV4ZSAxMTcxMyAgICA4IC91c3IgICAgIDY1OTUwOSAtcnctci0tci0tICAg ICAgIDAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTMgICAgOSAvdXNyICAgICA2NTk1 MzkgLXJ3LXItLXItLSAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNzEzICAg MTAgL3VzciAgICAgNjU5NTQ0IC1ydy1yLS1yLS0gICAgNTE5NiBydwptYXRoZXVzICBGYWhDb3Jl Xzc4LmV4ZSAxMTcxMyAgIDExIC91c3IgICAgIDY1OTUxMyAtcnctci0tci0tICAgICAgIDAgcncK bWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE3MTMgICAxMiAvdXNyICAgICA2NTk1MTEgLXJ3LXIt LXItLSAgIDExNzgwIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgMTE3MTIgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYgICAgICAgMTE3MTIgICB3 ZCAvdXNyICAgICA2NTk3NDkgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYgICAg ICAgMTE3MTIgdGV4dCAvdXNyICAgICA2NTk3OTAgLXJ3eC0tLS0tLSAgMjUyNjc2ICByCm1hdGhl dXMgIGZhaDYgICAgICAgMTE3MTIgICAgMCAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0 cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgMTE3MTIgICAgMSAvZGV2ICAgICAgICAxNjggY3J3 LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgMTE3MTIgICAgMiAvZGV2ICAg ICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgMTE3MTIg ICAgMyAvdXNyICAgICA2NTk0NjEgLXJ3LXItLXItLSAgIDQ5MDE2IHJ3Cm1hdGhldXMgIGZhaDYg ICAgICAgMTE3MTIgICAgNCAvdXNyICAgICA2NTk1MDMgLXJ3eHIteC0tLSAgICA1MDQ0ICByCm1h dGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk4IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhy LXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5OCAgIHdkIC91c3IgICAg IDY1OTc5NiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2 OTggdGV4dCAvdXNyICAgICA2NTk0NTcgLXJ3eHIteC0tLSAgMzQzNTI5NiAgcgptYXRoZXVzICBG YWhDb3JlXzc4LmV4ZSAxMTY5OCAgICAwIC9kZXYgICAgICAgIDE3NCBjcnctLXctLS0tICAgcHRz LzQgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTggICAgMSAvZGV2ICAgICAgICAxNzQg Y3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk4ICAgIDIg L2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBGYWhDb3JlXzc4 LmV4ZSAxMTY5OCAgICAzIC91c3IgICAgIDY1OTQ2NyAtcnctci0tci0tICAgNDg0NzAgcncKbWF0 aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTggICAgNCAvdXNyICAgICA2NTk0NzcgLXJ3eHIteC0t LSAgICA1MTEwICB3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk4ICAgIDUqIHBpcGUgZmZm ZmZmMDAwMWJkMjJjOCA8LT4gZmZmZmZmMDAwMWJkMjQxOCAgICAgIDAgcncKbWF0aGV1cyAgRmFo Q29yZV83OC5leGUgMTE2OTggICAgNiogcGlwZSBmZmZmZmYwMDAxYmQyNDE4IDwtPiBmZmZmZmYw MDAxYmQyMmM4ICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5OCAgICA3IC91 c3IgICAgIDY1OTUzMCAtcnctci0tci0tICAgMzM3NDIgIHcKbWF0aGV1cyAgRmFoQ29yZV83OC5l eGUgMTE2OTggICAgOCAvdXNyICAgICA2NTk0ODAgLXJ3LXItLXItLSAgICAgICAwIHJ3Cm1hdGhl dXMgIEZhaENvcmVfNzguZXhlIDExNjk4ICAgIDkgL3VzciAgICAgNjU5NDg3IC1ydy1yLS1yLS0g ICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5OCAgIDEwIC91c3IgICAgIDY1 OTQ5MyAtcnctci0tci0tICAgIDUxOTYgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTgg ICAxMSAvdXNyICAgICA2NTk0ODUgLXJ3LXItLXItLSAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENv cmVfNzguZXhlIDExNjk4ICAgMTIgL3VzciAgICAgNjU5NDg0IC1ydy1yLS1yLS0gICAxMjMyNCBy dwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NyByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTcgICB3ZCAvdXNy ICAgICA2NTk3OTYgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIEZhaENvcmVfNzguZXhl IDExNjk3IHRleHQgL3VzciAgICAgNjU5NDU3IC1yd3hyLXgtLS0gIDM0MzUyOTYgIHIKbWF0aGV1 cyAgRmFoQ29yZV83OC5leGUgMTE2OTcgICAgMCAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAg IHB0cy80IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk3ICAgIDEgL2RldiAgICAgICAg MTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NyAg ICAyIC9kZXYgICAgICAgIDE3NCBjcnctLXctLS0tICAgcHRzLzQgcncKbWF0aGV1cyAgRmFoQ29y ZV83OC5leGUgMTE2OTcgICAgMyAvdXNyICAgICA2NTk0NjcgLXJ3LXItLXItLSAgIDQ4NDcwIHJ3 Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk3ICAgIDQgL3VzciAgICAgNjU5NDc3IC1yd3hy LXgtLS0gICAgNTExMCAgdwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NyAgICA1KiBwaXBl IGZmZmZmZjAwMDFiZDIyYzggPC0+IGZmZmZmZjAwMDFiZDI0MTggICAgICAwIHJ3Cm1hdGhldXMg IEZhaENvcmVfNzguZXhlIDExNjk3ICAgIDYqIHBpcGUgZmZmZmZmMDAwMWJkMjQxOCA8LT4gZmZm ZmZmMDAwMWJkMjJjOCAgICAgIDAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTcgICAg NyAvdXNyICAgICA2NTk1MzAgLXJ3LXItLXItLSAgIDMzNzQyICB3Cm1hdGhldXMgIEZhaENvcmVf NzguZXhlIDExNjk3ICAgIDggL3VzciAgICAgNjU5NDgwIC1ydy1yLS1yLS0gICAgICAgMCBydwpt YXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NyAgICA5IC91c3IgICAgIDY1OTQ4NyAtcnctci0t ci0tICAgICAgIDAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTcgICAxMCAvdXNyICAg ICA2NTk0OTMgLXJ3LXItLXItLSAgICA1MTk2IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDEx Njk3ICAgMTEgL3VzciAgICAgNjU5NDg1IC1ydy1yLS1yLS0gICAgICAgMCBydwptYXRoZXVzICBG YWhDb3JlXzc4LmV4ZSAxMTY5NyAgIDEyIC91c3IgICAgIDY1OTQ4NCAtcnctci0tci0tICAgMTIz MjQgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTYgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk2ICAgd2Qg L3VzciAgICAgNjU5Nzk2IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhDb3JlXzc4 LmV4ZSAxMTY5NiB0ZXh0IC91c3IgICAgIDY1OTQ1NyAtcnd4ci14LS0tICAzNDM1Mjk2ICByCm1h dGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk2ICAgIDAgL2RldiAgICAgICAgMTc0IGNydy0tdy0t LS0gICBwdHMvNCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NiAgICAxIC9kZXYgICAg ICAgIDE3NCBjcnctLXctLS0tICAgcHRzLzQgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2 OTYgICAgMiAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIEZh aENvcmVfNzguZXhlIDExNjk2ICAgIDMgL3VzciAgICAgNjU5NDY3IC1ydy1yLS1yLS0gICA0ODQ3 MCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NiAgICA0IC91c3IgICAgIDY1OTQ3NyAt cnd4ci14LS0tICAgIDUxMTAgIHcKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTYgICAgNSog cGlwZSBmZmZmZmYwMDAxYmQyMmM4IDwtPiBmZmZmZmYwMDAxYmQyNDE4ICAgICAgMCBydwptYXRo ZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NiAgICA2KiBwaXBlIGZmZmZmZjAwMDFiZDI0MTggPC0+ IGZmZmZmZjAwMDFiZDIyYzggICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk2 ICAgIDcgL3VzciAgICAgNjU5NTMwIC1ydy1yLS1yLS0gICAzMzc0MiAgdwptYXRoZXVzICBGYWhD b3JlXzc4LmV4ZSAxMTY5NiAgICA4IC91c3IgICAgIDY1OTQ4MCAtcnctci0tci0tICAgICAgIDAg cncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTYgICAgOSAvdXNyICAgICA2NTk0ODcgLXJ3 LXItLXItLSAgICAgICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk2ICAgMTAgL3Vz ciAgICAgNjU5NDkzIC1ydy1yLS1yLS0gICAgNTE5NiBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4 ZSAxMTY5NiAgIDExIC91c3IgICAgIDY1OTQ4NSAtcnctci0tci0tICAgICAgIDAgcncKbWF0aGV1 cyAgRmFoQ29yZV83OC5leGUgMTE2OTYgICAxMiAvdXNyICAgICA2NTk0ODQgLXJ3LXItLXItLSAg IDEyMzI0IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk1IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NSAg IHdkIC91c3IgICAgIDY1OTc5NiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgRmFoQ29y ZV83OC5leGUgMTE2OTUgdGV4dCAvdXNyICAgICA2NTk0NTcgLXJ3eHIteC0tLSAgMzQzNTI5NiAg cgptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NSAgICAwIC9kZXYgICAgICAgIDE3NCBjcnct LXctLS0tICAgcHRzLzQgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTUgICAgMSAvZGV2 ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhl IDExNjk1ICAgIDIgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVz ICBGYWhDb3JlXzc4LmV4ZSAxMTY5NSAgICAzIC91c3IgICAgIDY1OTQ2NyAtcnctci0tci0tICAg NDg0NzAgcncKbWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTUgICAgNCAvdXNyICAgICA2NTk0 NzcgLXJ3eHIteC0tLSAgICA1MTEwICB3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk1ICAg IDUqIHBpcGUgZmZmZmZmMDAwMWJkMjJjOCA8LT4gZmZmZmZmMDAwMWJkMjQxOCAgICAgIDAgcncK bWF0aGV1cyAgRmFoQ29yZV83OC5leGUgMTE2OTUgICAgNiogcGlwZSBmZmZmZmYwMDAxYmQyNDE4 IDwtPiBmZmZmZmYwMDAxYmQyMmM4ICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAx MTY5NSAgICA3IC91c3IgICAgIDY1OTUzMCAtcnctci0tci0tICAgMzM3NDIgIHcKbWF0aGV1cyAg RmFoQ29yZV83OC5leGUgMTE2OTUgICAgOCAvdXNyICAgICA2NTk0ODAgLXJ3LXItLXItLSAgICAg ICAwIHJ3Cm1hdGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk1ICAgIDkgL3VzciAgICAgNjU5NDg3 IC1ydy1yLS1yLS0gICAgICAgMCBydwptYXRoZXVzICBGYWhDb3JlXzc4LmV4ZSAxMTY5NSAgIDEw IC91c3IgICAgIDY1OTQ5MyAtcnctci0tci0tICAgIDUxOTYgcncKbWF0aGV1cyAgRmFoQ29yZV83 OC5leGUgMTE2OTUgICAxMSAvdXNyICAgICA2NTk0ODUgLXJ3LXItLXItLSAgICAgICAwIHJ3Cm1h dGhldXMgIEZhaENvcmVfNzguZXhlIDExNjk1ICAgMTIgL3VzciAgICAgNjU5NDg0IC1ydy1yLS1y LS0gICAxMjMyNCBydwptYXRoZXVzICBmYWg2ICAgICAgIDExNjk0IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBmYWg2ICAgICAgIDExNjk0ICAgd2Qg L3VzciAgICAgNjU5Nzk2IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBmYWg2ICAgICAg IDExNjk0IHRleHQgL3VzciAgICAgNjU5ODM3IC1yd3gtLS0tLS0gIDI1MjY3NiAgcgptYXRoZXVz ICBmYWg2ICAgICAgIDExNjk0ICAgIDAgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMv NCBydwptYXRoZXVzICBmYWg2ICAgICAgIDExNjk0ICAgIDEgL2RldiAgICAgICAgMTc0IGNydy0t dy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgIDExNjk0ICAgIDIgL2RldiAgICAg ICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgIDExNjk0ICAg IDMgL3VzciAgICAgNjU5NDY3IC1ydy1yLS1yLS0gICA0ODQ3MCBydwptYXRoZXVzICBmYWg2ICAg ICAgIDExNjk0ICAgIDQgL3VzciAgICAgNjU5NDc3IC1yd3hyLXgtLS0gICAgNTExMCAgcgptYXRo ZXVzICBmYWg2ICAgICAgICAxOTYxIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTYxICAgd2QgL3VzciAgICAgNjU5Nzk2IGRy d3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTYxIHRleHQgL3VzciAg ICAgNjU5ODM3IC1yd3gtLS0tLS0gIDI1MjY3NiAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTYx ICAgIDAgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2 ICAgICAgICAxOTYxICAgIDEgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwpt YXRoZXVzICBmYWg2ICAgICAgICAxOTYxICAgIDIgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0g ICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTYxICAgIDMgL3VzciAgICAgNjU5NDY3 IC1ydy1yLS1yLS0gICA0ODQ3MCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTYxICAgIDQgL3Vz ciAgICAgNjU5NDc3IC1yd3hyLXgtLS0gICAgNTExMCAgcgptYXRoZXVzICBmYWg2ICAgICAgICAx OTYwIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBm YWg2ICAgICAgICAxOTYwICAgd2QgL3VzciAgICAgNjU5Nzk2IGRyd3hyLXhyLXggICAgIDUxMiAg cgptYXRoZXVzICBmYWg2ICAgICAgICAxOTYwIHRleHQgL3VzciAgICAgNjU5ODM3IC1yd3gtLS0t LS0gIDI1MjY3NiAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTYwICAgIDAgL2RldiAgICAgICAg MTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTYwICAgIDEg L2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAg ICAxOTYwICAgIDIgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVz ICBmYWg2ICAgICAgICAxOTYwICAgIDMgL3VzciAgICAgNjU5NDY3IC1ydy1yLS1yLS0gICA0ODQ3 MCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTYwICAgIDQgL3VzciAgICAgNjU5NDc3IC1yd3hy LXgtLS0gICAgNTExMCAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTU5IHJvb3QgLyAgICAgICAg ICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBmYWg2ICAgICAgICAxOTU5ICAg d2QgL3VzciAgICAgNjU5Nzk2IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBmYWg2ICAg ICAgICAxOTU5IHRleHQgL3VzciAgICAgNjU5ODM3IC1yd3gtLS0tLS0gIDI1MjY3NiAgcgptYXRo ZXVzICBmYWg2ICAgICAgICAxOTU5ICAgIDAgL2RldiAgICAgICAgMTc0IGNydy0tdy0tLS0gICBw dHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTU5ICAgIDEgL2RldiAgICAgICAgMTc0IGNy dy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTU5ICAgIDIgL2RldiAg ICAgICAgMTc0IGNydy0tdy0tLS0gICBwdHMvNCBydwptYXRoZXVzICBmYWg2ICAgICAgICAxOTU5 ICAgIDMgL3VzciAgICAgNjU5NDY3IC1ydy1yLS1yLS0gICA0ODQ3MCBydwptYXRoZXVzICBmYWg2 ICAgICAgICAxOTU5ICAgIDQgL3VzciAgICAgNjU5NDc3IC1yd3hyLXgtLS0gICAgNTExMCAgcgpt YXRoZXVzICBiYXNoICAgICAgICAxOTU4IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXgg ICAgIDUxMiAgcgptYXRoZXVzICBiYXNoICAgICAgICAxOTU4ICAgd2QgL3VzciAgICAgNjU5Nzk2 IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBiYXNoICAgICAgICAxOTU4IHRleHQgL3Vz ciAgICAgMTQ0MzM0MyAtcnd4ci14ci14ICA3MzIwNjQgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAg MTk1OCAgICAwIC9kZXYgICAgICAgIDE3NCBjcnctLXctLS0tICAgcHRzLzQgcncKbWF0aGV1cyAg YmFzaCAgICAgICAgMTk1OCAgICAxIC9kZXYgICAgICAgIDE3NCBjcnctLXctLS0tICAgcHRzLzQg cncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTk1OCAgICAyIC9kZXYgICAgICAgIDE3NCBjcnctLXct LS0tICAgcHRzLzQgcncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTk1OCAgMjU0IC91c3IgICAgIDY1 OTY2MSAtcnd4ci14ci14ICAgICAgMzUgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAgMTk1OCAgMjU1 IC9kZXYgICAgICAgIDE3NCBjcnctLXctLS0tICAgcHRzLzQgcncKbWF0aGV1cyAgYmFzaCAgICAg ICAgMTk1NiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1 cyAgYmFzaCAgICAgICAgMTk1NiAgIHdkIC91c3IgICAgIDY1OTc5NiBkcnd4ci14ci14ICAgICA1 MTIgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAgMTk1NiB0ZXh0IC91c3IgICAgIDE0NDMzNDMgLXJ3 eHIteHIteCAgNzMyMDY0ICByCm1hdGhldXMgIGJhc2ggICAgICAgIDE5NTYgICAgMCAvZGV2ICAg ICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIGJhc2ggICAgICAgIDE5NTYg ICAgMSAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIGJhc2gg ICAgICAgIDE5NTYgICAgMiAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1h dGhldXMgIGJhc2ggICAgICAgIDE5NTYgIDI1NSAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAg IHB0cy80IHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE5NTUgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIHNoICAgICAgICAgIDE5NTUgICB3ZCAvdXNy ICAgICA2MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICByCm1hdGhldXMgIHNoICAgICAgICAgIDE5 NTUgdGV4dCAvICAgICAgICAgICAxNDAgLXIteHIteHIteCAgMTMzMTIwICByCm1hdGhldXMgIHNo ICAgICAgICAgIDE5NTUgICAgMCAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3 Cm1hdGhldXMgIHNoICAgICAgICAgIDE5NTUgICAgMSAvZGV2ICAgICAgICAxNzQgY3J3LS13LS0t LSAgIHB0cy80IHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE5NTUgICAgMiAvZGV2ICAgICAgICAx NzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE5NTUgICAxMCAv ZGV2ICAgICAgICAxNzQgY3J3LS13LS0tLSAgIHB0cy80IHJ3Cm1hdGhldXMgIGZhaDYgICAgICAg IDE5NTIgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMg IGZhaDYgICAgICAgIDE5NTIgICB3ZCAvdXNyICAgICA2NTk3NDkgZHJ3eHIteHIteCAgICAgNTEy ICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTIgdGV4dCAvdXNyICAgICA2NTk3OTAgLXJ3eC0t LS0tLSAgMjUyNjc2ICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTIgICAgMCAvZGV2ICAgICAg ICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTIgICAg MSAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAg ICAgIDE5NTIgICAgMiAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhl dXMgIGZhaDYgICAgICAgIDE5NTIgICAgMyAvdXNyICAgICA2NTk0NjEgLXJ3LXItLXItLSAgIDQ5 MDE2IHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTIgICAgNCAvdXNyICAgICA2NTk1MDMgLXJ3 eHIteC0tLSAgICA1MDQ0ICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTEgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTEg ICB3ZCAvdXNyICAgICA2NTk3NDkgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYg ICAgICAgIDE5NTEgdGV4dCAvdXNyICAgICA2NTk3OTAgLXJ3eC0tLS0tLSAgMjUyNjc2ICByCm1h dGhldXMgIGZhaDYgICAgICAgIDE5NTEgICAgMCAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAg IHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTEgICAgMSAvZGV2ICAgICAgICAxNjgg Y3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTEgICAgMiAvZGV2 ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5 NTEgICAgMyAvdXNyICAgICA2NTk0NjEgLXJ3LXItLXItLSAgIDQ5MDE2IHJ3Cm1hdGhldXMgIGZh aDYgICAgICAgIDE5NTEgICAgNCAvdXNyICAgICA2NTk1MDMgLXJ3eHIteC0tLSAgICA1MDQ0ICBy Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgICB3ZCAvdXNyICAgICA2NTk3 NDkgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgdGV4dCAv dXNyICAgICA2NTk3OTAgLXJ3eC0tLS0tLSAgMjUyNjc2ICByCm1hdGhldXMgIGZhaDYgICAgICAg IDE5NTAgICAgMCAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMg IGZhaDYgICAgICAgIDE5NTAgICAgMSAvZGV2ICAgICAgICAxNjggY3J3LS13LS0tLSAgIHB0cy8z IHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgICAgMiAvZGV2ICAgICAgICAxNjggY3J3LS13 LS0tLSAgIHB0cy8zIHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgICAgMyAvdXNyICAgICA2 NTk0NjEgLXJ3LXItLXItLSAgIDQ5MDE2IHJ3Cm1hdGhldXMgIGZhaDYgICAgICAgIDE5NTAgICAg NCAvdXNyICAgICA2NTk1MDMgLXJ3eHIteC0tLSAgICA1MDQ0ICByCm1hdGhldXMgIGJhc2ggICAg ICAgIDE5NDkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhl dXMgIGJhc2ggICAgICAgIDE5NDkgICB3ZCAvdXNyICAgICA2NTk3NDkgZHJ3eHIteHIteCAgICAg NTEyICByCm1hdGhldXMgIGJhc2ggICAgICAgIDE5NDkgdGV4dCAvdXNyICAgICAxNDQzMzQzIC1y d3hyLXhyLXggIDczMjA2NCAgcgptYXRoZXVzICBiYXNoICAgICAgICAxOTQ5ICAgIDAgL2RldiAg ICAgICAgMTY4IGNydy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBiYXNoICAgICAgICAxOTQ5 ICAgIDEgL2RldiAgICAgICAgMTY4IGNydy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBiYXNo ICAgICAgICAxOTQ5ICAgIDIgL2RldiAgICAgICAgMTY4IGNydy0tdy0tLS0gICBwdHMvMyBydwpt YXRoZXVzICBiYXNoICAgICAgICAxOTQ5ICAyNTQgL3VzciAgICAgNjU5NzgwIC1yd3hyLXhyLXgg ICAgICAzNSAgcgptYXRoZXVzICBiYXNoICAgICAgICAxOTQ5ICAyNTUgL2RldiAgICAgICAgMTY4 IGNydy0tdy0tLS0gICBwdHMvMyBydwptYXRoZXVzICBiYXNoICAgICAgICAxODcxIHJvb3QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBiYXNoICAgICAgICAx ODcxICAgd2QgL3VzciAgICAgNjU5NzQ5IGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBi YXNoICAgICAgICAxODcxIHRleHQgL3VzciAgICAgMTQ0MzM0MyAtcnd4ci14ci14ICA3MzIwNjQg IHIKbWF0aGV1cyAgYmFzaCAgICAgICAgMTg3MSAgICAwIC9kZXYgICAgICAgIDE2OCBjcnctLXct LS0tICAgcHRzLzMgcncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTg3MSAgICAxIC9kZXYgICAgICAg IDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTg3MSAgICAy IC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgYmFzaCAgICAg ICAgMTg3MSAgMjU1IC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1 cyAgc2ggICAgICAgICAgMTg3MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHIKbWF0aGV1cyAgc2ggICAgICAgICAgMTg3MCAgIHdkIC91c3IgICAgIDYxMjM1MyBkcnd4 ci14ci14ICAgIDEwMjQgIHIKbWF0aGV1cyAgc2ggICAgICAgICAgMTg3MCB0ZXh0IC8gICAgICAg ICAgIDE0MCAtci14ci14ci14ICAxMzMxMjAgIHIKbWF0aGV1cyAgc2ggICAgICAgICAgMTg3MCAg ICAwIC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgc2ggICAg ICAgICAgMTg3MCAgICAxIC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAgcHRzLzMgcncKbWF0 aGV1cyAgc2ggICAgICAgICAgMTg3MCAgICAyIC9kZXYgICAgICAgIDE2OCBjcnctLXctLS0tICAg cHRzLzMgcncKbWF0aGV1cyAgc2ggICAgICAgICAgMTg3MCAgIDEwIC9kZXYgICAgICAgIDE2OCBj cnctLXctLS0tICAgcHRzLzMgcncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTg1OCByb290IC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAgMTg1 OCAgIHdkIC91c3IgICAgIDYxMjM1MyBkcnd4ci14ci14ICAgIDEwMjQgIHIKbWF0aGV1cyAgYmFz aCAgICAgICAgMTg1OCB0ZXh0IC91c3IgICAgIDE0NDMzNDMgLXJ3eHIteHIteCAgNzMyMDY0ICBy Cm1hdGhldXMgIGJhc2ggICAgICAgIDE4NTggICAgMCAvZGV2ICAgICAgICAxNjcgY3J3LS13LS0t LSAgIHB0cy8yIHJ3Cm1hdGhldXMgIGJhc2ggICAgICAgIDE4NTggICAgMSAvZGV2ICAgICAgICAx NjcgY3J3LS13LS0tLSAgIHB0cy8yIHJ3Cm1hdGhldXMgIGJhc2ggICAgICAgIDE4NTggICAgMiAv ZGV2ICAgICAgICAxNjcgY3J3LS13LS0tLSAgIHB0cy8yIHJ3Cm1hdGhldXMgIGJhc2ggICAgICAg IDE4NTggIDI1NSAvZGV2ICAgICAgICAxNjcgY3J3LS13LS0tLSAgIHB0cy8yIHJ3Cm1hdGhldXMg IHNoICAgICAgICAgIDE4NTcgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCm1hdGhldXMgIHNoICAgICAgICAgIDE4NTcgICB3ZCAvdXNyICAgICA2MTIzNTMgZHJ3eHIt eHIteCAgICAxMDI0ICByCm1hdGhldXMgIHNoICAgICAgICAgIDE4NTcgdGV4dCAvICAgICAgICAg ICAxNDAgLXIteHIteHIteCAgMTMzMTIwICByCm1hdGhldXMgIHNoICAgICAgICAgIDE4NTcgICAg MCAvZGV2ICAgICAgICAxNjcgY3J3LS13LS0tLSAgIHB0cy8yIHJ3Cm1hdGhldXMgIHNoICAgICAg ICAgIDE4NTcgICAgMSAvZGV2ICAgICAgICAxNjcgY3J3LS13LS0tLSAgIHB0cy8yIHJ3Cm1hdGhl dXMgIHNoICAgICAgICAgIDE4NTcgICAgMiAvZGV2ICAgICAgICAxNjcgY3J3LS13LS0tLSAgIHB0 cy8yIHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE4NTcgICAxMCAvZGV2ICAgICAgICAxNjcgY3J3 LS13LS0tLSAgIHB0cy8yIHJ3CnJvb3QgICAgIHNjcmVlbiAgICAgIDE4NTUgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNjcmVlbiAgICAgIDE4NTUg ICB3ZCAvdXNyICAgICA2MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHNjcmVl biAgICAgIDE4NTUgdGV4dCAvdXNyICAgICAxNDQzMzEyIC1yd3NyLXhyLXggIDMyOTc4NCAgcgpy b290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDAgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0g ICAgbnVsbCAgcgpyb290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDEgL2RldiAgICAgICAgICA5 IGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDIgL2Rl diAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBzY3JlZW4gICAgICAx ODU1ICAgIDMgL3RtcCAgICAgIDQ5MzQ5IHBydy0tLS0tLS0gICAgICAgMCAgcgpyb290ICAgICBz Y3JlZW4gICAgICAxODU1ICAgIDUgL3ZhciAgICAgIDcwNjY0IC1ydy1yLS1yLS0gICAxMjE4OCBy dwpyb290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDYgLyAgICAgICAgIDQ5NDIzIC1ydy1yLS1y LS0gICAgNzY1MyAgcgpyb290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDcqIHBzZXVkby10ZXJt aW5hbCBtYXN0ZXIgICAgICBwdHMvMiBydwpyb290ICAgICBzY3JlZW4gICAgICAxODU1ICAgIDgq IHBzZXVkby10ZXJtaW5hbCBtYXN0ZXIgICAgICBwdHMvMyBydwpyb290ICAgICBzY3JlZW4gICAg ICAxODU1ICAgIDkqIHBzZXVkby10ZXJtaW5hbCBtYXN0ZXIgICAgICBwdHMvNCBydwptYXRoZXVz ICBna3JlbGxtICAgICAxNzU5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUx MiAgcgptYXRoZXVzICBna3JlbGxtICAgICAxNzU5ICAgd2QgL3VzciAgICAgNjEyMzUzIGRyd3hy LXhyLXggICAgMTAyNCAgcgptYXRoZXVzICBna3JlbGxtICAgICAxNzU5IHRleHQgL3VzciAgICAg MTQzODgyNiAtcnd4ci14ci14ICA4MzExNzYgIHIKbWF0aGV1cyAgZ2tyZWxsbSAgICAgMTc1OSAg ICAwIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0aGV1cyAgZ2tyZWxs bSAgICAgMTc1OSAgICAxIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0 aGV1cyAgZ2tyZWxsbSAgICAgMTc1OSAgICAyIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAg dHR5djAgcncKbWF0aGV1cyAgZ2tyZWxsbSAgICAgMTc1OSAgICAzKiBsb2NhbCBzdHJlYW0gZmZm ZmZmMDAwNTE4OWI0MCA8LT4gZmZmZmZmMDAwNTE4OWMzMAptYXRoZXVzICBna3JlbGxtICAgICAx NzU5ICAgIDQqIHBpcGUgZmZmZmZmMDAwMWJkMjAwMCA8LT4gZmZmZmZmMDAwMWJkMjE1MCAgICAg IDAgcncKbWF0aGV1cyAgZ2tyZWxsbSAgICAgMTc1OSAgICA1KiBwaXBlIGZmZmZmZjAwMDFiZDIx NTAgPC0+IGZmZmZmZjAwMDFiZDIwMDAgICAgICAwIHJ3Cm1hdGhldXMgIHdtYWtlciAgICAgIDE3 NTYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIHdt YWtlciAgICAgIDE3NTYgICB3ZCAvdXNyICAgICA2MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICBy Cm1hdGhldXMgIHdtYWtlciAgICAgIDE3NTYgdGV4dCAvdXNyICAgICAxNDQzMjc2IC1yLXhyLXhy LXggIDYxMjg4MCAgcgptYXRoZXVzICB3bWFrZXIgICAgICAxNzU2ICAgIDAgL2RldiAgICAgICAg IDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICB3bWFrZXIgICAgICAxNzU2ICAgIDEg L2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICB3bWFrZXIgICAg ICAxNzU2ICAgIDIgL2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVz ICB3bWFrZXIgICAgICAxNzU2ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmYwMDA1MTg5NzgwIDwt PiBmZmZmZmYwMDA1MThhZTEwCm1hdGhldXMgIHdtYWtlciAgICAgIDE3NTUgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIHdtYWtlciAgICAgIDE3NTUg ICB3ZCAvdXNyICAgICA2MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICByCm1hdGhldXMgIHdtYWtl ciAgICAgIDE3NTUgdGV4dCAvdXNyICAgICAxNDQzMjc2IC1yLXhyLXhyLXggIDYxMjg4MCAgcgpt YXRoZXVzICB3bWFrZXIgICAgICAxNzU1ICAgIDAgL2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0g ICB0dHl2MCBydwptYXRoZXVzICB3bWFrZXIgICAgICAxNzU1ICAgIDEgL2RldiAgICAgICAgIDU5 IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICB3bWFrZXIgICAgICAxNzU1ICAgIDIgL2Rl diAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICBzaCAgICAgICAgICAx NzU0IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBz aCAgICAgICAgICAxNzU0ICAgd2QgL3VzciAgICAgNjEyMzUzIGRyd3hyLXhyLXggICAgMTAyNCAg cgptYXRoZXVzICBzaCAgICAgICAgICAxNzU0IHRleHQgLyAgICAgICAgICAgMTQwIC1yLXhyLXhy LXggIDEzMzEyMCAgcgptYXRoZXVzICBzaCAgICAgICAgICAxNzU0ICAgIDAgL2RldiAgICAgICAg IDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICBzaCAgICAgICAgICAxNzU0ICAgIDEg L2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICBzaCAgICAgICAg ICAxNzU0ICAgIDIgL2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVz ICBzaCAgICAgICAgICAxNzU0ICAgMTAgL3VzciAgICAgNjE0MzI1IC1ydy1yLS1yLS0gICAgICAg NyAgcgpyb290ICAgICBYb3JnICAgICAgICAxNzQ5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgIDUxMiAgcgpyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAgd2QgL3VzciAgICAg NjEyMzUzIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBYb3JnICAgICAgICAxNzQ5IHRl eHQgL3VzciAgICAgMTQ0Nzc0OSAtci1zci14ci14ICAxNjgwNzIwICByCnJvb3QgICAgIFhvcmcg ICAgICAgIDE3NDkgICAgMCAvdmFyICAgICAgMjM1NTMgLXJ3LXItLXItLSAgIDIwMzMxICB3CnJv b3QgICAgIFhvcmcgICAgICAgIDE3NDkgICAgMSogaW50ZXJuZXQ2IHN0cmVhbSB0Y3AgZmZmZmZm MDAwNTJhNzAwMApyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAgIDIgL2RldiAgICAgICAgIDU5 IGNydy0tLS0tLS0gICB0dHl2MCBydwpyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAgIDMqIGlu dGVybmV0IHN0cmVhbSB0Y3AgZmZmZmZmMDAwNTJhNzJlOApyb290ICAgICBYb3JnICAgICAgICAx NzQ5ICAgIDQqIGxvY2FsIHN0cmVhbSBmZmZmZmYwMDA1MTg5MmQwCnJvb3QgICAgIFhvcmcgICAg ICAgIDE3NDkgICAgNSAvdXNyICAgICAxNzI0NTc0IC1yLS1yLS1yLS0gICAyOTk5NyAgcgpyb290 ICAgICBYb3JnICAgICAgICAxNzQ5ICAgIDYgL2RldiAgICAgICAgIDY3IGNydy0tLS0tLS0gICB0 dHl2OCBydwpyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAgIDcgL2RldiAgICAgICAgIDEzIGNy dy1yLS1yLS0gICAgIHBjaSBydwpyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAgIDggL2RldiAg ICAgICAgIDMyIGNydy1yLS0tLS0gICAgIG1lbSBydwpyb290ICAgICBYb3JnICAgICAgICAxNzQ5 ICAgIDkgL2RldiAgICAgICAgIDM0IGNydy0tLS0tLS0gICAgICBpbyBydwpyb290ICAgICBYb3Jn ICAgICAgICAxNzQ5ICAgMTAgL2RldiAgICAgICAgIDM4IGNydy0tLS0tLS0gIGFncGdhcnQgcncK cm9vdCAgICAgWG9yZyAgICAgICAgMTc0OSAgIDExIC9kZXYgICAgICAgIDEzMCBjcnctcnctLS0t ICBkcmkvY2FyZDAgcncKcm9vdCAgICAgWG9yZyAgICAgICAgMTc0OSAgIDEyIC9kZXYgICAgICAg ICAxOCBjcnctLS0tLS0tICBzeXNtb3VzZSBydwpyb290ICAgICBYb3JnICAgICAgICAxNzQ5ICAg MTMqIGxvY2FsIHN0cmVhbSBmZmZmZmYwMDA1MTg5M2MwIDwtPiBmZmZmZmYwMDA1MjVlMWUwCnJv b3QgICAgIFhvcmcgICAgICAgIDE3NDkgICAxNCogbG9jYWwgc3RyZWFtIGZmZmZmZjAwMDUxOGFl MTAgPC0+IGZmZmZmZjAwMDUxODk3ODAKcm9vdCAgICAgWG9yZyAgICAgICAgMTc0OSAgIDE1KiBs b2NhbCBzdHJlYW0gZmZmZmZmMDAwNTE4OWMzMCA8LT4gZmZmZmZmMDAwNTE4OWI0MApyb290ICAg ICBYb3JnICAgICAgICAxNzQ5ICAgMTYqIGxvY2FsIHN0cmVhbSBmZmZmZmYwMDA1MjVlNWEwIDwt PiBmZmZmZmYwMDA1MThhMWUwCm1hdGhldXMgIHhpbml0ICAgICAgIDE3NDggcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCm1hdGhldXMgIHhpbml0ICAgICAgIDE3NDgg ICB3ZCAvdXNyICAgICA2MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICByCm1hdGhldXMgIHhpbml0 ICAgICAgIDE3NDggdGV4dCAvdXNyICAgICAxNDQ3Mjc4IC1yLXhyLXhyLXggICAxNDIwOCAgcgpt YXRoZXVzICB4aW5pdCAgICAgICAxNzQ4ICAgIDAgL2RldiAgICAgICAgIDU5IGNydy0tLS0tLS0g ICB0dHl2MCBydwptYXRoZXVzICB4aW5pdCAgICAgICAxNzQ4ICAgIDEgL2RldiAgICAgICAgIDU5 IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICB4aW5pdCAgICAgICAxNzQ4ICAgIDIgL2Rl diAgICAgICAgIDU5IGNydy0tLS0tLS0gICB0dHl2MCBydwptYXRoZXVzICB4aW5pdCAgICAgICAx NzQ4ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmYwMDA1MjVlMWUwIDwtPiBmZmZmZmYwMDA1MTg5 M2MwCm1hdGhldXMgIHNoICAgICAgICAgIDE3MzAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCm1hdGhldXMgIHNoICAgICAgICAgIDE3MzAgICB3ZCAvdXNyICAgICA2 MTIzNTMgZHJ3eHIteHIteCAgICAxMDI0ICByCm1hdGhldXMgIHNoICAgICAgICAgIDE3MzAgdGV4 dCAvICAgICAgICAgICAxNDAgLXIteHIteHIteCAgMTMzMTIwICByCm1hdGhldXMgIHNoICAgICAg ICAgIDE3MzAgICAgMCAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3Cm1hdGhl dXMgIHNoICAgICAgICAgIDE3MzAgICAgMSAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0 eXYwIHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE3MzAgICAgMiAvZGV2ICAgICAgICAgNTkgY3J3 LS0tLS0tLSAgIHR0eXYwIHJ3Cm1hdGhldXMgIHNoICAgICAgICAgIDE3MzAgICAxMCAvdXNyICAg ICAxNDQ3MjgwIC1yLXhyLXhyLXggICAgNDcwNiAgcgptYXRoZXVzICBiYXNoICAgICAgICAxNzI5 IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgptYXRoZXVzICBiYXNo ICAgICAgICAxNzI5ICAgd2QgL3VzciAgICAgNjEyMzUzIGRyd3hyLXhyLXggICAgMTAyNCAgcgpt YXRoZXVzICBiYXNoICAgICAgICAxNzI5IHRleHQgL3VzciAgICAgMTQ0MzM0MyAtcnd4ci14ci14 ICA3MzIwNjQgIHIKbWF0aGV1cyAgYmFzaCAgICAgICAgMTcyOSAgICAwIC9kZXYgICAgICAgICA1 OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0aGV1cyAgYmFzaCAgICAgICAgMTcyOSAgICAxIC9k ZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0aGV1cyAgYmFzaCAgICAgICAg MTcyOSAgICAyIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0aGV1cyAg YmFzaCAgICAgICAgMTcyOSAgMjU1IC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAg cncKbWF0aGV1cyAgc2ggICAgICAgICAgMTcyNyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKbWF0aGV1cyAgc2ggICAgICAgICAgMTcyNyAgIHdkIC91c3IgICAgIDYx MjM1MyBkcnd4ci14ci14ICAgIDEwMjQgIHIKbWF0aGV1cyAgc2ggICAgICAgICAgMTcyNyB0ZXh0 IC8gICAgICAgICAgIDE0MCAtci14ci14ci14ICAxMzMxMjAgIHIKbWF0aGV1cyAgc2ggICAgICAg ICAgMTcyNyAgICAwIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKbWF0aGV1 cyAgc2ggICAgICAgICAgMTcyNyAgICAxIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5 djAgcncKbWF0aGV1cyAgc2ggICAgICAgICAgMTcyNyAgICAyIC9kZXYgICAgICAgICA1OSBjcnct LS0tLS0tICAgdHR5djAgcncKbWF0aGV1cyAgc2ggICAgICAgICAgMTcyNyAgIDEwIC9kZXYgICAg ICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NSBy b290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkg ICAgICAgMTY4NSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9v dCAgICAgZ2V0dHkgICAgICAgMTY4NSB0ZXh0IC91c3IgICAgICA3MDk5MiAtci14ci14ci14ICAg Mjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NSAgICAwIC9kZXYgICAgICAgICA2NiBj cnctLS0tLS0tICAgdHR5djcgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NSAgICAxIC9kZXYg ICAgICAgICA2NiBjcnctLS0tLS0tICAgdHR5djcgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4 NSAgICAyIC9kZXYgICAgICAgICA2NiBjcnctLS0tLS0tICAgdHR5djcgcncKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTY4NCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NCB0ZXh0IC91c3IgICAgICA3MDk5 MiAtci14ci14ci14ICAgMjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4NCAgICAwIC9k ZXYgICAgICAgICA2NSBjcnctLS0tLS0tICAgdHR5djYgcncKcm9vdCAgICAgZ2V0dHkgICAgICAg MTY4NCAgICAxIC9kZXYgICAgICAgICA2NSBjcnctLS0tLS0tICAgdHR5djYgcncKcm9vdCAgICAg Z2V0dHkgICAgICAgMTY4NCAgICAyIC9kZXYgICAgICAgICA2NSBjcnctLS0tLS0tICAgdHR5djYg cncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MyAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MyB0ZXh0 IC91c3IgICAgICA3MDk5MiAtci14ci14ci14ICAgMjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkgICAg ICAgMTY4MyAgICAwIC9kZXYgICAgICAgICA2NCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTY4MyAgICAxIC9kZXYgICAgICAgICA2NCBjcnctLS0tLS0tICAgdHR5 djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MyAgICAyIC9kZXYgICAgICAgICA2NCBjcnct LS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MiByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MiAg IHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkg ICAgICAgMTY4MiB0ZXh0IC91c3IgICAgICA3MDk5MiAtci14ci14ci14ICAgMjc3NjAgIHIKcm9v dCAgICAgZ2V0dHkgICAgICAgMTY4MiAgICAwIC9kZXYgICAgICAgICA2MyBjcnctLS0tLS0tICAg dHR5djQgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MiAgICAxIC9kZXYgICAgICAgICA2MyBj cnctLS0tLS0tICAgdHR5djQgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MiAgICAyIC9kZXYg ICAgICAgICA2MyBjcnctLS0tLS0tICAgdHR5djQgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4 MSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTY4MSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MSB0ZXh0IC91c3IgICAgICA3MDk5MiAtci14ci14ci14 ICAgMjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MSAgICAwIC9kZXYgICAgICAgICA2 MiBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MSAgICAxIC9k ZXYgICAgICAgICA2MiBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgZ2V0dHkgICAgICAg MTY4MSAgICAyIC9kZXYgICAgICAgICA2MiBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAg Z2V0dHkgICAgICAgMTY4MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIg IHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MCB0ZXh0IC91c3IgICAgICA3 MDk5MiAtci14ci14ci14ICAgMjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY4MCAgICAw IC9kZXYgICAgICAgICA2MSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAg ICAgMTY4MCAgICAxIC9kZXYgICAgICAgICA2MSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTY4MCAgICAyIC9kZXYgICAgICAgICA2MSBjcnctLS0tLS0tICAgdHR5 djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY3OSByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY3OSAgIHdkIC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY3OSB0 ZXh0IC91c3IgICAgICA3MDk5MiAtci14ci14ci14ICAgMjc3NjAgIHIKcm9vdCAgICAgZ2V0dHkg ICAgICAgMTY3OSAgICAwIC9kZXYgICAgICAgICA2MCBjcnctLS0tLS0tICAgdHR5djEgcncKcm9v dCAgICAgZ2V0dHkgICAgICAgMTY3OSAgICAxIC9kZXYgICAgICAgICA2MCBjcnctLS0tLS0tICAg dHR5djEgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTY3OSAgICAyIC9kZXYgICAgICAgICA2MCBj cnctLS0tLS0tICAgdHR5djEgcncKcm9vdCAgICAgbG9naW4gICAgICAgMTY3OCByb290IC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbG9naW4gICAgICAgMTY3 OCAgIHdkIC91c3IgICAgIDYxMjM1MyBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgbG9n aW4gICAgICAgMTY3OCB0ZXh0IC91c3IgICAgICAyNDAzNiAtci1zci14ci14ICAgMjU0MzIgIHIK cm9vdCAgICAgbG9naW4gICAgICAgMTY3OCAgICAwIC9kZXYgICAgICAgICA1OSBjcnctLS0tLS0t ICAgdHR5djAgcncKcm9vdCAgICAgbG9naW4gICAgICAgMTY3OCAgICAxIC9kZXYgICAgICAgICA1 OSBjcnctLS0tLS0tICAgdHR5djAgcncKcm9vdCAgICAgbG9naW4gICAgICAgMTY3OCAgICAyIC9k ZXYgICAgICAgICA1OSBjcnctLS0tLS0tICAgdHR5djAgcncKcm9vdCAgICAgbG9naW4gICAgICAg MTY3OCAgICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmYwMDA1MTg5MWUwIDwtPiBmZmZmZmYwMDA1MThh ODcwCnJvb3QgICAgIGNyb24gICAgICAgIDE2MTcgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCnJvb3QgICAgIGNyb24gICAgICAgIDE2MTcgICB3ZCAvdmFyICAgICAy MTE5NjggZHJ3eHIteC0tLSAgICAgNTEyICByCnJvb3QgICAgIGNyb24gICAgICAgIDE2MTcgdGV4 dCAvdXNyICAgICAxMDE5ODk2IC1yLXhyLXhyLXggICAzOTQ3MiAgcgpyb290ICAgICBjcm9uICAg ICAgICAxNjE3ICAgIDAgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290 ICAgICBjcm9uICAgICAgICAxNjE3ICAgIDEgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAg bnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxNjE3ICAgIDIgL2RldiAgICAgICAgICA5IGNy dy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxNjE3ICAgIDMgL3ZhciAg ICAgIDcwNjkyIC1ydy0tLS0tLS0gICAgICAgNCAgdwpzbW1zcCAgICBzZW5kbWFpbCAgICAxNjEx IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpzbW1zcCAgICBzZW5k bWFpbCAgICAxNjExICAgd2QgL3ZhciAgICAgIDQ3MTExIGRyd3hyd3gtLS0gICAgIDUxMiAgcgpz bW1zcCAgICBzZW5kbWFpbCAgICAxNjExIHRleHQgL3VzciAgICAgIDcwODYyIC1yLXhyLXNyLXgg IDY4OTU3NiAgcgpzbW1zcCAgICBzZW5kbWFpbCAgICAxNjExICAgIDAgL2RldiAgICAgICAgICA5 IGNydy1ydy1ydy0gICAgbnVsbCAgcgpzbW1zcCAgICBzZW5kbWFpbCAgICAxNjExICAgIDEgL2Rl diAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCAgdwpzbW1zcCAgICBzZW5kbWFpbCAgICAx NjExICAgIDIgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCAgdwpzbW1zcCAgICBz ZW5kbWFpbCAgICAxNjExICAgIDMqIGxvY2FsIGRncmFtIGZmZmZmZjAwMDUxOGE2OTAgPC0+IGZm ZmZmZjAwMDUxOGE5NjAKc21tc3AgICAgc2VuZG1haWwgICAgMTYxMSAgICA0IC92YXIgICAgICA0 NzExMyAtcnctLS0tLS0tICAgICAgNTAgIHcKcm9vdCAgICAgc2VuZG1haWwgICAgMTYwNyByb290 IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgc2VuZG1haWwg ICAgMTYwNyAgIHdkIC92YXIgICAgICA0NzEwOCBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgc2VuZG1haWwgICAgMTYwNyB0ZXh0IC91c3IgICAgICA3MDg2MiAtci14ci1zci14ICA2ODk1 NzYgIHIKcm9vdCAgICAgc2VuZG1haWwgICAgMTYwNyAgICAwIC9kZXYgICAgICAgICAgOSBjcnct cnctcnctICAgIG51bGwgIHIKcm9vdCAgICAgc2VuZG1haWwgICAgMTYwNyAgICAxIC9kZXYgICAg ICAgICAgOSBjcnctcnctcnctICAgIG51bGwgIHcKcm9vdCAgICAgc2VuZG1haWwgICAgMTYwNyAg ICAyIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgIHcKcm9vdCAgICAgc2VuZG1h aWwgICAgMTYwNyAgICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmYwMDA1MThhNzgwIDwtPiBmZmZmZmYw MDA1MThhODcwCnJvb3QgICAgIHNlbmRtYWlsICAgIDE2MDcgICAgNCogaW50ZXJuZXQgc3RyZWFt IHRjcCBmZmZmZmYwMDA1MmE3NWQwCnJvb3QgICAgIHNlbmRtYWlsICAgIDE2MDcgICAgNSAvdmFy ICAgICAgNzA2OTAgLXJ3LS0tLS0tLSAgICAgIDc5ICB3CnJvb3QgICAgIHNzaGQgICAgICAgIDE2 MDAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNz aGQgICAgICAgIDE2MDAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy CnJvb3QgICAgIHNzaGQgICAgICAgIDE2MDAgdGV4dCAvdXNyICAgICAxMDEyODM2IC1yLXhyLXhy LXggIDI0NTI3MiAgcgpyb290ICAgICBzc2hkICAgICAgICAxNjAwICAgIDAgL2RldiAgICAgICAg ICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzc2hkICAgICAgICAxNjAwICAgIDEg L2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzc2hkICAgICAg ICAxNjAwICAgIDIgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAg ICBzc2hkICAgICAgICAxNjAwICAgIDMqIGludGVybmV0NiBzdHJlYW0gdGNwIGZmZmZmZjAwMDUy YTg4YjgKcm9vdCAgICAgc3NoZCAgICAgICAgMTYwMCAgICA0KiBpbnRlcm5ldCBzdHJlYW0gdGNw IGZmZmZmZjAwMDUyYTg1ZDAKcm9vdCAgICAgbmZzZCAgICAgICAgMTM3OSByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbmZzZCAgICAgICAgMTM3OSAg IHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbmZzZCAg ICAgICAgMTM3OSB0ZXh0IC91c3IgICAgIDEwMjEwMjYgLXIteHIteHIteCAgIDE3MTg0ICByCnJv b3QgICAgIG5mc2QgICAgICAgIDEzNzkgICAgMCAvZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CnJvb3QgICAgIG5mc2QgICAgICAgIDEzNzkgICAgMSAvZGV2ICAgICAgICAgIDkg Y3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5mc2QgICAgICAgIDEzNzkgICAgMiAvZGV2 ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5mc2QgICAgICAgIDEz Nzggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIG5m c2QgICAgICAgIDEzNzggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy CnJvb3QgICAgIG5mc2QgICAgICAgIDEzNzggdGV4dCAvdXNyICAgICAxMDIxMDI2IC1yLXhyLXhy LXggICAxNzE4NCAgcgpyb290ICAgICBuZnNkICAgICAgICAxMzc4ICAgIDAgL2RldiAgICAgICAg ICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBuZnNkICAgICAgICAxMzc4ICAgIDEg L2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBuZnNkICAgICAg ICAxMzc4ICAgIDIgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAg ICBuZnNkICAgICAgICAxMzc4ICAgIDMqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZmZmZmMDAwNTJh MDAwMApyb290ICAgICBuZnNkICAgICAgICAxMzc4ICAgIDQqIGludGVybmV0NiBzdHJlYW0gdGNw IGZmZmZmZjAwMDUyYThiYTAKcm9vdCAgICAgbW91bnRkICAgICAgMTM3MCByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbW91bnRkICAgICAgMTM3MCAg IHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbW91bnRk ICAgICAgMTM3MCB0ZXh0IC91c3IgICAgIDEwMjA1ODEgLXIteHIteHIteCAgIDQyNzIwICByCnJv b3QgICAgIG1vdW50ZCAgICAgIDEzNzAgICAgMCAvZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CnJvb3QgICAgIG1vdW50ZCAgICAgIDEzNzAgICAgMSAvZGV2ICAgICAgICAgIDkg Y3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdW50ZCAgICAgIDEzNzAgICAgMiAvZGV2 ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdW50ZCAgICAgIDEz NzAgICAgMyAvdmFyICAgICAgNzA2ODggLXJ3LS0tLS0tLSAgICAgICA0ICB3CnJvb3QgICAgIG1v dW50ZCAgICAgIDEzNzAgICAgNSogaW50ZXJuZXQ2IGRncmFtIHVkcCBmZmZmZmYwMDA1MTg4ZDEw CnJvb3QgICAgIG1vdW50ZCAgICAgIDEzNzAgICAgNiogaW50ZXJuZXQ2IHN0cmVhbSB0Y3AgZmZm ZmZmMDAwNTJhMDVkMApyb290ICAgICBtb3VudGQgICAgICAxMzcwICAgIDcqIGludGVybmV0IGRn cmFtIHVkcCBmZmZmZmYwMDA1MTQ5MjYwCnJvb3QgICAgIG1vdW50ZCAgICAgIDEzNzAgICAgOCog aW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmYwMDA1MmEwMmU4CnJvb3QgICAgIHJwY2JpbmQgICAg IDEzMDAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAg IHJwY2JpbmQgICAgIDEzMDAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCnJvb3QgICAgIHJwY2JpbmQgICAgIDEzMDAgdGV4dCAvdXNyICAgICAxMDIxMDkzIC1yLXhy LXhyLXggICA0MzEyMCAgcgpyb290ICAgICBycGNiaW5kICAgICAxMzAwICAgIDAgL2RldiAgICAg ICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBycGNiaW5kICAgICAxMzAwICAg IDEgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBycGNiaW5k ICAgICAxMzAwICAgIDIgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290 ICAgICBycGNiaW5kICAgICAxMzAwICAgIDMgL3ZhciAgICAgIDcwNjg1IC1yLS1yLS1yLS0gICAg ICAgMCAgcgpyb290ICAgICBycGNiaW5kICAgICAxMzAwICAgIDQqIGludGVybmV0NiBkZ3JhbSB1 ZHAgZmZmZmZmMDAwNTE3MzM5MApyb290ICAgICBycGNiaW5kICAgICAxMzAwICAgIDUqIGxvY2Fs IHN0cmVhbSBmZmZmZmYwMDA1MTg5ODcwCnJvb3QgICAgIHJwY2JpbmQgICAgIDEzMDAgICAgNiog aW50ZXJuZXQ2IGRncmFtIHVkcCBmZmZmZmYwMDA1MTczYWIwCnJvb3QgICAgIHJwY2JpbmQgICAg IDEzMDAgICAgNyogaW50ZXJuZXQ2IGRncmFtIHVkcCBmZmZmZmYwMDA1MTczZDEwCnJvb3QgICAg IHJwY2JpbmQgICAgIDEzMDAgICAgOCogaW50ZXJuZXQ2IHN0cmVhbSB0Y3AgZmZmZmZmMDAwNTJh ODAwMApyb290ICAgICBycGNiaW5kICAgICAxMzAwICAgIDkqIGludGVybmV0IGRncmFtIHVkcCBm ZmZmZmYwMDA1MTg4MDAwCnJvb3QgICAgIHJwY2JpbmQgICAgIDEzMDAgICAxMCogaW50ZXJuZXQg ZGdyYW0gdWRwIGZmZmZmZjAwMDUxNzM3MjAKcm9vdCAgICAgcnBjYmluZCAgICAgMTMwMCAgIDEx KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZjAwMDUyYTdiYTAKcm9vdCAgICAgc3lzbG9nZCAg ICAgMTI3OSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAg ICAgc3lzbG9nZCAgICAgMTI3OSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHIKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSB0ZXh0IC91c3IgICAgIDEwMjExMTkgLXIt eHIteHIteCAgIDM5MzkyICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDEyNzkgICAgMCAvZGV2ICAg ICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDEyNzkg ICAgMSAvZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN5c2xv Z2QgICAgIDEyNzkgICAgMiAvZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIHN5c2xvZ2QgICAgIDEyNzkgICAgMyAvdmFyICAgICAgNzA2NzYgLXJ3LS0tLS0tLSAg ICAgICA0ICB3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDEyNzkgICAgNCogbG9jYWwgZGdyYW0gZmZm ZmZmMDAwNTE4YTk2MApyb290ICAgICBzeXNsb2dkICAgICAxMjc5ICAgIDUqIGxvY2FsIGRncmFt IGZmZmZmZjAwMDUxOGE4NzAKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgICA2KiBpbnRlcm5l dDYgZGdyYW0gdWRwIGZmZmZmZjAwMDUxNzM4NTAKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAg ICA3KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDAwNTE3Mzk4MApyb290ICAgICBzeXNsb2dk ICAgICAxMjc5ICAgIDggL2RldiAgICAgICAgICA4IGNydy0tLS0tLS0gICAga2xvZyAgcgpyb290 ICAgICBzeXNsb2dkICAgICAxMjc5ICAgMTAgL2RldiAgICAgICAgICA3IGNydy0tLS0tLS0gIGNv bnNvbGUgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgIDExIC92YXIgICAgICAyMzU3MSAt cnctci0tci0tICAgNzA5NzkgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgIDEyIC92YXIg ICAgICAyMzU2NSAtcnctLS0tLS0tICAgICAgNjAgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3 OSAgIDEzIC92YXIgICAgICAyMzU1OCAtcnctLS0tLS0tICAgMTU4MDYgIHcKcm9vdCAgICAgc3lz bG9nZCAgICAgMTI3OSAgIDE0IC92YXIgICAgICAyMzU4MyAtcnctci0tLS0tICAgIDI0MzQgIHcK cm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgIDE1IC92YXIgICAgICAyMzU2MSAtcnctci0tci0t ICAgICAgNjAgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgIDE2IC92YXIgICAgICAyMzU2 NyAtcnctLS0tLS0tICAgICAgNjAgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTI3OSAgIDE3IC92 YXIgICAgICAyMzYwMiAtcnctLS0tLS0tICAgODI4MDQgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAg MTI3OSAgIDE4IC92YXIgICAgICAyMzU2MCAtcnctLS0tLS0tICAgICAgNjAgIHcKcm9vdCAgICAg c3lzbG9nZCAgICAgMTI3OSAgIDE5IC92YXIgICAgICAyMzYxMyAtcnctci0tLS0tICAgMzc4NDgg IHcKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiB0ZXh0 IC8gICAgICAgICAgIDE1OSAtci14ci14ci14ICA0MjAzMjggIHIKcm9vdCAgICAgZGV2ZCAgICAg ICAgMTEwNiAgICAwIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAg ICAgZGV2ZCAgICAgICAgMTEwNiAgICAxIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51 bGwgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiAgICAyIC9kZXYgICAgICAgICAgOSBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiAgICAzIC8gICAgICAg ICAgIDE1MCBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTEwNiAg ICA0IC9kZXYgICAgICAgICAgNCBjcnctLS0tLS0tICBkZXZjdGwgIHIKcm9vdCAgICAgZGV2ZCAg ICAgICAgMTEwNiAgICA1KiBsb2NhbCBzdHJlYW0gZmZmZmZmMDAwNTE4OWUxMApyb290ICAgICBk ZXZkICAgICAgICAxMTA2ICAgIDYgL3ZhciAgICAgIDcwNjczIC1ydy0tLS0tLS0gICAgICAgNCAg dwpyb290ICAgICBtb3VzZWQgICAgICAxMDg5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhy LXggICAgIDUxMiAgcgpyb290ICAgICBtb3VzZWQgICAgICAxMDg5ICAgd2QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBtb3VzZWQgICAgICAxMDg5IHRleHQg L3VzciAgICAgMTAyMDk1NSAtci14ci14ci14ICAgNDAyMDggIHIKcm9vdCAgICAgbW91c2VkICAg ICAgMTA4OSAgICAwIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAg ICAgbW91c2VkICAgICAgMTA4OSAgICAxIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51 bGwgcncKcm9vdCAgICAgbW91c2VkICAgICAgMTA4OSAgICAyIC9kZXYgICAgICAgICAgOSBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbW91c2VkICAgICAgMTA4OSAgICAzIC9kZXYgICAg ICAgIDE0NSBjcnctci0tci0tICAgIHVtczAgcncKcm9vdCAgICAgbW91c2VkICAgICAgMTA4OSAg ICA0IC9kZXYgICAgICAgICA3NSBjcnctLS0tLS0tICBjb25zb2xlY3RsIHJ3CnJvb3QgICAgIG1v dXNlZCAgICAgIDEwODkgICAgNSogbG9jYWwgc3RyZWFtIGZmZmZmZjAwMDUxODllMTAKcm9vdCAg ICAgbW91c2VkICAgICAgMTA4OSAgICA2IC92YXIgICAgICA3MDY3MiAtcnctLS0tLS0tICAgICAg IDQgIHcKcm9vdCAgICAgYWRqa2VybnR6ICAgIDI1OCByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgYWRqa2VybnR6ICAgIDI1OCAgIHdkIC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgYWRqa2VybnR6ICAgIDI1OCB0 ZXh0IC8gICAgICAgICAgIDE1MyAtci14ci14ci14ICAgIDkxNzYgIHIKcm9vdCAgICAgYWRqa2Vy bnR6ICAgIDI1OCAgICAwIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9v dCAgICAgYWRqa2VybnR6ICAgIDI1OCAgICAxIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAg IG51bGwgcncKcm9vdCAgICAgYWRqa2VybnR6ICAgIDI1OCAgICAyIC9kZXYgICAgICAgICAgOSBj cnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgemlsX2NsZWFuICAgIDE5MiByb290IC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgemlsX2NsZWFuICAgIDE5 MiAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgemls X2NsZWFuICAgIDE5MSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIK cm9vdCAgICAgemlsX2NsZWFuICAgIDE5MSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgICA1MTIgIHIKcm9vdCAgICAgdHhnX3RocmVhZF9lbnRlciAgIDE4OSByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgdHhnX3RocmVhZF9lbnRlciAg IDE4OSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAg dHhnX3RocmVhZF9lbnRlciAgIDE4OCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg ICA1MTIgIHIKcm9vdCAgICAgdHhnX3RocmVhZF9lbnRlciAgIDE4OCAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgdmRldjp3b3JrZXIgYWQxMiAgIDE4 NyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgdmRl djp3b3JrZXIgYWQxMiAgIDE4NyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHIKcm9vdCAgICAgdmRldjp3b3JrZXIgYWQxMCAgIDE4NiByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgdmRldjp3b3JrZXIgYWQxMCAgIDE4NiAg IHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgdmRldjp3 b3JrZXIgYWQ4ICAgMTg1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAg cgpyb290ICAgICB2ZGV2OndvcmtlciBhZDggICAxODUgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3 eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxODQgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxODQg ICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96 aW8gICAgICAxODMgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJv b3QgICAgIHNwYV96aW8gICAgICAxODMgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxODIgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxODIgICB3ZCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAx ODEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNw YV96aW8gICAgICAxODEgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy CnJvb3QgICAgIHNwYV96aW8gICAgICAxODAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxODAgICB3ZCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzkgcm9vdCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAg ICAxNzkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAg IHNwYV96aW8gICAgICAxNzggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzcgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzcgICB3 ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8g ICAgICAxNzYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3Qg ICAgIHNwYV96aW8gICAgICAxNzYgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAg NTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzUgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3 eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzUgICB3ZCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzQg cm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96 aW8gICAgICAxNzQgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJv b3QgICAgIHNwYV96aW8gICAgICAxNzMgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzMgICB3ZCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzIgcm9vdCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAx NzIgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNw YV96aW8gICAgICAxNzEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy CnJvb3QgICAgIHNwYV96aW8gICAgICAxNzEgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzAgcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNzAgICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAg ICAxNjkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAg IHNwYV96aW8gICAgICAxNjkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjggICB3ZCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjcgcm9v dCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8g ICAgICAxNjcgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3Qg ICAgIHNwYV96aW8gICAgICAxNjYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAg NTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjYgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3 eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjUgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjUg ICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96 aW8gICAgICAxNjQgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJv b3QgICAgIHNwYV96aW8gICAgICAxNjQgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjMgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjMgICB3ZCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAx NjIgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNw YV96aW8gICAgICAxNjIgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy CnJvb3QgICAgIHNwYV96aW8gICAgICAxNjEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjEgICB3ZCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNjAgcm9vdCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHNwYV96aW8gICAg ICAxNjAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAg IHNwYV96aW8gICAgICAxNTkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCnJvb3QgICAgIHNwYV96aW8gICAgICAxNTkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCnJvb3QgICAgIGwyYXJjX2ZlZWRfdGhyZWFkICAgMTI5IHJvb3QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBsMmFyY19mZWVkX3Ro cmVhZCAgIDEyOSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9v dCAgICAgYXJjX3JlY2xhaW1fdGhyZWFkICAgMTI4IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgIDUxMiAgcgpyb290ICAgICBhcmNfcmVjbGFpbV90aHJlYWQgICAxMjggICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHZhY2xlYW4gICAg ICAxMjUgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAg IHZhY2xlYW4gICAgICAxMjUgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByCnJvb3QgICAgIHN5c3RlbV90YXNrcSAgIDEyNCByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgc3lzdGVtX3Rhc2txICAgMTI0ICAgd2QgLyAgICAg ICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBzeXN0ZW1fdGFza3EgICAx MjMgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHN5 c3RlbV90YXNrcSAgIDEyMyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIg IHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSB0ZXh0 IC8gICAgICAgICAgIDE1OCAtci14ci14ci14ICA3MzQ4ODAgIHIKcm9vdCAgICAga2VybmVsICAg ICAgICAgMCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAg ICAga2VybmVsICAgICAgICAgMCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHIKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpkbWVzZwoKX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZh aWxlZApwaWQgMTgzNCAoYW11bGUpLCB1aWQgMjExMiwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAg c3BhY2UKTWF5IDEzIDE3OjE5OjMyIGhhcnJ5IGtlcm5lbDogcGlkIDE4MzQgKGFtdWxlKSwgdWlk IDIxMTIsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEy KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSg1KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo OSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMik6IGZhaWxlZApwaWQgNTk2NyAoYW11bGUpLCB1aWQgMjExMiwgd2FzIGtp bGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKTWF5IDEzIDE3OjI5OjQ3IGhhcnJ5IGtlcm5lbDogcGlk IDU5NjcgKGFtdWxlKSwgdWlkIDIxMTIsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDgpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgx Mik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgx Nik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo OSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg1KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoNSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDUpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSg1KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoNSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDUpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg1KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo MTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgx Nik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2 KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApwaWQgNjAw NSAoYW11bGUpLCB1aWQgMjExMiwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKTWF5IDEz IDE3OjQxOjMyIGhhcnJ5IGtlcm5lbDogcGlkIDYwMDUgKGFtdWxlKSwgdWlkIDIxMTIsIHdhcyBr aWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDgpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo MTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTIpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgxMik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDEyKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTIp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxMik6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDEyKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDgpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoOSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDE2KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo OSk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSg5KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDE2KTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDkpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMTYpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMp OiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dl dHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQK c3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFj ZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdl cl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFp bGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fw c3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBf cGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6 IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0 c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApz d2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNl KDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWls ZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBz cGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9w YWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTog ZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRz d2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3 YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2Uo Myk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJf Z2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxl ZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNw YWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3Bh Z2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBm YWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3 YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dh cF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgz KTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9n ZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVk CnN3YXBfcGFnZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3Bh Y2UoMyk6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFn ZXJfZ2V0c3dhcHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZh aWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnN3YXBfcGFnZXJfZ2V0c3dh cHNwYWNlKDMpOiBmYWlsZWQKc3dhcF9wYWdlcl9nZXRzd2Fwc3BhY2UoMyk6IGZhaWxlZApzd2Fw X3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgx Nik6IGZhaWxlZApzd2FwX3BhZ2VyX2dldHN3YXBzcGFjZSgxNik6IGZhaWxlZApzd2FwX3BhZ2Vy X2dldHN3YXBzcGFjZSgzKTogZmFpbGVkCnBpZCA2MDQ3IChhbXVsZSksIHVpZCAyMTEyLCB3YXMg a2lsbGVkOiBvdXQgb2Ygc3dhcCBzcGFjZQpNYXkgMTMgMTc6NTI6MDQgaGFycnkga2VybmVsOiBw aWQgNjA0NyAoYW11bGUpLCB1aWQgMjExMiwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAgc3BhY2UK cGlkIDE3MDggKFhvcmcpLCB1aWQgMCwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKTWF5 IDEzIDE3OjUyOjA0IGhhcnJ5IGtlcm5lbDogcGlkIDE3MDggKFhvcmcpLCB1aWQgMCwgd2FzIGtp bGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKU3RvcHBpbmcgaG9zdGFwZC4KV2FpdGluZyBmb3IgUElE UzogNTg5MwouClNodXR0aW5nIGRvd24gbG9jYWwgcGFja2FnZXM6Ci4KU3RvcHBpbmcgY3Jvbi4K U3RvcHBpbmcgc3NoZC4KV2FpdGluZyBmb3IgUElEUzogMTU4NwouClN0b3BwaW5nIG5mc2QuCldh aXRpbmcgZm9yIFBJRFM6IDEzNzggMTM4MAouClN0b3BwaW5nIG1vdW50ZC4KV2FpdGluZyBmb3Ig UElEUzogMTM3MAouClN0b3BwaW5nIHJwY2JpbmQuCldhaXRpbmcgZm9yIFBJRFM6IDEzMDAKLgpT dG9wcGluZyBkZXZkLgpXYWl0aW5nIGZvciBQSURTOiAxMTA2Ci4KV3JpdGluZyBlbnRyb3B5IGZp bGU6Ci4KVGVybWluYXRlZAouCk1heSAxMyAxODowNjoyOSBoYXJyeSBzeXNsb2dkOiBleGl0aW5n IG9uIHNpZ25hbCAxNQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNz IGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vj b25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2luZyBkaXNr cywgdm5vZGVzIHJlbWFpbmluZy4uLjMgMiAzIDMgMCAwIDAgZG9uZQpBbGwgYnVmZmVycyBzeW5j ZWQuCnpmc191bW91bnQ6OTcwWzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJl bW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTcwWzBdOiBGb3JjZSB1bm1vdW50IGlzIG5v dCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuClVwdGltZTogMjNoNTZtMTBzClJlYm9v dGluZy4uLgpjcHVfcmVzZXQ6IFN0b3BwaW5nIG90aGVyIENQVXMKQ29weXJpZ2h0IChjKSAxOTky LTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgz LCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVl QlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4K RnJlZUJTRCA4LjAtQ1VSUkVOVCAjMDogVHVlIE1heSAxMiAxMDo1MTowMCBCUlQgMjAwOQogICAg cm9vdEBoYXJyeS50cmUtcGIuZ292LmJyOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0NvcmUyRHVvOApU aW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IElu dGVsKFIpIENvcmUoVE0pMiBEdW8gQ1BVICAgICBFNjc1MCAgQCAyLjY2R0h6ICgyNjg3LjcwLU1I eiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ZmIgIFN0 ZXBwaW5nID0gMTEKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gs RFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHhl M2ZkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQ UixQRENNPgogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZl YXR1cmVzMj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9 IDIxNDc0ODM2NDggKDIwNDggTUIpCmF2YWlsIG1lbW9yeSA9IDIwMzE3NDI5NzYgKDE5MzcgTUIp CkFDUEkgQVBJQyBUYWJsZTogPElOVEVMICBERzMzQlUgID4KRnJlZUJTRC9TTVA6IE11bHRpcHJv Y2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2Uocykg eCAyIGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6 ICAxCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gMgppb2FwaWMwIDxWZXJzaW9uIDIuMD4g aXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPElOVEVMIERH MzNCVT4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9u IChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVh bGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0 IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNw aTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3Bp MApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUg ZGlzcGxheT4gcG9ydCAweDI0NjAtMHgyNDY3IG1lbSAweDkwMzAwMDAwLTB4OTAzN2ZmZmYsMHg4 MDAwMDAwMC0weDhmZmZmZmZmLDB4OTAyMDAwMDAtMHg5MDJmZmZmZiBpcnEgMTYgYXQgZGV2aWNl IDIuMCBvbiBwY2kwCmFncDA6IDxJbnRlbCBHMzMgU1ZHQSBjb250cm9sbGVyPiBvbiB2Z2FwY2kw CmFncDA6IGRldGVjdGVkIDcxNjRrIHN0b2xlbiBtZW1vcnkKYWdwMDogYXBlcnR1cmUgc2l6ZSBp cyAyNTZNCnBjaTA6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDYuOS45PiBw b3J0IDB4MjBlMC0weDIwZmYgbWVtIDB4OTAzODAwMDAtMHg5MDM5ZmZmZiwweDkwM2E0MDAwLTB4 OTAzYTRmZmYgaXJxIDIwIGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0wOiBVc2luZyBNU0kgaW50 ZXJydXB0CmVtMDogW0ZJTFRFUl0KZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxOTpkMTo4Mzoy MzplYwp1aGNpMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgy MGMwLTB4MjBkZiBpcnEgMTggYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNpMDogW0lUSFJFQURd CnVoY2kwOiBMZWdTdXAgPSAweDBmMTAKdXNidXMwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0Ig Y29udHJvbGxlcj4gb24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBwb3J0IDB4MjBhMC0weDIwYmYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG9uIHBjaTAK dWhjaTE6IFtJVEhSRUFEXQp1aGNpMTogTGVnU3VwID0gMHgwZjEwCnVzYnVzMTogPEludGVsIDgy ODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCnVoY2kyOiA8SW50ZWwgODI4MDFJ IChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwODAtMHgyMDlmIGlycSAxNyBhdCBkZXZp Y2UgMjYuMiBvbiBwY2kwCnVoY2kyOiBbSVRIUkVBRF0KdWhjaTI6IExlZ1N1cCA9IDB4MGYxMAp1 c2J1czI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgplaGNp MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHg5MDNhNTQw MC0weDkwM2E1N2ZmIGlycSAxNyBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCmVoY2kwOiBbSVRIUkVB RF0KdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMzogPEludGVsIDgyODAxSSAoSUNIOSkg VVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApoZGFjMDogPEludGVsIDgyODAxSSBIaWdoIERl ZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4OTAzYTAwMDAtMHg5MDNhM2ZmZiBpcnEg MjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAw OTA0MDFfMDEzMgpoZGFjMDogW0lUSFJFQURdCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2li MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4xIG9uIHBjaTAKcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjIKYXRhcGNpMDogPE1hcnZlbGwgODhTWDYxMDEgVURNQTEzMyBj b250cm9sbGVyPiBwb3J0IDB4MTAxOC0weDEwMWYsMHgxMDI0LTB4MTAyNywweDEwMTAtMHgxMDE3 LDB4MTAyMC0weDEwMjMsMHgxMDAwLTB4MTAwZiBtZW0gMHg5MDEwMDAwMC0weDkwMTAwMWZmIGly cSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYXRhcGNpMDogW0lUSFJFQURdCmF0YTI6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IFtJVEhSRUFEXQpwY2liMzogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMyBvbiBwY2kw CnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDI4LjQgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQp1 aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgyMDYwLTB4 MjA3ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMzogW0lUSFJFQURdCnVoY2kz OiBMZWdTdXAgPSAweDBmMTAKdXNidXM0OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJv bGxlcj4gb24gdWhjaTMKdWhjaTQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVy PiBwb3J0IDB4MjA0MC0weDIwNWYgaXJxIDE5IGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdWhjaTQ6 IFtJVEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgwZjEwCnVzYnVzNTogPEludGVsIDgyODAxSSAo SUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVoY2k1OiA8SW50ZWwgODI4MDFJIChJQ0g5 KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwMjAtMHgyMDNmIGlycSAxOCBhdCBkZXZpY2UgMjku MiBvbiBwY2kwCnVoY2k1OiBbSVRIUkVBRF0KdWhjaTU6IExlZ1N1cCA9IDB4MGYxMAp1c2J1czY6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpNQplaGNpMTogPElu dGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHg5MDNhNTAwMC0weDkw M2E1M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kxOiBbSVRIUkVBRF0KdXNi dXM3OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIu MCBjb250cm9sbGVyPiBvbiBlaGNpMQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAzMC4wIG9uIHBjaTAKcGNpNjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjYKcmFsMDogPFJh bGluayBUZWNobm9sb2d5IFJUMjU2MT4gbWVtIDB4OTAwMDAwMDAtMHg5MDAwN2ZmZiBpcnEgMjIg YXQgZGV2aWNlIDEuMCBvbiBwY2k2CnJhbDA6IE1BQy9CQlAgUlQyNTYxQywgUkYgUlQyNTI3CnJh bDA6IFtJVEhSRUFEXQpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVudHMgVFNCNDNBQjIyL0E+IG1l bSAweDkwMDBjMDAwLTB4OTAwMGM3ZmYsMHg5MDAwODAwMC0weDkwMDBiZmZmIGlycSAxOSBhdCBk ZXZpY2UgMy4wIG9uIHBjaTYKZndvaGNpMDogW0lUSFJFQURdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lv biAxLjEwIChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDQu CmZ3b2hjaTA6IEVVSTY0IDAwOjkwOjI3OjAwOjAxOmUyOjU1OmFmCmZ3b2hjaTA6IFBoeSAxMzk0 YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIw NDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAK ZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24gZmlyZXdpcmUwCmRjb25z X2Nyb20wOiBidXNfYWRkciAweDdlNDg4MDAwCmZ3ZTA6IDxFdGhlcm5ldCBvdmVyIEZpcmVXaXJl PiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNzOiAwMjo5MDoyNzpl Mjo1NTphZgpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjo5MDoyNzplMjo1NTphZgpmd2lwMDog PElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd2lwMDogRmlyZXdpcmUgYWRkcmVzczog MDA6OTA6Mjc6MDA6MDE6ZTI6NTU6YWYgQCAweGZmZmUwMDAwMDAwMCwgUzQwMCwgbWF4cmVjIDIw NDgKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwCmZ3b2hjaTA6 IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kwOiBmd29oY2lfaW50cl9jb3JlOiBCVVMgcmVzZXQK ZndvaGNpMDogZndvaGNpX2ludHJfY29yZTogbm9kZV9pZD0weDAwMDAwMDAwLCBTZWxmSUQgQ291 bnQ9MSwgQ1lDTEVNQVNURVIgbW9kZQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2Ug MzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kxOiA8SW50ZWwgSUNI OSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHgyNDU4LTB4MjQ1ZiwweDI0NzQtMHgyNDc3LDB4 MjQ1MC0weDI0NTcsMHgyNDcwLTB4MjQ3MywweDI0MzAtMHgyNDNmLDB4MjQyMC0weDI0MmYgaXJx IDIxIGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYXRhcGNpMTogW0lUSFJFQURdCmF0YTM6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMQphdGE0OiBbSVRIUkVBRF0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBh dCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphdGFwY2kyOiA8SW50ZWwgSUNIOSBT QVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHgyNDQ4LTB4MjQ0ZiwweDI0NmMtMHgyNDZmLDB4MjQ0 MC0weDI0NDcsMHgyNDY4LTB4MjQ2YiwweDI0MTAtMHgyNDFmLDB4MjQwMC0weDI0MGYgaXJxIDIx IGF0IGRldmljZSAzMS41IG9uIHBjaTAKYXRhcGNpMjogW0lUSFJFQURdCmF0YTU6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kyCmF0YTU6IFtJVEhSRUFEXQphdGE2OiA8QVRBIGNoYW5uZWwgMT4g b24gYXRhcGNpMgphdGE2OiBbSVRIUkVBRF0KYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBv cnQgMHg3MC0weDcxLDB4NzQtMHg3NyBpcnEgOCBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQg Y29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6 IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtH SUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJs ZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQwOiBbRklM VEVSXQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAg RnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2w+IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMAplc3QxOiA8RW5oYW5j ZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCnA0dGNjMTogPENQVSBGcmVx dWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBm bGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5n ZQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmZpcmV3aXJlMDogMSBub2Rlcywg bWF4aG9wIDw9IDAgY2FibGUgSVJNIGlybSgwKSAgKG1lKSAKZmlyZXdpcmUwOiBidXMgbWFuYWdl ciAwIAp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1 bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1 czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVk IFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM2OiAxMk1i cHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czc6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIu MAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPElu dGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMy CnVodWIyOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVs IEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czMKdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJ bnRlbD4gYXQgdXNidXM1CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVz Ngp1aHViNjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czYKdWdlbjcuMTogPEludGVsPiBhdCB1c2J1czcKdWh1Yjc6IDxJbnRl bCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXM3CmFjZDA6IERWRFIgPEhMLURULVNUIERWRFJBTSBHU0EtSDQyTi9STDAwPiBhdCBhdGEyLXNs YXZlIFVETUE2NgphZDY6IDc2MzI0TUIgPFdEQyBXRDgwMEpELTA4TFNBMCAwOS4wMUQwOT4gYXQg YXRhMy1tYXN0ZXIgU0FUQTMwMAphZDg6IDE1MjYyN01CIDxTQU1TVU5HIEhEMTYxSEogR0YxMDAt MDc+IGF0IGF0YTQtbWFzdGVyIFNBVEEzMDAKYWQxMDogMTUyNjI3TUIgPFNBTVNVTkcgSEQxNjFI SiA0MVIwMTg2TEVOIEpGMTAwLTE5PiBhdCBhdGE1LW1hc3RlciBTQVRBMzAwCmFkMTI6IDE1MjYy N01CIDxTQU1TVU5HIEhEMTYxSEogR0YxMDAtMDc+IGF0IGF0YTYtbWFzdGVyIFNBVEEzMDAKR0VP TTogYWQ2czI6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgs NjNzKS4KaGRhYzA6IEhEQSBDb2RlYyAjMjogUmVhbHRlayBBTEM4ODgKcGNtMDogPEhEQSBSZWFs dGVrIEFMQzg4OCBQQ00gIzAgQW5hbG9nPiBhdCBjYWQgMiBuaWQgMSBvbiBoZGFjMApwY20xOiA8 SERBIFJlYWx0ZWsgQUxDODg4IFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAyIG5pZCAxIG9uIGhkYWMw CkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDZzMmEgaXMgdWZzaWQvNDliZTU1OTA0 OGMwMzY5ZS4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkNnMyZCBpcyB1ZnNpZC80 OWJlNTU5MTlmODgyNjZmLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ2czJlIGlz IHVmc2lkLzQ5YmU1NTkxODliOTAyMWMuCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBh ZDZzMmYgaXMgdWZzaWQvNDliZTU1OTFiZjg1YmZiZi4KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZAp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK dWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZAp1Z2VuMi4yOiA8TG9naXRlY2g+IGF0IHVzYnVzMgp1bXMwOiA8TG9naXRlY2ggT3B0aWNhbCBV U0IgTW91c2UsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMy40MCwgYWRkciAyPiBvbiB1c2J1czIKdW1z MDogMyBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wClNNUDogQVAgQ1BVICMxIExh dW5jaGVkIQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkNnMyYQpFbnRyb3B5 IGhhcnZlc3Rpbmc6CiBpbnRlcnJ1cHRzCiBldGhlcm5ldAogcG9pbnRfdG9fcG9pbnQKIGtpY2tz dGFydAouCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5YmU1NTkwNDhjMDM2OWUgcmVtb3ZlZC4K L2Rldi9hZDZzMmE6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZDZz MmE6IGNsZWFuLCAxMzAxMCBmcmVlICgxMjgyIGZyYWdzLCAxNDY2IGJsb2NrcywgMC41JSBmcmFn bWVudGF0aW9uKQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ2czJhIGlzIHVmc2lk LzQ5YmU1NTkwNDhjMDM2OWUuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5YmU1NTkxODliOTAy MWMgcmVtb3ZlZC4KL2Rldi9hZDZzMmU6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVD S1MKL2Rldi9hZDZzMmU6IGNsZWFuLCAyNTM3OTUgZnJlZSAoNDMgZnJhZ3MsIDMxNzE5IGJsb2Nr cywgMC4wJSBmcmFnbWVudGF0aW9uKQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ2 czJlIGlzIHVmc2lkLzQ5YmU1NTkxODliOTAyMWMuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5 YmU1NTkxYmY4NWJmYmYgcmVtb3ZlZC4KL2Rldi9hZDZzMmY6IEZJTEUgU1lTVEVNIENMRUFOOyBT S0lQUElORyBDSEVDS1MKL2Rldi9hZDZzMmY6IGNsZWFuLCA0NDY1NDM0IGZyZWUgKDEzODY1MCBm cmFncywgNTQwODQ4IGJsb2NrcywgMS45JSBmcmFnbWVudGF0aW9uKQpHRU9NX0xBQkVMOiBMYWJl bCBmb3IgcHJvdmlkZXIgYWQ2czJmIGlzIHVmc2lkLzQ5YmU1NTkxYmY4NWJmYmYuCkdFT01fTEFC RUw6IExhYmVsIHVmc2lkLzQ5YmU1NTkxOWY4ODI2NmYgcmVtb3ZlZC4KL2Rldi9hZDZzMmQ6IEZJ TEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZDZzMmQ6IGNsZWFuLCAxMzU5 NzY1IGZyZWUgKDQ1NjUgZnJhZ3MsIDE2OTQwMCBibG9ja3MsIDAuMyUgZnJhZ21lbnRhdGlvbikK R0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkNnMyZCBpcyB1ZnNpZC80OWJlNTU5MTlm ODgyNjZmLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80OWJlNTU5MDQ4YzAzNjllIHJlbW92ZWQu CkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5YmU1NTkxODliOTAyMWMgcmVtb3ZlZC4KR0VPTV9M QUJFTDogTGFiZWwgdWZzaWQvNDliZTU1OTFiZjg1YmZiZiByZW1vdmVkLgpHRU9NX0xBQkVMOiBM YWJlbCB1ZnNpZC80OWJlNTU5MTlmODgyNjZmIHJlbW92ZWQuClRoaXMgbW9kdWxlIChvcGVuc29s YXJpcykgY29udGFpbnMgY29kZSBjb3ZlcmVkIGJ5IHRoZQpDb21tb24gRGV2ZWxvcG1lbnQgYW5k IERpc3RyaWJ1dGlvbiBMaWNlbnNlIChDRERMKQpzZWUgaHR0cDovL29wZW5zb2xhcmlzLm9yZy9v cy9saWNlbnNpbmcvb3BlbnNvbGFyaXNfbGljZW5zZS8KV0FSTklORzogWkZTIGlzIGNvbnNpZGVy ZWQgdG8gYmUgYW4gZXhwZXJpbWVudGFsIGZlYXR1cmUgaW4gRnJlZUJTRC4KWkZTIGZpbGVzeXN0 ZW0gdmVyc2lvbiAxMwpaRlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMTMKU3RhcnRpbmcgTmV0d29y azogbG8wIGVtMC4KQWRkaXRpb25hbCByb3V0aW5nIG9wdGlvbnM6CiBJUCBnYXRld2F5PVlFUwou CkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6CiBsaW51eAouCm1vdXNlZDogCnVuYWJsZSB0byBvcGVu IC9kZXYvcHNtMDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQoKZW0wOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVAKaW5faWZpbml0OiBpbnNlcnRpb24gZmFpbGVkCk1heSAxMyAxODowNzo0MCBo YXJyeSBkaGNsaWVudFsxNDY1XTogZW0wOiBub3QgZm91bmQKTWF5IDEzIDE4OjA3OjQwIGhhcnJ5 IGRoY2xpZW50WzE0NjVdOiBleGl0aW5nLgpNYXkgMTMgMTg6MDc6NDAgaGFycnkgZGhjbGllbnRb MTQ3OV06IGNvbm5lY3Rpb24gY2xvc2VkCk1heSAxMyAxODowNzo0MCBoYXJyeSBkaGNsaWVudFsx NDc5XTogZXhpdGluZy4KQ29uZmlndXJpbmcgc3lzY29uczoKIGtleW1hcAogYmxhbmt0aW1lCiBz Y3JlZW5zYXZlcgouCkxvY2FsIHBhY2thZ2UgaW5pdGlhbGl6YXRpb246Ci4KQ29uZmlndXJhdGlv biBmaWxlOiAvZXRjL2hvc3RhcGQuY29uZgpic2RfaW5pdDogaW50ZXJmYWNlIHdsYW4wIGRvZXMg bm90IGV4aXN0YnNkIGRyaXZlciBpbml0aWFsaXphdGlvbiBmYWlsZWQuCi9ldGMvcmM6IFdBUk5J Tkc6IGZhaWxlZCB0byBzdGFydCBob3N0YXBkCgpXZWQgTWF5IDEzIDE4OjA3OjQxIEJSVCAyMDA5 CmRybTA6IDxJbnRlbCBHMzM+IG9uIHZnYXBjaTAKaW5mbzogW2RybV0gTVNJIGVuYWJsZWQgMSBt ZXNzYWdlKHMpCnZnYXBjaTA6IGNoaWxkIGRybTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfYnVzbWFz dGVyCmluZm86IFtkcm1dIEFHUCBhdCAweDgwMDAwMDAwIDI1Nk1CCmluZm86IFtkcm1dIEluaXRp YWxpemVkIGk5MTUgMS42LjAgMjAwODA3MzAKZHJtMDogW0lUSFJFQURdCk1heSAxNSAwODozMjow MiBoYXJyeSBzdTogbWF0aGV1cyB0byByb290IG9uIC9kZXYvcHRzLzQKTWF5IDE1IDA4OjMyOjEw IGhhcnJ5IGRoY2xpZW50WzgzODJdOiBlbTA6IG5vdCBmb3VuZApNYXkgMTUgMDg6MzI6MTAgaGFy cnkgZGhjbGllbnRbODM4Ml06IGV4aXRpbmcuCk1heSAxNSAwODozMjoxMCBoYXJyeSBkaGNsaWVu dFs4MzgzXTogY29ubmVjdGlvbiBjbG9zZWQKTWF5IDE1IDA4OjMyOjEwIGhhcnJ5IGRoY2xpZW50 WzgzODNdOiBleGl0aW5nLgp1M2dfaHVhd2VpX2luaXQ6MjUyOiAKdXNiMl9hbGxvY19kZXZpY2U6 MTc4ODogRm91bmQgSHVhd2VpIGF1dG8taW5zdGFsbCBkaXNrIQp1Z2VuMC4yOiA8SFVBV0VJIFRl Y2hub2xvZ2llcz4gYXQgdXNidXMwCnVnZW4wLjI6IDxIVUFXRUkgVGVjaG5vbG9naWVzPiBhdCB1 c2J1czAgKGRpc2Nvbm5lY3RlZCkKdWh1Yl9yZWF0dGFjaF9wb3J0OjQxNjogY291bGQgbm90IGFs bG9jYXRlIG5ldyBkZXZpY2UhCnVnZW4wLjI6IDxIVUFXRUkgVGVjaG5vbG9naWVzPiBhdCB1c2J1 czAKdTNnMDogPERhdGEgSW50ZXJmYWNlPiBvbiB1c2J1czAKdTNnMDogRm91bmQgMiBwb3J0cy4K dHVuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCk1heSAxNSAxMDoyNDoyNSBoYXJyeSBzdTog QkFEIFNVIG1hdGhldXMgdG8gcm9vdCBvbiAvZGV2L3B0cy82Ck1heSAxNSAxMTo1ODo1MyBoYXJy eSByZWJvb3Q6IHJlYm9vdGVkIGJ5IG1hdGhldXMKTWF5IDE1IDExOjU4OjUzIGhhcnJ5IHN5c2xv Z2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1CldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lz dGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25k cykgZm9yIHN5c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3AuLi5kb25lCldhaXRpbmcg KG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNlcicgdG8gc3RvcC4uLgpT eW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uOSA5IDYgNiAyIDAgMCAwIGRvbmUKQWxs IGJ1ZmZlcnMgc3luY2VkLgp6ZnNfdW1vdW50Ojk3MFswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qg c3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk3MFswXTogRm9yY2Ug dW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgpVcHRpbWU6IDFk MTdoNTFtNDFzClJlYm9vdGluZy4uLgpjcHVfcmVzZXQ6IFN0b3BwaW5nIG90aGVyIENQVXMKQ29w eXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAx OTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0 CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRz IHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVC U0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQ1VSUkVOVCAjMTogRnJpIE1heSAxNSAxMTo1Mjow MyBCUlQgMjAwOQogICAgcm9vdEBoYXJyeS50cmUtcGIuZ292LmJyOi91c3Ivb2JqL3Vzci9zcmMv c3lzL0NvcmUyRHVvOApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApDUFU6IEludGVsKFIpIENvcmUoVE0pMiBEdW8gQ1BVICAgICBFNjc1MCAgQCAyLjY2 R0h6ICgyNjg3LjcwLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIg IElkID0gMHg2ZmIgIFN0ZXBwaW5nID0gMTEKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUs REUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4K ICBGZWF0dXJlczI9MHhlM2ZkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0y LFNTU0UzLENYMTYseFRQUixQRENNPgogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEws TlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50 CnJlYWwgbWVtb3J5ICA9IDIxNDc0ODM2NDggKDIwNDggTUIpCmF2YWlsIG1lbW9yeSA9IDIwMzE3 Mzg4ODAgKDE5MzcgTUIpCkFDUEkgQVBJQyBUYWJsZTogPElOVEVMICBERzMzQlUgID4KRnJlZUJT RC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01Q OiAxIHBhY2thZ2UocykgeCAyIGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUx IChBUCk6IEFQSUMgSUQ6ICAxCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gMgppb2FwaWMw IDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmtiZDEgYXQga2JkbXV4MAph Y3BpMDogPElOVEVMIERHMzNCVT4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQphY3Bp MDogUG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMu NTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVw IEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNm OC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAp2Z2FwY2kwOiA8 VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDI0NjAtMHgyNDY3IG1lbSAweDkwMzAwMDAw LTB4OTAzN2ZmZmYsMHg4MDAwMDAwMC0weDhmZmZmZmZmLDB4OTAyMDAwMDAtMHg5MDJmZmZmZiBp cnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFncDA6IDxJbnRlbCBHMzMgU1ZHQSBjb250cm9s bGVyPiBvbiB2Z2FwY2kwCmFncDA6IGRldGVjdGVkIDcxNjRrIHN0b2xlbiBtZW1vcnkKYWdwMDog YXBlcnR1cmUgc2l6ZSBpcyAyNTZNCnBjaTA6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAzLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25u ZWN0aW9uIDYuOS45PiBwb3J0IDB4MjBlMC0weDIwZmYgbWVtIDB4OTAzODAwMDAtMHg5MDM5ZmZm ZiwweDkwM2E0MDAwLTB4OTAzYTRmZmYgaXJxIDIwIGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0w OiBVc2luZyBNU0kgaW50ZXJydXB0CmVtMDogW0ZJTFRFUl0KZW0wOiBFdGhlcm5ldCBhZGRyZXNz OiAwMDoxOTpkMTo4MzoyMzplYwp1aGNpMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRy b2xsZXI+IHBvcnQgMHgyMGMwLTB4MjBkZiBpcnEgMTggYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1 aGNpMDogW0lUSFJFQURdCnVoY2kwOiBMZWdTdXAgPSAweDBmMTAKdXNidXMwOiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MjBhMC0weDIwYmYgaXJxIDIxIGF0IGRldmlj ZSAyNi4xIG9uIHBjaTAKdWhjaTE6IFtJVEhSRUFEXQp1aGNpMTogTGVnU3VwID0gMHgwZjEwCnVz YnVzMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCnVoY2ky OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwODAtMHgyMDlm IGlycSAxNyBhdCBkZXZpY2UgMjYuMiBvbiBwY2kwCnVoY2kyOiBbSVRIUkVBRF0KdWhjaTI6IExl Z1N1cCA9IDB4MGYxMAp1c2J1czI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMgplaGNpMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVy PiBtZW0gMHg5MDNhNTQwMC0weDkwM2E1N2ZmIGlycSAxNyBhdCBkZXZpY2UgMjYuNyBvbiBwY2kw CmVoY2kwOiBbSVRIUkVBRF0KdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMzogPEludGVs IDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApoZGFjMDogPEludGVs IDgyODAxSSBIaWdoIERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4OTAzYTAwMDAt MHg5MDNhM2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZl ciBSZXZpc2lvbjogMjAwOTA0MDFfMDEzMgpoZGFjMDogW0lUSFJFQURdCnBjaWIxOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4xIG9u IHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKYXRhcGNpMDogPE1hcnZlbGwgODhT WDYxMDEgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MTAxOC0weDEwMWYsMHgxMDI0LTB4MTAy NywweDEwMTAtMHgxMDE3LDB4MTAyMC0weDEwMjMsMHgxMDAwLTB4MTAwZiBtZW0gMHg5MDEwMDAw MC0weDkwMTAwMWZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYXRhcGNpMDogW0lUSFJF QURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IFtJVEhSRUFEXQpwY2li MzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpMzogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMjguMyBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjQgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNQp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+ IHBvcnQgMHgyMDYwLTB4MjA3ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMzog W0lUSFJFQURdCnVoY2kzOiBMZWdTdXAgPSAweDBmMTAKdXNidXM0OiA8SW50ZWwgODI4MDFJIChJ Q0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTMKdWhjaTQ6IDxJbnRlbCA4MjgwMUkgKElDSDkp IFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MjA0MC0weDIwNWYgaXJxIDE5IGF0IGRldmljZSAyOS4x IG9uIHBjaTAKdWhjaTQ6IFtJVEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgwZjEwCnVzYnVzNTog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVoY2k1OiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwMjAtMHgyMDNmIGlycSAx OCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k1OiBbSVRIUkVBRF0KdWhjaTU6IExlZ1N1cCA9 IDB4MGYxMAp1c2J1czY6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1 aGNpNQplaGNpMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0g MHg5MDNhNTAwMC0weDkwM2E1M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kx OiBbSVRIUkVBRF0KdXNidXM3OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNzogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMQpwY2liNjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpNjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjYKcmFsMDogPFJhbGluayBUZWNobm9sb2d5IFJUMjU2MT4gbWVtIDB4OTAwMDAwMDAtMHg5 MDAwN2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDEuMCBvbiBwY2k2CnJhbDA6IE1BQy9CQlAgUlQyNTYx QywgUkYgUlQyNTI3CnJhbDA6IFtJVEhSRUFEXQpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVudHMg VFNCNDNBQjIyL0E+IG1lbSAweDkwMDBjMDAwLTB4OTAwMGM3ZmYsMHg5MDAwODAwMC0weDkwMDBi ZmZmIGlycSAxOSBhdCBkZXZpY2UgMy4wIG9uIHBjaTYKZndvaGNpMDogW0lUSFJFQURdCmZ3b2hj aTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3Vz IGNoYW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDAwOjkwOjI3OjAwOjAxOmUyOjU1OmFmCmZ3 b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDogTGluayBT NDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBi dXM+IG9uIGZ3b2hjaTAKZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24g ZmlyZXdpcmUwCmRjb25zX2Nyb20wOiBidXNfYWRkciAweDdlNDg4MDAwCmZ3ZTA6IDxFdGhlcm5l dCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRy ZXNzOiAwMjo5MDoyNzplMjo1NTphZgpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjo5MDoyNzpl Mjo1NTphZgpmd2lwMDogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd2lwMDogRmly ZXdpcmUgYWRkcmVzczogMDA6OTA6Mjc6MDA6MDE6ZTI6NTU6YWYgQCAweGZmZmUwMDAwMDAwMCwg UzQwMCwgbWF4cmVjIDIwNDgKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmly ZXdpcmUwCmZ3b2hjaTA6IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kwOiBmd29oY2lfaW50cl9j b3JlOiBCVVMgcmVzZXQKZndvaGNpMDogZndvaGNpX2ludHJfY29yZTogbm9kZV9pZD0weDAwMDAw MDAwLCBTZWxmSUQgQ291bnQ9MSwgQ1lDTEVNQVNURVIgbW9kZQppc2FiMDogPFBDSS1JU0EgYnJp ZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFw Y2kxOiA8SW50ZWwgSUNIOSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHgyNDU4LTB4MjQ1Ziww eDI0NzQtMHgyNDc3LDB4MjQ1MC0weDI0NTcsMHgyNDcwLTB4MjQ3MywweDI0MzAtMHgyNDNmLDB4 MjQyMC0weDI0MmYgaXJxIDIxIGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYXRhcGNpMTogW0lUSFJF QURdCmF0YTM6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YTM6IFtJVEhSRUFEXQphdGE0 OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGE0OiBbSVRIUkVBRF0KcGNpMDogPHNlcmlh bCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphdGFwY2ky OiA8SW50ZWwgSUNIOSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHgyNDQ4LTB4MjQ0ZiwweDI0 NmMtMHgyNDZmLDB4MjQ0MC0weDI0NDcsMHgyNDY4LTB4MjQ2YiwweDI0MTAtMHgyNDFmLDB4MjQw MC0weDI0MGYgaXJxIDIxIGF0IGRldmljZSAzMS41IG9uIHBjaTAKYXRhcGNpMjogW0lUSFJFQURd CmF0YTU6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kyCmF0YTU6IFtJVEhSRUFEXQphdGE2OiA8 QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMgphdGE2OiBbSVRIUkVBRF0KYXRydGMwOiA8QVQgcmVh bHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxLDB4NzQtMHg3NyBpcnEgOCBvbiBhY3BpMAphdGti ZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBv biBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0 a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnVhcnQwOiA8MTY1 NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFj cGkwCnVhcnQwOiBbRklMVEVSXQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDA6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3Bp MAplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCnA0 dGNjMTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNv bnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNj MC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2 ZSBJL08gcG9ydCByYW5nZQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmZpcmV3 aXJlMDogMSBub2RlcywgbWF4aG9wIDw9IDAgY2FibGUgSVJNIGlybSgwKSAgKG1lKSAKZmlyZXdp cmUwOiBidXMgbWFuYWdlciAwIAp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVl ZCBVU0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czQ6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjAKdXNidXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czc6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVs IFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJ bnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVz Mwp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRl bCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8 SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWdlbjcuMTogPEludGVsPiBhdCB1c2J1 czcKdWh1Yjc6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXM3CmFjZDA6IERWRFIgPEhMLURULVNUIERWRFJBTSBHU0EtSDQyTi9S TDAwPiBhdCBhdGEyLXNsYXZlIFVETUE2NgphZDY6IDc2MzI0TUIgPFdEQyBXRDgwMEpELTA4TFNB MCAwOS4wMUQwOT4gYXQgYXRhMy1tYXN0ZXIgU0FUQTMwMAphZDg6IDE1MjYyN01CIDxTQU1TVU5H IEhEMTYxSEogR0YxMDAtMDc+IGF0IGF0YTQtbWFzdGVyIFNBVEEzMDAKYWQxMDogMTUyNjI3TUIg PFNBTVNVTkcgSEQxNjFISiA0MVIwMTg2TEVOIEpGMTAwLTE5PiBhdCBhdGE1LW1hc3RlciBTQVRB MzAwCmFkMTI6IDE1MjYyN01CIDxTQU1TVU5HIEhEMTYxSEogR0YxMDAtMDc+IGF0IGF0YTYtbWFz dGVyIFNBVEEzMDAKaGRhYzA6IEhEQSBDb2RlYyAjMjogUmVhbHRlayBBTEM4ODgKcGNtMDogPEhE QSBSZWFsdGVrIEFMQzg4OCBQQ01HRU9NOiBhZDZzMjogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2gg bGFiZWwgKDI1NWgsNjNzICE9IDE2aCw2M3MpLgogIzAgQW5hbG9nPiBhdCBjYWQgMiBuaWQgMSBv biBoZGFjMApwY20xOiA8SERBIFJlYWx0ZWsgQUxDODg4IFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAy IG5pZCAxIG9uIGhkYWMwCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDZzMmEgaXMg dWZzaWQvNDliZTU1OTA0OGMwMzY5ZS4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFk NnMyZCBpcyB1ZnNpZC80OWJlNTU5MTlmODgyNjZmLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJv dmlkZXIgYWQ2czJlIGlzIHVmc2lkLzQ5YmU1NTkxODliOTAyMWMuCkdFT01fTEFCRUw6IExhYmVs IGZvciBwcm92aWRlciBhZDZzMmYgaXMgdWZzaWQvNDliZTU1OTFiZjg1YmZiZi4KdWh1YjA6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDYgcG9ydHMgd2l0 aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDZzMmEKdWdlbjIuMjogPExvZ2l0ZWNoPiBhdCB1c2J1czIK dWdlbjAuMjogPEhVQVdFSSBUZWNobm9sb2dpZXM+IGF0IHVzYnVzMAp1bXMwOiA8TG9naXRlY2gg T3B0aWNhbCBVU0IgTW91c2UsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMy40MCwgYWRkciAyPiBvbiB1 c2J1czIKdTNnMDogPERhdGEgSW50ZXJmYWNlPiBvbiB1c2J1czAKdTNnMDogRm91bmQgMiBwb3J0 cy4KdW1zMDogMyBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wCkVudHJvcHkgaGFy dmVzdGluZzoKIGludGVycnVwdHMKIGV0aGVybmV0CiBwb2ludF90b19wb2ludAoga2lja3N0YXJ0 Ci4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDliZTU1OTA0OGMwMzY5ZSByZW1vdmVkLgovZGV2 L2FkNnMyYTogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkNnMyYTog Y2xlYW4sIDEyMDY2IGZyZWUgKDEzNDYgZnJhZ3MsIDEzNDAgYmxvY2tzLCAwLjUlIGZyYWdtZW50 YXRpb24pCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDZzMmEgaXMgdWZzaWQvNDli ZTU1OTA0OGMwMzY5ZS4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDliZTU1OTE4OWI5MDIxYyBy ZW1vdmVkLgovZGV2L2FkNnMyZTogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwov ZGV2L2FkNnMyZTogY2xlYW4sIDI1Mzc5NSBmcmVlICgzNSBmcmFncywgMzE3MjAgYmxvY2tzLCAw LjAlIGZyYWdtZW50YXRpb24pCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDZzMmUg aXMgdWZzaWQvNDliZTU1OTE4OWI5MDIxYy4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDliZTU1 OTFiZjg1YmZiZiByZW1vdmVkLgovZGV2L2FkNnMyZjogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQ SU5HIENIRUNLUwovZGV2L2FkNnMyZjogY2xlYW4sIDQ1NTAyMTMgZnJlZSAoMTQxNTg5IGZyYWdz LCA1NTEwNzggYmxvY2tzLCAxLjklIGZyYWdtZW50YXRpb24pCkdFT01fTEFCRUw6IExhYmVsIGZv ciBwcm92aWRlciBhZDZzMmYgaXMgdWZzaWQvNDliZTU1OTFiZjg1YmZiZi4KR0VPTV9MQUJFTDog TGFiZWwgdWZzaWQvNDliZTU1OTE5Zjg4MjY2ZiByZW1vdmVkLgovZGV2L2FkNnMyZDogRklMRSBT WVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkNnMyZDogY2xlYW4sIDEzNTk2NTEg ZnJlZSAoNDU3OSBmcmFncywgMTY5Mzg0IGJsb2NrcywgMC4zJSBmcmFnbWVudGF0aW9uKQpHRU9N X0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ2czJkIGlzIHVmc2lkLzQ5YmU1NTkxOWY4ODI2 NmYuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5YmU1NTkwNDhjMDM2OWUgcmVtb3ZlZC4KR0VP TV9MQUJFTDogTGFiZWwgdWZzaWQvNDliZTU1OTE4OWI5MDIxYyByZW1vdmVkLgpHRU9NX0xBQkVM OiBMYWJlbCB1ZnNpZC80OWJlNTU5MWJmODViZmJmIHJlbW92ZWQuCkdFT01fTEFCRUw6IExhYmVs IHVmc2lkLzQ5YmU1NTkxOWY4ODI2NmYgcmVtb3ZlZC4KVGhpcyBtb2R1bGUgKG9wZW5zb2xhcmlz KSBjb250YWlucyBjb2RlIGNvdmVyZWQgYnkgdGhlCkNvbW1vbiBEZXZlbG9wbWVudCBhbmQgRGlz dHJpYnV0aW9uIExpY2Vuc2UgKENEREwpCnNlZSBodHRwOi8vb3BlbnNvbGFyaXMub3JnL29zL2xp Y2Vuc2luZy9vcGVuc29sYXJpc19saWNlbnNlLwpXQVJOSU5HOiBaRlMgaXMgY29uc2lkZXJlZCB0 byBiZSBhbiBleHBlcmltZW50YWwgZmVhdHVyZSBpbiBGcmVlQlNELgpaRlMgZmlsZXN5c3RlbSB2 ZXJzaW9uIDEzClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbiAxMwpTdGFydGluZyBOZXR3b3JrOiBs bzAgZW0wLgpBZGRpdGlvbmFsIHJvdXRpbmcgb3B0aW9uczoKIElQIGdhdGV3YXk9WUVTCi4KQWRk aXRpb25hbCBBQkkgc3VwcG9ydDoKIGxpbnV4Ci4KbW91c2VkOiAKdW5hYmxlIHRvIG9wZW4gL2Rl di9wc20wOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CgplbTA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUApDb25maWd1cmluZyBzeXNjb25zOgoga2V5bWFwCiBibGFua3RpbWUKIHNjcmVlbnNh dmVyCi4KTG9jYWwgcGFja2FnZSBpbml0aWFsaXphdGlvbjoKLgpDb25maWd1cmF0aW9uIGZpbGU6 IC9ldGMvaG9zdGFwZC5jb25mCmJzZF9pbml0OiBpbnRlcmZhY2Ugd2xhbjAgZG9lcyBub3QgZXhp c3Ric2QgZHJpdmVyIGluaXRpYWxpemF0aW9uIGZhaWxlZC4KL2V0Yy9yYzogV0FSTklORzogZmFp bGVkIHRvIHN0YXJ0IGhvc3RhcGQKCkZyaSBNYXkgMTUgMTE6NTk6NTggQlJUIDIwMDkKZHJtMDog PEludGVsIEczMz4gb24gdmdhcGNpMAppbmZvOiBbZHJtXSBNU0kgZW5hYmxlZCAxIG1lc3NhZ2Uo cykKdmdhcGNpMDogY2hpbGQgZHJtMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9idXNtYXN0ZXIKaW5m bzogW2RybV0gQUdQIGF0IDB4ODAwMDAwMDAgMjU2TUIKaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQg aTkxNSAxLjYuMCAyMDA4MDczMApkcm0wOiBbSVRIUkVBRF0KTWF5IDE1IDEyOjAwOjM5IGhhcnJ5 IHN1OiBtYXRoZXVzIHRvIHJvb3Qgb24gL2Rldi9wdHMvMAp0dW4wOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVAKdW1hc3MwOiA8SFVBV0VJIFRlY2hub2xvZ2llcyBIVUFXRUkgTW9iaWxlLCBjbGFz cyAwLzAsIHJldiAxLjEwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMwCnVtYXNzMDogIFNDU0kgb3Zl ciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAwMAp1bWFzczA6MTowOi0xOiBBdHRhY2hlZCB0byBz Y2J1czEKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAg MCAwIDAgMCAwIAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0 YXR1cyBFcnJvcgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIFN0YXR1czogQ2hlY2sg Q29uZGl0aW9uCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMAoo cHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKKHByb2JlMDp1bWFz cy1zaW0wOjA6MDowKTogVW5yZXRyeWFibGUgZXJyb3IKY2QwIGF0IHVtYXNzLXNpbTAgYnVzIDAg dGFyZ2V0IDAgbHVuIDAKY2QwOiA8SFVBV0VJIE1hc3MgU3RvcmFnZSAyLjMxPiBSZW1vdmFibGUg Q0QtUk9NIFNDU0ktMiBkZXZpY2UgCmNkMDogMS4wMDBNQi9zIHRyYW5zZmVycwpjZDA6IGNkIHBy ZXNlbnQgWzE2ODk2IHggMjA0OCBieXRlIHJlY29yZHNdCkdFT01fTEFCRUw6IExhYmVsIGZvciBw cm92aWRlciBjZDAgaXMgaXNvOTY2MC9Nb2JpbGUgUGFydG5lci4KdWdlbjcuMjogPEdlbmVyaWM+ IGF0IHVzYnVzNwp1bWFzczE6IDxHZW5lcmljIE1hc3MgU3RvcmFnZSwgY2xhc3MgMC8wLCByZXYg Mi4wMC8xLjA3LCBhZGRyIDI+IG9uIHVzYnVzNwp1bWFzczE6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5 OyBxdWlya3MgPSAweDAxMDAKdW1hc3MxOjI6MTotMTogQXR0YWNoZWQgdG8gc2NidXMyCihwcm9i ZTA6dW1hc3Mtc2ltMToxOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAgMCAK KHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IK KHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoo cHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBVTklUIEFUVEVOVElPTiBhc2M6MjgsMAoocHJvYmUw OnVtYXNzLXNpbTE6MTowOjApOiBOb3QgcmVhZHkgdG8gcmVhZHkgY2hhbmdlLCBtZWRpdW0gbWF5 IGhhdmUgY2hhbmdlZAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBSZXRyeWluZyBDb21tYW5k IChwZXIgU2Vuc2UgRGF0YSkKZGEwIGF0IHVtYXNzLXNpbTEgYnVzIDEgdGFyZ2V0IDAgbHVuIDAK ZGEwOiA8RkxBU0ggRHJpdmUgQVVfVVNCMjAgOC4wNz4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3Mg U0NTSS0yIGRldmljZSAKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDk5OU1CICgyMDQ1 OTUyIDUxMiBieXRlIHNlY3RvcnM6IDY0SCAzMlMvVCA5OTlDKQpHRU9NOiBkYTA6IHBhcnRpdGlv biAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGRhMDogcGFydGl0 aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT01fTEFCRUw6IExhYmVs IGZvciBwcm92aWRlciBkYTBzMSBpcyBtc2Rvc2ZzL01BVEhFVVNfMUcuCnVnZW43LjI6IDxHZW5l cmljPiBhdCB1c2J1czcgKGRpc2Nvbm5lY3RlZCkKdW1hc3MxOiBhdCB1aHViNywgcG9ydCA2LCBh ZGRyIDIgKGRpc2Nvbm5lY3RlZCkKKGRhMDp1bWFzcy1zaW0xOjE6MDowKTogbG9zdCBkZXZpY2UK KGRhMDp1bWFzcy1zaW0xOjE6MDowKTogcmVtb3ZpbmcgZGV2aWNlIGVudHJ5CkdFT01fTEFCRUw6 IExhYmVsIG1zZG9zZnMvTUFUSEVVU18xRyByZW1vdmVkLgpNYXkgMTUgMTI6MTk6MjggaGFycnkg ZGhjbGllbnRbMTUxNV06IGNvbm5lY3Rpb24gY2xvc2VkCk1heSAxNSAxMjoxOToyOCBoYXJyeSBk aGNsaWVudFsxNTE1XTogZXhpdGluZy4KTWF5IDE1IDEyOjIxOjQxIGhhcnJ5IHN1OiBtYXRoZXVz IHRvIHJvb3Qgb24gL2Rldi9wdHMvMAp0dW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgp1 Z2VuMC4yOiA8SFVBV0VJIFRlY2hub2xvZ2llcz4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQpCnUz ZzA6IGF0IHVodWIwLCBwb3J0IDEsIGFkZHIgMiAoZGlzY29ubmVjdGVkKQp1bWFzczA6IGF0IHVo dWIwLCBwb3J0IDEsIGFkZHIgMiAoZGlzY29ubmVjdGVkKQooY2QwRzpFT3VNbV9hTHNBc0ItRXNM aTptIDA6TDBhOmIwZTpsMCApOmkgc2xvbzlzNnQ2IDBkL2VNdm9pYmNpZWxlCiBQYShyY3RkbjBl OnJ1IG1yYWVzbXNvLXZzZWlkbS4wOgowOjA6MCk6IHJlbW92aW5nIGRldmljZSBlbnRyeQp1M2df aHVhd2VpX2luaXQ6MjUyOiAKdXNiMl9hbGxvY19kZXZpY2U6MTc4ODogRm91bmQgSHVhd2VpIGF1 dG8taW5zdGFsbCBkaXNrIQp1Z2VuMC4yOiA8SFVBV0VJIFRlY2hub2xvZ2llcz4gYXQgdXNidXMw CnVnZW4wLjI6IDxIVUFXRUkgVGVjaG5vbG9naWVzPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkK dWh1Yl9yZWF0dGFjaF9wb3J0OjQxNjogY291bGQgbm90IGFsbG9jYXRlIG5ldyBkZXZpY2UhCnVn ZW4wLjI6IDxIVUFXRUkgVGVjaG5vbG9naWVzPiBhdCB1c2J1czAKdTNnMDogPERhdGEgSW50ZXJm YWNlPiBvbiB1c2J1czAKdTNnMDogRm91bmQgMiBwb3J0cy4KdW1hc3MwOiA8SFVBV0VJIFRlY2hu b2xvZ2llcyBIVUFXRUkgTW9iaWxlLCBjbGFzcyAwLzAsIHJldiAxLjEwLzAuMDAsIGFkZHIgMj4g b24gdXNidXMwCnVtYXNzMDogIFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAwMAp1 bWFzczA6MTowOi0xOiBBdHRhY2hlZCB0byBzY2J1czEKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDow KTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAgMCAwIAoocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgoocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihwcm9iZTA6dW1hc3Mtc2ltMDow OjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRp dW0gbm90IHByZXNlbnQKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogVW5yZXRyeWFibGUgZXJy b3IKY2QwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8SFVBV0VJIE1h c3MgU3RvcmFnZSAyLjMxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMiBkZXZpY2UgCmNkMDogMS4w MDBNQi9zIHRyYW5zZmVycwpjZDA6IGNkIHByZXNlbnQgWzM3MDYwNjA4MDAgeCA0Mjg2NTEzMTUy IGJ5dGUgcmVjb3Jkc10KTWF5IDE4IDE0OjMzOjA3IGhhcnJ5IHN1OiBCQUQgU1UgbWF0aGV1cyB0 byByb290IG9uIC9kZXYvcHRzLzAKTWF5IDE4IDE0OjMzOjExIGhhcnJ5IHN1OiBtYXRoZXVzIHRv IHJvb3Qgb24gL2Rldi9wdHMvMApwYW5pYzoga21lbV9tYWxsb2MoLTg0NTQxNDQpOiBrbWVtX21h cCB0b28gc21hbGw6IDg5MTYxNzI4IHRvdGFsIGFsbG9jYXRlZApjcHVpZCA9IDAKVXB0aW1lOiAz ZDJoMzNtMzFzClBoeXNpY2FsIG1lbW9yeTogMjAwNiBNQgpEdW1waW5nIDQwOSBNQjogMzk0IChD VFJMLUMgdG8gYWJvcnQpICAzNzggMzYyIDM0NiAzMzAgKENUUkwtQyB0byBhYm9ydCkgIDMxNCAy OTggMjgyIChDVFJMLUMgdG8gYWJvcnQpICAyNjYgKENUUkwtQyB0byBhYm9ydCkgIDI1MCAoQ1RS TC1DIHRvIGFib3J0KSAgKENUUkwtQyB0byBhYm9ydCkgIDIzNCAoQ1RSTC1DIHRvIGFib3J0KSAg MjE4IChDVFJMLUMgdG8gYWJvcnQpICAoQ1RSTC1DIHRvIGFib3J0KSAgMjAyIChDVFJMLUMgdG8g YWJvcnQpICAoQ1RSTC1DIHRvIGFib3J0KSAgMTg2IChDVFJMLUMgdG8gYWJvcnQpICAxNzAgKENU UkwtQyB0byBhYm9ydCkgIChDVFJMLUMgdG8gYWJvcnQpICAxNTQgKENUUkwtQyB0byBhYm9ydCkg IDEzOCAxMjIgMTA2IDkwIDc0IDU4IDQyIDI2IDEwCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Ka2VybmVsIGNv bmZpZwoKY29uZmlnOiBGaWxlIC9ib290L2tlcm5lbC9rZXJuZWwgZG9lc24ndCBjb250YWluIGNv bmZpZ3VyYXRpb24gZmlsZS4gRWl0aGVyIHVuc3VwcG9ydGVkLCBvciBub3QgY29tcGlsZWQgd2l0 aCBJTkNMVURFX0NPTkZJR19GSUxFCg== ------=_20090518155128_91725-- From owner-freebsd-current@FreeBSD.ORG Mon May 18 20:31:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F0A1065677; Mon, 18 May 2009 20:31:58 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8AB8FC18; Mon, 18 May 2009 20:31:56 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so4224768ewy.43 for ; Mon, 18 May 2009 13:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8k7sxGRIt6GJyrDr4rPk1KtclTI2IOz4GE8lNUKyKw4=; b=UF3rjDRjf/lFgz1fBt0Zlz8OkFscZPqzy0BPvYXHwyehRh8h950+6E/gkWotiKwrGW 6YNdtuMq8lE9Q4A/UTHoHewNDxyHLHm52UXgngGdBECuNvHUWYltlN6r9miKag2ZP484 GT4rp1mGiWZr7VJUB8FOO2CQCitF68PzDqBrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gJkZEMu79Fo2nYZ7BFOPpksqziKUdIAKeo6+zXuAhDVs1sbTVvaUtbGzDfyaIwT+qg AIQNJFl3rtx9rqcghrnU+TH3GC286ECj+7SffvCw8ipygmfsjyKsBpd0H4eEkqNqRGgj voNe/AFXLjOhNAsshLSD0+Jicjl7ntFFJvhvM= MIME-Version: 1.0 Received: by 10.216.51.202 with SMTP id b52mr2240294wec.38.1242678715763; Mon, 18 May 2009 13:31:55 -0700 (PDT) In-Reply-To: <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> Date: Mon, 18 May 2009 22:31:55 +0200 Message-ID: <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 20:31:59 -0000 2009/5/18 Magnus Kling > 2009/5/18 Alexander Motin > > Hi. >> >> Magnus Kling wrote: >> >>> After having some trouble with ACPI kernel in 7.1, regarding booting with >>> a Promise SX4000 card in a RAID1 setup, I tried to upgrade to CURRENT to >>> test the bits that John Baldwin wrote and had commited to head. >>> Result: >>> Well, it boots ok but on reboot I get a kernel panic after the disks have >>> made the sync. >>> Attached is a bt and panic message. >>> >> >> According to backtrace, system tried to reference address 0xc while >> sending final flush command to the drive. ATA has no other shutdown actions >> except this, so any contexts and states should not be lost in any case. And >> as soon as your drive was detected, the controller is probably operable. >> Haven't you seen any other ATA error messages during boot or later? >> >> If my i386 kernel is more or less coherent to your's, >> ata_promise_sx4_command+0x39 address where it have crashed means >> caddr_t window = rman_get_virtual(ctlr->r_res1); >> line, and especially 'ctlr->r_res1' part. So looks like >> struct ata_pci_controller *ctlr = device_get_softc(gparent); >> returned NULL there. But the same technique used by many other ATA drivers >> without problems, so I am a bit surprised. >> >> Is the problem continuously repeatable? Does the controller operates well >> all other time before shutdown? Are you sure that you have rebuilt your >> kernel correctly? >> >> -- >> Alexander Motin >> > > Yes it is repeatable. Happens every reboot or shutdown. Controller works ok > all other time. (I have my homedir mounted to the raidarray.) > > The source was synced and then I did a normal: > make buildworld > make buildkernel > make installkernel > reboot to singel user mode and mergemaster -p + make installworld + > mergemaster then reboot. > > I will try to compile it again... > > /Magnus Compiled once again. No change. The kernel panics. /Magnus From owner-freebsd-current@FreeBSD.ORG Mon May 18 20:43:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35E5D106567C; Mon, 18 May 2009 20:43:51 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id A97498FC2F; Mon, 18 May 2009 20:43:50 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by yw-out-2324.google.com with SMTP id 9so2133761ywe.13 for ; Mon, 18 May 2009 13:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.132.10 with SMTP id j10mr13369415ybn.139.1242679429918; Mon, 18 May 2009 13:43:49 -0700 (PDT) In-Reply-To: <20090517180920.GY71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Date: Mon, 18 May 2009 22:43:49 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 20:43:55 -0000 On Sun, May 17, 2009 at 20:09, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin I'm impressed, everything I tried worked ootb. Thank you all! (FreeBSD/i386 7.2-STABLE) From owner-freebsd-current@FreeBSD.ORG Mon May 18 21:39:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C85D106567B for ; Mon, 18 May 2009 21:39:30 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5858FC1C for ; Mon, 18 May 2009 21:39:29 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by bwz9 with SMTP id 9so3464762bwz.43 for ; Mon, 18 May 2009 14:39:28 -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 :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=PgSjLHTbqu85GEC1v3xKYlPVFp5rHoARNEtFGOjRzA4=; b=q+fDCP7UlPR1+mmZJYuVi61AXD7EnrHvCdtBDBPRxqRur4XquSQoUT1F7PS9JxFo6o hWeguvzTQ4uyjkdPt8aaul9Wul6ldaSAOO4xADcP5GEQYYNQo/35uRzoepWz8mkj0Ki5 oJfIx3wIyHwgv12Tr2Y4whnlkjoKLpyOVrGbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Xupx/LrI4Pp0dKS7pntN9h9nmqNEO15SY9V2m6cqw14VNYJTZYF7t603t9xp/4L2N3 hedFeQB66c/qlGr4JsUV0z7S/Bye9YlQ12cEaE3CcjjjRR9t51xLLlQUcB2HNoCP+6Ie NxQoGr0R3nLnNTgKXZqr6UXMOzqf+ATiWfnSQ= Received: by 10.102.215.1 with SMTP id n1mr3729713mug.109.1242682767742; Mon, 18 May 2009 14:39:27 -0700 (PDT) Received: from beastie.lan ([195.60.175.243]) by mx.google.com with ESMTPS id s11sm1543005mue.20.2009.05.18.14.39.23 (version=SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 14:39:26 -0700 (PDT) Message-ID: <4A11D53D.7090106@gmail.com> Date: Tue, 19 May 2009 00:38:05 +0300 From: Andrey User-Agent: Thunderbird 2.0.0.21 (X11/20090418) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [snd_hda][AD1981HD] microphone doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 21:39:30 -0000 Hi, There is a laptop with Intel HD Audio Controller on board (HDA Codec AD1981HD) and FreeBSD8.0 CURRENT installed. Unfortunately I can't get microphone working. (7.2-PRERELEASE had been used before switching to CURRENT and microphone had been known as working out-of-the-box on that version of FreeBSD). Looking through the list exposed message where similar issue was reported: http://www.mailinglistarchive.com/freebsd-current@freebsd.org/msg22832.html But it looks like requestor didn't provide feedback regarding enclosed patch. Also, as far as I can judge, that patch is already in CURRENT, but it seems issue is not solved yet (well, at least I think so). There are various outputs below. Please, let me know if additional info is required. Thanks in advance! --- <> --- uname -a FreeBSD beastie.lan 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue May 12 21:53:51 EEST 2009 root@beastie.lan:/usr/obj/usr/src/sys/BEASTIE-SMP-ULE-20090512-v1 i386 --- <> --- dev.hdac.0.pindump: hdac0: Dumping AFG cad=0 nid=1 pins: hdac0: nid 5 0x92174110 as 1 seq 0 Speaker Fixed jack 7 loc 18 color Green misc 1 hdac0: Caps: IN OUT HP EAPD VREF Sense: 0x7fffec60 hdac0: nid 6 0x0321201f as 1 seq 15 Headphones Jack jack 1 loc 3 color Grey misc 0 hdac0: Caps: OUT HP Sense: 0xffffec60 hdac0: nid 7 0x410710f0 as 15 seq 0 Line-out None jack 7 loc 1 color Black misc 0 [DISABLED] hdac0: Caps: OUT hdac0: nid 8 0x03a12020 as 2 seq 0 Mic Jack jack 1 loc 3 color Grey misc 0 hdac0: Caps: IN VREF Sense: 0x7fff0014 hdac0: nid 9 0x0181302e as 2 seq 14 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: Caps: IN OUT VREF Sense: 0x0000ec60 hdac0: nid 10 0x4145f0f0 as 15 seq 0 SPDIF-out None jack 5 loc 1 color Other misc 0 [DISABLED] hdac0: Caps: OUT hdac0: nid 22 0x995711f0 as 15 seq 0 Digital-out Fixed jack 7 loc 25 color Black misc 1 [DISABLED] hdac0: Caps: IN hdac0: nid 23 0x5993e0f0 as 15 seq 0 AUX None jack 3 loc 25 color White misc 0 [DISABLED] hdac0: Caps: IN hdac0: Unsol Tag: 0x00000000 hdac0: Pin sense: nid=6 res=0xffffec60 Sense: 0x7ffff420 hdac0: nid 24 0x91a79121 as 2 seq 1 Mic Fixed jack 7 loc 17 color Pink misc 1 hdac0: Caps: IN OUT VREF Sense: 0x7ffff420 hdac0: nid 25 0x593310f0 as 15 seq 0 CD None jack 3 loc 25 color Black misc 0 [DISABLED] hdac0: Caps: IN hdac0: NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: GPIO: data=0x0000000b enable=0x00000000 direction=0x00000000 hdac0: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 --- <> --- dmesg: hdac0: mem 0xe4504000-0xe4507fff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xe4504000 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 256 for MSI msi: Assigning MSI IRQ 256 to local APIC 0 vector 52 hdac0: [MPSAFE] hdac0: [ITHREAD] --- < skipped > ---- hdac0: Probing codec #0... hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec ID: 0x11d41981 hdac0: Vendor: 0x11d4 hdac0: Device: 0x1981 hdac0: Revision: 0x02 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x30c0103c hdac0: Found audio FG nid=1 startnode=2 endnode=32 total=30 hdac0: Probing codec #1... hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) hdac0: HDA Codec ID: 0x11c11040 hdac0: Vendor: 0x11c1 hdac0: Device: 0x1040 hdac0: Revision: 0x02 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x30c0103c hdac0: Found modem FG nid=1 startnode=2 endnode=127 total=125 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: GHOST: nid=2 j=0 entnum=4 index=0 res=0x00000401 hdac0: nid 5 0x92174110 as 1 seq 0 Speaker Fixed jack 7 loc 18 color Green misc 1 hdac0: nid 6 0x0321201f as 1 seq 15 Headphones Jack jack 1 loc 3 color Grey misc 0 hdac0: nid 7 0x410710f0 as 15 seq 0 Line-out None jack 7 loc 1 color Black misc 0 hdac0: nid 8 0x03a12020 as 2 seq 0 Mic Jack jack 1 loc 3 color Grey misc 0 hdac0: nid 9 0x0181302e as 2 seq 14 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 10 0x4145f0f0 as 15 seq 0 SPDIF-out None jack 5 loc 1 color Other misc 0 hdac0: nid 22 0x995711f0 as 15 seq 0 Digital-out Fixed jack 7 loc 25 color Black misc 1 hdac0: nid 23 0x5993e0f0 as 15 seq 0 AUX None jack 3 loc 25 color White misc 0 hdac0: nid 24 0x91a79121 as 2 seq 1 Mic Fixed jack 7 loc 17 color Pink misc 1 hdac0: nid 25 0x593310f0 as 15 seq 0 CD None jack 3 loc 25 color Black misc 0 hdac0: Patched pins configuration: hdac0: nid 5 0x92174110 as 1 seq 0 Speaker Fixed jack 7 loc 18 color Green misc 1 hdac0: nid 6 0x0321201f as 1 seq 15 Headphones Jack jack 1 loc 3 color Grey misc 0 hdac0: nid 7 0x410710f0 as 15 seq 0 Line-out None jack 7 loc 1 color Black misc 0 [DISABLED] hdac0: nid 8 0x03a12020 as 2 seq 0 Mic Jack jack 1 loc 3 color Grey misc 0 hdac0: nid 9 0x0181302e as 2 seq 14 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 10 0x4145f0f0 as 15 seq 0 SPDIF-out None jack 5 loc 1 color Other misc 0 [DISABLED] hdac0: nid 22 0x995711f0 as 15 seq 0 Digital-out Fixed jack 7 loc 25 color Black misc 1 hdac0: nid 23 0x5993e0f0 as 15 seq 0 AUX None jack 3 loc 25 color White misc 0 [DISABLED] hdac0: nid 24 0x91a79121 as 2 seq 1 Mic Fixed jack 7 loc 17 color Pink misc 1 hdac0: nid 25 0x593310f0 as 15 seq 0 CD None jack 3 loc 25 color Black misc 0 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=5 seq=0 hdac0: Pin nid=6 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=8 seq=0 hdac0: Pin nid=24 seq=1 hdac0: Pin nid=9 seq=14 hdac0: Association 2 (15) out: hdac0: Pin nid=22 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 5 traced to DAC 3 hdac0: Pin 6 traced to DAC 3 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 8 traced to ADC 4 hdac0: Pin 24 traced to ADC 4 hdac0: Pin 9 traced to ADC 4 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (15) hdac0: Unable to trace pin 22 seq 0 with min nid 0 hdac0: Association 2 (15) trace failed hdac0: Tracing input monitor hdac0: Tracing nid 12 to out hdac0: Tracing beeper hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=6 [UNSOL] hdac0: Pin sense: nid=6 res=0x8000ec60 hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e007f hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz hdac0: IN amp: 0x00270300 hdac0: OUT amp: 0x80053f3d hdac0: hdac0: nid: 2 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00030311 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x00020060 hdac0: 16 bits, 44 48 KHz hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=1 [GHOST!] [UNKNOWN] (selected) hdac0: + <- nid=4 [audio input] hdac0: hdac0: nid: 3 hdac0: Name: audio output hdac0: Widget cap: 0x00000441 hdac0: PWR PROC STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e007f hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz hdac0: hdac0: nid: 4 hdac0: Name: audio input hdac0: Widget cap: 0x00100511 hdac0: PWR STEREO hdac0: Association: 1 (0x00004003) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x0006007f hdac0: 16 20 bits, 8 11 16 22 32 44 48 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=21 [audio selector] hdac0: hdac0: nid: 5 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400187 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001173f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] EAPD hdac0: Pin config: 0x92174110 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80053f3d hdac0: mute=1 step=63 size=5 offset=61 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3 [audio output] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 6 hdac0: Name: pin: Headphones (Grey Jack) hdac0: Widget cap: 0x00400185 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000001f hdac0: ISC TRQD PDC HP OUT hdac0: Pin config: 0x0321201f hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80053f3d hdac0: mute=1 step=63 size=5 offset=61 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3 [audio output] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x00400104 hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x410710f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80053f3d hdac0: mute=1 step=63 size=5 offset=61 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdac0: hdac0: nid: 8 hdac0: Name: pin: Mic (Grey Jack) hdac0: Widget cap: 0x00400083 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001727 hdac0: ISC TRQD PDC IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x03a12020 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: hdac0: nid: 9 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x00400187 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0181302e hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80053f3d hdac0: mute=1 step=63 size=5 offset=61 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: pin: SPDIF-out (None) hdac0: Widget cap: 0x00400301 hdac0: DIGITAL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x4145f0f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=2 [audio output] [DISABLED] hdac0: hdac0: nid: 11 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: connections: 6 hdac0: | hdac0: + <- nid=3 [audio output] (selected) hdac0: + <- nid=12 [audio mixer] hdac0: + <- nid=9 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: + <- nid=5 [pin: Speaker (Fixed)] hdac0: + <- nid=24 [pin: Mic (Fixed)] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x00200101 hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: connections: 2 hdac0: | hdac0: + <- nid=30 [audio selector] hdac0: + [DISABLED] <- nid=31 [audio selector] [DISABLED] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010c hdac0: Output amp: 0x800b0f0f hdac0: mute=1 step=15 size=11 offset=15 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [beep widget] (selected) hdac0: + <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200101 hdac0: STEREO hdac0: connections: 8 hdac0: | hdac0: + <- nid=13 [audio selector] [DISABLED] hdac0: + <- nid=17 [audio selector] [DISABLED] hdac0: + <- nid=18 [audio selector] [DISABLED] hdac0: + <- nid=19 [audio selector] [DISABLED] hdac0: + <- nid=26 [audio selector] [DISABLED] hdac0: + <- nid=27 [audio selector] [DISABLED] hdac0: + <- nid=28 [audio selector] [DISABLED] hdac0: + <- nid=29 [audio selector] [DISABLED] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200100 hdac0: connections: 1 hdac0: | hdac0: + <- nid=11 [audio selector] [DISABLED] hdac0: hdac0: nid: 16 hdac0: Name: beep widget hdac0: Widget cap: 0x00700000 hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3 [audio output] hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + <- nid=8 [pin: Mic (Grey Jack)] hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + <- nid=9 [pin: Line-in (Blue Jack)] hdac0: hdac0: nid: 20 [DISABLED] hdac0: Name: power widget hdac0: Widget cap: 0x00500500 hdac0: PWR hdac0: connections: 13 hdac0: | hdac0: + <- nid=13 [audio selector] [DISABLED] (selected) hdac0: + <- nid=14 [audio mixer] [DISABLED] hdac0: + <- nid=15 [audio mixer] [DISABLED] hdac0: + <- nid=16 [beep widget] hdac0: + <- nid=19 [audio selector] [DISABLED] hdac0: + <- nid=20 [power widget] [DISABLED] hdac0: + <- nid=21 [audio selector] hdac0: + <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] hdac0: + <- nid=23 [pin: AUX (None)] [DISABLED] hdac0: + <- nid=24 [pin: Mic (Fixed)] hdac0: + <- nid=25 [pin: CD (None)] [DISABLED] hdac0: + <- nid=26 [audio selector] [DISABLED] hdac0: + <- nid=29 [audio selector] [DISABLED] hdac0: hdac0: nid: 21 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004003) hdac0: OSS: line, mic, monitor hdac0: Output amp: 0x80050f00 hdac0: mute=1 step=15 size=5 offset=0 hdac0: connections: 8 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + <- nid=9 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdac0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] hdac0: + [DISABLED] <- nid=5 [pin: Speaker (Fixed)] hdac0: + <- nid=24 [pin: Mic (Fixed)] hdac0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Digital-out (Fixed) hdac0: Widget cap: 0x00400000 hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x995711f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: pin: AUX (None) hdac0: Widget cap: 0x00400081 hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000027 hdac0: ISC TRQD PDC IN hdac0: Pin config: 0x5993e0f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400187 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000002) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x91a79121 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80053f3d hdac0: mute=1 step=63 size=5 offset=61 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 25 [DISABLED] hdac0: Name: pin: CD (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x593310f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + <- nid=5 [pin: Speaker (Fixed)] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + <- nid=24 [pin: Mic (Fixed)] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] hdac0: hdac0: nid: 30 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=8 [pin: Mic (Grey Jack)] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=24 [pin: Mic (Fixed)] hdac0: hdac0: Processing modem FG cad=1 nid=1... hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e007f pcm0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz pcm0: DAC: 3 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x0006007f pcm0: 16 20 bits, 8 11 16 22 32 44 48 KHz pcm0: ADC: 4 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=5 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: pcm0: nid=6 [pin: Headphones (Grey Jack)] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=4 [audio input] pcm0: | pcm0: + <- nid=21 [audio selector] [src: line, mic, monitor] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: mic] pcm0: | pcm0: + <- nid=30 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=24 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 5 in ): -91/3dB (64 steps) + mute pcm0: +- ctl 3 (nid 6 in ): -91/3dB (64 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 5 in ): -91/3dB (64 steps) + mute pcm0: +- ctl 3 (nid 6 in ): -91/3dB (64 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 5 (nid 8 out): 0/30dB (4 steps) pcm0: +- ctl 19 (nid 30 out): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor) pcm0: | pcm0: +- ctl 14 (nid 24 out): 0/30dB (4 steps) pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 7 (nid 9 out): 0/30dB (4 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute pcm0: +- ctl 19 (nid 30 out): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 2190000, 4000; 0xe6918000 -> 2190000 pcm0: sndbuf_setmap 21a0000, 4000; 0xe6928000 -> 21a0000 --- WBR, Andrey Kosachenko From owner-freebsd-current@FreeBSD.ORG Mon May 18 21:46:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117CE106567D for ; Mon, 18 May 2009 21:46:34 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4398FC12 for ; Mon, 18 May 2009 21:46:32 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bvA9ArPTLE4A:10 a=wUE4w7GWRSwA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=pGLkceISAAAA:8 a=ciXaXG2MCObTuAzfgLEA:9 a=g_etLkPB33tYeuKBH0ILilD3Jx8A:4 a=MSl-tDqOz04A:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1243128415; Mon, 18 May 2009 23:46:31 +0200 Received-SPF: softfail receiver=mailfe08.swip.net; client-ip=62.113.132.61; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 18 May 2009 23:49:05 +0200 User-Agent: KMail/1.9.7 References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> In-Reply-To: <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905182349.06150.hselasky@freebsd.org> Cc: Lucius Windschuh , Weongyo Jeong Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 21:46:34 -0000 On Sunday 17 May 2009, Lucius Windschuh wrote: > 2009/4/7 Weongyo Jeong > Here's one more device, which is currently not listed in if_uath.c: ugen3.10: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x1385 idProduct = 0x5f01 bcdDevice = 0x0001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001 Resulting dmesg after running uathload: uath0: timeout waiting for reply to cmd 0x4 (4) uath0: could not read capability 2 uath0: could not get device capabilities device_attach: uath0 attach returned 35 uath0: timeout waiting for reply to cmd 0x1 (1) uath0: could not initialize adapter device_attach: uath0 attach returned 35 Can this be fixed? --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 21:48:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028AE10656E0 for ; Mon, 18 May 2009 21:48:30 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5F49B8FC08 for ; Mon, 18 May 2009 21:48:29 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bvA9ArPTLE4A:10 a=wUE4w7GWRSwA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=pGLkceISAAAA:8 a=ot-8-Ia_Vng62H1EAtAA:9 a=V-mmI-CU-tALfxxusG-5s2T9E_YA:4 a=MSl-tDqOz04A:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 497151108; Mon, 18 May 2009 23:48:28 +0200 Received-SPF: softfail receiver=mailfe15.swip.net; client-ip=62.113.132.61; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org User-Agent: KMail/1.9.7 References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> In-Reply-To: <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 18 May 2009 23:51:03 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905182351.03891.hselasky@freebsd.org> Cc: Lucius Windschuh , Weongyo Jeong Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 21:48:30 -0000 On Sunday 17 May 2009, Lucius Windschuh wrote: > 2009/4/7 Weongyo Jeong > Device descriptor after running uathload. "idProduct" changed. ugen3.10: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x1385 idProduct = 0x5f02 bcdDevice = 0x0001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001 --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 18 22:08:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9873106566B for ; Mon, 18 May 2009 22:08:46 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by mx1.freebsd.org (Postfix) with ESMTP id 612C08FC15 for ; Mon, 18 May 2009 22:08:46 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by gxk10 with SMTP id 10so3286485gxk.19 for ; Mon, 18 May 2009 15:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LhX2SPr0ZA/uAK1nKG/YRdiEbxaMPtm7Lw9E1fRQIww=; b=ORoFNvAcl9Z6LV/VdR4Zz9VLV+8z+sBbEDB8Q0WvmZN+QgLnuMbG1ghBa6sghqxdMN FlDkdsFoXxqLPdxwGZFhM5liIF4SF2EwsETpbuGgm59kk6Is51EJaSZNsZktLBsXGqSG l6LDolWZ4ZvXqir2j3Q0bnT/Yc84ZQQBKWRG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=m8qV+nBOF+APvUclyTDIbBrHkb+5fn+nwUBOO4oSa9CPYCJiYQbPV1Z+P+sE6ET/nr oZTxvfb93vzxfKNI/wsL3mtD74ntuBaxZtfMaKGYoiNPhE53aHTNlXdY1uU9We7OGo3X 4iJaf7dEssY+E+32TVetZsr1qq2QYaTRFuW3c= MIME-Version: 1.0 Received: by 10.151.131.5 with SMTP id i5mr13603359ybn.18.1242684525833; Mon, 18 May 2009 15:08:45 -0700 (PDT) In-Reply-To: <200905181050.03154.hselasky@c2i.net> References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <200905181050.03154.hselasky@c2i.net> Date: Tue, 19 May 2009 00:08:45 +0200 Message-ID: <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> From: Lucius Windschuh To: freebsd-current@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 22:08:47 -0000 2009/5/18 Hans Petter Selasky : > Regarding the first panic, there seems to be a detach race in both upgt and > uath, which is not USB related. Try this patch: > > http://perforce.freebsd.org/chv.cgi?CH=162250 This fixes not only the first panic. I can't provoke any panic by pulling out the active device. Thanks. Lucius From owner-freebsd-current@FreeBSD.ORG Mon May 18 23:32:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28ADB106564A for ; Mon, 18 May 2009 23:32:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id D8BEC8FC15 for ; Mon, 18 May 2009 23:32:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:28773 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6CJo-000EBE-S9; Mon, 18 May 2009 18:32:34 -0500 Date: Mon, 18 May 2009 18:32:13 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Adam McDougall In-Reply-To: Message-ID: References: <20090518145614.GF82547@egr.msu.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.6 (/) X-LERCTR-Spam-Score: 0.6 (/) X-Spam-Report: SpamScore (0.6/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 X-LERCTR-Spam-Report: SpamScore (0.6/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 DomainKey-Status: no signature Cc: current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 23:32:36 -0000 On Mon, 18 May 2009, Larry Rosenman wrote: > On Mon, 18 May 2009, Adam McDougall wrote: > >> I'm not sure if this is related to recent kernel memory code changes >> or what, but it hasn't happened with code from earlier than a couple >> days ago. I had this happen twice, I think the first time was with >> arc max set to 1024M, the second time was when arc max was unset in >> loader.conf and the system had been up a few hours but the arc hadn't >> been squeezed down to a small number yet: >> Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M Free >> >> I've deleted the kernel since then but I did not change my sources, >> I could build a new one and check where the pointers point to I think? >> If needed. Or I could reproduce the panic if needed. It doesn't dump, >> it just gets stuck after printing the panic. > I wonder if this is the same crash I saw without getting all the info. > > What I saw was the wired memory getting to be most of the memory on the box, > and then boom. > > see my post a few above this. Ok, something(tm) is seriously messed up. I was able to get my hands on 12G more memory, and with that, the backup finishes, but the wired count is insane: last pid: 1760; load averages: 5.46, 7.01, 6.43 up 0+00:37:54 18:31:41 78 processes: 5 running, 73 sleeping Mem: 440M Active, 4020K Inact, 13G Wired, 524K Cache, 441M Buf, 1970M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1403 ler 1 138 20 141M 118M RUN 2 31:53 100.00% FahCore_7 1400 ler 1 138 20 141M 117M CPU0 0 31:51 100.00% FahCore_7 1397 ler 1 138 20 141M 118M CPU3 3 31:46 100.00% FahCore_7 1235 ler 1 138 20 20072K 11404K CPU1 1 31:34 100.00% FahCore_7 1209 ler 1 44 20 141M 118M nanslp 0 0:07 0.00% FahCore_78 1206 ler 1 44 20 141M 117M nanslp 0 0:07 0.00% FahCore_78 1207 ler 1 44 20 141M 118M nanslp 2 0:06 0.00% FahCore_78 1098 pgsql 1 44 0 62052K 34948K select 2 0:02 0.00% postgres 1069 root 1 44 0 19096K 6172K nanslp 0 0:01 0.00% perl 1202 ler 1 44 0 194M 776K nanslp 2 0:00 0.00% fah6 1203 ler 1 44 0 194M 776K nanslp 1 0:00 0.00% fah6 1204 ler 1 44 0 194M 776K nanslp 1 0:00 0.00% fah6 1205 ler 1 44 0 194M 768K nanslp 1 0:00 0.00% fah6 1095 pgsql 1 44 0 62052K 5664K select 0 0:00 0.00% postgres 1208 ler 1 44 20 20072K 11404K nanslp 2 0:00 0.00% FahCore_78 1756 ler 1 44 0 23900K 8672K nanslp 0 0:00 0.00% alpine 988 root 1 44 0 10612K 2376K select 2 0:00 0.00% ntpd 1182 root 1 44 0 17636K 7048K nanslp 2 0:00 0.00% perl Sysctl -a: kern.ostype: FreeBSD kern.osrelease: 8.0-CURRENT kern.osrevision: 199506 kern.version: FreeBSD 8.0-CURRENT #18: Mon May 18 04:18:03 CDT 2009 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG kern.maxvnodes: 100000 kern.maxproc: 6164 kern.maxfiles: 12328 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: borg.lerctr.org kern.hostid: 3935026275 kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1242687257, usec = 281783 } Mon May 18 17:54:17 2009 kern.domainname: kern.osreldate: 800087 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 11095 kern.maxprocperuid: 5547 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 92 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 25600 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 98304 kern.ipc.maxpipekva: 277905408 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 152 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 4096 kern.ipc.semmni: 2048 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 8192000 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 819200000 kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 63 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 kern.dummy: 0 kern.ps_strings: 140737488355296 kern.usrstack: 140737488355328 kern.logsigexit: 1 kern.iov_max: 1024 kern.hostuuid: 53D19F64-D663-A017-8922-003048339480 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.cd.retry_count: 4 kern.cam.cd.changer.max_busy_seconds: 15 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.cd.0.minimum_cmd_size: 10 kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.rndtest.verbose: 1 kern.rndtest.retest: 120 kern.disks: cd0 ad14 ad12 ad10 ad8 ad6 ad4 kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.elf64.fallback_brand: -1 kern.init_shutdown_timeout: 120 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_suspended: 0 kern.acct_configured: 0 kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_times: 3050 257577 31202 420 9098 2948 258837 29420 2264 7280 2800 260523 30701 171 6615 2523 263506 27118 122 7538 kern.cp_time: 11321 1040443 118441 2977 30531 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: ttyv0,/ttyv0,uart,gdb, kern.openfiles: 220 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 1762 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules kern.malloc_count: 267 kern.fallback_elf_brand: -1 kern.features.compat_freebsd7: 1 kern.features.compat_freebsd6: 1 kern.features.compat_freebsd5: 1 kern.features.compat_freebsd4: 1 kern.features.posix_shm: 1 kern.maxusers: 384 kern.ident: BORG kern.kstack_pages: 4 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 1 kern.sugid_coredump: 0 kern.sigqueue.alloc_fail: 0 kern.sigqueue.overflow: 0 kern.sigqueue.preallocate: 1024 kern.sigqueue.max_pending_per_proc: 128 kern.forcesigexit: 1 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 62178 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 3310006 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2523974339 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1218885212 kern.timecounter.tc.TSC.frequency: 1862013503 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.threads.max_threads_hits: 0 kern.threads.max_threads_per_proc: 1500 kern.ccpu: 0 kern.sched.preemption: 1 kern.sched.topology_spec: 0, 1, 2, 3 0, 1 2, 3 kern.sched.steal_thresh: 2 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 4 kern.sched.idlespins: 10000 kern.sched.static_boost: 160 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE kern.devstat.version: 6 kern.devstat.generation: 225 kern.devstat.numdevs: 9 kern.kobj_methodcount: 155 kern.log_wakeups_per_second: 5 kern.vm_guest: none kern.sgrowsiz: 131072 kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 kern.maxbcache: 1073741824 kern.maxswzone: 33554432 kern.nswbuf: 256 kern.nbuf: 65536 kern.ncallout: 18508 kern.hz: 1000 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_output: 1 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.topology: 0 kern.smp.cpus: 4 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 32 kern.smp.maxid: 3 kern.tty_inq_nslow: 297 kern.tty_inq_nfast: 1701 kern.tty_outq_nslow: 0 kern.tty_outq_nfast: 0 kern.pts_maxdev: 999 kern.tty_pty_warningcnt: 10 kern.tty_nout: 4730961 kern.tty_nin: 2138 kern.minvnodes: 25000 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.cryptodevallowsoft: 0 kern.userasymcrypto: 1 kern.rpc.invalid: 0 kern.rpc.unexpected: 0 kern.rpc.timeouts: 0 kern.rpc.request: 0 kern.rpc.retries: 0 kern.elf32.fallback_brand: -1 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 5 Disk Wait: 0 Page Wait: 0 Sleep: 73) Virtual Memory: (Total: 1076206992K, Active 2349180K) Real Memory: (Total: 1103632K Active 455252K) Shared Virtual Memory: (Total: 20708K Active: 14128K) Shared Real Memory: (Total: 9388K Active: 8756K) Free Memory Pages: 2017432K vm.loadavg: { 5.08 6.77 6.36 } vm.v_free_min: 25703 vm.v_free_target: 108162 vm.v_free_reserved: 5350 vm.v_inactive_target: 162243 vm.v_cache_min: 108162 vm.v_cache_max: 216324 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 5558173696 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone_count: 98 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 59 vm.stats.misc.cnt_prezero: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 2236 vm.stats.vm.v_vforkpages: 39693 vm.stats.vm.v_forkpages: 363901 vm.stats.vm.v_kthreads: 141 vm.stats.vm.v_rforks: 28 vm.stats.vm.v_vforks: 198 vm.stats.vm.v_forks: 1395 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 216324 vm.stats.vm.v_cache_min: 108162 vm.stats.vm.v_cache_count: 123 vm.stats.vm.v_inactive_count: 1005 vm.stats.vm.v_inactive_target: 162243 vm.stats.vm.v_active_count: 112687 vm.stats.vm.v_wire_count: 3452797 vm.stats.vm.v_free_count: 504231 vm.stats.vm.v_free_min: 25703 vm.stats.vm.v_free_target: 108162 vm.stats.vm.v_free_reserved: 5350 vm.stats.vm.v_page_count: 4070929 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 19085156 vm.stats.vm.v_pfree: 612782 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 3100 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_reactivated: 2925 vm.stats.vm.v_intrans: 704 vm.stats.vm.v_vnodepgsout: 1 vm.stats.vm.v_vnodepgsin: 6890 vm.stats.vm.v_vnodeout: 1 vm.stats.vm.v_vnodein: 5806 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 27 vm.stats.vm.v_zfod: 2565409 vm.stats.vm.v_cow_optim: 397 vm.stats.vm.v_cow_faults: 64414 vm.stats.vm.v_vm_faults: 2768133 vm.stats.sys.v_soft: 1359531 vm.stats.sys.v_intr: 715196 vm.stats.sys.v_syscall: 6458471 vm.stats.sys.v_trap: 6074556 vm.stats.sys.v_swtch: 8393310 vm.stats.object.bypasses: 757 vm.stats.object.collapses: 5656 vm.v_free_severe: 15526 vm.max_proc_mmap: 496265 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.boot_pages: 48 vm.max_wired: 1345352 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 108162 vm.max_launder: 32 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x98000 free list: 0xffffffff80849668 SEGMENT 1: start: 0xb8a000 end: 0x1000000 free list: 0xffffffff80849668 SEGMENT 2: start: 0x1000000 end: 0xcff50000 free list: 0xffffffff808492c0 SEGMENT 3: start: 0x100000000 end: 0x4129b4000 free list: 0xffffffff808492c0 vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 91 | 0 | 0 11 ( 8192K) | 3 | 1 | 0 10 ( 4096K) | 7 | 1 | 0 9 ( 2048K) | 0 | 1 | 0 8 ( 1024K) | 4 | 1 | 0 7 ( 512K) | 10 | 0 | 0 6 ( 256K) | 7 | 0 | 0 5 ( 128K) | 11 | 0 | 0 4 ( 64K) | 32 | 0 | 0 3 ( 32K) | 246 | 0 | 0 2 ( 16K) | 929 | 3 | 1 1 ( 8K) | 1849 | 1 | 7 0 ( 4K) | 9492 | 0 | 73 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 1 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 2 | 0 | 0 5 ( 128K) | 2 | 0 | 0 4 ( 64K) | 2 | 0 | 0 3 ( 32K) | 2 | 0 | 0 2 ( 16K) | 2 | 0 | 0 1 ( 8K) | 3 | 0 | 0 0 ( 4K) | 0 | 0 | 0 vm.reserv.reclaimed: 0 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 362368K, 326 vm.reserv.freed: 11598 vm.reserv.broken: 8 vm.idlezero_enable: 0 vm.kvm_free: 542615007232 vm.kvm_size: 549755809792 vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 8566 vm.pmap.pv_entry_allocs: 3744878 vm.pmap.pv_entry_frees: 3679188 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 13290 vm.pmap.pc_chunk_allocs: 13732 vm.pmap.pc_chunk_count: 442 vm.pmap.pv_entry_count: 65690 vm.pmap.pdpe.demotions: 0 vm.pmap.pde.promotions: 110851 vm.pmap.pde.p_failures: 1022233 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 107618 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 5303729 vm.pmap.pg_ps_enabled: 1 vfs.zfs.arc_meta_limit: 4023481344 vfs.zfs.arc_meta_used: 1192541184 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 2011740672 vfs.zfs.arc_max: 16093925376 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 0 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 1 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 39648 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_minsize: 2560 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 139 vfs.nfs4.access_cache_timeout: 60 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 0 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs.prime_access_cache: 0 vfs.nfs.access_cache_timeout: 60 vfs.pfs.trace: 0 vfs.pfs.vncache.misses: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.entries: 0 vfs.flushwithdeps: 0 vfs.notbufdflashes: 0 vfs.flushbufqtarget: 100 vfs.getnewbufrestarts: 0 vfs.getnewbufcalls: 28204 vfs.hifreebuffers: 7290 vfs.lofreebuffers: 3645 vfs.numfreebuffers: 65534 vfs.dirtybufthresh: 14763 vfs.hidirtybuffers: 16404 vfs.lodirtybuffers: 8202 vfs.numdirtybuffers: 2 vfs.recursiveflushes: 0 vfs.altbufferflushes: 0 vfs.bdwriteskip: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 28198 vfs.hibufspace: 1073086464 vfs.lobufspace: 1073020928 vfs.maxmallocbufspace: 53654323 vfs.bufmallocspace: 0 vfs.maxbufspace: 1073741824 vfs.bufspace: 461996032 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 124 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathcalls: 124 vfs.cache.nchstats: 4488983 27354 228 0 466972 0 33 156 vfs.cache.numupgrades: 28 vfs.cache.numneghits: 27354 vfs.cache.numnegzaps: 57 vfs.cache.numposhits: 4488983 vfs.cache.numposzaps: 171 vfs.cache.nummisszap: 309 vfs.cache.nummiss: 466663 vfs.cache.numchecks: 5829112 vfs.cache.dotdothits: 47 vfs.cache.dothits: 1035 vfs.cache.numcalls: 4984636 vfs.cache.numcache: 30787 vfs.cache.numneg: 766 vfs.read_max: 8 vfs.write_behind: 1 vfs.lookup_shared: 1 vfs.usermount: 1 vfs.worklist_len: 1 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 611 vfs.freevnodes: 24986 vfs.wantfreevnodes: 25000 vfs.numvnodes: 29998 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.fha.bin_shift: 18 vfs.nfsrv.fha.max_nfsds_per_fh: 8 vfs.nfsrv.fha.max_reqs_per_nfsd: 4 vfs.nfsrv.fha.fhe_stats: No file handle entries. vfs.nfsrv.commit_miss: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.async: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.gatherdelay_v3: 0 vfs.nfsrv.gatherdelay: 10000 vfs.nfsrv.minthreads: 4 vfs.nfsrv.maxthreads: 4 vfs.nfsrv.threads: 4 vfs.nfsrv.request_space_used: 0 vfs.nfsrv.request_space_used_highest: 0 vfs.nfsrv.request_space_high: 13107200 vfs.nfsrv.request_space_low: 8738133 vfs.nfsrv.request_space_throttled: 0 vfs.nfsrv.request_space_throttle_count: 0 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.taskcount: 0 net.local.recycled: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.random_id_total: 0 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_period: 8192 net.inet.ip.mcast.loop: 1 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 800 net.inet.ip.output_flowtable_size: 0 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.igmp.gsrdelay: 10 net.inet.igmp.default_version: 3 net.inet.igmp.legacysupp: 0 net.inet.igmp.v2enable: 1 net.inet.igmp.v1enable: 1 net.inet.igmp.sendlocal: 1 net.inet.igmp.sendra: 1 net.inet.igmp.recvifkludge: 1 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 3 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.wlock_looped: 0 net.inet.tcp.wlock_relocked: 0 net.inet.tcp.wlock_upgraded: 262 net.inet.tcp.tcp_wlock_atfirst: 416 net.inet.tcp.rlock_atfirst: 829900 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 26 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.sctp.nat_friendly_init: 1 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.early_fast_retran_msec: 250 net.inet.sctp.early_fast_retran: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_pf: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 3200 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.ecn_nonce: 0 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 233016 net.inet.sctp.sendspace: 233016 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 net.inet.flowtable.nmbflows: 4096 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.collisions: 0 net.inet.flowtable.max_depth: 0 net.inet.flowtable.free_checks: 0 net.inet.flowtable.frees: 0 net.inet.flowtable.misses: 0 net.inet.flowtable.lookups: 0 net.inet.flowtable.hits: 0 net.inet.flowtable.enable: 0 net.link.generic.system.ifcount: 3 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 0 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.maxgrpsrc: 512 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.inet6.mld.gsrdelay: 10 net.bpf.zerocopy_enable: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 419599 net.isr.drop: 0 net.isr.queued: 830117 net.isr.deferred: 0 net.isr.directed: 3109 net.isr.count: 3109 net.isr.direct: 1 net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.route.netisr_maxqlen: 256 debug.ddb.capture.bufsize: 49152 debug.ddb.capture.inprogress: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.bufoff: 0 debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: debug.ddb.textdump.do_version: 1 debug.ddb.textdump.do_panic: 1 debug.ddb.textdump.do_msgbuf: 1 debug.ddb.textdump.do_ddb: 1 debug.ddb.textdump.do_config: 1 debug.ddb.textdump.pending: 0 debug.ddb_use_printf: 0 debug.acpi.semaphore_debug: 0 debug.acpi.suspend_bounce: 0 debug.acpi.reset_clock: 1 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 20070320 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 debug.mddebug: 0 debug.gdbcons: 0 debug.elf64_legacy_coredump: 0 debug.bootverbose: 0 debug.boothowto: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.sizeof.cdev_priv: 376 debug.sizeof.cdev: 288 debug.sizeof.g_bioq: 56 debug.sizeof.g_consumer: 96 debug.sizeof.g_provider: 136 debug.sizeof.g_geom: 136 debug.sizeof.g_class: 136 debug.sizeof.kinfo_proc: 1088 debug.sizeof.buf: 600 debug.sizeof.bio: 216 debug.sizeof.proc: 1112 debug.sizeof.vnode: 472 debug.sizeof.devstat: 288 debug.sizeof.namecache: 72 debug.sizeof.znode: 376 debug.osd: 0 debug.rwlock.loops: 10000 debug.rwlock.retry: 10 debug.trace_on_panic: 1 debug.debugger_on_panic: 0 debug.to_avg_mpcalls: 515 debug.to_avg_lockcalls: 1 debug.to_avg_gcalls: 255 debug.to_avg_depth: 1017 debug.umtx.umtx_pi_allocated: 0 debug.kdb.stop_cpus: 1 debug.kdb.trap_code: 0 debug.kdb.trap: 0 debug.kdb.panic: 0 debug.kdb.enter: 0 debug.kdb.current: ddb debug.kdb.available: ddb debug.rman_debug: 0 debug.ttydebug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.vfscache: 1 debug.numcachehv: 2066 debug.numcache: 30787 debug.numneg: 766 debug.ncnegfactor: 16 debug.nchash: 131071 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.mpsafevfs: 1 debug.if_tun_debug: 0 debug.nlm_debug: 0 debug.crypto_timing: 0 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.dir_entry: 0 debug.direct_blk_ptrs: 0 debug.inode_bitmap: 0 debug.indir_blk_ptrs: 0 debug.sync_limit_hit: 0 debug.ino_limit_hit: 0 debug.blk_limit_hit: 0 debug.ino_limit_push: 0 debug.blk_limit_push: 0 debug.worklist_push: 0 debug.maxindirdeps: 50 debug.tickdelay: 2 debug.max_softdeps: 400000 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.minidump: 1 debug.psm.pkterrthresh: 2 debug.psm.usecs: 500000 debug.psm.secs: 0 debug.psm.errusecs: 0 debug.psm.errsecs: 2 debug.psm.hz: 20 debug.psm.loglevel: 0 debug.fdc.settle: 125 debug.fdc.spec2: 16 debug.fdc.spec1: 175 debug.fdc.retries: 10 debug.fdc.debugflags: 0 debug.fdc.fifo: 8 debug.elf32_legacy_coredump: 0 debug.hwpstate_verbose: 0 hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz hw.ncpu: 4 hw.byteorder: 1234 hw.physmem: 17167667200 hw.usermem: 3024932864 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 17985175552 hw.ata.setmax: 0 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.syscons.bell: 1 hw.syscons.saver.keybonly: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.usb2.ehci.no_hs: 0 hw.usb2.ehci.debug: 0 hw.usb2.uhci.loop: 0 hw.usb2.uhci.debug: 0 hw.usb2.ctrl.debug: 0 hw.usb2.umass.debug: 0 hw.usb2.urio.debug: 0 hw.usb2.debug: 0 hw.usb2.dev.debug: 0 hw.usb2.template: 0 hw.usb2.ugen.debug: 0 hw.usb2.power_timeout: 30 hw.usb2.uhub.debug: 0 hw.usb2.proc.debug: 0 hw.usb2.ss_delay: 0 hw.usb2.pr_recovery_delay: 250 hw.usb2.pr_poll_delay: 50 hw.usb2.ulpt.debug: 0 hw.usb2.ucom.debug: 0 hw.usb2.uhid.debug: 0 hw.usb2.ukbd.debug: 0 hw.usb2.ums.debug: 0 hw.intr_storm_threshold: 1000 hw.availpages: 4191325 hw.bus.devctl_disable: 0 hw.busdma.total_bpages: 8202 hw.busdma.zone0.total_bpages: 8202 hw.busdma.zone0.free_bpages: 8202 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 639896 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 4096 hw.clockrate: 1862 hw.via_feature_xcrypt: 0 hw.via_feature_rng: 0 hw.instruction_sse: 1 hw.apic.enable_extint: 0 hw.psm.tap_timeout: 125000 hw.psm.tap_threshold: 25 hw.ipmi.on: 1 hw.kbd.keymap_restrict_change: 0 hw.mca.count: 0 hw.mca.interval: 3600 hw.mca.force_scan: 0 hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: NONE hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 1 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.dri.0.name: radeon 0x2a hw.dri.0.vm: slot offset size type flags address mtrr 0 0x00000000d8200000 0x00010000 REG 0x82 0xffffff00d8200000 no hw.dri.0.clients: a dev pid uid magic ioctls hw.dri.0.debug: 0 machdep.acpi_timer_freq: 3579545 machdep.enable_panic_key: 0 machdep.adjkerntz: 18000 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.acpi_root: 1007888 machdep.disable_mtrrs: 0 machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, machdep.hlt_cpus: 0 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.tsc_freq: 1862013503 machdep.i8254_freq: 1193182 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 10 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 security.jail.jailed: 0 security.jail.param.host.hostname: 256 security.jail.param.securelevel: 0 security.jail.param.path: 1024 security.jail.param.cpuset: 0 security.jail.param.name: 256 security.jail.param.jid: 0 security.jail.param.linux.oss_version: 0 security.jail.param.linux.osrelease: 65 security.jail.param.linux.osname: 65 security.jail.jail_max_af_ips: 255 security.jail.mount_allowed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.ram.0.%desc: System RAM dev.ram.0.%driver: ram dev.ram.0.%parent: nexus0 dev.smbios.0.%desc: System Management BIOS dev.smbios.0.%driver: smbios dev.smbios.0.%parent: nexus0 dev.cryptosoft.0.%desc: software crypto dev.cryptosoft.0.%driver: cryptosoft dev.cryptosoft.0.%parent: nexus0 dev.acpi.0.%desc: SMCI SMCISLP2 dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.LPC0.MBRD dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=31 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.PCI0.LPC0.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.PCI0.LPC0.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.PCI0.LPC0.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.PCI0.LPC0.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.PCI0.LPC0.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.PCI0.LPC0.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.PCI0.LPC0.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.PCI0.LPC0.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.acpi_hpet.0.%desc: High Precision Event Timer dev.acpi_hpet.0.%driver: acpi_hpet dev.acpi_hpet.0.%location: unknown dev.acpi_hpet.0.%pnpinfo: unknown dev.acpi_hpet.0.%parent: acpi0 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=0 dev.pcib.0.%parent: acpi0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=2 function=0 handle=\_SB_.PCI0.P0P2 dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x25f7 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.domain: 0 dev.pcib.1.pribus: 0 dev.pcib.1.secbus: 1 dev.pcib.1.subbus: 7 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x3500 subvendor=0x15d9 subdevice=0x8080 class=0x060400 dev.pcib.2.%parent: pci1 dev.pcib.2.domain: 0 dev.pcib.2.pribus: 1 dev.pcib.2.secbus: 2 dev.pcib.2.subbus: 6 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0.BPD0 dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x3510 subvendor=0x15d9 subdevice=0x8080 class=0x060400 dev.pcib.3.%parent: pci2 dev.pcib.3.domain: 0 dev.pcib.3.pribus: 2 dev.pcib.3.secbus: 3 dev.pcib.3.subbus: 5 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH0 dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x0329 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.4.%parent: pci3 dev.pcib.4.domain: 0 dev.pcib.4.pribus: 3 dev.pcib.4.secbus: 4 dev.pcib.4.subbus: 4 dev.pcib.4.wake: 0 dev.pcib.5.%desc: ACPI PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=0 function=2 handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH1 dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x032a subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.5.%parent: pci3 dev.pcib.5.domain: 0 dev.pcib.5.pribus: 3 dev.pcib.5.secbus: 5 dev.pcib.5.subbus: 5 dev.pcib.5.wake: 0 dev.pcib.6.%desc: ACPI PCI-PCI bridge dev.pcib.6.%driver: pcib dev.pcib.6.%location: slot=2 function=0 handle=\_SB_.PCI0.P0P2.BMD0.BPD2 dev.pcib.6.%pnpinfo: vendor=0x8086 device=0x3518 subvendor=0x15d9 subdevice=0x8080 class=0x060400 dev.pcib.6.%parent: pci2 dev.pcib.6.domain: 0 dev.pcib.6.pribus: 2 dev.pcib.6.secbus: 6 dev.pcib.6.subbus: 6 dev.pcib.6.wake: 0 dev.pcib.7.%desc: ACPI PCI-PCI bridge dev.pcib.7.%driver: pcib dev.pcib.7.%location: slot=0 function=3 handle=\_SB_.PCI0.P0P2.BMF3 dev.pcib.7.%pnpinfo: vendor=0x8086 device=0x350c subvendor=0x15d9 subdevice=0x8080 class=0x060400 dev.pcib.7.%parent: pci1 dev.pcib.7.domain: 0 dev.pcib.7.pribus: 1 dev.pcib.7.secbus: 7 dev.pcib.7.subbus: 7 dev.pcib.7.wake: 0 dev.pcib.8.%desc: ACPI PCI-PCI bridge dev.pcib.8.%driver: pcib dev.pcib.8.%location: slot=4 function=0 handle=\_SB_.PCI0.P0P4 dev.pcib.8.%pnpinfo: vendor=0x8086 device=0x25f8 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.8.%parent: pci0 dev.pcib.8.domain: 0 dev.pcib.8.pribus: 0 dev.pcib.8.secbus: 8 dev.pcib.8.subbus: 8 dev.pcib.8.wake: 0 dev.pcib.9.%desc: ACPI PCI-PCI bridge dev.pcib.9.%driver: pcib dev.pcib.9.%location: slot=6 function=0 handle=\_SB_.PCI0.P0P6 dev.pcib.9.%pnpinfo: vendor=0x8086 device=0x25f9 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.9.%parent: pci0 dev.pcib.9.domain: 0 dev.pcib.9.pribus: 0 dev.pcib.9.secbus: 9 dev.pcib.9.subbus: 9 dev.pcib.9.wake: 0 dev.pcib.10.%desc: ACPI PCI-PCI bridge dev.pcib.10.%driver: pcib dev.pcib.10.%location: slot=28 function=0 handle=\_SB_.PCI0.PEX0 dev.pcib.10.%pnpinfo: vendor=0x8086 device=0x2690 subvendor=0x15d9 subdevice=0x8080 class=0x060400 dev.pcib.10.%parent: pci0 dev.pcib.10.domain: 0 dev.pcib.10.pribus: 0 dev.pcib.10.secbus: 10 dev.pcib.10.subbus: 10 dev.pcib.10.wake: 0 dev.pcib.11.%desc: ACPI PCI-PCI bridge dev.pcib.11.%driver: pcib dev.pcib.11.%location: slot=30 function=0 handle=\_SB_.PCI0.PCIB dev.pcib.11.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x15d9 subdevice=0x8080 class=0x060401 dev.pcib.11.%parent: pci0 dev.pcib.11.domain: 0 dev.pcib.11.pribus: 0 dev.pcib.11.secbus: 11 dev.pcib.11.subbus: 11 dev.pcib.11.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%parent: pcib4 dev.pci.4.wake: 0 dev.pci.5.%desc: ACPI PCI bus dev.pci.5.%driver: pci dev.pci.5.%parent: pcib5 dev.pci.5.wake: 0 dev.pci.6.%desc: ACPI PCI bus dev.pci.6.%driver: pci dev.pci.6.%parent: pcib6 dev.pci.6.wake: 0 dev.pci.7.%desc: ACPI PCI bus dev.pci.7.%driver: pci dev.pci.7.%parent: pcib7 dev.pci.7.wake: 0 dev.pci.8.%desc: ACPI PCI bus dev.pci.8.%driver: pci dev.pci.8.%parent: pcib8 dev.pci.8.wake: 0 dev.pci.9.%desc: ACPI PCI bus dev.pci.9.%driver: pci dev.pci.9.%parent: pcib9 dev.pci.9.wake: 0 dev.pci.10.%desc: ACPI PCI bus dev.pci.10.%driver: pci dev.pci.10.%parent: pcib10 dev.pci.10.wake: 0 dev.pci.11.%desc: ACPI PCI bus dev.pci.11.%driver: pci dev.pci.11.%parent: pcib11 dev.pci.11.wake: 0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x25d8 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.0.%parent: pci0 dev.hostb.1.%desc: Host to PCI bridge dev.hostb.1.%driver: hostb dev.hostb.1.%location: slot=16 function=0 dev.hostb.1.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.1.%parent: pci0 dev.hostb.2.%desc: Host to PCI bridge dev.hostb.2.%driver: hostb dev.hostb.2.%location: slot=16 function=1 dev.hostb.2.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.2.%parent: pci0 dev.hostb.3.%desc: Host to PCI bridge dev.hostb.3.%driver: hostb dev.hostb.3.%location: slot=16 function=2 dev.hostb.3.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.3.%parent: pci0 dev.hostb.4.%desc: Host to PCI bridge dev.hostb.4.%driver: hostb dev.hostb.4.%location: slot=17 function=0 dev.hostb.4.%pnpinfo: vendor=0x8086 device=0x25f1 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.4.%parent: pci0 dev.hostb.5.%desc: Host to PCI bridge dev.hostb.5.%driver: hostb dev.hostb.5.%location: slot=19 function=0 dev.hostb.5.%pnpinfo: vendor=0x8086 device=0x25f3 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.5.%parent: pci0 dev.hostb.6.%desc: Host to PCI bridge dev.hostb.6.%driver: hostb dev.hostb.6.%location: slot=21 function=0 dev.hostb.6.%pnpinfo: vendor=0x8086 device=0x25f5 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.6.%parent: pci0 dev.hostb.7.%desc: Host to PCI bridge dev.hostb.7.%driver: hostb dev.hostb.7.%location: slot=22 function=0 dev.hostb.7.%pnpinfo: vendor=0x8086 device=0x25f6 subvendor=0x15d9 subdevice=0x8080 class=0x060000 dev.hostb.7.%parent: pci0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.1.%parent: pci6 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=29 function=0 handle=\_SB_.PCI0.USB1 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2688 subvendor=0x15d9 subdevice=0x8080 class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.0.wake: 0 dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=29 function=1 handle=\_SB_.PCI0.USB2 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2689 subvendor=0x15d9 subdevice=0x8080 class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.1.wake: 0 dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=29 function=2 handle=\_SB_.PCI0.USB3 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x268a subvendor=0x15d9 subdevice=0x8080 class=0x0c0300 dev.uhci.2.%parent: pci0 dev.uhci.2.wake: 0 dev.usbus.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 dev.usbus.0.%driver: usbus dev.usbus.0.%parent: uhci0 dev.usbus.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 dev.usbus.1.%driver: usbus dev.usbus.1.%parent: uhci1 dev.usbus.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 dev.usbus.2.%driver: usbus dev.usbus.2.%parent: uhci2 dev.usbus.3.%desc: Intel 63XXESB USB 2.0 controller dev.usbus.3.%driver: usbus dev.usbus.3.%parent: ehci0 dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=29 function=7 handle=\_SB_.PCI0.EUSB dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x268c subvendor=0x15d9 subdevice=0x8080 class=0x0c0320 dev.ehci.0.%parent: pci0 dev.ehci.0.wake: 0 dev.vgapci.0.%desc: VGA-compatible display dev.vgapci.0.%driver: vgapci dev.vgapci.0.%location: slot=1 function=0 dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x515e subvendor=0x15d9 subdevice=0x8080 class=0x030000 dev.vgapci.0.%parent: pci11 dev.drm.0.%desc: ATI ES1000 RN50 dev.drm.0.%driver: drm dev.drm.0.%parent: vgapci0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.LPC0 dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2670 subvendor=0x15d9 subdevice=0x8080 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=31 function=1 handle=\_SB_.PCI0.IDEC dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x269e subvendor=0x15d9 subdevice=0x8080 class=0x01018a dev.atapci.0.%parent: pci0 dev.atapci.1.%desc: Intel 63XXESB2 SATA300 controller dev.atapci.1.%driver: atapci dev.atapci.1.%location: slot=31 function=2 dev.atapci.1.%pnpinfo: vendor=0x8086 device=0x2681 subvendor=0x15d9 subdevice=0x8080 class=0x010601 dev.atapci.1.%parent: pci0 dev.ata.0.%desc: ATA channel 0 dev.ata.0.%driver: ata dev.ata.0.%parent: atapci0 dev.ata.2.%desc: ATA channel 0 dev.ata.2.%driver: ata dev.ata.2.%parent: atapci1 dev.ata.3.%desc: ATA channel 1 dev.ata.3.%driver: ata dev.ata.3.%parent: atapci1 dev.ata.4.%desc: ATA channel 2 dev.ata.4.%driver: ata dev.ata.4.%parent: atapci1 dev.ata.5.%desc: ATA channel 3 dev.ata.5.%driver: ata dev.ata.5.%parent: atapci1 dev.ata.6.%desc: ATA channel 4 dev.ata.6.%driver: ata dev.ata.6.%parent: atapci1 dev.ata.7.%desc: ATA channel 5 dev.ata.7.%driver: ata dev.ata.7.%parent: atapci1 dev.ichsmb.0.%desc: Intel 631xESB/6321ESB (ESB2) SMBus controller dev.ichsmb.0.%driver: ichsmb dev.ichsmb.0.%location: slot=31 function=3 handle=\_SB_.PCI0.SMBS dev.ichsmb.0.%pnpinfo: vendor=0x8086 device=0x269b subvendor=0x15d9 subdevice=0x8080 class=0x0c0500 dev.ichsmb.0.%parent: pci0 dev.smbus.0.%desc: System Management Bus dev.smbus.0.%driver: smbus dev.smbus.0.%parent: ichsmb0 dev.smb.0.%desc: SMBus generic I/O dev.smb.0.%driver: smb dev.smb.0.%parent: smbus0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.PCI0.PWRB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 dev.acpi_button.0.%parent: acpi0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.LPC0.DMAC dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.fpupnp.0.%desc: Legacy ISA coprocessor support dev.fpupnp.0.%driver: fpupnp dev.fpupnp.0.%location: handle=\_SB_.PCI0.LPC0.MATH dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.fpupnp.0.%parent: acpi0 dev.atrtc.0.%desc: AT realtime clock dev.atrtc.0.%driver: atrtc dev.atrtc.0.%location: handle=\_SB_.PCI0.LPC0.RTC_ dev.atrtc.0.%pnpinfo: _HID=PNP0B00 _UID=0 dev.atrtc.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.LPC0.TIME dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.KBC0 dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbdc.0.wake: 0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.MSE0 dev.psmcpnp.0.%pnpinfo: _HID=PNP0F13 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.psmcpnp.0.wake: 0 dev.uart.0.%desc: 16550 or compatible dev.uart.0.%driver: uart dev.uart.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM1 dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.uart.0.%parent: acpi0 dev.uart.0.wake: 0 dev.uart.1.%desc: 16550 or compatible dev.uart.1.%driver: uart dev.uart.1.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM2 dev.uart.1.%pnpinfo: _HID=PNP0501 _UID=2 dev.uart.1.%parent: acpi0 dev.uart.1.wake: 0 dev.fdc.0.%desc: Enhanced floppy controller dev.fdc.0.%driver: fdc dev.fdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.FDC_ dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=1 dev.fdc.0.%parent: acpi0 dev.fd.0.%desc: 1440-KB 3.5" drive dev.fd.0.%driver: fd dev.fd.0.%parent: fdc0 dev.ppc.0.%desc: Parallel port dev.ppc.0.%driver: ppc dev.ppc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.PRT_ dev.ppc.0.%pnpinfo: _HID=PNP0401 _UID=2 dev.ppc.0.%parent: acpi0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.ppi.0.%desc: Parallel I/O dev.ppi.0.%driver: ppi dev.ppi.0.%parent: ppbus0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 57 dev.cpu.0.freq: 1867 dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 933/17500 700/13125 466/8750 233/4375 dev.cpu.0.cx_supported: C1/1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 59 dev.cpu.1.cx_supported: C1/1 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 59 dev.cpu.2.cx_supported: C1/1 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 500us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 60 dev.cpu.3.cx_supported: C1/1 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 500us dev.acpi_perf.0.%driver: acpi_perf dev.acpi_perf.0.%parent: cpu0 dev.acpi_perf.1.%driver: acpi_perf dev.acpi_perf.1.%parent: cpu1 dev.acpi_perf.2.%driver: acpi_perf dev.acpi_perf.2.%parent: cpu2 dev.acpi_perf.3.%driver: acpi_perf dev.acpi_perf.3.%parent: cpu3 dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 1867/35000 dev.est.1.%desc: Enhanced SpeedStep Frequency Control dev.est.1.%driver: est dev.est.1.%parent: cpu1 dev.est.1.freq_settings: 1867/35000 dev.est.2.%desc: Enhanced SpeedStep Frequency Control dev.est.2.%driver: est dev.est.2.%parent: cpu2 dev.est.2.freq_settings: 1867/35000 dev.est.3.%desc: Enhanced SpeedStep Frequency Control dev.est.3.%driver: est dev.est.3.%parent: cpu3 dev.est.3.freq_settings: 1867/35000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.cpufreq.2.%driver: cpufreq dev.cpufreq.2.%parent: cpu2 dev.cpufreq.3.%driver: cpufreq dev.cpufreq.3.%parent: cpu3 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.2.%desc: CPU Frequency Thermal Control dev.p4tcc.2.%driver: p4tcc dev.p4tcc.2.%parent: cpu2 dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.3.%desc: CPU Frequency Thermal Control dev.p4tcc.3.%driver: p4tcc dev.p4tcc.3.%parent: cpu3 dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.apic.0.%desc: APIC resources dev.apic.0.%driver: apic dev.apic.0.%parent: nexus0 dev.ipmi.0.%desc: IPMI System Interface dev.ipmi.0.%driver: ipmi dev.ipmi.0.%parent: isa0 dev.orm.0.%desc: ISA Option ROM dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.acd.0.%desc: Memorex DVD+-RAM 510L v1/MWS7 dev.acd.0.%driver: acd dev.acd.0.%parent: ata0 dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usbus0 dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usbus1 dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usbus2 dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%parent: usbus3 dev.atapicam.0.%desc: ATAPI CAM Attachment dev.atapicam.0.%driver: atapicam dev.atapicam.0.%parent: ata0 dev.atapicam.1.%desc: ATAPI CAM Attachment dev.atapicam.1.%driver: atapicam dev.atapicam.1.%parent: ata2 dev.atapicam.2.%desc: ATAPI CAM Attachment dev.atapicam.2.%driver: atapicam dev.atapicam.2.%parent: ata3 dev.atapicam.3.%desc: ATAPI CAM Attachment dev.atapicam.3.%driver: atapicam dev.atapicam.3.%parent: ata4 dev.atapicam.4.%desc: ATAPI CAM Attachment dev.atapicam.4.%driver: atapicam dev.atapicam.4.%parent: ata5 dev.atapicam.5.%desc: ATAPI CAM Attachment dev.atapicam.5.%driver: atapicam dev.atapicam.5.%parent: ata6 dev.atapicam.6.%desc: ATAPI CAM Attachment dev.atapicam.6.%driver: atapicam dev.atapicam.6.%parent: ata7 dev.ad.4.%desc: ST3400620AS/3.AAJ dev.ad.4.%driver: ad dev.ad.4.%parent: ata2 dev.ad.6.%desc: ST3400620AS/3.AAJ dev.ad.6.%driver: ad dev.ad.6.%parent: ata3 dev.ad.8.%desc: ST3500630AS/3.AAE dev.ad.8.%driver: ad dev.ad.8.%parent: ata4 dev.ad.10.%desc: ST3400620AS/3.AAJ dev.ad.10.%driver: ad dev.ad.10.%parent: ata5 dev.ad.12.%desc: ST3400620AS/3.AAJ dev.ad.12.%driver: ad dev.ad.12.%parent: ata6 dev.ad.14.%desc: ST3400620AS/3.AAJ dev.ad.14.%driver: ad dev.ad.14.%parent: ata7 dev.ums.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 dev.ums.0.%driver: ums dev.ums.0.%location: port=6 interface=0 dev.ums.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" intclass=0x03 intsubclass=0x00 dev.ums.0.%parent: uhub3 dev.ukbd.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 dev.ukbd.0.%driver: ukbd dev.ukbd.0.%location: port=6 interface=1 dev.ukbd.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" intclass=0x03 intsubclass=0x01 dev.ukbd.0.%parent: uhub3 kstat.zfs.misc.arcstats.hits: 1799140 kstat.zfs.misc.arcstats.misses: 501784 kstat.zfs.misc.arcstats.demand_data_hits: 575806 kstat.zfs.misc.arcstats.demand_data_misses: 83877 kstat.zfs.misc.arcstats.demand_metadata_hits: 949664 kstat.zfs.misc.arcstats.demand_metadata_misses: 71350 kstat.zfs.misc.arcstats.prefetch_data_hits: 126189 kstat.zfs.misc.arcstats.prefetch_data_misses: 326939 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 147481 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19618 kstat.zfs.misc.arcstats.mru_hits: 1115709 kstat.zfs.misc.arcstats.mru_ghost_hits: 0 kstat.zfs.misc.arcstats.mfu_hits: 490457 kstat.zfs.misc.arcstats.mfu_ghost_hits: 0 kstat.zfs.misc.arcstats.deleted: 9687 kstat.zfs.misc.arcstats.recycle_miss: 0 kstat.zfs.misc.arcstats.mutex_miss: 0 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 546247 kstat.zfs.misc.arcstats.hash_elements_max: 549954 kstat.zfs.misc.arcstats.hash_collisions: 396590 kstat.zfs.misc.arcstats.hash_chains: 160935 kstat.zfs.misc.arcstats.hash_chain_max: 12 kstat.zfs.misc.arcstats.p: 9317411840 kstat.zfs.misc.arcstats.c: 16093925376 kstat.zfs.misc.arcstats.c_min: 2011740672 kstat.zfs.misc.arcstats.c_max: 16093925376 kstat.zfs.misc.arcstats.size: 12788124608 kstat.zfs.misc.arcstats.hdr_size: 113621248 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 19244 kstat.zfs.misc.vdev_cache_stats.hits: 63137 kstat.zfs.misc.vdev_cache_stats.misses: 53109 Ideas? > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon May 18 23:59:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3187E106566C for ; Mon, 18 May 2009 23:59:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 92FBC8FC18 for ; Mon, 18 May 2009 23:59:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1957681ana.13 for ; Mon, 18 May 2009 16:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TXmEj1Ux78W1UXcP1bhFAoHRfWMrtIHDBGpwBjfpS+c=; b=XY02Q16xz6qrz8QOQ/9A+5bUgWTYdHNjB3yv1X0eIsvOdBd7qfPU+yzWdocOQKkQHA hZy9ffUic2t2YD9KO3KDiE/vhBy5ZWo9GdqWWyRvvc3O9g7gPsoPqvBD9PsLtQvWzcoh 14HvzeeJPD9LkN4vPuE1IQoriXl0UabcbgICM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YHfSVhHuW5cydfkrpqvA74uWiokQqFYA6Hhum1ixa6w7jhQByit7KpLj80jaSQI2Gq 2KtA/b9QosfvZzCMzlGxoxM/WKCyIAl9qnm6X71EUwunWsKCI6q+68tFHgJy8z5b6oYC KaF596y4t2x5dPO2XMC59XoWEmFt/J2h/8lTg= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.207.15 with SMTP id e15mr9938383ang.30.1242691183689; Mon, 18 May 2009 16:59:43 -0700 (PDT) In-Reply-To: References: <20090518145614.GF82547@egr.msu.edu> Date: Mon, 18 May 2009 16:59:43 -0700 X-Google-Sender-Auth: ea30b679093de202 Message-ID: <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> From: Kip Macy To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 23:59:45 -0000 The ARC cache allocates wired memory. The ARC will grow until there is vm pressure. -Kip On Mon, May 18, 2009 at 4:32 PM, Larry Rosenman wrote: > On Mon, 18 May 2009, Larry Rosenman wrote: > >> On Mon, 18 May 2009, Adam McDougall wrote: >> >>> I'm not sure if this is related to recent kernel memory code changes >>> or what, but it hasn't happened with code from earlier than a couple >>> days ago. =A0I had this happen twice, I think the first time was with >>> arc max set to 1024M, the second time was when arc max was unset in >>> loader.conf and the system had been up a few hours but the arc hadn't >>> been squeezed down to a small number yet: >>> Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M >>> Free >>> >>> I've deleted the kernel since then but I did not change my sources, >>> I could build a new one and check where the pointers point to I think? >>> If needed. =A0Or I could reproduce the panic if needed. =A0It doesn't d= ump, >>> it just gets stuck after printing the panic. >> >> I wonder if this is the same crash I saw without getting all the info. >> >> What I saw was the wired memory getting to be most of the memory on the >> box, and then boom. >> >> see my post a few above this. > > Ok, something(tm) is seriously messed up. =A0I was able to get my hands o= n 12G > more memory, and with that, the backup finishes, but the wired count is > insane: > > > last pid: =A01760; =A0load averages: =A05.46, =A07.01, =A06.43 =A0up 0+00= :37:54 > =A018:31:41 > 78 processes: =A05 running, 73 sleeping > > Mem: 440M Active, 4020K Inact, 13G Wired, 524K Cache, 441M Buf, 1970M Fre= e > Swap: 4096M Total, 4096M Free > > > =A0PID USERNAME =A0 =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 T= IME =A0 WCPU COMMAND > =A01403 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 118M RUN =A0 = =A0 2 =A031:53 100.00% > FahCore_7 > =A01400 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 117M CPU0 =A0 = =A00 =A031:51 100.00% > FahCore_7 > =A01397 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 118M CPU3 =A0 = =A03 =A031:46 100.00% > FahCore_7 > =A01235 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 20072K 11404K CPU1 =A0 =A01 = =A031:34 100.00% > FahCore_7 > =A01209 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 118M nanslp = =A00 =A0 0:07 =A00.00% > FahCore_78 > =A01206 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 117M nanslp = =A00 =A0 0:07 =A00.00% > FahCore_78 > =A01207 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 118M nanslp = =A02 =A0 0:06 =A00.00% > FahCore_78 > =A01098 pgsql =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 62052K 34948K select =A02 = =A0 0:02 =A00.00% > postgres > =A01069 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 19096K =A06172K nanslp = =A00 =A0 0:01 =A00.00% perl > =A01202 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nanslp= =A02 =A0 0:00 =A00.00% fah6 > =A01203 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nanslp= =A01 =A0 0:00 =A00.00% fah6 > =A01204 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nanslp= =A01 =A0 0:00 =A00.00% fah6 > =A01205 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 768K nanslp= =A01 =A0 0:00 =A00.00% fah6 > =A01095 pgsql =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 62052K =A05664K select =A0= 0 =A0 0:00 =A00.00% > postgres > =A01208 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 20072K 11404K nanslp =A02 = =A0 0:00 =A00.00% > FahCore_78 > =A01756 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 23900K =A08672K nanslp = =A00 =A0 0:00 =A00.00% alpine > =A0988 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 10612K =A02376K select = =A02 =A0 0:00 =A00.00% ntpd > =A01182 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 17636K =A07048K nanslp = =A02 =A0 0:00 =A00.00% perl > > Sysctl -a: > > kern.ostype: FreeBSD > kern.osrelease: 8.0-CURRENT > kern.osrevision: 199506 > kern.version: FreeBSD 8.0-CURRENT #18: Mon May 18 04:18:03 CDT 2009 > =A0 =A0root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG > > kern.maxvnodes: 100000 > kern.maxproc: 6164 > kern.maxfiles: 12328 > kern.argmax: 262144 > kern.securelevel: -1 > kern.hostname: borg.lerctr.org > kern.hostid: 3935026275 > kern.clockrate: { hz =3D 1000, tick =3D 1000, profhz =3D 2000, stathz =3D= 133 } > kern.posix1version: 200112 > kern.ngroups: 16 > kern.job_control: 1 > kern.saved_ids: 0 > kern.boottime: { sec =3D 1242687257, usec =3D 281783 } Mon May 18 17:54:1= 7 2009 > kern.domainname: kern.osreldate: 800087 > kern.bootfile: /boot/kernel/kernel > kern.maxfilesperproc: 11095 > kern.maxprocperuid: 5547 > kern.ipc.maxsockbuf: 262144 > kern.ipc.sockbuf_waste_factor: 8 > kern.ipc.somaxconn: 128 > kern.ipc.max_linkhdr: 16 > kern.ipc.max_protohdr: 60 > kern.ipc.max_hdr: 76 > kern.ipc.max_datalen: 92 > kern.ipc.nmbjumbo16: 3200 > kern.ipc.nmbjumbo9: 6400 > kern.ipc.nmbjumbop: 12800 > kern.ipc.nmbclusters: 25600 > kern.ipc.piperesizeallowed: 1 > kern.ipc.piperesizefail: 0 > kern.ipc.pipeallocfail: 0 > kern.ipc.pipefragretry: 0 > kern.ipc.pipekva: 98304 > kern.ipc.maxpipekva: 277905408 > kern.ipc.msgseg: 2048 > kern.ipc.msgssz: 8 > kern.ipc.msgtql: 40 > kern.ipc.msgmnb: 2048 > kern.ipc.msgmni: 40 > kern.ipc.msgmax: 16384 > kern.ipc.semaem: 16384 > kern.ipc.semvmx: 32767 > kern.ipc.semusz: 152 > kern.ipc.semume: 10 > kern.ipc.semopm: 100 > kern.ipc.semmsl: 60 > kern.ipc.semmnu: 30 > kern.ipc.semmns: 4096 > kern.ipc.semmni: 2048 > kern.ipc.semmap: 30 > kern.ipc.shm_allow_removed: 0 > kern.ipc.shm_use_phys: 0 > kern.ipc.shmall: 8192000 > kern.ipc.shmseg: 128 > kern.ipc.shmmni: 192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 819200000 > kern.ipc.maxsockets: 25600 > kern.ipc.numopensockets: 63 > kern.ipc.nsfbufsused: 0 > kern.ipc.nsfbufspeak: 0 > kern.ipc.nsfbufs: 0 > kern.dummy: 0 > kern.ps_strings: 140737488355296 > kern.usrstack: 140737488355328 > kern.logsigexit: 1 > kern.iov_max: 1024 > kern.hostuuid: 53D19F64-D663-A017-8922-003048339480 > kern.cam.cam_srch_hi: 0 > kern.cam.scsi_delay: 5000 > kern.cam.cd.retry_count: 4 > kern.cam.cd.changer.max_busy_seconds: 15 > kern.cam.cd.changer.min_busy_seconds: 5 > kern.cam.cd.0.minimum_cmd_size: 10 > kern.cam.da.da_send_ordered: 1 > kern.cam.da.default_timeout: 60 > kern.cam.da.retry_count: 4 > kern.rndtest.verbose: 1 > kern.rndtest.retest: 120 > kern.disks: cd0 ad14 ad12 ad10 ad8 ad6 ad4 > kern.geom.collectstats: 1 > kern.geom.debugflags: 0 > kern.geom.label.debug: 0 > kern.elf64.fallback_brand: -1 > kern.init_shutdown_timeout: 120 > kern.init_path: > /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall > kern.acct_suspended: 0 > kern.acct_configured: 0 > kern.acct_chkfreq: 15 > kern.acct_resume: 4 > kern.acct_suspend: 2 > kern.cp_times: 3050 257577 31202 420 9098 2948 258837 29420 2264 7280 280= 0 > 260523 30701 171 6615 2523 263506 27118 122 7538 > kern.cp_time: 11321 1040443 118441 2977 30531 > kern.constty_wakeups_per_second: 5 > kern.consmsgbuf_size: 8192 > kern.consmute: 0 > kern.console: ttyv0,/ttyv0,uart,gdb, > kern.openfiles: 220 > kern.kq_calloutmax: 4096 > kern.ps_arg_cache_limit: 256 > kern.stackprot: 7 > kern.randompid: 0 > kern.lastpid: 1762 > kern.ktrace.request_pool: 100 > kern.ktrace.genio_size: 4096 > kern.module_path: /boot/kernel;/boot/modules > kern.malloc_count: 267 > kern.fallback_elf_brand: -1 > kern.features.compat_freebsd7: 1 > kern.features.compat_freebsd6: 1 > kern.features.compat_freebsd5: 1 > kern.features.compat_freebsd4: 1 > kern.features.posix_shm: 1 > kern.maxusers: 384 > kern.ident: BORG > kern.kstack_pages: 4 > kern.shutdown.kproc_shutdown_wait: 60 > kern.shutdown.poweroff_delay: 5000 > kern.sync_on_panic: 0 > kern.corefile: %N.core > kern.nodump_coredump: 0 > kern.coredump: 1 > kern.sugid_coredump: 0 > kern.sigqueue.alloc_fail: 0 > kern.sigqueue.overflow: 0 > kern.sigqueue.preallocate: 1024 > kern.sigqueue.max_pending_per_proc: 128 > kern.forcesigexit: 1 > kern.fscale: 2048 > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 62178 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 3310006 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 2523974339 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 1218885212 > kern.timecounter.tc.TSC.frequency: 1862013503 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.threads.max_threads_hits: 0 > kern.threads.max_threads_per_proc: 1500 > kern.ccpu: 0 > kern.sched.preemption: 1 > kern.sched.topology_spec: > =A0 > =A00, 1, 2, 3 > =A0 > =A0 > =A0 > =A0 =A00, 1 > =A0 =A0 > =A0 > =A0 > =A0 =A02, 3 > =A0 =A0 > =A0 > =A0 > =A0 > > > kern.sched.steal_thresh: 2 > kern.sched.steal_idle: 1 > kern.sched.steal_htt: 1 > kern.sched.balance_interval: 133 > kern.sched.balance: 1 > kern.sched.affinity: 1 > kern.sched.idlespinthresh: 4 > kern.sched.idlespins: 10000 > kern.sched.static_boost: 160 > kern.sched.preempt_thresh: 64 > kern.sched.interact: 30 > kern.sched.slice: 13 > kern.sched.name: ULE > kern.devstat.version: 6 > kern.devstat.generation: 225 > kern.devstat.numdevs: 9 > kern.kobj_methodcount: 155 > kern.log_wakeups_per_second: 5 > kern.vm_guest: none > kern.sgrowsiz: 131072 > kern.maxssiz: 536870912 > kern.dflssiz: 8388608 > kern.maxdsiz: 34359738368 > kern.dfldsiz: 134217728 > kern.maxtsiz: 134217728 > kern.maxbcache: 1073741824 > kern.maxswzone: 33554432 > kern.nswbuf: 256 > kern.nbuf: 65536 > kern.ncallout: 18508 > kern.hz: 1000 > kern.msgbuf_clear: 0 > kern.msgbuf: kern.always_console_output: 0 > kern.log_console_output: 1 > kern.smp.forward_roundrobin_enabled: 1 > kern.smp.forward_signal_enabled: 1 > kern.smp.topology: 0 > kern.smp.cpus: 4 > kern.smp.disabled: 0 > kern.smp.active: 1 > kern.smp.maxcpus: 32 > kern.smp.maxid: 3 > kern.tty_inq_nslow: 297 > kern.tty_inq_nfast: 1701 > kern.tty_outq_nslow: 0 > kern.tty_outq_nfast: 0 > kern.pts_maxdev: 999 > kern.tty_pty_warningcnt: 10 > kern.tty_nout: 4730961 > kern.tty_nin: 2138 > kern.minvnodes: 25000 > kern.metadelay: 28 > kern.dirdelay: 29 > kern.filedelay: 30 > kern.chroot_allow_open_directories: 1 > kern.cryptodevallowsoft: 0 > kern.userasymcrypto: 1 > kern.rpc.invalid: 0 > kern.rpc.unexpected: 0 > kern.rpc.timeouts: 0 > kern.rpc.request: 0 > kern.rpc.retries: 0 > kern.elf32.fallback_brand: -1 > kern.random.yarrow.gengateinterval: 10 > kern.random.yarrow.bins: 10 > kern.random.yarrow.fastthresh: 192 > kern.random.yarrow.slowthresh: 256 > kern.random.yarrow.slowoverthresh: 2 > kern.random.sys.seeded: 1 > kern.random.sys.harvest.ethernet: 1 > kern.random.sys.harvest.point_to_point: 1 > kern.random.sys.harvest.interrupt: 1 > kern.random.sys.harvest.swi: 0 > vm.vmtotal: System wide totals computed every five seconds: (values in > kilobytes) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Processes: =A0 =A0 =A0 =A0 =A0 =A0 =A0(RUNQ: 5 Disk Wait: 0 Page Wait: 0 = Sleep: 73) > Virtual Memory: =A0 =A0 =A0 =A0 (Total: 1076206992K, Active 2349180K) > Real Memory: =A0 =A0 =A0 =A0 =A0 =A0(Total: 1103632K Active 455252K) > Shared Virtual Memory: =A0(Total: 20708K Active: 14128K) > Shared Real Memory: =A0 =A0 (Total: 9388K Active: 8756K) > Free Memory Pages: =A0 =A0 =A02017432K > > vm.loadavg: { 5.08 6.77 6.36 } > vm.v_free_min: 25703 > vm.v_free_target: 108162 > vm.v_free_reserved: 5350 > vm.v_inactive_target: 162243 > vm.v_cache_min: 108162 > vm.v_cache_max: 216324 > vm.v_pageout_free_min: 34 > vm.pageout_algorithm: 0 > vm.swap_enabled: 1 > vm.kmem_size_scale: 3 > vm.kmem_size_max: 329853485875 > vm.kmem_size_min: 0 > vm.kmem_size: 5558173696 > vm.nswapdev: 1 > vm.dmmax: 32 > vm.swap_async_max: 4 > vm.zone_count: 98 > vm.swap_idle_threshold2: 10 > vm.swap_idle_threshold1: 2 > vm.exec_map_entries: 16 > vm.stats.misc.zero_page_count: 59 > vm.stats.misc.cnt_prezero: 0 > vm.stats.vm.v_kthreadpages: 0 > vm.stats.vm.v_rforkpages: 2236 > vm.stats.vm.v_vforkpages: 39693 > vm.stats.vm.v_forkpages: 363901 > vm.stats.vm.v_kthreads: 141 > vm.stats.vm.v_rforks: 28 > vm.stats.vm.v_vforks: 198 > vm.stats.vm.v_forks: 1395 > vm.stats.vm.v_interrupt_free_min: 2 > vm.stats.vm.v_pageout_free_min: 34 > vm.stats.vm.v_cache_max: 216324 > vm.stats.vm.v_cache_min: 108162 > vm.stats.vm.v_cache_count: 123 > vm.stats.vm.v_inactive_count: 1005 > vm.stats.vm.v_inactive_target: 162243 > vm.stats.vm.v_active_count: 112687 > vm.stats.vm.v_wire_count: 3452797 > vm.stats.vm.v_free_count: 504231 > vm.stats.vm.v_free_min: 25703 > vm.stats.vm.v_free_target: 108162 > vm.stats.vm.v_free_reserved: 5350 > vm.stats.vm.v_page_count: 4070929 > vm.stats.vm.v_page_size: 4096 > vm.stats.vm.v_tfree: 19085156 > vm.stats.vm.v_pfree: 612782 > vm.stats.vm.v_dfree: 0 > vm.stats.vm.v_tcached: 3100 > vm.stats.vm.v_pdpages: 0 > vm.stats.vm.v_pdwakeups: 0 > vm.stats.vm.v_reactivated: 2925 > vm.stats.vm.v_intrans: 704 > vm.stats.vm.v_vnodepgsout: 1 > vm.stats.vm.v_vnodepgsin: 6890 > vm.stats.vm.v_vnodeout: 1 > vm.stats.vm.v_vnodein: 5806 > vm.stats.vm.v_swappgsout: 0 > vm.stats.vm.v_swappgsin: 0 > vm.stats.vm.v_swapout: 0 > vm.stats.vm.v_swapin: 0 > vm.stats.vm.v_ozfod: 27 > vm.stats.vm.v_zfod: 2565409 > vm.stats.vm.v_cow_optim: 397 > vm.stats.vm.v_cow_faults: 64414 > vm.stats.vm.v_vm_faults: 2768133 > vm.stats.sys.v_soft: 1359531 > vm.stats.sys.v_intr: 715196 > vm.stats.sys.v_syscall: 6458471 > vm.stats.sys.v_trap: 6074556 > vm.stats.sys.v_swtch: 8393310 > vm.stats.object.bypasses: 757 > vm.stats.object.collapses: 5656 > vm.v_free_severe: 15526 > vm.max_proc_mmap: 496265 > vm.old_msync: 0 > vm.msync_flush_flags: 3 > vm.boot_pages: 48 > vm.max_wired: 1345352 > vm.pageout_lock_miss: 0 > vm.disable_swapspace_pageouts: 0 > vm.defer_swapspace_pageouts: 0 > vm.swap_idle_enabled: 0 > vm.pageout_stats_interval: 5 > vm.pageout_full_stats_interval: 20 > vm.pageout_stats_max: 108162 > vm.max_launder: 32 > vm.phys_segs: SEGMENT 0: > > start: =A0 =A0 0x1000 > end: =A0 =A0 =A0 0x98000 > free list: 0xffffffff80849668 > > SEGMENT 1: > > start: =A0 =A0 0xb8a000 > end: =A0 =A0 =A0 0x1000000 > free list: 0xffffffff80849668 > > SEGMENT 2: > > start: =A0 =A0 0x1000000 > end: =A0 =A0 =A0 0xcff50000 > free list: 0xffffffff808492c0 > > SEGMENT 3: > > start: =A0 =A0 0x100000000 > end: =A0 =A0 =A0 0x4129b4000 > free list: 0xffffffff808492c0 > > vm.phys_free: FREE LIST 0: > > =A0ORDER (SIZE) =A0| =A0NUMBER > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0POOL 0 =A0| =A0POOL 1 =A0| =A0POOL 2 > -- =A0 =A0 =A0 =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0= =A0-- > =A012 ( 16384K) =A0| =A0 =A0 =A091 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 > =A011 ( =A08192K) =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 = 0 > =A010 ( =A04096K) =A0| =A0 =A0 =A0 7 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 = 0 > =A0 9 ( =A02048K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 = 0 > =A0 8 ( =A01024K) =A0| =A0 =A0 =A0 4 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 = 0 > =A0 7 ( =A0 512K) =A0| =A0 =A0 =A010 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 6 ( =A0 256K) =A0| =A0 =A0 =A0 7 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 5 ( =A0 128K) =A0| =A0 =A0 =A011 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 4 ( =A0 =A064K) =A0| =A0 =A0 =A032 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > =A0 3 ( =A0 =A032K) =A0| =A0 =A0 246 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 2 ( =A0 =A016K) =A0| =A0 =A0 929 =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0 = 1 > =A0 1 ( =A0 =A0 8K) =A0| =A0 =A01849 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 = 7 > =A0 0 ( =A0 =A0 4K) =A0| =A0 =A09492 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A07= 3 > > FREE LIST 1: > > =A0ORDER (SIZE) =A0| =A0NUMBER > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0POOL 0 =A0| =A0POOL 1 =A0| =A0POOL 2 > -- =A0 =A0 =A0 =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0= =A0-- > =A012 ( 16384K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 > =A011 ( =A08192K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A010 ( =A04096K) =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 9 ( =A02048K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 8 ( =A01024K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 7 ( =A0 512K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 6 ( =A0 256K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 5 ( =A0 128K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 > =A0 4 ( =A0 =A064K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > =A0 3 ( =A0 =A032K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > =A0 2 ( =A0 =A016K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > =A0 1 ( =A0 =A0 8K) =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > =A0 0 ( =A0 =A0 4K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 > > vm.reserv.reclaimed: 0 > vm.reserv.partpopq: LEVEL =A0 =A0 SIZE =A0NUMBER > > =A0 -1: 362368K, =A0 =A0326 > > vm.reserv.freed: 11598 > vm.reserv.broken: 8 > vm.idlezero_enable: 0 > vm.kvm_free: 542615007232 > vm.kvm_size: 549755809792 > vm.pmap.pmap_collect_active: 0 > vm.pmap.pmap_collect_inactive: 0 > vm.pmap.pv_entry_spare: 8566 > vm.pmap.pv_entry_allocs: 3744878 > vm.pmap.pv_entry_frees: 3679188 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pc_chunk_frees: 13290 > vm.pmap.pc_chunk_allocs: 13732 > vm.pmap.pc_chunk_count: 442 > vm.pmap.pv_entry_count: 65690 > vm.pmap.pdpe.demotions: 0 > vm.pmap.pde.promotions: 110851 > vm.pmap.pde.p_failures: 1022233 > vm.pmap.pde.mappings: 0 > vm.pmap.pde.demotions: 107618 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 5303729 > vm.pmap.pg_ps_enabled: 1 > vfs.zfs.arc_meta_limit: 4023481344 > vfs.zfs.arc_meta_used: 1192541184 > vfs.zfs.mdcomp_disable: 0 > vfs.zfs.arc_min: 2011740672 > vfs.zfs.arc_max: 16093925376 > vfs.zfs.zfetch.array_rd_sz: 1048576 > vfs.zfs.zfetch.block_cap: 256 > vfs.zfs.zfetch.min_sec_reap: 2 > vfs.zfs.zfetch.max_streams: 8 > vfs.zfs.prefetch_disable: 0 > vfs.zfs.recover: 0 > vfs.zfs.txg.synctime: 5 > vfs.zfs.txg.timeout: 30 > vfs.zfs.scrub_limit: 10 > vfs.zfs.vdev.cache.bshift: 16 > vfs.zfs.vdev.cache.size: 10485760 > vfs.zfs.vdev.cache.max: 16384 > vfs.zfs.vdev.aggregation_limit: 131072 > vfs.zfs.vdev.ramp_rate: 2 > vfs.zfs.vdev.time_shift: 6 > vfs.zfs.vdev.min_pending: 4 > vfs.zfs.vdev.max_pending: 35 > vfs.zfs.cache_flush_disable: 0 > vfs.zfs.zil_disable: 0 > vfs.zfs.version.zpl: 3 > vfs.zfs.version.vdev_boot: 1 > vfs.zfs.version.spa: 13 > vfs.zfs.version.dmu_backup_stream: 1 > vfs.zfs.version.dmu_backup_header: 2 > vfs.zfs.version.acl: 1 > vfs.zfs.debug: 0 > vfs.zfs.super_owner: 1 > vfs.ufs.dirhash_docheck: 0 > vfs.ufs.dirhash_mem: 39648 > vfs.ufs.dirhash_maxmem: 2097152 > vfs.ufs.dirhash_minsize: 2560 > vfs.devfs.rule_depth: 1 > vfs.devfs.generation: 139 > vfs.nfs4.access_cache_timeout: 60 > vfs.nfs.downdelayinitial: 12 > vfs.nfs.downdelayinterval: 30 > vfs.nfs.skip_wcc_data_onerr: 1 > vfs.nfs.nfs3_jukebox_delay: 10 > vfs.nfs.reconnects: 0 > vfs.nfs.bufpackets: 4 > vfs.nfs.realign_count: 0 > vfs.nfs.realign_test: 0 > vfs.nfs.defect: 0 > vfs.nfs.iodmax: 20 > vfs.nfs.iodmin: 0 > vfs.nfs.iodmaxidle: 120 > vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 > vfs.nfs.nfs_ip_paranoia: 1 > vfs.nfs.nfs_directio_allow_mmap: 1 > vfs.nfs.nfs_directio_enable: 0 > vfs.nfs.clean_pages_on_close: 1 > vfs.nfs.nfsv3_commit_on_close: 0 > vfs.nfs.prime_access_cache: 0 > vfs.nfs.access_cache_timeout: 60 > vfs.pfs.trace: 0 > vfs.pfs.vncache.misses: 0 > vfs.pfs.vncache.hits: 0 > vfs.pfs.vncache.maxentries: 0 > vfs.pfs.vncache.entries: 0 > vfs.flushwithdeps: 0 > vfs.notbufdflashes: 0 > vfs.flushbufqtarget: 100 > vfs.getnewbufrestarts: 0 > vfs.getnewbufcalls: 28204 > vfs.hifreebuffers: 7290 > vfs.lofreebuffers: 3645 > vfs.numfreebuffers: 65534 > vfs.dirtybufthresh: 14763 > vfs.hidirtybuffers: 16404 > vfs.lodirtybuffers: 8202 > vfs.numdirtybuffers: 2 > vfs.recursiveflushes: 0 > vfs.altbufferflushes: 0 > vfs.bdwriteskip: 0 > vfs.dirtybufferflushes: 0 > vfs.hirunningspace: 1048576 > vfs.lorunningspace: 524288 > vfs.bufdefragcnt: 0 > vfs.buffreekvacnt: 0 > vfs.bufreusecnt: 28198 > vfs.hibufspace: 1073086464 > vfs.lobufspace: 1073020928 > vfs.maxmallocbufspace: 53654323 > vfs.bufmallocspace: 0 > vfs.maxbufspace: 1073741824 > vfs.bufspace: 461996032 > vfs.runningbufspace: 0 > vfs.vmiodirenable: 1 > vfs.cache.numfullpathfound: 124 > vfs.cache.numfullpathfail4: 0 > vfs.cache.numfullpathfail2: 0 > vfs.cache.numfullpathfail1: 0 > vfs.cache.numfullpathcalls: 124 > vfs.cache.nchstats: 4488983 27354 228 0 466972 0 33 156 > vfs.cache.numupgrades: 28 > vfs.cache.numneghits: 27354 > vfs.cache.numnegzaps: 57 > vfs.cache.numposhits: 4488983 > vfs.cache.numposzaps: 171 > vfs.cache.nummisszap: 309 > vfs.cache.nummiss: 466663 > vfs.cache.numchecks: 5829112 > vfs.cache.dotdothits: 47 > vfs.cache.dothits: 1035 > vfs.cache.numcalls: 4984636 > vfs.cache.numcache: 30787 > vfs.cache.numneg: 766 > vfs.read_max: 8 > vfs.write_behind: 1 > vfs.lookup_shared: 1 > vfs.usermount: 1 > vfs.worklist_len: 1 > vfs.timestamp_precision: 0 > vfs.reassignbufcalls: 611 > vfs.freevnodes: 24986 > vfs.wantfreevnodes: 25000 > vfs.numvnodes: 29998 > vfs.nfsrv.nfs_privport: 0 > vfs.nfsrv.fha.bin_shift: 18 > vfs.nfsrv.fha.max_nfsds_per_fh: 8 > vfs.nfsrv.fha.max_reqs_per_nfsd: 4 > vfs.nfsrv.fha.fhe_stats: No file handle entries. > vfs.nfsrv.commit_miss: 0 > vfs.nfsrv.commit_blks: 0 > vfs.nfsrv.async: 0 > vfs.nfsrv.realign_count: 0 > vfs.nfsrv.realign_test: 0 > vfs.nfsrv.gatherdelay_v3: 0 > vfs.nfsrv.gatherdelay: 10000 > vfs.nfsrv.minthreads: 4 > vfs.nfsrv.maxthreads: 4 > vfs.nfsrv.threads: 4 > vfs.nfsrv.request_space_used: 0 > vfs.nfsrv.request_space_used_highest: 0 > vfs.nfsrv.request_space_high: 13107200 > vfs.nfsrv.request_space_low: 8738133 > vfs.nfsrv.request_space_throttled: 0 > vfs.nfsrv.request_space_throttle_count: 0 > vfs.ffs.doreallocblks: 1 > vfs.ffs.doasyncfree: 1 > vfs.ffs.compute_summary_at_mount: 0 > net.local.stream.recvspace: 8192 > net.local.stream.sendspace: 8192 > net.local.dgram.recvspace: 4096 > net.local.dgram.maxdgram: 2048 > net.local.taskcount: 0 > net.local.recycled: 0 > net.local.inflight: 0 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.portrange.reservedlow: 0 > net.inet.ip.portrange.reservedhigh: 1023 > net.inet.ip.portrange.hilast: 65535 > net.inet.ip.portrange.hifirst: 49152 > net.inet.ip.portrange.last: 65535 > net.inet.ip.portrange.first: 10000 > net.inet.ip.portrange.lowlast: 600 > net.inet.ip.portrange.lowfirst: 1023 > net.inet.ip.forwarding: 0 > net.inet.ip.redirect: 1 > net.inet.ip.ttl: 64 > net.inet.ip.rtexpire: 3600 > net.inet.ip.rtminexpire: 10 > net.inet.ip.rtmaxcache: 128 > net.inet.ip.sourceroute: 0 > net.inet.ip.intr_queue_maxlen: 50 > net.inet.ip.intr_queue_drops: 0 > net.inet.ip.accept_sourceroute: 0 > net.inet.ip.keepfaith: 0 > net.inet.ip.gifttl: 30 > net.inet.ip.same_prefix_carp_only: 0 > net.inet.ip.subnets_are_local: 0 > net.inet.ip.random_id_total: 0 > net.inet.ip.random_id_collisions: 0 > net.inet.ip.random_id_period: 8192 > net.inet.ip.mcast.loop: 1 > net.inet.ip.mcast.maxsocksrc: 128 > net.inet.ip.mcast.maxgrpsrc: 512 > net.inet.ip.fastforwarding: 0 > net.inet.ip.maxfragpackets: 800 > net.inet.ip.output_flowtable_size: 0 > net.inet.ip.maxfragsperpacket: 16 > net.inet.ip.fragpackets: 0 > net.inet.ip.check_interface: 0 > net.inet.ip.random_id: 0 > net.inet.ip.sendsourcequench: 0 > net.inet.ip.process_options: 1 > net.inet.icmp.maskrepl: 0 > net.inet.icmp.icmplim: 200 > net.inet.icmp.bmcastecho: 0 > net.inet.icmp.quotelen: 8 > net.inet.icmp.reply_from_interface: 0 > net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 > net.inet.icmp.log_redirect: 0 > net.inet.icmp.drop_redirect: 0 > net.inet.icmp.maskfake: 0 > net.inet.igmp.gsrdelay: 10 > net.inet.igmp.default_version: 3 > net.inet.igmp.legacysupp: 0 > net.inet.igmp.v2enable: 1 > net.inet.igmp.v1enable: 1 > net.inet.igmp.sendlocal: 1 > net.inet.igmp.sendra: 1 > net.inet.igmp.recvifkludge: 1 > net.inet.tcp.rfc1323: 1 > net.inet.tcp.mssdflt: 512 > net.inet.tcp.keepidle: 7200000 > net.inet.tcp.keepintvl: 75000 > net.inet.tcp.sendspace: 32768 > net.inet.tcp.recvspace: 65536 > net.inet.tcp.keepinit: 75000 > net.inet.tcp.delacktime: 100 > net.inet.tcp.v6mssdflt: 1024 > net.inet.tcp.hostcache.purge: 0 > net.inet.tcp.hostcache.prune: 300 > net.inet.tcp.hostcache.expire: 3600 > net.inet.tcp.hostcache.count: 3 > net.inet.tcp.hostcache.bucketlimit: 30 > net.inet.tcp.hostcache.hashsize: 512 > net.inet.tcp.hostcache.cachelimit: 15360 > net.inet.tcp.wlock_looped: 0 > net.inet.tcp.wlock_relocked: 0 > net.inet.tcp.wlock_upgraded: 262 > net.inet.tcp.tcp_wlock_atfirst: 416 > net.inet.tcp.rlock_atfirst: 829900 > net.inet.tcp.read_locking: 1 > net.inet.tcp.recvbuf_max: 262144 > net.inet.tcp.recvbuf_inc: 16384 > net.inet.tcp.recvbuf_auto: 1 > net.inet.tcp.insecure_rst: 0 > net.inet.tcp.ecn.maxretries: 1 > net.inet.tcp.ecn.enable: 0 > net.inet.tcp.abc_l_var: 2 > net.inet.tcp.rfc3465: 1 > net.inet.tcp.rfc3390: 1 > net.inet.tcp.rfc3042: 1 > net.inet.tcp.drop_synfin: 0 > net.inet.tcp.delayed_ack: 1 > net.inet.tcp.blackhole: 0 > net.inet.tcp.log_in_vain: 0 > net.inet.tcp.sendbuf_max: 262144 > net.inet.tcp.sendbuf_inc: 8192 > net.inet.tcp.sendbuf_auto: 1 > net.inet.tcp.tso: 1 > net.inet.tcp.newreno: 1 > net.inet.tcp.local_slowstart_flightsize: 4 > net.inet.tcp.slowstart_flightsize: 1 > net.inet.tcp.path_mtu_discovery: 1 > net.inet.tcp.reass.overflows: 0 > net.inet.tcp.reass.maxqlen: 48 > net.inet.tcp.reass.cursegments: 0 > net.inet.tcp.reass.maxsegments: 1600 > net.inet.tcp.sack.globalholes: 0 > net.inet.tcp.sack.globalmaxholes: 65536 > net.inet.tcp.sack.maxholes: 128 > net.inet.tcp.sack.enable: 1 > net.inet.tcp.inflight.stab: 20 > net.inet.tcp.inflight.max: 1073725440 > net.inet.tcp.inflight.min: 6144 > net.inet.tcp.inflight.rttthresh: 10 > net.inet.tcp.inflight.debug: 0 > net.inet.tcp.inflight.enable: 1 > net.inet.tcp.isn_reseed_interval: 0 > net.inet.tcp.icmp_may_rst: 1 > net.inet.tcp.pcbcount: 26 > net.inet.tcp.do_tcpdrain: 1 > net.inet.tcp.tcbhashsize: 512 > net.inet.tcp.log_debug: 0 > net.inet.tcp.minmss: 216 > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > net.inet.tcp.syncookies_only: 0 > net.inet.tcp.syncookies: 1 > net.inet.tcp.timer_race: 0 > net.inet.tcp.finwait2_timeout: 60000 > net.inet.tcp.fast_finwait2_recycle: 0 > net.inet.tcp.always_keepalive: 1 > net.inet.tcp.rexmit_slop: 200 > net.inet.tcp.rexmit_min: 30 > net.inet.tcp.msl: 30000 > net.inet.tcp.nolocaltimewait: 0 > net.inet.tcp.maxtcptw: 5120 > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 42080 > net.inet.udp.blackhole: 0 > net.inet.udp.log_in_vain: 0 > net.inet.sctp.nat_friendly_init: 1 > net.inet.sctp.enable_sack_immediately: 0 > net.inet.sctp.udp_tunneling_port: 0 > net.inet.sctp.udp_tunneling_for_client_enable: 0 > net.inet.sctp.mobility_fasthandoff: 0 > net.inet.sctp.mobility_base: 0 > net.inet.sctp.default_frag_interleave: 1 > net.inet.sctp.default_cc_module: 0 > net.inet.sctp.log_level: 0 > net.inet.sctp.max_retran_chunk: 30 > net.inet.sctp.min_residual: 1452 > net.inet.sctp.strict_data_order: 0 > net.inet.sctp.abort_at_limit: 0 > net.inet.sctp.hb_max_burst: 4 > net.inet.sctp.do_sctp_drain: 1 > net.inet.sctp.max_chained_mbufs: 5 > net.inet.sctp.abc_l_var: 1 > net.inet.sctp.nat_friendly: 1 > net.inet.sctp.auth_disable: 0 > net.inet.sctp.asconf_auth_nochk: 0 > net.inet.sctp.early_fast_retran_msec: 250 > net.inet.sctp.early_fast_retran: 0 > net.inet.sctp.cwnd_maxburst: 1 > net.inet.sctp.cmt_pf: 0 > net.inet.sctp.cmt_use_dac: 0 > net.inet.sctp.nr_sack_on_off: 0 > net.inet.sctp.cmt_on_off: 0 > net.inet.sctp.outgoing_streams: 10 > net.inet.sctp.add_more_on_output: 1452 > net.inet.sctp.path_rtx_max: 5 > net.inet.sctp.assoc_rtx_max: 10 > net.inet.sctp.init_rtx_max: 8 > net.inet.sctp.valid_cookie_life: 60000 > net.inet.sctp.init_rto_max: 60000 > net.inet.sctp.rto_initial: 3000 > net.inet.sctp.rto_min: 1000 > net.inet.sctp.rto_max: 60000 > net.inet.sctp.secret_lifetime: 3600 > net.inet.sctp.shutdown_guard_time: 180 > net.inet.sctp.pmtu_raise_time: 600 > net.inet.sctp.heartbeat_interval: 30000 > net.inet.sctp.asoc_resource: 10 > net.inet.sctp.sys_resource: 1000 > net.inet.sctp.sack_freq: 2 > net.inet.sctp.delayed_sack_time: 200 > net.inet.sctp.chunkscale: 10 > net.inet.sctp.min_split_point: 2904 > net.inet.sctp.pcbhashsize: 256 > net.inet.sctp.tcbhashsize: 1024 > net.inet.sctp.maxchunks: 3200 > net.inet.sctp.maxburst: 4 > net.inet.sctp.peer_chkoh: 256 > net.inet.sctp.strict_init: 1 > net.inet.sctp.loopback_nocsum: 1 > net.inet.sctp.strict_sacks: 1 > net.inet.sctp.ecn_nonce: 0 > net.inet.sctp.ecn_enable: 1 > net.inet.sctp.auto_asconf: 1 > net.inet.sctp.recvspace: 233016 > net.inet.sctp.sendspace: 233016 > net.inet.raw.recvspace: 9216 > net.inet.raw.maxdgram: 9216 > net.inet.accf.unloadable: 0 > net.inet.flowtable.nmbflows: 4096 > net.inet.flowtable.tcp_expire: 86400 > net.inet.flowtable.fin_wait_expire: 600 > net.inet.flowtable.udp_expire: 300 > net.inet.flowtable.syn_expire: 300 > net.inet.flowtable.collisions: 0 > net.inet.flowtable.max_depth: 0 > net.inet.flowtable.free_checks: 0 > net.inet.flowtable.frees: 0 > net.inet.flowtable.misses: 0 > net.inet.flowtable.lookups: 0 > net.inet.flowtable.hits: 0 > net.inet.flowtable.enable: 0 > net.link.generic.system.ifcount: 3 > net.link.ether.inet.log_arp_permanent_modify: 1 > net.link.ether.inet.log_arp_movements: 1 > net.link.ether.inet.log_arp_wrong_iface: 1 > net.link.ether.inet.proxyall: 0 > net.link.ether.inet.useloopback: 1 > net.link.ether.inet.maxtries: 5 > net.link.ether.inet.max_age: 1200 > net.link.ether.ipfw: 0 > net.link.gif.parallel_tunnels: 0 > net.link.gif.max_nesting: 1 > net.link.log_link_state_change: 1 > net.link.tun.devfs_cloning: 1 > net.inet6.ip6.forwarding: 0 > net.inet6.ip6.redirect: 1 > net.inet6.ip6.hlim: 64 > net.inet6.ip6.maxfragpackets: 6400 > net.inet6.ip6.accept_rtadv: 0 > net.inet6.ip6.keepfaith: 0 > net.inet6.ip6.log_interval: 5 > net.inet6.ip6.hdrnestlimit: 15 > net.inet6.ip6.dad_count: 1 > net.inet6.ip6.auto_flowlabel: 1 > net.inet6.ip6.defmcasthlim: 1 > net.inet6.ip6.gifhlim: 30 > net.inet6.ip6.kame_version: FreeBSD > net.inet6.ip6.use_deprecated: 1 > net.inet6.ip6.rr_prune: 5 > net.inet6.ip6.v6only: 1 > net.inet6.ip6.rtexpire: 3600 > net.inet6.ip6.rtminexpire: 10 > net.inet6.ip6.rtmaxcache: 128 > net.inet6.ip6.use_tempaddr: 0 > net.inet6.ip6.temppltime: 86400 > net.inet6.ip6.tempvltime: 604800 > net.inet6.ip6.auto_linklocal: 0 > net.inet6.ip6.prefer_tempaddr: 0 > net.inet6.ip6.use_defaultzone: 0 > net.inet6.ip6.maxfrags: 6400 > net.inet6.ip6.mcast_pmtu: 0 > net.inet6.ip6.mcast.loop: 1 > net.inet6.ip6.mcast.maxsocksrc: 128 > net.inet6.ip6.mcast.maxgrpsrc: 512 > net.inet6.icmp6.rediraccept: 1 > net.inet6.icmp6.redirtimeout: 600 > net.inet6.icmp6.nd6_prune: 1 > net.inet6.icmp6.nd6_delay: 5 > net.inet6.icmp6.nd6_umaxtries: 3 > net.inet6.icmp6.nd6_mmaxtries: 3 > net.inet6.icmp6.nd6_useloopback: 1 > net.inet6.icmp6.nodeinfo: 3 > net.inet6.icmp6.errppslimit: 100 > net.inet6.icmp6.nd6_maxnudhint: 0 > net.inet6.icmp6.nd6_debug: 0 > net.inet6.icmp6.nd6_maxqueuelen: 1 > net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 > net.inet6.mld.gsrdelay: 10 > net.bpf.zerocopy_enable: 0 > net.bpf.maxinsns: 512 > net.bpf.maxbufsize: 524288 > net.bpf.bufsize: 4096 > net.isr.swi_count: 419599 > net.isr.drop: 0 > net.isr.queued: 830117 > net.isr.deferred: 0 > net.isr.directed: 3109 > net.isr.count: 3109 > net.isr.direct: 1 > net.raw.recvspace: 8192 > net.raw.sendspace: 8192 > net.my_fibnum: 0 > net.add_addr_allfibs: 1 > net.fibs: 1 > net.route.netisr_maxqlen: 256 > debug.ddb.capture.bufsize: 49152 > debug.ddb.capture.inprogress: 0 > debug.ddb.capture.maxbufsize: 5242880 > debug.ddb.capture.bufoff: 0 > debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: > debug.ddb.textdump.do_version: 1 > debug.ddb.textdump.do_panic: 1 > debug.ddb.textdump.do_msgbuf: 1 > debug.ddb.textdump.do_ddb: 1 > debug.ddb.textdump.do_config: 1 > debug.ddb.textdump.pending: 0 > debug.ddb_use_printf: 0 > debug.acpi.semaphore_debug: 0 > debug.acpi.suspend_bounce: 0 > debug.acpi.reset_clock: 1 > debug.acpi.do_powerstate: 1 > debug.acpi.acpi_ca_version: 20070320 > debug.acpi.ec.timeout: 750 > debug.acpi.ec.polled: 0 > debug.acpi.ec.burst: 0 > debug.acpi.batt.batt_sleep_ms: 0 > debug.acpi.resume_beep: 0 > debug.mddebug: 0 > debug.gdbcons: 0 > debug.elf64_legacy_coredump: 0 > debug.bootverbose: 0 > debug.boothowto: 0 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > debug.sizeof.cdev_priv: 376 > debug.sizeof.cdev: 288 > debug.sizeof.g_bioq: 56 > debug.sizeof.g_consumer: 96 > debug.sizeof.g_provider: 136 > debug.sizeof.g_geom: 136 > debug.sizeof.g_class: 136 > debug.sizeof.kinfo_proc: 1088 > debug.sizeof.buf: 600 > debug.sizeof.bio: 216 > debug.sizeof.proc: 1112 > debug.sizeof.vnode: 472 > debug.sizeof.devstat: 288 > debug.sizeof.namecache: 72 > debug.sizeof.znode: 376 > debug.osd: 0 > debug.rwlock.loops: 10000 > debug.rwlock.retry: 10 > debug.trace_on_panic: 1 > debug.debugger_on_panic: 0 > debug.to_avg_mpcalls: 515 > debug.to_avg_lockcalls: 1 > debug.to_avg_gcalls: 255 > debug.to_avg_depth: 1017 > debug.umtx.umtx_pi_allocated: 0 > debug.kdb.stop_cpus: 1 > debug.kdb.trap_code: 0 > debug.kdb.trap: 0 > debug.kdb.panic: 0 > debug.kdb.enter: 0 > debug.kdb.current: ddb > debug.kdb.available: ddb debug.rman_debug: 0 > debug.ttydebug: 0 > debug.disablefullpath: 0 > debug.disablecwd: 0 > debug.vfscache: 1 > debug.numcachehv: 2066 > debug.numcache: 30787 > debug.numneg: 766 > debug.ncnegfactor: 16 > debug.nchash: 131071 > debug.vnlru_nowhere: 0 > debug.rush_requests: 0 > debug.mpsafevfs: 1 > debug.if_tun_debug: 0 > debug.nlm_debug: 0 > debug.crypto_timing: 0 > debug.collectsnapstats: 0 > debug.snapdebug: 0 > debug.dopersistence: 0 > debug.dir_entry: 0 > debug.direct_blk_ptrs: 0 > debug.inode_bitmap: 0 > debug.indir_blk_ptrs: 0 > debug.sync_limit_hit: 0 > debug.ino_limit_hit: 0 > debug.blk_limit_hit: 0 > debug.ino_limit_push: 0 > debug.blk_limit_push: 0 > debug.worklist_push: 0 > debug.maxindirdeps: 50 > debug.tickdelay: 2 > debug.max_softdeps: 400000 > debug.dobkgrdwrite: 1 > debug.bigcgs: 0 > debug.dircheck: 0 > debug.minidump: 1 > debug.psm.pkterrthresh: 2 > debug.psm.usecs: 500000 > debug.psm.secs: 0 > debug.psm.errusecs: 0 > debug.psm.errsecs: 2 > debug.psm.hz: 20 > debug.psm.loglevel: 0 > debug.fdc.settle: 125 > debug.fdc.spec2: 16 > debug.fdc.spec1: 175 > debug.fdc.retries: 10 > debug.fdc.debugflags: 0 > debug.fdc.fifo: 8 > debug.elf32_legacy_coredump: 0 > debug.hwpstate_verbose: 0 > hw.machine: amd64 > hw.model: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 =A05120 =A0@ 1.86GHz > hw.ncpu: 4 > hw.byteorder: 1234 > hw.physmem: 17167667200 > hw.usermem: 3024932864 > hw.pagesize: 4096 > hw.floatingpoint: 1 > hw.machine_arch: amd64 > hw.realmem: 17985175552 > hw.ata.setmax: 0 > hw.ata.wc: 1 > hw.ata.atapi_dma: 1 > hw.ata.ata_dma_check_80pin: 1 > hw.ata.ata_dma: 1 > hw.pci.honor_msi_blacklist: 1 > hw.pci.enable_msix: 1 > hw.pci.enable_msi: 1 > hw.pci.do_power_resume: 1 > hw.pci.do_power_nodriver: 0 > hw.pci.enable_io_modes: 1 > hw.pci.host_mem_start: 2147483648 > hw.syscons.kbd_debug: 1 > hw.syscons.kbd_reboot: 1 > hw.syscons.bell: 1 > hw.syscons.saver.keybonly: 1 > hw.syscons.sc_no_suspend_vtswitch: 0 > hw.usb2.ehci.no_hs: 0 > hw.usb2.ehci.debug: 0 > hw.usb2.uhci.loop: 0 > hw.usb2.uhci.debug: 0 > hw.usb2.ctrl.debug: 0 > hw.usb2.umass.debug: 0 > hw.usb2.urio.debug: 0 > hw.usb2.debug: 0 > hw.usb2.dev.debug: 0 > hw.usb2.template: 0 > hw.usb2.ugen.debug: 0 > hw.usb2.power_timeout: 30 > hw.usb2.uhub.debug: 0 > hw.usb2.proc.debug: 0 > hw.usb2.ss_delay: 0 > hw.usb2.pr_recovery_delay: 250 > hw.usb2.pr_poll_delay: 50 > hw.usb2.ulpt.debug: 0 > hw.usb2.ucom.debug: 0 > hw.usb2.uhid.debug: 0 > hw.usb2.ukbd.debug: 0 > hw.usb2.ums.debug: 0 > hw.intr_storm_threshold: 1000 > hw.availpages: 4191325 > hw.bus.devctl_disable: 0 > hw.busdma.total_bpages: 8202 > hw.busdma.zone0.total_bpages: 8202 > hw.busdma.zone0.free_bpages: 8202 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 0 > hw.busdma.zone0.total_bounced: 639896 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.alignment: 4096 > hw.clockrate: 1862 > hw.via_feature_xcrypt: 0 > hw.via_feature_rng: 0 > hw.instruction_sse: 1 > hw.apic.enable_extint: 0 > hw.psm.tap_timeout: 125000 > hw.psm.tap_threshold: 25 > hw.ipmi.on: 1 > hw.kbd.keymap_restrict_change: 0 > hw.mca.count: 0 > hw.mca.interval: 3600 > hw.mca.force_scan: 0 > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: NONE > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 1 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > hw.dri.0.name: radeon 0x2a > hw.dri.0.vm: slot offset =A0 =A0 =A0 =A0 =A0 =A0 size =A0 =A0 =A0 type fl= ags address > =A0mtrr > =A0 0 0x00000000d8200000 0x00010000 =A0REG =A00x82 0xffffff00d8200000 no > > hw.dri.0.clients: a dev =A0 pid =A0 =A0uid =A0 =A0 =A0magic =A0 =A0 ioctl= s > > hw.dri.0.debug: 0 > machdep.acpi_timer_freq: 3579545 > machdep.enable_panic_key: 0 > machdep.adjkerntz: 18000 > machdep.wall_cmos_clock: 1 > machdep.disable_rtc_set: 0 > machdep.acpi_root: 1007888 > machdep.disable_mtrrs: 0 > machdep.idle: acpi > machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, machdep.hlt_cp= us: > 0 > machdep.prot_fault_translation: 0 > machdep.panic_on_nmi: 1 > machdep.kdb_on_nmi: 1 > machdep.tsc_freq: 1862013503 > machdep.i8254_freq: 1193182 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 10 > user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: > user.bc_base_max: 99 > user.bc_dim_max: 2048 > user.bc_scale_max: 99 > user.bc_string_max: 1000 > user.coll_weights_max: 0 > user.expr_nest_max: 32 > user.line_max: 2048 > user.re_dup_max: 255 > user.posix2_version: 199212 > user.posix2_c_bind: 0 > user.posix2_c_dev: 0 > user.posix2_char_term: 0 > user.posix2_fort_dev: 0 > user.posix2_fort_run: 0 > user.posix2_localedef: 0 > user.posix2_sw_dev: 0 > user.posix2_upe: 0 > user.stream_max: 20 > user.tzname_max: 255 > p1003_1b.asynchronous_io: 0 > p1003_1b.mapped_files: 1 > p1003_1b.memlock: 0 > p1003_1b.memlock_range: 0 > p1003_1b.memory_protection: 0 > p1003_1b.message_passing: 0 > p1003_1b.prioritized_io: 0 > p1003_1b.priority_scheduling: 1 > p1003_1b.realtime_signals: 200112 > p1003_1b.semaphores: 0 > p1003_1b.fsync: 0 > p1003_1b.shared_memory_objects: 1 > p1003_1b.synchronized_io: 0 > p1003_1b.timers: 200112 > p1003_1b.aio_listio_max: -1 > p1003_1b.aio_max: -1 > p1003_1b.aio_prio_delta_max: -1 > p1003_1b.delaytimer_max: 2147483647 > p1003_1b.mq_open_max: 0 > p1003_1b.pagesize: 4096 > p1003_1b.rtsig_max: 62 > p1003_1b.sem_nsems_max: 0 > p1003_1b.sem_value_max: 0 > p1003_1b.sigqueue_max: 128 > p1003_1b.timer_max: 32 > security.jail.jailed: 0 > security.jail.param.host.hostname: 256 > security.jail.param.securelevel: 0 > security.jail.param.path: 1024 > security.jail.param.cpuset: 0 > security.jail.param.name: 256 > security.jail.param.jid: 0 > security.jail.param.linux.oss_version: 0 > security.jail.param.linux.osrelease: 65 > security.jail.param.linux.osname: 65 > security.jail.jail_max_af_ips: 255 > security.jail.mount_allowed: 0 > security.jail.chflags_allowed: 0 > security.jail.allow_raw_sockets: 0 > security.jail.enforce_statfs: 2 > security.jail.sysvipc_allowed: 0 > security.jail.socket_unixiproute_only: 1 > security.jail.set_hostname_allowed: 1 > security.bsd.suser_enabled: 1 > security.bsd.unprivileged_proc_debug: 1 > security.bsd.conservative_signals: 1 > security.bsd.see_other_gids: 1 > security.bsd.see_other_uids: 1 > security.bsd.unprivileged_read_msgbuf: 1 > security.bsd.hardlink_check_gid: 0 > security.bsd.hardlink_check_uid: 0 > security.bsd.unprivileged_get_quota: 0 > compat.ia32.maxvmem: 0 > compat.ia32.maxssiz: 67108864 > compat.ia32.maxdsiz: 536870912 > compat.linux.oss_version: 198144 > compat.linux.osrelease: 2.6.16 > compat.linux.osname: Linux > compat.linux32.maxvmem: 0 > compat.linux32.maxssiz: 67108864 > compat.linux32.maxdsiz: 536870912 > dev.nexus.0.%driver: nexus > dev.nexus.0.%parent: root0 > dev.ram.0.%desc: System RAM > dev.ram.0.%driver: ram > dev.ram.0.%parent: nexus0 > dev.smbios.0.%desc: System Management BIOS > dev.smbios.0.%driver: smbios > dev.smbios.0.%parent: nexus0 > dev.cryptosoft.0.%desc: software crypto > dev.cryptosoft.0.%driver: cryptosoft > dev.cryptosoft.0.%parent: nexus0 > dev.acpi.0.%desc: SMCI SMCISLP2 > dev.acpi.0.%driver: acpi > dev.acpi.0.%parent: nexus0 > dev.acpi_sysresource.0.%desc: System Resource > dev.acpi_sysresource.0.%driver: acpi_sysresource > dev.acpi_sysresource.0.%location: handle=3D\_SB_.PCI0.LPC0.MBRD > dev.acpi_sysresource.0.%pnpinfo: _HID=3DPNP0C02 _UID=3D31 > dev.acpi_sysresource.0.%parent: acpi0 > dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz > dev.acpi_timer.0.%driver: acpi_timer > dev.acpi_timer.0.%location: unknown > dev.acpi_timer.0.%pnpinfo: unknown > dev.acpi_timer.0.%parent: acpi0 > dev.pci_link.0.%desc: ACPI PCI Link LNKA > dev.pci_link.0.%driver: pci_link > dev.pci_link.0.%location: handle=3D\_SB_.PCI0.LPC0.LNKA > dev.pci_link.0.%pnpinfo: _HID=3DPNP0C0F _UID=3D1 > dev.pci_link.0.%parent: acpi0 > dev.pci_link.1.%desc: ACPI PCI Link LNKB > dev.pci_link.1.%driver: pci_link > dev.pci_link.1.%location: handle=3D\_SB_.PCI0.LPC0.LNKB > dev.pci_link.1.%pnpinfo: _HID=3DPNP0C0F _UID=3D2 > dev.pci_link.1.%parent: acpi0 > dev.pci_link.2.%desc: ACPI PCI Link LNKC > dev.pci_link.2.%driver: pci_link > dev.pci_link.2.%location: handle=3D\_SB_.PCI0.LPC0.LNKC > dev.pci_link.2.%pnpinfo: _HID=3DPNP0C0F _UID=3D3 > dev.pci_link.2.%parent: acpi0 > dev.pci_link.3.%desc: ACPI PCI Link LNKD > dev.pci_link.3.%driver: pci_link > dev.pci_link.3.%location: handle=3D\_SB_.PCI0.LPC0.LNKD > dev.pci_link.3.%pnpinfo: _HID=3DPNP0C0F _UID=3D4 > dev.pci_link.3.%parent: acpi0 > dev.pci_link.4.%desc: ACPI PCI Link LNKE > dev.pci_link.4.%driver: pci_link > dev.pci_link.4.%location: handle=3D\_SB_.PCI0.LPC0.LNKE > dev.pci_link.4.%pnpinfo: _HID=3DPNP0C0F _UID=3D5 > dev.pci_link.4.%parent: acpi0 > dev.pci_link.5.%desc: ACPI PCI Link LNKF > dev.pci_link.5.%driver: pci_link > dev.pci_link.5.%location: handle=3D\_SB_.PCI0.LPC0.LNKF > dev.pci_link.5.%pnpinfo: _HID=3DPNP0C0F _UID=3D6 > dev.pci_link.5.%parent: acpi0 > dev.pci_link.6.%desc: ACPI PCI Link LNKG > dev.pci_link.6.%driver: pci_link > dev.pci_link.6.%location: handle=3D\_SB_.PCI0.LPC0.LNKG > dev.pci_link.6.%pnpinfo: _HID=3DPNP0C0F _UID=3D7 > dev.pci_link.6.%parent: acpi0 > dev.pci_link.7.%desc: ACPI PCI Link LNKH > dev.pci_link.7.%driver: pci_link > dev.pci_link.7.%location: handle=3D\_SB_.PCI0.LPC0.LNKH > dev.pci_link.7.%pnpinfo: _HID=3DPNP0C0F _UID=3D8 > dev.pci_link.7.%parent: acpi0 > dev.acpi_hpet.0.%desc: High Precision Event Timer > dev.acpi_hpet.0.%driver: acpi_hpet > dev.acpi_hpet.0.%location: unknown > dev.acpi_hpet.0.%pnpinfo: unknown > dev.acpi_hpet.0.%parent: acpi0 > dev.pcib.0.%desc: ACPI Host-PCI bridge > dev.pcib.0.%driver: pcib > dev.pcib.0.%location: handle=3D\_SB_.PCI0 > dev.pcib.0.%pnpinfo: _HID=3DPNP0A03 _UID=3D0 > dev.pcib.0.%parent: acpi0 > dev.pcib.1.%desc: ACPI PCI-PCI bridge > dev.pcib.1.%driver: pcib > dev.pcib.1.%location: slot=3D2 function=3D0 handle=3D\_SB_.PCI0.P0P2 > dev.pcib.1.%pnpinfo: vendor=3D0x8086 device=3D0x25f7 subvendor=3D0x0000 > subdevice=3D0x0000 class=3D0x060400 > dev.pcib.1.%parent: pci0 > dev.pcib.1.domain: 0 > dev.pcib.1.pribus: 0 > dev.pcib.1.secbus: 1 > dev.pcib.1.subbus: 7 > dev.pcib.2.%desc: ACPI PCI-PCI bridge > dev.pcib.2.%driver: pcib > dev.pcib.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P2.BMD0 > dev.pcib.2.%pnpinfo: vendor=3D0x8086 device=3D0x3500 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060400 > dev.pcib.2.%parent: pci1 > dev.pcib.2.domain: 0 > dev.pcib.2.pribus: 1 > dev.pcib.2.secbus: 2 > dev.pcib.2.subbus: 6 > dev.pcib.3.%desc: ACPI PCI-PCI bridge > dev.pcib.3.%driver: pcib > dev.pcib.3.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P2.BMD0= .BPD0 > dev.pcib.3.%pnpinfo: vendor=3D0x8086 device=3D0x3510 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060400 > dev.pcib.3.%parent: pci2 > dev.pcib.3.domain: 0 > dev.pcib.3.pribus: 2 > dev.pcib.3.secbus: 3 > dev.pcib.3.subbus: 5 > dev.pcib.4.%desc: ACPI PCI-PCI bridge > dev.pcib.4.%driver: pcib > dev.pcib.4.%location: slot=3D0 function=3D0 > handle=3D\_SB_.PCI0.P0P2.BMD0.BPD0.PXH0 > dev.pcib.4.%pnpinfo: vendor=3D0x8086 device=3D0x0329 subvendor=3D0x0000 > subdevice=3D0x0000 class=3D0x060400 > dev.pcib.4.%parent: pci3 > dev.pcib.4.domain: 0 > dev.pcib.4.pribus: 3 > dev.pcib.4.secbus: 4 > dev.pcib.4.subbus: 4 > dev.pcib.4.wake: 0 > dev.pcib.5.%desc: ACPI PCI-PCI bridge > dev.pcib.5.%driver: pcib > dev.pcib.5.%location: slot=3D0 function=3D2 > handle=3D\_SB_.PCI0.P0P2.BMD0.BPD0.PXH1 > dev.pcib.5.%pnpinfo: vendor=3D0x8086 device=3D0x032a subvendor=3D0x0000 > subdevice=3D0x0000 class=3D0x060400 > dev.pcib.5.%parent: pci3 > dev.pcib.5.domain: 0 > dev.pcib.5.pribus: 3 > dev.pcib.5.secbus: 5 > dev.pcib.5.subbus: 5 > dev.pcib.5.wake: 0 > dev.pcib.6.%desc: ACPI PCI-PCI bridge > dev.pcib.6.%driver: pcib > dev.pcib.6.%location: slot=3D2 function=3D0 handle=3D\_SB_.PCI0.P0P2.BMD0= .BPD2 > dev.pcib.6.%pnpinfo: vendor=3D0x8086 device=3D0x3518 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060400 > dev.pcib.6.%parent: pci2 > dev.pcib.6.domain: 0 > dev.pcib.6.pribus: 2 > dev.pcib.6.secbus: 6 > dev.pcib.6.subbus: 6 > dev.pcib.6.wake: 0 > dev.pcib.7.%desc: ACPI PCI-PCI bridge > dev.pcib.7.%driver: pcib > dev.pcib.7.%location: slot=3D0 function=3D3 handle=3D\_SB_.PCI0.P0P2.BMF3 > dev.pcib.7.%pnpinfo: vendor=3D0x8086 device=3D0x350c subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060400 > dev.pcib.7.%parent: pci1 > dev.pcib.7.domain: 0 > dev.pcib.7.pribus: 1 > dev.pcib.7.secbus: 7 > dev.pcib.7.subbus: 7 > dev.pcib.7.wake: 0 > dev.pcib.8.%desc: ACPI PCI-PCI bridge > dev.pcib.8.%driver: pcib > dev.pcib.8.%location: slot=3D4 function=3D0 handle=3D\_SB_.PCI0.P0P4 > dev.pcib.8.%pnpinfo: vendor=3D0x8086 device=3D0x25f8 subvendor=3D0x0000 > subdevice=3D0x0000 class=3D0x060400 > dev.pcib.8.%parent: pci0 > dev.pcib.8.domain: 0 > dev.pcib.8.pribus: 0 > dev.pcib.8.secbus: 8 > dev.pcib.8.subbus: 8 > dev.pcib.8.wake: 0 > dev.pcib.9.%desc: ACPI PCI-PCI bridge > dev.pcib.9.%driver: pcib > dev.pcib.9.%location: slot=3D6 function=3D0 handle=3D\_SB_.PCI0.P0P6 > dev.pcib.9.%pnpinfo: vendor=3D0x8086 device=3D0x25f9 subvendor=3D0x0000 > subdevice=3D0x0000 class=3D0x060400 > dev.pcib.9.%parent: pci0 > dev.pcib.9.domain: 0 > dev.pcib.9.pribus: 0 > dev.pcib.9.secbus: 9 > dev.pcib.9.subbus: 9 > dev.pcib.9.wake: 0 > dev.pcib.10.%desc: ACPI PCI-PCI bridge > dev.pcib.10.%driver: pcib > dev.pcib.10.%location: slot=3D28 function=3D0 handle=3D\_SB_.PCI0.PEX0 > dev.pcib.10.%pnpinfo: vendor=3D0x8086 device=3D0x2690 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060400 > dev.pcib.10.%parent: pci0 > dev.pcib.10.domain: 0 > dev.pcib.10.pribus: 0 > dev.pcib.10.secbus: 10 > dev.pcib.10.subbus: 10 > dev.pcib.10.wake: 0 > dev.pcib.11.%desc: ACPI PCI-PCI bridge > dev.pcib.11.%driver: pcib > dev.pcib.11.%location: slot=3D30 function=3D0 handle=3D\_SB_.PCI0.PCIB > dev.pcib.11.%pnpinfo: vendor=3D0x8086 device=3D0x244e subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060401 > dev.pcib.11.%parent: pci0 > dev.pcib.11.domain: 0 > dev.pcib.11.pribus: 0 > dev.pcib.11.secbus: 11 > dev.pcib.11.subbus: 11 > dev.pcib.11.wake: 0 > dev.pci.0.%desc: ACPI PCI bus > dev.pci.0.%driver: pci > dev.pci.0.%parent: pcib0 > dev.pci.1.%desc: ACPI PCI bus > dev.pci.1.%driver: pci > dev.pci.1.%parent: pcib1 > dev.pci.2.%desc: ACPI PCI bus > dev.pci.2.%driver: pci > dev.pci.2.%parent: pcib2 > dev.pci.3.%desc: ACPI PCI bus > dev.pci.3.%driver: pci > dev.pci.3.%parent: pcib3 > dev.pci.4.%desc: ACPI PCI bus > dev.pci.4.%driver: pci > dev.pci.4.%parent: pcib4 > dev.pci.4.wake: 0 > dev.pci.5.%desc: ACPI PCI bus > dev.pci.5.%driver: pci > dev.pci.5.%parent: pcib5 > dev.pci.5.wake: 0 > dev.pci.6.%desc: ACPI PCI bus > dev.pci.6.%driver: pci > dev.pci.6.%parent: pcib6 > dev.pci.6.wake: 0 > dev.pci.7.%desc: ACPI PCI bus > dev.pci.7.%driver: pci > dev.pci.7.%parent: pcib7 > dev.pci.7.wake: 0 > dev.pci.8.%desc: ACPI PCI bus > dev.pci.8.%driver: pci > dev.pci.8.%parent: pcib8 > dev.pci.8.wake: 0 > dev.pci.9.%desc: ACPI PCI bus > dev.pci.9.%driver: pci > dev.pci.9.%parent: pcib9 > dev.pci.9.wake: 0 > dev.pci.10.%desc: ACPI PCI bus > dev.pci.10.%driver: pci > dev.pci.10.%parent: pcib10 > dev.pci.10.wake: 0 > dev.pci.11.%desc: ACPI PCI bus > dev.pci.11.%driver: pci > dev.pci.11.%parent: pcib11 > dev.pci.11.wake: 0 > dev.hostb.0.%desc: Host to PCI bridge > dev.hostb.0.%driver: hostb > dev.hostb.0.%location: slot=3D0 function=3D0 > dev.hostb.0.%pnpinfo: vendor=3D0x8086 device=3D0x25d8 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.0.%parent: pci0 > dev.hostb.1.%desc: Host to PCI bridge > dev.hostb.1.%driver: hostb > dev.hostb.1.%location: slot=3D16 function=3D0 > dev.hostb.1.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.1.%parent: pci0 > dev.hostb.2.%desc: Host to PCI bridge > dev.hostb.2.%driver: hostb > dev.hostb.2.%location: slot=3D16 function=3D1 > dev.hostb.2.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.2.%parent: pci0 > dev.hostb.3.%desc: Host to PCI bridge > dev.hostb.3.%driver: hostb > dev.hostb.3.%location: slot=3D16 function=3D2 > dev.hostb.3.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.3.%parent: pci0 > dev.hostb.4.%desc: Host to PCI bridge > dev.hostb.4.%driver: hostb > dev.hostb.4.%location: slot=3D17 function=3D0 > dev.hostb.4.%pnpinfo: vendor=3D0x8086 device=3D0x25f1 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.4.%parent: pci0 > dev.hostb.5.%desc: Host to PCI bridge > dev.hostb.5.%driver: hostb > dev.hostb.5.%location: slot=3D19 function=3D0 > dev.hostb.5.%pnpinfo: vendor=3D0x8086 device=3D0x25f3 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.5.%parent: pci0 > dev.hostb.6.%desc: Host to PCI bridge > dev.hostb.6.%driver: hostb > dev.hostb.6.%location: slot=3D21 function=3D0 > dev.hostb.6.%pnpinfo: vendor=3D0x8086 device=3D0x25f5 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.6.%parent: pci0 > dev.hostb.7.%desc: Host to PCI bridge > dev.hostb.7.%driver: hostb > dev.hostb.7.%location: slot=3D22 function=3D0 > dev.hostb.7.%pnpinfo: vendor=3D0x8086 device=3D0x25f6 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060000 > dev.hostb.7.%parent: pci0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 > dev.em.0.%driver: em > dev.em.0.%location: slot=3D0 function=3D0 > dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x15d9 > subdevice=3D0x0000 class=3D0x020000 > dev.em.0.%parent: pci6 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 > dev.em.1.%driver: em > dev.em.1.%location: slot=3D0 function=3D1 > dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x15d9 > subdevice=3D0x0000 class=3D0x020000 > dev.em.1.%parent: pci6 > dev.em.1.debug: -1 > dev.em.1.stats: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 > dev.uhci.0.%driver: uhci > dev.uhci.0.%location: slot=3D29 function=3D0 handle=3D\_SB_.PCI0.USB1 > dev.uhci.0.%pnpinfo: vendor=3D0x8086 device=3D0x2688 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x0c0300 > dev.uhci.0.%parent: pci0 > dev.uhci.0.wake: 0 > dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 > dev.uhci.1.%driver: uhci > dev.uhci.1.%location: slot=3D29 function=3D1 handle=3D\_SB_.PCI0.USB2 > dev.uhci.1.%pnpinfo: vendor=3D0x8086 device=3D0x2689 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x0c0300 > dev.uhci.1.%parent: pci0 > dev.uhci.1.wake: 0 > dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 > dev.uhci.2.%driver: uhci > dev.uhci.2.%location: slot=3D29 function=3D2 handle=3D\_SB_.PCI0.USB3 > dev.uhci.2.%pnpinfo: vendor=3D0x8086 device=3D0x268a subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x0c0300 > dev.uhci.2.%parent: pci0 > dev.uhci.2.wake: 0 > dev.usbus.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 > dev.usbus.0.%driver: usbus > dev.usbus.0.%parent: uhci0 > dev.usbus.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 > dev.usbus.1.%driver: usbus > dev.usbus.1.%parent: uhci1 > dev.usbus.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 > dev.usbus.2.%driver: usbus > dev.usbus.2.%parent: uhci2 > dev.usbus.3.%desc: Intel 63XXESB USB 2.0 controller > dev.usbus.3.%driver: usbus > dev.usbus.3.%parent: ehci0 > dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller > dev.ehci.0.%driver: ehci > dev.ehci.0.%location: slot=3D29 function=3D7 handle=3D\_SB_.PCI0.EUSB > dev.ehci.0.%pnpinfo: vendor=3D0x8086 device=3D0x268c subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x0c0320 > dev.ehci.0.%parent: pci0 > dev.ehci.0.wake: 0 > dev.vgapci.0.%desc: VGA-compatible display > dev.vgapci.0.%driver: vgapci > dev.vgapci.0.%location: slot=3D1 function=3D0 > dev.vgapci.0.%pnpinfo: vendor=3D0x1002 device=3D0x515e subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x030000 > dev.vgapci.0.%parent: pci11 > dev.drm.0.%desc: ATI ES1000 RN50 > dev.drm.0.%driver: drm > dev.drm.0.%parent: vgapci0 > dev.isab.0.%desc: PCI-ISA bridge > dev.isab.0.%driver: isab > dev.isab.0.%location: slot=3D31 function=3D0 handle=3D\_SB_.PCI0.LPC0 > dev.isab.0.%pnpinfo: vendor=3D0x8086 device=3D0x2670 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x060100 > dev.isab.0.%parent: pci0 > dev.isa.0.%desc: ISA bus > dev.isa.0.%driver: isa > dev.isa.0.%parent: isab0 > dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller > dev.atapci.0.%driver: atapci > dev.atapci.0.%location: slot=3D31 function=3D1 handle=3D\_SB_.PCI0.IDEC > dev.atapci.0.%pnpinfo: vendor=3D0x8086 device=3D0x269e subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x01018a > dev.atapci.0.%parent: pci0 > dev.atapci.1.%desc: Intel 63XXESB2 SATA300 controller > dev.atapci.1.%driver: atapci > dev.atapci.1.%location: slot=3D31 function=3D2 > dev.atapci.1.%pnpinfo: vendor=3D0x8086 device=3D0x2681 subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x010601 > dev.atapci.1.%parent: pci0 > dev.ata.0.%desc: ATA channel 0 > dev.ata.0.%driver: ata > dev.ata.0.%parent: atapci0 > dev.ata.2.%desc: ATA channel 0 > dev.ata.2.%driver: ata > dev.ata.2.%parent: atapci1 > dev.ata.3.%desc: ATA channel 1 > dev.ata.3.%driver: ata > dev.ata.3.%parent: atapci1 > dev.ata.4.%desc: ATA channel 2 > dev.ata.4.%driver: ata > dev.ata.4.%parent: atapci1 > dev.ata.5.%desc: ATA channel 3 > dev.ata.5.%driver: ata > dev.ata.5.%parent: atapci1 > dev.ata.6.%desc: ATA channel 4 > dev.ata.6.%driver: ata > dev.ata.6.%parent: atapci1 > dev.ata.7.%desc: ATA channel 5 > dev.ata.7.%driver: ata > dev.ata.7.%parent: atapci1 > dev.ichsmb.0.%desc: Intel 631xESB/6321ESB (ESB2) SMBus controller > dev.ichsmb.0.%driver: ichsmb > dev.ichsmb.0.%location: slot=3D31 function=3D3 handle=3D\_SB_.PCI0.SMBS > dev.ichsmb.0.%pnpinfo: vendor=3D0x8086 device=3D0x269b subvendor=3D0x15d9 > subdevice=3D0x8080 class=3D0x0c0500 > dev.ichsmb.0.%parent: pci0 > dev.smbus.0.%desc: System Management Bus > dev.smbus.0.%driver: smbus > dev.smbus.0.%parent: ichsmb0 > dev.smb.0.%desc: SMBus generic I/O > dev.smb.0.%driver: smb > dev.smb.0.%parent: smbus0 > dev.acpi_button.0.%desc: Power Button > dev.acpi_button.0.%driver: acpi_button > dev.acpi_button.0.%location: handle=3D\_SB_.PCI0.PWRB > dev.acpi_button.0.%pnpinfo: _HID=3DPNP0C0C _UID=3D0 > dev.acpi_button.0.%parent: acpi0 > dev.atdma.0.%desc: AT DMA controller > dev.atdma.0.%driver: atdma > dev.atdma.0.%location: handle=3D\_SB_.PCI0.LPC0.DMAC > dev.atdma.0.%pnpinfo: _HID=3DPNP0200 _UID=3D0 > dev.atdma.0.%parent: acpi0 > dev.fpupnp.0.%desc: Legacy ISA coprocessor support > dev.fpupnp.0.%driver: fpupnp > dev.fpupnp.0.%location: handle=3D\_SB_.PCI0.LPC0.MATH > dev.fpupnp.0.%pnpinfo: _HID=3DPNP0C04 _UID=3D0 > dev.fpupnp.0.%parent: acpi0 > dev.atrtc.0.%desc: AT realtime clock > dev.atrtc.0.%driver: atrtc > dev.atrtc.0.%location: handle=3D\_SB_.PCI0.LPC0.RTC_ > dev.atrtc.0.%pnpinfo: _HID=3DPNP0B00 _UID=3D0 > dev.atrtc.0.%parent: acpi0 > dev.attimer.0.%desc: AT timer > dev.attimer.0.%driver: attimer > dev.attimer.0.%location: handle=3D\_SB_.PCI0.LPC0.TIME > dev.attimer.0.%pnpinfo: _HID=3DPNP0100 _UID=3D0 > dev.attimer.0.%parent: acpi0 > dev.atkbdc.0.%desc: Keyboard controller (i8042) > dev.atkbdc.0.%driver: atkbdc > dev.atkbdc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.KBC0 > dev.atkbdc.0.%pnpinfo: _HID=3DPNP0303 _UID=3D0 > dev.atkbdc.0.%parent: acpi0 > dev.atkbdc.0.wake: 0 > dev.atkbd.0.%desc: AT Keyboard > dev.atkbd.0.%driver: atkbd > dev.atkbd.0.%parent: atkbdc0 > dev.psmcpnp.0.%desc: PS/2 mouse port > dev.psmcpnp.0.%driver: psmcpnp > dev.psmcpnp.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.MSE0 > dev.psmcpnp.0.%pnpinfo: _HID=3DPNP0F13 _UID=3D0 > dev.psmcpnp.0.%parent: acpi0 > dev.psmcpnp.0.wake: 0 > dev.uart.0.%desc: 16550 or compatible > dev.uart.0.%driver: uart > dev.uart.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.COM1 > dev.uart.0.%pnpinfo: _HID=3DPNP0501 _UID=3D1 > dev.uart.0.%parent: acpi0 > dev.uart.0.wake: 0 > dev.uart.1.%desc: 16550 or compatible > dev.uart.1.%driver: uart > dev.uart.1.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.COM2 > dev.uart.1.%pnpinfo: _HID=3DPNP0501 _UID=3D2 > dev.uart.1.%parent: acpi0 > dev.uart.1.wake: 0 > dev.fdc.0.%desc: Enhanced floppy controller > dev.fdc.0.%driver: fdc > dev.fdc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.FDC_ > dev.fdc.0.%pnpinfo: _HID=3DPNP0700 _UID=3D1 > dev.fdc.0.%parent: acpi0 > dev.fd.0.%desc: 1440-KB 3.5" drive > dev.fd.0.%driver: fd > dev.fd.0.%parent: fdc0 > dev.ppc.0.%desc: Parallel port > dev.ppc.0.%driver: ppc > dev.ppc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.PRT_ > dev.ppc.0.%pnpinfo: _HID=3DPNP0401 _UID=3D2 > dev.ppc.0.%parent: acpi0 > dev.ppbus.0.%desc: Parallel port bus > dev.ppbus.0.%driver: ppbus > dev.ppbus.0.%parent: ppc0 > dev.lpt.0.%desc: Printer > dev.lpt.0.%driver: lpt > dev.lpt.0.%parent: ppbus0 > dev.ppi.0.%desc: Parallel I/O > dev.ppi.0.%driver: ppi > dev.ppi.0.%parent: ppbus0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=3D\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.temperature: 57 > dev.cpu.0.freq: 1867 > dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 933/17= 500 > 700/13125 466/8750 233/4375 > dev.cpu.0.cx_supported: C1/1 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% last 500us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=3D\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.temperature: 59 > dev.cpu.1.cx_supported: C1/1 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% last 500us > dev.cpu.2.%desc: ACPI CPU > dev.cpu.2.%driver: cpu > dev.cpu.2.%location: handle=3D\_PR_.CPU2 > dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.temperature: 59 > dev.cpu.2.cx_supported: C1/1 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% last 500us > dev.cpu.3.%desc: ACPI CPU > dev.cpu.3.%driver: cpu > dev.cpu.3.%location: handle=3D\_PR_.CPU3 > dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.temperature: 60 > dev.cpu.3.cx_supported: C1/1 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% last 500us > dev.acpi_perf.0.%driver: acpi_perf > dev.acpi_perf.0.%parent: cpu0 > dev.acpi_perf.1.%driver: acpi_perf > dev.acpi_perf.1.%parent: cpu1 > dev.acpi_perf.2.%driver: acpi_perf > dev.acpi_perf.2.%parent: cpu2 > dev.acpi_perf.3.%driver: acpi_perf > dev.acpi_perf.3.%parent: cpu3 > dev.coretemp.0.%desc: CPU On-Die Thermal Sensors > dev.coretemp.0.%driver: coretemp > dev.coretemp.0.%parent: cpu0 > dev.coretemp.1.%desc: CPU On-Die Thermal Sensors > dev.coretemp.1.%driver: coretemp > dev.coretemp.1.%parent: cpu1 > dev.coretemp.2.%desc: CPU On-Die Thermal Sensors > dev.coretemp.2.%driver: coretemp > dev.coretemp.2.%parent: cpu2 > dev.coretemp.3.%desc: CPU On-Die Thermal Sensors > dev.coretemp.3.%driver: coretemp > dev.coretemp.3.%parent: cpu3 > dev.est.0.%desc: Enhanced SpeedStep Frequency Control > dev.est.0.%driver: est > dev.est.0.%parent: cpu0 > dev.est.0.freq_settings: 1867/35000 > dev.est.1.%desc: Enhanced SpeedStep Frequency Control > dev.est.1.%driver: est > dev.est.1.%parent: cpu1 > dev.est.1.freq_settings: 1867/35000 > dev.est.2.%desc: Enhanced SpeedStep Frequency Control > dev.est.2.%driver: est > dev.est.2.%parent: cpu2 > dev.est.2.freq_settings: 1867/35000 > dev.est.3.%desc: Enhanced SpeedStep Frequency Control > dev.est.3.%driver: est > dev.est.3.%parent: cpu3 > dev.est.3.freq_settings: 1867/35000 > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%parent: cpu0 > dev.cpufreq.1.%driver: cpufreq > dev.cpufreq.1.%parent: cpu1 > dev.cpufreq.2.%driver: cpufreq > dev.cpufreq.2.%parent: cpu2 > dev.cpufreq.3.%driver: cpufreq > dev.cpufreq.3.%parent: cpu3 > dev.p4tcc.0.%desc: CPU Frequency Thermal Control > dev.p4tcc.0.%driver: p4tcc > dev.p4tcc.0.%parent: cpu0 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/= -1 > 2500/-1 1250/-1 > dev.p4tcc.1.%desc: CPU Frequency Thermal Control > dev.p4tcc.1.%driver: p4tcc > dev.p4tcc.1.%parent: cpu1 > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/= -1 > 2500/-1 1250/-1 > dev.p4tcc.2.%desc: CPU Frequency Thermal Control > dev.p4tcc.2.%driver: p4tcc > dev.p4tcc.2.%parent: cpu2 > dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/= -1 > 2500/-1 1250/-1 > dev.p4tcc.3.%desc: CPU Frequency Thermal Control > dev.p4tcc.3.%driver: p4tcc > dev.p4tcc.3.%parent: cpu3 > dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/= -1 > 2500/-1 1250/-1 > dev.apic.0.%desc: APIC resources > dev.apic.0.%driver: apic > dev.apic.0.%parent: nexus0 > dev.ipmi.0.%desc: IPMI System Interface > dev.ipmi.0.%driver: ipmi > dev.ipmi.0.%parent: isa0 > dev.orm.0.%desc: ISA Option ROM > dev.orm.0.%driver: orm > dev.orm.0.%parent: isa0 > dev.sc.0.%desc: System console > dev.sc.0.%driver: sc > dev.sc.0.%parent: isa0 > dev.vga.0.%desc: Generic ISA VGA > dev.vga.0.%driver: vga > dev.vga.0.%parent: isa0 > dev.acd.0.%desc: Memorex DVD+-RAM 510L v1/MWS7 > dev.acd.0.%driver: acd > dev.acd.0.%parent: ata0 > dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 > dev.uhub.0.%driver: uhub > dev.uhub.0.%parent: usbus0 > dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 > dev.uhub.1.%driver: uhub > dev.uhub.1.%parent: usbus1 > dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 > dev.uhub.2.%driver: uhub > dev.uhub.2.%parent: usbus2 > dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 > dev.uhub.3.%driver: uhub > dev.uhub.3.%parent: usbus3 > dev.atapicam.0.%desc: ATAPI CAM Attachment > dev.atapicam.0.%driver: atapicam > dev.atapicam.0.%parent: ata0 > dev.atapicam.1.%desc: ATAPI CAM Attachment > dev.atapicam.1.%driver: atapicam > dev.atapicam.1.%parent: ata2 > dev.atapicam.2.%desc: ATAPI CAM Attachment > dev.atapicam.2.%driver: atapicam > dev.atapicam.2.%parent: ata3 > dev.atapicam.3.%desc: ATAPI CAM Attachment > dev.atapicam.3.%driver: atapicam > dev.atapicam.3.%parent: ata4 > dev.atapicam.4.%desc: ATAPI CAM Attachment > dev.atapicam.4.%driver: atapicam > dev.atapicam.4.%parent: ata5 > dev.atapicam.5.%desc: ATAPI CAM Attachment > dev.atapicam.5.%driver: atapicam > dev.atapicam.5.%parent: ata6 > dev.atapicam.6.%desc: ATAPI CAM Attachment > dev.atapicam.6.%driver: atapicam > dev.atapicam.6.%parent: ata7 > dev.ad.4.%desc: ST3400620AS/3.AAJ > dev.ad.4.%driver: ad > dev.ad.4.%parent: ata2 > dev.ad.6.%desc: ST3400620AS/3.AAJ > dev.ad.6.%driver: ad > dev.ad.6.%parent: ata3 > dev.ad.8.%desc: ST3500630AS/3.AAE > dev.ad.8.%driver: ad > dev.ad.8.%parent: ata4 > dev.ad.10.%desc: ST3400620AS/3.AAJ > dev.ad.10.%driver: ad > dev.ad.10.%parent: ata5 > dev.ad.12.%desc: ST3400620AS/3.AAJ > dev.ad.12.%driver: ad > dev.ad.12.%parent: ata6 > dev.ad.14.%desc: ST3400620AS/3.AAJ > dev.ad.14.%driver: ad > dev.ad.14.%parent: ata7 > dev.ums.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr= 2 > dev.ums.0.%driver: ums > dev.ums.0.%location: port=3D6 interface=3D0 > dev.ums.0.%pnpinfo: vendor=3D0x14dd product=3D0x0002 devclass=3D0x00 > devsubclass=3D0x00 sernum=3D"05269e0157450fa9611C11C62A54F306" intclass= =3D0x03 > intsubclass=3D0x00 > dev.ums.0.%parent: uhub3 > dev.ukbd.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, add= r 2 > dev.ukbd.0.%driver: ukbd > dev.ukbd.0.%location: port=3D6 interface=3D1 > dev.ukbd.0.%pnpinfo: vendor=3D0x14dd product=3D0x0002 devclass=3D0x00 > devsubclass=3D0x00 sernum=3D"05269e0157450fa9611C11C62A54F306" intclass= =3D0x03 > intsubclass=3D0x01 > dev.ukbd.0.%parent: uhub3 > kstat.zfs.misc.arcstats.hits: 1799140 > kstat.zfs.misc.arcstats.misses: 501784 > kstat.zfs.misc.arcstats.demand_data_hits: 575806 > kstat.zfs.misc.arcstats.demand_data_misses: 83877 > kstat.zfs.misc.arcstats.demand_metadata_hits: 949664 > kstat.zfs.misc.arcstats.demand_metadata_misses: 71350 > kstat.zfs.misc.arcstats.prefetch_data_hits: 126189 > kstat.zfs.misc.arcstats.prefetch_data_misses: 326939 > kstat.zfs.misc.arcstats.prefetch_metadata_hits: 147481 > kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19618 > kstat.zfs.misc.arcstats.mru_hits: 1115709 > kstat.zfs.misc.arcstats.mru_ghost_hits: 0 > kstat.zfs.misc.arcstats.mfu_hits: 490457 > kstat.zfs.misc.arcstats.mfu_ghost_hits: 0 > kstat.zfs.misc.arcstats.deleted: 9687 > kstat.zfs.misc.arcstats.recycle_miss: 0 > kstat.zfs.misc.arcstats.mutex_miss: 0 > kstat.zfs.misc.arcstats.evict_skip: 0 > kstat.zfs.misc.arcstats.hash_elements: 546247 > kstat.zfs.misc.arcstats.hash_elements_max: 549954 > kstat.zfs.misc.arcstats.hash_collisions: 396590 > kstat.zfs.misc.arcstats.hash_chains: 160935 > kstat.zfs.misc.arcstats.hash_chain_max: 12 > kstat.zfs.misc.arcstats.p: 9317411840 > kstat.zfs.misc.arcstats.c: 16093925376 > kstat.zfs.misc.arcstats.c_min: 2011740672 > kstat.zfs.misc.arcstats.c_max: 16093925376 > kstat.zfs.misc.arcstats.size: 12788124608 > kstat.zfs.misc.arcstats.hdr_size: 113621248 > kstat.zfs.misc.arcstats.l2_hits: 0 > kstat.zfs.misc.arcstats.l2_misses: 0 > kstat.zfs.misc.arcstats.l2_feeds: 0 > kstat.zfs.misc.arcstats.l2_rw_clash: 0 > kstat.zfs.misc.arcstats.l2_writes_sent: 0 > kstat.zfs.misc.arcstats.l2_writes_done: 0 > kstat.zfs.misc.arcstats.l2_writes_error: 0 > kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 > kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 > kstat.zfs.misc.arcstats.l2_evict_reading: 0 > kstat.zfs.misc.arcstats.l2_free_on_write: 0 > kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 > kstat.zfs.misc.arcstats.l2_cksum_bad: 0 > kstat.zfs.misc.arcstats.l2_io_error: 0 > kstat.zfs.misc.arcstats.l2_size: 0 > kstat.zfs.misc.arcstats.l2_hdr_size: 0 > kstat.zfs.misc.arcstats.memory_throttle_count: 0 > kstat.zfs.misc.vdev_cache_stats.delegations: 19244 > kstat.zfs.misc.vdev_cache_stats.hits: 63137 > kstat.zfs.misc.vdev_cache_stats.misses: 53109 > > Ideas? > > >> >> >> > > -- > Larry Rosenman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.lerctr.= org/~ler > Phone: +1 512-248-2683 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 E-Mail: ler@lerctr= .org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Tue May 19 00:07:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B75106566C; Tue, 19 May 2009 00:07:18 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 295978FC14; Tue, 19 May 2009 00:07:18 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:22597 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6CrO-000EWd-7z; Mon, 18 May 2009 19:07:17 -0500 Date: Mon, 18 May 2009 19:06:57 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Kip Macy In-Reply-To: <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> Message-ID: References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.6 (/) X-LERCTR-Spam-Score: 0.6 (/) X-Spam-Report: SpamScore (0.6/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 X-LERCTR-Spam-Report: SpamScore (0.6/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 DomainKey-Status: no signature Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 00:07:18 -0000 On Mon, 18 May 2009, Kip Macy wrote: > The ARC cache allocates wired memory. The ARC will grow until there is > vm pressure. My crash this AM was with 4G real, and the ARC seemed to grow and grow, then we started paging, and then crashed. Even with the VM pressure it seemed to grow out of control. Ideas? > > -Kip > > > On Mon, May 18, 2009 at 4:32 PM, Larry Rosenman wrote: >> On Mon, 18 May 2009, Larry Rosenman wrote: >> >>> On Mon, 18 May 2009, Adam McDougall wrote: >>> >>>> I'm not sure if this is related to recent kernel memory code changes >>>> or what, but it hasn't happened with code from earlier than a couple >>>> days ago. I had this happen twice, I think the first time was with >>>> arc max set to 1024M, the second time was when arc max was unset in >>>> loader.conf and the system had been up a few hours but the arc hadn't >>>> been squeezed down to a small number yet: >>>> Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M >>>> Free >>>> >>>> I've deleted the kernel since then but I did not change my sources, >>>> I could build a new one and check where the pointers point to I think? >>>> If needed. Or I could reproduce the panic if needed. It doesn't dump, >>>> it just gets stuck after printing the panic. >>> >>> I wonder if this is the same crash I saw without getting all the info. >>> >>> What I saw was the wired memory getting to be most of the memory on the >>> box, and then boom. >>> >>> see my post a few above this. >> >> Ok, something(tm) is seriously messed up. I was able to get my hands on 12G >> more memory, and with that, the backup finishes, but the wired count is >> insane: >> >> >> last pid: 1760; load averages: 5.46, 7.01, 6.43 up 0+00:37:54 >> 18:31:41 >> 78 processes: 5 running, 73 sleeping >> >> Mem: 440M Active, 4020K Inact, 13G Wired, 524K Cache, 441M Buf, 1970M Free >> Swap: 4096M Total, 4096M Free >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 1403 ler 1 138 20 141M 118M RUN 2 31:53 100.00% >> FahCore_7 >> 1400 ler 1 138 20 141M 117M CPU0 0 31:51 100.00% >> FahCore_7 >> 1397 ler 1 138 20 141M 118M CPU3 3 31:46 100.00% >> FahCore_7 >> 1235 ler 1 138 20 20072K 11404K CPU1 1 31:34 100.00% >> FahCore_7 >> 1209 ler 1 44 20 141M 118M nanslp 0 0:07 0.00% >> FahCore_78 >> 1206 ler 1 44 20 141M 117M nanslp 0 0:07 0.00% >> FahCore_78 >> 1207 ler 1 44 20 141M 118M nanslp 2 0:06 0.00% >> FahCore_78 >> 1098 pgsql 1 44 0 62052K 34948K select 2 0:02 0.00% >> postgres >> 1069 root 1 44 0 19096K 6172K nanslp 0 0:01 0.00% perl >> 1202 ler 1 44 0 194M 776K nanslp 2 0:00 0.00% fah6 >> 1203 ler 1 44 0 194M 776K nanslp 1 0:00 0.00% fah6 >> 1204 ler 1 44 0 194M 776K nanslp 1 0:00 0.00% fah6 >> 1205 ler 1 44 0 194M 768K nanslp 1 0:00 0.00% fah6 >> 1095 pgsql 1 44 0 62052K 5664K select 0 0:00 0.00% >> postgres >> 1208 ler 1 44 20 20072K 11404K nanslp 2 0:00 0.00% >> FahCore_78 >> 1756 ler 1 44 0 23900K 8672K nanslp 0 0:00 0.00% alpine >> 988 root 1 44 0 10612K 2376K select 2 0:00 0.00% ntpd >> 1182 root 1 44 0 17636K 7048K nanslp 2 0:00 0.00% perl >> >> Sysctl -a: >> >> kern.ostype: FreeBSD >> kern.osrelease: 8.0-CURRENT >> kern.osrevision: 199506 >> kern.version: FreeBSD 8.0-CURRENT #18: Mon May 18 04:18:03 CDT 2009 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG >> >> kern.maxvnodes: 100000 >> kern.maxproc: 6164 >> kern.maxfiles: 12328 >> kern.argmax: 262144 >> kern.securelevel: -1 >> kern.hostname: borg.lerctr.org >> kern.hostid: 3935026275 >> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } >> kern.posix1version: 200112 >> kern.ngroups: 16 >> kern.job_control: 1 >> kern.saved_ids: 0 >> kern.boottime: { sec = 1242687257, usec = 281783 } Mon May 18 17:54:17 2009 >> kern.domainname: kern.osreldate: 800087 >> kern.bootfile: /boot/kernel/kernel >> kern.maxfilesperproc: 11095 >> kern.maxprocperuid: 5547 >> kern.ipc.maxsockbuf: 262144 >> kern.ipc.sockbuf_waste_factor: 8 >> kern.ipc.somaxconn: 128 >> kern.ipc.max_linkhdr: 16 >> kern.ipc.max_protohdr: 60 >> kern.ipc.max_hdr: 76 >> kern.ipc.max_datalen: 92 >> kern.ipc.nmbjumbo16: 3200 >> kern.ipc.nmbjumbo9: 6400 >> kern.ipc.nmbjumbop: 12800 >> kern.ipc.nmbclusters: 25600 >> kern.ipc.piperesizeallowed: 1 >> kern.ipc.piperesizefail: 0 >> kern.ipc.pipeallocfail: 0 >> kern.ipc.pipefragretry: 0 >> kern.ipc.pipekva: 98304 >> kern.ipc.maxpipekva: 277905408 >> kern.ipc.msgseg: 2048 >> kern.ipc.msgssz: 8 >> kern.ipc.msgtql: 40 >> kern.ipc.msgmnb: 2048 >> kern.ipc.msgmni: 40 >> kern.ipc.msgmax: 16384 >> kern.ipc.semaem: 16384 >> kern.ipc.semvmx: 32767 >> kern.ipc.semusz: 152 >> kern.ipc.semume: 10 >> kern.ipc.semopm: 100 >> kern.ipc.semmsl: 60 >> kern.ipc.semmnu: 30 >> kern.ipc.semmns: 4096 >> kern.ipc.semmni: 2048 >> kern.ipc.semmap: 30 >> kern.ipc.shm_allow_removed: 0 >> kern.ipc.shm_use_phys: 0 >> kern.ipc.shmall: 8192000 >> kern.ipc.shmseg: 128 >> kern.ipc.shmmni: 192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 819200000 >> kern.ipc.maxsockets: 25600 >> kern.ipc.numopensockets: 63 >> kern.ipc.nsfbufsused: 0 >> kern.ipc.nsfbufspeak: 0 >> kern.ipc.nsfbufs: 0 >> kern.dummy: 0 >> kern.ps_strings: 140737488355296 >> kern.usrstack: 140737488355328 >> kern.logsigexit: 1 >> kern.iov_max: 1024 >> kern.hostuuid: 53D19F64-D663-A017-8922-003048339480 >> kern.cam.cam_srch_hi: 0 >> kern.cam.scsi_delay: 5000 >> kern.cam.cd.retry_count: 4 >> kern.cam.cd.changer.max_busy_seconds: 15 >> kern.cam.cd.changer.min_busy_seconds: 5 >> kern.cam.cd.0.minimum_cmd_size: 10 >> kern.cam.da.da_send_ordered: 1 >> kern.cam.da.default_timeout: 60 >> kern.cam.da.retry_count: 4 >> kern.rndtest.verbose: 1 >> kern.rndtest.retest: 120 >> kern.disks: cd0 ad14 ad12 ad10 ad8 ad6 ad4 >> kern.geom.collectstats: 1 >> kern.geom.debugflags: 0 >> kern.geom.label.debug: 0 >> kern.elf64.fallback_brand: -1 >> kern.init_shutdown_timeout: 120 >> kern.init_path: >> /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall >> kern.acct_suspended: 0 >> kern.acct_configured: 0 >> kern.acct_chkfreq: 15 >> kern.acct_resume: 4 >> kern.acct_suspend: 2 >> kern.cp_times: 3050 257577 31202 420 9098 2948 258837 29420 2264 7280 2800 >> 260523 30701 171 6615 2523 263506 27118 122 7538 >> kern.cp_time: 11321 1040443 118441 2977 30531 >> kern.constty_wakeups_per_second: 5 >> kern.consmsgbuf_size: 8192 >> kern.consmute: 0 >> kern.console: ttyv0,/ttyv0,uart,gdb, >> kern.openfiles: 220 >> kern.kq_calloutmax: 4096 >> kern.ps_arg_cache_limit: 256 >> kern.stackprot: 7 >> kern.randompid: 0 >> kern.lastpid: 1762 >> kern.ktrace.request_pool: 100 >> kern.ktrace.genio_size: 4096 >> kern.module_path: /boot/kernel;/boot/modules >> kern.malloc_count: 267 >> kern.fallback_elf_brand: -1 >> kern.features.compat_freebsd7: 1 >> kern.features.compat_freebsd6: 1 >> kern.features.compat_freebsd5: 1 >> kern.features.compat_freebsd4: 1 >> kern.features.posix_shm: 1 >> kern.maxusers: 384 >> kern.ident: BORG >> kern.kstack_pages: 4 >> kern.shutdown.kproc_shutdown_wait: 60 >> kern.shutdown.poweroff_delay: 5000 >> kern.sync_on_panic: 0 >> kern.corefile: %N.core >> kern.nodump_coredump: 0 >> kern.coredump: 1 >> kern.sugid_coredump: 0 >> kern.sigqueue.alloc_fail: 0 >> kern.sigqueue.overflow: 0 >> kern.sigqueue.preallocate: 1024 >> kern.sigqueue.max_pending_per_proc: 128 >> kern.forcesigexit: 1 >> kern.fscale: 2048 >> kern.timecounter.tick: 1 >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: ACPI-fast >> kern.timecounter.stepwarnings: 0 >> kern.timecounter.tc.i8254.mask: 65535 >> kern.timecounter.tc.i8254.counter: 62178 >> kern.timecounter.tc.i8254.frequency: 1193182 >> kern.timecounter.tc.i8254.quality: 0 >> kern.timecounter.tc.ACPI-fast.mask: 16777215 >> kern.timecounter.tc.ACPI-fast.counter: 3310006 >> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >> kern.timecounter.tc.ACPI-fast.quality: 1000 >> kern.timecounter.tc.HPET.mask: 4294967295 >> kern.timecounter.tc.HPET.counter: 2523974339 >> kern.timecounter.tc.HPET.frequency: 14318180 >> kern.timecounter.tc.HPET.quality: 900 >> kern.timecounter.tc.TSC.mask: 4294967295 >> kern.timecounter.tc.TSC.counter: 1218885212 >> kern.timecounter.tc.TSC.frequency: 1862013503 >> kern.timecounter.tc.TSC.quality: -100 >> kern.timecounter.smp_tsc: 0 >> kern.timecounter.invariant_tsc: 1 >> kern.threads.max_threads_hits: 0 >> kern.threads.max_threads_per_proc: 1500 >> kern.ccpu: 0 >> kern.sched.preemption: 1 >> kern.sched.topology_spec: >> >> 0, 1, 2, 3 >> >> >> >> 0, 1 >> >> >> >> 2, 3 >> >> >> >> >> >> >> kern.sched.steal_thresh: 2 >> kern.sched.steal_idle: 1 >> kern.sched.steal_htt: 1 >> kern.sched.balance_interval: 133 >> kern.sched.balance: 1 >> kern.sched.affinity: 1 >> kern.sched.idlespinthresh: 4 >> kern.sched.idlespins: 10000 >> kern.sched.static_boost: 160 >> kern.sched.preempt_thresh: 64 >> kern.sched.interact: 30 >> kern.sched.slice: 13 >> kern.sched.name: ULE >> kern.devstat.version: 6 >> kern.devstat.generation: 225 >> kern.devstat.numdevs: 9 >> kern.kobj_methodcount: 155 >> kern.log_wakeups_per_second: 5 >> kern.vm_guest: none >> kern.sgrowsiz: 131072 >> kern.maxssiz: 536870912 >> kern.dflssiz: 8388608 >> kern.maxdsiz: 34359738368 >> kern.dfldsiz: 134217728 >> kern.maxtsiz: 134217728 >> kern.maxbcache: 1073741824 >> kern.maxswzone: 33554432 >> kern.nswbuf: 256 >> kern.nbuf: 65536 >> kern.ncallout: 18508 >> kern.hz: 1000 >> kern.msgbuf_clear: 0 >> kern.msgbuf: kern.always_console_output: 0 >> kern.log_console_output: 1 >> kern.smp.forward_roundrobin_enabled: 1 >> kern.smp.forward_signal_enabled: 1 >> kern.smp.topology: 0 >> kern.smp.cpus: 4 >> kern.smp.disabled: 0 >> kern.smp.active: 1 >> kern.smp.maxcpus: 32 >> kern.smp.maxid: 3 >> kern.tty_inq_nslow: 297 >> kern.tty_inq_nfast: 1701 >> kern.tty_outq_nslow: 0 >> kern.tty_outq_nfast: 0 >> kern.pts_maxdev: 999 >> kern.tty_pty_warningcnt: 10 >> kern.tty_nout: 4730961 >> kern.tty_nin: 2138 >> kern.minvnodes: 25000 >> kern.metadelay: 28 >> kern.dirdelay: 29 >> kern.filedelay: 30 >> kern.chroot_allow_open_directories: 1 >> kern.cryptodevallowsoft: 0 >> kern.userasymcrypto: 1 >> kern.rpc.invalid: 0 >> kern.rpc.unexpected: 0 >> kern.rpc.timeouts: 0 >> kern.rpc.request: 0 >> kern.rpc.retries: 0 >> kern.elf32.fallback_brand: -1 >> kern.random.yarrow.gengateinterval: 10 >> kern.random.yarrow.bins: 10 >> kern.random.yarrow.fastthresh: 192 >> kern.random.yarrow.slowthresh: 256 >> kern.random.yarrow.slowoverthresh: 2 >> kern.random.sys.seeded: 1 >> kern.random.sys.harvest.ethernet: 1 >> kern.random.sys.harvest.point_to_point: 1 >> kern.random.sys.harvest.interrupt: 1 >> kern.random.sys.harvest.swi: 0 >> vm.vmtotal: System wide totals computed every five seconds: (values in >> kilobytes) >> =============================================== >> Processes: (RUNQ: 5 Disk Wait: 0 Page Wait: 0 Sleep: 73) >> Virtual Memory: (Total: 1076206992K, Active 2349180K) >> Real Memory: (Total: 1103632K Active 455252K) >> Shared Virtual Memory: (Total: 20708K Active: 14128K) >> Shared Real Memory: (Total: 9388K Active: 8756K) >> Free Memory Pages: 2017432K >> >> vm.loadavg: { 5.08 6.77 6.36 } >> vm.v_free_min: 25703 >> vm.v_free_target: 108162 >> vm.v_free_reserved: 5350 >> vm.v_inactive_target: 162243 >> vm.v_cache_min: 108162 >> vm.v_cache_max: 216324 >> vm.v_pageout_free_min: 34 >> vm.pageout_algorithm: 0 >> vm.swap_enabled: 1 >> vm.kmem_size_scale: 3 >> vm.kmem_size_max: 329853485875 >> vm.kmem_size_min: 0 >> vm.kmem_size: 5558173696 >> vm.nswapdev: 1 >> vm.dmmax: 32 >> vm.swap_async_max: 4 >> vm.zone_count: 98 >> vm.swap_idle_threshold2: 10 >> vm.swap_idle_threshold1: 2 >> vm.exec_map_entries: 16 >> vm.stats.misc.zero_page_count: 59 >> vm.stats.misc.cnt_prezero: 0 >> vm.stats.vm.v_kthreadpages: 0 >> vm.stats.vm.v_rforkpages: 2236 >> vm.stats.vm.v_vforkpages: 39693 >> vm.stats.vm.v_forkpages: 363901 >> vm.stats.vm.v_kthreads: 141 >> vm.stats.vm.v_rforks: 28 >> vm.stats.vm.v_vforks: 198 >> vm.stats.vm.v_forks: 1395 >> vm.stats.vm.v_interrupt_free_min: 2 >> vm.stats.vm.v_pageout_free_min: 34 >> vm.stats.vm.v_cache_max: 216324 >> vm.stats.vm.v_cache_min: 108162 >> vm.stats.vm.v_cache_count: 123 >> vm.stats.vm.v_inactive_count: 1005 >> vm.stats.vm.v_inactive_target: 162243 >> vm.stats.vm.v_active_count: 112687 >> vm.stats.vm.v_wire_count: 3452797 >> vm.stats.vm.v_free_count: 504231 >> vm.stats.vm.v_free_min: 25703 >> vm.stats.vm.v_free_target: 108162 >> vm.stats.vm.v_free_reserved: 5350 >> vm.stats.vm.v_page_count: 4070929 >> vm.stats.vm.v_page_size: 4096 >> vm.stats.vm.v_tfree: 19085156 >> vm.stats.vm.v_pfree: 612782 >> vm.stats.vm.v_dfree: 0 >> vm.stats.vm.v_tcached: 3100 >> vm.stats.vm.v_pdpages: 0 >> vm.stats.vm.v_pdwakeups: 0 >> vm.stats.vm.v_reactivated: 2925 >> vm.stats.vm.v_intrans: 704 >> vm.stats.vm.v_vnodepgsout: 1 >> vm.stats.vm.v_vnodepgsin: 6890 >> vm.stats.vm.v_vnodeout: 1 >> vm.stats.vm.v_vnodein: 5806 >> vm.stats.vm.v_swappgsout: 0 >> vm.stats.vm.v_swappgsin: 0 >> vm.stats.vm.v_swapout: 0 >> vm.stats.vm.v_swapin: 0 >> vm.stats.vm.v_ozfod: 27 >> vm.stats.vm.v_zfod: 2565409 >> vm.stats.vm.v_cow_optim: 397 >> vm.stats.vm.v_cow_faults: 64414 >> vm.stats.vm.v_vm_faults: 2768133 >> vm.stats.sys.v_soft: 1359531 >> vm.stats.sys.v_intr: 715196 >> vm.stats.sys.v_syscall: 6458471 >> vm.stats.sys.v_trap: 6074556 >> vm.stats.sys.v_swtch: 8393310 >> vm.stats.object.bypasses: 757 >> vm.stats.object.collapses: 5656 >> vm.v_free_severe: 15526 >> vm.max_proc_mmap: 496265 >> vm.old_msync: 0 >> vm.msync_flush_flags: 3 >> vm.boot_pages: 48 >> vm.max_wired: 1345352 >> vm.pageout_lock_miss: 0 >> vm.disable_swapspace_pageouts: 0 >> vm.defer_swapspace_pageouts: 0 >> vm.swap_idle_enabled: 0 >> vm.pageout_stats_interval: 5 >> vm.pageout_full_stats_interval: 20 >> vm.pageout_stats_max: 108162 >> vm.max_launder: 32 >> vm.phys_segs: SEGMENT 0: >> >> start: 0x1000 >> end: 0x98000 >> free list: 0xffffffff80849668 >> >> SEGMENT 1: >> >> start: 0xb8a000 >> end: 0x1000000 >> free list: 0xffffffff80849668 >> >> SEGMENT 2: >> >> start: 0x1000000 >> end: 0xcff50000 >> free list: 0xffffffff808492c0 >> >> SEGMENT 3: >> >> start: 0x100000000 >> end: 0x4129b4000 >> free list: 0xffffffff808492c0 >> >> vm.phys_free: FREE LIST 0: >> >> ORDER (SIZE) | NUMBER >> | POOL 0 | POOL 1 | POOL 2 >> -- -- -- -- -- -- -- -- >> 12 ( 16384K) | 91 | 0 | 0 >> 11 ( 8192K) | 3 | 1 | 0 >> 10 ( 4096K) | 7 | 1 | 0 >> 9 ( 2048K) | 0 | 1 | 0 >> 8 ( 1024K) | 4 | 1 | 0 >> 7 ( 512K) | 10 | 0 | 0 >> 6 ( 256K) | 7 | 0 | 0 >> 5 ( 128K) | 11 | 0 | 0 >> 4 ( 64K) | 32 | 0 | 0 >> 3 ( 32K) | 246 | 0 | 0 >> 2 ( 16K) | 929 | 3 | 1 >> 1 ( 8K) | 1849 | 1 | 7 >> 0 ( 4K) | 9492 | 0 | 73 >> >> FREE LIST 1: >> >> ORDER (SIZE) | NUMBER >> | POOL 0 | POOL 1 | POOL 2 >> -- -- -- -- -- -- -- -- >> 12 ( 16384K) | 0 | 0 | 0 >> 11 ( 8192K) | 0 | 0 | 0 >> 10 ( 4096K) | 1 | 0 | 0 >> 9 ( 2048K) | 0 | 0 | 0 >> 8 ( 1024K) | 0 | 0 | 0 >> 7 ( 512K) | 0 | 0 | 0 >> 6 ( 256K) | 2 | 0 | 0 >> 5 ( 128K) | 2 | 0 | 0 >> 4 ( 64K) | 2 | 0 | 0 >> 3 ( 32K) | 2 | 0 | 0 >> 2 ( 16K) | 2 | 0 | 0 >> 1 ( 8K) | 3 | 0 | 0 >> 0 ( 4K) | 0 | 0 | 0 >> >> vm.reserv.reclaimed: 0 >> vm.reserv.partpopq: LEVEL SIZE NUMBER >> >> -1: 362368K, 326 >> >> vm.reserv.freed: 11598 >> vm.reserv.broken: 8 >> vm.idlezero_enable: 0 >> vm.kvm_free: 542615007232 >> vm.kvm_size: 549755809792 >> vm.pmap.pmap_collect_active: 0 >> vm.pmap.pmap_collect_inactive: 0 >> vm.pmap.pv_entry_spare: 8566 >> vm.pmap.pv_entry_allocs: 3744878 >> vm.pmap.pv_entry_frees: 3679188 >> vm.pmap.pc_chunk_tryfail: 0 >> vm.pmap.pc_chunk_frees: 13290 >> vm.pmap.pc_chunk_allocs: 13732 >> vm.pmap.pc_chunk_count: 442 >> vm.pmap.pv_entry_count: 65690 >> vm.pmap.pdpe.demotions: 0 >> vm.pmap.pde.promotions: 110851 >> vm.pmap.pde.p_failures: 1022233 >> vm.pmap.pde.mappings: 0 >> vm.pmap.pde.demotions: 107618 >> vm.pmap.shpgperproc: 200 >> vm.pmap.pv_entry_max: 5303729 >> vm.pmap.pg_ps_enabled: 1 >> vfs.zfs.arc_meta_limit: 4023481344 >> vfs.zfs.arc_meta_used: 1192541184 >> vfs.zfs.mdcomp_disable: 0 >> vfs.zfs.arc_min: 2011740672 >> vfs.zfs.arc_max: 16093925376 >> vfs.zfs.zfetch.array_rd_sz: 1048576 >> vfs.zfs.zfetch.block_cap: 256 >> vfs.zfs.zfetch.min_sec_reap: 2 >> vfs.zfs.zfetch.max_streams: 8 >> vfs.zfs.prefetch_disable: 0 >> vfs.zfs.recover: 0 >> vfs.zfs.txg.synctime: 5 >> vfs.zfs.txg.timeout: 30 >> vfs.zfs.scrub_limit: 10 >> vfs.zfs.vdev.cache.bshift: 16 >> vfs.zfs.vdev.cache.size: 10485760 >> vfs.zfs.vdev.cache.max: 16384 >> vfs.zfs.vdev.aggregation_limit: 131072 >> vfs.zfs.vdev.ramp_rate: 2 >> vfs.zfs.vdev.time_shift: 6 >> vfs.zfs.vdev.min_pending: 4 >> vfs.zfs.vdev.max_pending: 35 >> vfs.zfs.cache_flush_disable: 0 >> vfs.zfs.zil_disable: 0 >> vfs.zfs.version.zpl: 3 >> vfs.zfs.version.vdev_boot: 1 >> vfs.zfs.version.spa: 13 >> vfs.zfs.version.dmu_backup_stream: 1 >> vfs.zfs.version.dmu_backup_header: 2 >> vfs.zfs.version.acl: 1 >> vfs.zfs.debug: 0 >> vfs.zfs.super_owner: 1 >> vfs.ufs.dirhash_docheck: 0 >> vfs.ufs.dirhash_mem: 39648 >> vfs.ufs.dirhash_maxmem: 2097152 >> vfs.ufs.dirhash_minsize: 2560 >> vfs.devfs.rule_depth: 1 >> vfs.devfs.generation: 139 >> vfs.nfs4.access_cache_timeout: 60 >> vfs.nfs.downdelayinitial: 12 >> vfs.nfs.downdelayinterval: 30 >> vfs.nfs.skip_wcc_data_onerr: 1 >> vfs.nfs.nfs3_jukebox_delay: 10 >> vfs.nfs.reconnects: 0 >> vfs.nfs.bufpackets: 4 >> vfs.nfs.realign_count: 0 >> vfs.nfs.realign_test: 0 >> vfs.nfs.defect: 0 >> vfs.nfs.iodmax: 20 >> vfs.nfs.iodmin: 0 >> vfs.nfs.iodmaxidle: 120 >> vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 >> vfs.nfs.nfs_ip_paranoia: 1 >> vfs.nfs.nfs_directio_allow_mmap: 1 >> vfs.nfs.nfs_directio_enable: 0 >> vfs.nfs.clean_pages_on_close: 1 >> vfs.nfs.nfsv3_commit_on_close: 0 >> vfs.nfs.prime_access_cache: 0 >> vfs.nfs.access_cache_timeout: 60 >> vfs.pfs.trace: 0 >> vfs.pfs.vncache.misses: 0 >> vfs.pfs.vncache.hits: 0 >> vfs.pfs.vncache.maxentries: 0 >> vfs.pfs.vncache.entries: 0 >> vfs.flushwithdeps: 0 >> vfs.notbufdflashes: 0 >> vfs.flushbufqtarget: 100 >> vfs.getnewbufrestarts: 0 >> vfs.getnewbufcalls: 28204 >> vfs.hifreebuffers: 7290 >> vfs.lofreebuffers: 3645 >> vfs.numfreebuffers: 65534 >> vfs.dirtybufthresh: 14763 >> vfs.hidirtybuffers: 16404 >> vfs.lodirtybuffers: 8202 >> vfs.numdirtybuffers: 2 >> vfs.recursiveflushes: 0 >> vfs.altbufferflushes: 0 >> vfs.bdwriteskip: 0 >> vfs.dirtybufferflushes: 0 >> vfs.hirunningspace: 1048576 >> vfs.lorunningspace: 524288 >> vfs.bufdefragcnt: 0 >> vfs.buffreekvacnt: 0 >> vfs.bufreusecnt: 28198 >> vfs.hibufspace: 1073086464 >> vfs.lobufspace: 1073020928 >> vfs.maxmallocbufspace: 53654323 >> vfs.bufmallocspace: 0 >> vfs.maxbufspace: 1073741824 >> vfs.bufspace: 461996032 >> vfs.runningbufspace: 0 >> vfs.vmiodirenable: 1 >> vfs.cache.numfullpathfound: 124 >> vfs.cache.numfullpathfail4: 0 >> vfs.cache.numfullpathfail2: 0 >> vfs.cache.numfullpathfail1: 0 >> vfs.cache.numfullpathcalls: 124 >> vfs.cache.nchstats: 4488983 27354 228 0 466972 0 33 156 >> vfs.cache.numupgrades: 28 >> vfs.cache.numneghits: 27354 >> vfs.cache.numnegzaps: 57 >> vfs.cache.numposhits: 4488983 >> vfs.cache.numposzaps: 171 >> vfs.cache.nummisszap: 309 >> vfs.cache.nummiss: 466663 >> vfs.cache.numchecks: 5829112 >> vfs.cache.dotdothits: 47 >> vfs.cache.dothits: 1035 >> vfs.cache.numcalls: 4984636 >> vfs.cache.numcache: 30787 >> vfs.cache.numneg: 766 >> vfs.read_max: 8 >> vfs.write_behind: 1 >> vfs.lookup_shared: 1 >> vfs.usermount: 1 >> vfs.worklist_len: 1 >> vfs.timestamp_precision: 0 >> vfs.reassignbufcalls: 611 >> vfs.freevnodes: 24986 >> vfs.wantfreevnodes: 25000 >> vfs.numvnodes: 29998 >> vfs.nfsrv.nfs_privport: 0 >> vfs.nfsrv.fha.bin_shift: 18 >> vfs.nfsrv.fha.max_nfsds_per_fh: 8 >> vfs.nfsrv.fha.max_reqs_per_nfsd: 4 >> vfs.nfsrv.fha.fhe_stats: No file handle entries. >> vfs.nfsrv.commit_miss: 0 >> vfs.nfsrv.commit_blks: 0 >> vfs.nfsrv.async: 0 >> vfs.nfsrv.realign_count: 0 >> vfs.nfsrv.realign_test: 0 >> vfs.nfsrv.gatherdelay_v3: 0 >> vfs.nfsrv.gatherdelay: 10000 >> vfs.nfsrv.minthreads: 4 >> vfs.nfsrv.maxthreads: 4 >> vfs.nfsrv.threads: 4 >> vfs.nfsrv.request_space_used: 0 >> vfs.nfsrv.request_space_used_highest: 0 >> vfs.nfsrv.request_space_high: 13107200 >> vfs.nfsrv.request_space_low: 8738133 >> vfs.nfsrv.request_space_throttled: 0 >> vfs.nfsrv.request_space_throttle_count: 0 >> vfs.ffs.doreallocblks: 1 >> vfs.ffs.doasyncfree: 1 >> vfs.ffs.compute_summary_at_mount: 0 >> net.local.stream.recvspace: 8192 >> net.local.stream.sendspace: 8192 >> net.local.dgram.recvspace: 4096 >> net.local.dgram.maxdgram: 2048 >> net.local.taskcount: 0 >> net.local.recycled: 0 >> net.local.inflight: 0 >> net.inet.ip.portrange.randomtime: 45 >> net.inet.ip.portrange.randomcps: 10 >> net.inet.ip.portrange.randomized: 1 >> net.inet.ip.portrange.reservedlow: 0 >> net.inet.ip.portrange.reservedhigh: 1023 >> net.inet.ip.portrange.hilast: 65535 >> net.inet.ip.portrange.hifirst: 49152 >> net.inet.ip.portrange.last: 65535 >> net.inet.ip.portrange.first: 10000 >> net.inet.ip.portrange.lowlast: 600 >> net.inet.ip.portrange.lowfirst: 1023 >> net.inet.ip.forwarding: 0 >> net.inet.ip.redirect: 1 >> net.inet.ip.ttl: 64 >> net.inet.ip.rtexpire: 3600 >> net.inet.ip.rtminexpire: 10 >> net.inet.ip.rtmaxcache: 128 >> net.inet.ip.sourceroute: 0 >> net.inet.ip.intr_queue_maxlen: 50 >> net.inet.ip.intr_queue_drops: 0 >> net.inet.ip.accept_sourceroute: 0 >> net.inet.ip.keepfaith: 0 >> net.inet.ip.gifttl: 30 >> net.inet.ip.same_prefix_carp_only: 0 >> net.inet.ip.subnets_are_local: 0 >> net.inet.ip.random_id_total: 0 >> net.inet.ip.random_id_collisions: 0 >> net.inet.ip.random_id_period: 8192 >> net.inet.ip.mcast.loop: 1 >> net.inet.ip.mcast.maxsocksrc: 128 >> net.inet.ip.mcast.maxgrpsrc: 512 >> net.inet.ip.fastforwarding: 0 >> net.inet.ip.maxfragpackets: 800 >> net.inet.ip.output_flowtable_size: 0 >> net.inet.ip.maxfragsperpacket: 16 >> net.inet.ip.fragpackets: 0 >> net.inet.ip.check_interface: 0 >> net.inet.ip.random_id: 0 >> net.inet.ip.sendsourcequench: 0 >> net.inet.ip.process_options: 1 >> net.inet.icmp.maskrepl: 0 >> net.inet.icmp.icmplim: 200 >> net.inet.icmp.bmcastecho: 0 >> net.inet.icmp.quotelen: 8 >> net.inet.icmp.reply_from_interface: 0 >> net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 >> net.inet.icmp.log_redirect: 0 >> net.inet.icmp.drop_redirect: 0 >> net.inet.icmp.maskfake: 0 >> net.inet.igmp.gsrdelay: 10 >> net.inet.igmp.default_version: 3 >> net.inet.igmp.legacysupp: 0 >> net.inet.igmp.v2enable: 1 >> net.inet.igmp.v1enable: 1 >> net.inet.igmp.sendlocal: 1 >> net.inet.igmp.sendra: 1 >> net.inet.igmp.recvifkludge: 1 >> net.inet.tcp.rfc1323: 1 >> net.inet.tcp.mssdflt: 512 >> net.inet.tcp.keepidle: 7200000 >> net.inet.tcp.keepintvl: 75000 >> net.inet.tcp.sendspace: 32768 >> net.inet.tcp.recvspace: 65536 >> net.inet.tcp.keepinit: 75000 >> net.inet.tcp.delacktime: 100 >> net.inet.tcp.v6mssdflt: 1024 >> net.inet.tcp.hostcache.purge: 0 >> net.inet.tcp.hostcache.prune: 300 >> net.inet.tcp.hostcache.expire: 3600 >> net.inet.tcp.hostcache.count: 3 >> net.inet.tcp.hostcache.bucketlimit: 30 >> net.inet.tcp.hostcache.hashsize: 512 >> net.inet.tcp.hostcache.cachelimit: 15360 >> net.inet.tcp.wlock_looped: 0 >> net.inet.tcp.wlock_relocked: 0 >> net.inet.tcp.wlock_upgraded: 262 >> net.inet.tcp.tcp_wlock_atfirst: 416 >> net.inet.tcp.rlock_atfirst: 829900 >> net.inet.tcp.read_locking: 1 >> net.inet.tcp.recvbuf_max: 262144 >> net.inet.tcp.recvbuf_inc: 16384 >> net.inet.tcp.recvbuf_auto: 1 >> net.inet.tcp.insecure_rst: 0 >> net.inet.tcp.ecn.maxretries: 1 >> net.inet.tcp.ecn.enable: 0 >> net.inet.tcp.abc_l_var: 2 >> net.inet.tcp.rfc3465: 1 >> net.inet.tcp.rfc3390: 1 >> net.inet.tcp.rfc3042: 1 >> net.inet.tcp.drop_synfin: 0 >> net.inet.tcp.delayed_ack: 1 >> net.inet.tcp.blackhole: 0 >> net.inet.tcp.log_in_vain: 0 >> net.inet.tcp.sendbuf_max: 262144 >> net.inet.tcp.sendbuf_inc: 8192 >> net.inet.tcp.sendbuf_auto: 1 >> net.inet.tcp.tso: 1 >> net.inet.tcp.newreno: 1 >> net.inet.tcp.local_slowstart_flightsize: 4 >> net.inet.tcp.slowstart_flightsize: 1 >> net.inet.tcp.path_mtu_discovery: 1 >> net.inet.tcp.reass.overflows: 0 >> net.inet.tcp.reass.maxqlen: 48 >> net.inet.tcp.reass.cursegments: 0 >> net.inet.tcp.reass.maxsegments: 1600 >> net.inet.tcp.sack.globalholes: 0 >> net.inet.tcp.sack.globalmaxholes: 65536 >> net.inet.tcp.sack.maxholes: 128 >> net.inet.tcp.sack.enable: 1 >> net.inet.tcp.inflight.stab: 20 >> net.inet.tcp.inflight.max: 1073725440 >> net.inet.tcp.inflight.min: 6144 >> net.inet.tcp.inflight.rttthresh: 10 >> net.inet.tcp.inflight.debug: 0 >> net.inet.tcp.inflight.enable: 1 >> net.inet.tcp.isn_reseed_interval: 0 >> net.inet.tcp.icmp_may_rst: 1 >> net.inet.tcp.pcbcount: 26 >> net.inet.tcp.do_tcpdrain: 1 >> net.inet.tcp.tcbhashsize: 512 >> net.inet.tcp.log_debug: 0 >> net.inet.tcp.minmss: 216 >> net.inet.tcp.syncache.rst_on_sock_fail: 1 >> net.inet.tcp.syncache.rexmtlimit: 3 >> net.inet.tcp.syncache.hashsize: 512 >> net.inet.tcp.syncache.count: 0 >> net.inet.tcp.syncache.cachelimit: 15360 >> net.inet.tcp.syncache.bucketlimit: 30 >> net.inet.tcp.syncookies_only: 0 >> net.inet.tcp.syncookies: 1 >> net.inet.tcp.timer_race: 0 >> net.inet.tcp.finwait2_timeout: 60000 >> net.inet.tcp.fast_finwait2_recycle: 0 >> net.inet.tcp.always_keepalive: 1 >> net.inet.tcp.rexmit_slop: 200 >> net.inet.tcp.rexmit_min: 30 >> net.inet.tcp.msl: 30000 >> net.inet.tcp.nolocaltimewait: 0 >> net.inet.tcp.maxtcptw: 5120 >> net.inet.udp.checksum: 1 >> net.inet.udp.maxdgram: 9216 >> net.inet.udp.recvspace: 42080 >> net.inet.udp.blackhole: 0 >> net.inet.udp.log_in_vain: 0 >> net.inet.sctp.nat_friendly_init: 1 >> net.inet.sctp.enable_sack_immediately: 0 >> net.inet.sctp.udp_tunneling_port: 0 >> net.inet.sctp.udp_tunneling_for_client_enable: 0 >> net.inet.sctp.mobility_fasthandoff: 0 >> net.inet.sctp.mobility_base: 0 >> net.inet.sctp.default_frag_interleave: 1 >> net.inet.sctp.default_cc_module: 0 >> net.inet.sctp.log_level: 0 >> net.inet.sctp.max_retran_chunk: 30 >> net.inet.sctp.min_residual: 1452 >> net.inet.sctp.strict_data_order: 0 >> net.inet.sctp.abort_at_limit: 0 >> net.inet.sctp.hb_max_burst: 4 >> net.inet.sctp.do_sctp_drain: 1 >> net.inet.sctp.max_chained_mbufs: 5 >> net.inet.sctp.abc_l_var: 1 >> net.inet.sctp.nat_friendly: 1 >> net.inet.sctp.auth_disable: 0 >> net.inet.sctp.asconf_auth_nochk: 0 >> net.inet.sctp.early_fast_retran_msec: 250 >> net.inet.sctp.early_fast_retran: 0 >> net.inet.sctp.cwnd_maxburst: 1 >> net.inet.sctp.cmt_pf: 0 >> net.inet.sctp.cmt_use_dac: 0 >> net.inet.sctp.nr_sack_on_off: 0 >> net.inet.sctp.cmt_on_off: 0 >> net.inet.sctp.outgoing_streams: 10 >> net.inet.sctp.add_more_on_output: 1452 >> net.inet.sctp.path_rtx_max: 5 >> net.inet.sctp.assoc_rtx_max: 10 >> net.inet.sctp.init_rtx_max: 8 >> net.inet.sctp.valid_cookie_life: 60000 >> net.inet.sctp.init_rto_max: 60000 >> net.inet.sctp.rto_initial: 3000 >> net.inet.sctp.rto_min: 1000 >> net.inet.sctp.rto_max: 60000 >> net.inet.sctp.secret_lifetime: 3600 >> net.inet.sctp.shutdown_guard_time: 180 >> net.inet.sctp.pmtu_raise_time: 600 >> net.inet.sctp.heartbeat_interval: 30000 >> net.inet.sctp.asoc_resource: 10 >> net.inet.sctp.sys_resource: 1000 >> net.inet.sctp.sack_freq: 2 >> net.inet.sctp.delayed_sack_time: 200 >> net.inet.sctp.chunkscale: 10 >> net.inet.sctp.min_split_point: 2904 >> net.inet.sctp.pcbhashsize: 256 >> net.inet.sctp.tcbhashsize: 1024 >> net.inet.sctp.maxchunks: 3200 >> net.inet.sctp.maxburst: 4 >> net.inet.sctp.peer_chkoh: 256 >> net.inet.sctp.strict_init: 1 >> net.inet.sctp.loopback_nocsum: 1 >> net.inet.sctp.strict_sacks: 1 >> net.inet.sctp.ecn_nonce: 0 >> net.inet.sctp.ecn_enable: 1 >> net.inet.sctp.auto_asconf: 1 >> net.inet.sctp.recvspace: 233016 >> net.inet.sctp.sendspace: 233016 >> net.inet.raw.recvspace: 9216 >> net.inet.raw.maxdgram: 9216 >> net.inet.accf.unloadable: 0 >> net.inet.flowtable.nmbflows: 4096 >> net.inet.flowtable.tcp_expire: 86400 >> net.inet.flowtable.fin_wait_expire: 600 >> net.inet.flowtable.udp_expire: 300 >> net.inet.flowtable.syn_expire: 300 >> net.inet.flowtable.collisions: 0 >> net.inet.flowtable.max_depth: 0 >> net.inet.flowtable.free_checks: 0 >> net.inet.flowtable.frees: 0 >> net.inet.flowtable.misses: 0 >> net.inet.flowtable.lookups: 0 >> net.inet.flowtable.hits: 0 >> net.inet.flowtable.enable: 0 >> net.link.generic.system.ifcount: 3 >> net.link.ether.inet.log_arp_permanent_modify: 1 >> net.link.ether.inet.log_arp_movements: 1 >> net.link.ether.inet.log_arp_wrong_iface: 1 >> net.link.ether.inet.proxyall: 0 >> net.link.ether.inet.useloopback: 1 >> net.link.ether.inet.maxtries: 5 >> net.link.ether.inet.max_age: 1200 >> net.link.ether.ipfw: 0 >> net.link.gif.parallel_tunnels: 0 >> net.link.gif.max_nesting: 1 >> net.link.log_link_state_change: 1 >> net.link.tun.devfs_cloning: 1 >> net.inet6.ip6.forwarding: 0 >> net.inet6.ip6.redirect: 1 >> net.inet6.ip6.hlim: 64 >> net.inet6.ip6.maxfragpackets: 6400 >> net.inet6.ip6.accept_rtadv: 0 >> net.inet6.ip6.keepfaith: 0 >> net.inet6.ip6.log_interval: 5 >> net.inet6.ip6.hdrnestlimit: 15 >> net.inet6.ip6.dad_count: 1 >> net.inet6.ip6.auto_flowlabel: 1 >> net.inet6.ip6.defmcasthlim: 1 >> net.inet6.ip6.gifhlim: 30 >> net.inet6.ip6.kame_version: FreeBSD >> net.inet6.ip6.use_deprecated: 1 >> net.inet6.ip6.rr_prune: 5 >> net.inet6.ip6.v6only: 1 >> net.inet6.ip6.rtexpire: 3600 >> net.inet6.ip6.rtminexpire: 10 >> net.inet6.ip6.rtmaxcache: 128 >> net.inet6.ip6.use_tempaddr: 0 >> net.inet6.ip6.temppltime: 86400 >> net.inet6.ip6.tempvltime: 604800 >> net.inet6.ip6.auto_linklocal: 0 >> net.inet6.ip6.prefer_tempaddr: 0 >> net.inet6.ip6.use_defaultzone: 0 >> net.inet6.ip6.maxfrags: 6400 >> net.inet6.ip6.mcast_pmtu: 0 >> net.inet6.ip6.mcast.loop: 1 >> net.inet6.ip6.mcast.maxsocksrc: 128 >> net.inet6.ip6.mcast.maxgrpsrc: 512 >> net.inet6.icmp6.rediraccept: 1 >> net.inet6.icmp6.redirtimeout: 600 >> net.inet6.icmp6.nd6_prune: 1 >> net.inet6.icmp6.nd6_delay: 5 >> net.inet6.icmp6.nd6_umaxtries: 3 >> net.inet6.icmp6.nd6_mmaxtries: 3 >> net.inet6.icmp6.nd6_useloopback: 1 >> net.inet6.icmp6.nodeinfo: 3 >> net.inet6.icmp6.errppslimit: 100 >> net.inet6.icmp6.nd6_maxnudhint: 0 >> net.inet6.icmp6.nd6_debug: 0 >> net.inet6.icmp6.nd6_maxqueuelen: 1 >> net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 >> net.inet6.mld.gsrdelay: 10 >> net.bpf.zerocopy_enable: 0 >> net.bpf.maxinsns: 512 >> net.bpf.maxbufsize: 524288 >> net.bpf.bufsize: 4096 >> net.isr.swi_count: 419599 >> net.isr.drop: 0 >> net.isr.queued: 830117 >> net.isr.deferred: 0 >> net.isr.directed: 3109 >> net.isr.count: 3109 >> net.isr.direct: 1 >> net.raw.recvspace: 8192 >> net.raw.sendspace: 8192 >> net.my_fibnum: 0 >> net.add_addr_allfibs: 1 >> net.fibs: 1 >> net.route.netisr_maxqlen: 256 >> debug.ddb.capture.bufsize: 49152 >> debug.ddb.capture.inprogress: 0 >> debug.ddb.capture.maxbufsize: 5242880 >> debug.ddb.capture.bufoff: 0 >> debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: >> debug.ddb.textdump.do_version: 1 >> debug.ddb.textdump.do_panic: 1 >> debug.ddb.textdump.do_msgbuf: 1 >> debug.ddb.textdump.do_ddb: 1 >> debug.ddb.textdump.do_config: 1 >> debug.ddb.textdump.pending: 0 >> debug.ddb_use_printf: 0 >> debug.acpi.semaphore_debug: 0 >> debug.acpi.suspend_bounce: 0 >> debug.acpi.reset_clock: 1 >> debug.acpi.do_powerstate: 1 >> debug.acpi.acpi_ca_version: 20070320 >> debug.acpi.ec.timeout: 750 >> debug.acpi.ec.polled: 0 >> debug.acpi.ec.burst: 0 >> debug.acpi.batt.batt_sleep_ms: 0 >> debug.acpi.resume_beep: 0 >> debug.mddebug: 0 >> debug.gdbcons: 0 >> debug.elf64_legacy_coredump: 0 >> debug.bootverbose: 0 >> debug.boothowto: 0 >> debug.cpufreq.verbose: 0 >> debug.cpufreq.lowest: 0 >> debug.sizeof.cdev_priv: 376 >> debug.sizeof.cdev: 288 >> debug.sizeof.g_bioq: 56 >> debug.sizeof.g_consumer: 96 >> debug.sizeof.g_provider: 136 >> debug.sizeof.g_geom: 136 >> debug.sizeof.g_class: 136 >> debug.sizeof.kinfo_proc: 1088 >> debug.sizeof.buf: 600 >> debug.sizeof.bio: 216 >> debug.sizeof.proc: 1112 >> debug.sizeof.vnode: 472 >> debug.sizeof.devstat: 288 >> debug.sizeof.namecache: 72 >> debug.sizeof.znode: 376 >> debug.osd: 0 >> debug.rwlock.loops: 10000 >> debug.rwlock.retry: 10 >> debug.trace_on_panic: 1 >> debug.debugger_on_panic: 0 >> debug.to_avg_mpcalls: 515 >> debug.to_avg_lockcalls: 1 >> debug.to_avg_gcalls: 255 >> debug.to_avg_depth: 1017 >> debug.umtx.umtx_pi_allocated: 0 >> debug.kdb.stop_cpus: 1 >> debug.kdb.trap_code: 0 >> debug.kdb.trap: 0 >> debug.kdb.panic: 0 >> debug.kdb.enter: 0 >> debug.kdb.current: ddb >> debug.kdb.available: ddb debug.rman_debug: 0 >> debug.ttydebug: 0 >> debug.disablefullpath: 0 >> debug.disablecwd: 0 >> debug.vfscache: 1 >> debug.numcachehv: 2066 >> debug.numcache: 30787 >> debug.numneg: 766 >> debug.ncnegfactor: 16 >> debug.nchash: 131071 >> debug.vnlru_nowhere: 0 >> debug.rush_requests: 0 >> debug.mpsafevfs: 1 >> debug.if_tun_debug: 0 >> debug.nlm_debug: 0 >> debug.crypto_timing: 0 >> debug.collectsnapstats: 0 >> debug.snapdebug: 0 >> debug.dopersistence: 0 >> debug.dir_entry: 0 >> debug.direct_blk_ptrs: 0 >> debug.inode_bitmap: 0 >> debug.indir_blk_ptrs: 0 >> debug.sync_limit_hit: 0 >> debug.ino_limit_hit: 0 >> debug.blk_limit_hit: 0 >> debug.ino_limit_push: 0 >> debug.blk_limit_push: 0 >> debug.worklist_push: 0 >> debug.maxindirdeps: 50 >> debug.tickdelay: 2 >> debug.max_softdeps: 400000 >> debug.dobkgrdwrite: 1 >> debug.bigcgs: 0 >> debug.dircheck: 0 >> debug.minidump: 1 >> debug.psm.pkterrthresh: 2 >> debug.psm.usecs: 500000 >> debug.psm.secs: 0 >> debug.psm.errusecs: 0 >> debug.psm.errsecs: 2 >> debug.psm.hz: 20 >> debug.psm.loglevel: 0 >> debug.fdc.settle: 125 >> debug.fdc.spec2: 16 >> debug.fdc.spec1: 175 >> debug.fdc.retries: 10 >> debug.fdc.debugflags: 0 >> debug.fdc.fifo: 8 >> debug.elf32_legacy_coredump: 0 >> debug.hwpstate_verbose: 0 >> hw.machine: amd64 >> hw.model: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz >> hw.ncpu: 4 >> hw.byteorder: 1234 >> hw.physmem: 17167667200 >> hw.usermem: 3024932864 >> hw.pagesize: 4096 >> hw.floatingpoint: 1 >> hw.machine_arch: amd64 >> hw.realmem: 17985175552 >> hw.ata.setmax: 0 >> hw.ata.wc: 1 >> hw.ata.atapi_dma: 1 >> hw.ata.ata_dma_check_80pin: 1 >> hw.ata.ata_dma: 1 >> hw.pci.honor_msi_blacklist: 1 >> hw.pci.enable_msix: 1 >> hw.pci.enable_msi: 1 >> hw.pci.do_power_resume: 1 >> hw.pci.do_power_nodriver: 0 >> hw.pci.enable_io_modes: 1 >> hw.pci.host_mem_start: 2147483648 >> hw.syscons.kbd_debug: 1 >> hw.syscons.kbd_reboot: 1 >> hw.syscons.bell: 1 >> hw.syscons.saver.keybonly: 1 >> hw.syscons.sc_no_suspend_vtswitch: 0 >> hw.usb2.ehci.no_hs: 0 >> hw.usb2.ehci.debug: 0 >> hw.usb2.uhci.loop: 0 >> hw.usb2.uhci.debug: 0 >> hw.usb2.ctrl.debug: 0 >> hw.usb2.umass.debug: 0 >> hw.usb2.urio.debug: 0 >> hw.usb2.debug: 0 >> hw.usb2.dev.debug: 0 >> hw.usb2.template: 0 >> hw.usb2.ugen.debug: 0 >> hw.usb2.power_timeout: 30 >> hw.usb2.uhub.debug: 0 >> hw.usb2.proc.debug: 0 >> hw.usb2.ss_delay: 0 >> hw.usb2.pr_recovery_delay: 250 >> hw.usb2.pr_poll_delay: 50 >> hw.usb2.ulpt.debug: 0 >> hw.usb2.ucom.debug: 0 >> hw.usb2.uhid.debug: 0 >> hw.usb2.ukbd.debug: 0 >> hw.usb2.ums.debug: 0 >> hw.intr_storm_threshold: 1000 >> hw.availpages: 4191325 >> hw.bus.devctl_disable: 0 >> hw.busdma.total_bpages: 8202 >> hw.busdma.zone0.total_bpages: 8202 >> hw.busdma.zone0.free_bpages: 8202 >> hw.busdma.zone0.reserved_bpages: 0 >> hw.busdma.zone0.active_bpages: 0 >> hw.busdma.zone0.total_bounced: 639896 >> hw.busdma.zone0.total_deferred: 0 >> hw.busdma.zone0.lowaddr: 0xffffffff >> hw.busdma.zone0.alignment: 4096 >> hw.clockrate: 1862 >> hw.via_feature_xcrypt: 0 >> hw.via_feature_rng: 0 >> hw.instruction_sse: 1 >> hw.apic.enable_extint: 0 >> hw.psm.tap_timeout: 125000 >> hw.psm.tap_threshold: 25 >> hw.ipmi.on: 1 >> hw.kbd.keymap_restrict_change: 0 >> hw.mca.count: 0 >> hw.mca.interval: 3600 >> hw.mca.force_scan: 0 >> hw.acpi.supported_sleep_state: S1 S4 S5 >> hw.acpi.power_button_state: S5 >> hw.acpi.sleep_button_state: S1 >> hw.acpi.lid_switch_state: NONE >> hw.acpi.standby_state: S1 >> hw.acpi.suspend_state: NONE >> hw.acpi.sleep_delay: 1 >> hw.acpi.s4bios: 0 >> hw.acpi.verbose: 0 >> hw.acpi.disable_on_reboot: 0 >> hw.acpi.handle_reboot: 1 >> hw.acpi.reset_video: 0 >> hw.acpi.cpu.cx_lowest: C1 >> hw.dri.0.name: radeon 0x2a >> hw.dri.0.vm: slot offset size type flags address >> mtrr >> 0 0x00000000d8200000 0x00010000 REG 0x82 0xffffff00d8200000 no >> >> hw.dri.0.clients: a dev pid uid magic ioctls >> >> hw.dri.0.debug: 0 >> machdep.acpi_timer_freq: 3579545 >> machdep.enable_panic_key: 0 >> machdep.adjkerntz: 18000 >> machdep.wall_cmos_clock: 1 >> machdep.disable_rtc_set: 0 >> machdep.acpi_root: 1007888 >> machdep.disable_mtrrs: 0 >> machdep.idle: acpi >> machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, machdep.hlt_cpus: >> 0 >> machdep.prot_fault_translation: 0 >> machdep.panic_on_nmi: 1 >> machdep.kdb_on_nmi: 1 >> machdep.tsc_freq: 1862013503 >> machdep.i8254_freq: 1193182 >> machdep.hlt_logical_cpus: 0 >> machdep.logical_cpus_mask: 10 >> user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: >> user.bc_base_max: 99 >> user.bc_dim_max: 2048 >> user.bc_scale_max: 99 >> user.bc_string_max: 1000 >> user.coll_weights_max: 0 >> user.expr_nest_max: 32 >> user.line_max: 2048 >> user.re_dup_max: 255 >> user.posix2_version: 199212 >> user.posix2_c_bind: 0 >> user.posix2_c_dev: 0 >> user.posix2_char_term: 0 >> user.posix2_fort_dev: 0 >> user.posix2_fort_run: 0 >> user.posix2_localedef: 0 >> user.posix2_sw_dev: 0 >> user.posix2_upe: 0 >> user.stream_max: 20 >> user.tzname_max: 255 >> p1003_1b.asynchronous_io: 0 >> p1003_1b.mapped_files: 1 >> p1003_1b.memlock: 0 >> p1003_1b.memlock_range: 0 >> p1003_1b.memory_protection: 0 >> p1003_1b.message_passing: 0 >> p1003_1b.prioritized_io: 0 >> p1003_1b.priority_scheduling: 1 >> p1003_1b.realtime_signals: 200112 >> p1003_1b.semaphores: 0 >> p1003_1b.fsync: 0 >> p1003_1b.shared_memory_objects: 1 >> p1003_1b.synchronized_io: 0 >> p1003_1b.timers: 200112 >> p1003_1b.aio_listio_max: -1 >> p1003_1b.aio_max: -1 >> p1003_1b.aio_prio_delta_max: -1 >> p1003_1b.delaytimer_max: 2147483647 >> p1003_1b.mq_open_max: 0 >> p1003_1b.pagesize: 4096 >> p1003_1b.rtsig_max: 62 >> p1003_1b.sem_nsems_max: 0 >> p1003_1b.sem_value_max: 0 >> p1003_1b.sigqueue_max: 128 >> p1003_1b.timer_max: 32 >> security.jail.jailed: 0 >> security.jail.param.host.hostname: 256 >> security.jail.param.securelevel: 0 >> security.jail.param.path: 1024 >> security.jail.param.cpuset: 0 >> security.jail.param.name: 256 >> security.jail.param.jid: 0 >> security.jail.param.linux.oss_version: 0 >> security.jail.param.linux.osrelease: 65 >> security.jail.param.linux.osname: 65 >> security.jail.jail_max_af_ips: 255 >> security.jail.mount_allowed: 0 >> security.jail.chflags_allowed: 0 >> security.jail.allow_raw_sockets: 0 >> security.jail.enforce_statfs: 2 >> security.jail.sysvipc_allowed: 0 >> security.jail.socket_unixiproute_only: 1 >> security.jail.set_hostname_allowed: 1 >> security.bsd.suser_enabled: 1 >> security.bsd.unprivileged_proc_debug: 1 >> security.bsd.conservative_signals: 1 >> security.bsd.see_other_gids: 1 >> security.bsd.see_other_uids: 1 >> security.bsd.unprivileged_read_msgbuf: 1 >> security.bsd.hardlink_check_gid: 0 >> security.bsd.hardlink_check_uid: 0 >> security.bsd.unprivileged_get_quota: 0 >> compat.ia32.maxvmem: 0 >> compat.ia32.maxssiz: 67108864 >> compat.ia32.maxdsiz: 536870912 >> compat.linux.oss_version: 198144 >> compat.linux.osrelease: 2.6.16 >> compat.linux.osname: Linux >> compat.linux32.maxvmem: 0 >> compat.linux32.maxssiz: 67108864 >> compat.linux32.maxdsiz: 536870912 >> dev.nexus.0.%driver: nexus >> dev.nexus.0.%parent: root0 >> dev.ram.0.%desc: System RAM >> dev.ram.0.%driver: ram >> dev.ram.0.%parent: nexus0 >> dev.smbios.0.%desc: System Management BIOS >> dev.smbios.0.%driver: smbios >> dev.smbios.0.%parent: nexus0 >> dev.cryptosoft.0.%desc: software crypto >> dev.cryptosoft.0.%driver: cryptosoft >> dev.cryptosoft.0.%parent: nexus0 >> dev.acpi.0.%desc: SMCI SMCISLP2 >> dev.acpi.0.%driver: acpi >> dev.acpi.0.%parent: nexus0 >> dev.acpi_sysresource.0.%desc: System Resource >> dev.acpi_sysresource.0.%driver: acpi_sysresource >> dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.LPC0.MBRD >> dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=31 >> dev.acpi_sysresource.0.%parent: acpi0 >> dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz >> dev.acpi_timer.0.%driver: acpi_timer >> dev.acpi_timer.0.%location: unknown >> dev.acpi_timer.0.%pnpinfo: unknown >> dev.acpi_timer.0.%parent: acpi0 >> dev.pci_link.0.%desc: ACPI PCI Link LNKA >> dev.pci_link.0.%driver: pci_link >> dev.pci_link.0.%location: handle=\_SB_.PCI0.LPC0.LNKA >> dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 >> dev.pci_link.0.%parent: acpi0 >> dev.pci_link.1.%desc: ACPI PCI Link LNKB >> dev.pci_link.1.%driver: pci_link >> dev.pci_link.1.%location: handle=\_SB_.PCI0.LPC0.LNKB >> dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 >> dev.pci_link.1.%parent: acpi0 >> dev.pci_link.2.%desc: ACPI PCI Link LNKC >> dev.pci_link.2.%driver: pci_link >> dev.pci_link.2.%location: handle=\_SB_.PCI0.LPC0.LNKC >> dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 >> dev.pci_link.2.%parent: acpi0 >> dev.pci_link.3.%desc: ACPI PCI Link LNKD >> dev.pci_link.3.%driver: pci_link >> dev.pci_link.3.%location: handle=\_SB_.PCI0.LPC0.LNKD >> dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 >> dev.pci_link.3.%parent: acpi0 >> dev.pci_link.4.%desc: ACPI PCI Link LNKE >> dev.pci_link.4.%driver: pci_link >> dev.pci_link.4.%location: handle=\_SB_.PCI0.LPC0.LNKE >> dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 >> dev.pci_link.4.%parent: acpi0 >> dev.pci_link.5.%desc: ACPI PCI Link LNKF >> dev.pci_link.5.%driver: pci_link >> dev.pci_link.5.%location: handle=\_SB_.PCI0.LPC0.LNKF >> dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 >> dev.pci_link.5.%parent: acpi0 >> dev.pci_link.6.%desc: ACPI PCI Link LNKG >> dev.pci_link.6.%driver: pci_link >> dev.pci_link.6.%location: handle=\_SB_.PCI0.LPC0.LNKG >> dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 >> dev.pci_link.6.%parent: acpi0 >> dev.pci_link.7.%desc: ACPI PCI Link LNKH >> dev.pci_link.7.%driver: pci_link >> dev.pci_link.7.%location: handle=\_SB_.PCI0.LPC0.LNKH >> dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 >> dev.pci_link.7.%parent: acpi0 >> dev.acpi_hpet.0.%desc: High Precision Event Timer >> dev.acpi_hpet.0.%driver: acpi_hpet >> dev.acpi_hpet.0.%location: unknown >> dev.acpi_hpet.0.%pnpinfo: unknown >> dev.acpi_hpet.0.%parent: acpi0 >> dev.pcib.0.%desc: ACPI Host-PCI bridge >> dev.pcib.0.%driver: pcib >> dev.pcib.0.%location: handle=\_SB_.PCI0 >> dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=0 >> dev.pcib.0.%parent: acpi0 >> dev.pcib.1.%desc: ACPI PCI-PCI bridge >> dev.pcib.1.%driver: pcib >> dev.pcib.1.%location: slot=2 function=0 handle=\_SB_.PCI0.P0P2 >> dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x25f7 subvendor=0x0000 >> subdevice=0x0000 class=0x060400 >> dev.pcib.1.%parent: pci0 >> dev.pcib.1.domain: 0 >> dev.pcib.1.pribus: 0 >> dev.pcib.1.secbus: 1 >> dev.pcib.1.subbus: 7 >> dev.pcib.2.%desc: ACPI PCI-PCI bridge >> dev.pcib.2.%driver: pcib >> dev.pcib.2.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0 >> dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x3500 subvendor=0x15d9 >> subdevice=0x8080 class=0x060400 >> dev.pcib.2.%parent: pci1 >> dev.pcib.2.domain: 0 >> dev.pcib.2.pribus: 1 >> dev.pcib.2.secbus: 2 >> dev.pcib.2.subbus: 6 >> dev.pcib.3.%desc: ACPI PCI-PCI bridge >> dev.pcib.3.%driver: pcib >> dev.pcib.3.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0.BPD0 >> dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x3510 subvendor=0x15d9 >> subdevice=0x8080 class=0x060400 >> dev.pcib.3.%parent: pci2 >> dev.pcib.3.domain: 0 >> dev.pcib.3.pribus: 2 >> dev.pcib.3.secbus: 3 >> dev.pcib.3.subbus: 5 >> dev.pcib.4.%desc: ACPI PCI-PCI bridge >> dev.pcib.4.%driver: pcib >> dev.pcib.4.%location: slot=0 function=0 >> handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH0 >> dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x0329 subvendor=0x0000 >> subdevice=0x0000 class=0x060400 >> dev.pcib.4.%parent: pci3 >> dev.pcib.4.domain: 0 >> dev.pcib.4.pribus: 3 >> dev.pcib.4.secbus: 4 >> dev.pcib.4.subbus: 4 >> dev.pcib.4.wake: 0 >> dev.pcib.5.%desc: ACPI PCI-PCI bridge >> dev.pcib.5.%driver: pcib >> dev.pcib.5.%location: slot=0 function=2 >> handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH1 >> dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x032a subvendor=0x0000 >> subdevice=0x0000 class=0x060400 >> dev.pcib.5.%parent: pci3 >> dev.pcib.5.domain: 0 >> dev.pcib.5.pribus: 3 >> dev.pcib.5.secbus: 5 >> dev.pcib.5.subbus: 5 >> dev.pcib.5.wake: 0 >> dev.pcib.6.%desc: ACPI PCI-PCI bridge >> dev.pcib.6.%driver: pcib >> dev.pcib.6.%location: slot=2 function=0 handle=\_SB_.PCI0.P0P2.BMD0.BPD2 >> dev.pcib.6.%pnpinfo: vendor=0x8086 device=0x3518 subvendor=0x15d9 >> subdevice=0x8080 class=0x060400 >> dev.pcib.6.%parent: pci2 >> dev.pcib.6.domain: 0 >> dev.pcib.6.pribus: 2 >> dev.pcib.6.secbus: 6 >> dev.pcib.6.subbus: 6 >> dev.pcib.6.wake: 0 >> dev.pcib.7.%desc: ACPI PCI-PCI bridge >> dev.pcib.7.%driver: pcib >> dev.pcib.7.%location: slot=0 function=3 handle=\_SB_.PCI0.P0P2.BMF3 >> dev.pcib.7.%pnpinfo: vendor=0x8086 device=0x350c subvendor=0x15d9 >> subdevice=0x8080 class=0x060400 >> dev.pcib.7.%parent: pci1 >> dev.pcib.7.domain: 0 >> dev.pcib.7.pribus: 1 >> dev.pcib.7.secbus: 7 >> dev.pcib.7.subbus: 7 >> dev.pcib.7.wake: 0 >> dev.pcib.8.%desc: ACPI PCI-PCI bridge >> dev.pcib.8.%driver: pcib >> dev.pcib.8.%location: slot=4 function=0 handle=\_SB_.PCI0.P0P4 >> dev.pcib.8.%pnpinfo: vendor=0x8086 device=0x25f8 subvendor=0x0000 >> subdevice=0x0000 class=0x060400 >> dev.pcib.8.%parent: pci0 >> dev.pcib.8.domain: 0 >> dev.pcib.8.pribus: 0 >> dev.pcib.8.secbus: 8 >> dev.pcib.8.subbus: 8 >> dev.pcib.8.wake: 0 >> dev.pcib.9.%desc: ACPI PCI-PCI bridge >> dev.pcib.9.%driver: pcib >> dev.pcib.9.%location: slot=6 function=0 handle=\_SB_.PCI0.P0P6 >> dev.pcib.9.%pnpinfo: vendor=0x8086 device=0x25f9 subvendor=0x0000 >> subdevice=0x0000 class=0x060400 >> dev.pcib.9.%parent: pci0 >> dev.pcib.9.domain: 0 >> dev.pcib.9.pribus: 0 >> dev.pcib.9.secbus: 9 >> dev.pcib.9.subbus: 9 >> dev.pcib.9.wake: 0 >> dev.pcib.10.%desc: ACPI PCI-PCI bridge >> dev.pcib.10.%driver: pcib >> dev.pcib.10.%location: slot=28 function=0 handle=\_SB_.PCI0.PEX0 >> dev.pcib.10.%pnpinfo: vendor=0x8086 device=0x2690 subvendor=0x15d9 >> subdevice=0x8080 class=0x060400 >> dev.pcib.10.%parent: pci0 >> dev.pcib.10.domain: 0 >> dev.pcib.10.pribus: 0 >> dev.pcib.10.secbus: 10 >> dev.pcib.10.subbus: 10 >> dev.pcib.10.wake: 0 >> dev.pcib.11.%desc: ACPI PCI-PCI bridge >> dev.pcib.11.%driver: pcib >> dev.pcib.11.%location: slot=30 function=0 handle=\_SB_.PCI0.PCIB >> dev.pcib.11.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x15d9 >> subdevice=0x8080 class=0x060401 >> dev.pcib.11.%parent: pci0 >> dev.pcib.11.domain: 0 >> dev.pcib.11.pribus: 0 >> dev.pcib.11.secbus: 11 >> dev.pcib.11.subbus: 11 >> dev.pcib.11.wake: 0 >> dev.pci.0.%desc: ACPI PCI bus >> dev.pci.0.%driver: pci >> dev.pci.0.%parent: pcib0 >> dev.pci.1.%desc: ACPI PCI bus >> dev.pci.1.%driver: pci >> dev.pci.1.%parent: pcib1 >> dev.pci.2.%desc: ACPI PCI bus >> dev.pci.2.%driver: pci >> dev.pci.2.%parent: pcib2 >> dev.pci.3.%desc: ACPI PCI bus >> dev.pci.3.%driver: pci >> dev.pci.3.%parent: pcib3 >> dev.pci.4.%desc: ACPI PCI bus >> dev.pci.4.%driver: pci >> dev.pci.4.%parent: pcib4 >> dev.pci.4.wake: 0 >> dev.pci.5.%desc: ACPI PCI bus >> dev.pci.5.%driver: pci >> dev.pci.5.%parent: pcib5 >> dev.pci.5.wake: 0 >> dev.pci.6.%desc: ACPI PCI bus >> dev.pci.6.%driver: pci >> dev.pci.6.%parent: pcib6 >> dev.pci.6.wake: 0 >> dev.pci.7.%desc: ACPI PCI bus >> dev.pci.7.%driver: pci >> dev.pci.7.%parent: pcib7 >> dev.pci.7.wake: 0 >> dev.pci.8.%desc: ACPI PCI bus >> dev.pci.8.%driver: pci >> dev.pci.8.%parent: pcib8 >> dev.pci.8.wake: 0 >> dev.pci.9.%desc: ACPI PCI bus >> dev.pci.9.%driver: pci >> dev.pci.9.%parent: pcib9 >> dev.pci.9.wake: 0 >> dev.pci.10.%desc: ACPI PCI bus >> dev.pci.10.%driver: pci >> dev.pci.10.%parent: pcib10 >> dev.pci.10.wake: 0 >> dev.pci.11.%desc: ACPI PCI bus >> dev.pci.11.%driver: pci >> dev.pci.11.%parent: pcib11 >> dev.pci.11.wake: 0 >> dev.hostb.0.%desc: Host to PCI bridge >> dev.hostb.0.%driver: hostb >> dev.hostb.0.%location: slot=0 function=0 >> dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x25d8 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.0.%parent: pci0 >> dev.hostb.1.%desc: Host to PCI bridge >> dev.hostb.1.%driver: hostb >> dev.hostb.1.%location: slot=16 function=0 >> dev.hostb.1.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.1.%parent: pci0 >> dev.hostb.2.%desc: Host to PCI bridge >> dev.hostb.2.%driver: hostb >> dev.hostb.2.%location: slot=16 function=1 >> dev.hostb.2.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.2.%parent: pci0 >> dev.hostb.3.%desc: Host to PCI bridge >> dev.hostb.3.%driver: hostb >> dev.hostb.3.%location: slot=16 function=2 >> dev.hostb.3.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.3.%parent: pci0 >> dev.hostb.4.%desc: Host to PCI bridge >> dev.hostb.4.%driver: hostb >> dev.hostb.4.%location: slot=17 function=0 >> dev.hostb.4.%pnpinfo: vendor=0x8086 device=0x25f1 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.4.%parent: pci0 >> dev.hostb.5.%desc: Host to PCI bridge >> dev.hostb.5.%driver: hostb >> dev.hostb.5.%location: slot=19 function=0 >> dev.hostb.5.%pnpinfo: vendor=0x8086 device=0x25f3 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.5.%parent: pci0 >> dev.hostb.6.%desc: Host to PCI bridge >> dev.hostb.6.%driver: hostb >> dev.hostb.6.%location: slot=21 function=0 >> dev.hostb.6.%pnpinfo: vendor=0x8086 device=0x25f5 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.6.%parent: pci0 >> dev.hostb.7.%desc: Host to PCI bridge >> dev.hostb.7.%driver: hostb >> dev.hostb.7.%location: slot=22 function=0 >> dev.hostb.7.%pnpinfo: vendor=0x8086 device=0x25f6 subvendor=0x15d9 >> subdevice=0x8080 class=0x060000 >> dev.hostb.7.%parent: pci0 >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=0 function=0 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >> subdevice=0x0000 class=0x020000 >> dev.em.0.%parent: pci6 >> dev.em.0.debug: -1 >> dev.em.0.stats: -1 >> dev.em.0.rx_int_delay: 0 >> dev.em.0.tx_int_delay: 66 >> dev.em.0.rx_abs_int_delay: 66 >> dev.em.0.tx_abs_int_delay: 66 >> dev.em.0.rx_processing_limit: 100 >> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >> dev.em.1.%driver: em >> dev.em.1.%location: slot=0 function=1 >> dev.em.1.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >> subdevice=0x0000 class=0x020000 >> dev.em.1.%parent: pci6 >> dev.em.1.debug: -1 >> dev.em.1.stats: -1 >> dev.em.1.rx_int_delay: 0 >> dev.em.1.tx_int_delay: 66 >> dev.em.1.rx_abs_int_delay: 66 >> dev.em.1.tx_abs_int_delay: 66 >> dev.em.1.rx_processing_limit: 100 >> dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >> dev.uhci.0.%driver: uhci >> dev.uhci.0.%location: slot=29 function=0 handle=\_SB_.PCI0.USB1 >> dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2688 subvendor=0x15d9 >> subdevice=0x8080 class=0x0c0300 >> dev.uhci.0.%parent: pci0 >> dev.uhci.0.wake: 0 >> dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >> dev.uhci.1.%driver: uhci >> dev.uhci.1.%location: slot=29 function=1 handle=\_SB_.PCI0.USB2 >> dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2689 subvendor=0x15d9 >> subdevice=0x8080 class=0x0c0300 >> dev.uhci.1.%parent: pci0 >> dev.uhci.1.wake: 0 >> dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >> dev.uhci.2.%driver: uhci >> dev.uhci.2.%location: slot=29 function=2 handle=\_SB_.PCI0.USB3 >> dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x268a subvendor=0x15d9 >> subdevice=0x8080 class=0x0c0300 >> dev.uhci.2.%parent: pci0 >> dev.uhci.2.wake: 0 >> dev.usbus.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >> dev.usbus.0.%driver: usbus >> dev.usbus.0.%parent: uhci0 >> dev.usbus.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >> dev.usbus.1.%driver: usbus >> dev.usbus.1.%parent: uhci1 >> dev.usbus.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >> dev.usbus.2.%driver: usbus >> dev.usbus.2.%parent: uhci2 >> dev.usbus.3.%desc: Intel 63XXESB USB 2.0 controller >> dev.usbus.3.%driver: usbus >> dev.usbus.3.%parent: ehci0 >> dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller >> dev.ehci.0.%driver: ehci >> dev.ehci.0.%location: slot=29 function=7 handle=\_SB_.PCI0.EUSB >> dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x268c subvendor=0x15d9 >> subdevice=0x8080 class=0x0c0320 >> dev.ehci.0.%parent: pci0 >> dev.ehci.0.wake: 0 >> dev.vgapci.0.%desc: VGA-compatible display >> dev.vgapci.0.%driver: vgapci >> dev.vgapci.0.%location: slot=1 function=0 >> dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x515e subvendor=0x15d9 >> subdevice=0x8080 class=0x030000 >> dev.vgapci.0.%parent: pci11 >> dev.drm.0.%desc: ATI ES1000 RN50 >> dev.drm.0.%driver: drm >> dev.drm.0.%parent: vgapci0 >> dev.isab.0.%desc: PCI-ISA bridge >> dev.isab.0.%driver: isab >> dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.LPC0 >> dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2670 subvendor=0x15d9 >> subdevice=0x8080 class=0x060100 >> dev.isab.0.%parent: pci0 >> dev.isa.0.%desc: ISA bus >> dev.isa.0.%driver: isa >> dev.isa.0.%parent: isab0 >> dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller >> dev.atapci.0.%driver: atapci >> dev.atapci.0.%location: slot=31 function=1 handle=\_SB_.PCI0.IDEC >> dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x269e subvendor=0x15d9 >> subdevice=0x8080 class=0x01018a >> dev.atapci.0.%parent: pci0 >> dev.atapci.1.%desc: Intel 63XXESB2 SATA300 controller >> dev.atapci.1.%driver: atapci >> dev.atapci.1.%location: slot=31 function=2 >> dev.atapci.1.%pnpinfo: vendor=0x8086 device=0x2681 subvendor=0x15d9 >> subdevice=0x8080 class=0x010601 >> dev.atapci.1.%parent: pci0 >> dev.ata.0.%desc: ATA channel 0 >> dev.ata.0.%driver: ata >> dev.ata.0.%parent: atapci0 >> dev.ata.2.%desc: ATA channel 0 >> dev.ata.2.%driver: ata >> dev.ata.2.%parent: atapci1 >> dev.ata.3.%desc: ATA channel 1 >> dev.ata.3.%driver: ata >> dev.ata.3.%parent: atapci1 >> dev.ata.4.%desc: ATA channel 2 >> dev.ata.4.%driver: ata >> dev.ata.4.%parent: atapci1 >> dev.ata.5.%desc: ATA channel 3 >> dev.ata.5.%driver: ata >> dev.ata.5.%parent: atapci1 >> dev.ata.6.%desc: ATA channel 4 >> dev.ata.6.%driver: ata >> dev.ata.6.%parent: atapci1 >> dev.ata.7.%desc: ATA channel 5 >> dev.ata.7.%driver: ata >> dev.ata.7.%parent: atapci1 >> dev.ichsmb.0.%desc: Intel 631xESB/6321ESB (ESB2) SMBus controller >> dev.ichsmb.0.%driver: ichsmb >> dev.ichsmb.0.%location: slot=31 function=3 handle=\_SB_.PCI0.SMBS >> dev.ichsmb.0.%pnpinfo: vendor=0x8086 device=0x269b subvendor=0x15d9 >> subdevice=0x8080 class=0x0c0500 >> dev.ichsmb.0.%parent: pci0 >> dev.smbus.0.%desc: System Management Bus >> dev.smbus.0.%driver: smbus >> dev.smbus.0.%parent: ichsmb0 >> dev.smb.0.%desc: SMBus generic I/O >> dev.smb.0.%driver: smb >> dev.smb.0.%parent: smbus0 >> dev.acpi_button.0.%desc: Power Button >> dev.acpi_button.0.%driver: acpi_button >> dev.acpi_button.0.%location: handle=\_SB_.PCI0.PWRB >> dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 >> dev.acpi_button.0.%parent: acpi0 >> dev.atdma.0.%desc: AT DMA controller >> dev.atdma.0.%driver: atdma >> dev.atdma.0.%location: handle=\_SB_.PCI0.LPC0.DMAC >> dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 >> dev.atdma.0.%parent: acpi0 >> dev.fpupnp.0.%desc: Legacy ISA coprocessor support >> dev.fpupnp.0.%driver: fpupnp >> dev.fpupnp.0.%location: handle=\_SB_.PCI0.LPC0.MATH >> dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 >> dev.fpupnp.0.%parent: acpi0 >> dev.atrtc.0.%desc: AT realtime clock >> dev.atrtc.0.%driver: atrtc >> dev.atrtc.0.%location: handle=\_SB_.PCI0.LPC0.RTC_ >> dev.atrtc.0.%pnpinfo: _HID=PNP0B00 _UID=0 >> dev.atrtc.0.%parent: acpi0 >> dev.attimer.0.%desc: AT timer >> dev.attimer.0.%driver: attimer >> dev.attimer.0.%location: handle=\_SB_.PCI0.LPC0.TIME >> dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 >> dev.attimer.0.%parent: acpi0 >> dev.atkbdc.0.%desc: Keyboard controller (i8042) >> dev.atkbdc.0.%driver: atkbdc >> dev.atkbdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.KBC0 >> dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 >> dev.atkbdc.0.%parent: acpi0 >> dev.atkbdc.0.wake: 0 >> dev.atkbd.0.%desc: AT Keyboard >> dev.atkbd.0.%driver: atkbd >> dev.atkbd.0.%parent: atkbdc0 >> dev.psmcpnp.0.%desc: PS/2 mouse port >> dev.psmcpnp.0.%driver: psmcpnp >> dev.psmcpnp.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.MSE0 >> dev.psmcpnp.0.%pnpinfo: _HID=PNP0F13 _UID=0 >> dev.psmcpnp.0.%parent: acpi0 >> dev.psmcpnp.0.wake: 0 >> dev.uart.0.%desc: 16550 or compatible >> dev.uart.0.%driver: uart >> dev.uart.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM1 >> dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 >> dev.uart.0.%parent: acpi0 >> dev.uart.0.wake: 0 >> dev.uart.1.%desc: 16550 or compatible >> dev.uart.1.%driver: uart >> dev.uart.1.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM2 >> dev.uart.1.%pnpinfo: _HID=PNP0501 _UID=2 >> dev.uart.1.%parent: acpi0 >> dev.uart.1.wake: 0 >> dev.fdc.0.%desc: Enhanced floppy controller >> dev.fdc.0.%driver: fdc >> dev.fdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.FDC_ >> dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=1 >> dev.fdc.0.%parent: acpi0 >> dev.fd.0.%desc: 1440-KB 3.5" drive >> dev.fd.0.%driver: fd >> dev.fd.0.%parent: fdc0 >> dev.ppc.0.%desc: Parallel port >> dev.ppc.0.%driver: ppc >> dev.ppc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.PRT_ >> dev.ppc.0.%pnpinfo: _HID=PNP0401 _UID=2 >> dev.ppc.0.%parent: acpi0 >> dev.ppbus.0.%desc: Parallel port bus >> dev.ppbus.0.%driver: ppbus >> dev.ppbus.0.%parent: ppc0 >> dev.lpt.0.%desc: Printer >> dev.lpt.0.%driver: lpt >> dev.lpt.0.%parent: ppbus0 >> dev.ppi.0.%desc: Parallel I/O >> dev.ppi.0.%driver: ppi >> dev.ppi.0.%parent: ppbus0 >> dev.cpu.0.%desc: ACPI CPU >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.CPU0 >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.temperature: 57 >> dev.cpu.0.freq: 1867 >> dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 933/17500 >> 700/13125 466/8750 233/4375 >> dev.cpu.0.cx_supported: C1/1 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_usage: 100.00% last 500us >> dev.cpu.1.%desc: ACPI CPU >> dev.cpu.1.%driver: cpu >> dev.cpu.1.%location: handle=\_PR_.CPU1 >> dev.cpu.1.%pnpinfo: _HID=none _UID=0 >> dev.cpu.1.%parent: acpi0 >> dev.cpu.1.temperature: 59 >> dev.cpu.1.cx_supported: C1/1 >> dev.cpu.1.cx_lowest: C1 >> dev.cpu.1.cx_usage: 100.00% last 500us >> dev.cpu.2.%desc: ACPI CPU >> dev.cpu.2.%driver: cpu >> dev.cpu.2.%location: handle=\_PR_.CPU2 >> dev.cpu.2.%pnpinfo: _HID=none _UID=0 >> dev.cpu.2.%parent: acpi0 >> dev.cpu.2.temperature: 59 >> dev.cpu.2.cx_supported: C1/1 >> dev.cpu.2.cx_lowest: C1 >> dev.cpu.2.cx_usage: 100.00% last 500us >> dev.cpu.3.%desc: ACPI CPU >> dev.cpu.3.%driver: cpu >> dev.cpu.3.%location: handle=\_PR_.CPU3 >> dev.cpu.3.%pnpinfo: _HID=none _UID=0 >> dev.cpu.3.%parent: acpi0 >> dev.cpu.3.temperature: 60 >> dev.cpu.3.cx_supported: C1/1 >> dev.cpu.3.cx_lowest: C1 >> dev.cpu.3.cx_usage: 100.00% last 500us >> dev.acpi_perf.0.%driver: acpi_perf >> dev.acpi_perf.0.%parent: cpu0 >> dev.acpi_perf.1.%driver: acpi_perf >> dev.acpi_perf.1.%parent: cpu1 >> dev.acpi_perf.2.%driver: acpi_perf >> dev.acpi_perf.2.%parent: cpu2 >> dev.acpi_perf.3.%driver: acpi_perf >> dev.acpi_perf.3.%parent: cpu3 >> dev.coretemp.0.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.0.%driver: coretemp >> dev.coretemp.0.%parent: cpu0 >> dev.coretemp.1.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.1.%driver: coretemp >> dev.coretemp.1.%parent: cpu1 >> dev.coretemp.2.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.2.%driver: coretemp >> dev.coretemp.2.%parent: cpu2 >> dev.coretemp.3.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.3.%driver: coretemp >> dev.coretemp.3.%parent: cpu3 >> dev.est.0.%desc: Enhanced SpeedStep Frequency Control >> dev.est.0.%driver: est >> dev.est.0.%parent: cpu0 >> dev.est.0.freq_settings: 1867/35000 >> dev.est.1.%desc: Enhanced SpeedStep Frequency Control >> dev.est.1.%driver: est >> dev.est.1.%parent: cpu1 >> dev.est.1.freq_settings: 1867/35000 >> dev.est.2.%desc: Enhanced SpeedStep Frequency Control >> dev.est.2.%driver: est >> dev.est.2.%parent: cpu2 >> dev.est.2.freq_settings: 1867/35000 >> dev.est.3.%desc: Enhanced SpeedStep Frequency Control >> dev.est.3.%driver: est >> dev.est.3.%parent: cpu3 >> dev.est.3.freq_settings: 1867/35000 >> dev.cpufreq.0.%driver: cpufreq >> dev.cpufreq.0.%parent: cpu0 >> dev.cpufreq.1.%driver: cpufreq >> dev.cpufreq.1.%parent: cpu1 >> dev.cpufreq.2.%driver: cpufreq >> dev.cpufreq.2.%parent: cpu2 >> dev.cpufreq.3.%driver: cpufreq >> dev.cpufreq.3.%parent: cpu3 >> dev.p4tcc.0.%desc: CPU Frequency Thermal Control >> dev.p4tcc.0.%driver: p4tcc >> dev.p4tcc.0.%parent: cpu0 >> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> dev.p4tcc.1.%desc: CPU Frequency Thermal Control >> dev.p4tcc.1.%driver: p4tcc >> dev.p4tcc.1.%parent: cpu1 >> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> dev.p4tcc.2.%desc: CPU Frequency Thermal Control >> dev.p4tcc.2.%driver: p4tcc >> dev.p4tcc.2.%parent: cpu2 >> dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> dev.p4tcc.3.%desc: CPU Frequency Thermal Control >> dev.p4tcc.3.%driver: p4tcc >> dev.p4tcc.3.%parent: cpu3 >> dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> dev.apic.0.%desc: APIC resources >> dev.apic.0.%driver: apic >> dev.apic.0.%parent: nexus0 >> dev.ipmi.0.%desc: IPMI System Interface >> dev.ipmi.0.%driver: ipmi >> dev.ipmi.0.%parent: isa0 >> dev.orm.0.%desc: ISA Option ROM >> dev.orm.0.%driver: orm >> dev.orm.0.%parent: isa0 >> dev.sc.0.%desc: System console >> dev.sc.0.%driver: sc >> dev.sc.0.%parent: isa0 >> dev.vga.0.%desc: Generic ISA VGA >> dev.vga.0.%driver: vga >> dev.vga.0.%parent: isa0 >> dev.acd.0.%desc: Memorex DVD+-RAM 510L v1/MWS7 >> dev.acd.0.%driver: acd >> dev.acd.0.%parent: ata0 >> dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >> dev.uhub.0.%driver: uhub >> dev.uhub.0.%parent: usbus0 >> dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >> dev.uhub.1.%driver: uhub >> dev.uhub.1.%parent: usbus1 >> dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >> dev.uhub.2.%driver: uhub >> dev.uhub.2.%parent: usbus2 >> dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 >> dev.uhub.3.%driver: uhub >> dev.uhub.3.%parent: usbus3 >> dev.atapicam.0.%desc: ATAPI CAM Attachment >> dev.atapicam.0.%driver: atapicam >> dev.atapicam.0.%parent: ata0 >> dev.atapicam.1.%desc: ATAPI CAM Attachment >> dev.atapicam.1.%driver: atapicam >> dev.atapicam.1.%parent: ata2 >> dev.atapicam.2.%desc: ATAPI CAM Attachment >> dev.atapicam.2.%driver: atapicam >> dev.atapicam.2.%parent: ata3 >> dev.atapicam.3.%desc: ATAPI CAM Attachment >> dev.atapicam.3.%driver: atapicam >> dev.atapicam.3.%parent: ata4 >> dev.atapicam.4.%desc: ATAPI CAM Attachment >> dev.atapicam.4.%driver: atapicam >> dev.atapicam.4.%parent: ata5 >> dev.atapicam.5.%desc: ATAPI CAM Attachment >> dev.atapicam.5.%driver: atapicam >> dev.atapicam.5.%parent: ata6 >> dev.atapicam.6.%desc: ATAPI CAM Attachment >> dev.atapicam.6.%driver: atapicam >> dev.atapicam.6.%parent: ata7 >> dev.ad.4.%desc: ST3400620AS/3.AAJ >> dev.ad.4.%driver: ad >> dev.ad.4.%parent: ata2 >> dev.ad.6.%desc: ST3400620AS/3.AAJ >> dev.ad.6.%driver: ad >> dev.ad.6.%parent: ata3 >> dev.ad.8.%desc: ST3500630AS/3.AAE >> dev.ad.8.%driver: ad >> dev.ad.8.%parent: ata4 >> dev.ad.10.%desc: ST3400620AS/3.AAJ >> dev.ad.10.%driver: ad >> dev.ad.10.%parent: ata5 >> dev.ad.12.%desc: ST3400620AS/3.AAJ >> dev.ad.12.%driver: ad >> dev.ad.12.%parent: ata6 >> dev.ad.14.%desc: ST3400620AS/3.AAJ >> dev.ad.14.%driver: ad >> dev.ad.14.%parent: ata7 >> dev.ums.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 >> dev.ums.0.%driver: ums >> dev.ums.0.%location: port=6 interface=0 >> dev.ums.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 >> devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" intclass=0x03 >> intsubclass=0x00 >> dev.ums.0.%parent: uhub3 >> dev.ukbd.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 >> dev.ukbd.0.%driver: ukbd >> dev.ukbd.0.%location: port=6 interface=1 >> dev.ukbd.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 >> devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" intclass=0x03 >> intsubclass=0x01 >> dev.ukbd.0.%parent: uhub3 >> kstat.zfs.misc.arcstats.hits: 1799140 >> kstat.zfs.misc.arcstats.misses: 501784 >> kstat.zfs.misc.arcstats.demand_data_hits: 575806 >> kstat.zfs.misc.arcstats.demand_data_misses: 83877 >> kstat.zfs.misc.arcstats.demand_metadata_hits: 949664 >> kstat.zfs.misc.arcstats.demand_metadata_misses: 71350 >> kstat.zfs.misc.arcstats.prefetch_data_hits: 126189 >> kstat.zfs.misc.arcstats.prefetch_data_misses: 326939 >> kstat.zfs.misc.arcstats.prefetch_metadata_hits: 147481 >> kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19618 >> kstat.zfs.misc.arcstats.mru_hits: 1115709 >> kstat.zfs.misc.arcstats.mru_ghost_hits: 0 >> kstat.zfs.misc.arcstats.mfu_hits: 490457 >> kstat.zfs.misc.arcstats.mfu_ghost_hits: 0 >> kstat.zfs.misc.arcstats.deleted: 9687 >> kstat.zfs.misc.arcstats.recycle_miss: 0 >> kstat.zfs.misc.arcstats.mutex_miss: 0 >> kstat.zfs.misc.arcstats.evict_skip: 0 >> kstat.zfs.misc.arcstats.hash_elements: 546247 >> kstat.zfs.misc.arcstats.hash_elements_max: 549954 >> kstat.zfs.misc.arcstats.hash_collisions: 396590 >> kstat.zfs.misc.arcstats.hash_chains: 160935 >> kstat.zfs.misc.arcstats.hash_chain_max: 12 >> kstat.zfs.misc.arcstats.p: 9317411840 >> kstat.zfs.misc.arcstats.c: 16093925376 >> kstat.zfs.misc.arcstats.c_min: 2011740672 >> kstat.zfs.misc.arcstats.c_max: 16093925376 >> kstat.zfs.misc.arcstats.size: 12788124608 >> kstat.zfs.misc.arcstats.hdr_size: 113621248 >> kstat.zfs.misc.arcstats.l2_hits: 0 >> kstat.zfs.misc.arcstats.l2_misses: 0 >> kstat.zfs.misc.arcstats.l2_feeds: 0 >> kstat.zfs.misc.arcstats.l2_rw_clash: 0 >> kstat.zfs.misc.arcstats.l2_writes_sent: 0 >> kstat.zfs.misc.arcstats.l2_writes_done: 0 >> kstat.zfs.misc.arcstats.l2_writes_error: 0 >> kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 >> kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 >> kstat.zfs.misc.arcstats.l2_evict_reading: 0 >> kstat.zfs.misc.arcstats.l2_free_on_write: 0 >> kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 >> kstat.zfs.misc.arcstats.l2_cksum_bad: 0 >> kstat.zfs.misc.arcstats.l2_io_error: 0 >> kstat.zfs.misc.arcstats.l2_size: 0 >> kstat.zfs.misc.arcstats.l2_hdr_size: 0 >> kstat.zfs.misc.arcstats.memory_throttle_count: 0 >> kstat.zfs.misc.vdev_cache_stats.delegations: 19244 >> kstat.zfs.misc.vdev_cache_stats.hits: 63137 >> kstat.zfs.misc.vdev_cache_stats.misses: 53109 >> >> Ideas? >> >> >>> >>> >>> >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:00:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9BE106566B for ; Tue, 19 May 2009 01:00:09 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6218FC13 for ; Tue, 19 May 2009 01:00:08 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1974944ana.13 for ; Mon, 18 May 2009 18:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=msKbZrUPAK1HUIkXqBKM3ivmvV2ZQAV/nRBXRmEocJg=; b=EGn3iHKjmc9HUG0nTsqVVEUhRzXbJ/8xn0P5741C95S2HrqmOI9WSjDEAuvRupZbo9 /xNO9C8Ch835YhjHB81fGVCpVFN6olPD2ucrq32FaJZtal1muhQhrrKm6i6+aCLEY8U/ IedAEBjfpk/VWlHiZ/ZN80qoEUsFXB1Beee0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TBKMk7gImxXGbJL+OkO1Fin8Uu/Vbz2Oi46Gkh/5o//SK4BVXJMki/RoPb1MBXQjZi DfiYRkihc0gEhu4Q+nPunmIqAmOPHUvlM99pMrXntAVx1dEpIsfW6IG8JsHBeTkNtAvh dES1utzouHvsOpr9x9412e4X7nc5VUSI6KxI8= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.227.18 with SMTP id z18mr9949249ang.49.1242694808144; Mon, 18 May 2009 18:00:08 -0700 (PDT) In-Reply-To: References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> Date: Mon, 18 May 2009 18:00:07 -0700 X-Google-Sender-Auth: 972ec3d68f888a3c Message-ID: <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> From: Kip Macy To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:00:10 -0000 On Mon, May 18, 2009 at 5:06 PM, Larry Rosenman wrote: > On Mon, 18 May 2009, Kip Macy wrote: > >> The ARC cache allocates wired memory. The ARC will grow until there is >> vm pressure. > > My crash this AM was with 4G real, and the ARC seemed to grow and grow, t= hen > we started paging, and then crashed. > > Even with the VM pressure it seemed to grow out of control. > You're running the most recent HEAD? -Kip > Ideas? > > >> >> -Kip >> >> >> On Mon, May 18, 2009 at 4:32 PM, Larry Rosenman wrote: >>> >>> On Mon, 18 May 2009, Larry Rosenman wrote: >>> >>>> On Mon, 18 May 2009, Adam McDougall wrote: >>>> >>>>> I'm not sure if this is related to recent kernel memory code changes >>>>> or what, but it hasn't happened with code from earlier than a couple >>>>> days ago. =A0I had this happen twice, I think the first time was with >>>>> arc max set to 1024M, the second time was when arc max was unset in >>>>> loader.conf and the system had been up a few hours but the arc hadn't >>>>> been squeezed down to a small number yet: >>>>> Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, 3741M >>>>> Free >>>>> >>>>> I've deleted the kernel since then but I did not change my sources, >>>>> I could build a new one and check where the pointers point to I think= ? >>>>> If needed. =A0Or I could reproduce the panic if needed. =A0It doesn't= dump, >>>>> it just gets stuck after printing the panic. >>>> >>>> I wonder if this is the same crash I saw without getting all the info. >>>> >>>> What I saw was the wired memory getting to be most of the memory on th= e >>>> box, and then boom. >>>> >>>> see my post a few above this. >>> >>> Ok, something(tm) is seriously messed up. =A0I was able to get my hands= on >>> 12G >>> more memory, and with that, the backup finishes, but the wired count is >>> insane: >>> >>> >>> last pid: =A01760; =A0load averages: =A05.46, =A07.01, =A06.43 =A0up 0+= 00:37:54 >>> =A018:31:41 >>> 78 processes: =A05 running, 73 sleeping >>> >>> Mem: 440M Active, 4020K Inact, 13G Wired, 524K Cache, 441M Buf, 1970M >>> Free >>> Swap: 4096M Total, 4096M Free >>> >>> >>> =A0PID USERNAME =A0 =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0= TIME =A0 WCPU >>> COMMAND >>> =A01403 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 118M RUN =A0 = =A0 2 =A031:53 100.00% >>> FahCore_7 >>> =A01400 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 117M CPU0 =A0= =A00 =A031:51 100.00% >>> FahCore_7 >>> =A01397 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 =A0 141M =A0 118M CPU3 =A0= =A03 =A031:46 100.00% >>> FahCore_7 >>> =A01235 ler =A0 =A0 =A0 =A0 =A0 1 138 =A0 20 20072K 11404K CPU1 =A0 =A0= 1 =A031:34 100.00% >>> FahCore_7 >>> =A01209 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 118M nanslp= =A00 =A0 0:07 =A00.00% >>> FahCore_78 >>> =A01206 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 117M nanslp= =A00 =A0 0:07 =A00.00% >>> FahCore_78 >>> =A01207 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 =A0 141M =A0 118M nanslp= =A02 =A0 0:06 =A00.00% >>> FahCore_78 >>> =A01098 pgsql =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 62052K 34948K select =A0= 2 =A0 0:02 =A00.00% >>> postgres >>> =A01069 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 19096K =A06172K nanslp= =A00 =A0 0:01 =A00.00% perl >>> =A01202 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nans= lp =A02 =A0 0:00 =A00.00% fah6 >>> =A01203 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nans= lp =A01 =A0 0:00 =A00.00% fah6 >>> =A01204 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 776K nans= lp =A01 =A0 0:00 =A00.00% fah6 >>> =A01205 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 194M =A0 768K nans= lp =A01 =A0 0:00 =A00.00% fah6 >>> =A01095 pgsql =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 62052K =A05664K select = =A00 =A0 0:00 =A00.00% >>> postgres >>> =A01208 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 20 20072K 11404K nanslp =A0= 2 =A0 0:00 =A00.00% >>> FahCore_78 >>> =A01756 ler =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 23900K =A08672K nanslp= =A00 =A0 0:00 =A00.00% >>> alpine >>> =A0988 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 10612K =A02376K select = =A02 =A0 0:00 =A00.00% ntpd >>> =A01182 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 17636K =A07048K nanslp= =A02 =A0 0:00 =A00.00% perl >>> >>> Sysctl -a: >>> >>> kern.ostype: FreeBSD >>> kern.osrelease: 8.0-CURRENT >>> kern.osrevision: 199506 >>> kern.version: FreeBSD 8.0-CURRENT #18: Mon May 18 04:18:03 CDT 2009 >>> =A0 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG >>> >>> kern.maxvnodes: 100000 >>> kern.maxproc: 6164 >>> kern.maxfiles: 12328 >>> kern.argmax: 262144 >>> kern.securelevel: -1 >>> kern.hostname: borg.lerctr.org >>> kern.hostid: 3935026275 >>> kern.clockrate: { hz =3D 1000, tick =3D 1000, profhz =3D 2000, stathz = =3D 133 } >>> kern.posix1version: 200112 >>> kern.ngroups: 16 >>> kern.job_control: 1 >>> kern.saved_ids: 0 >>> kern.boottime: { sec =3D 1242687257, usec =3D 281783 } Mon May 18 17:54= :17 >>> 2009 >>> kern.domainname: kern.osreldate: 800087 >>> kern.bootfile: /boot/kernel/kernel >>> kern.maxfilesperproc: 11095 >>> kern.maxprocperuid: 5547 >>> kern.ipc.maxsockbuf: 262144 >>> kern.ipc.sockbuf_waste_factor: 8 >>> kern.ipc.somaxconn: 128 >>> kern.ipc.max_linkhdr: 16 >>> kern.ipc.max_protohdr: 60 >>> kern.ipc.max_hdr: 76 >>> kern.ipc.max_datalen: 92 >>> kern.ipc.nmbjumbo16: 3200 >>> kern.ipc.nmbjumbo9: 6400 >>> kern.ipc.nmbjumbop: 12800 >>> kern.ipc.nmbclusters: 25600 >>> kern.ipc.piperesizeallowed: 1 >>> kern.ipc.piperesizefail: 0 >>> kern.ipc.pipeallocfail: 0 >>> kern.ipc.pipefragretry: 0 >>> kern.ipc.pipekva: 98304 >>> kern.ipc.maxpipekva: 277905408 >>> kern.ipc.msgseg: 2048 >>> kern.ipc.msgssz: 8 >>> kern.ipc.msgtql: 40 >>> kern.ipc.msgmnb: 2048 >>> kern.ipc.msgmni: 40 >>> kern.ipc.msgmax: 16384 >>> kern.ipc.semaem: 16384 >>> kern.ipc.semvmx: 32767 >>> kern.ipc.semusz: 152 >>> kern.ipc.semume: 10 >>> kern.ipc.semopm: 100 >>> kern.ipc.semmsl: 60 >>> kern.ipc.semmnu: 30 >>> kern.ipc.semmns: 4096 >>> kern.ipc.semmni: 2048 >>> kern.ipc.semmap: 30 >>> kern.ipc.shm_allow_removed: 0 >>> kern.ipc.shm_use_phys: 0 >>> kern.ipc.shmall: 8192000 >>> kern.ipc.shmseg: 128 >>> kern.ipc.shmmni: 192 >>> kern.ipc.shmmin: 1 >>> kern.ipc.shmmax: 819200000 >>> kern.ipc.maxsockets: 25600 >>> kern.ipc.numopensockets: 63 >>> kern.ipc.nsfbufsused: 0 >>> kern.ipc.nsfbufspeak: 0 >>> kern.ipc.nsfbufs: 0 >>> kern.dummy: 0 >>> kern.ps_strings: 140737488355296 >>> kern.usrstack: 140737488355328 >>> kern.logsigexit: 1 >>> kern.iov_max: 1024 >>> kern.hostuuid: 53D19F64-D663-A017-8922-003048339480 >>> kern.cam.cam_srch_hi: 0 >>> kern.cam.scsi_delay: 5000 >>> kern.cam.cd.retry_count: 4 >>> kern.cam.cd.changer.max_busy_seconds: 15 >>> kern.cam.cd.changer.min_busy_seconds: 5 >>> kern.cam.cd.0.minimum_cmd_size: 10 >>> kern.cam.da.da_send_ordered: 1 >>> kern.cam.da.default_timeout: 60 >>> kern.cam.da.retry_count: 4 >>> kern.rndtest.verbose: 1 >>> kern.rndtest.retest: 120 >>> kern.disks: cd0 ad14 ad12 ad10 ad8 ad6 ad4 >>> kern.geom.collectstats: 1 >>> kern.geom.debugflags: 0 >>> kern.geom.label.debug: 0 >>> kern.elf64.fallback_brand: -1 >>> kern.init_shutdown_timeout: 120 >>> kern.init_path: >>> /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall >>> kern.acct_suspended: 0 >>> kern.acct_configured: 0 >>> kern.acct_chkfreq: 15 >>> kern.acct_resume: 4 >>> kern.acct_suspend: 2 >>> kern.cp_times: 3050 257577 31202 420 9098 2948 258837 29420 2264 7280 >>> 2800 >>> 260523 30701 171 6615 2523 263506 27118 122 7538 >>> kern.cp_time: 11321 1040443 118441 2977 30531 >>> kern.constty_wakeups_per_second: 5 >>> kern.consmsgbuf_size: 8192 >>> kern.consmute: 0 >>> kern.console: ttyv0,/ttyv0,uart,gdb, >>> kern.openfiles: 220 >>> kern.kq_calloutmax: 4096 >>> kern.ps_arg_cache_limit: 256 >>> kern.stackprot: 7 >>> kern.randompid: 0 >>> kern.lastpid: 1762 >>> kern.ktrace.request_pool: 100 >>> kern.ktrace.genio_size: 4096 >>> kern.module_path: /boot/kernel;/boot/modules >>> kern.malloc_count: 267 >>> kern.fallback_elf_brand: -1 >>> kern.features.compat_freebsd7: 1 >>> kern.features.compat_freebsd6: 1 >>> kern.features.compat_freebsd5: 1 >>> kern.features.compat_freebsd4: 1 >>> kern.features.posix_shm: 1 >>> kern.maxusers: 384 >>> kern.ident: BORG >>> kern.kstack_pages: 4 >>> kern.shutdown.kproc_shutdown_wait: 60 >>> kern.shutdown.poweroff_delay: 5000 >>> kern.sync_on_panic: 0 >>> kern.corefile: %N.core >>> kern.nodump_coredump: 0 >>> kern.coredump: 1 >>> kern.sugid_coredump: 0 >>> kern.sigqueue.alloc_fail: 0 >>> kern.sigqueue.overflow: 0 >>> kern.sigqueue.preallocate: 1024 >>> kern.sigqueue.max_pending_per_proc: 128 >>> kern.forcesigexit: 1 >>> kern.fscale: 2048 >>> kern.timecounter.tick: 1 >>> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) >>> dummy(-1000000) >>> kern.timecounter.hardware: ACPI-fast >>> kern.timecounter.stepwarnings: 0 >>> kern.timecounter.tc.i8254.mask: 65535 >>> kern.timecounter.tc.i8254.counter: 62178 >>> kern.timecounter.tc.i8254.frequency: 1193182 >>> kern.timecounter.tc.i8254.quality: 0 >>> kern.timecounter.tc.ACPI-fast.mask: 16777215 >>> kern.timecounter.tc.ACPI-fast.counter: 3310006 >>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>> kern.timecounter.tc.ACPI-fast.quality: 1000 >>> kern.timecounter.tc.HPET.mask: 4294967295 >>> kern.timecounter.tc.HPET.counter: 2523974339 >>> kern.timecounter.tc.HPET.frequency: 14318180 >>> kern.timecounter.tc.HPET.quality: 900 >>> kern.timecounter.tc.TSC.mask: 4294967295 >>> kern.timecounter.tc.TSC.counter: 1218885212 >>> kern.timecounter.tc.TSC.frequency: 1862013503 >>> kern.timecounter.tc.TSC.quality: -100 >>> kern.timecounter.smp_tsc: 0 >>> kern.timecounter.invariant_tsc: 1 >>> kern.threads.max_threads_hits: 0 >>> kern.threads.max_threads_per_proc: 1500 >>> kern.ccpu: 0 >>> kern.sched.preemption: 1 >>> kern.sched.topology_spec: >>> =A0 >>> =A00, 1, 2, 3 >>> =A0 >>> =A0 >>> =A0 >>> =A0 0, 1 >>> =A0 >>> =A0 >>> =A0 >>> =A0 2, 3 >>> =A0 >>> =A0 >>> =A0 >>> =A0 >>> >>> >>> kern.sched.steal_thresh: 2 >>> kern.sched.steal_idle: 1 >>> kern.sched.steal_htt: 1 >>> kern.sched.balance_interval: 133 >>> kern.sched.balance: 1 >>> kern.sched.affinity: 1 >>> kern.sched.idlespinthresh: 4 >>> kern.sched.idlespins: 10000 >>> kern.sched.static_boost: 160 >>> kern.sched.preempt_thresh: 64 >>> kern.sched.interact: 30 >>> kern.sched.slice: 13 >>> kern.sched.name: ULE >>> kern.devstat.version: 6 >>> kern.devstat.generation: 225 >>> kern.devstat.numdevs: 9 >>> kern.kobj_methodcount: 155 >>> kern.log_wakeups_per_second: 5 >>> kern.vm_guest: none >>> kern.sgrowsiz: 131072 >>> kern.maxssiz: 536870912 >>> kern.dflssiz: 8388608 >>> kern.maxdsiz: 34359738368 >>> kern.dfldsiz: 134217728 >>> kern.maxtsiz: 134217728 >>> kern.maxbcache: 1073741824 >>> kern.maxswzone: 33554432 >>> kern.nswbuf: 256 >>> kern.nbuf: 65536 >>> kern.ncallout: 18508 >>> kern.hz: 1000 >>> kern.msgbuf_clear: 0 >>> kern.msgbuf: kern.always_console_output: 0 >>> kern.log_console_output: 1 >>> kern.smp.forward_roundrobin_enabled: 1 >>> kern.smp.forward_signal_enabled: 1 >>> kern.smp.topology: 0 >>> kern.smp.cpus: 4 >>> kern.smp.disabled: 0 >>> kern.smp.active: 1 >>> kern.smp.maxcpus: 32 >>> kern.smp.maxid: 3 >>> kern.tty_inq_nslow: 297 >>> kern.tty_inq_nfast: 1701 >>> kern.tty_outq_nslow: 0 >>> kern.tty_outq_nfast: 0 >>> kern.pts_maxdev: 999 >>> kern.tty_pty_warningcnt: 10 >>> kern.tty_nout: 4730961 >>> kern.tty_nin: 2138 >>> kern.minvnodes: 25000 >>> kern.metadelay: 28 >>> kern.dirdelay: 29 >>> kern.filedelay: 30 >>> kern.chroot_allow_open_directories: 1 >>> kern.cryptodevallowsoft: 0 >>> kern.userasymcrypto: 1 >>> kern.rpc.invalid: 0 >>> kern.rpc.unexpected: 0 >>> kern.rpc.timeouts: 0 >>> kern.rpc.request: 0 >>> kern.rpc.retries: 0 >>> kern.elf32.fallback_brand: -1 >>> kern.random.yarrow.gengateinterval: 10 >>> kern.random.yarrow.bins: 10 >>> kern.random.yarrow.fastthresh: 192 >>> kern.random.yarrow.slowthresh: 256 >>> kern.random.yarrow.slowoverthresh: 2 >>> kern.random.sys.seeded: 1 >>> kern.random.sys.harvest.ethernet: 1 >>> kern.random.sys.harvest.point_to_point: 1 >>> kern.random.sys.harvest.interrupt: 1 >>> kern.random.sys.harvest.swi: 0 >>> vm.vmtotal: System wide totals computed every five seconds: (values in >>> kilobytes) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Processes: =A0 =A0 =A0 =A0 =A0 =A0 =A0(RUNQ: 5 Disk Wait: 0 Page Wait: = 0 Sleep: 73) >>> Virtual Memory: =A0 =A0 =A0 =A0 (Total: 1076206992K, Active 2349180K) >>> Real Memory: =A0 =A0 =A0 =A0 =A0 =A0(Total: 1103632K Active 455252K) >>> Shared Virtual Memory: =A0(Total: 20708K Active: 14128K) >>> Shared Real Memory: =A0 =A0 (Total: 9388K Active: 8756K) >>> Free Memory Pages: =A0 =A0 =A02017432K >>> >>> vm.loadavg: { 5.08 6.77 6.36 } >>> vm.v_free_min: 25703 >>> vm.v_free_target: 108162 >>> vm.v_free_reserved: 5350 >>> vm.v_inactive_target: 162243 >>> vm.v_cache_min: 108162 >>> vm.v_cache_max: 216324 >>> vm.v_pageout_free_min: 34 >>> vm.pageout_algorithm: 0 >>> vm.swap_enabled: 1 >>> vm.kmem_size_scale: 3 >>> vm.kmem_size_max: 329853485875 >>> vm.kmem_size_min: 0 >>> vm.kmem_size: 5558173696 >>> vm.nswapdev: 1 >>> vm.dmmax: 32 >>> vm.swap_async_max: 4 >>> vm.zone_count: 98 >>> vm.swap_idle_threshold2: 10 >>> vm.swap_idle_threshold1: 2 >>> vm.exec_map_entries: 16 >>> vm.stats.misc.zero_page_count: 59 >>> vm.stats.misc.cnt_prezero: 0 >>> vm.stats.vm.v_kthreadpages: 0 >>> vm.stats.vm.v_rforkpages: 2236 >>> vm.stats.vm.v_vforkpages: 39693 >>> vm.stats.vm.v_forkpages: 363901 >>> vm.stats.vm.v_kthreads: 141 >>> vm.stats.vm.v_rforks: 28 >>> vm.stats.vm.v_vforks: 198 >>> vm.stats.vm.v_forks: 1395 >>> vm.stats.vm.v_interrupt_free_min: 2 >>> vm.stats.vm.v_pageout_free_min: 34 >>> vm.stats.vm.v_cache_max: 216324 >>> vm.stats.vm.v_cache_min: 108162 >>> vm.stats.vm.v_cache_count: 123 >>> vm.stats.vm.v_inactive_count: 1005 >>> vm.stats.vm.v_inactive_target: 162243 >>> vm.stats.vm.v_active_count: 112687 >>> vm.stats.vm.v_wire_count: 3452797 >>> vm.stats.vm.v_free_count: 504231 >>> vm.stats.vm.v_free_min: 25703 >>> vm.stats.vm.v_free_target: 108162 >>> vm.stats.vm.v_free_reserved: 5350 >>> vm.stats.vm.v_page_count: 4070929 >>> vm.stats.vm.v_page_size: 4096 >>> vm.stats.vm.v_tfree: 19085156 >>> vm.stats.vm.v_pfree: 612782 >>> vm.stats.vm.v_dfree: 0 >>> vm.stats.vm.v_tcached: 3100 >>> vm.stats.vm.v_pdpages: 0 >>> vm.stats.vm.v_pdwakeups: 0 >>> vm.stats.vm.v_reactivated: 2925 >>> vm.stats.vm.v_intrans: 704 >>> vm.stats.vm.v_vnodepgsout: 1 >>> vm.stats.vm.v_vnodepgsin: 6890 >>> vm.stats.vm.v_vnodeout: 1 >>> vm.stats.vm.v_vnodein: 5806 >>> vm.stats.vm.v_swappgsout: 0 >>> vm.stats.vm.v_swappgsin: 0 >>> vm.stats.vm.v_swapout: 0 >>> vm.stats.vm.v_swapin: 0 >>> vm.stats.vm.v_ozfod: 27 >>> vm.stats.vm.v_zfod: 2565409 >>> vm.stats.vm.v_cow_optim: 397 >>> vm.stats.vm.v_cow_faults: 64414 >>> vm.stats.vm.v_vm_faults: 2768133 >>> vm.stats.sys.v_soft: 1359531 >>> vm.stats.sys.v_intr: 715196 >>> vm.stats.sys.v_syscall: 6458471 >>> vm.stats.sys.v_trap: 6074556 >>> vm.stats.sys.v_swtch: 8393310 >>> vm.stats.object.bypasses: 757 >>> vm.stats.object.collapses: 5656 >>> vm.v_free_severe: 15526 >>> vm.max_proc_mmap: 496265 >>> vm.old_msync: 0 >>> vm.msync_flush_flags: 3 >>> vm.boot_pages: 48 >>> vm.max_wired: 1345352 >>> vm.pageout_lock_miss: 0 >>> vm.disable_swapspace_pageouts: 0 >>> vm.defer_swapspace_pageouts: 0 >>> vm.swap_idle_enabled: 0 >>> vm.pageout_stats_interval: 5 >>> vm.pageout_full_stats_interval: 20 >>> vm.pageout_stats_max: 108162 >>> vm.max_launder: 32 >>> vm.phys_segs: SEGMENT 0: >>> >>> start: =A0 =A0 0x1000 >>> end: =A0 =A0 =A0 0x98000 >>> free list: 0xffffffff80849668 >>> >>> SEGMENT 1: >>> >>> start: =A0 =A0 0xb8a000 >>> end: =A0 =A0 =A0 0x1000000 >>> free list: 0xffffffff80849668 >>> >>> SEGMENT 2: >>> >>> start: =A0 =A0 0x1000000 >>> end: =A0 =A0 =A0 0xcff50000 >>> free list: 0xffffffff808492c0 >>> >>> SEGMENT 3: >>> >>> start: =A0 =A0 0x100000000 >>> end: =A0 =A0 =A0 0x4129b4000 >>> free list: 0xffffffff808492c0 >>> >>> vm.phys_free: FREE LIST 0: >>> >>> =A0ORDER (SIZE) =A0| =A0NUMBER >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0POOL 0 =A0| =A0POOL 1 =A0| =A0POOL 2 >>> -- =A0 =A0 =A0 =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 = =A0 =A0-- >>> =A012 ( 16384K) =A0| =A0 =A0 =A091 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 >>> =A011 ( =A08192K) =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 = =A0 0 >>> =A010 ( =A04096K) =A0| =A0 =A0 =A0 7 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 = =A0 0 >>> =A09 ( =A02048K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0= 0 >>> =A08 ( =A01024K) =A0| =A0 =A0 =A0 4 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0= 0 >>> =A07 ( =A0 512K) =A0| =A0 =A0 =A010 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A06 ( =A0 256K) =A0| =A0 =A0 =A0 7 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A05 ( =A0 128K) =A0| =A0 =A0 =A011 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A04 ( =A0 =A064K) =A0| =A0 =A0 =A032 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A03 ( =A0 =A032K) =A0| =A0 =A0 246 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A02 ( =A0 =A016K) =A0| =A0 =A0 929 =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0= 1 >>> =A01 ( =A0 =A0 8K) =A0| =A0 =A01849 =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0= 7 >>> =A00 ( =A0 =A0 4K) =A0| =A0 =A09492 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 73 >>> >>> FREE LIST 1: >>> >>> =A0ORDER (SIZE) =A0| =A0NUMBER >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0POOL 0 =A0| =A0POOL 1 =A0| =A0POOL 2 >>> -- =A0 =A0 =A0 =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 =A0 =A0-- -- =A0 = =A0 =A0-- >>> =A012 ( 16384K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 = 0 >>> =A011 ( =A08192K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A010 ( =A04096K) =A0| =A0 =A0 =A0 1 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A09 ( =A02048K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A08 ( =A01024K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A07 ( =A0 512K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A06 ( =A0 256K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A05 ( =A0 128K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0= 0 >>> =A04 ( =A0 =A064K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A03 ( =A0 =A032K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A02 ( =A0 =A016K) =A0| =A0 =A0 =A0 2 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A01 ( =A0 =A0 8K) =A0| =A0 =A0 =A0 3 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> =A00 ( =A0 =A0 4K) =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 =A0 0 =A0| =A0 =A0 = =A0 0 >>> >>> vm.reserv.reclaimed: 0 >>> vm.reserv.partpopq: LEVEL =A0 =A0 SIZE =A0NUMBER >>> >>> =A0-1: 362368K, =A0 =A0326 >>> >>> vm.reserv.freed: 11598 >>> vm.reserv.broken: 8 >>> vm.idlezero_enable: 0 >>> vm.kvm_free: 542615007232 >>> vm.kvm_size: 549755809792 >>> vm.pmap.pmap_collect_active: 0 >>> vm.pmap.pmap_collect_inactive: 0 >>> vm.pmap.pv_entry_spare: 8566 >>> vm.pmap.pv_entry_allocs: 3744878 >>> vm.pmap.pv_entry_frees: 3679188 >>> vm.pmap.pc_chunk_tryfail: 0 >>> vm.pmap.pc_chunk_frees: 13290 >>> vm.pmap.pc_chunk_allocs: 13732 >>> vm.pmap.pc_chunk_count: 442 >>> vm.pmap.pv_entry_count: 65690 >>> vm.pmap.pdpe.demotions: 0 >>> vm.pmap.pde.promotions: 110851 >>> vm.pmap.pde.p_failures: 1022233 >>> vm.pmap.pde.mappings: 0 >>> vm.pmap.pde.demotions: 107618 >>> vm.pmap.shpgperproc: 200 >>> vm.pmap.pv_entry_max: 5303729 >>> vm.pmap.pg_ps_enabled: 1 >>> vfs.zfs.arc_meta_limit: 4023481344 >>> vfs.zfs.arc_meta_used: 1192541184 >>> vfs.zfs.mdcomp_disable: 0 >>> vfs.zfs.arc_min: 2011740672 >>> vfs.zfs.arc_max: 16093925376 >>> vfs.zfs.zfetch.array_rd_sz: 1048576 >>> vfs.zfs.zfetch.block_cap: 256 >>> vfs.zfs.zfetch.min_sec_reap: 2 >>> vfs.zfs.zfetch.max_streams: 8 >>> vfs.zfs.prefetch_disable: 0 >>> vfs.zfs.recover: 0 >>> vfs.zfs.txg.synctime: 5 >>> vfs.zfs.txg.timeout: 30 >>> vfs.zfs.scrub_limit: 10 >>> vfs.zfs.vdev.cache.bshift: 16 >>> vfs.zfs.vdev.cache.size: 10485760 >>> vfs.zfs.vdev.cache.max: 16384 >>> vfs.zfs.vdev.aggregation_limit: 131072 >>> vfs.zfs.vdev.ramp_rate: 2 >>> vfs.zfs.vdev.time_shift: 6 >>> vfs.zfs.vdev.min_pending: 4 >>> vfs.zfs.vdev.max_pending: 35 >>> vfs.zfs.cache_flush_disable: 0 >>> vfs.zfs.zil_disable: 0 >>> vfs.zfs.version.zpl: 3 >>> vfs.zfs.version.vdev_boot: 1 >>> vfs.zfs.version.spa: 13 >>> vfs.zfs.version.dmu_backup_stream: 1 >>> vfs.zfs.version.dmu_backup_header: 2 >>> vfs.zfs.version.acl: 1 >>> vfs.zfs.debug: 0 >>> vfs.zfs.super_owner: 1 >>> vfs.ufs.dirhash_docheck: 0 >>> vfs.ufs.dirhash_mem: 39648 >>> vfs.ufs.dirhash_maxmem: 2097152 >>> vfs.ufs.dirhash_minsize: 2560 >>> vfs.devfs.rule_depth: 1 >>> vfs.devfs.generation: 139 >>> vfs.nfs4.access_cache_timeout: 60 >>> vfs.nfs.downdelayinitial: 12 >>> vfs.nfs.downdelayinterval: 30 >>> vfs.nfs.skip_wcc_data_onerr: 1 >>> vfs.nfs.nfs3_jukebox_delay: 10 >>> vfs.nfs.reconnects: 0 >>> vfs.nfs.bufpackets: 4 >>> vfs.nfs.realign_count: 0 >>> vfs.nfs.realign_test: 0 >>> vfs.nfs.defect: 0 >>> vfs.nfs.iodmax: 20 >>> vfs.nfs.iodmin: 0 >>> vfs.nfs.iodmaxidle: 120 >>> vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 >>> vfs.nfs.nfs_ip_paranoia: 1 >>> vfs.nfs.nfs_directio_allow_mmap: 1 >>> vfs.nfs.nfs_directio_enable: 0 >>> vfs.nfs.clean_pages_on_close: 1 >>> vfs.nfs.nfsv3_commit_on_close: 0 >>> vfs.nfs.prime_access_cache: 0 >>> vfs.nfs.access_cache_timeout: 60 >>> vfs.pfs.trace: 0 >>> vfs.pfs.vncache.misses: 0 >>> vfs.pfs.vncache.hits: 0 >>> vfs.pfs.vncache.maxentries: 0 >>> vfs.pfs.vncache.entries: 0 >>> vfs.flushwithdeps: 0 >>> vfs.notbufdflashes: 0 >>> vfs.flushbufqtarget: 100 >>> vfs.getnewbufrestarts: 0 >>> vfs.getnewbufcalls: 28204 >>> vfs.hifreebuffers: 7290 >>> vfs.lofreebuffers: 3645 >>> vfs.numfreebuffers: 65534 >>> vfs.dirtybufthresh: 14763 >>> vfs.hidirtybuffers: 16404 >>> vfs.lodirtybuffers: 8202 >>> vfs.numdirtybuffers: 2 >>> vfs.recursiveflushes: 0 >>> vfs.altbufferflushes: 0 >>> vfs.bdwriteskip: 0 >>> vfs.dirtybufferflushes: 0 >>> vfs.hirunningspace: 1048576 >>> vfs.lorunningspace: 524288 >>> vfs.bufdefragcnt: 0 >>> vfs.buffreekvacnt: 0 >>> vfs.bufreusecnt: 28198 >>> vfs.hibufspace: 1073086464 >>> vfs.lobufspace: 1073020928 >>> vfs.maxmallocbufspace: 53654323 >>> vfs.bufmallocspace: 0 >>> vfs.maxbufspace: 1073741824 >>> vfs.bufspace: 461996032 >>> vfs.runningbufspace: 0 >>> vfs.vmiodirenable: 1 >>> vfs.cache.numfullpathfound: 124 >>> vfs.cache.numfullpathfail4: 0 >>> vfs.cache.numfullpathfail2: 0 >>> vfs.cache.numfullpathfail1: 0 >>> vfs.cache.numfullpathcalls: 124 >>> vfs.cache.nchstats: 4488983 27354 228 0 466972 0 33 156 >>> vfs.cache.numupgrades: 28 >>> vfs.cache.numneghits: 27354 >>> vfs.cache.numnegzaps: 57 >>> vfs.cache.numposhits: 4488983 >>> vfs.cache.numposzaps: 171 >>> vfs.cache.nummisszap: 309 >>> vfs.cache.nummiss: 466663 >>> vfs.cache.numchecks: 5829112 >>> vfs.cache.dotdothits: 47 >>> vfs.cache.dothits: 1035 >>> vfs.cache.numcalls: 4984636 >>> vfs.cache.numcache: 30787 >>> vfs.cache.numneg: 766 >>> vfs.read_max: 8 >>> vfs.write_behind: 1 >>> vfs.lookup_shared: 1 >>> vfs.usermount: 1 >>> vfs.worklist_len: 1 >>> vfs.timestamp_precision: 0 >>> vfs.reassignbufcalls: 611 >>> vfs.freevnodes: 24986 >>> vfs.wantfreevnodes: 25000 >>> vfs.numvnodes: 29998 >>> vfs.nfsrv.nfs_privport: 0 >>> vfs.nfsrv.fha.bin_shift: 18 >>> vfs.nfsrv.fha.max_nfsds_per_fh: 8 >>> vfs.nfsrv.fha.max_reqs_per_nfsd: 4 >>> vfs.nfsrv.fha.fhe_stats: No file handle entries. >>> vfs.nfsrv.commit_miss: 0 >>> vfs.nfsrv.commit_blks: 0 >>> vfs.nfsrv.async: 0 >>> vfs.nfsrv.realign_count: 0 >>> vfs.nfsrv.realign_test: 0 >>> vfs.nfsrv.gatherdelay_v3: 0 >>> vfs.nfsrv.gatherdelay: 10000 >>> vfs.nfsrv.minthreads: 4 >>> vfs.nfsrv.maxthreads: 4 >>> vfs.nfsrv.threads: 4 >>> vfs.nfsrv.request_space_used: 0 >>> vfs.nfsrv.request_space_used_highest: 0 >>> vfs.nfsrv.request_space_high: 13107200 >>> vfs.nfsrv.request_space_low: 8738133 >>> vfs.nfsrv.request_space_throttled: 0 >>> vfs.nfsrv.request_space_throttle_count: 0 >>> vfs.ffs.doreallocblks: 1 >>> vfs.ffs.doasyncfree: 1 >>> vfs.ffs.compute_summary_at_mount: 0 >>> net.local.stream.recvspace: 8192 >>> net.local.stream.sendspace: 8192 >>> net.local.dgram.recvspace: 4096 >>> net.local.dgram.maxdgram: 2048 >>> net.local.taskcount: 0 >>> net.local.recycled: 0 >>> net.local.inflight: 0 >>> net.inet.ip.portrange.randomtime: 45 >>> net.inet.ip.portrange.randomcps: 10 >>> net.inet.ip.portrange.randomized: 1 >>> net.inet.ip.portrange.reservedlow: 0 >>> net.inet.ip.portrange.reservedhigh: 1023 >>> net.inet.ip.portrange.hilast: 65535 >>> net.inet.ip.portrange.hifirst: 49152 >>> net.inet.ip.portrange.last: 65535 >>> net.inet.ip.portrange.first: 10000 >>> net.inet.ip.portrange.lowlast: 600 >>> net.inet.ip.portrange.lowfirst: 1023 >>> net.inet.ip.forwarding: 0 >>> net.inet.ip.redirect: 1 >>> net.inet.ip.ttl: 64 >>> net.inet.ip.rtexpire: 3600 >>> net.inet.ip.rtminexpire: 10 >>> net.inet.ip.rtmaxcache: 128 >>> net.inet.ip.sourceroute: 0 >>> net.inet.ip.intr_queue_maxlen: 50 >>> net.inet.ip.intr_queue_drops: 0 >>> net.inet.ip.accept_sourceroute: 0 >>> net.inet.ip.keepfaith: 0 >>> net.inet.ip.gifttl: 30 >>> net.inet.ip.same_prefix_carp_only: 0 >>> net.inet.ip.subnets_are_local: 0 >>> net.inet.ip.random_id_total: 0 >>> net.inet.ip.random_id_collisions: 0 >>> net.inet.ip.random_id_period: 8192 >>> net.inet.ip.mcast.loop: 1 >>> net.inet.ip.mcast.maxsocksrc: 128 >>> net.inet.ip.mcast.maxgrpsrc: 512 >>> net.inet.ip.fastforwarding: 0 >>> net.inet.ip.maxfragpackets: 800 >>> net.inet.ip.output_flowtable_size: 0 >>> net.inet.ip.maxfragsperpacket: 16 >>> net.inet.ip.fragpackets: 0 >>> net.inet.ip.check_interface: 0 >>> net.inet.ip.random_id: 0 >>> net.inet.ip.sendsourcequench: 0 >>> net.inet.ip.process_options: 1 >>> net.inet.icmp.maskrepl: 0 >>> net.inet.icmp.icmplim: 200 >>> net.inet.icmp.bmcastecho: 0 >>> net.inet.icmp.quotelen: 8 >>> net.inet.icmp.reply_from_interface: 0 >>> net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 >>> net.inet.icmp.log_redirect: 0 >>> net.inet.icmp.drop_redirect: 0 >>> net.inet.icmp.maskfake: 0 >>> net.inet.igmp.gsrdelay: 10 >>> net.inet.igmp.default_version: 3 >>> net.inet.igmp.legacysupp: 0 >>> net.inet.igmp.v2enable: 1 >>> net.inet.igmp.v1enable: 1 >>> net.inet.igmp.sendlocal: 1 >>> net.inet.igmp.sendra: 1 >>> net.inet.igmp.recvifkludge: 1 >>> net.inet.tcp.rfc1323: 1 >>> net.inet.tcp.mssdflt: 512 >>> net.inet.tcp.keepidle: 7200000 >>> net.inet.tcp.keepintvl: 75000 >>> net.inet.tcp.sendspace: 32768 >>> net.inet.tcp.recvspace: 65536 >>> net.inet.tcp.keepinit: 75000 >>> net.inet.tcp.delacktime: 100 >>> net.inet.tcp.v6mssdflt: 1024 >>> net.inet.tcp.hostcache.purge: 0 >>> net.inet.tcp.hostcache.prune: 300 >>> net.inet.tcp.hostcache.expire: 3600 >>> net.inet.tcp.hostcache.count: 3 >>> net.inet.tcp.hostcache.bucketlimit: 30 >>> net.inet.tcp.hostcache.hashsize: 512 >>> net.inet.tcp.hostcache.cachelimit: 15360 >>> net.inet.tcp.wlock_looped: 0 >>> net.inet.tcp.wlock_relocked: 0 >>> net.inet.tcp.wlock_upgraded: 262 >>> net.inet.tcp.tcp_wlock_atfirst: 416 >>> net.inet.tcp.rlock_atfirst: 829900 >>> net.inet.tcp.read_locking: 1 >>> net.inet.tcp.recvbuf_max: 262144 >>> net.inet.tcp.recvbuf_inc: 16384 >>> net.inet.tcp.recvbuf_auto: 1 >>> net.inet.tcp.insecure_rst: 0 >>> net.inet.tcp.ecn.maxretries: 1 >>> net.inet.tcp.ecn.enable: 0 >>> net.inet.tcp.abc_l_var: 2 >>> net.inet.tcp.rfc3465: 1 >>> net.inet.tcp.rfc3390: 1 >>> net.inet.tcp.rfc3042: 1 >>> net.inet.tcp.drop_synfin: 0 >>> net.inet.tcp.delayed_ack: 1 >>> net.inet.tcp.blackhole: 0 >>> net.inet.tcp.log_in_vain: 0 >>> net.inet.tcp.sendbuf_max: 262144 >>> net.inet.tcp.sendbuf_inc: 8192 >>> net.inet.tcp.sendbuf_auto: 1 >>> net.inet.tcp.tso: 1 >>> net.inet.tcp.newreno: 1 >>> net.inet.tcp.local_slowstart_flightsize: 4 >>> net.inet.tcp.slowstart_flightsize: 1 >>> net.inet.tcp.path_mtu_discovery: 1 >>> net.inet.tcp.reass.overflows: 0 >>> net.inet.tcp.reass.maxqlen: 48 >>> net.inet.tcp.reass.cursegments: 0 >>> net.inet.tcp.reass.maxsegments: 1600 >>> net.inet.tcp.sack.globalholes: 0 >>> net.inet.tcp.sack.globalmaxholes: 65536 >>> net.inet.tcp.sack.maxholes: 128 >>> net.inet.tcp.sack.enable: 1 >>> net.inet.tcp.inflight.stab: 20 >>> net.inet.tcp.inflight.max: 1073725440 >>> net.inet.tcp.inflight.min: 6144 >>> net.inet.tcp.inflight.rttthresh: 10 >>> net.inet.tcp.inflight.debug: 0 >>> net.inet.tcp.inflight.enable: 1 >>> net.inet.tcp.isn_reseed_interval: 0 >>> net.inet.tcp.icmp_may_rst: 1 >>> net.inet.tcp.pcbcount: 26 >>> net.inet.tcp.do_tcpdrain: 1 >>> net.inet.tcp.tcbhashsize: 512 >>> net.inet.tcp.log_debug: 0 >>> net.inet.tcp.minmss: 216 >>> net.inet.tcp.syncache.rst_on_sock_fail: 1 >>> net.inet.tcp.syncache.rexmtlimit: 3 >>> net.inet.tcp.syncache.hashsize: 512 >>> net.inet.tcp.syncache.count: 0 >>> net.inet.tcp.syncache.cachelimit: 15360 >>> net.inet.tcp.syncache.bucketlimit: 30 >>> net.inet.tcp.syncookies_only: 0 >>> net.inet.tcp.syncookies: 1 >>> net.inet.tcp.timer_race: 0 >>> net.inet.tcp.finwait2_timeout: 60000 >>> net.inet.tcp.fast_finwait2_recycle: 0 >>> net.inet.tcp.always_keepalive: 1 >>> net.inet.tcp.rexmit_slop: 200 >>> net.inet.tcp.rexmit_min: 30 >>> net.inet.tcp.msl: 30000 >>> net.inet.tcp.nolocaltimewait: 0 >>> net.inet.tcp.maxtcptw: 5120 >>> net.inet.udp.checksum: 1 >>> net.inet.udp.maxdgram: 9216 >>> net.inet.udp.recvspace: 42080 >>> net.inet.udp.blackhole: 0 >>> net.inet.udp.log_in_vain: 0 >>> net.inet.sctp.nat_friendly_init: 1 >>> net.inet.sctp.enable_sack_immediately: 0 >>> net.inet.sctp.udp_tunneling_port: 0 >>> net.inet.sctp.udp_tunneling_for_client_enable: 0 >>> net.inet.sctp.mobility_fasthandoff: 0 >>> net.inet.sctp.mobility_base: 0 >>> net.inet.sctp.default_frag_interleave: 1 >>> net.inet.sctp.default_cc_module: 0 >>> net.inet.sctp.log_level: 0 >>> net.inet.sctp.max_retran_chunk: 30 >>> net.inet.sctp.min_residual: 1452 >>> net.inet.sctp.strict_data_order: 0 >>> net.inet.sctp.abort_at_limit: 0 >>> net.inet.sctp.hb_max_burst: 4 >>> net.inet.sctp.do_sctp_drain: 1 >>> net.inet.sctp.max_chained_mbufs: 5 >>> net.inet.sctp.abc_l_var: 1 >>> net.inet.sctp.nat_friendly: 1 >>> net.inet.sctp.auth_disable: 0 >>> net.inet.sctp.asconf_auth_nochk: 0 >>> net.inet.sctp.early_fast_retran_msec: 250 >>> net.inet.sctp.early_fast_retran: 0 >>> net.inet.sctp.cwnd_maxburst: 1 >>> net.inet.sctp.cmt_pf: 0 >>> net.inet.sctp.cmt_use_dac: 0 >>> net.inet.sctp.nr_sack_on_off: 0 >>> net.inet.sctp.cmt_on_off: 0 >>> net.inet.sctp.outgoing_streams: 10 >>> net.inet.sctp.add_more_on_output: 1452 >>> net.inet.sctp.path_rtx_max: 5 >>> net.inet.sctp.assoc_rtx_max: 10 >>> net.inet.sctp.init_rtx_max: 8 >>> net.inet.sctp.valid_cookie_life: 60000 >>> net.inet.sctp.init_rto_max: 60000 >>> net.inet.sctp.rto_initial: 3000 >>> net.inet.sctp.rto_min: 1000 >>> net.inet.sctp.rto_max: 60000 >>> net.inet.sctp.secret_lifetime: 3600 >>> net.inet.sctp.shutdown_guard_time: 180 >>> net.inet.sctp.pmtu_raise_time: 600 >>> net.inet.sctp.heartbeat_interval: 30000 >>> net.inet.sctp.asoc_resource: 10 >>> net.inet.sctp.sys_resource: 1000 >>> net.inet.sctp.sack_freq: 2 >>> net.inet.sctp.delayed_sack_time: 200 >>> net.inet.sctp.chunkscale: 10 >>> net.inet.sctp.min_split_point: 2904 >>> net.inet.sctp.pcbhashsize: 256 >>> net.inet.sctp.tcbhashsize: 1024 >>> net.inet.sctp.maxchunks: 3200 >>> net.inet.sctp.maxburst: 4 >>> net.inet.sctp.peer_chkoh: 256 >>> net.inet.sctp.strict_init: 1 >>> net.inet.sctp.loopback_nocsum: 1 >>> net.inet.sctp.strict_sacks: 1 >>> net.inet.sctp.ecn_nonce: 0 >>> net.inet.sctp.ecn_enable: 1 >>> net.inet.sctp.auto_asconf: 1 >>> net.inet.sctp.recvspace: 233016 >>> net.inet.sctp.sendspace: 233016 >>> net.inet.raw.recvspace: 9216 >>> net.inet.raw.maxdgram: 9216 >>> net.inet.accf.unloadable: 0 >>> net.inet.flowtable.nmbflows: 4096 >>> net.inet.flowtable.tcp_expire: 86400 >>> net.inet.flowtable.fin_wait_expire: 600 >>> net.inet.flowtable.udp_expire: 300 >>> net.inet.flowtable.syn_expire: 300 >>> net.inet.flowtable.collisions: 0 >>> net.inet.flowtable.max_depth: 0 >>> net.inet.flowtable.free_checks: 0 >>> net.inet.flowtable.frees: 0 >>> net.inet.flowtable.misses: 0 >>> net.inet.flowtable.lookups: 0 >>> net.inet.flowtable.hits: 0 >>> net.inet.flowtable.enable: 0 >>> net.link.generic.system.ifcount: 3 >>> net.link.ether.inet.log_arp_permanent_modify: 1 >>> net.link.ether.inet.log_arp_movements: 1 >>> net.link.ether.inet.log_arp_wrong_iface: 1 >>> net.link.ether.inet.proxyall: 0 >>> net.link.ether.inet.useloopback: 1 >>> net.link.ether.inet.maxtries: 5 >>> net.link.ether.inet.max_age: 1200 >>> net.link.ether.ipfw: 0 >>> net.link.gif.parallel_tunnels: 0 >>> net.link.gif.max_nesting: 1 >>> net.link.log_link_state_change: 1 >>> net.link.tun.devfs_cloning: 1 >>> net.inet6.ip6.forwarding: 0 >>> net.inet6.ip6.redirect: 1 >>> net.inet6.ip6.hlim: 64 >>> net.inet6.ip6.maxfragpackets: 6400 >>> net.inet6.ip6.accept_rtadv: 0 >>> net.inet6.ip6.keepfaith: 0 >>> net.inet6.ip6.log_interval: 5 >>> net.inet6.ip6.hdrnestlimit: 15 >>> net.inet6.ip6.dad_count: 1 >>> net.inet6.ip6.auto_flowlabel: 1 >>> net.inet6.ip6.defmcasthlim: 1 >>> net.inet6.ip6.gifhlim: 30 >>> net.inet6.ip6.kame_version: FreeBSD >>> net.inet6.ip6.use_deprecated: 1 >>> net.inet6.ip6.rr_prune: 5 >>> net.inet6.ip6.v6only: 1 >>> net.inet6.ip6.rtexpire: 3600 >>> net.inet6.ip6.rtminexpire: 10 >>> net.inet6.ip6.rtmaxcache: 128 >>> net.inet6.ip6.use_tempaddr: 0 >>> net.inet6.ip6.temppltime: 86400 >>> net.inet6.ip6.tempvltime: 604800 >>> net.inet6.ip6.auto_linklocal: 0 >>> net.inet6.ip6.prefer_tempaddr: 0 >>> net.inet6.ip6.use_defaultzone: 0 >>> net.inet6.ip6.maxfrags: 6400 >>> net.inet6.ip6.mcast_pmtu: 0 >>> net.inet6.ip6.mcast.loop: 1 >>> net.inet6.ip6.mcast.maxsocksrc: 128 >>> net.inet6.ip6.mcast.maxgrpsrc: 512 >>> net.inet6.icmp6.rediraccept: 1 >>> net.inet6.icmp6.redirtimeout: 600 >>> net.inet6.icmp6.nd6_prune: 1 >>> net.inet6.icmp6.nd6_delay: 5 >>> net.inet6.icmp6.nd6_umaxtries: 3 >>> net.inet6.icmp6.nd6_mmaxtries: 3 >>> net.inet6.icmp6.nd6_useloopback: 1 >>> net.inet6.icmp6.nodeinfo: 3 >>> net.inet6.icmp6.errppslimit: 100 >>> net.inet6.icmp6.nd6_maxnudhint: 0 >>> net.inet6.icmp6.nd6_debug: 0 >>> net.inet6.icmp6.nd6_maxqueuelen: 1 >>> net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 >>> net.inet6.mld.gsrdelay: 10 >>> net.bpf.zerocopy_enable: 0 >>> net.bpf.maxinsns: 512 >>> net.bpf.maxbufsize: 524288 >>> net.bpf.bufsize: 4096 >>> net.isr.swi_count: 419599 >>> net.isr.drop: 0 >>> net.isr.queued: 830117 >>> net.isr.deferred: 0 >>> net.isr.directed: 3109 >>> net.isr.count: 3109 >>> net.isr.direct: 1 >>> net.raw.recvspace: 8192 >>> net.raw.sendspace: 8192 >>> net.my_fibnum: 0 >>> net.add_addr_allfibs: 1 >>> net.fibs: 1 >>> net.route.netisr_maxqlen: 256 >>> debug.ddb.capture.bufsize: 49152 >>> debug.ddb.capture.inprogress: 0 >>> debug.ddb.capture.maxbufsize: 5242880 >>> debug.ddb.capture.bufoff: 0 >>> debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: >>> debug.ddb.textdump.do_version: 1 >>> debug.ddb.textdump.do_panic: 1 >>> debug.ddb.textdump.do_msgbuf: 1 >>> debug.ddb.textdump.do_ddb: 1 >>> debug.ddb.textdump.do_config: 1 >>> debug.ddb.textdump.pending: 0 >>> debug.ddb_use_printf: 0 >>> debug.acpi.semaphore_debug: 0 >>> debug.acpi.suspend_bounce: 0 >>> debug.acpi.reset_clock: 1 >>> debug.acpi.do_powerstate: 1 >>> debug.acpi.acpi_ca_version: 20070320 >>> debug.acpi.ec.timeout: 750 >>> debug.acpi.ec.polled: 0 >>> debug.acpi.ec.burst: 0 >>> debug.acpi.batt.batt_sleep_ms: 0 >>> debug.acpi.resume_beep: 0 >>> debug.mddebug: 0 >>> debug.gdbcons: 0 >>> debug.elf64_legacy_coredump: 0 >>> debug.bootverbose: 0 >>> debug.boothowto: 0 >>> debug.cpufreq.verbose: 0 >>> debug.cpufreq.lowest: 0 >>> debug.sizeof.cdev_priv: 376 >>> debug.sizeof.cdev: 288 >>> debug.sizeof.g_bioq: 56 >>> debug.sizeof.g_consumer: 96 >>> debug.sizeof.g_provider: 136 >>> debug.sizeof.g_geom: 136 >>> debug.sizeof.g_class: 136 >>> debug.sizeof.kinfo_proc: 1088 >>> debug.sizeof.buf: 600 >>> debug.sizeof.bio: 216 >>> debug.sizeof.proc: 1112 >>> debug.sizeof.vnode: 472 >>> debug.sizeof.devstat: 288 >>> debug.sizeof.namecache: 72 >>> debug.sizeof.znode: 376 >>> debug.osd: 0 >>> debug.rwlock.loops: 10000 >>> debug.rwlock.retry: 10 >>> debug.trace_on_panic: 1 >>> debug.debugger_on_panic: 0 >>> debug.to_avg_mpcalls: 515 >>> debug.to_avg_lockcalls: 1 >>> debug.to_avg_gcalls: 255 >>> debug.to_avg_depth: 1017 >>> debug.umtx.umtx_pi_allocated: 0 >>> debug.kdb.stop_cpus: 1 >>> debug.kdb.trap_code: 0 >>> debug.kdb.trap: 0 >>> debug.kdb.panic: 0 >>> debug.kdb.enter: 0 >>> debug.kdb.current: ddb >>> debug.kdb.available: ddb debug.rman_debug: 0 >>> debug.ttydebug: 0 >>> debug.disablefullpath: 0 >>> debug.disablecwd: 0 >>> debug.vfscache: 1 >>> debug.numcachehv: 2066 >>> debug.numcache: 30787 >>> debug.numneg: 766 >>> debug.ncnegfactor: 16 >>> debug.nchash: 131071 >>> debug.vnlru_nowhere: 0 >>> debug.rush_requests: 0 >>> debug.mpsafevfs: 1 >>> debug.if_tun_debug: 0 >>> debug.nlm_debug: 0 >>> debug.crypto_timing: 0 >>> debug.collectsnapstats: 0 >>> debug.snapdebug: 0 >>> debug.dopersistence: 0 >>> debug.dir_entry: 0 >>> debug.direct_blk_ptrs: 0 >>> debug.inode_bitmap: 0 >>> debug.indir_blk_ptrs: 0 >>> debug.sync_limit_hit: 0 >>> debug.ino_limit_hit: 0 >>> debug.blk_limit_hit: 0 >>> debug.ino_limit_push: 0 >>> debug.blk_limit_push: 0 >>> debug.worklist_push: 0 >>> debug.maxindirdeps: 50 >>> debug.tickdelay: 2 >>> debug.max_softdeps: 400000 >>> debug.dobkgrdwrite: 1 >>> debug.bigcgs: 0 >>> debug.dircheck: 0 >>> debug.minidump: 1 >>> debug.psm.pkterrthresh: 2 >>> debug.psm.usecs: 500000 >>> debug.psm.secs: 0 >>> debug.psm.errusecs: 0 >>> debug.psm.errsecs: 2 >>> debug.psm.hz: 20 >>> debug.psm.loglevel: 0 >>> debug.fdc.settle: 125 >>> debug.fdc.spec2: 16 >>> debug.fdc.spec1: 175 >>> debug.fdc.retries: 10 >>> debug.fdc.debugflags: 0 >>> debug.fdc.fifo: 8 >>> debug.elf32_legacy_coredump: 0 >>> debug.hwpstate_verbose: 0 >>> hw.machine: amd64 >>> hw.model: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 =A05120 =A0@ 1.86GHz >>> hw.ncpu: 4 >>> hw.byteorder: 1234 >>> hw.physmem: 17167667200 >>> hw.usermem: 3024932864 >>> hw.pagesize: 4096 >>> hw.floatingpoint: 1 >>> hw.machine_arch: amd64 >>> hw.realmem: 17985175552 >>> hw.ata.setmax: 0 >>> hw.ata.wc: 1 >>> hw.ata.atapi_dma: 1 >>> hw.ata.ata_dma_check_80pin: 1 >>> hw.ata.ata_dma: 1 >>> hw.pci.honor_msi_blacklist: 1 >>> hw.pci.enable_msix: 1 >>> hw.pci.enable_msi: 1 >>> hw.pci.do_power_resume: 1 >>> hw.pci.do_power_nodriver: 0 >>> hw.pci.enable_io_modes: 1 >>> hw.pci.host_mem_start: 2147483648 >>> hw.syscons.kbd_debug: 1 >>> hw.syscons.kbd_reboot: 1 >>> hw.syscons.bell: 1 >>> hw.syscons.saver.keybonly: 1 >>> hw.syscons.sc_no_suspend_vtswitch: 0 >>> hw.usb2.ehci.no_hs: 0 >>> hw.usb2.ehci.debug: 0 >>> hw.usb2.uhci.loop: 0 >>> hw.usb2.uhci.debug: 0 >>> hw.usb2.ctrl.debug: 0 >>> hw.usb2.umass.debug: 0 >>> hw.usb2.urio.debug: 0 >>> hw.usb2.debug: 0 >>> hw.usb2.dev.debug: 0 >>> hw.usb2.template: 0 >>> hw.usb2.ugen.debug: 0 >>> hw.usb2.power_timeout: 30 >>> hw.usb2.uhub.debug: 0 >>> hw.usb2.proc.debug: 0 >>> hw.usb2.ss_delay: 0 >>> hw.usb2.pr_recovery_delay: 250 >>> hw.usb2.pr_poll_delay: 50 >>> hw.usb2.ulpt.debug: 0 >>> hw.usb2.ucom.debug: 0 >>> hw.usb2.uhid.debug: 0 >>> hw.usb2.ukbd.debug: 0 >>> hw.usb2.ums.debug: 0 >>> hw.intr_storm_threshold: 1000 >>> hw.availpages: 4191325 >>> hw.bus.devctl_disable: 0 >>> hw.busdma.total_bpages: 8202 >>> hw.busdma.zone0.total_bpages: 8202 >>> hw.busdma.zone0.free_bpages: 8202 >>> hw.busdma.zone0.reserved_bpages: 0 >>> hw.busdma.zone0.active_bpages: 0 >>> hw.busdma.zone0.total_bounced: 639896 >>> hw.busdma.zone0.total_deferred: 0 >>> hw.busdma.zone0.lowaddr: 0xffffffff >>> hw.busdma.zone0.alignment: 4096 >>> hw.clockrate: 1862 >>> hw.via_feature_xcrypt: 0 >>> hw.via_feature_rng: 0 >>> hw.instruction_sse: 1 >>> hw.apic.enable_extint: 0 >>> hw.psm.tap_timeout: 125000 >>> hw.psm.tap_threshold: 25 >>> hw.ipmi.on: 1 >>> hw.kbd.keymap_restrict_change: 0 >>> hw.mca.count: 0 >>> hw.mca.interval: 3600 >>> hw.mca.force_scan: 0 >>> hw.acpi.supported_sleep_state: S1 S4 S5 >>> hw.acpi.power_button_state: S5 >>> hw.acpi.sleep_button_state: S1 >>> hw.acpi.lid_switch_state: NONE >>> hw.acpi.standby_state: S1 >>> hw.acpi.suspend_state: NONE >>> hw.acpi.sleep_delay: 1 >>> hw.acpi.s4bios: 0 >>> hw.acpi.verbose: 0 >>> hw.acpi.disable_on_reboot: 0 >>> hw.acpi.handle_reboot: 1 >>> hw.acpi.reset_video: 0 >>> hw.acpi.cpu.cx_lowest: C1 >>> hw.dri.0.name: radeon 0x2a >>> hw.dri.0.vm: slot offset =A0 =A0 =A0 =A0 =A0 =A0 size =A0 =A0 =A0 type = flags address >>> =A0mtrr >>> =A00 0x00000000d8200000 0x00010000 =A0REG =A00x82 0xffffff00d8200000 no >>> >>> hw.dri.0.clients: a dev =A0 pid =A0 =A0uid =A0 =A0 =A0magic =A0 =A0 ioc= tls >>> >>> hw.dri.0.debug: 0 >>> machdep.acpi_timer_freq: 3579545 >>> machdep.enable_panic_key: 0 >>> machdep.adjkerntz: 18000 >>> machdep.wall_cmos_clock: 1 >>> machdep.disable_rtc_set: 0 >>> machdep.acpi_root: 1007888 >>> machdep.disable_mtrrs: 0 >>> machdep.idle: acpi >>> machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, >>> machdep.hlt_cpus: >>> 0 >>> machdep.prot_fault_translation: 0 >>> machdep.panic_on_nmi: 1 >>> machdep.kdb_on_nmi: 1 >>> machdep.tsc_freq: 1862013503 >>> machdep.i8254_freq: 1193182 >>> machdep.hlt_logical_cpus: 0 >>> machdep.logical_cpus_mask: 10 >>> user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: >>> user.bc_base_max: 99 >>> user.bc_dim_max: 2048 >>> user.bc_scale_max: 99 >>> user.bc_string_max: 1000 >>> user.coll_weights_max: 0 >>> user.expr_nest_max: 32 >>> user.line_max: 2048 >>> user.re_dup_max: 255 >>> user.posix2_version: 199212 >>> user.posix2_c_bind: 0 >>> user.posix2_c_dev: 0 >>> user.posix2_char_term: 0 >>> user.posix2_fort_dev: 0 >>> user.posix2_fort_run: 0 >>> user.posix2_localedef: 0 >>> user.posix2_sw_dev: 0 >>> user.posix2_upe: 0 >>> user.stream_max: 20 >>> user.tzname_max: 255 >>> p1003_1b.asynchronous_io: 0 >>> p1003_1b.mapped_files: 1 >>> p1003_1b.memlock: 0 >>> p1003_1b.memlock_range: 0 >>> p1003_1b.memory_protection: 0 >>> p1003_1b.message_passing: 0 >>> p1003_1b.prioritized_io: 0 >>> p1003_1b.priority_scheduling: 1 >>> p1003_1b.realtime_signals: 200112 >>> p1003_1b.semaphores: 0 >>> p1003_1b.fsync: 0 >>> p1003_1b.shared_memory_objects: 1 >>> p1003_1b.synchronized_io: 0 >>> p1003_1b.timers: 200112 >>> p1003_1b.aio_listio_max: -1 >>> p1003_1b.aio_max: -1 >>> p1003_1b.aio_prio_delta_max: -1 >>> p1003_1b.delaytimer_max: 2147483647 >>> p1003_1b.mq_open_max: 0 >>> p1003_1b.pagesize: 4096 >>> p1003_1b.rtsig_max: 62 >>> p1003_1b.sem_nsems_max: 0 >>> p1003_1b.sem_value_max: 0 >>> p1003_1b.sigqueue_max: 128 >>> p1003_1b.timer_max: 32 >>> security.jail.jailed: 0 >>> security.jail.param.host.hostname: 256 >>> security.jail.param.securelevel: 0 >>> security.jail.param.path: 1024 >>> security.jail.param.cpuset: 0 >>> security.jail.param.name: 256 >>> security.jail.param.jid: 0 >>> security.jail.param.linux.oss_version: 0 >>> security.jail.param.linux.osrelease: 65 >>> security.jail.param.linux.osname: 65 >>> security.jail.jail_max_af_ips: 255 >>> security.jail.mount_allowed: 0 >>> security.jail.chflags_allowed: 0 >>> security.jail.allow_raw_sockets: 0 >>> security.jail.enforce_statfs: 2 >>> security.jail.sysvipc_allowed: 0 >>> security.jail.socket_unixiproute_only: 1 >>> security.jail.set_hostname_allowed: 1 >>> security.bsd.suser_enabled: 1 >>> security.bsd.unprivileged_proc_debug: 1 >>> security.bsd.conservative_signals: 1 >>> security.bsd.see_other_gids: 1 >>> security.bsd.see_other_uids: 1 >>> security.bsd.unprivileged_read_msgbuf: 1 >>> security.bsd.hardlink_check_gid: 0 >>> security.bsd.hardlink_check_uid: 0 >>> security.bsd.unprivileged_get_quota: 0 >>> compat.ia32.maxvmem: 0 >>> compat.ia32.maxssiz: 67108864 >>> compat.ia32.maxdsiz: 536870912 >>> compat.linux.oss_version: 198144 >>> compat.linux.osrelease: 2.6.16 >>> compat.linux.osname: Linux >>> compat.linux32.maxvmem: 0 >>> compat.linux32.maxssiz: 67108864 >>> compat.linux32.maxdsiz: 536870912 >>> dev.nexus.0.%driver: nexus >>> dev.nexus.0.%parent: root0 >>> dev.ram.0.%desc: System RAM >>> dev.ram.0.%driver: ram >>> dev.ram.0.%parent: nexus0 >>> dev.smbios.0.%desc: System Management BIOS >>> dev.smbios.0.%driver: smbios >>> dev.smbios.0.%parent: nexus0 >>> dev.cryptosoft.0.%desc: software crypto >>> dev.cryptosoft.0.%driver: cryptosoft >>> dev.cryptosoft.0.%parent: nexus0 >>> dev.acpi.0.%desc: SMCI SMCISLP2 >>> dev.acpi.0.%driver: acpi >>> dev.acpi.0.%parent: nexus0 >>> dev.acpi_sysresource.0.%desc: System Resource >>> dev.acpi_sysresource.0.%driver: acpi_sysresource >>> dev.acpi_sysresource.0.%location: handle=3D\_SB_.PCI0.LPC0.MBRD >>> dev.acpi_sysresource.0.%pnpinfo: _HID=3DPNP0C02 _UID=3D31 >>> dev.acpi_sysresource.0.%parent: acpi0 >>> dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz >>> dev.acpi_timer.0.%driver: acpi_timer >>> dev.acpi_timer.0.%location: unknown >>> dev.acpi_timer.0.%pnpinfo: unknown >>> dev.acpi_timer.0.%parent: acpi0 >>> dev.pci_link.0.%desc: ACPI PCI Link LNKA >>> dev.pci_link.0.%driver: pci_link >>> dev.pci_link.0.%location: handle=3D\_SB_.PCI0.LPC0.LNKA >>> dev.pci_link.0.%pnpinfo: _HID=3DPNP0C0F _UID=3D1 >>> dev.pci_link.0.%parent: acpi0 >>> dev.pci_link.1.%desc: ACPI PCI Link LNKB >>> dev.pci_link.1.%driver: pci_link >>> dev.pci_link.1.%location: handle=3D\_SB_.PCI0.LPC0.LNKB >>> dev.pci_link.1.%pnpinfo: _HID=3DPNP0C0F _UID=3D2 >>> dev.pci_link.1.%parent: acpi0 >>> dev.pci_link.2.%desc: ACPI PCI Link LNKC >>> dev.pci_link.2.%driver: pci_link >>> dev.pci_link.2.%location: handle=3D\_SB_.PCI0.LPC0.LNKC >>> dev.pci_link.2.%pnpinfo: _HID=3DPNP0C0F _UID=3D3 >>> dev.pci_link.2.%parent: acpi0 >>> dev.pci_link.3.%desc: ACPI PCI Link LNKD >>> dev.pci_link.3.%driver: pci_link >>> dev.pci_link.3.%location: handle=3D\_SB_.PCI0.LPC0.LNKD >>> dev.pci_link.3.%pnpinfo: _HID=3DPNP0C0F _UID=3D4 >>> dev.pci_link.3.%parent: acpi0 >>> dev.pci_link.4.%desc: ACPI PCI Link LNKE >>> dev.pci_link.4.%driver: pci_link >>> dev.pci_link.4.%location: handle=3D\_SB_.PCI0.LPC0.LNKE >>> dev.pci_link.4.%pnpinfo: _HID=3DPNP0C0F _UID=3D5 >>> dev.pci_link.4.%parent: acpi0 >>> dev.pci_link.5.%desc: ACPI PCI Link LNKF >>> dev.pci_link.5.%driver: pci_link >>> dev.pci_link.5.%location: handle=3D\_SB_.PCI0.LPC0.LNKF >>> dev.pci_link.5.%pnpinfo: _HID=3DPNP0C0F _UID=3D6 >>> dev.pci_link.5.%parent: acpi0 >>> dev.pci_link.6.%desc: ACPI PCI Link LNKG >>> dev.pci_link.6.%driver: pci_link >>> dev.pci_link.6.%location: handle=3D\_SB_.PCI0.LPC0.LNKG >>> dev.pci_link.6.%pnpinfo: _HID=3DPNP0C0F _UID=3D7 >>> dev.pci_link.6.%parent: acpi0 >>> dev.pci_link.7.%desc: ACPI PCI Link LNKH >>> dev.pci_link.7.%driver: pci_link >>> dev.pci_link.7.%location: handle=3D\_SB_.PCI0.LPC0.LNKH >>> dev.pci_link.7.%pnpinfo: _HID=3DPNP0C0F _UID=3D8 >>> dev.pci_link.7.%parent: acpi0 >>> dev.acpi_hpet.0.%desc: High Precision Event Timer >>> dev.acpi_hpet.0.%driver: acpi_hpet >>> dev.acpi_hpet.0.%location: unknown >>> dev.acpi_hpet.0.%pnpinfo: unknown >>> dev.acpi_hpet.0.%parent: acpi0 >>> dev.pcib.0.%desc: ACPI Host-PCI bridge >>> dev.pcib.0.%driver: pcib >>> dev.pcib.0.%location: handle=3D\_SB_.PCI0 >>> dev.pcib.0.%pnpinfo: _HID=3DPNP0A03 _UID=3D0 >>> dev.pcib.0.%parent: acpi0 >>> dev.pcib.1.%desc: ACPI PCI-PCI bridge >>> dev.pcib.1.%driver: pcib >>> dev.pcib.1.%location: slot=3D2 function=3D0 handle=3D\_SB_.PCI0.P0P2 >>> dev.pcib.1.%pnpinfo: vendor=3D0x8086 device=3D0x25f7 subvendor=3D0x0000 >>> subdevice=3D0x0000 class=3D0x060400 >>> dev.pcib.1.%parent: pci0 >>> dev.pcib.1.domain: 0 >>> dev.pcib.1.pribus: 0 >>> dev.pcib.1.secbus: 1 >>> dev.pcib.1.subbus: 7 >>> dev.pcib.2.%desc: ACPI PCI-PCI bridge >>> dev.pcib.2.%driver: pcib >>> dev.pcib.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P2.BM= D0 >>> dev.pcib.2.%pnpinfo: vendor=3D0x8086 device=3D0x3500 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x060400 >>> dev.pcib.2.%parent: pci1 >>> dev.pcib.2.domain: 0 >>> dev.pcib.2.pribus: 1 >>> dev.pcib.2.secbus: 2 >>> dev.pcib.2.subbus: 6 >>> dev.pcib.3.%desc: ACPI PCI-PCI bridge >>> dev.pcib.3.%driver: pcib >>> dev.pcib.3.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P2.BM= D0.BPD0 >>> dev.pcib.3.%pnpinfo: vendor=3D0x8086 device=3D0x3510 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x060400 >>> dev.pcib.3.%parent: pci2 >>> dev.pcib.3.domain: 0 >>> dev.pcib.3.pribus: 2 >>> dev.pcib.3.secbus: 3 >>> dev.pcib.3.subbus: 5 >>> dev.pcib.4.%desc: ACPI PCI-PCI bridge >>> dev.pcib.4.%driver: pcib >>> dev.pcib.4.%location: slot=3D0 function=3D0 >>> handle=3D\_SB_.PCI0.P0P2.BMD0.BPD0.PXH0 >>> dev.pcib.4.%pnpinfo: vendor=3D0x8086 device=3D0x0329 subvendor=3D0x0000 >>> subdevice=3D0x0000 class=3D0x060400 >>> dev.pcib.4.%parent: pci3 >>> dev.pcib.4.domain: 0 >>> dev.pcib.4.pribus: 3 >>> dev.pcib.4.secbus: 4 >>> dev.pcib.4.subbus: 4 >>> dev.pcib.4.wake: 0 >>> dev.pcib.5.%desc: ACPI PCI-PCI bridge >>> dev.pcib.5.%driver: pcib >>> dev.pcib.5.%location: slot=3D0 function=3D2 >>> handle=3D\_SB_.PCI0.P0P2.BMD0.BPD0.PXH1 >>> dev.pcib.5.%pnpinfo: vendor=3D0x8086 device=3D0x032a subvendor=3D0x0000 >>> subdevice=3D0x0000 class=3D0x060400 >>> dev.pcib.5.%parent: pci3 >>> dev.pcib.5.domain: 0 >>> dev.pcib.5.pribus: 3 >>> dev.pcib.5.secbus: 5 >>> dev.pcib.5.subbus: 5 >>> dev.pcib.5.wake: 0 >>> dev.pcib.6.%desc: ACPI PCI-PCI bridge >>> dev.pcib.6.%driver: pcib >>> dev.pcib.6.%location: slot=3D2 function=3D0 handle=3D\_SB_.PCI0.P0P2.BM= D0.BPD2 >>> dev.pcib.6.%pnpinfo: vendor=3D0x8086 device=3D0x3518 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x060400 >>> dev.pcib.6.%parent: pci2 >>> dev.pcib.6.domain: 0 >>> dev.pcib.6.pribus: 2 >>> dev.pcib.6.secbus: 6 >>> dev.pcib.6.subbus: 6 >>> dev.pcib.6.wake: 0 >>> dev.pcib.7.%desc: ACPI PCI-PCI bridge >>> dev.pcib.7.%driver: pcib >>> dev.pcib.7.%location: slot=3D0 function=3D3 handle=3D\_SB_.PCI0.P0P2.BM= F3 >>> dev.pcib.7.%pnpinfo: vendor=3D0x8086 device=3D0x350c subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x060400 >>> dev.pcib.7.%parent: pci1 >>> dev.pcib.7.domain: 0 >>> dev.pcib.7.pribus: 1 >>> dev.pcib.7.secbus: 7 >>> dev.pcib.7.subbus: 7 >>> dev.pcib.7.wake: 0 >>> dev.pcib.8.%desc: ACPI PCI-PCI bridge >>> dev.pcib.8.%driver: pcib >>> dev.pcib.8.%location: slot=3D4 function=3D0 handle=3D\_SB_.PCI0.P0P4 >>> dev.pcib.8.%pnpinfo: vendor=3D0x8086 device=3D0x25f8 subvendor=3D0x0000 >>> subdevice=3D0x0000 class=3D0x060400 >>> dev.pcib.8.%parent: pci0 >>> dev.pcib.8.domain: 0 >>> dev.pcib.8.pribus: 0 >>> dev.pcib.8.secbus: 8 >>> dev.pcib.8.subbus: 8 >>> dev.pcib.8.wake: 0 >>> dev.pcib.9.%desc: ACPI PCI-PCI bridge >>> dev.pcib.9.%driver: pcib >>> dev.pcib.9.%location: slot=3D6 function=3D0 handle=3D\_SB_.PCI0.P0P6 >>> dev.pcib.9.%pnpinfo: vendor=3D0x8086 device=3D0x25f9 subvendor=3D0x0000 >>> subdevice=3D0x0000 class=3D0x060400 >>> dev.pcib.9.%parent: pci0 >>> dev.pcib.9.domain: 0 >>> dev.pcib.9.pribus: 0 >>> dev.pcib.9.secbus: 9 >>> dev.pcib.9.subbus: 9 >>> dev.pcib.9.wake: 0 >>> dev.pcib.10.%desc: ACPI PCI-PCI bridge >>> dev.pcib.10.%driver: pcib >>> dev.pcib.10.%location: slot=3D28 function=3D0 handle=3D\_SB_.PCI0.PEX0 >>> dev.pcib.10.%pnpinfo: vendor=3D0x8086 device=3D0x2690 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060400 >>> dev.pcib.10.%parent: pci0 >>> dev.pcib.10.domain: 0 >>> dev.pcib.10.pribus: 0 >>> dev.pcib.10.secbus: 10 >>> dev.pcib.10.subbus: 10 >>> dev.pcib.10.wake: 0 >>> dev.pcib.11.%desc: ACPI PCI-PCI bridge >>> dev.pcib.11.%driver: pcib >>> dev.pcib.11.%location: slot=3D30 function=3D0 handle=3D\_SB_.PCI0.PCIB >>> dev.pcib.11.%pnpinfo: vendor=3D0x8086 device=3D0x244e subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060401 >>> dev.pcib.11.%parent: pci0 >>> dev.pcib.11.domain: 0 >>> dev.pcib.11.pribus: 0 >>> dev.pcib.11.secbus: 11 >>> dev.pcib.11.subbus: 11 >>> dev.pcib.11.wake: 0 >>> dev.pci.0.%desc: ACPI PCI bus >>> dev.pci.0.%driver: pci >>> dev.pci.0.%parent: pcib0 >>> dev.pci.1.%desc: ACPI PCI bus >>> dev.pci.1.%driver: pci >>> dev.pci.1.%parent: pcib1 >>> dev.pci.2.%desc: ACPI PCI bus >>> dev.pci.2.%driver: pci >>> dev.pci.2.%parent: pcib2 >>> dev.pci.3.%desc: ACPI PCI bus >>> dev.pci.3.%driver: pci >>> dev.pci.3.%parent: pcib3 >>> dev.pci.4.%desc: ACPI PCI bus >>> dev.pci.4.%driver: pci >>> dev.pci.4.%parent: pcib4 >>> dev.pci.4.wake: 0 >>> dev.pci.5.%desc: ACPI PCI bus >>> dev.pci.5.%driver: pci >>> dev.pci.5.%parent: pcib5 >>> dev.pci.5.wake: 0 >>> dev.pci.6.%desc: ACPI PCI bus >>> dev.pci.6.%driver: pci >>> dev.pci.6.%parent: pcib6 >>> dev.pci.6.wake: 0 >>> dev.pci.7.%desc: ACPI PCI bus >>> dev.pci.7.%driver: pci >>> dev.pci.7.%parent: pcib7 >>> dev.pci.7.wake: 0 >>> dev.pci.8.%desc: ACPI PCI bus >>> dev.pci.8.%driver: pci >>> dev.pci.8.%parent: pcib8 >>> dev.pci.8.wake: 0 >>> dev.pci.9.%desc: ACPI PCI bus >>> dev.pci.9.%driver: pci >>> dev.pci.9.%parent: pcib9 >>> dev.pci.9.wake: 0 >>> dev.pci.10.%desc: ACPI PCI bus >>> dev.pci.10.%driver: pci >>> dev.pci.10.%parent: pcib10 >>> dev.pci.10.wake: 0 >>> dev.pci.11.%desc: ACPI PCI bus >>> dev.pci.11.%driver: pci >>> dev.pci.11.%parent: pcib11 >>> dev.pci.11.wake: 0 >>> dev.hostb.0.%desc: Host to PCI bridge >>> dev.hostb.0.%driver: hostb >>> dev.hostb.0.%location: slot=3D0 function=3D0 >>> dev.hostb.0.%pnpinfo: vendor=3D0x8086 device=3D0x25d8 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.0.%parent: pci0 >>> dev.hostb.1.%desc: Host to PCI bridge >>> dev.hostb.1.%driver: hostb >>> dev.hostb.1.%location: slot=3D16 function=3D0 >>> dev.hostb.1.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.1.%parent: pci0 >>> dev.hostb.2.%desc: Host to PCI bridge >>> dev.hostb.2.%driver: hostb >>> dev.hostb.2.%location: slot=3D16 function=3D1 >>> dev.hostb.2.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.2.%parent: pci0 >>> dev.hostb.3.%desc: Host to PCI bridge >>> dev.hostb.3.%driver: hostb >>> dev.hostb.3.%location: slot=3D16 function=3D2 >>> dev.hostb.3.%pnpinfo: vendor=3D0x8086 device=3D0x25f0 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.3.%parent: pci0 >>> dev.hostb.4.%desc: Host to PCI bridge >>> dev.hostb.4.%driver: hostb >>> dev.hostb.4.%location: slot=3D17 function=3D0 >>> dev.hostb.4.%pnpinfo: vendor=3D0x8086 device=3D0x25f1 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.4.%parent: pci0 >>> dev.hostb.5.%desc: Host to PCI bridge >>> dev.hostb.5.%driver: hostb >>> dev.hostb.5.%location: slot=3D19 function=3D0 >>> dev.hostb.5.%pnpinfo: vendor=3D0x8086 device=3D0x25f3 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.5.%parent: pci0 >>> dev.hostb.6.%desc: Host to PCI bridge >>> dev.hostb.6.%driver: hostb >>> dev.hostb.6.%location: slot=3D21 function=3D0 >>> dev.hostb.6.%pnpinfo: vendor=3D0x8086 device=3D0x25f5 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.6.%parent: pci0 >>> dev.hostb.7.%desc: Host to PCI bridge >>> dev.hostb.7.%driver: hostb >>> dev.hostb.7.%location: slot=3D22 function=3D0 >>> dev.hostb.7.%pnpinfo: vendor=3D0x8086 device=3D0x25f6 subvendor=3D0x15d= 9 >>> subdevice=3D0x8080 class=3D0x060000 >>> dev.hostb.7.%parent: pci0 >>> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >>> dev.em.0.%driver: em >>> dev.em.0.%location: slot=3D0 function=3D0 >>> dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x15d9 >>> subdevice=3D0x0000 class=3D0x020000 >>> dev.em.0.%parent: pci6 >>> dev.em.0.debug: -1 >>> dev.em.0.stats: -1 >>> dev.em.0.rx_int_delay: 0 >>> dev.em.0.tx_int_delay: 66 >>> dev.em.0.rx_abs_int_delay: 66 >>> dev.em.0.tx_abs_int_delay: 66 >>> dev.em.0.rx_processing_limit: 100 >>> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >>> dev.em.1.%driver: em >>> dev.em.1.%location: slot=3D0 function=3D1 >>> dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x15d9 >>> subdevice=3D0x0000 class=3D0x020000 >>> dev.em.1.%parent: pci6 >>> dev.em.1.debug: -1 >>> dev.em.1.stats: -1 >>> dev.em.1.rx_int_delay: 0 >>> dev.em.1.tx_int_delay: 66 >>> dev.em.1.rx_abs_int_delay: 66 >>> dev.em.1.tx_abs_int_delay: 66 >>> dev.em.1.rx_processing_limit: 100 >>> dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >>> dev.uhci.0.%driver: uhci >>> dev.uhci.0.%location: slot=3D29 function=3D0 handle=3D\_SB_.PCI0.USB1 >>> dev.uhci.0.%pnpinfo: vendor=3D0x8086 device=3D0x2688 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x0c0300 >>> dev.uhci.0.%parent: pci0 >>> dev.uhci.0.wake: 0 >>> dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >>> dev.uhci.1.%driver: uhci >>> dev.uhci.1.%location: slot=3D29 function=3D1 handle=3D\_SB_.PCI0.USB2 >>> dev.uhci.1.%pnpinfo: vendor=3D0x8086 device=3D0x2689 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x0c0300 >>> dev.uhci.1.%parent: pci0 >>> dev.uhci.1.wake: 0 >>> dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >>> dev.uhci.2.%driver: uhci >>> dev.uhci.2.%location: slot=3D29 function=3D2 handle=3D\_SB_.PCI0.USB3 >>> dev.uhci.2.%pnpinfo: vendor=3D0x8086 device=3D0x268a subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x0c0300 >>> dev.uhci.2.%parent: pci0 >>> dev.uhci.2.wake: 0 >>> dev.usbus.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >>> dev.usbus.0.%driver: usbus >>> dev.usbus.0.%parent: uhci0 >>> dev.usbus.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >>> dev.usbus.1.%driver: usbus >>> dev.usbus.1.%parent: uhci1 >>> dev.usbus.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >>> dev.usbus.2.%driver: usbus >>> dev.usbus.2.%parent: uhci2 >>> dev.usbus.3.%desc: Intel 63XXESB USB 2.0 controller >>> dev.usbus.3.%driver: usbus >>> dev.usbus.3.%parent: ehci0 >>> dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller >>> dev.ehci.0.%driver: ehci >>> dev.ehci.0.%location: slot=3D29 function=3D7 handle=3D\_SB_.PCI0.EUSB >>> dev.ehci.0.%pnpinfo: vendor=3D0x8086 device=3D0x268c subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x0c0320 >>> dev.ehci.0.%parent: pci0 >>> dev.ehci.0.wake: 0 >>> dev.vgapci.0.%desc: VGA-compatible display >>> dev.vgapci.0.%driver: vgapci >>> dev.vgapci.0.%location: slot=3D1 function=3D0 >>> dev.vgapci.0.%pnpinfo: vendor=3D0x1002 device=3D0x515e subvendor=3D0x15= d9 >>> subdevice=3D0x8080 class=3D0x030000 >>> dev.vgapci.0.%parent: pci11 >>> dev.drm.0.%desc: ATI ES1000 RN50 >>> dev.drm.0.%driver: drm >>> dev.drm.0.%parent: vgapci0 >>> dev.isab.0.%desc: PCI-ISA bridge >>> dev.isab.0.%driver: isab >>> dev.isab.0.%location: slot=3D31 function=3D0 handle=3D\_SB_.PCI0.LPC0 >>> dev.isab.0.%pnpinfo: vendor=3D0x8086 device=3D0x2670 subvendor=3D0x15d9 >>> subdevice=3D0x8080 class=3D0x060100 >>> dev.isab.0.%parent: pci0 >>> dev.isa.0.%desc: ISA bus >>> dev.isa.0.%driver: isa >>> dev.isa.0.%parent: isab0 >>> dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller >>> dev.atapci.0.%driver: atapci >>> dev.atapci.0.%location: slot=3D31 function=3D1 handle=3D\_SB_.PCI0.IDEC >>> dev.atapci.0.%pnpinfo: vendor=3D0x8086 device=3D0x269e subvendor=3D0x15= d9 >>> subdevice=3D0x8080 class=3D0x01018a >>> dev.atapci.0.%parent: pci0 >>> dev.atapci.1.%desc: Intel 63XXESB2 SATA300 controller >>> dev.atapci.1.%driver: atapci >>> dev.atapci.1.%location: slot=3D31 function=3D2 >>> dev.atapci.1.%pnpinfo: vendor=3D0x8086 device=3D0x2681 subvendor=3D0x15= d9 >>> subdevice=3D0x8080 class=3D0x010601 >>> dev.atapci.1.%parent: pci0 >>> dev.ata.0.%desc: ATA channel 0 >>> dev.ata.0.%driver: ata >>> dev.ata.0.%parent: atapci0 >>> dev.ata.2.%desc: ATA channel 0 >>> dev.ata.2.%driver: ata >>> dev.ata.2.%parent: atapci1 >>> dev.ata.3.%desc: ATA channel 1 >>> dev.ata.3.%driver: ata >>> dev.ata.3.%parent: atapci1 >>> dev.ata.4.%desc: ATA channel 2 >>> dev.ata.4.%driver: ata >>> dev.ata.4.%parent: atapci1 >>> dev.ata.5.%desc: ATA channel 3 >>> dev.ata.5.%driver: ata >>> dev.ata.5.%parent: atapci1 >>> dev.ata.6.%desc: ATA channel 4 >>> dev.ata.6.%driver: ata >>> dev.ata.6.%parent: atapci1 >>> dev.ata.7.%desc: ATA channel 5 >>> dev.ata.7.%driver: ata >>> dev.ata.7.%parent: atapci1 >>> dev.ichsmb.0.%desc: Intel 631xESB/6321ESB (ESB2) SMBus controller >>> dev.ichsmb.0.%driver: ichsmb >>> dev.ichsmb.0.%location: slot=3D31 function=3D3 handle=3D\_SB_.PCI0.SMBS >>> dev.ichsmb.0.%pnpinfo: vendor=3D0x8086 device=3D0x269b subvendor=3D0x15= d9 >>> subdevice=3D0x8080 class=3D0x0c0500 >>> dev.ichsmb.0.%parent: pci0 >>> dev.smbus.0.%desc: System Management Bus >>> dev.smbus.0.%driver: smbus >>> dev.smbus.0.%parent: ichsmb0 >>> dev.smb.0.%desc: SMBus generic I/O >>> dev.smb.0.%driver: smb >>> dev.smb.0.%parent: smbus0 >>> dev.acpi_button.0.%desc: Power Button >>> dev.acpi_button.0.%driver: acpi_button >>> dev.acpi_button.0.%location: handle=3D\_SB_.PCI0.PWRB >>> dev.acpi_button.0.%pnpinfo: _HID=3DPNP0C0C _UID=3D0 >>> dev.acpi_button.0.%parent: acpi0 >>> dev.atdma.0.%desc: AT DMA controller >>> dev.atdma.0.%driver: atdma >>> dev.atdma.0.%location: handle=3D\_SB_.PCI0.LPC0.DMAC >>> dev.atdma.0.%pnpinfo: _HID=3DPNP0200 _UID=3D0 >>> dev.atdma.0.%parent: acpi0 >>> dev.fpupnp.0.%desc: Legacy ISA coprocessor support >>> dev.fpupnp.0.%driver: fpupnp >>> dev.fpupnp.0.%location: handle=3D\_SB_.PCI0.LPC0.MATH >>> dev.fpupnp.0.%pnpinfo: _HID=3DPNP0C04 _UID=3D0 >>> dev.fpupnp.0.%parent: acpi0 >>> dev.atrtc.0.%desc: AT realtime clock >>> dev.atrtc.0.%driver: atrtc >>> dev.atrtc.0.%location: handle=3D\_SB_.PCI0.LPC0.RTC_ >>> dev.atrtc.0.%pnpinfo: _HID=3DPNP0B00 _UID=3D0 >>> dev.atrtc.0.%parent: acpi0 >>> dev.attimer.0.%desc: AT timer >>> dev.attimer.0.%driver: attimer >>> dev.attimer.0.%location: handle=3D\_SB_.PCI0.LPC0.TIME >>> dev.attimer.0.%pnpinfo: _HID=3DPNP0100 _UID=3D0 >>> dev.attimer.0.%parent: acpi0 >>> dev.atkbdc.0.%desc: Keyboard controller (i8042) >>> dev.atkbdc.0.%driver: atkbdc >>> dev.atkbdc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.KBC0 >>> dev.atkbdc.0.%pnpinfo: _HID=3DPNP0303 _UID=3D0 >>> dev.atkbdc.0.%parent: acpi0 >>> dev.atkbdc.0.wake: 0 >>> dev.atkbd.0.%desc: AT Keyboard >>> dev.atkbd.0.%driver: atkbd >>> dev.atkbd.0.%parent: atkbdc0 >>> dev.psmcpnp.0.%desc: PS/2 mouse port >>> dev.psmcpnp.0.%driver: psmcpnp >>> dev.psmcpnp.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.MSE0 >>> dev.psmcpnp.0.%pnpinfo: _HID=3DPNP0F13 _UID=3D0 >>> dev.psmcpnp.0.%parent: acpi0 >>> dev.psmcpnp.0.wake: 0 >>> dev.uart.0.%desc: 16550 or compatible >>> dev.uart.0.%driver: uart >>> dev.uart.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.COM1 >>> dev.uart.0.%pnpinfo: _HID=3DPNP0501 _UID=3D1 >>> dev.uart.0.%parent: acpi0 >>> dev.uart.0.wake: 0 >>> dev.uart.1.%desc: 16550 or compatible >>> dev.uart.1.%driver: uart >>> dev.uart.1.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.COM2 >>> dev.uart.1.%pnpinfo: _HID=3DPNP0501 _UID=3D2 >>> dev.uart.1.%parent: acpi0 >>> dev.uart.1.wake: 0 >>> dev.fdc.0.%desc: Enhanced floppy controller >>> dev.fdc.0.%driver: fdc >>> dev.fdc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.FDC_ >>> dev.fdc.0.%pnpinfo: _HID=3DPNP0700 _UID=3D1 >>> dev.fdc.0.%parent: acpi0 >>> dev.fd.0.%desc: 1440-KB 3.5" drive >>> dev.fd.0.%driver: fd >>> dev.fd.0.%parent: fdc0 >>> dev.ppc.0.%desc: Parallel port >>> dev.ppc.0.%driver: ppc >>> dev.ppc.0.%location: handle=3D\_SB_.PCI0.LPC0.SIO_.PRT_ >>> dev.ppc.0.%pnpinfo: _HID=3DPNP0401 _UID=3D2 >>> dev.ppc.0.%parent: acpi0 >>> dev.ppbus.0.%desc: Parallel port bus >>> dev.ppbus.0.%driver: ppbus >>> dev.ppbus.0.%parent: ppc0 >>> dev.lpt.0.%desc: Printer >>> dev.lpt.0.%driver: lpt >>> dev.lpt.0.%parent: ppbus0 >>> dev.ppi.0.%desc: Parallel I/O >>> dev.ppi.0.%driver: ppi >>> dev.ppi.0.%parent: ppbus0 >>> dev.cpu.0.%desc: ACPI CPU >>> dev.cpu.0.%driver: cpu >>> dev.cpu.0.%location: handle=3D\_PR_.CPU0 >>> dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 >>> dev.cpu.0.%parent: acpi0 >>> dev.cpu.0.temperature: 57 >>> dev.cpu.0.freq: 1867 >>> dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 >>> 933/17500 >>> 700/13125 466/8750 233/4375 >>> dev.cpu.0.cx_supported: C1/1 >>> dev.cpu.0.cx_lowest: C1 >>> dev.cpu.0.cx_usage: 100.00% last 500us >>> dev.cpu.1.%desc: ACPI CPU >>> dev.cpu.1.%driver: cpu >>> dev.cpu.1.%location: handle=3D\_PR_.CPU1 >>> dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 >>> dev.cpu.1.%parent: acpi0 >>> dev.cpu.1.temperature: 59 >>> dev.cpu.1.cx_supported: C1/1 >>> dev.cpu.1.cx_lowest: C1 >>> dev.cpu.1.cx_usage: 100.00% last 500us >>> dev.cpu.2.%desc: ACPI CPU >>> dev.cpu.2.%driver: cpu >>> dev.cpu.2.%location: handle=3D\_PR_.CPU2 >>> dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 >>> dev.cpu.2.%parent: acpi0 >>> dev.cpu.2.temperature: 59 >>> dev.cpu.2.cx_supported: C1/1 >>> dev.cpu.2.cx_lowest: C1 >>> dev.cpu.2.cx_usage: 100.00% last 500us >>> dev.cpu.3.%desc: ACPI CPU >>> dev.cpu.3.%driver: cpu >>> dev.cpu.3.%location: handle=3D\_PR_.CPU3 >>> dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 >>> dev.cpu.3.%parent: acpi0 >>> dev.cpu.3.temperature: 60 >>> dev.cpu.3.cx_supported: C1/1 >>> dev.cpu.3.cx_lowest: C1 >>> dev.cpu.3.cx_usage: 100.00% last 500us >>> dev.acpi_perf.0.%driver: acpi_perf >>> dev.acpi_perf.0.%parent: cpu0 >>> dev.acpi_perf.1.%driver: acpi_perf >>> dev.acpi_perf.1.%parent: cpu1 >>> dev.acpi_perf.2.%driver: acpi_perf >>> dev.acpi_perf.2.%parent: cpu2 >>> dev.acpi_perf.3.%driver: acpi_perf >>> dev.acpi_perf.3.%parent: cpu3 >>> dev.coretemp.0.%desc: CPU On-Die Thermal Sensors >>> dev.coretemp.0.%driver: coretemp >>> dev.coretemp.0.%parent: cpu0 >>> dev.coretemp.1.%desc: CPU On-Die Thermal Sensors >>> dev.coretemp.1.%driver: coretemp >>> dev.coretemp.1.%parent: cpu1 >>> dev.coretemp.2.%desc: CPU On-Die Thermal Sensors >>> dev.coretemp.2.%driver: coretemp >>> dev.coretemp.2.%parent: cpu2 >>> dev.coretemp.3.%desc: CPU On-Die Thermal Sensors >>> dev.coretemp.3.%driver: coretemp >>> dev.coretemp.3.%parent: cpu3 >>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control >>> dev.est.0.%driver: est >>> dev.est.0.%parent: cpu0 >>> dev.est.0.freq_settings: 1867/35000 >>> dev.est.1.%desc: Enhanced SpeedStep Frequency Control >>> dev.est.1.%driver: est >>> dev.est.1.%parent: cpu1 >>> dev.est.1.freq_settings: 1867/35000 >>> dev.est.2.%desc: Enhanced SpeedStep Frequency Control >>> dev.est.2.%driver: est >>> dev.est.2.%parent: cpu2 >>> dev.est.2.freq_settings: 1867/35000 >>> dev.est.3.%desc: Enhanced SpeedStep Frequency Control >>> dev.est.3.%driver: est >>> dev.est.3.%parent: cpu3 >>> dev.est.3.freq_settings: 1867/35000 >>> dev.cpufreq.0.%driver: cpufreq >>> dev.cpufreq.0.%parent: cpu0 >>> dev.cpufreq.1.%driver: cpufreq >>> dev.cpufreq.1.%parent: cpu1 >>> dev.cpufreq.2.%driver: cpufreq >>> dev.cpufreq.2.%parent: cpu2 >>> dev.cpufreq.3.%driver: cpufreq >>> dev.cpufreq.3.%parent: cpu3 >>> dev.p4tcc.0.%desc: CPU Frequency Thermal Control >>> dev.p4tcc.0.%driver: p4tcc >>> dev.p4tcc.0.%parent: cpu0 >>> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>> 3750/-1 >>> 2500/-1 1250/-1 >>> dev.p4tcc.1.%desc: CPU Frequency Thermal Control >>> dev.p4tcc.1.%driver: p4tcc >>> dev.p4tcc.1.%parent: cpu1 >>> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>> 3750/-1 >>> 2500/-1 1250/-1 >>> dev.p4tcc.2.%desc: CPU Frequency Thermal Control >>> dev.p4tcc.2.%driver: p4tcc >>> dev.p4tcc.2.%parent: cpu2 >>> dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>> 3750/-1 >>> 2500/-1 1250/-1 >>> dev.p4tcc.3.%desc: CPU Frequency Thermal Control >>> dev.p4tcc.3.%driver: p4tcc >>> dev.p4tcc.3.%parent: cpu3 >>> dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>> 3750/-1 >>> 2500/-1 1250/-1 >>> dev.apic.0.%desc: APIC resources >>> dev.apic.0.%driver: apic >>> dev.apic.0.%parent: nexus0 >>> dev.ipmi.0.%desc: IPMI System Interface >>> dev.ipmi.0.%driver: ipmi >>> dev.ipmi.0.%parent: isa0 >>> dev.orm.0.%desc: ISA Option ROM >>> dev.orm.0.%driver: orm >>> dev.orm.0.%parent: isa0 >>> dev.sc.0.%desc: System console >>> dev.sc.0.%driver: sc >>> dev.sc.0.%parent: isa0 >>> dev.vga.0.%desc: Generic ISA VGA >>> dev.vga.0.%driver: vga >>> dev.vga.0.%parent: isa0 >>> dev.acd.0.%desc: Memorex DVD+-RAM 510L v1/MWS7 >>> dev.acd.0.%driver: acd >>> dev.acd.0.%parent: ata0 >>> dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >>> dev.uhub.0.%driver: uhub >>> dev.uhub.0.%parent: usbus0 >>> dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >>> dev.uhub.1.%driver: uhub >>> dev.uhub.1.%parent: usbus1 >>> dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 >>> dev.uhub.2.%driver: uhub >>> dev.uhub.2.%parent: usbus2 >>> dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 >>> dev.uhub.3.%driver: uhub >>> dev.uhub.3.%parent: usbus3 >>> dev.atapicam.0.%desc: ATAPI CAM Attachment >>> dev.atapicam.0.%driver: atapicam >>> dev.atapicam.0.%parent: ata0 >>> dev.atapicam.1.%desc: ATAPI CAM Attachment >>> dev.atapicam.1.%driver: atapicam >>> dev.atapicam.1.%parent: ata2 >>> dev.atapicam.2.%desc: ATAPI CAM Attachment >>> dev.atapicam.2.%driver: atapicam >>> dev.atapicam.2.%parent: ata3 >>> dev.atapicam.3.%desc: ATAPI CAM Attachment >>> dev.atapicam.3.%driver: atapicam >>> dev.atapicam.3.%parent: ata4 >>> dev.atapicam.4.%desc: ATAPI CAM Attachment >>> dev.atapicam.4.%driver: atapicam >>> dev.atapicam.4.%parent: ata5 >>> dev.atapicam.5.%desc: ATAPI CAM Attachment >>> dev.atapicam.5.%driver: atapicam >>> dev.atapicam.5.%parent: ata6 >>> dev.atapicam.6.%desc: ATAPI CAM Attachment >>> dev.atapicam.6.%driver: atapicam >>> dev.atapicam.6.%parent: ata7 >>> dev.ad.4.%desc: ST3400620AS/3.AAJ >>> dev.ad.4.%driver: ad >>> dev.ad.4.%parent: ata2 >>> dev.ad.6.%desc: ST3400620AS/3.AAJ >>> dev.ad.6.%driver: ad >>> dev.ad.6.%parent: ata3 >>> dev.ad.8.%desc: ST3500630AS/3.AAE >>> dev.ad.8.%driver: ad >>> dev.ad.8.%parent: ata4 >>> dev.ad.10.%desc: ST3400620AS/3.AAJ >>> dev.ad.10.%driver: ad >>> dev.ad.10.%parent: ata5 >>> dev.ad.12.%desc: ST3400620AS/3.AAJ >>> dev.ad.12.%driver: ad >>> dev.ad.12.%parent: ata6 >>> dev.ad.14.%desc: ST3400620AS/3.AAJ >>> dev.ad.14.%driver: ad >>> dev.ad.14.%parent: ata7 >>> dev.ums.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, ad= dr >>> 2 >>> dev.ums.0.%driver: ums >>> dev.ums.0.%location: port=3D6 interface=3D0 >>> dev.ums.0.%pnpinfo: vendor=3D0x14dd product=3D0x0002 devclass=3D0x00 >>> devsubclass=3D0x00 sernum=3D"05269e0157450fa9611C11C62A54F306" intclass= =3D0x03 >>> intsubclass=3D0x00 >>> dev.ums.0.%parent: uhub3 >>> dev.ukbd.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, >>> addr 2 >>> dev.ukbd.0.%driver: ukbd >>> dev.ukbd.0.%location: port=3D6 interface=3D1 >>> dev.ukbd.0.%pnpinfo: vendor=3D0x14dd product=3D0x0002 devclass=3D0x00 >>> devsubclass=3D0x00 sernum=3D"05269e0157450fa9611C11C62A54F306" intclass= =3D0x03 >>> intsubclass=3D0x01 >>> dev.ukbd.0.%parent: uhub3 >>> kstat.zfs.misc.arcstats.hits: 1799140 >>> kstat.zfs.misc.arcstats.misses: 501784 >>> kstat.zfs.misc.arcstats.demand_data_hits: 575806 >>> kstat.zfs.misc.arcstats.demand_data_misses: 83877 >>> kstat.zfs.misc.arcstats.demand_metadata_hits: 949664 >>> kstat.zfs.misc.arcstats.demand_metadata_misses: 71350 >>> kstat.zfs.misc.arcstats.prefetch_data_hits: 126189 >>> kstat.zfs.misc.arcstats.prefetch_data_misses: 326939 >>> kstat.zfs.misc.arcstats.prefetch_metadata_hits: 147481 >>> kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19618 >>> kstat.zfs.misc.arcstats.mru_hits: 1115709 >>> kstat.zfs.misc.arcstats.mru_ghost_hits: 0 >>> kstat.zfs.misc.arcstats.mfu_hits: 490457 >>> kstat.zfs.misc.arcstats.mfu_ghost_hits: 0 >>> kstat.zfs.misc.arcstats.deleted: 9687 >>> kstat.zfs.misc.arcstats.recycle_miss: 0 >>> kstat.zfs.misc.arcstats.mutex_miss: 0 >>> kstat.zfs.misc.arcstats.evict_skip: 0 >>> kstat.zfs.misc.arcstats.hash_elements: 546247 >>> kstat.zfs.misc.arcstats.hash_elements_max: 549954 >>> kstat.zfs.misc.arcstats.hash_collisions: 396590 >>> kstat.zfs.misc.arcstats.hash_chains: 160935 >>> kstat.zfs.misc.arcstats.hash_chain_max: 12 >>> kstat.zfs.misc.arcstats.p: 9317411840 >>> kstat.zfs.misc.arcstats.c: 16093925376 >>> kstat.zfs.misc.arcstats.c_min: 2011740672 >>> kstat.zfs.misc.arcstats.c_max: 16093925376 >>> kstat.zfs.misc.arcstats.size: 12788124608 >>> kstat.zfs.misc.arcstats.hdr_size: 113621248 >>> kstat.zfs.misc.arcstats.l2_hits: 0 >>> kstat.zfs.misc.arcstats.l2_misses: 0 >>> kstat.zfs.misc.arcstats.l2_feeds: 0 >>> kstat.zfs.misc.arcstats.l2_rw_clash: 0 >>> kstat.zfs.misc.arcstats.l2_writes_sent: 0 >>> kstat.zfs.misc.arcstats.l2_writes_done: 0 >>> kstat.zfs.misc.arcstats.l2_writes_error: 0 >>> kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 >>> kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 >>> kstat.zfs.misc.arcstats.l2_evict_reading: 0 >>> kstat.zfs.misc.arcstats.l2_free_on_write: 0 >>> kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 >>> kstat.zfs.misc.arcstats.l2_cksum_bad: 0 >>> kstat.zfs.misc.arcstats.l2_io_error: 0 >>> kstat.zfs.misc.arcstats.l2_size: 0 >>> kstat.zfs.misc.arcstats.l2_hdr_size: 0 >>> kstat.zfs.misc.arcstats.memory_throttle_count: 0 >>> kstat.zfs.misc.vdev_cache_stats.delegations: 19244 >>> kstat.zfs.misc.vdev_cache_stats.hits: 63137 >>> kstat.zfs.misc.vdev_cache_stats.misses: 53109 >>> >>> Ideas? >>> >>> >>>> >>>> >>>> >>> >>> -- >>> Larry Rosenman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.lerct= r.org/~ler >>> Phone: +1 512-248-2683 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 E-Mail: ler@lerc= tr.org >>> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> >> >> >> > > -- > Larry Rosenman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.lerctr.= org/~ler > Phone: +1 512-248-2683 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 E-Mail: ler@lerctr= .org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:05:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317E91065673; Tue, 19 May 2009 01:05:23 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id E4B0F8FC18; Tue, 19 May 2009 01:05:22 +0000 (UTC) (envelope-from ler@lerctr.org) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=N3wCoypqyLwbdukP5xMRCJ+/yuo61Z8EB138LpKRx0acfOaBvuZPG/bFwdGJW+NAjeyRXfXsuTYP0fEdlOm6PFGW9VWBypVPkWIy1r0BBJiwiH4J7GStM/UXSARvuE4V4CZHemUrJe8XVqj7vItMB/kcysdePROHyCq84lyeXlM=; Received: from localhost.lerctr.org ([127.0.0.1]:59445 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6Dlb-000F09-U2; Mon, 18 May 2009 20:05:22 -0500 Received: from 76.205.169.61 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Mon, 18 May 2009 20:05:16 -0500 (CDT) Message-ID: <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> In-Reply-To: <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> Date: Mon, 18 May 2009 20:05:16 -0500 (CDT) From: "Larry Rosenman" To: "Kip Macy" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -1.3 (-) X-LERCTR-Spam-Score: -1.3 (-) X-Spam-Report: SpamScore (-1.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 X-LERCTR-Spam-Report: SpamScore (-1.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, SARE_SUB_OBFU_OTHER=0.135, TW_FH=0.077, TW_KB=0.077, TW_PG=0.077, TW_TK=0.077, TW_UH=0.077, TW_XF=0.077 DomainKey-Status: no signature Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:05:24 -0000 On Mon, May 18, 2009 8:00 pm, Kip Macy wrote: > On Mon, May 18, 2009 at 5:06 PM, Larry Rosenman wrote: >> On Mon, 18 May 2009, Kip Macy wrote: >> >>> The ARC cache allocates wired memory. The ARC will grow until there is >>> vm pressure. >> >> My crash this AM was with 4G real, and the ARC seemed to grow and grow, >> then >> we started paging, and then crashed. >> >> Even with the VM pressure it seemed to grow out of control. >> > > > > > You're running the most recent HEAD? Yes. Also, this used to work just fine (as recently as a 8-may-2009 kernel) with 4G real. It used to leave about 2700M free. The changes in the last week apparently changed something. When I crashed this AM, I re-csup'ed. That's the kernel that's running now. > > -Kip > > >> Ideas? >> >> >>> >>> -Kip >>> >>> >>> On Mon, May 18, 2009 at 4:32 PM, Larry Rosenman wrote: >>>> >>>> On Mon, 18 May 2009, Larry Rosenman wrote: >>>> >>>>> On Mon, 18 May 2009, Adam McDougall wrote: >>>>> >>>>>> I'm not sure if this is related to recent kernel memory code changes >>>>>> or what, but it hasn't happened with code from earlier than a couple >>>>>> days ago.  I had this happen twice, I think the first time was with >>>>>> arc max set to 1024M, the second time was when arc max was unset in >>>>>> loader.conf and the system had been up a few hours but the arc >>>>>> hadn't >>>>>> been squeezed down to a small number yet: >>>>>> Mem: 719M Active, 12G Inact, 3413M Wired, 2608K Cache, 24M Buf, >>>>>> 3741M >>>>>> Free >>>>>> >>>>>> I've deleted the kernel since then but I did not change my sources, >>>>>> I could build a new one and check where the pointers point to I >>>>>> think? >>>>>> If needed.  Or I could reproduce the panic if needed.  It doesn't >>>>>> dump, >>>>>> it just gets stuck after printing the panic. >>>>> >>>>> I wonder if this is the same crash I saw without getting all the >>>>> info. >>>>> >>>>> What I saw was the wired memory getting to be most of the memory on >>>>> the >>>>> box, and then boom. >>>>> >>>>> see my post a few above this. >>>> >>>> Ok, something(tm) is seriously messed up.  I was able to get my hands >>>> on >>>> 12G >>>> more memory, and with that, the backup finishes, but the wired count >>>> is >>>> insane: >>>> >>>> >>>> last pid:  1760;  load averages:  5.46,  7.01,  6.43  up 0+00:37:54 >>>>  18:31:41 >>>> 78 processes:  5 running, 73 sleeping >>>> >>>> Mem: 440M Active, 4020K Inact, 13G Wired, 524K Cache, 441M Buf, 1970M >>>> Free >>>> Swap: 4096M Total, 4096M Free >>>> >>>> >>>>  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU >>>> COMMAND >>>>  1403 ler           1 138   20   141M   118M RUN     2  31:53 100.00% >>>> FahCore_7 >>>>  1400 ler           1 138   20   141M   117M CPU0    0  31:51 100.00% >>>> FahCore_7 >>>>  1397 ler           1 138   20   141M   118M CPU3    3  31:46 100.00% >>>> FahCore_7 >>>>  1235 ler           1 138   20 20072K 11404K CPU1    1  31:34 100.00% >>>> FahCore_7 >>>>  1209 ler           1  44   20   141M   118M nanslp  0   0:07  0.00% >>>> FahCore_78 >>>>  1206 ler           1  44   20   141M   117M nanslp  0   0:07  0.00% >>>> FahCore_78 >>>>  1207 ler           1  44   20   141M   118M nanslp  2   0:06  0.00% >>>> FahCore_78 >>>>  1098 pgsql         1  44    0 62052K 34948K select  2   0:02  0.00% >>>> postgres >>>>  1069 root          1  44    0 19096K  6172K nanslp  0   0:01  0.00% >>>> perl >>>>  1202 ler           1  44    0   194M   776K nanslp  2   0:00  0.00% >>>> fah6 >>>>  1203 ler           1  44    0   194M   776K nanslp  1   0:00  0.00% >>>> fah6 >>>>  1204 ler           1  44    0   194M   776K nanslp  1   0:00  0.00% >>>> fah6 >>>>  1205 ler           1  44    0   194M   768K nanslp  1   0:00  0.00% >>>> fah6 >>>>  1095 pgsql         1  44    0 62052K  5664K select  0   0:00  0.00% >>>> postgres >>>>  1208 ler           1  44   20 20072K 11404K nanslp  2   0:00  0.00% >>>> FahCore_78 >>>>  1756 ler           1  44    0 23900K  8672K nanslp  0   0:00  0.00% >>>> alpine >>>>  988 root          1  44    0 10612K  2376K select  2   0:00  0.00% >>>> ntpd >>>>  1182 root          1  44    0 17636K  7048K nanslp  2   0:00  0.00% >>>> perl >>>> >>>> Sysctl -a: >>>> >>>> kern.ostype: FreeBSD >>>> kern.osrelease: 8.0-CURRENT >>>> kern.osrevision: 199506 >>>> kern.version: FreeBSD 8.0-CURRENT #18: Mon May 18 04:18:03 CDT 2009 >>>>   root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG >>>> >>>> kern.maxvnodes: 100000 >>>> kern.maxproc: 6164 >>>> kern.maxfiles: 12328 >>>> kern.argmax: 262144 >>>> kern.securelevel: -1 >>>> kern.hostname: borg.lerctr.org >>>> kern.hostid: 3935026275 >>>> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 >>>> } >>>> kern.posix1version: 200112 >>>> kern.ngroups: 16 >>>> kern.job_control: 1 >>>> kern.saved_ids: 0 >>>> kern.boottime: { sec = 1242687257, usec = 281783 } Mon May 18 17:54:17 >>>> 2009 >>>> kern.domainname: kern.osreldate: 800087 >>>> kern.bootfile: /boot/kernel/kernel >>>> kern.maxfilesperproc: 11095 >>>> kern.maxprocperuid: 5547 >>>> kern.ipc.maxsockbuf: 262144 >>>> kern.ipc.sockbuf_waste_factor: 8 >>>> kern.ipc.somaxconn: 128 >>>> kern.ipc.max_linkhdr: 16 >>>> kern.ipc.max_protohdr: 60 >>>> kern.ipc.max_hdr: 76 >>>> kern.ipc.max_datalen: 92 >>>> kern.ipc.nmbjumbo16: 3200 >>>> kern.ipc.nmbjumbo9: 6400 >>>> kern.ipc.nmbjumbop: 12800 >>>> kern.ipc.nmbclusters: 25600 >>>> kern.ipc.piperesizeallowed: 1 >>>> kern.ipc.piperesizefail: 0 >>>> kern.ipc.pipeallocfail: 0 >>>> kern.ipc.pipefragretry: 0 >>>> kern.ipc.pipekva: 98304 >>>> kern.ipc.maxpipekva: 277905408 >>>> kern.ipc.msgseg: 2048 >>>> kern.ipc.msgssz: 8 >>>> kern.ipc.msgtql: 40 >>>> kern.ipc.msgmnb: 2048 >>>> kern.ipc.msgmni: 40 >>>> kern.ipc.msgmax: 16384 >>>> kern.ipc.semaem: 16384 >>>> kern.ipc.semvmx: 32767 >>>> kern.ipc.semusz: 152 >>>> kern.ipc.semume: 10 >>>> kern.ipc.semopm: 100 >>>> kern.ipc.semmsl: 60 >>>> kern.ipc.semmnu: 30 >>>> kern.ipc.semmns: 4096 >>>> kern.ipc.semmni: 2048 >>>> kern.ipc.semmap: 30 >>>> kern.ipc.shm_allow_removed: 0 >>>> kern.ipc.shm_use_phys: 0 >>>> kern.ipc.shmall: 8192000 >>>> kern.ipc.shmseg: 128 >>>> kern.ipc.shmmni: 192 >>>> kern.ipc.shmmin: 1 >>>> kern.ipc.shmmax: 819200000 >>>> kern.ipc.maxsockets: 25600 >>>> kern.ipc.numopensockets: 63 >>>> kern.ipc.nsfbufsused: 0 >>>> kern.ipc.nsfbufspeak: 0 >>>> kern.ipc.nsfbufs: 0 >>>> kern.dummy: 0 >>>> kern.ps_strings: 140737488355296 >>>> kern.usrstack: 140737488355328 >>>> kern.logsigexit: 1 >>>> kern.iov_max: 1024 >>>> kern.hostuuid: 53D19F64-D663-A017-8922-003048339480 >>>> kern.cam.cam_srch_hi: 0 >>>> kern.cam.scsi_delay: 5000 >>>> kern.cam.cd.retry_count: 4 >>>> kern.cam.cd.changer.max_busy_seconds: 15 >>>> kern.cam.cd.changer.min_busy_seconds: 5 >>>> kern.cam.cd.0.minimum_cmd_size: 10 >>>> kern.cam.da.da_send_ordered: 1 >>>> kern.cam.da.default_timeout: 60 >>>> kern.cam.da.retry_count: 4 >>>> kern.rndtest.verbose: 1 >>>> kern.rndtest.retest: 120 >>>> kern.disks: cd0 ad14 ad12 ad10 ad8 ad6 ad4 >>>> kern.geom.collectstats: 1 >>>> kern.geom.debugflags: 0 >>>> kern.geom.label.debug: 0 >>>> kern.elf64.fallback_brand: -1 >>>> kern.init_shutdown_timeout: 120 >>>> kern.init_path: >>>> /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall >>>> kern.acct_suspended: 0 >>>> kern.acct_configured: 0 >>>> kern.acct_chkfreq: 15 >>>> kern.acct_resume: 4 >>>> kern.acct_suspend: 2 >>>> kern.cp_times: 3050 257577 31202 420 9098 2948 258837 29420 2264 7280 >>>> 2800 >>>> 260523 30701 171 6615 2523 263506 27118 122 7538 >>>> kern.cp_time: 11321 1040443 118441 2977 30531 >>>> kern.constty_wakeups_per_second: 5 >>>> kern.consmsgbuf_size: 8192 >>>> kern.consmute: 0 >>>> kern.console: ttyv0,/ttyv0,uart,gdb, >>>> kern.openfiles: 220 >>>> kern.kq_calloutmax: 4096 >>>> kern.ps_arg_cache_limit: 256 >>>> kern.stackprot: 7 >>>> kern.randompid: 0 >>>> kern.lastpid: 1762 >>>> kern.ktrace.request_pool: 100 >>>> kern.ktrace.genio_size: 4096 >>>> kern.module_path: /boot/kernel;/boot/modules >>>> kern.malloc_count: 267 >>>> kern.fallback_elf_brand: -1 >>>> kern.features.compat_freebsd7: 1 >>>> kern.features.compat_freebsd6: 1 >>>> kern.features.compat_freebsd5: 1 >>>> kern.features.compat_freebsd4: 1 >>>> kern.features.posix_shm: 1 >>>> kern.maxusers: 384 >>>> kern.ident: BORG >>>> kern.kstack_pages: 4 >>>> kern.shutdown.kproc_shutdown_wait: 60 >>>> kern.shutdown.poweroff_delay: 5000 >>>> kern.sync_on_panic: 0 >>>> kern.corefile: %N.core >>>> kern.nodump_coredump: 0 >>>> kern.coredump: 1 >>>> kern.sugid_coredump: 0 >>>> kern.sigqueue.alloc_fail: 0 >>>> kern.sigqueue.overflow: 0 >>>> kern.sigqueue.preallocate: 1024 >>>> kern.sigqueue.max_pending_per_proc: 128 >>>> kern.forcesigexit: 1 >>>> kern.fscale: 2048 >>>> kern.timecounter.tick: 1 >>>> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) >>>> dummy(-1000000) >>>> kern.timecounter.hardware: ACPI-fast >>>> kern.timecounter.stepwarnings: 0 >>>> kern.timecounter.tc.i8254.mask: 65535 >>>> kern.timecounter.tc.i8254.counter: 62178 >>>> kern.timecounter.tc.i8254.frequency: 1193182 >>>> kern.timecounter.tc.i8254.quality: 0 >>>> kern.timecounter.tc.ACPI-fast.mask: 16777215 >>>> kern.timecounter.tc.ACPI-fast.counter: 3310006 >>>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>>> kern.timecounter.tc.ACPI-fast.quality: 1000 >>>> kern.timecounter.tc.HPET.mask: 4294967295 >>>> kern.timecounter.tc.HPET.counter: 2523974339 >>>> kern.timecounter.tc.HPET.frequency: 14318180 >>>> kern.timecounter.tc.HPET.quality: 900 >>>> kern.timecounter.tc.TSC.mask: 4294967295 >>>> kern.timecounter.tc.TSC.counter: 1218885212 >>>> kern.timecounter.tc.TSC.frequency: 1862013503 >>>> kern.timecounter.tc.TSC.quality: -100 >>>> kern.timecounter.smp_tsc: 0 >>>> kern.timecounter.invariant_tsc: 1 >>>> kern.threads.max_threads_hits: 0 >>>> kern.threads.max_threads_per_proc: 1500 >>>> kern.ccpu: 0 >>>> kern.sched.preemption: 1 >>>> kern.sched.topology_spec: >>>>   >>>>  0, 1, 2, 3 >>>>   >>>>   >>>>   >>>>   0, 1 >>>>   >>>>   >>>>   >>>>   2, 3 >>>>   >>>>   >>>>   >>>>   >>>> >>>> >>>> kern.sched.steal_thresh: 2 >>>> kern.sched.steal_idle: 1 >>>> kern.sched.steal_htt: 1 >>>> kern.sched.balance_interval: 133 >>>> kern.sched.balance: 1 >>>> kern.sched.affinity: 1 >>>> kern.sched.idlespinthresh: 4 >>>> kern.sched.idlespins: 10000 >>>> kern.sched.static_boost: 160 >>>> kern.sched.preempt_thresh: 64 >>>> kern.sched.interact: 30 >>>> kern.sched.slice: 13 >>>> kern.sched.name: ULE >>>> kern.devstat.version: 6 >>>> kern.devstat.generation: 225 >>>> kern.devstat.numdevs: 9 >>>> kern.kobj_methodcount: 155 >>>> kern.log_wakeups_per_second: 5 >>>> kern.vm_guest: none >>>> kern.sgrowsiz: 131072 >>>> kern.maxssiz: 536870912 >>>> kern.dflssiz: 8388608 >>>> kern.maxdsiz: 34359738368 >>>> kern.dfldsiz: 134217728 >>>> kern.maxtsiz: 134217728 >>>> kern.maxbcache: 1073741824 >>>> kern.maxswzone: 33554432 >>>> kern.nswbuf: 256 >>>> kern.nbuf: 65536 >>>> kern.ncallout: 18508 >>>> kern.hz: 1000 >>>> kern.msgbuf_clear: 0 >>>> kern.msgbuf: kern.always_console_output: 0 >>>> kern.log_console_output: 1 >>>> kern.smp.forward_roundrobin_enabled: 1 >>>> kern.smp.forward_signal_enabled: 1 >>>> kern.smp.topology: 0 >>>> kern.smp.cpus: 4 >>>> kern.smp.disabled: 0 >>>> kern.smp.active: 1 >>>> kern.smp.maxcpus: 32 >>>> kern.smp.maxid: 3 >>>> kern.tty_inq_nslow: 297 >>>> kern.tty_inq_nfast: 1701 >>>> kern.tty_outq_nslow: 0 >>>> kern.tty_outq_nfast: 0 >>>> kern.pts_maxdev: 999 >>>> kern.tty_pty_warningcnt: 10 >>>> kern.tty_nout: 4730961 >>>> kern.tty_nin: 2138 >>>> kern.minvnodes: 25000 >>>> kern.metadelay: 28 >>>> kern.dirdelay: 29 >>>> kern.filedelay: 30 >>>> kern.chroot_allow_open_directories: 1 >>>> kern.cryptodevallowsoft: 0 >>>> kern.userasymcrypto: 1 >>>> kern.rpc.invalid: 0 >>>> kern.rpc.unexpected: 0 >>>> kern.rpc.timeouts: 0 >>>> kern.rpc.request: 0 >>>> kern.rpc.retries: 0 >>>> kern.elf32.fallback_brand: -1 >>>> kern.random.yarrow.gengateinterval: 10 >>>> kern.random.yarrow.bins: 10 >>>> kern.random.yarrow.fastthresh: 192 >>>> kern.random.yarrow.slowthresh: 256 >>>> kern.random.yarrow.slowoverthresh: 2 >>>> kern.random.sys.seeded: 1 >>>> kern.random.sys.harvest.ethernet: 1 >>>> kern.random.sys.harvest.point_to_point: 1 >>>> kern.random.sys.harvest.interrupt: 1 >>>> kern.random.sys.harvest.swi: 0 >>>> vm.vmtotal: System wide totals computed every five seconds: (values in >>>> kilobytes) >>>> =============================================== >>>> Processes:              (RUNQ: 5 Disk Wait: 0 Page Wait: 0 Sleep: 73) >>>> Virtual Memory:         (Total: 1076206992K, Active 2349180K) >>>> Real Memory:            (Total: 1103632K Active 455252K) >>>> Shared Virtual Memory:  (Total: 20708K Active: 14128K) >>>> Shared Real Memory:     (Total: 9388K Active: 8756K) >>>> Free Memory Pages:      2017432K >>>> >>>> vm.loadavg: { 5.08 6.77 6.36 } >>>> vm.v_free_min: 25703 >>>> vm.v_free_target: 108162 >>>> vm.v_free_reserved: 5350 >>>> vm.v_inactive_target: 162243 >>>> vm.v_cache_min: 108162 >>>> vm.v_cache_max: 216324 >>>> vm.v_pageout_free_min: 34 >>>> vm.pageout_algorithm: 0 >>>> vm.swap_enabled: 1 >>>> vm.kmem_size_scale: 3 >>>> vm.kmem_size_max: 329853485875 >>>> vm.kmem_size_min: 0 >>>> vm.kmem_size: 5558173696 >>>> vm.nswapdev: 1 >>>> vm.dmmax: 32 >>>> vm.swap_async_max: 4 >>>> vm.zone_count: 98 >>>> vm.swap_idle_threshold2: 10 >>>> vm.swap_idle_threshold1: 2 >>>> vm.exec_map_entries: 16 >>>> vm.stats.misc.zero_page_count: 59 >>>> vm.stats.misc.cnt_prezero: 0 >>>> vm.stats.vm.v_kthreadpages: 0 >>>> vm.stats.vm.v_rforkpages: 2236 >>>> vm.stats.vm.v_vforkpages: 39693 >>>> vm.stats.vm.v_forkpages: 363901 >>>> vm.stats.vm.v_kthreads: 141 >>>> vm.stats.vm.v_rforks: 28 >>>> vm.stats.vm.v_vforks: 198 >>>> vm.stats.vm.v_forks: 1395 >>>> vm.stats.vm.v_interrupt_free_min: 2 >>>> vm.stats.vm.v_pageout_free_min: 34 >>>> vm.stats.vm.v_cache_max: 216324 >>>> vm.stats.vm.v_cache_min: 108162 >>>> vm.stats.vm.v_cache_count: 123 >>>> vm.stats.vm.v_inactive_count: 1005 >>>> vm.stats.vm.v_inactive_target: 162243 >>>> vm.stats.vm.v_active_count: 112687 >>>> vm.stats.vm.v_wire_count: 3452797 >>>> vm.stats.vm.v_free_count: 504231 >>>> vm.stats.vm.v_free_min: 25703 >>>> vm.stats.vm.v_free_target: 108162 >>>> vm.stats.vm.v_free_reserved: 5350 >>>> vm.stats.vm.v_page_count: 4070929 >>>> vm.stats.vm.v_page_size: 4096 >>>> vm.stats.vm.v_tfree: 19085156 >>>> vm.stats.vm.v_pfree: 612782 >>>> vm.stats.vm.v_dfree: 0 >>>> vm.stats.vm.v_tcached: 3100 >>>> vm.stats.vm.v_pdpages: 0 >>>> vm.stats.vm.v_pdwakeups: 0 >>>> vm.stats.vm.v_reactivated: 2925 >>>> vm.stats.vm.v_intrans: 704 >>>> vm.stats.vm.v_vnodepgsout: 1 >>>> vm.stats.vm.v_vnodepgsin: 6890 >>>> vm.stats.vm.v_vnodeout: 1 >>>> vm.stats.vm.v_vnodein: 5806 >>>> vm.stats.vm.v_swappgsout: 0 >>>> vm.stats.vm.v_swappgsin: 0 >>>> vm.stats.vm.v_swapout: 0 >>>> vm.stats.vm.v_swapin: 0 >>>> vm.stats.vm.v_ozfod: 27 >>>> vm.stats.vm.v_zfod: 2565409 >>>> vm.stats.vm.v_cow_optim: 397 >>>> vm.stats.vm.v_cow_faults: 64414 >>>> vm.stats.vm.v_vm_faults: 2768133 >>>> vm.stats.sys.v_soft: 1359531 >>>> vm.stats.sys.v_intr: 715196 >>>> vm.stats.sys.v_syscall: 6458471 >>>> vm.stats.sys.v_trap: 6074556 >>>> vm.stats.sys.v_swtch: 8393310 >>>> vm.stats.object.bypasses: 757 >>>> vm.stats.object.collapses: 5656 >>>> vm.v_free_severe: 15526 >>>> vm.max_proc_mmap: 496265 >>>> vm.old_msync: 0 >>>> vm.msync_flush_flags: 3 >>>> vm.boot_pages: 48 >>>> vm.max_wired: 1345352 >>>> vm.pageout_lock_miss: 0 >>>> vm.disable_swapspace_pageouts: 0 >>>> vm.defer_swapspace_pageouts: 0 >>>> vm.swap_idle_enabled: 0 >>>> vm.pageout_stats_interval: 5 >>>> vm.pageout_full_stats_interval: 20 >>>> vm.pageout_stats_max: 108162 >>>> vm.max_launder: 32 >>>> vm.phys_segs: SEGMENT 0: >>>> >>>> start:     0x1000 >>>> end:       0x98000 >>>> free list: 0xffffffff80849668 >>>> >>>> SEGMENT 1: >>>> >>>> start:     0xb8a000 >>>> end:       0x1000000 >>>> free list: 0xffffffff80849668 >>>> >>>> SEGMENT 2: >>>> >>>> start:     0x1000000 >>>> end:       0xcff50000 >>>> free list: 0xffffffff808492c0 >>>> >>>> SEGMENT 3: >>>> >>>> start:     0x100000000 >>>> end:       0x4129b4000 >>>> free list: 0xffffffff808492c0 >>>> >>>> vm.phys_free: FREE LIST 0: >>>> >>>>  ORDER (SIZE)  |  NUMBER >>>>               |  POOL 0  |  POOL 1  |  POOL 2 >>>> --            -- --      -- --      -- --      -- >>>>  12 ( 16384K)  |      91  |       0  |       0 >>>>  11 (  8192K)  |       3  |       1  |       0 >>>>  10 (  4096K)  |       7  |       1  |       0 >>>>  9 (  2048K)  |       0  |       1  |       0 >>>>  8 (  1024K)  |       4  |       1  |       0 >>>>  7 (   512K)  |      10  |       0  |       0 >>>>  6 (   256K)  |       7  |       0  |       0 >>>>  5 (   128K)  |      11  |       0  |       0 >>>>  4 (    64K)  |      32  |       0  |       0 >>>>  3 (    32K)  |     246  |       0  |       0 >>>>  2 (    16K)  |     929  |       3  |       1 >>>>  1 (     8K)  |    1849  |       1  |       7 >>>>  0 (     4K)  |    9492  |       0  |      73 >>>> >>>> FREE LIST 1: >>>> >>>>  ORDER (SIZE)  |  NUMBER >>>>               |  POOL 0  |  POOL 1  |  POOL 2 >>>> --            -- --      -- --      -- --      -- >>>>  12 ( 16384K)  |       0  |       0  |       0 >>>>  11 (  8192K)  |       0  |       0  |       0 >>>>  10 (  4096K)  |       1  |       0  |       0 >>>>  9 (  2048K)  |       0  |       0  |       0 >>>>  8 (  1024K)  |       0  |       0  |       0 >>>>  7 (   512K)  |       0  |       0  |       0 >>>>  6 (   256K)  |       2  |       0  |       0 >>>>  5 (   128K)  |       2  |       0  |       0 >>>>  4 (    64K)  |       2  |       0  |       0 >>>>  3 (    32K)  |       2  |       0  |       0 >>>>  2 (    16K)  |       2  |       0  |       0 >>>>  1 (     8K)  |       3  |       0  |       0 >>>>  0 (     4K)  |       0  |       0  |       0 >>>> >>>> vm.reserv.reclaimed: 0 >>>> vm.reserv.partpopq: LEVEL     SIZE  NUMBER >>>> >>>>  -1: 362368K,    326 >>>> >>>> vm.reserv.freed: 11598 >>>> vm.reserv.broken: 8 >>>> vm.idlezero_enable: 0 >>>> vm.kvm_free: 542615007232 >>>> vm.kvm_size: 549755809792 >>>> vm.pmap.pmap_collect_active: 0 >>>> vm.pmap.pmap_collect_inactive: 0 >>>> vm.pmap.pv_entry_spare: 8566 >>>> vm.pmap.pv_entry_allocs: 3744878 >>>> vm.pmap.pv_entry_frees: 3679188 >>>> vm.pmap.pc_chunk_tryfail: 0 >>>> vm.pmap.pc_chunk_frees: 13290 >>>> vm.pmap.pc_chunk_allocs: 13732 >>>> vm.pmap.pc_chunk_count: 442 >>>> vm.pmap.pv_entry_count: 65690 >>>> vm.pmap.pdpe.demotions: 0 >>>> vm.pmap.pde.promotions: 110851 >>>> vm.pmap.pde.p_failures: 1022233 >>>> vm.pmap.pde.mappings: 0 >>>> vm.pmap.pde.demotions: 107618 >>>> vm.pmap.shpgperproc: 200 >>>> vm.pmap.pv_entry_max: 5303729 >>>> vm.pmap.pg_ps_enabled: 1 >>>> vfs.zfs.arc_meta_limit: 4023481344 >>>> vfs.zfs.arc_meta_used: 1192541184 >>>> vfs.zfs.mdcomp_disable: 0 >>>> vfs.zfs.arc_min: 2011740672 >>>> vfs.zfs.arc_max: 16093925376 >>>> vfs.zfs.zfetch.array_rd_sz: 1048576 >>>> vfs.zfs.zfetch.block_cap: 256 >>>> vfs.zfs.zfetch.min_sec_reap: 2 >>>> vfs.zfs.zfetch.max_streams: 8 >>>> vfs.zfs.prefetch_disable: 0 >>>> vfs.zfs.recover: 0 >>>> vfs.zfs.txg.synctime: 5 >>>> vfs.zfs.txg.timeout: 30 >>>> vfs.zfs.scrub_limit: 10 >>>> vfs.zfs.vdev.cache.bshift: 16 >>>> vfs.zfs.vdev.cache.size: 10485760 >>>> vfs.zfs.vdev.cache.max: 16384 >>>> vfs.zfs.vdev.aggregation_limit: 131072 >>>> vfs.zfs.vdev.ramp_rate: 2 >>>> vfs.zfs.vdev.time_shift: 6 >>>> vfs.zfs.vdev.min_pending: 4 >>>> vfs.zfs.vdev.max_pending: 35 >>>> vfs.zfs.cache_flush_disable: 0 >>>> vfs.zfs.zil_disable: 0 >>>> vfs.zfs.version.zpl: 3 >>>> vfs.zfs.version.vdev_boot: 1 >>>> vfs.zfs.version.spa: 13 >>>> vfs.zfs.version.dmu_backup_stream: 1 >>>> vfs.zfs.version.dmu_backup_header: 2 >>>> vfs.zfs.version.acl: 1 >>>> vfs.zfs.debug: 0 >>>> vfs.zfs.super_owner: 1 >>>> vfs.ufs.dirhash_docheck: 0 >>>> vfs.ufs.dirhash_mem: 39648 >>>> vfs.ufs.dirhash_maxmem: 2097152 >>>> vfs.ufs.dirhash_minsize: 2560 >>>> vfs.devfs.rule_depth: 1 >>>> vfs.devfs.generation: 139 >>>> vfs.nfs4.access_cache_timeout: 60 >>>> vfs.nfs.downdelayinitial: 12 >>>> vfs.nfs.downdelayinterval: 30 >>>> vfs.nfs.skip_wcc_data_onerr: 1 >>>> vfs.nfs.nfs3_jukebox_delay: 10 >>>> vfs.nfs.reconnects: 0 >>>> vfs.nfs.bufpackets: 4 >>>> vfs.nfs.realign_count: 0 >>>> vfs.nfs.realign_test: 0 >>>> vfs.nfs.defect: 0 >>>> vfs.nfs.iodmax: 20 >>>> vfs.nfs.iodmin: 0 >>>> vfs.nfs.iodmaxidle: 120 >>>> vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 >>>> vfs.nfs.nfs_ip_paranoia: 1 >>>> vfs.nfs.nfs_directio_allow_mmap: 1 >>>> vfs.nfs.nfs_directio_enable: 0 >>>> vfs.nfs.clean_pages_on_close: 1 >>>> vfs.nfs.nfsv3_commit_on_close: 0 >>>> vfs.nfs.prime_access_cache: 0 >>>> vfs.nfs.access_cache_timeout: 60 >>>> vfs.pfs.trace: 0 >>>> vfs.pfs.vncache.misses: 0 >>>> vfs.pfs.vncache.hits: 0 >>>> vfs.pfs.vncache.maxentries: 0 >>>> vfs.pfs.vncache.entries: 0 >>>> vfs.flushwithdeps: 0 >>>> vfs.notbufdflashes: 0 >>>> vfs.flushbufqtarget: 100 >>>> vfs.getnewbufrestarts: 0 >>>> vfs.getnewbufcalls: 28204 >>>> vfs.hifreebuffers: 7290 >>>> vfs.lofreebuffers: 3645 >>>> vfs.numfreebuffers: 65534 >>>> vfs.dirtybufthresh: 14763 >>>> vfs.hidirtybuffers: 16404 >>>> vfs.lodirtybuffers: 8202 >>>> vfs.numdirtybuffers: 2 >>>> vfs.recursiveflushes: 0 >>>> vfs.altbufferflushes: 0 >>>> vfs.bdwriteskip: 0 >>>> vfs.dirtybufferflushes: 0 >>>> vfs.hirunningspace: 1048576 >>>> vfs.lorunningspace: 524288 >>>> vfs.bufdefragcnt: 0 >>>> vfs.buffreekvacnt: 0 >>>> vfs.bufreusecnt: 28198 >>>> vfs.hibufspace: 1073086464 >>>> vfs.lobufspace: 1073020928 >>>> vfs.maxmallocbufspace: 53654323 >>>> vfs.bufmallocspace: 0 >>>> vfs.maxbufspace: 1073741824 >>>> vfs.bufspace: 461996032 >>>> vfs.runningbufspace: 0 >>>> vfs.vmiodirenable: 1 >>>> vfs.cache.numfullpathfound: 124 >>>> vfs.cache.numfullpathfail4: 0 >>>> vfs.cache.numfullpathfail2: 0 >>>> vfs.cache.numfullpathfail1: 0 >>>> vfs.cache.numfullpathcalls: 124 >>>> vfs.cache.nchstats: 4488983 27354 228 0 466972 0 33 156 >>>> vfs.cache.numupgrades: 28 >>>> vfs.cache.numneghits: 27354 >>>> vfs.cache.numnegzaps: 57 >>>> vfs.cache.numposhits: 4488983 >>>> vfs.cache.numposzaps: 171 >>>> vfs.cache.nummisszap: 309 >>>> vfs.cache.nummiss: 466663 >>>> vfs.cache.numchecks: 5829112 >>>> vfs.cache.dotdothits: 47 >>>> vfs.cache.dothits: 1035 >>>> vfs.cache.numcalls: 4984636 >>>> vfs.cache.numcache: 30787 >>>> vfs.cache.numneg: 766 >>>> vfs.read_max: 8 >>>> vfs.write_behind: 1 >>>> vfs.lookup_shared: 1 >>>> vfs.usermount: 1 >>>> vfs.worklist_len: 1 >>>> vfs.timestamp_precision: 0 >>>> vfs.reassignbufcalls: 611 >>>> vfs.freevnodes: 24986 >>>> vfs.wantfreevnodes: 25000 >>>> vfs.numvnodes: 29998 >>>> vfs.nfsrv.nfs_privport: 0 >>>> vfs.nfsrv.fha.bin_shift: 18 >>>> vfs.nfsrv.fha.max_nfsds_per_fh: 8 >>>> vfs.nfsrv.fha.max_reqs_per_nfsd: 4 >>>> vfs.nfsrv.fha.fhe_stats: No file handle entries. >>>> vfs.nfsrv.commit_miss: 0 >>>> vfs.nfsrv.commit_blks: 0 >>>> vfs.nfsrv.async: 0 >>>> vfs.nfsrv.realign_count: 0 >>>> vfs.nfsrv.realign_test: 0 >>>> vfs.nfsrv.gatherdelay_v3: 0 >>>> vfs.nfsrv.gatherdelay: 10000 >>>> vfs.nfsrv.minthreads: 4 >>>> vfs.nfsrv.maxthreads: 4 >>>> vfs.nfsrv.threads: 4 >>>> vfs.nfsrv.request_space_used: 0 >>>> vfs.nfsrv.request_space_used_highest: 0 >>>> vfs.nfsrv.request_space_high: 13107200 >>>> vfs.nfsrv.request_space_low: 8738133 >>>> vfs.nfsrv.request_space_throttled: 0 >>>> vfs.nfsrv.request_space_throttle_count: 0 >>>> vfs.ffs.doreallocblks: 1 >>>> vfs.ffs.doasyncfree: 1 >>>> vfs.ffs.compute_summary_at_mount: 0 >>>> net.local.stream.recvspace: 8192 >>>> net.local.stream.sendspace: 8192 >>>> net.local.dgram.recvspace: 4096 >>>> net.local.dgram.maxdgram: 2048 >>>> net.local.taskcount: 0 >>>> net.local.recycled: 0 >>>> net.local.inflight: 0 >>>> net.inet.ip.portrange.randomtime: 45 >>>> net.inet.ip.portrange.randomcps: 10 >>>> net.inet.ip.portrange.randomized: 1 >>>> net.inet.ip.portrange.reservedlow: 0 >>>> net.inet.ip.portrange.reservedhigh: 1023 >>>> net.inet.ip.portrange.hilast: 65535 >>>> net.inet.ip.portrange.hifirst: 49152 >>>> net.inet.ip.portrange.last: 65535 >>>> net.inet.ip.portrange.first: 10000 >>>> net.inet.ip.portrange.lowlast: 600 >>>> net.inet.ip.portrange.lowfirst: 1023 >>>> net.inet.ip.forwarding: 0 >>>> net.inet.ip.redirect: 1 >>>> net.inet.ip.ttl: 64 >>>> net.inet.ip.rtexpire: 3600 >>>> net.inet.ip.rtminexpire: 10 >>>> net.inet.ip.rtmaxcache: 128 >>>> net.inet.ip.sourceroute: 0 >>>> net.inet.ip.intr_queue_maxlen: 50 >>>> net.inet.ip.intr_queue_drops: 0 >>>> net.inet.ip.accept_sourceroute: 0 >>>> net.inet.ip.keepfaith: 0 >>>> net.inet.ip.gifttl: 30 >>>> net.inet.ip.same_prefix_carp_only: 0 >>>> net.inet.ip.subnets_are_local: 0 >>>> net.inet.ip.random_id_total: 0 >>>> net.inet.ip.random_id_collisions: 0 >>>> net.inet.ip.random_id_period: 8192 >>>> net.inet.ip.mcast.loop: 1 >>>> net.inet.ip.mcast.maxsocksrc: 128 >>>> net.inet.ip.mcast.maxgrpsrc: 512 >>>> net.inet.ip.fastforwarding: 0 >>>> net.inet.ip.maxfragpackets: 800 >>>> net.inet.ip.output_flowtable_size: 0 >>>> net.inet.ip.maxfragsperpacket: 16 >>>> net.inet.ip.fragpackets: 0 >>>> net.inet.ip.check_interface: 0 >>>> net.inet.ip.random_id: 0 >>>> net.inet.ip.sendsourcequench: 0 >>>> net.inet.ip.process_options: 1 >>>> net.inet.icmp.maskrepl: 0 >>>> net.inet.icmp.icmplim: 200 >>>> net.inet.icmp.bmcastecho: 0 >>>> net.inet.icmp.quotelen: 8 >>>> net.inet.icmp.reply_from_interface: 0 >>>> net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 >>>> net.inet.icmp.log_redirect: 0 >>>> net.inet.icmp.drop_redirect: 0 >>>> net.inet.icmp.maskfake: 0 >>>> net.inet.igmp.gsrdelay: 10 >>>> net.inet.igmp.default_version: 3 >>>> net.inet.igmp.legacysupp: 0 >>>> net.inet.igmp.v2enable: 1 >>>> net.inet.igmp.v1enable: 1 >>>> net.inet.igmp.sendlocal: 1 >>>> net.inet.igmp.sendra: 1 >>>> net.inet.igmp.recvifkludge: 1 >>>> net.inet.tcp.rfc1323: 1 >>>> net.inet.tcp.mssdflt: 512 >>>> net.inet.tcp.keepidle: 7200000 >>>> net.inet.tcp.keepintvl: 75000 >>>> net.inet.tcp.sendspace: 32768 >>>> net.inet.tcp.recvspace: 65536 >>>> net.inet.tcp.keepinit: 75000 >>>> net.inet.tcp.delacktime: 100 >>>> net.inet.tcp.v6mssdflt: 1024 >>>> net.inet.tcp.hostcache.purge: 0 >>>> net.inet.tcp.hostcache.prune: 300 >>>> net.inet.tcp.hostcache.expire: 3600 >>>> net.inet.tcp.hostcache.count: 3 >>>> net.inet.tcp.hostcache.bucketlimit: 30 >>>> net.inet.tcp.hostcache.hashsize: 512 >>>> net.inet.tcp.hostcache.cachelimit: 15360 >>>> net.inet.tcp.wlock_looped: 0 >>>> net.inet.tcp.wlock_relocked: 0 >>>> net.inet.tcp.wlock_upgraded: 262 >>>> net.inet.tcp.tcp_wlock_atfirst: 416 >>>> net.inet.tcp.rlock_atfirst: 829900 >>>> net.inet.tcp.read_locking: 1 >>>> net.inet.tcp.recvbuf_max: 262144 >>>> net.inet.tcp.recvbuf_inc: 16384 >>>> net.inet.tcp.recvbuf_auto: 1 >>>> net.inet.tcp.insecure_rst: 0 >>>> net.inet.tcp.ecn.maxretries: 1 >>>> net.inet.tcp.ecn.enable: 0 >>>> net.inet.tcp.abc_l_var: 2 >>>> net.inet.tcp.rfc3465: 1 >>>> net.inet.tcp.rfc3390: 1 >>>> net.inet.tcp.rfc3042: 1 >>>> net.inet.tcp.drop_synfin: 0 >>>> net.inet.tcp.delayed_ack: 1 >>>> net.inet.tcp.blackhole: 0 >>>> net.inet.tcp.log_in_vain: 0 >>>> net.inet.tcp.sendbuf_max: 262144 >>>> net.inet.tcp.sendbuf_inc: 8192 >>>> net.inet.tcp.sendbuf_auto: 1 >>>> net.inet.tcp.tso: 1 >>>> net.inet.tcp.newreno: 1 >>>> net.inet.tcp.local_slowstart_flightsize: 4 >>>> net.inet.tcp.slowstart_flightsize: 1 >>>> net.inet.tcp.path_mtu_discovery: 1 >>>> net.inet.tcp.reass.overflows: 0 >>>> net.inet.tcp.reass.maxqlen: 48 >>>> net.inet.tcp.reass.cursegments: 0 >>>> net.inet.tcp.reass.maxsegments: 1600 >>>> net.inet.tcp.sack.globalholes: 0 >>>> net.inet.tcp.sack.globalmaxholes: 65536 >>>> net.inet.tcp.sack.maxholes: 128 >>>> net.inet.tcp.sack.enable: 1 >>>> net.inet.tcp.inflight.stab: 20 >>>> net.inet.tcp.inflight.max: 1073725440 >>>> net.inet.tcp.inflight.min: 6144 >>>> net.inet.tcp.inflight.rttthresh: 10 >>>> net.inet.tcp.inflight.debug: 0 >>>> net.inet.tcp.inflight.enable: 1 >>>> net.inet.tcp.isn_reseed_interval: 0 >>>> net.inet.tcp.icmp_may_rst: 1 >>>> net.inet.tcp.pcbcount: 26 >>>> net.inet.tcp.do_tcpdrain: 1 >>>> net.inet.tcp.tcbhashsize: 512 >>>> net.inet.tcp.log_debug: 0 >>>> net.inet.tcp.minmss: 216 >>>> net.inet.tcp.syncache.rst_on_sock_fail: 1 >>>> net.inet.tcp.syncache.rexmtlimit: 3 >>>> net.inet.tcp.syncache.hashsize: 512 >>>> net.inet.tcp.syncache.count: 0 >>>> net.inet.tcp.syncache.cachelimit: 15360 >>>> net.inet.tcp.syncache.bucketlimit: 30 >>>> net.inet.tcp.syncookies_only: 0 >>>> net.inet.tcp.syncookies: 1 >>>> net.inet.tcp.timer_race: 0 >>>> net.inet.tcp.finwait2_timeout: 60000 >>>> net.inet.tcp.fast_finwait2_recycle: 0 >>>> net.inet.tcp.always_keepalive: 1 >>>> net.inet.tcp.rexmit_slop: 200 >>>> net.inet.tcp.rexmit_min: 30 >>>> net.inet.tcp.msl: 30000 >>>> net.inet.tcp.nolocaltimewait: 0 >>>> net.inet.tcp.maxtcptw: 5120 >>>> net.inet.udp.checksum: 1 >>>> net.inet.udp.maxdgram: 9216 >>>> net.inet.udp.recvspace: 42080 >>>> net.inet.udp.blackhole: 0 >>>> net.inet.udp.log_in_vain: 0 >>>> net.inet.sctp.nat_friendly_init: 1 >>>> net.inet.sctp.enable_sack_immediately: 0 >>>> net.inet.sctp.udp_tunneling_port: 0 >>>> net.inet.sctp.udp_tunneling_for_client_enable: 0 >>>> net.inet.sctp.mobility_fasthandoff: 0 >>>> net.inet.sctp.mobility_base: 0 >>>> net.inet.sctp.default_frag_interleave: 1 >>>> net.inet.sctp.default_cc_module: 0 >>>> net.inet.sctp.log_level: 0 >>>> net.inet.sctp.max_retran_chunk: 30 >>>> net.inet.sctp.min_residual: 1452 >>>> net.inet.sctp.strict_data_order: 0 >>>> net.inet.sctp.abort_at_limit: 0 >>>> net.inet.sctp.hb_max_burst: 4 >>>> net.inet.sctp.do_sctp_drain: 1 >>>> net.inet.sctp.max_chained_mbufs: 5 >>>> net.inet.sctp.abc_l_var: 1 >>>> net.inet.sctp.nat_friendly: 1 >>>> net.inet.sctp.auth_disable: 0 >>>> net.inet.sctp.asconf_auth_nochk: 0 >>>> net.inet.sctp.early_fast_retran_msec: 250 >>>> net.inet.sctp.early_fast_retran: 0 >>>> net.inet.sctp.cwnd_maxburst: 1 >>>> net.inet.sctp.cmt_pf: 0 >>>> net.inet.sctp.cmt_use_dac: 0 >>>> net.inet.sctp.nr_sack_on_off: 0 >>>> net.inet.sctp.cmt_on_off: 0 >>>> net.inet.sctp.outgoing_streams: 10 >>>> net.inet.sctp.add_more_on_output: 1452 >>>> net.inet.sctp.path_rtx_max: 5 >>>> net.inet.sctp.assoc_rtx_max: 10 >>>> net.inet.sctp.init_rtx_max: 8 >>>> net.inet.sctp.valid_cookie_life: 60000 >>>> net.inet.sctp.init_rto_max: 60000 >>>> net.inet.sctp.rto_initial: 3000 >>>> net.inet.sctp.rto_min: 1000 >>>> net.inet.sctp.rto_max: 60000 >>>> net.inet.sctp.secret_lifetime: 3600 >>>> net.inet.sctp.shutdown_guard_time: 180 >>>> net.inet.sctp.pmtu_raise_time: 600 >>>> net.inet.sctp.heartbeat_interval: 30000 >>>> net.inet.sctp.asoc_resource: 10 >>>> net.inet.sctp.sys_resource: 1000 >>>> net.inet.sctp.sack_freq: 2 >>>> net.inet.sctp.delayed_sack_time: 200 >>>> net.inet.sctp.chunkscale: 10 >>>> net.inet.sctp.min_split_point: 2904 >>>> net.inet.sctp.pcbhashsize: 256 >>>> net.inet.sctp.tcbhashsize: 1024 >>>> net.inet.sctp.maxchunks: 3200 >>>> net.inet.sctp.maxburst: 4 >>>> net.inet.sctp.peer_chkoh: 256 >>>> net.inet.sctp.strict_init: 1 >>>> net.inet.sctp.loopback_nocsum: 1 >>>> net.inet.sctp.strict_sacks: 1 >>>> net.inet.sctp.ecn_nonce: 0 >>>> net.inet.sctp.ecn_enable: 1 >>>> net.inet.sctp.auto_asconf: 1 >>>> net.inet.sctp.recvspace: 233016 >>>> net.inet.sctp.sendspace: 233016 >>>> net.inet.raw.recvspace: 9216 >>>> net.inet.raw.maxdgram: 9216 >>>> net.inet.accf.unloadable: 0 >>>> net.inet.flowtable.nmbflows: 4096 >>>> net.inet.flowtable.tcp_expire: 86400 >>>> net.inet.flowtable.fin_wait_expire: 600 >>>> net.inet.flowtable.udp_expire: 300 >>>> net.inet.flowtable.syn_expire: 300 >>>> net.inet.flowtable.collisions: 0 >>>> net.inet.flowtable.max_depth: 0 >>>> net.inet.flowtable.free_checks: 0 >>>> net.inet.flowtable.frees: 0 >>>> net.inet.flowtable.misses: 0 >>>> net.inet.flowtable.lookups: 0 >>>> net.inet.flowtable.hits: 0 >>>> net.inet.flowtable.enable: 0 >>>> net.link.generic.system.ifcount: 3 >>>> net.link.ether.inet.log_arp_permanent_modify: 1 >>>> net.link.ether.inet.log_arp_movements: 1 >>>> net.link.ether.inet.log_arp_wrong_iface: 1 >>>> net.link.ether.inet.proxyall: 0 >>>> net.link.ether.inet.useloopback: 1 >>>> net.link.ether.inet.maxtries: 5 >>>> net.link.ether.inet.max_age: 1200 >>>> net.link.ether.ipfw: 0 >>>> net.link.gif.parallel_tunnels: 0 >>>> net.link.gif.max_nesting: 1 >>>> net.link.log_link_state_change: 1 >>>> net.link.tun.devfs_cloning: 1 >>>> net.inet6.ip6.forwarding: 0 >>>> net.inet6.ip6.redirect: 1 >>>> net.inet6.ip6.hlim: 64 >>>> net.inet6.ip6.maxfragpackets: 6400 >>>> net.inet6.ip6.accept_rtadv: 0 >>>> net.inet6.ip6.keepfaith: 0 >>>> net.inet6.ip6.log_interval: 5 >>>> net.inet6.ip6.hdrnestlimit: 15 >>>> net.inet6.ip6.dad_count: 1 >>>> net.inet6.ip6.auto_flowlabel: 1 >>>> net.inet6.ip6.defmcasthlim: 1 >>>> net.inet6.ip6.gifhlim: 30 >>>> net.inet6.ip6.kame_version: FreeBSD >>>> net.inet6.ip6.use_deprecated: 1 >>>> net.inet6.ip6.rr_prune: 5 >>>> net.inet6.ip6.v6only: 1 >>>> net.inet6.ip6.rtexpire: 3600 >>>> net.inet6.ip6.rtminexpire: 10 >>>> net.inet6.ip6.rtmaxcache: 128 >>>> net.inet6.ip6.use_tempaddr: 0 >>>> net.inet6.ip6.temppltime: 86400 >>>> net.inet6.ip6.tempvltime: 604800 >>>> net.inet6.ip6.auto_linklocal: 0 >>>> net.inet6.ip6.prefer_tempaddr: 0 >>>> net.inet6.ip6.use_defaultzone: 0 >>>> net.inet6.ip6.maxfrags: 6400 >>>> net.inet6.ip6.mcast_pmtu: 0 >>>> net.inet6.ip6.mcast.loop: 1 >>>> net.inet6.ip6.mcast.maxsocksrc: 128 >>>> net.inet6.ip6.mcast.maxgrpsrc: 512 >>>> net.inet6.icmp6.rediraccept: 1 >>>> net.inet6.icmp6.redirtimeout: 600 >>>> net.inet6.icmp6.nd6_prune: 1 >>>> net.inet6.icmp6.nd6_delay: 5 >>>> net.inet6.icmp6.nd6_umaxtries: 3 >>>> net.inet6.icmp6.nd6_mmaxtries: 3 >>>> net.inet6.icmp6.nd6_useloopback: 1 >>>> net.inet6.icmp6.nodeinfo: 3 >>>> net.inet6.icmp6.errppslimit: 100 >>>> net.inet6.icmp6.nd6_maxnudhint: 0 >>>> net.inet6.icmp6.nd6_debug: 0 >>>> net.inet6.icmp6.nd6_maxqueuelen: 1 >>>> net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 >>>> net.inet6.mld.gsrdelay: 10 >>>> net.bpf.zerocopy_enable: 0 >>>> net.bpf.maxinsns: 512 >>>> net.bpf.maxbufsize: 524288 >>>> net.bpf.bufsize: 4096 >>>> net.isr.swi_count: 419599 >>>> net.isr.drop: 0 >>>> net.isr.queued: 830117 >>>> net.isr.deferred: 0 >>>> net.isr.directed: 3109 >>>> net.isr.count: 3109 >>>> net.isr.direct: 1 >>>> net.raw.recvspace: 8192 >>>> net.raw.sendspace: 8192 >>>> net.my_fibnum: 0 >>>> net.add_addr_allfibs: 1 >>>> net.fibs: 1 >>>> net.route.netisr_maxqlen: 256 >>>> debug.ddb.capture.bufsize: 49152 >>>> debug.ddb.capture.inprogress: 0 >>>> debug.ddb.capture.maxbufsize: 5242880 >>>> debug.ddb.capture.bufoff: 0 >>>> debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: >>>> debug.ddb.textdump.do_version: 1 >>>> debug.ddb.textdump.do_panic: 1 >>>> debug.ddb.textdump.do_msgbuf: 1 >>>> debug.ddb.textdump.do_ddb: 1 >>>> debug.ddb.textdump.do_config: 1 >>>> debug.ddb.textdump.pending: 0 >>>> debug.ddb_use_printf: 0 >>>> debug.acpi.semaphore_debug: 0 >>>> debug.acpi.suspend_bounce: 0 >>>> debug.acpi.reset_clock: 1 >>>> debug.acpi.do_powerstate: 1 >>>> debug.acpi.acpi_ca_version: 20070320 >>>> debug.acpi.ec.timeout: 750 >>>> debug.acpi.ec.polled: 0 >>>> debug.acpi.ec.burst: 0 >>>> debug.acpi.batt.batt_sleep_ms: 0 >>>> debug.acpi.resume_beep: 0 >>>> debug.mddebug: 0 >>>> debug.gdbcons: 0 >>>> debug.elf64_legacy_coredump: 0 >>>> debug.bootverbose: 0 >>>> debug.boothowto: 0 >>>> debug.cpufreq.verbose: 0 >>>> debug.cpufreq.lowest: 0 >>>> debug.sizeof.cdev_priv: 376 >>>> debug.sizeof.cdev: 288 >>>> debug.sizeof.g_bioq: 56 >>>> debug.sizeof.g_consumer: 96 >>>> debug.sizeof.g_provider: 136 >>>> debug.sizeof.g_geom: 136 >>>> debug.sizeof.g_class: 136 >>>> debug.sizeof.kinfo_proc: 1088 >>>> debug.sizeof.buf: 600 >>>> debug.sizeof.bio: 216 >>>> debug.sizeof.proc: 1112 >>>> debug.sizeof.vnode: 472 >>>> debug.sizeof.devstat: 288 >>>> debug.sizeof.namecache: 72 >>>> debug.sizeof.znode: 376 >>>> debug.osd: 0 >>>> debug.rwlock.loops: 10000 >>>> debug.rwlock.retry: 10 >>>> debug.trace_on_panic: 1 >>>> debug.debugger_on_panic: 0 >>>> debug.to_avg_mpcalls: 515 >>>> debug.to_avg_lockcalls: 1 >>>> debug.to_avg_gcalls: 255 >>>> debug.to_avg_depth: 1017 >>>> debug.umtx.umtx_pi_allocated: 0 >>>> debug.kdb.stop_cpus: 1 >>>> debug.kdb.trap_code: 0 >>>> debug.kdb.trap: 0 >>>> debug.kdb.panic: 0 >>>> debug.kdb.enter: 0 >>>> debug.kdb.current: ddb >>>> debug.kdb.available: ddb debug.rman_debug: 0 >>>> debug.ttydebug: 0 >>>> debug.disablefullpath: 0 >>>> debug.disablecwd: 0 >>>> debug.vfscache: 1 >>>> debug.numcachehv: 2066 >>>> debug.numcache: 30787 >>>> debug.numneg: 766 >>>> debug.ncnegfactor: 16 >>>> debug.nchash: 131071 >>>> debug.vnlru_nowhere: 0 >>>> debug.rush_requests: 0 >>>> debug.mpsafevfs: 1 >>>> debug.if_tun_debug: 0 >>>> debug.nlm_debug: 0 >>>> debug.crypto_timing: 0 >>>> debug.collectsnapstats: 0 >>>> debug.snapdebug: 0 >>>> debug.dopersistence: 0 >>>> debug.dir_entry: 0 >>>> debug.direct_blk_ptrs: 0 >>>> debug.inode_bitmap: 0 >>>> debug.indir_blk_ptrs: 0 >>>> debug.sync_limit_hit: 0 >>>> debug.ino_limit_hit: 0 >>>> debug.blk_limit_hit: 0 >>>> debug.ino_limit_push: 0 >>>> debug.blk_limit_push: 0 >>>> debug.worklist_push: 0 >>>> debug.maxindirdeps: 50 >>>> debug.tickdelay: 2 >>>> debug.max_softdeps: 400000 >>>> debug.dobkgrdwrite: 1 >>>> debug.bigcgs: 0 >>>> debug.dircheck: 0 >>>> debug.minidump: 1 >>>> debug.psm.pkterrthresh: 2 >>>> debug.psm.usecs: 500000 >>>> debug.psm.secs: 0 >>>> debug.psm.errusecs: 0 >>>> debug.psm.errsecs: 2 >>>> debug.psm.hz: 20 >>>> debug.psm.loglevel: 0 >>>> debug.fdc.settle: 125 >>>> debug.fdc.spec2: 16 >>>> debug.fdc.spec1: 175 >>>> debug.fdc.retries: 10 >>>> debug.fdc.debugflags: 0 >>>> debug.fdc.fifo: 8 >>>> debug.elf32_legacy_coredump: 0 >>>> debug.hwpstate_verbose: 0 >>>> hw.machine: amd64 >>>> hw.model: Intel(R) Xeon(R) CPU            5120  @ 1.86GHz >>>> hw.ncpu: 4 >>>> hw.byteorder: 1234 >>>> hw.physmem: 17167667200 >>>> hw.usermem: 3024932864 >>>> hw.pagesize: 4096 >>>> hw.floatingpoint: 1 >>>> hw.machine_arch: amd64 >>>> hw.realmem: 17985175552 >>>> hw.ata.setmax: 0 >>>> hw.ata.wc: 1 >>>> hw.ata.atapi_dma: 1 >>>> hw.ata.ata_dma_check_80pin: 1 >>>> hw.ata.ata_dma: 1 >>>> hw.pci.honor_msi_blacklist: 1 >>>> hw.pci.enable_msix: 1 >>>> hw.pci.enable_msi: 1 >>>> hw.pci.do_power_resume: 1 >>>> hw.pci.do_power_nodriver: 0 >>>> hw.pci.enable_io_modes: 1 >>>> hw.pci.host_mem_start: 2147483648 >>>> hw.syscons.kbd_debug: 1 >>>> hw.syscons.kbd_reboot: 1 >>>> hw.syscons.bell: 1 >>>> hw.syscons.saver.keybonly: 1 >>>> hw.syscons.sc_no_suspend_vtswitch: 0 >>>> hw.usb2.ehci.no_hs: 0 >>>> hw.usb2.ehci.debug: 0 >>>> hw.usb2.uhci.loop: 0 >>>> hw.usb2.uhci.debug: 0 >>>> hw.usb2.ctrl.debug: 0 >>>> hw.usb2.umass.debug: 0 >>>> hw.usb2.urio.debug: 0 >>>> hw.usb2.debug: 0 >>>> hw.usb2.dev.debug: 0 >>>> hw.usb2.template: 0 >>>> hw.usb2.ugen.debug: 0 >>>> hw.usb2.power_timeout: 30 >>>> hw.usb2.uhub.debug: 0 >>>> hw.usb2.proc.debug: 0 >>>> hw.usb2.ss_delay: 0 >>>> hw.usb2.pr_recovery_delay: 250 >>>> hw.usb2.pr_poll_delay: 50 >>>> hw.usb2.ulpt.debug: 0 >>>> hw.usb2.ucom.debug: 0 >>>> hw.usb2.uhid.debug: 0 >>>> hw.usb2.ukbd.debug: 0 >>>> hw.usb2.ums.debug: 0 >>>> hw.intr_storm_threshold: 1000 >>>> hw.availpages: 4191325 >>>> hw.bus.devctl_disable: 0 >>>> hw.busdma.total_bpages: 8202 >>>> hw.busdma.zone0.total_bpages: 8202 >>>> hw.busdma.zone0.free_bpages: 8202 >>>> hw.busdma.zone0.reserved_bpages: 0 >>>> hw.busdma.zone0.active_bpages: 0 >>>> hw.busdma.zone0.total_bounced: 639896 >>>> hw.busdma.zone0.total_deferred: 0 >>>> hw.busdma.zone0.lowaddr: 0xffffffff >>>> hw.busdma.zone0.alignment: 4096 >>>> hw.clockrate: 1862 >>>> hw.via_feature_xcrypt: 0 >>>> hw.via_feature_rng: 0 >>>> hw.instruction_sse: 1 >>>> hw.apic.enable_extint: 0 >>>> hw.psm.tap_timeout: 125000 >>>> hw.psm.tap_threshold: 25 >>>> hw.ipmi.on: 1 >>>> hw.kbd.keymap_restrict_change: 0 >>>> hw.mca.count: 0 >>>> hw.mca.interval: 3600 >>>> hw.mca.force_scan: 0 >>>> hw.acpi.supported_sleep_state: S1 S4 S5 >>>> hw.acpi.power_button_state: S5 >>>> hw.acpi.sleep_button_state: S1 >>>> hw.acpi.lid_switch_state: NONE >>>> hw.acpi.standby_state: S1 >>>> hw.acpi.suspend_state: NONE >>>> hw.acpi.sleep_delay: 1 >>>> hw.acpi.s4bios: 0 >>>> hw.acpi.verbose: 0 >>>> hw.acpi.disable_on_reboot: 0 >>>> hw.acpi.handle_reboot: 1 >>>> hw.acpi.reset_video: 0 >>>> hw.acpi.cpu.cx_lowest: C1 >>>> hw.dri.0.name: radeon 0x2a >>>> hw.dri.0.vm: slot offset             size       type flags address >>>>  mtrr >>>>  0 0x00000000d8200000 0x00010000  REG  0x82 0xffffff00d8200000 no >>>> >>>> hw.dri.0.clients: a dev   pid    uid      magic     ioctls >>>> >>>> hw.dri.0.debug: 0 >>>> machdep.acpi_timer_freq: 3579545 >>>> machdep.enable_panic_key: 0 >>>> machdep.adjkerntz: 18000 >>>> machdep.wall_cmos_clock: 1 >>>> machdep.disable_rtc_set: 0 >>>> machdep.acpi_root: 1007888 >>>> machdep.disable_mtrrs: 0 >>>> machdep.idle: acpi >>>> machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, >>>> machdep.hlt_cpus: >>>> 0 >>>> machdep.prot_fault_translation: 0 >>>> machdep.panic_on_nmi: 1 >>>> machdep.kdb_on_nmi: 1 >>>> machdep.tsc_freq: 1862013503 >>>> machdep.i8254_freq: 1193182 >>>> machdep.hlt_logical_cpus: 0 >>>> machdep.logical_cpus_mask: 10 >>>> user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: >>>> user.bc_base_max: 99 >>>> user.bc_dim_max: 2048 >>>> user.bc_scale_max: 99 >>>> user.bc_string_max: 1000 >>>> user.coll_weights_max: 0 >>>> user.expr_nest_max: 32 >>>> user.line_max: 2048 >>>> user.re_dup_max: 255 >>>> user.posix2_version: 199212 >>>> user.posix2_c_bind: 0 >>>> user.posix2_c_dev: 0 >>>> user.posix2_char_term: 0 >>>> user.posix2_fort_dev: 0 >>>> user.posix2_fort_run: 0 >>>> user.posix2_localedef: 0 >>>> user.posix2_sw_dev: 0 >>>> user.posix2_upe: 0 >>>> user.stream_max: 20 >>>> user.tzname_max: 255 >>>> p1003_1b.asynchronous_io: 0 >>>> p1003_1b.mapped_files: 1 >>>> p1003_1b.memlock: 0 >>>> p1003_1b.memlock_range: 0 >>>> p1003_1b.memory_protection: 0 >>>> p1003_1b.message_passing: 0 >>>> p1003_1b.prioritized_io: 0 >>>> p1003_1b.priority_scheduling: 1 >>>> p1003_1b.realtime_signals: 200112 >>>> p1003_1b.semaphores: 0 >>>> p1003_1b.fsync: 0 >>>> p1003_1b.shared_memory_objects: 1 >>>> p1003_1b.synchronized_io: 0 >>>> p1003_1b.timers: 200112 >>>> p1003_1b.aio_listio_max: -1 >>>> p1003_1b.aio_max: -1 >>>> p1003_1b.aio_prio_delta_max: -1 >>>> p1003_1b.delaytimer_max: 2147483647 >>>> p1003_1b.mq_open_max: 0 >>>> p1003_1b.pagesize: 4096 >>>> p1003_1b.rtsig_max: 62 >>>> p1003_1b.sem_nsems_max: 0 >>>> p1003_1b.sem_value_max: 0 >>>> p1003_1b.sigqueue_max: 128 >>>> p1003_1b.timer_max: 32 >>>> security.jail.jailed: 0 >>>> security.jail.param.host.hostname: 256 >>>> security.jail.param.securelevel: 0 >>>> security.jail.param.path: 1024 >>>> security.jail.param.cpuset: 0 >>>> security.jail.param.name: 256 >>>> security.jail.param.jid: 0 >>>> security.jail.param.linux.oss_version: 0 >>>> security.jail.param.linux.osrelease: 65 >>>> security.jail.param.linux.osname: 65 >>>> security.jail.jail_max_af_ips: 255 >>>> security.jail.mount_allowed: 0 >>>> security.jail.chflags_allowed: 0 >>>> security.jail.allow_raw_sockets: 0 >>>> security.jail.enforce_statfs: 2 >>>> security.jail.sysvipc_allowed: 0 >>>> security.jail.socket_unixiproute_only: 1 >>>> security.jail.set_hostname_allowed: 1 >>>> security.bsd.suser_enabled: 1 >>>> security.bsd.unprivileged_proc_debug: 1 >>>> security.bsd.conservative_signals: 1 >>>> security.bsd.see_other_gids: 1 >>>> security.bsd.see_other_uids: 1 >>>> security.bsd.unprivileged_read_msgbuf: 1 >>>> security.bsd.hardlink_check_gid: 0 >>>> security.bsd.hardlink_check_uid: 0 >>>> security.bsd.unprivileged_get_quota: 0 >>>> compat.ia32.maxvmem: 0 >>>> compat.ia32.maxssiz: 67108864 >>>> compat.ia32.maxdsiz: 536870912 >>>> compat.linux.oss_version: 198144 >>>> compat.linux.osrelease: 2.6.16 >>>> compat.linux.osname: Linux >>>> compat.linux32.maxvmem: 0 >>>> compat.linux32.maxssiz: 67108864 >>>> compat.linux32.maxdsiz: 536870912 >>>> dev.nexus.0.%driver: nexus >>>> dev.nexus.0.%parent: root0 >>>> dev.ram.0.%desc: System RAM >>>> dev.ram.0.%driver: ram >>>> dev.ram.0.%parent: nexus0 >>>> dev.smbios.0.%desc: System Management BIOS >>>> dev.smbios.0.%driver: smbios >>>> dev.smbios.0.%parent: nexus0 >>>> dev.cryptosoft.0.%desc: software crypto >>>> dev.cryptosoft.0.%driver: cryptosoft >>>> dev.cryptosoft.0.%parent: nexus0 >>>> dev.acpi.0.%desc: SMCI SMCISLP2 >>>> dev.acpi.0.%driver: acpi >>>> dev.acpi.0.%parent: nexus0 >>>> dev.acpi_sysresource.0.%desc: System Resource >>>> dev.acpi_sysresource.0.%driver: acpi_sysresource >>>> dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.LPC0.MBRD >>>> dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=31 >>>> dev.acpi_sysresource.0.%parent: acpi0 >>>> dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz >>>> dev.acpi_timer.0.%driver: acpi_timer >>>> dev.acpi_timer.0.%location: unknown >>>> dev.acpi_timer.0.%pnpinfo: unknown >>>> dev.acpi_timer.0.%parent: acpi0 >>>> dev.pci_link.0.%desc: ACPI PCI Link LNKA >>>> dev.pci_link.0.%driver: pci_link >>>> dev.pci_link.0.%location: handle=\_SB_.PCI0.LPC0.LNKA >>>> dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 >>>> dev.pci_link.0.%parent: acpi0 >>>> dev.pci_link.1.%desc: ACPI PCI Link LNKB >>>> dev.pci_link.1.%driver: pci_link >>>> dev.pci_link.1.%location: handle=\_SB_.PCI0.LPC0.LNKB >>>> dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 >>>> dev.pci_link.1.%parent: acpi0 >>>> dev.pci_link.2.%desc: ACPI PCI Link LNKC >>>> dev.pci_link.2.%driver: pci_link >>>> dev.pci_link.2.%location: handle=\_SB_.PCI0.LPC0.LNKC >>>> dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 >>>> dev.pci_link.2.%parent: acpi0 >>>> dev.pci_link.3.%desc: ACPI PCI Link LNKD >>>> dev.pci_link.3.%driver: pci_link >>>> dev.pci_link.3.%location: handle=\_SB_.PCI0.LPC0.LNKD >>>> dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 >>>> dev.pci_link.3.%parent: acpi0 >>>> dev.pci_link.4.%desc: ACPI PCI Link LNKE >>>> dev.pci_link.4.%driver: pci_link >>>> dev.pci_link.4.%location: handle=\_SB_.PCI0.LPC0.LNKE >>>> dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 >>>> dev.pci_link.4.%parent: acpi0 >>>> dev.pci_link.5.%desc: ACPI PCI Link LNKF >>>> dev.pci_link.5.%driver: pci_link >>>> dev.pci_link.5.%location: handle=\_SB_.PCI0.LPC0.LNKF >>>> dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 >>>> dev.pci_link.5.%parent: acpi0 >>>> dev.pci_link.6.%desc: ACPI PCI Link LNKG >>>> dev.pci_link.6.%driver: pci_link >>>> dev.pci_link.6.%location: handle=\_SB_.PCI0.LPC0.LNKG >>>> dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 >>>> dev.pci_link.6.%parent: acpi0 >>>> dev.pci_link.7.%desc: ACPI PCI Link LNKH >>>> dev.pci_link.7.%driver: pci_link >>>> dev.pci_link.7.%location: handle=\_SB_.PCI0.LPC0.LNKH >>>> dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 >>>> dev.pci_link.7.%parent: acpi0 >>>> dev.acpi_hpet.0.%desc: High Precision Event Timer >>>> dev.acpi_hpet.0.%driver: acpi_hpet >>>> dev.acpi_hpet.0.%location: unknown >>>> dev.acpi_hpet.0.%pnpinfo: unknown >>>> dev.acpi_hpet.0.%parent: acpi0 >>>> dev.pcib.0.%desc: ACPI Host-PCI bridge >>>> dev.pcib.0.%driver: pcib >>>> dev.pcib.0.%location: handle=\_SB_.PCI0 >>>> dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=0 >>>> dev.pcib.0.%parent: acpi0 >>>> dev.pcib.1.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.1.%driver: pcib >>>> dev.pcib.1.%location: slot=2 function=0 handle=\_SB_.PCI0.P0P2 >>>> dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x25f7 subvendor=0x0000 >>>> subdevice=0x0000 class=0x060400 >>>> dev.pcib.1.%parent: pci0 >>>> dev.pcib.1.domain: 0 >>>> dev.pcib.1.pribus: 0 >>>> dev.pcib.1.secbus: 1 >>>> dev.pcib.1.subbus: 7 >>>> dev.pcib.2.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.2.%driver: pcib >>>> dev.pcib.2.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P2.BMD0 >>>> dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x3500 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060400 >>>> dev.pcib.2.%parent: pci1 >>>> dev.pcib.2.domain: 0 >>>> dev.pcib.2.pribus: 1 >>>> dev.pcib.2.secbus: 2 >>>> dev.pcib.2.subbus: 6 >>>> dev.pcib.3.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.3.%driver: pcib >>>> dev.pcib.3.%location: slot=0 function=0 >>>> handle=\_SB_.PCI0.P0P2.BMD0.BPD0 >>>> dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x3510 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060400 >>>> dev.pcib.3.%parent: pci2 >>>> dev.pcib.3.domain: 0 >>>> dev.pcib.3.pribus: 2 >>>> dev.pcib.3.secbus: 3 >>>> dev.pcib.3.subbus: 5 >>>> dev.pcib.4.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.4.%driver: pcib >>>> dev.pcib.4.%location: slot=0 function=0 >>>> handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH0 >>>> dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x0329 subvendor=0x0000 >>>> subdevice=0x0000 class=0x060400 >>>> dev.pcib.4.%parent: pci3 >>>> dev.pcib.4.domain: 0 >>>> dev.pcib.4.pribus: 3 >>>> dev.pcib.4.secbus: 4 >>>> dev.pcib.4.subbus: 4 >>>> dev.pcib.4.wake: 0 >>>> dev.pcib.5.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.5.%driver: pcib >>>> dev.pcib.5.%location: slot=0 function=2 >>>> handle=\_SB_.PCI0.P0P2.BMD0.BPD0.PXH1 >>>> dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x032a subvendor=0x0000 >>>> subdevice=0x0000 class=0x060400 >>>> dev.pcib.5.%parent: pci3 >>>> dev.pcib.5.domain: 0 >>>> dev.pcib.5.pribus: 3 >>>> dev.pcib.5.secbus: 5 >>>> dev.pcib.5.subbus: 5 >>>> dev.pcib.5.wake: 0 >>>> dev.pcib.6.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.6.%driver: pcib >>>> dev.pcib.6.%location: slot=2 function=0 >>>> handle=\_SB_.PCI0.P0P2.BMD0.BPD2 >>>> dev.pcib.6.%pnpinfo: vendor=0x8086 device=0x3518 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060400 >>>> dev.pcib.6.%parent: pci2 >>>> dev.pcib.6.domain: 0 >>>> dev.pcib.6.pribus: 2 >>>> dev.pcib.6.secbus: 6 >>>> dev.pcib.6.subbus: 6 >>>> dev.pcib.6.wake: 0 >>>> dev.pcib.7.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.7.%driver: pcib >>>> dev.pcib.7.%location: slot=0 function=3 handle=\_SB_.PCI0.P0P2.BMF3 >>>> dev.pcib.7.%pnpinfo: vendor=0x8086 device=0x350c subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060400 >>>> dev.pcib.7.%parent: pci1 >>>> dev.pcib.7.domain: 0 >>>> dev.pcib.7.pribus: 1 >>>> dev.pcib.7.secbus: 7 >>>> dev.pcib.7.subbus: 7 >>>> dev.pcib.7.wake: 0 >>>> dev.pcib.8.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.8.%driver: pcib >>>> dev.pcib.8.%location: slot=4 function=0 handle=\_SB_.PCI0.P0P4 >>>> dev.pcib.8.%pnpinfo: vendor=0x8086 device=0x25f8 subvendor=0x0000 >>>> subdevice=0x0000 class=0x060400 >>>> dev.pcib.8.%parent: pci0 >>>> dev.pcib.8.domain: 0 >>>> dev.pcib.8.pribus: 0 >>>> dev.pcib.8.secbus: 8 >>>> dev.pcib.8.subbus: 8 >>>> dev.pcib.8.wake: 0 >>>> dev.pcib.9.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.9.%driver: pcib >>>> dev.pcib.9.%location: slot=6 function=0 handle=\_SB_.PCI0.P0P6 >>>> dev.pcib.9.%pnpinfo: vendor=0x8086 device=0x25f9 subvendor=0x0000 >>>> subdevice=0x0000 class=0x060400 >>>> dev.pcib.9.%parent: pci0 >>>> dev.pcib.9.domain: 0 >>>> dev.pcib.9.pribus: 0 >>>> dev.pcib.9.secbus: 9 >>>> dev.pcib.9.subbus: 9 >>>> dev.pcib.9.wake: 0 >>>> dev.pcib.10.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.10.%driver: pcib >>>> dev.pcib.10.%location: slot=28 function=0 handle=\_SB_.PCI0.PEX0 >>>> dev.pcib.10.%pnpinfo: vendor=0x8086 device=0x2690 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060400 >>>> dev.pcib.10.%parent: pci0 >>>> dev.pcib.10.domain: 0 >>>> dev.pcib.10.pribus: 0 >>>> dev.pcib.10.secbus: 10 >>>> dev.pcib.10.subbus: 10 >>>> dev.pcib.10.wake: 0 >>>> dev.pcib.11.%desc: ACPI PCI-PCI bridge >>>> dev.pcib.11.%driver: pcib >>>> dev.pcib.11.%location: slot=30 function=0 handle=\_SB_.PCI0.PCIB >>>> dev.pcib.11.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060401 >>>> dev.pcib.11.%parent: pci0 >>>> dev.pcib.11.domain: 0 >>>> dev.pcib.11.pribus: 0 >>>> dev.pcib.11.secbus: 11 >>>> dev.pcib.11.subbus: 11 >>>> dev.pcib.11.wake: 0 >>>> dev.pci.0.%desc: ACPI PCI bus >>>> dev.pci.0.%driver: pci >>>> dev.pci.0.%parent: pcib0 >>>> dev.pci.1.%desc: ACPI PCI bus >>>> dev.pci.1.%driver: pci >>>> dev.pci.1.%parent: pcib1 >>>> dev.pci.2.%desc: ACPI PCI bus >>>> dev.pci.2.%driver: pci >>>> dev.pci.2.%parent: pcib2 >>>> dev.pci.3.%desc: ACPI PCI bus >>>> dev.pci.3.%driver: pci >>>> dev.pci.3.%parent: pcib3 >>>> dev.pci.4.%desc: ACPI PCI bus >>>> dev.pci.4.%driver: pci >>>> dev.pci.4.%parent: pcib4 >>>> dev.pci.4.wake: 0 >>>> dev.pci.5.%desc: ACPI PCI bus >>>> dev.pci.5.%driver: pci >>>> dev.pci.5.%parent: pcib5 >>>> dev.pci.5.wake: 0 >>>> dev.pci.6.%desc: ACPI PCI bus >>>> dev.pci.6.%driver: pci >>>> dev.pci.6.%parent: pcib6 >>>> dev.pci.6.wake: 0 >>>> dev.pci.7.%desc: ACPI PCI bus >>>> dev.pci.7.%driver: pci >>>> dev.pci.7.%parent: pcib7 >>>> dev.pci.7.wake: 0 >>>> dev.pci.8.%desc: ACPI PCI bus >>>> dev.pci.8.%driver: pci >>>> dev.pci.8.%parent: pcib8 >>>> dev.pci.8.wake: 0 >>>> dev.pci.9.%desc: ACPI PCI bus >>>> dev.pci.9.%driver: pci >>>> dev.pci.9.%parent: pcib9 >>>> dev.pci.9.wake: 0 >>>> dev.pci.10.%desc: ACPI PCI bus >>>> dev.pci.10.%driver: pci >>>> dev.pci.10.%parent: pcib10 >>>> dev.pci.10.wake: 0 >>>> dev.pci.11.%desc: ACPI PCI bus >>>> dev.pci.11.%driver: pci >>>> dev.pci.11.%parent: pcib11 >>>> dev.pci.11.wake: 0 >>>> dev.hostb.0.%desc: Host to PCI bridge >>>> dev.hostb.0.%driver: hostb >>>> dev.hostb.0.%location: slot=0 function=0 >>>> dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x25d8 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.0.%parent: pci0 >>>> dev.hostb.1.%desc: Host to PCI bridge >>>> dev.hostb.1.%driver: hostb >>>> dev.hostb.1.%location: slot=16 function=0 >>>> dev.hostb.1.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.1.%parent: pci0 >>>> dev.hostb.2.%desc: Host to PCI bridge >>>> dev.hostb.2.%driver: hostb >>>> dev.hostb.2.%location: slot=16 function=1 >>>> dev.hostb.2.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.2.%parent: pci0 >>>> dev.hostb.3.%desc: Host to PCI bridge >>>> dev.hostb.3.%driver: hostb >>>> dev.hostb.3.%location: slot=16 function=2 >>>> dev.hostb.3.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.3.%parent: pci0 >>>> dev.hostb.4.%desc: Host to PCI bridge >>>> dev.hostb.4.%driver: hostb >>>> dev.hostb.4.%location: slot=17 function=0 >>>> dev.hostb.4.%pnpinfo: vendor=0x8086 device=0x25f1 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.4.%parent: pci0 >>>> dev.hostb.5.%desc: Host to PCI bridge >>>> dev.hostb.5.%driver: hostb >>>> dev.hostb.5.%location: slot=19 function=0 >>>> dev.hostb.5.%pnpinfo: vendor=0x8086 device=0x25f3 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.5.%parent: pci0 >>>> dev.hostb.6.%desc: Host to PCI bridge >>>> dev.hostb.6.%driver: hostb >>>> dev.hostb.6.%location: slot=21 function=0 >>>> dev.hostb.6.%pnpinfo: vendor=0x8086 device=0x25f5 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.6.%parent: pci0 >>>> dev.hostb.7.%desc: Host to PCI bridge >>>> dev.hostb.7.%driver: hostb >>>> dev.hostb.7.%location: slot=22 function=0 >>>> dev.hostb.7.%pnpinfo: vendor=0x8086 device=0x25f6 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060000 >>>> dev.hostb.7.%parent: pci0 >>>> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >>>> dev.em.0.%driver: em >>>> dev.em.0.%location: slot=0 function=0 >>>> dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >>>> subdevice=0x0000 class=0x020000 >>>> dev.em.0.%parent: pci6 >>>> dev.em.0.debug: -1 >>>> dev.em.0.stats: -1 >>>> dev.em.0.rx_int_delay: 0 >>>> dev.em.0.tx_int_delay: 66 >>>> dev.em.0.rx_abs_int_delay: 66 >>>> dev.em.0.tx_abs_int_delay: 66 >>>> dev.em.0.rx_processing_limit: 100 >>>> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.9 >>>> dev.em.1.%driver: em >>>> dev.em.1.%location: slot=0 function=1 >>>> dev.em.1.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >>>> subdevice=0x0000 class=0x020000 >>>> dev.em.1.%parent: pci6 >>>> dev.em.1.debug: -1 >>>> dev.em.1.stats: -1 >>>> dev.em.1.rx_int_delay: 0 >>>> dev.em.1.tx_int_delay: 66 >>>> dev.em.1.rx_abs_int_delay: 66 >>>> dev.em.1.tx_abs_int_delay: 66 >>>> dev.em.1.rx_processing_limit: 100 >>>> dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >>>> dev.uhci.0.%driver: uhci >>>> dev.uhci.0.%location: slot=29 function=0 handle=\_SB_.PCI0.USB1 >>>> dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2688 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x0c0300 >>>> dev.uhci.0.%parent: pci0 >>>> dev.uhci.0.wake: 0 >>>> dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >>>> dev.uhci.1.%driver: uhci >>>> dev.uhci.1.%location: slot=29 function=1 handle=\_SB_.PCI0.USB2 >>>> dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2689 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x0c0300 >>>> dev.uhci.1.%parent: pci0 >>>> dev.uhci.1.wake: 0 >>>> dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >>>> dev.uhci.2.%driver: uhci >>>> dev.uhci.2.%location: slot=29 function=2 handle=\_SB_.PCI0.USB3 >>>> dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x268a subvendor=0x15d9 >>>> subdevice=0x8080 class=0x0c0300 >>>> dev.uhci.2.%parent: pci0 >>>> dev.uhci.2.wake: 0 >>>> dev.usbus.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 >>>> dev.usbus.0.%driver: usbus >>>> dev.usbus.0.%parent: uhci0 >>>> dev.usbus.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 >>>> dev.usbus.1.%driver: usbus >>>> dev.usbus.1.%parent: uhci1 >>>> dev.usbus.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 >>>> dev.usbus.2.%driver: usbus >>>> dev.usbus.2.%parent: uhci2 >>>> dev.usbus.3.%desc: Intel 63XXESB USB 2.0 controller >>>> dev.usbus.3.%driver: usbus >>>> dev.usbus.3.%parent: ehci0 >>>> dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller >>>> dev.ehci.0.%driver: ehci >>>> dev.ehci.0.%location: slot=29 function=7 handle=\_SB_.PCI0.EUSB >>>> dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x268c subvendor=0x15d9 >>>> subdevice=0x8080 class=0x0c0320 >>>> dev.ehci.0.%parent: pci0 >>>> dev.ehci.0.wake: 0 >>>> dev.vgapci.0.%desc: VGA-compatible display >>>> dev.vgapci.0.%driver: vgapci >>>> dev.vgapci.0.%location: slot=1 function=0 >>>> dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x515e subvendor=0x15d9 >>>> subdevice=0x8080 class=0x030000 >>>> dev.vgapci.0.%parent: pci11 >>>> dev.drm.0.%desc: ATI ES1000 RN50 >>>> dev.drm.0.%driver: drm >>>> dev.drm.0.%parent: vgapci0 >>>> dev.isab.0.%desc: PCI-ISA bridge >>>> dev.isab.0.%driver: isab >>>> dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.LPC0 >>>> dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2670 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x060100 >>>> dev.isab.0.%parent: pci0 >>>> dev.isa.0.%desc: ISA bus >>>> dev.isa.0.%driver: isa >>>> dev.isa.0.%parent: isab0 >>>> dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller >>>> dev.atapci.0.%driver: atapci >>>> dev.atapci.0.%location: slot=31 function=1 handle=\_SB_.PCI0.IDEC >>>> dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x269e subvendor=0x15d9 >>>> subdevice=0x8080 class=0x01018a >>>> dev.atapci.0.%parent: pci0 >>>> dev.atapci.1.%desc: Intel 63XXESB2 SATA300 controller >>>> dev.atapci.1.%driver: atapci >>>> dev.atapci.1.%location: slot=31 function=2 >>>> dev.atapci.1.%pnpinfo: vendor=0x8086 device=0x2681 subvendor=0x15d9 >>>> subdevice=0x8080 class=0x010601 >>>> dev.atapci.1.%parent: pci0 >>>> dev.ata.0.%desc: ATA channel 0 >>>> dev.ata.0.%driver: ata >>>> dev.ata.0.%parent: atapci0 >>>> dev.ata.2.%desc: ATA channel 0 >>>> dev.ata.2.%driver: ata >>>> dev.ata.2.%parent: atapci1 >>>> dev.ata.3.%desc: ATA channel 1 >>>> dev.ata.3.%driver: ata >>>> dev.ata.3.%parent: atapci1 >>>> dev.ata.4.%desc: ATA channel 2 >>>> dev.ata.4.%driver: ata >>>> dev.ata.4.%parent: atapci1 >>>> dev.ata.5.%desc: ATA channel 3 >>>> dev.ata.5.%driver: ata >>>> dev.ata.5.%parent: atapci1 >>>> dev.ata.6.%desc: ATA channel 4 >>>> dev.ata.6.%driver: ata >>>> dev.ata.6.%parent: atapci1 >>>> dev.ata.7.%desc: ATA channel 5 >>>> dev.ata.7.%driver: ata >>>> dev.ata.7.%parent: atapci1 >>>> dev.ichsmb.0.%desc: Intel 631xESB/6321ESB (ESB2) SMBus controller >>>> dev.ichsmb.0.%driver: ichsmb >>>> dev.ichsmb.0.%location: slot=31 function=3 handle=\_SB_.PCI0.SMBS >>>> dev.ichsmb.0.%pnpinfo: vendor=0x8086 device=0x269b subvendor=0x15d9 >>>> subdevice=0x8080 class=0x0c0500 >>>> dev.ichsmb.0.%parent: pci0 >>>> dev.smbus.0.%desc: System Management Bus >>>> dev.smbus.0.%driver: smbus >>>> dev.smbus.0.%parent: ichsmb0 >>>> dev.smb.0.%desc: SMBus generic I/O >>>> dev.smb.0.%driver: smb >>>> dev.smb.0.%parent: smbus0 >>>> dev.acpi_button.0.%desc: Power Button >>>> dev.acpi_button.0.%driver: acpi_button >>>> dev.acpi_button.0.%location: handle=\_SB_.PCI0.PWRB >>>> dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 >>>> dev.acpi_button.0.%parent: acpi0 >>>> dev.atdma.0.%desc: AT DMA controller >>>> dev.atdma.0.%driver: atdma >>>> dev.atdma.0.%location: handle=\_SB_.PCI0.LPC0.DMAC >>>> dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 >>>> dev.atdma.0.%parent: acpi0 >>>> dev.fpupnp.0.%desc: Legacy ISA coprocessor support >>>> dev.fpupnp.0.%driver: fpupnp >>>> dev.fpupnp.0.%location: handle=\_SB_.PCI0.LPC0.MATH >>>> dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 >>>> dev.fpupnp.0.%parent: acpi0 >>>> dev.atrtc.0.%desc: AT realtime clock >>>> dev.atrtc.0.%driver: atrtc >>>> dev.atrtc.0.%location: handle=\_SB_.PCI0.LPC0.RTC_ >>>> dev.atrtc.0.%pnpinfo: _HID=PNP0B00 _UID=0 >>>> dev.atrtc.0.%parent: acpi0 >>>> dev.attimer.0.%desc: AT timer >>>> dev.attimer.0.%driver: attimer >>>> dev.attimer.0.%location: handle=\_SB_.PCI0.LPC0.TIME >>>> dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 >>>> dev.attimer.0.%parent: acpi0 >>>> dev.atkbdc.0.%desc: Keyboard controller (i8042) >>>> dev.atkbdc.0.%driver: atkbdc >>>> dev.atkbdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.KBC0 >>>> dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 >>>> dev.atkbdc.0.%parent: acpi0 >>>> dev.atkbdc.0.wake: 0 >>>> dev.atkbd.0.%desc: AT Keyboard >>>> dev.atkbd.0.%driver: atkbd >>>> dev.atkbd.0.%parent: atkbdc0 >>>> dev.psmcpnp.0.%desc: PS/2 mouse port >>>> dev.psmcpnp.0.%driver: psmcpnp >>>> dev.psmcpnp.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.MSE0 >>>> dev.psmcpnp.0.%pnpinfo: _HID=PNP0F13 _UID=0 >>>> dev.psmcpnp.0.%parent: acpi0 >>>> dev.psmcpnp.0.wake: 0 >>>> dev.uart.0.%desc: 16550 or compatible >>>> dev.uart.0.%driver: uart >>>> dev.uart.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM1 >>>> dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 >>>> dev.uart.0.%parent: acpi0 >>>> dev.uart.0.wake: 0 >>>> dev.uart.1.%desc: 16550 or compatible >>>> dev.uart.1.%driver: uart >>>> dev.uart.1.%location: handle=\_SB_.PCI0.LPC0.SIO_.COM2 >>>> dev.uart.1.%pnpinfo: _HID=PNP0501 _UID=2 >>>> dev.uart.1.%parent: acpi0 >>>> dev.uart.1.wake: 0 >>>> dev.fdc.0.%desc: Enhanced floppy controller >>>> dev.fdc.0.%driver: fdc >>>> dev.fdc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.FDC_ >>>> dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=1 >>>> dev.fdc.0.%parent: acpi0 >>>> dev.fd.0.%desc: 1440-KB 3.5" drive >>>> dev.fd.0.%driver: fd >>>> dev.fd.0.%parent: fdc0 >>>> dev.ppc.0.%desc: Parallel port >>>> dev.ppc.0.%driver: ppc >>>> dev.ppc.0.%location: handle=\_SB_.PCI0.LPC0.SIO_.PRT_ >>>> dev.ppc.0.%pnpinfo: _HID=PNP0401 _UID=2 >>>> dev.ppc.0.%parent: acpi0 >>>> dev.ppbus.0.%desc: Parallel port bus >>>> dev.ppbus.0.%driver: ppbus >>>> dev.ppbus.0.%parent: ppc0 >>>> dev.lpt.0.%desc: Printer >>>> dev.lpt.0.%driver: lpt >>>> dev.lpt.0.%parent: ppbus0 >>>> dev.ppi.0.%desc: Parallel I/O >>>> dev.ppi.0.%driver: ppi >>>> dev.ppi.0.%parent: ppbus0 >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.temperature: 57 >>>> dev.cpu.0.freq: 1867 >>>> dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 >>>> 933/17500 >>>> 700/13125 466/8750 233/4375 >>>> dev.cpu.0.cx_supported: C1/1 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% last 500us >>>> dev.cpu.1.%desc: ACPI CPU >>>> dev.cpu.1.%driver: cpu >>>> dev.cpu.1.%location: handle=\_PR_.CPU1 >>>> dev.cpu.1.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.1.%parent: acpi0 >>>> dev.cpu.1.temperature: 59 >>>> dev.cpu.1.cx_supported: C1/1 >>>> dev.cpu.1.cx_lowest: C1 >>>> dev.cpu.1.cx_usage: 100.00% last 500us >>>> dev.cpu.2.%desc: ACPI CPU >>>> dev.cpu.2.%driver: cpu >>>> dev.cpu.2.%location: handle=\_PR_.CPU2 >>>> dev.cpu.2.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.2.%parent: acpi0 >>>> dev.cpu.2.temperature: 59 >>>> dev.cpu.2.cx_supported: C1/1 >>>> dev.cpu.2.cx_lowest: C1 >>>> dev.cpu.2.cx_usage: 100.00% last 500us >>>> dev.cpu.3.%desc: ACPI CPU >>>> dev.cpu.3.%driver: cpu >>>> dev.cpu.3.%location: handle=\_PR_.CPU3 >>>> dev.cpu.3.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.3.%parent: acpi0 >>>> dev.cpu.3.temperature: 60 >>>> dev.cpu.3.cx_supported: C1/1 >>>> dev.cpu.3.cx_lowest: C1 >>>> dev.cpu.3.cx_usage: 100.00% last 500us >>>> dev.acpi_perf.0.%driver: acpi_perf >>>> dev.acpi_perf.0.%parent: cpu0 >>>> dev.acpi_perf.1.%driver: acpi_perf >>>> dev.acpi_perf.1.%parent: cpu1 >>>> dev.acpi_perf.2.%driver: acpi_perf >>>> dev.acpi_perf.2.%parent: cpu2 >>>> dev.acpi_perf.3.%driver: acpi_perf >>>> dev.acpi_perf.3.%parent: cpu3 >>>> dev.coretemp.0.%desc: CPU On-Die Thermal Sensors >>>> dev.coretemp.0.%driver: coretemp >>>> dev.coretemp.0.%parent: cpu0 >>>> dev.coretemp.1.%desc: CPU On-Die Thermal Sensors >>>> dev.coretemp.1.%driver: coretemp >>>> dev.coretemp.1.%parent: cpu1 >>>> dev.coretemp.2.%desc: CPU On-Die Thermal Sensors >>>> dev.coretemp.2.%driver: coretemp >>>> dev.coretemp.2.%parent: cpu2 >>>> dev.coretemp.3.%desc: CPU On-Die Thermal Sensors >>>> dev.coretemp.3.%driver: coretemp >>>> dev.coretemp.3.%parent: cpu3 >>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control >>>> dev.est.0.%driver: est >>>> dev.est.0.%parent: cpu0 >>>> dev.est.0.freq_settings: 1867/35000 >>>> dev.est.1.%desc: Enhanced SpeedStep Frequency Control >>>> dev.est.1.%driver: est >>>> dev.est.1.%parent: cpu1 >>>> dev.est.1.freq_settings: 1867/35000 >>>> dev.est.2.%desc: Enhanced SpeedStep Frequency Control >>>> dev.est.2.%driver: est >>>> dev.est.2.%parent: cpu2 >>>> dev.est.2.freq_settings: 1867/35000 >>>> dev.est.3.%desc: Enhanced SpeedStep Frequency Control >>>> dev.est.3.%driver: est >>>> dev.est.3.%parent: cpu3 >>>> dev.est.3.freq_settings: 1867/35000 >>>> dev.cpufreq.0.%driver: cpufreq >>>> dev.cpufreq.0.%parent: cpu0 >>>> dev.cpufreq.1.%driver: cpufreq >>>> dev.cpufreq.1.%parent: cpu1 >>>> dev.cpufreq.2.%driver: cpufreq >>>> dev.cpufreq.2.%parent: cpu2 >>>> dev.cpufreq.3.%driver: cpufreq >>>> dev.cpufreq.3.%parent: cpu3 >>>> dev.p4tcc.0.%desc: CPU Frequency Thermal Control >>>> dev.p4tcc.0.%driver: p4tcc >>>> dev.p4tcc.0.%parent: cpu0 >>>> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>>> 3750/-1 >>>> 2500/-1 1250/-1 >>>> dev.p4tcc.1.%desc: CPU Frequency Thermal Control >>>> dev.p4tcc.1.%driver: p4tcc >>>> dev.p4tcc.1.%parent: cpu1 >>>> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>>> 3750/-1 >>>> 2500/-1 1250/-1 >>>> dev.p4tcc.2.%desc: CPU Frequency Thermal Control >>>> dev.p4tcc.2.%driver: p4tcc >>>> dev.p4tcc.2.%parent: cpu2 >>>> dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>>> 3750/-1 >>>> 2500/-1 1250/-1 >>>> dev.p4tcc.3.%desc: CPU Frequency Thermal Control >>>> dev.p4tcc.3.%driver: p4tcc >>>> dev.p4tcc.3.%parent: cpu3 >>>> dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 >>>> 3750/-1 >>>> 2500/-1 1250/-1 >>>> dev.apic.0.%desc: APIC resources >>>> dev.apic.0.%driver: apic >>>> dev.apic.0.%parent: nexus0 >>>> dev.ipmi.0.%desc: IPMI System Interface >>>> dev.ipmi.0.%driver: ipmi >>>> dev.ipmi.0.%parent: isa0 >>>> dev.orm.0.%desc: ISA Option ROM >>>> dev.orm.0.%driver: orm >>>> dev.orm.0.%parent: isa0 >>>> dev.sc.0.%desc: System console >>>> dev.sc.0.%driver: sc >>>> dev.sc.0.%parent: isa0 >>>> dev.vga.0.%desc: Generic ISA VGA >>>> dev.vga.0.%driver: vga >>>> dev.vga.0.%parent: isa0 >>>> dev.acd.0.%desc: Memorex DVD+-RAM 510L v1/MWS7 >>>> dev.acd.0.%driver: acd >>>> dev.acd.0.%parent: ata0 >>>> dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr >>>> 1 >>>> dev.uhub.0.%driver: uhub >>>> dev.uhub.0.%parent: usbus0 >>>> dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr >>>> 1 >>>> dev.uhub.1.%driver: uhub >>>> dev.uhub.1.%parent: usbus1 >>>> dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr >>>> 1 >>>> dev.uhub.2.%driver: uhub >>>> dev.uhub.2.%parent: usbus2 >>>> dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr >>>> 1 >>>> dev.uhub.3.%driver: uhub >>>> dev.uhub.3.%parent: usbus3 >>>> dev.atapicam.0.%desc: ATAPI CAM Attachment >>>> dev.atapicam.0.%driver: atapicam >>>> dev.atapicam.0.%parent: ata0 >>>> dev.atapicam.1.%desc: ATAPI CAM Attachment >>>> dev.atapicam.1.%driver: atapicam >>>> dev.atapicam.1.%parent: ata2 >>>> dev.atapicam.2.%desc: ATAPI CAM Attachment >>>> dev.atapicam.2.%driver: atapicam >>>> dev.atapicam.2.%parent: ata3 >>>> dev.atapicam.3.%desc: ATAPI CAM Attachment >>>> dev.atapicam.3.%driver: atapicam >>>> dev.atapicam.3.%parent: ata4 >>>> dev.atapicam.4.%desc: ATAPI CAM Attachment >>>> dev.atapicam.4.%driver: atapicam >>>> dev.atapicam.4.%parent: ata5 >>>> dev.atapicam.5.%desc: ATAPI CAM Attachment >>>> dev.atapicam.5.%driver: atapicam >>>> dev.atapicam.5.%parent: ata6 >>>> dev.atapicam.6.%desc: ATAPI CAM Attachment >>>> dev.atapicam.6.%driver: atapicam >>>> dev.atapicam.6.%parent: ata7 >>>> dev.ad.4.%desc: ST3400620AS/3.AAJ >>>> dev.ad.4.%driver: ad >>>> dev.ad.4.%parent: ata2 >>>> dev.ad.6.%desc: ST3400620AS/3.AAJ >>>> dev.ad.6.%driver: ad >>>> dev.ad.6.%parent: ata3 >>>> dev.ad.8.%desc: ST3500630AS/3.AAE >>>> dev.ad.8.%driver: ad >>>> dev.ad.8.%parent: ata4 >>>> dev.ad.10.%desc: ST3400620AS/3.AAJ >>>> dev.ad.10.%driver: ad >>>> dev.ad.10.%parent: ata5 >>>> dev.ad.12.%desc: ST3400620AS/3.AAJ >>>> dev.ad.12.%driver: ad >>>> dev.ad.12.%parent: ata6 >>>> dev.ad.14.%desc: ST3400620AS/3.AAJ >>>> dev.ad.14.%driver: ad >>>> dev.ad.14.%parent: ata7 >>>> dev.ums.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, >>>> addr >>>> 2 >>>> dev.ums.0.%driver: ums >>>> dev.ums.0.%location: port=6 interface=0 >>>> dev.ums.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 >>>> devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" >>>> intclass=0x03 >>>> intsubclass=0x00 >>>> dev.ums.0.%parent: uhub3 >>>> dev.ukbd.0.%desc: Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, >>>> addr 2 >>>> dev.ukbd.0.%driver: ukbd >>>> dev.ukbd.0.%location: port=6 interface=1 >>>> dev.ukbd.0.%pnpinfo: vendor=0x14dd product=0x0002 devclass=0x00 >>>> devsubclass=0x00 sernum="05269e0157450fa9611C11C62A54F306" >>>> intclass=0x03 >>>> intsubclass=0x01 >>>> dev.ukbd.0.%parent: uhub3 >>>> kstat.zfs.misc.arcstats.hits: 1799140 >>>> kstat.zfs.misc.arcstats.misses: 501784 >>>> kstat.zfs.misc.arcstats.demand_data_hits: 575806 >>>> kstat.zfs.misc.arcstats.demand_data_misses: 83877 >>>> kstat.zfs.misc.arcstats.demand_metadata_hits: 949664 >>>> kstat.zfs.misc.arcstats.demand_metadata_misses: 71350 >>>> kstat.zfs.misc.arcstats.prefetch_data_hits: 126189 >>>> kstat.zfs.misc.arcstats.prefetch_data_misses: 326939 >>>> kstat.zfs.misc.arcstats.prefetch_metadata_hits: 147481 >>>> kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19618 >>>> kstat.zfs.misc.arcstats.mru_hits: 1115709 >>>> kstat.zfs.misc.arcstats.mru_ghost_hits: 0 >>>> kstat.zfs.misc.arcstats.mfu_hits: 490457 >>>> kstat.zfs.misc.arcstats.mfu_ghost_hits: 0 >>>> kstat.zfs.misc.arcstats.deleted: 9687 >>>> kstat.zfs.misc.arcstats.recycle_miss: 0 >>>> kstat.zfs.misc.arcstats.mutex_miss: 0 >>>> kstat.zfs.misc.arcstats.evict_skip: 0 >>>> kstat.zfs.misc.arcstats.hash_elements: 546247 >>>> kstat.zfs.misc.arcstats.hash_elements_max: 549954 >>>> kstat.zfs.misc.arcstats.hash_collisions: 396590 >>>> kstat.zfs.misc.arcstats.hash_chains: 160935 >>>> kstat.zfs.misc.arcstats.hash_chain_max: 12 >>>> kstat.zfs.misc.arcstats.p: 9317411840 >>>> kstat.zfs.misc.arcstats.c: 16093925376 >>>> kstat.zfs.misc.arcstats.c_min: 2011740672 >>>> kstat.zfs.misc.arcstats.c_max: 16093925376 >>>> kstat.zfs.misc.arcstats.size: 12788124608 >>>> kstat.zfs.misc.arcstats.hdr_size: 113621248 >>>> kstat.zfs.misc.arcstats.l2_hits: 0 >>>> kstat.zfs.misc.arcstats.l2_misses: 0 >>>> kstat.zfs.misc.arcstats.l2_feeds: 0 >>>> kstat.zfs.misc.arcstats.l2_rw_clash: 0 >>>> kstat.zfs.misc.arcstats.l2_writes_sent: 0 >>>> kstat.zfs.misc.arcstats.l2_writes_done: 0 >>>> kstat.zfs.misc.arcstats.l2_writes_error: 0 >>>> kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 >>>> kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 >>>> kstat.zfs.misc.arcstats.l2_evict_reading: 0 >>>> kstat.zfs.misc.arcstats.l2_free_on_write: 0 >>>> kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 >>>> kstat.zfs.misc.arcstats.l2_cksum_bad: 0 >>>> kstat.zfs.misc.arcstats.l2_io_error: 0 >>>> kstat.zfs.misc.arcstats.l2_size: 0 >>>> kstat.zfs.misc.arcstats.l2_hdr_size: 0 >>>> kstat.zfs.misc.arcstats.memory_throttle_count: 0 >>>> kstat.zfs.misc.vdev_cache_stats.delegations: 19244 >>>> kstat.zfs.misc.vdev_cache_stats.hits: 63137 >>>> kstat.zfs.misc.vdev_cache_stats.misses: 53109 >>>> >>>> Ideas? >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Larry Rosenman                     http://www.lerctr.org/~ler >>>> Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org >>>> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> >>> >>> >> >> -- >> Larry Rosenman                     http://www.lerctr.org/~ler >> Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org >> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> > > > > -- > When bad men combine, the good must associate; else they will fall one > by one, an unpitied sacrifice in a contemptible struggle. > > Edmund Burke > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:15:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 164F7106564A for ; Tue, 19 May 2009 01:15:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id BBCBF8FC12 for ; Tue, 19 May 2009 01:15:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so2218064yxb.13 for ; Mon, 18 May 2009 18:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fOpvR8notW2Or09j3eQctW1H4is7lhpUw4Nq0iykwMc=; b=PW1JJ5NOpcrYb1MQPnCK3Ncn7vHV2Pa4Nbf0HXJQst0MkiV8zz5xJCqyw3UPFrJENN tisSw0erMOXqcJ+4PJPy/zItiOiLi6kCCE0Sgp8DEAoPxDGeUCHWKtojhntIzr2KLiYW EtXe3w6WT2MvlThji7du2oJQjF3xRxzB9g/CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mroP9bGJsxU/+rKQnQVKVGMXTMayeiVRs4daRUSmMcgovHDX9LRlfwf7mHLQwe1C6V XT2CDVWZLOF07HPsX+YPfCiQaF1pddT505/KPxwDNpXfvBJrJqgXnzJ9FaA/k3VwP3UU GXD5P5XnIr7E3MCHUUSMs6edMIODDf7G2jM8c= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.166.13 with SMTP id o13mr9812778ane.103.1242695751864; Mon, 18 May 2009 18:15:51 -0700 (PDT) In-Reply-To: <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> Date: Mon, 18 May 2009 18:15:51 -0700 X-Google-Sender-Auth: 068fd25c37326908 Message-ID: <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> From: Kip Macy To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:15:55 -0000 On Mon, May 18, 2009 at 6:05 PM, Larry Rosenman wrote: > > On Mon, May 18, 2009 8:00 pm, Kip Macy wrote: >> On Mon, May 18, 2009 at 5:06 PM, Larry Rosenman wrote: >>> On Mon, 18 May 2009, Kip Macy wrote: >>> >>>> The ARC cache allocates wired memory. The ARC will grow until there is >>>> vm pressure. >>> >>> My crash this AM was with 4G real, and the ARC seemed to grow and grow, >>> then >>> we started paging, and then crashed. >>> >>> Even with the VM pressure it seemed to grow out of control. >>> >> >> >> >> >> You're running the most recent HEAD? > > Yes. =A0Also, this used to work just fine (as recently as a 8-may-2009 ke= rnel) > with 4G real. > > It used to leave about 2700M free. > > The changes in the last week apparently changed something. > > When I crashed this AM, I re-csup'ed. =A0That's the kernel that's running= now. Please update to r192360 and let me know if that helps. Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:18:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1E69106564A for ; Tue, 19 May 2009 01:18:02 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 65F648FC16 for ; Tue, 19 May 2009 01:18:02 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243146162; Tue, 19 May 2009 04:18:01 +0300 Message-ID: <4A1208C0.2000605@FreeBSD.org> Date: Tue, 19 May 2009 04:17:52 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Andrey References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: [snd_hda][AD1981HD] microphone doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:18:03 -0000 Hi. Andrey wrote: > There is a laptop with Intel HD Audio Controller on board (HDA Codec > AD1981HD) and FreeBSD8.0 CURRENT installed. Unfortunately I can't get > microphone working. (7.2-PRERELEASE had been used before switching to > CURRENT and microphone had been known as working out-of-the-box on that > version of FreeBSD). > > Looking through the list exposed message where similar issue was > reported: > http://www.mailinglistarchive.com/freebsd-current@freebsd.org/msg22832.html > But it looks like requestor didn't provide feedback regarding enclosed > patch. Also, as far as I can judge, that patch is already in CURRENT, > but it seems issue is not solved yet (well, at least I think so). This patch was merged to 7-stable 4 months ago, together with the rest of driver changes. 7.2-PRERELEASE had snd_hda driver almost (or may be even completely) identical to the CURRENT of that time. So I don't understand the difference. To find any difference in driver operation, try to compare verbose dmesg of the driver in working and not working systems. By the way, are you sure that problem is in driver itself? Can't be linuxulator, Skype, settings or whatever else problem? What are you using to record sound? Have you tried to use something trivial like rawrec and rawplay? What microphone are you using: external or internal? Have you tried another one? Are you recording silence or some noise? What mixer settings do you use? PS: Next time, please, put file somewhere. Inlining broke lines, making difficult to read it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:22:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C968E106566B; Tue, 19 May 2009 01:22:03 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5818FC16; Tue, 19 May 2009 01:22:03 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id E17B871F23E; Mon, 18 May 2009 21:22:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n9LQtbC1jF4; Mon, 18 May 2009 21:22:02 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id BFC4071F22E; Mon, 18 May 2009 21:22:02 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id B95D5741; Mon, 18 May 2009 21:22:02 -0400 (EDT) Date: Mon, 18 May 2009 21:22:02 -0400 From: Adam McDougall To: Larry Rosenman Message-ID: <20090519012202.GR82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Kip Macy , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:22:04 -0000 On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: On Mon, 18 May 2009, Kip Macy wrote: > The ARC cache allocates wired memory. The ARC will grow until there is > vm pressure. My crash this AM was with 4G real, and the ARC seemed to grow and grow, then we started paging, and then crashed. Even with the VM pressure it seemed to grow out of control. Ideas? Before that but since 191902 I was having the opposite problem, my ARC and thus Wired would grow up to approx arc_max until my Inactive memory put pressure on ARC making it shrink back down to ~450M where some aspects of performance degraded. A partial workaround was to add a arc_min which isn't entirely successful and I found I could restore ZFS performance by temporarily squeezing down Inactive memory by allocating a bunch of it myself; after freeing that, ARC had no pressure and could grow towards arc_max again until Inactive eventually rose. Reported to Kip last night and some cvs commit lists. I never did run into Swap. From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:26:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A2681065674 for ; Tue, 19 May 2009 01:26:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8188FC13 for ; Tue, 19 May 2009 01:26:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1982637ana.13 for ; Mon, 18 May 2009 18:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=S7wC0CZ8C/chzWfmNWKP1zjx1FDzZirO8Lq1gwLH92U=; b=hBd3ZmN7cB1VXF+fpCIb9U9ffrelreb9S60IziTSaOAZc6USZg9MZ9mm4YrKKODVB6 JIChbw9OSTXpuOrKoH2XDJ5z05DJ26K9slO+CW8aLHmkb1zk9sE1+l8SybOweW034Wai j1aOOm8rSWE80aKCBMW2Ud2JikSzIxRZ/m6mk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kIBUO2EI292pWcpBZt8JCn6p1iIVtmvoRtjg9NZL+Dy896Yr8msW5v3H6+5jtpEJhA 4EqFH93XcAN/1FjHhj8nH0p4NC1Lsz66kCwemQ8KbDJa4iPjgGqR+g20IlB0daAFxrWQ 4dxfEPCInwW3IUmHwSCH2IWDTTVzvTH3vo4uQ= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.46.15 with SMTP id t15mr10063040ant.102.1242696411173; Mon, 18 May 2009 18:26:51 -0700 (PDT) In-Reply-To: <20090519012202.GR82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> Date: Mon, 18 May 2009 18:26:51 -0700 X-Google-Sender-Auth: 057463b1dd1da167 Message-ID: <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> From: Kip Macy To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:26:53 -0000 On Mon, May 18, 2009 at 6:22 PM, Adam McDougall wrot= e: > On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: > > =A0On Mon, 18 May 2009, Kip Macy wrote: > > =A0> The ARC cache allocates wired memory. The ARC will grow until there = is > =A0> vm pressure. > =A0My crash this AM was with 4G real, and the ARC seemed to grow and grow= , then > =A0we started paging, and then crashed. > > =A0Even with the VM pressure it seemed to grow out of control. > > =A0Ideas? > > > Before that but since 191902 I was having the opposite problem, > my ARC and thus Wired would grow up to approx arc_max until my > Inactive memory put pressure on ARC making it shrink back down > to ~450M where some aspects of performance degraded. =A0A partial > workaround was to add a arc_min which isn't entirely successful > and I found I could restore ZFS performance by temporarily squeezing > down Inactive memory by allocating a bunch of it myself; after > freeing that, ARC had no pressure and could grow towards arc_max > again until Inactive eventually rose. =A0Reported to Kip last night > and some cvs commit lists. =A0I never did run into Swap. > That is a separate issue. I'm going to try adding a vm_lowmem event handler to drive reclamation instead of the current paging target. That shouldn't cause inactive pages to shrink the ARC. Most people consider out of the box stability more import than getting the maximum ARC. However, for people like you who want the safety catches removed I should make it possible to disable back-pressure. -Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:57:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85E12106566B; Tue, 19 May 2009 01:57:14 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 470328FC1B; Tue, 19 May 2009 01:57:13 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 8387471F3EA; Mon, 18 May 2009 21:57:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGhWa6itjn4p; Mon, 18 May 2009 21:57:13 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 6037671F3D6; Mon, 18 May 2009 21:57:13 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 5C107743; Mon, 18 May 2009 21:57:13 -0400 (EDT) Date: Mon, 18 May 2009 21:57:13 -0400 From: Adam McDougall To: Kip Macy Message-ID: <20090519015713.GS82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 01:57:14 -0000 On Mon, May 18, 2009 at 06:26:51PM -0700, Kip Macy wrote: On Mon, May 18, 2009 at 6:22 PM, Adam McDougall wrote: > On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: > > ?On Mon, 18 May 2009, Kip Macy wrote: > > ?> The ARC cache allocates wired memory. The ARC will grow until there is > ?> vm pressure. > ?My crash this AM was with 4G real, and the ARC seemed to grow and grow, then > ?we started paging, and then crashed. > > ?Even with the VM pressure it seemed to grow out of control. > > ?Ideas? > > > Before that but since 191902 I was having the opposite problem, > my ARC and thus Wired would grow up to approx arc_max until my > Inactive memory put pressure on ARC making it shrink back down > to ~450M where some aspects of performance degraded. ?A partial > workaround was to add a arc_min which isn't entirely successful > and I found I could restore ZFS performance by temporarily squeezing > down Inactive memory by allocating a bunch of it myself; after > freeing that, ARC had no pressure and could grow towards arc_max > again until Inactive eventually rose. ?Reported to Kip last night > and some cvs commit lists. ?I never did run into Swap. > That is a separate issue. I'm going to try adding a vm_lowmem event handler to drive reclamation instead of the current paging target. That shouldn't cause inactive pages to shrink the ARC. Most people consider out of the box stability more import than getting the maximum ARC. However, for people like you who want the safety catches removed I should make it possible to disable back-pressure. -Kip Thanks, I appreciate all this work. Not allowing inactive pages to shrink the ARC sounds great as an option. I would be willing to bet that allowing inactive pages to shrink the arc would be far less detrimental to most people who aren't running a constant busy file server load, and its definitely important to try to protect untuned boxes. Do you have any suggestions for increasing the amount of memory ARC can use? I've had difficulty increasing kmem past a few gigs on any of my recent builds (all past where kmem was changed so it could be more than ~2g) because at some point the kernel would stop booting. If I increase them too far, a few lines of the booting kernel would print, followed by a long stream of page fault panics or something with a sudden reboot. With the recent change allowing the use of direct mem, the ARC could easily use ample memory except it turned out not to be stable. Thanks again. From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:03:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F60D106566B for ; Tue, 19 May 2009 02:03:46 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 110718FC17 for ; Tue, 19 May 2009 02:03:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1993406ana.13 for ; Mon, 18 May 2009 19:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=DngOhXoHYJdJQXyzxTaKn3qBMqZJdpAwS4mIvrn/Gv0=; b=WS8CaPVUUPFff35JS1mn7eFI8gmPhmTgx893vpQkEtDrvKufjJi6oMJglejkQbiESi qEDW85CiISI3L7CEub/va7nCvgpckeIXbFDyUq8oy3JdYIDo23NJ9Kpai7ZpB0Xv1jcu 1g6R4VqAnRSy6/uakLbLsVpGCcEkIoph3v4j8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v2qDqVqHSMfyZ0RPlRmxPXTzLYstFsV5v5+4RQp/ZqnEUdaP+GLeseCqBZ5j9HfPXX xw0PlyKjX2rGcirSrPK08hoh1ro63WUw2rKGyc4me01zxU8QeuhzvoyYcu83vmhvgDm/ /C+orb8mJEIFL3VbAWy9dNvoTEtYO+lNOqtTg= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.41.9 with SMTP id o9mr10083244ano.155.1242698625150; Mon, 18 May 2009 19:03:45 -0700 (PDT) In-Reply-To: <20090519015713.GS82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <20090519015713.GS82547@egr.msu.edu> Date: Mon, 18 May 2009 19:03:45 -0700 X-Google-Sender-Auth: f9eaeb67df24f644 Message-ID: <3c1674c90905181903o281406fbia135c295738d73b5@mail.gmail.com> From: Kip Macy To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:03:46 -0000 > Thanks, I appreciate all this work. =A0Not allowing inactive pages to > shrink the ARC sounds great as an option. =A0I would be willing to bet > that allowing inactive pages to shrink the arc would be far less > detrimental to most people who aren't running a constant busy file > server load, and its definitely important to try to protect untuned > boxes. Allowing NFS to use ARC buffers might be one solution to that. > Do you have any suggestions for increasing the amount of memory ARC > can use? =A0I've had difficulty increasing kmem past a few gigs on any > of my recent builds (all past where kmem was changed so it could be > more than ~2g) because at some point the kernel would stop booting. > If I increase them too far, a few lines of the booting kernel would > print, followed by a long stream of page fault panics or something > with a sudden reboot. =A0With the recent change allowing the use of > direct mem, the ARC could easily use ample memory except it turned > out not to be stable. As of r192216 that should not be a probably any more. The maximum kmem is now 512GB. It will be at least a year or two before anyone bumps his head against that. From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:13:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15C9106564A; Tue, 19 May 2009 02:13:03 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7013F8FC19; Tue, 19 May 2009 02:13:03 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4J2Cw5R018174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 02:12:59 GMT (envelope-from ben@wanderview.com) Message-Id: <34451C28-9ADF-467B-B2C8-43498C87C0C2@wanderview.com> From: Ben Kelly To: Attilio Rao In-Reply-To: <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 22:12:58 -0400 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org> <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:13:04 -0000 On May 18, 2009, at 1:38 PM, Attilio Rao wrote: > OMG. > This still doesn't explain priorities like 49 or such seen in the > first report as long as we don't set priorities by hand, I'm trying to understand why this particular priority value is so concerning, but I'm a little bit confused. Can you elaborate on why you think its a problem? From previous off-list e-mails I get the impression that you are concerned that it does not fall on an RQ_PPQ boundary. Is this the case? Again, I may be completely confused, but ULE does not seem to consider RQ_PPQ when it assigns priorities for interactive threads. Here is how I came to this conclusion: From what I can tell a thread's priority might be adjusted for interactivity in sched_priority() around line 1421 of sched_ule: > score = imax(0, sched_interact_score(td) - td->td_proc- > >p_nice); > if (score < sched_interact) { > pri = PRI_MIN_REALTIME; > pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) / > sched_interact) > * score; One my machine (PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact resolves to a value of 1. So the priority is being set to PRI_MIN_REALTIME plus the value of score. According to the comment on sched_interact_score() the returned value ranges from 0 to 100. As far as I can tell from looking at the code the calculations based on the ration of ts_runtime to ts_sleeptime aren't guaranteed to return a value divisible by RQ_PPQ. For example, on my machine tickincr turns out to be 8000. So if ts_sleeptime is 16000 and ts_runtime is 8000 sched_interact_score() will return a value of 25. Which then means the thread will be assigned a priority of PRI_MIN_REALTIME + 25. Also, looking at my currently idle system I actually have many priorities that do not fall on RQ_PPQ boundaries: > ianto# ps ax -opri | grep 43 | wc -l > 14 > ianto# ps ax -opri | grep 44 | wc -l > 70 > ianto# ps ax -opri | grep 45 | wc -l > 4 > ianto# ps ax -opri | grep 46 | wc -l > 3 > ianto# ps ax -opri | grep 47 | wc -l > 2 > ianto# ps ax -opri | grep 48 | wc -l > 1 > ianto# ps ax -opri | grep 49 | wc -l > 1 I'm running a non-SMP kernel with ULE last synced with subversion on March 16. Full system info can be found here: http://www.wanderview.com/svn/public/misc/zfs_livelock/ Anyway, I apologize if I'm missing something. I'd be happy to do more investigation if you'd like. Just let me know. Thanks! - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:16:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E9B1065677; Tue, 19 May 2009 02:16:05 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 374398FC0A; Tue, 19 May 2009 02:16:04 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 64F5271F41F; Mon, 18 May 2009 22:16:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubwcatAi8avH; Mon, 18 May 2009 22:16:04 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 1D24671F41E; Mon, 18 May 2009 22:16:04 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 0BB97745; Mon, 18 May 2009 22:16:04 -0400 (EDT) Date: Mon, 18 May 2009 22:16:04 -0400 From: Adam McDougall To: Kip Macy Message-ID: <20090519021603.GT82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <20090519015713.GS82547@egr.msu.edu> <3c1674c90905181903o281406fbia135c295738d73b5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c1674c90905181903o281406fbia135c295738d73b5@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:16:05 -0000 On Mon, May 18, 2009 at 07:03:45PM -0700, Kip Macy wrote: > Thanks, I appreciate all this work. ?Not allowing inactive pages to > shrink the ARC sounds great as an option. ?I would be willing to bet > that allowing inactive pages to shrink the arc would be far less > detrimental to most people who aren't running a constant busy file > server load, and its definitely important to try to protect untuned > boxes. Allowing NFS to use ARC buffers might be one solution to that. That would be interesting. I haven't used ZFS for any NFS serving yet though. With my mix of userspace file serving daemons my Inactive mem just rises 1-3M/sec until almost all free memory is consumed and I don't know why. None of the processes in top or ps can account for 16G of Inactive. > Do you have any suggestions for increasing the amount of memory ARC > can use? ?I've had difficulty increasing kmem past a few gigs on any > of my recent builds (all past where kmem was changed so it could be > more than ~2g) because at some point the kernel would stop booting. > If I increase them too far, a few lines of the booting kernel would > print, followed by a long stream of page fault panics or something > with a sudden reboot. ?With the recent change allowing the use of > direct mem, the ARC could easily use ample memory except it turned > out not to be stable. As of r192216 that should not be a probably any more. The maximum kmem is now 512GB. It will be at least a year or two before anyone bumps his head against that. Ahh oops, I mistakenly thought it was backed out a few minutes ago but that was something else. I guess that gives me something else I can test. A number of changes went in recently and it was hard to tell which commits were causing which symptoms. From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:16:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A11E106567E; Tue, 19 May 2009 02:16:51 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 904438FC0A; Tue, 19 May 2009 02:16:50 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4J2GlK3018213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 02:16:47 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: John Baldwin In-Reply-To: <200905181129.51526.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 22:16:46 -0400 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <20090516031332.GG82547@egr.msu.edu> <5D988481-068A-4AB3-952E-255BEA1D9DA7@wanderview.com> <200905181129.51526.jhb@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:16:51 -0000 On May 18, 2009, at 11:29 AM, John Baldwin wrote: > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: >> 1) It changes the kproc(9) API by adding a kproc_create_priority() >> function that allows you to set the priority of the newly created >> thread. I'm not sure how people feel about this. > > Actually, I almost think we should just add a priority argument to > each of the > routines that creates a new kthread/kproc. Perhaps allow a priority > of 0 to > let the thread run with the default priority. Hmm, it looks like > kthreads > default to running with whatever thread0 runs at (PVM) which is > probably not > really ideal. Having an explicit priority for every kthread would > probably > be best. Most kthreads should probably be at PZERO by default I > think. If this approach was taken would it make sense to use a flag to indicate "use the specified priority" since 0 is a valid priority value? Thanks. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:18:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49151065672 for ; Tue, 19 May 2009 02:18:52 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9759D8FC17 for ; Tue, 19 May 2009 02:18:52 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2234911ywe.13 for ; Mon, 18 May 2009 19:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=glOUUgOKoj+lvcKUbmE7eTbHbkyOKqrMu2GK1BNCaq0=; b=JJreTcFqAfypS2EJ7NsaUdbBFE8QmKppqKzEVC3MFIbA9CDiyN/EgRgwxrR2n5VX0r oOp9g5cHZKbJoX5GhdO37G1RKoQxadMNwZGyYO1Jiiy/ArunS4e/76nWlbms0Y4mp9NP M5OOcsLE/tAJCNuF/jn1meaLkfXOpdcvODQT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GZiIshNdQbCFckRt3x12c1r3ZBjISSt2jhmunOt4WcVcGU6aJ6ckFgZNc46eN30oM0 2bZO046w/fT8Ku8uv1zWpSvfIxiw9BxXAy1g7xT9PoiU4T0ymddbRzaVY564CaUI4sAk +KVtsb/7wRqP8dlYGVh9s9u2m89PW1GoHdQxo= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.12.17 with SMTP id 17mr9907579anl.2.1242699531902; Mon, 18 May 2009 19:18:51 -0700 (PDT) In-Reply-To: <20090519021603.GT82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <20090519015713.GS82547@egr.msu.edu> <3c1674c90905181903o281406fbia135c295738d73b5@mail.gmail.com> <20090519021603.GT82547@egr.msu.edu> Date: Mon, 18 May 2009 19:18:51 -0700 X-Google-Sender-Auth: f4065ac1fa414b33 Message-ID: <3c1674c90905181918n5b4d04cdh4dca2f045c5c70a8@mail.gmail.com> From: Kip Macy To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:18:53 -0000 > Ahh oops, I mistakenly thought it was backed out a few minutes ago > but that was something else. =A0I guess that gives me something else I > can test. =A0A number of changes went in recently and it was hard to tell > which commits were causing which symptoms. > The change backed out was superannuated by the increase in kmem. -Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:35:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDE8106566B; Tue, 19 May 2009 02:35:03 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 107A58FC0C; Tue, 19 May 2009 02:35:02 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4J2Yxi9018393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 02:34:59 GMT (envelope-from ben@wanderview.com) Message-Id: <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> From: Ben Kelly To: Kip Macy In-Reply-To: <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 22:34:58 -0400 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:35:03 -0000 On May 18, 2009, at 9:26 PM, Kip Macy wrote: > On Mon, May 18, 2009 at 6:22 PM, Adam McDougall > wrote: >> On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: >> >> On Mon, 18 May 2009, Kip Macy wrote: >> >> > The ARC cache allocates wired memory. The ARC will grow until >> there is >> > vm pressure. >> My crash this AM was with 4G real, and the ARC seemed to grow and >> grow, then >> we started paging, and then crashed. >> >> Even with the VM pressure it seemed to grow out of control. >> >> Ideas? >> >> >> Before that but since 191902 I was having the opposite problem, >> my ARC and thus Wired would grow up to approx arc_max until my >> Inactive memory put pressure on ARC making it shrink back down >> to ~450M where some aspects of performance degraded. A partial >> workaround was to add a arc_min which isn't entirely successful >> and I found I could restore ZFS performance by temporarily squeezing >> down Inactive memory by allocating a bunch of it myself; after >> freeing that, ARC had no pressure and could grow towards arc_max >> again until Inactive eventually rose. Reported to Kip last night >> and some cvs commit lists. I never did run into Swap. >> > > > That is a separate issue. I'm going to try adding a vm_lowmem event > handler to drive reclamation instead of the current paging target. > That shouldn't cause inactive pages to shrink the ARC. Isn't there already a vm_lowmem event for the arc that triggers reclamation? On the low memory front it seems like the arc needs a way to tell the pager to mark some vnodes inactive. I've seen many cases where the arc size greatly exceeded the target, but it couldn't evict any memory because all its buffers were still referenced. This seems to behave a little better with code that increments vm_pageout_deficit and signals the pageout daemon when the arc is too far above its target. The normal buffer cache seems to do this as well when its low on memory. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:35:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6071065672 for ; Tue, 19 May 2009 02:35:52 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id C1E7F8FC12 for ; Tue, 19 May 2009 02:35:51 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 31705 invoked by uid 1002); 19 May 2009 02:35:49 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.92.196.6) by s217.sureserver.com with ESMTPA; 19 May 2009 02:35:49 -0000 Date: Tue, 19 May 2009 08:08:31 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: Adrian Chadd In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:35:52 -0000 On Mon, 18 May 2009, Adrian Chadd wrote: > I've started documenting (mostly for my own memory for now!) my > experiences getting a working FreeBSD-current Xen environment > together. > > http://wiki.freebsd.org/AdrianChadd/XenHackery > > Notable bits: pygrub works. :) > > Adrian Hi: What is the extent of Dom0 support for FreeBSD 8.x with Xen 3.3.x ? My interest is to run multiple guest OS hosted on a Xen-ified (aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64 box. Any pointers or observations ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:41:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA761065695 for ; Tue, 19 May 2009 02:41:14 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAB28FC16 for ; Tue, 19 May 2009 02:41:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243148055; Tue, 19 May 2009 05:41:12 +0300 Message-ID: <4A121C40.7040201@FreeBSD.org> Date: Tue, 19 May 2009 05:41:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> In-Reply-To: <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------030500010006020409010308" Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:41:15 -0000 This is a multi-part message in MIME format. --------------030500010006020409010308 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Magnus Kling wrote: > Compiled once again. No change. The kernel panics. I don't see obvious problems there. I think something else may erase that controller softc pointer. Can you try to apply attached patch. It may give us some more clues about what is actually become wrong there. May be it is somehow related to the RAID array built on controller. ata-raid part is quite complicated and historically was buggy quite often. Can you instead of your array drives try to attach some other one without any array built or just disable ata-raid module? Are you booting from some other device now? -- Alexander Motin --------------030500010006020409010308 Content-Type: text/plain; name="ata-promise.c.debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ata-promise.c.debug.patch" --- ata-promise.c.prev 2009-05-14 17:57:13.000000000 +0300 +++ ata-promise.c 2009-05-19 05:20:13.000000000 +0300 @@ -1053,6 +1053,15 @@ ata_promise_sx4_command(struct ata_reque { device_t gparent = GRANDPARENT(request->dev); struct ata_pci_controller *ctlr = device_get_softc(gparent); + +if (ctlr == NULL) { + printf("ctlr IS NULL!!!\n"); + device_printf(request->dev, "request->dev\n"); + device_printf(request->parent, "request->parent\n"); + device_printf(device_get_parent(request->dev), "device_get_parent(request->dev)\n"); + device_printf(gparent, "gparent\n"); +} + struct ata_channel *ch = device_get_softc(request->parent); struct ata_dma_prdentry *prd = request->dma->sg; caddr_t window = rman_get_virtual(ctlr->r_res1); --------------030500010006020409010308-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:42:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02FBD1065687; Tue, 19 May 2009 02:42:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id BDFDE8FC20; Tue, 19 May 2009 02:42:13 +0000 (UTC) (envelope-from ler@lerctr.org) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=AcfPEh8ulp2ZPhZBfnRoES3+3EdjqiEiy9ZD85M8CFW8nQMSclIjehiPqrH6OVlKkvwOEXclAzIcIGld8BPIQSHzhuAO9EnS1iudOs4CUAVqW+JadHw3b+HnTjOQpY+WP2yoE8pk4DfcH4F8BEuEdxo6KLjtEv5Gn32J1Ltt/2E=; Received: from localhost.lerctr.org ([127.0.0.1]:56482 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6FHP-000FrF-Sh; Mon, 18 May 2009 21:42:13 -0500 Received: from 76.205.169.61 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Mon, 18 May 2009 21:42:12 -0500 (CDT) Message-ID: <89bf2a3ec987be637c12029a7cd76508.squirrel@webmail.lerctr.org> In-Reply-To: <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> Date: Mon, 18 May 2009 21:42:12 -0500 (CDT) From: "Larry Rosenman" To: "Kip Macy" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -4.3 (----) X-LERCTR-Spam-Score: -4.3 (----) X-Spam-Report: SpamScore (-4.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135 X-LERCTR-Spam-Report: SpamScore (-4.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135 DomainKey-Status: no signature Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:42:14 -0000 On Mon, May 18, 2009 8:15 pm, Kip Macy wrote: > On Mon, May 18, 2009 at 6:05 PM, Larry Rosenman wrote: >> >> On Mon, May 18, 2009 8:00 pm, Kip Macy wrote: >>> On Mon, May 18, 2009 at 5:06 PM, Larry Rosenman wrote: >>>> On Mon, 18 May 2009, Kip Macy wrote: >>>> >>>>> The ARC cache allocates wired memory. The ARC will grow until there >>>>> is >>>>> vm pressure. >>>> >>>> My crash this AM was with 4G real, and the ARC seemed to grow and >>>> grow, >>>> then >>>> we started paging, and then crashed. >>>> >>>> Even with the VM pressure it seemed to grow out of control. >>>> >>> >>> >>> >>> >>> You're running the most recent HEAD? >> >> Yes.  Also, this used to work just fine (as recently as a 8-may-2009 >> kernel) >> with 4G real. >> >> It used to leave about 2700M free. >> >> The changes in the last week apparently changed something. >> >> When I crashed this AM, I re-csup'ed.  That's the kernel that's running >> now. > > > > Please update to r192360 and let me know if that helps. > > > Thanks, > Kip > I've put that code in place. I'm going to let my normal backups etc run. Thanks for the quick patch! LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:45:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FF51065721 for ; Tue, 19 May 2009 02:45:03 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 9793C8FC12 for ; Tue, 19 May 2009 02:45:03 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so2005156ana.13 for ; Mon, 18 May 2009 19:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=YqfBSz+6Q9lkcEczOSX8THHqWiImP9o97xlG4kmM6wM=; b=dsPQAkyOWq68tyUp5rMCuAATiruqNSxwKiQjWOzhdsuT4qtuh4CRbwc/GBONN2Ar4k KbsHK30tOdGIdUNzSlsBO/IPyvS0+paEKpeKNm+YPfz/6pN4EfcVS2GW0bv5Py9wY6cj kGH+k6kYqWqqBB6/7viS0cyzWsQEt0zaI6sFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xXgd/kg2qbCnLn73LxqRzZByKwFqJNZy6L+6vjtoPsa20oKW8mlWtmXQv/VIEAyzWv NC0UUHl852IIuH85HHpP2IXabuewekohueZIaxu6EyWl2cMZ+mfiLxUJe1CjKUXoc1di m9AXLnJYiuyOXtCv06sF6HgNnutGnZJbzoOd0= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.178.3 with SMTP id a3mr5310227anf.59.1242701102812; Mon, 18 May 2009 19:45:02 -0700 (PDT) In-Reply-To: <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> Date: Mon, 18 May 2009 19:45:02 -0700 X-Google-Sender-Auth: f7963ebcdc33872f Message-ID: <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> From: Kip Macy To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 02:45:04 -0000 On Mon, May 18, 2009 at 7:34 PM, Ben Kelly wrote: > On May 18, 2009, at 9:26 PM, Kip Macy wrote: >> >> On Mon, May 18, 2009 at 6:22 PM, Adam McDougall >> wrote: >>> >>> On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: >>> >>> =A0On Mon, 18 May 2009, Kip Macy wrote: >>> >>> =A0> The ARC cache allocates wired memory. The ARC will grow until ther= e is >>> =A0> vm pressure. >>> =A0My crash this AM was with 4G real, and the ARC seemed to grow and gr= ow, >>> then >>> =A0we started paging, and then crashed. >>> >>> =A0Even with the VM pressure it seemed to grow out of control. >>> >>> =A0Ideas? >>> >>> >>> Before that but since 191902 I was having the opposite problem, >>> my ARC and thus Wired would grow up to approx arc_max until my >>> Inactive memory put pressure on ARC making it shrink back down >>> to ~450M where some aspects of performance degraded. =A0A partial >>> workaround was to add a arc_min which isn't entirely successful >>> and I found I could restore ZFS performance by temporarily squeezing >>> down Inactive memory by allocating a bunch of it myself; after >>> freeing that, ARC had no pressure and could grow towards arc_max >>> again until Inactive eventually rose. =A0Reported to Kip last night >>> and some cvs commit lists. =A0I never did run into Swap. >>> >> >> >> That is a separate issue. I'm going to try adding a vm_lowmem event >> handler to drive reclamation instead of the current paging target. >> That shouldn't cause inactive pages to shrink the ARC. > > Isn't there already a vm_lowmem event for the arc that triggers reclamati= on? You're right, there is. I had asked alc if there was a better way than using the paging target and he suggested it. I hadn't looked to see if it was already there because we've had such troubles. > On the low memory front it seems like the arc needs a way to tell the pag= er > to mark some vnodes inactive. =A0I've seen many cases where the arc size > greatly exceeded the target, but it couldn't evict any memory because all > its buffers were still referenced. =A0This seems to behave a little bette= r > with code that increments vm_pageout_deficit and signals the pageout daem= on > when the arc is too far above its target. =A0The normal buffer cache seem= s to > do this as well when its low on memory. Good point. Patches welcome. Otherwise I'll look in to it when I get the ch= ance. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 03:07:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12405106566C; Tue, 19 May 2009 03:07:20 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 863168FC15; Tue, 19 May 2009 03:07:19 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4J37EC9018708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 03:07:14 GMT (envelope-from ben@wanderview.com) Message-Id: <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> From: Ben Kelly To: Kip Macy In-Reply-To: <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 23:07:13 -0400 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 03:07:20 -0000 On May 18, 2009, at 10:45 PM, Kip Macy wrote: > On Mon, May 18, 2009 at 7:34 PM, Ben Kelly wrote: >> On May 18, 2009, at 9:26 PM, Kip Macy wrote: >> On the low memory front it seems like the arc needs a way to tell >> the pager >> to mark some vnodes inactive. I've seen many cases where the arc >> size >> greatly exceeded the target, but it couldn't evict any memory >> because all >> its buffers were still referenced. This seems to behave a little >> better >> with code that increments vm_pageout_deficit and signals the >> pageout daemon >> when the arc is too far above its target. The normal buffer cache >> seems to >> do this as well when its low on memory. > > > Good point. Patches welcome. Otherwise I'll look in to it when I get > the chance. I do some of that in this patch: http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff But I trigger it based on kmem thresholds. See arc_reclaim_pages(). I can try to put together a smaller patch tomorrow evening that signals the pager based on size vs. c target. The main reason I didn't implement it in my previous patch was because I was concerned with the arc being prevented from growing at all once its been shrunk. It only grows when size exceeds its current target by a certain amount. This may require some careful balancing or hysteresis or something. Thanks. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 03:12:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A2E71065670 for ; Tue, 19 May 2009 03:12:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id AC6878FC17 for ; Tue, 19 May 2009 03:12:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2249348ywe.13 for ; Mon, 18 May 2009 20:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=6YHOxTC2JB1Oesiv0Va/w6M6jn1oubJFrJLFTo6r7xU=; b=DO3dVKrQ5s/zZegLK/hMcSkqhfTjhrOfmIhNEHa8mvahehn3NcPaYc+QqOI+/V0/az quBv4scqsjEmya1XyJ2wokg45GbrnqeHPOmFh0ozp70CrBRrb8isPIAMw3Yv0+kkoLUU fOCGFxCpqYl0JqhCcBCgGLDAXK+SMPtsVvl5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SVIbGslRbvLzTvHJ8WedCf64WJdWQsqW03kBmAxOyrPJVT9wZNVq7QyTf8peJsUSBR GVKfvfiOwVcotzZZVVLzOd/Lp0AxnWkeeVPvCOCOHx8HONDN/WDRMNNkvmHuaUv4NhAb 0pNmH/YnJ6/jFhT0VCLsydMoaZz9Jser9jbhg= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.166.13 with SMTP id o13mr10008059ane.103.1242702773075; Mon, 18 May 2009 20:12:53 -0700 (PDT) In-Reply-To: <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> Date: Mon, 18 May 2009 20:12:53 -0700 X-Google-Sender-Auth: 78f791a6d5867fd1 Message-ID: <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@mail.gmail.com> From: Kip Macy To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 03:12:54 -0000 > =A0http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff > > But I trigger it based on kmem thresholds. =A0See arc_reclaim_pages(). > > I can try to put together a smaller patch tomorrow evening that signals t= he > pager based on size vs. c target. =A0The main reason I didn't implement i= t in > my previous patch was because I was concerned with the arc being prevente= d > from growing at all once its been shrunk. =A0It only grows when size exce= eds > its current target by a certain amount. =A0This may require some careful > balancing or hysteresis or something. > I was actually referring to your comment about telling the ARC to tell ZFS to reclaim cached vnodes. Not that the kmem changes aren't good, but I don't think they're necessary on amd64. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 03:49:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4776F106566C for ; Tue, 19 May 2009 03:49:02 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 18D4C8FC0A for ; Tue, 19 May 2009 03:49:01 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n4J3mqbD078580; Mon, 18 May 2009 20:48:52 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id wa6f698vya8x8pttycgstj4m9a; Mon, 18 May 2009 20:48:51 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A122C23.40603@freebsd.org> Date: Mon, 18 May 2009 20:48:51 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Paul Wootton , "'freebsd-current@freebsd.org'" References: <4A1123C5.3070507@fletchermoorland.co.uk> In-Reply-To: <4A1123C5.3070507@fletchermoorland.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 03:49:02 -0000 Paul Wootton wrote: > > I am currently in the process of moving all my data around, going from a > single zfs drive (ex-mirror) to a zfs raidz. > I have used cpio to copy the data to the new pool, but a du shows a big > difference in the results. > > Does anyone have any ideas, or does a "du -h ." not do what I think it > should? ... ... > > demophon# pwd > /DemoPool/var/tmp/kdecache-paul/kpc > demophon# ls -lah > total 1282522 > drwx------ 2 paul paul 25B May 15 19:35 . > drwx------ 11 paul paul 16B May 15 19:36 .. > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index ... ... > demophon# du -h . > 1.2G . > > demophon# pwd > /var/tmp/kdecache-paul/kpc > demophon# ls -lah > total 7833 > drwx------ 2 paul paul 25B May 18 09:37 . > drwx------ 11 paul paul 16B May 18 09:12 .. > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index ... ... > demophon# du -h . > 7.6M . Dmitry Morozovsky wrote: > Ehmm, possibly stupid question: sparse files? Dmitry's probably right here: Files .data/.index are probably some kind of database package, which are often highly sparse files. Try "du -k *" in each of these directories to see how much disk space is actually allocated to each file; that would verify that file sparseness is at issue here. Tim From owner-freebsd-current@FreeBSD.ORG Tue May 19 03:52:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92425106564A; Tue, 19 May 2009 03:52:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 20C828FC08; Tue, 19 May 2009 03:52:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2394236qwe.7 for ; Mon, 18 May 2009 20:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Z3quKB8KH3HJeVHtzJ9aE3mgzf82DOKVAEZwfOeU/pk=; b=qsiWW/EadudZZRHvqgP9tShLXsmz5b515FHauZ+qgKp+XWFcnIzooDv9PYiCH4h2Lk UQHCRpXTtaC4ljDxDIie6N2vE3f7rXT6aGilKVoIjLDQnlrPYUCNzsZQ2qq6DSzyvsMl PGPfVpuc5xFecN8MNk9RPPpdfn+8gfTPbC2rY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NBNrU2SglVb17X/hW2nzdcuLp5jJ6wd9e4Y14OhsZPS0iC13dkFPpipGN/NYhNWyKP EQkvkpfbc6zt3vrq0EkJvfqZHUSJ80jVgxhHHgQwMQaiOt7gbnYKJSvl4+mwm8RO3I1i ZmyB0eV6mFH5YQHjWSBxcKBxhdj5v6jtv5dX0= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.82.83 with SMTP id a19mr3260113qcl.42.1242705155565; Mon, 18 May 2009 20:52:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2009 11:52:35 +0800 X-Google-Sender-Auth: 57568e0970ba6570 Message-ID: From: Adrian Chadd To: Saifi Khan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 03:52:37 -0000 I don't think there's any support for Dom0 stuff in FreeBSD. http://wiki.freebsd.org/FreeBSD/Xen has further information about what is and isn't supported at this time. Adrian 2009/5/19 Saifi Khan : > On Mon, 18 May 2009, Adrian Chadd wrote: > >> I've started documenting (mostly for my own memory for now!) my >> experiences getting a working FreeBSD-current Xen environment >> together. >> >> http://wiki.freebsd.org/AdrianChadd/XenHackery >> >> Notable bits: pygrub works. :) >> >> Adrian > > Hi: > > What is the extent of Dom0 support for FreeBSD 8.x with Xen > 3.3.x ? > > My interest is to run multiple guest OS hosted on a Xen-ified > (aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64 > box. > > Any pointers or observations ? > > > thanks > Saifi. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 19 04:24:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73907106566C for ; Tue, 19 May 2009 04:24:16 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id E16408FC1B for ; Tue, 19 May 2009 04:24:15 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 4932 invoked by uid 1002); 19 May 2009 04:24:13 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.92.196.6) by s217.sureserver.com with ESMTPA; 19 May 2009 04:24:13 -0000 Date: Tue, 19 May 2009 09:56:54 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: Adrian Chadd In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 04:24:16 -0000 On Tue, 19 May 2009, Adrian Chadd wrote: > I don't think there's any support for Dom0 stuff in FreeBSD. > > http://wiki.freebsd.org/FreeBSD/Xen has further information about what > is and isn't supported at this time. > > Adrian > > 2009/5/19 Saifi Khan : > > On Mon, 18 May 2009, Adrian Chadd wrote: > > > >> I've started documenting (mostly for my own memory for now!) my > >> experiences getting a working FreeBSD-current Xen environment > >> together. > >> > >> http://wiki.freebsd.org/AdrianChadd/XenHackery > >> > >> Notable bits: pygrub works. :) > >> > >> Adrian > > > > Hi: > > > > What is the extent of Dom0 support for FreeBSD 8.x with Xen > > 3.3.x ? > > > > My interest is to run multiple guest OS hosted on a Xen-ified > > (aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64 > > box. > > > > Any pointers or observations ? > > Hi Adrian: Thank you for the clarification about "no dom0 support in FreeBSD 8.x as of now". Yes, i did visit the wiki link couple of months ago and in fact dropped a mail to Kip as well :) there was no response, guess he was busy. i'd be thankful, if you could share your observations about the following: . is dom0 support something that FreeBSD will target at some point in time or would be happy to be domU ? . there was some mention of vimage/bitvisor in one of the slides (i think on scribd.com). So, is it that jails getting extended to support virtualization+containers and thus a entirely different approach which does not use Xen ? . is it envisaged that a stable NetBSD dom0 implementation would then be ported to FreeBSD (maybe) ? Thank you for your time. thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Tue May 19 04:50:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F119106566C for ; Tue, 19 May 2009 04:50:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 325988FC0C for ; Tue, 19 May 2009 04:50:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-019-074.pools.arcor-ip.net [88.66.19.74]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MKv5w-1M6H5l2MS0-0001V0; Tue, 19 May 2009 06:38:17 +0200 Received: (qmail 12714 invoked from network); 19 May 2009 04:38:17 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.188) by router.laiers.local with SMTP; 19 May 2009 04:38:17 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 19 May 2009 06:37:02 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc3-ARCH; KDE/4.2.3; x86_64; ; ) References: <4A1123C5.3070507@fletchermoorland.co.uk> <4A122C23.40603@freebsd.org> In-Reply-To: <4A122C23.40603@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190637.03323.max@love2party.net> X-Provags-ID: V01U2FsdGVkX191/ajN6BraL85u3roZzE3fcofmqvO+QSdCHcJ 8CXOCfP7rVIgv6CPiIJNzEcDhdaS0mc5oKAfXbAZi/x7BWjl/5 exdthZmeYzU2m2WkVDO1Q== Cc: Tim Kientzle , Paul Wootton Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 04:50:54 -0000 On Tuesday 19 May 2009 05:48:51 Tim Kientzle wrote: > Paul Wootton wrote: > > I am currently in the process of moving all my data around, going > > from a single zfs drive (ex-mirror) to a zfs raidz. > > I have used cpio to copy the data to the new pool, but a du shows a > > big difference in the results. > > > > Does anyone have any ideas, or does a "du -h ." not do what I think > > it should? > > ... ... > > > demophon# pwd > > /DemoPool/var/tmp/kdecache-paul/kpc > > demophon# ls -lah > > total 1282522 > > drwx------ 2 paul paul 25B May 15 19:35 . > > drwx------ 11 paul paul 16B May 15 19:36 .. > > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index > > ... ... > > > demophon# du -h . > > 1.2G . > > > > demophon# pwd > > /var/tmp/kdecache-paul/kpc > > demophon# ls -lah > > total 7833 > > drwx------ 2 paul paul 25B May 18 09:37 . > > drwx------ 11 paul paul 16B May 18 09:12 .. > > -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data > > -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index > > ... ... > > > demophon# du -h . > > 7.6M . > > Dmitry Morozovsky wrote: > > Ehmm, possibly stupid question: sparse files? > > Dmitry's probably right here: Files .data/.index are > probably some kind of database package, which are > often highly sparse files. > > Try "du -k *" in each of these directories to see > how much disk space is actually allocated to each file; > that would verify that file sparseness is at issue here. You can also use "du -hA ." to get the apparent size. But, as I assume that "/DemoPool" is the destination and "/var" is the source of your cpio copy, it is quite obvious that sparse files are in play at the source. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Tue May 19 05:07:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E9F1065670; Tue, 19 May 2009 05:07:07 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 69C518FC17; Tue, 19 May 2009 05:07:07 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2086111rvb.43 for ; Mon, 18 May 2009 22:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=0rQd6Rfby+qViaW7Q5isBjSu65N7MByWR7VqkxSnu2A=; b=Uht47GtvCI13OAVGfgcq9n6IaUja1JFmJ1QLq/85GOnkyflMF+tDCNFf4FcynO4f6L GtubaidVgOOWpRYxKf2otH4nho5wiBXiZD+NjXJgMfVcyTOMlb7ROnbHqXXkr0sJmSHr nVOt9i6+fpMoYnQRrcpmGD9V6Kw3U6jyQzZTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=HI0uhRuGB/5NQLl1ip8xCeqbZpK/pLq8BSe54WtTSJENPZUObpaNgRO7unZ2NKhNuK 5qrjsXSCsXwwAAPFdNn2sbV7hRZaS0HKMViitaGZjJrcQrBS+k0CrAmvn5dZxo9/kdCg Ksj5ETtj+w4uv9gsyE07Q6ey/qqaJdNZKIozM= Received: by 10.141.28.4 with SMTP id f4mr2631226rvj.164.1242709298631; Mon, 18 May 2009 22:01:38 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id f21sm15304181rvb.5.2009.05.18.22.01.36 (version=SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 22:01:37 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Tue, 19 May 2009 14:01:33 +0900 From: Weongyo Jeong Date: Tue, 19 May 2009 14:01:32 +0900 To: Sam Leffler Message-ID: <20090519050132.GE42412@weongyo.cdnetworks.kr> Mail-Followup-To: Sam Leffler , Lucius Windschuh , current@freebsd.org References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0F419A.2020700@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Lucius Windschuh , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:07:08 -0000 On Sat, May 16, 2009 at 03:43:38PM -0700, Sam Leffler wrote: > Lucius Windschuh wrote: > > 2009/4/7 Weongyo Jeong > > > >> Hello, > >> > >> FYI uath(4) driver has been committed into HEAD. To work with uath(4) > >> it needs to load the firmware using uathload. The example would be as > >> follows: > >> > >> # kldload if_uath > >> [plugin Atheros USB stick] > >> ugen0.2: at usbus0 > >> # uathload -d /dev/ugen0.2 > >> [after downloading the firmware it'll retry to attach] > >> # ifconfig uath0 > >> > >> Normally uathload could be found at /usr/sbin or > >> /usr/src/usr.sbin/uathload for sources and if you don't want to execute > >> uathload by hand it'd be better to add a entry into devd.conf(5). > > > > Thanks for porting the driver. > > This is not a port of anyone else's driver. > > > > I tried it with a TRENDnet TEW-504UB/EU on CURRENT as of today. > > But there are a couple of problems with that device: > > 1. Different product ID > > My TEW-504UB/EU becomes 0x3207 after loading the firmware. OK, this one is > > easy to fix: > > Index: sys/dev/usb/usbdevs > > =================================================================== > > --- sys/dev/usb/usbdevs (revision 192196) > > +++ sys/dev/usb/usbdevs (working copy) > > @@ -2425,6 +2425,7 @@ > > product UMEDIA ALL0298V2 0x3204 ALL0298 v2 > > product UMEDIA AR5523_2 0x3205 AR5523 > > product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) > > +product UMEDIA AR5523_3 0x3207 AR5523 > > > > /* Universal Access products */ > > product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter > > Index: sys/dev/usb/wlan/if_uath.c > > =================================================================== > > --- sys/dev/usb/wlan/if_uath.c (revision 192196) > > +++ sys/dev/usb/wlan/if_uath.c (working copy) > > @@ -192,6 +192,7 @@ > > UATH_DEV(NETGEAR3, WPN111), > > UATH_DEV(UMEDIA, TEW444UBEU), > > UATH_DEV(UMEDIA, AR5523_2), > > + UATH_DEV(UMEDIA, AR5523_3), > > UATH_DEV(WISTRONNEWEB, AR5523_1), > > UATH_DEV(WISTRONNEWEB, AR5523_2), > > UATH_DEV(ZCOM, AR5523) > > > > I don't know why this device has another product ID with a loaded firmware, > > but perhaps because it is an 802.11a capable device? > > The device works by changing identity once the firmware is downloaded. > One id is for the stick w/o fw and one for the stick w/ fw loaded and > running. > > > BTW: the vendor's firmware leads to the known ID (0x3205), but uath bails > > out: > > uath0: timeout waiting for reply to cmd 0x1 (1) > > uath0: could not initialize adapter > > device_attach: uath0 attach returned 35 > > uath0: timeout waiting for reply to cmd 0x1 (1) > > uath0: could not initialize adapter > > device_attach: uath0 attach returned 35 > > ugen4.2: at usbus4 (disconnected) > > ugen4.2: at usbus4 > > You must use the freebsd fw w/ the freebsd driver. > > > > > So, now to the second problem: > > The device works like a charm in 802.11b/g mode (ifconfig wlan0 chanlist > > 1-13) with FreeBSD's firmware. > > But 802.11a scanning does not work. Without the chanlist restrictiong, I get > > the following messages: > > (plug in the device) > > ugen4.2: at usbus4 > > (uathload) > > ugen4.2: at usbus4 (disconnected) > > ugen4.2: at usbus4 > > (ifconfig wlan create wlandev uath0) > > wlan0: Ethernet address: 00:14:d1:c0:23:5f > > (ifconfig wlan0 up) > > uath0: uath_cmdsend: empty inactive queue > > uath0: could not init Tx queues, error 55 > > uath0: uath_cmdsend: empty inactive queue > > uath0: could not set channel, error 55 > > [...] > > uath0: could not set channel, error 55 > > uath0: uath_cmdsend: empty inactive queue > > uath0: could not write register 0x08 > > uath0: uath_cmdsend: empty inactive queue > > uath0: could not set channel, error 55 > > uath0: could not switch channel > > I'd like to provide additional debugging information. If you need more, > > please tell me what. > > Known problem. Weongoy didn't have a dual-band stick and I never had > time to track down why 5Ghz channels failed. > > > BTW: Could you add a message declaring the device when it is plugged in? > > Something like "uath0: on usbus?" > > and "uath0: ether aa:bb:cc:dd:ee:ff"? > > I thought it did this but perhaps not; we can try to add it. IIRC in the previous USB1, it printed a message like uath0: on usbus? whenever a device is attached even if the device source doesn't print it but it's not now in USB2. I have no ideas it's a intention or a regression of USB2. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Tue May 19 05:10:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDCC01065680; Tue, 19 May 2009 05:10:51 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 98E178FC19; Tue, 19 May 2009 05:10:51 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id D2330FF10; Tue, 19 May 2009 17:10:50 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA1aVi5L6Xi4; Tue, 19 May 2009 17:10:46 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 19 May 2009 17:10:46 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id C38C511434; Tue, 19 May 2009 17:10:45 +1200 (NZST) Date: Mon, 18 May 2009 22:10:45 -0700 From: Andrew Thompson To: Sam Leffler , Lucius Windschuh , current@freebsd.org Message-ID: <20090519051045.GD78829@citylink.fud.org.nz> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> <20090519050132.GE42412@weongyo.cdnetworks.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090519050132.GE42412@weongyo.cdnetworks.kr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Hans Petter Selasky Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:10:52 -0000 On Tue, May 19, 2009 at 02:01:32PM +0900, Weongyo Jeong wrote: > > > > > BTW: Could you add a message declaring the device when it is plugged in? > > > Something like "uath0: on usbus?" > > > and "uath0: ether aa:bb:cc:dd:ee:ff"? > > > > I thought it did this but perhaps not; we can try to add it. > > IIRC in the previous USB1, it printed a message like > > uath0: on usbus? > > whenever a device is attached even if the device source doesn't print > it but it's not now in USB2. I have no ideas it's a intention or a > regression of USB2. This is because USB2 sets the quiet flag on the device (for better or worse) and relies on the driver calling device_set_usb2_desc(). I am not sure the reason for doing it this way. Andrew From owner-freebsd-current@FreeBSD.ORG Tue May 19 05:11:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927F510656A7 for ; Tue, 19 May 2009 05:11:53 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 558AF8FC2F for ; Tue, 19 May 2009 05:11:53 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2086949rvb.43 for ; Mon, 18 May 2009 22:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=TTQK5ec0rMYgfz0H9XDpWDMtkEUGqQ6S2TCc0Qa+xqI=; b=XcTdyf/YHda0vjAdnzm0SBuFxSHIs5an5KvytfePimMq/6qcjZ5PyLpHxv1PWYPzC2 xPR/9X2TEViCKLEa7WgasHv51Csgv0N3bcknCJaXtQYG5D1TS9K40Dh7HBLkKcSjb+Yb TM9hgMpDB/qmFa4QKYJK/WOHkWfc7O8C6DM0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=sOsz+yTzit0sF8OKAsTaaH0AcM+VhBkQH8qsxFiKTrMyaYFuXidOFttRwbeAOuyc+H bBNiQicKGkOTtMCiT5SKQega9597N7bSG6OIw/o13wMOjv+FWy3VyoXc/9eA19YYAJYm 1DU7xz5zU4oDxEThWfHphCQsWyXdp1WNlWWGA= Received: by 10.141.43.19 with SMTP id v19mr2744432rvj.226.1242708586546; Mon, 18 May 2009 21:49:46 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id b8sm15088017rvf.4.2009.05.18.21.49.44 (version=SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 21:49:46 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Tue, 19 May 2009 13:49:41 +0900 From: Weongyo Jeong Date: Tue, 19 May 2009 13:49:41 +0900 To: Lucius Windschuh Message-ID: <20090519044941.GC42412@weongyo.cdnetworks.kr> Mail-Followup-To: Lucius Windschuh , freebsd-current@freebsd.org, Hans Petter Selasky References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <200905181050.03154.hselasky@c2i.net> <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:11:54 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 19, 2009 at 12:08:45AM +0200, Lucius Windschuh wrote: > 2009/5/18 Hans Petter Selasky : > > Regarding the first panic, there seems to be a detach race in both upgt and > > uath, which is not USB related. Try this patch: > > > > http://perforce.freebsd.org/chv.cgi?CH=162250 > > This fixes not only the first panic. > I can't provoke any panic by pulling out the active device. Thanks. Could you please test with this patch that is slightly different with Hans's patch? It try to unsetup after stopping the device. If no problems I'd commit it. regards, Weongyo Jeong --BXVAT5kNtrzKuDFl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_uath_20090519.diff" Index: if_uath.c =================================================================== --- if_uath.c (revision 192368) +++ if_uath.c (working copy) @@ -517,12 +517,12 @@ sc->sc_flags |= UATH_FLAG_INVALID; uath_stop(ifp); - ieee80211_ifdetach(ic); callout_drain(&sc->stat_ch); callout_drain(&sc->watchdog_ch); usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS); + ieee80211_ifdetach(ic); /* free buffers */ UATH_LOCK(sc); --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 05:17:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A581065672; Tue, 19 May 2009 05:17:21 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id CB7A38FC21; Tue, 19 May 2009 05:17:20 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2087831rvb.43 for ; Mon, 18 May 2009 22:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=tUTcHp0MptQyejTkvStvEabX1bOWcBeB9zvlcmKH1Cg=; b=Uhrlz/an66Ikuigf3rRbGE/MNRmThtLF8CGLvgAHukS9BylRb0zfd+sw3mTO/1vhb4 U0soX8cbRnabGnenjPPRaWtdNioZUiNJRHiIy9OEx/OnSlRmzEVuLAoDTuYey8OKyq1M qNWCdHuH1cL09LO0pWOuLEt6O6T44Vn3UGu9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=bEeg0tfq0kgu8b+7EQEt4GBsWiMbVXCcKt/1DpIJwLbU6fgwnd3EFS+CM1BaEeVJ14 qJYhlDZdK3+k8mssH3AeYHbBdCGUsxkkbMNJU5RCVsUKAD0EoERRsrPehor73KJf7x+i tMclaO3yYjzL0RF7rD6u2r9DUTWcDxEkBWRRQ= Received: by 10.141.29.11 with SMTP id g11mr2606021rvj.17.1242708931586; Mon, 18 May 2009 21:55:31 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id g31sm15237519rvb.13.2009.05.18.21.55.18 (version=SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 21:55:19 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Tue, 19 May 2009 13:55:14 +0900 From: Weongyo Jeong Date: Tue, 19 May 2009 13:55:14 +0900 To: Lucius Windschuh Message-ID: <20090519045514.GD42412@weongyo.cdnetworks.kr> Mail-Followup-To: Lucius Windschuh , Sam Leffler , current@freebsd.org References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> <4A106B49.4020809@freebsd.org> <90a5caac0905171510v17441d4na51a059f72f7ecae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90a5caac0905171510v17441d4na51a059f72f7ecae@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Sam Leffler , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:17:21 -0000 On Mon, May 18, 2009 at 12:10:27AM +0200, Lucius Windschuh wrote: > Thanks for the commits. > > But... I forgot one thing: kldunload if_uath ; kldload if_uath on a > firmware-loaded device leads to this output: > > uath0: timeout waiting for reply to cmd 0x1 (1) > uath0: could not initialize adapter > device_attach: uath0 attach returned 35 > uath0: timeout waiting for reply to cmd 0x1 (1) > uath0: could not initialize adapter > device_attach: uath0 attach returned 35 > > Is this also a known problem? Perhaps yes but it's some complicate to describe how it could be fixed. Could you please file a PR for this issue? I'll try to look a HAL for uath(4) and find a method to solve it. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Tue May 19 05:33:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621BB106566B for ; Tue, 19 May 2009 05:33:32 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 266418FC0C for ; Tue, 19 May 2009 05:33:32 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2090509rvb.43 for ; Mon, 18 May 2009 22:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=LSbncjB4tEPCs4xMc+ukO6oxgOG+hQZGzlWUmYHIC04=; b=PyS+3cGjFnyGrVjoUhGY+n+zhAelPpMZoTG6BEydfiChYNxQidp/Ne44D/Wck2jWQD +j2X4b0TiEl3zqK17zza51uPf2cg0wdRbcCzOBSWAJbBM/cLBgqSd6wQWiP7H2BhNg1i uZp92Kn0DheN3R2e23dn1ndPiW1Uh3EZiMiRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=JKsU2SFNINsaBf+R0oF2wRRsrkS07DxKpfIvzLIiSvWeS1bAanEBRZGl1K405Z/ZWe +BGL+KGg5QlX5a2X7Q0pM9nrWrXVH/lB4kYqFkUMapFyS1izru4E9tgQVgnUjkxBhWF+ AG4PnZbAY78OcRSUFigbCTGLa/DUJnk9xkrd0= Received: by 10.140.173.17 with SMTP id v17mr2651892rve.3.1242711211847; Mon, 18 May 2009 22:33:31 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id g31sm15352877rvb.33.2009.05.18.22.33.30 (version=SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 22:33:31 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Tue, 19 May 2009 14:33:26 +0900 From: Weongyo Jeong Date: Tue, 19 May 2009 14:33:26 +0900 To: Hans Petter Selasky Message-ID: <20090519053326.GF42412@weongyo.cdnetworks.kr> Mail-Followup-To: Hans Petter Selasky , freebsd-current@freebsd.org, Lucius Windschuh References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <200905182349.06150.hselasky@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <200905182349.06150.hselasky@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Lucius Windschuh , freebsd-current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:33:32 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 18, 2009 at 11:49:05PM +0200, Hans Petter Selasky wrote: > On Sunday 17 May 2009, Lucius Windschuh wrote: > > 2009/4/7 Weongyo Jeong > > > > Here's one more device, which is currently not listed in if_uath.c: > > ugen3.10: at usbus3, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x00ff > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x1385 > idProduct = 0x5f01 > bcdDevice = 0x0001 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 <1.0> > bNumConfigurations = 0x0001 > > Resulting dmesg after running uathload: > > uath0: timeout waiting for reply to cmd 0x4 (4) > uath0: could not read capability 2 > uath0: could not get device capabilities > device_attach: uath0 attach returned 35 > uath0: timeout waiting for reply to cmd 0x1 (1) > uath0: could not initialize adapter > device_attach: uath0 attach returned 35 > > Can this be fixed? Because I don't have WPN111 stick which failed to buy in my local store I couldn't test it fully but one thing you can try is that adding some delays for each usb commands could be helpful like a attached patch. Could you please test with attached patch and show results? I think you can increase or decrease delay values or add delays at other places. regards, Weongyo Jeong --WYTEVAkct0FjGQmd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_uath_20090519_wpn111.diff" Index: if_uath.c =================================================================== --- if_uath.c (revision 192371) +++ if_uath.c (working copy) @@ -392,6 +392,7 @@ device_printf(sc->sc_dev, "could not initialize adapter\n"); goto fail3; } + usb2_pause_mtx(NULL, 500); error = uath_get_devcap(sc); if (error != 0) { device_printf(sc->sc_dev, @@ -842,6 +843,7 @@ uath_get_devcap(struct uath_softc *sc) { #define GETCAP(x, v) do { \ + usb2_pause_mtx(NULL, 200); \ error = uath_get_capability(sc, x, &v); \ if (error != 0) \ return (error); \ --WYTEVAkct0FjGQmd-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 06:51:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A07B106564A; Tue, 19 May 2009 06:51:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 898578FC08; Tue, 19 May 2009 06:51:44 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bvA9ArPTLE4A:10 a=wUE4w7GWRSwA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=5zm0jQc0V6eMfDCqFC0A:9 a=pBpX1mZlgZ7NZOZMHouGml9Aw6QA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 500290261; Tue, 19 May 2009 08:51:42 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 19 May 2009 08:54:17 +0200 User-Agent: KMail/1.9.7 References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <20090519050132.GE42412@weongyo.cdnetworks.kr> <20090519051045.GD78829@citylink.fud.org.nz> In-Reply-To: <20090519051045.GD78829@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190854.17888.hselasky@c2i.net> Cc: Lucius Windschuh , Sam Leffler , Andrew Thompson Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 06:51:45 -0000 On Tuesday 19 May 2009, Andrew Thompson wrote: > On Tue, May 19, 2009 at 02:01:32PM +0900, Weongyo Jeong wrote: > > > > BTW: Could you add a message declaring the device when it is plugged > > > > in? Something like "uath0: > > > > on usbus?" and "uath0: ether aa:bb:cc:dd:ee:ff"? > > > > > > I thought it did this but perhaps not; we can try to add it. > > > > IIRC in the previous USB1, it printed a message like > > > > uath0: on usbus? > > > > whenever a device is attached even if the device source doesn't print > > it but it's not now in USB2. I have no ideas it's a intention or a > > regression of USB2. > > This is because USB2 sets the quiet flag on the device (for better or > worse) and relies on the driver calling device_set_usb2_desc(). > > I am not sure the reason for doing it this way. > Did you run uathload? There should be an ugen entry for your device. --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 19 06:53:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A1D10656C6; Tue, 19 May 2009 06:53:21 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 19EE38FC24; Tue, 19 May 2009 06:53:16 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so4481786ewy.43 for ; Mon, 18 May 2009 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AYYGm/+EmgbQacDWzm3Pou4FK8l7x1A9TiygH2SbOaE=; b=nCGdHKPS98KDOOhcv580hL/sWkBGRoamSE+k5NTJU78o+Xp5nNI9Ibfxe9f4d1NrNq bQJ6dXRNyn5e+gDYPKGakjJYdZ6Uls7BXF0h0izGUw3Cs5tcg6fz+C3tMchBR4TmLJ/s 0T7vlHbMalyjyJqGIkMci+sg/Yh6W8UShzAYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=klZTLCm+smlkFp4one8iOcs9SpRuTPRVlQ1vpzr/M9tguCex5BYH7SAdKIAdH/Wbph 4++IdP8bdFHqi/266YOnDbp667vFwqFf/M1Bch4yZ0kMp3jAwR8r5iMhN4k51dgRR3W/ NXjPbTGc5SD92Kz84mFaEYJsKpyxYoMzhKB0I= MIME-Version: 1.0 Received: by 10.216.36.209 with SMTP id w59mr2382116wea.67.1242715995913; Mon, 18 May 2009 23:53:15 -0700 (PDT) In-Reply-To: <4A121C40.7040201@FreeBSD.org> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> Date: Tue, 19 May 2009 08:53:15 +0200 Message-ID: <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 06:53:21 -0000 2009/5/19 Alexander Motin > Magnus Kling wrote: > >> Compiled once again. No change. The kernel panics. >> > > I don't see obvious problems there. I think something else may erase that > controller softc pointer. Can you try to apply attached patch. It may giv= e > us some more clues about what is actually become wrong there. > > May be it is somehow related to the RAID array built on controller. > ata-raid part is quite complicated and historically was buggy quite often= . > Can you instead of your array drives try to attach some other one without > any array built or just disable ata-raid module? Are you booting from som= e > other device now? > > -- > Alexander Motin > > --- ata-promise.c.prev 2009-05-14 17:57:13.000000000 +0300 > +++ ata-promise.c 2009-05-19 05:20:13.000000000 +0300 > @@ -1053,6 +1053,15 @@ ata_promise_sx4_command(struct ata_reque > { > device_t gparent =3D GRANDPARENT(request->dev); > struct ata_pci_controller *ctlr =3D device_get_softc(gparent); > + > +if (ctlr =3D=3D NULL) { > + printf("ctlr IS NULL!!!\n"); > + device_printf(request->dev, "request->dev\n"); > + device_printf(request->parent, "request->parent\n"); > + device_printf(device_get_parent(request->dev), > "device_get_parent(request->dev)\n"); > + device_printf(gparent, "gparent\n"); > +} > + > struct ata_channel *ch =3D device_get_softc(request->parent); > struct ata_dma_prdentry *prd =3D request->dma->sg; > caddr_t window =3D rman_get_virtual(ctlr->r_res1); > > I applied the patch and rebuilt the kernel. But when should this be printed= ? At shutdown or boot? I can=B4t see it at all. When panic occurs I got the attached text as output on my serial console. The raidcontroller has two ata disks attached. Using RAID 1. My OS is on a separate disk using the motherboards ata connector. Should I disable(unplug the disks) and add a spare harddrive in non-raid state to the raid card? /magnus From owner-freebsd-current@FreeBSD.ORG Tue May 19 07:04:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7623106564A; Tue, 19 May 2009 07:04:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 841E08FC15; Tue, 19 May 2009 07:04:19 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bvA9ArPTLE4A:10 a=wUE4w7GWRSwA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=zi9OGOCMt8tPEm5n8G8A:9 a=88j6B-HObUJzsuNtZooidDr8ykIA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 191653686; Tue, 19 May 2009 09:04:17 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org User-Agent: KMail/1.9.7 References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <20090519050132.GE42412@weongyo.cdnetworks.kr> <20090519051045.GD78829@citylink.fud.org.nz> In-Reply-To: <20090519051045.GD78829@citylink.fud.org.nz> MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 19 May 2009 09:06:52 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905190906.53413.hselasky@c2i.net> Cc: Lucius Windschuh , Sam Leffler , Andrew Thompson Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:04:20 -0000 Hi, There is no call to: device_set_usb2_desc() In the attach method. --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 19 07:08:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C93E1065670 for ; Tue, 19 May 2009 07:08:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id A79098FC15 for ; Tue, 19 May 2009 07:08:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=x01RqrcTYZgA:10 a=bYLFNfMPybAA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=Ds2_JaYoDQwa8IFOgrgA:9 a=js8qjCAYeXs5wEw1lYR-R-wmlGAA:4 a=9aOQ2cSd83gA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 497318872; Tue, 19 May 2009 09:08:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Weongyo Jeong Date: Tue, 19 May 2009 09:11:01 +0200 User-Agent: KMail/1.9.7 References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> <20090519044941.GC42412@weongyo.cdnetworks.kr> In-Reply-To: <20090519044941.GC42412@weongyo.cdnetworks.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190911.01576.hselasky@c2i.net> Cc: Lucius Windschuh Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:08:28 -0000 On Tuesday 19 May 2009, Weongyo Jeong wrote: > On Tue, May 19, 2009 at 12:08:45AM +0200, Lucius Windschuh wrote: > > 2009/5/18 Hans Petter Selasky : > > > Regarding the first panic, there seems to be a detach race in both upgt > > > and uath, which is not USB related. Try this patch: > > > > > > http://perforce.freebsd.org/chv.cgi?CH=162250 > > > > This fixes not only the first panic. > > I can't provoke any panic by pulling out the active device. Thanks. > > Could you please test with this patch that is slightly different with > Hans's patch? It try to unsetup after stopping the device. > > If no problems I'd commit it. > > regards, > Weongyo Jeong Hi, I had added the wrong ID to the driver. Now it seems to almost work. What does the following error code mean? When I run wpa_cli I see some valid scan results. I have not tried to associate yet. uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 uath0: uath_cmdsend: empty inactive queue uath0: could not set channel, error 55 --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 19 07:13:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 407DE106566B; Tue, 19 May 2009 07:13:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3F88FC18; Tue, 19 May 2009 07:13:31 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bvA9ArPTLE4A:10 a=wUE4w7GWRSwA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=CyWKLIYsxORaQ4kLUoMA:9 a=8FV6X3cD4_zixixAc18A:7 a=IuTLT4YC31xa1QjFY3Zjl8AR1yMA:4 a=MSl-tDqOz04A:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1243722361; Tue, 19 May 2009 09:13:30 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Weongyo Jeong Date: Tue, 19 May 2009 09:16:05 +0200 User-Agent: KMail/1.9.7 References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <4A0F419A.2020700@freebsd.org> <20090519050132.GE42412@weongyo.cdnetworks.kr> In-Reply-To: <20090519050132.GE42412@weongyo.cdnetworks.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190916.06460.hselasky@c2i.net> Cc: Lucius Windschuh , Sam Leffler Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:13:33 -0000 On Tuesday 19 May 2009, Weongyo Jeong wrote: > On Sat, May 16, 2009 at 03:43:38PM -0700, Sam Leffler wrote: > > Lucius Windschuh wrote: > > > 2009/4/7 Weongyo Jeong > > > > > >> Hello, > > >> > > >> FYI uath(4) driver has been committed into HEAD. To work with uath(4) > > >> it needs to load the firmware using uathload. The example would be as > > >> follows: > > >> > > >> # kldload if_uath > > >> [plugin Atheros USB stick] > > >> ugen0.2: at usbus0 > > >> # uathload -d /dev/ugen0.2 > > >> [after downloading the firmware it'll retry to attach] > > >> # ifconfig uath0 > > >> > > >> Normally uathload could be found at /usr/sbin or > > >> /usr/src/usr.sbin/uathload for sources and if you don't want to > > >> execute uathload by hand it'd be better to add a entry into > > >> devd.conf(5). > > > > > > Thanks for porting the driver. > > > > This is not a port of anyone else's driver. > > > > > I tried it with a TRENDnet TEW-504UB/EU on CURRENT as of today. > > > But there are a couple of problems with that device: > > > 1. Different product ID > > > My TEW-504UB/EU becomes 0x3207 after loading the firmware. OK, this one > > > is easy to fix: > > > Index: sys/dev/usb/usbdevs > > > =================================================================== > > > --- sys/dev/usb/usbdevs (revision 192196) > > > +++ sys/dev/usb/usbdevs (working copy) > > > @@ -2425,6 +2425,7 @@ > > > product UMEDIA ALL0298V2 0x3204 ALL0298 v2 > > > product UMEDIA AR5523_2 0x3205 AR5523 > > > product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) > > > +product UMEDIA AR5523_3 0x3207 AR5523 > > > > > > /* Universal Access products */ > > > product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter > > > Index: sys/dev/usb/wlan/if_uath.c > > > =================================================================== > > > --- sys/dev/usb/wlan/if_uath.c (revision 192196) > > > +++ sys/dev/usb/wlan/if_uath.c (working copy) > > > @@ -192,6 +192,7 @@ > > > UATH_DEV(NETGEAR3, WPN111), > > > UATH_DEV(UMEDIA, TEW444UBEU), > > > UATH_DEV(UMEDIA, AR5523_2), > > > + UATH_DEV(UMEDIA, AR5523_3), > > > UATH_DEV(WISTRONNEWEB, AR5523_1), > > > UATH_DEV(WISTRONNEWEB, AR5523_2), > > > UATH_DEV(ZCOM, AR5523) > > > > > > I don't know why this device has another product ID with a loaded > > > firmware, but perhaps because it is an 802.11a capable device? > > > > The device works by changing identity once the firmware is downloaded. > > One id is for the stick w/o fw and one for the stick w/ fw loaded and > > running. > > > > > BTW: the vendor's firmware leads to the known ID (0x3205), but uath > > > bails out: > > > uath0: timeout waiting for reply to cmd 0x1 (1) > > > uath0: could not initialize adapter > > > device_attach: uath0 attach returned 35 > > > uath0: timeout waiting for reply to cmd 0x1 (1) > > > uath0: could not initialize adapter > > > device_attach: uath0 attach returned 35 > > > ugen4.2: at usbus4 (disconnected) > > > ugen4.2: at usbus4 > > > > You must use the freebsd fw w/ the freebsd driver. > > > > > So, now to the second problem: > > > The device works like a charm in 802.11b/g mode (ifconfig wlan0 > > > chanlist 1-13) with FreeBSD's firmware. > > > But 802.11a scanning does not work. Without the chanlist restrictiong, > > > I get the following messages: > > > (plug in the device) > > > ugen4.2: at usbus4 > > > (uathload) > > > ugen4.2: at usbus4 (disconnected) > > > ugen4.2: at usbus4 > > > (ifconfig wlan create wlandev uath0) > > > wlan0: Ethernet address: 00:14:d1:c0:23:5f > > > (ifconfig wlan0 up) > > > uath0: uath_cmdsend: empty inactive queue > > > uath0: could not init Tx queues, error 55 > > > uath0: uath_cmdsend: empty inactive queue > > > uath0: could not set channel, error 55 > > > [...] > > > uath0: could not set channel, error 55 > > > uath0: uath_cmdsend: empty inactive queue > > > uath0: could not write register 0x08 > > > uath0: uath_cmdsend: empty inactive queue > > > uath0: could not set channel, error 55 > > > uath0: could not switch channel > > > I'd like to provide additional debugging information. If you need more, > > > please tell me what. > > > > Known problem. Weongoy didn't have a dual-band stick and I never had > > time to track down why 5Ghz channels failed. > > > > > BTW: Could you add a message declaring the device when it is plugged > > > in? Something like "uath0: on > > > usbus?" and "uath0: ether aa:bb:cc:dd:ee:ff"? > > > > I thought it did this but perhaps not; we can try to add it. > > IIRC in the previous USB1, it printed a message like > > uath0: on usbus? > > whenever a device is attached even if the device source doesn't print > it but it's not now in USB2. I have no ideas it's a intention or a > regression of USB2. > > regards, > Weongyo Jeong > Fix here: http://perforce.freebsd.org/chv.cgi?CH=162306 --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 19 07:51:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B17D106564A for ; Tue, 19 May 2009 07:51:06 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DE7098FC23 for ; Tue, 19 May 2009 07:51:05 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 243169293; Tue, 19 May 2009 10:51:05 +0300 Message-ID: <4A1264E8.2080707@FreeBSD.org> Date: Tue, 19 May 2009 10:51:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> In-Reply-To: <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:51:06 -0000 Magnus Kling wrote: > I applied the patch and rebuilt the kernel. But when should this be > printed? At shutdown or boot? I can´t see it at all. On shutdown before panic. > When panic occurs I got the attached text as output on my serial console. Attached where? > The raidcontroller has two ata disks attached. Using RAID 1. My OS is on > a separate disk using the motherboards ata connector. > Should I disable(unplug the disks) and add a spare harddrive in non-raid > state to the raid card? Yes, I mean this exactly. Unplug your disk and insert some another without building RAID on it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue May 19 08:43:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C1CC106566B for ; Tue, 19 May 2009 08:43:36 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E4AB08FC18 for ; Tue, 19 May 2009 08:43:35 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DB29C346131; Tue, 19 May 2009 04:43:34 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 19 May 2009 04:43:34 -0400 X-Sasl-enc: ZvmNZnQ4DQa7ODPX0d+wjSIoEwiBKyxxKltZLTr1KSge 1242722614 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4A31822B96; Tue, 19 May 2009 04:43:34 -0400 (EDT) Message-ID: <4A127134.9060908@incunabulum.net> Date: Tue, 19 May 2009 09:43:32 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lucius Windschuh References: <90a5caac0905171159g23198d7ej71afb349abe9ab79@mail.gmail.com> In-Reply-To: <90a5caac0905171159g23198d7ej71afb349abe9ab79@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: [lor] if_afdata and mld_mtx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 08:43:36 -0000 Hi, Known issue, we need consensus on what to do about the KAME scope lock and indeed if_afdata lock. cheers BMS From owner-freebsd-current@FreeBSD.ORG Tue May 19 08:44:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC89106568C; Tue, 19 May 2009 08:44:53 +0000 (UTC) (envelope-from ivoras@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 10CC88FC15; Tue, 19 May 2009 08:44:51 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so1136750eyd.7 for ; Tue, 19 May 2009 01:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=x1/t/ZJ7Ytx0LCzp9HbzIzSl26sBbYxR7sANE/60iuA=; b=r5U2wZvx3FJOr9PrfG9fsBfxiBPv1k3GmW8wyyv3IPagE5hvt7gfh3aoeALQueVCh+ 0FapUTyteml1Ao/rllNd+K/0hh6AjTxFDF4gNkDretrhc1Aqo3Rw6zocCBwKPwtmbaRj 8iCJWpoLY4xsf/dZbr/OQI/fbTJ3nGXzf1/bU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=x3B7759xfI/bvK+bl82MVaL7tDDCqzxCQBtWL9tQzmtIcJo6YwfQkj/V4FQoT4IpOu WbpqepuryK6+AMZJzzS5Q8v1eYvUXDCrhCO4C5jg5VDtsyWh7sSeos6++9OFl9CVygzH 1zmMjBW7GVCXmqppEH9PRRK2uRw0l6buQxJaA= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.127.13 with SMTP id z13mr8810819ebc.10.1242722691134; Tue, 19 May 2009 01:44:51 -0700 (PDT) In-Reply-To: References: From: Ivan Voras Date: Tue, 19 May 2009 10:44:31 +0200 X-Google-Sender-Auth: 0cbe6cb0968f6697 Message-ID: <9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com> To: Saifi Khan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-xen@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 08:44:53 -0000 2009/5/19 Saifi Khan : > =C2=A0. is dom0 support something that FreeBSD will target at some > =C2=A0 point in time or would be happy to be domU ? I cannot speak for the developers but at BSDCan it was stated that dom0 would be a large chunk of job that deserves funding. The developers are interested. > =C2=A0. there was some mention of vimage/bitvisor in one of the > =C2=A0 slides (i think on scribd.com). So, is it that jails getting > =C2=A0 extended to support virtualization+containers and thus a > =C2=A0 entirely different approach which does not use Xen ? VIMAGE and jails are OS-level virtualization, orthogonal to Xen. http://en.wikipedia.org/wiki/Operating_system-level_virtualization > =C2=A0. is it envisaged that a stable NetBSD dom0 implementation > =C2=A0 would then be ported to FreeBSD (maybe) ? Probably not - the systems are too different now. From owner-freebsd-current@FreeBSD.ORG Tue May 19 09:13:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1BB3106564A; Tue, 19 May 2009 09:13:15 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 91B448FC15; Tue, 19 May 2009 09:13:15 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id D932B4AC5D; Tue, 19 May 2009 11:13:10 +0200 (CEST) Date: Tue, 19 May 2009 11:13:10 +0200 From: Martin Wilke To: ports@FreeBSD.org Message-ID: <20090519091310.GB71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20090517180920.GY71804@bsdcrew.de> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:13:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howdy .. Next run, We updated the port to 2.2.2r19801. The Patch files/patch-amd64-r0-exec-alloc was removed in favor of a similar fix commited to upstream. Also was fixed a bug on HEAD which should be fix the Kernel crash. Please test test test .. :-) PS: Yes this run is for AMD64 and HEAD users! http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz Happy Testing! - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu =LoBM -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 09:40:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A1731065690 for ; Tue, 19 May 2009 09:40:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 99BAE8FC1E for ; Tue, 19 May 2009 09:40:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz9 with SMTP id 9so3693273bwz.43 for ; Tue, 19 May 2009 02:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=97cL/o2aZ830nhuCiiGzqvm3aKKB1vbDm372YywhXls=; b=c+s4nZ5jfoEr5YVqZoJAsy3EDNwr+iu1kC0vskC2rN+pscQiO4my1w8QDGLLyycC7n Nx0wqAi8AsbFJn4RxFhWRDoqbcKSPgmy2BVE0ANWkdD68GFTeY8xJ1svDwly7nNbJmpT iiAVY40ZD0g4QbyLNLel+4zLqva0nPf/GVQQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=McqGESbGVB6MABY1Fhv3Y4EiMSv9tDZeBRdzF/C4iaUTdgeFtX1c0sSRyTnZkUUAA1 EhdckkISlygY9tbJ1t/2hisQd1/yJK9aEeo6A6H0V1eddWlU5z+wlTy5k7QEI6jzN5uK 2LzPAzjR/z7Gwejsk+qxTWxVP39KzHHzM3sNc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.109.198 with SMTP id k6mr5038251fap.46.1242726040790; Tue, 19 May 2009 02:40:40 -0700 (PDT) In-Reply-To: <34451C28-9ADF-467B-B2C8-43498C87C0C2@wanderview.com> References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org> <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> <34451C28-9ADF-467B-B2C8-43498C87C0C2@wanderview.com> Date: Tue, 19 May 2009 11:40:40 +0200 X-Google-Sender-Auth: 25449e0fd90ceea6 Message-ID: <3bbf2fe10905190240g3e6dd267nf1621ca4e54d7a85@mail.gmail.com> From: Attilio Rao To: Ben Kelly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:40:44 -0000 2009/5/19 Ben Kelly : > On May 18, 2009, at 1:38 PM, Attilio Rao wrote: >> >> OMG. >> This still doesn't explain priorities like 49 or such seen in the >> first report as long as we don't set priorities by hand, > > I'm trying to understand why this particular priority value is so > concerning, but I'm a little bit confused. =C2=A0Can you elaborate on why= you > think its a problem? =C2=A0From previous off-list e-mails I get the impre= ssion > that you are concerned that it does not fall on an RQ_PPQ boundary. =C2= =A0Is this > the case? =C2=A0Again, I may be completely confused, but ULE does not see= m to > consider RQ_PPQ when it assigns priorities for interactive threads. =C2= =A0Here is > how I came to this conclusion: I'm concerned because the first starvation I saw in this thread was caused by the proprity lowered inappropriately (it was 49 on 45 IIRC). 49 means that the thread will never be choosen when the 45s are still in the runqueue. I'm not concerned on RQ_PPQ boundaries. > From what I can tell a thread's priority might be adjusted for interactiv= ity > in sched_priority() around line 1421 of sched_ule: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0score =3D imax(0, sched_interact_score(td) - = td->td_proc->p_nice); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (score < sched_interact) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pri =3D PRI_MIN_R= EALTIME; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pri +=3D ((PRI_MA= X_REALTIME - PRI_MIN_REALTIME) / >> sched_interact) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* s= core; > > One my machine (PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact > resolves to a value of 1. =C2=A0So the priority is being set to PRI_MIN_R= EALTIME > plus the value of score. =C2=A0According to the comment on sched_interact= _score() > the returned value ranges from 0 to 100. =C2=A0As far as I can tell from = looking > at the code the calculations based on the ration of ts_runtime to > ts_sleeptime aren't guaranteed to return a value divisible by RQ_PPQ. =C2= =A0For > example, on my machine tickincr turns out to be 8000. =C2=A0So if ts_slee= ptime is > 16000 and ts_runtime is 8000 sched_interact_score() will return a value o= f > 25. =C2=A0Which then means the thread will be assigned a priority of > PRI_MIN_REALTIME + 25. > > Also, looking at my currently idle system I actually have many priorities > that do not fall on RQ_PPQ boundaries: > >> ianto# ps ax -opri | grep 43 | wc -l >> =C2=A0 =C2=A0 =C2=A014 >> ianto# ps ax -opri | grep 44 | wc -l >> =C2=A0 =C2=A0 =C2=A070 >> ianto# ps ax -opri | grep 45 | wc -l >> =C2=A0 =C2=A0 =C2=A0 4 >> ianto# ps ax -opri | grep 46 | wc -l >> =C2=A0 =C2=A0 =C2=A0 3 >> ianto# ps ax -opri | grep 47 | wc -l >> =C2=A0 =C2=A0 =C2=A0 2 >> ianto# ps ax -opri | grep 48 | wc -l >> =C2=A0 =C2=A0 =C2=A0 1 >> ianto# ps ax -opri | grep 49 | wc -l >> =C2=A0 =C2=A0 =C2=A0 1 > > I'm running a non-SMP kernel with ULE last synced with subversion on Marc= h > 16. =C2=A0 Full system info can be found here: > > =C2=A0http://www.wanderview.com/svn/public/misc/zfs_livelock/ > > Anyway, I apologize if I'm missing something. =C2=A0I'd be happy to do mo= re > investigation if you'd like. =C2=A0Just let me know. I still need to check the ktr/datas you sent me that time, I just need to find the time to do that, sorry. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue May 19 09:54:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C7F106567A for ; Tue, 19 May 2009 09:54:51 +0000 (UTC) (envelope-from pascal.braun@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 634238FC1D for ; Tue, 19 May 2009 09:54:50 +0000 (UTC) (envelope-from pascal.braun@continum.net) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.73]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6LfN-0000HB-5T for freebsd-current@freebsd.org; Tue, 19 May 2009 11:31:21 +0200 Message-ID: <4A127C56.6040502@continum.net> Date: Tue, 19 May 2009 11:31:02 +0200 From: Pascal Braun User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with jumbo frames on nfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:54:52 -0000 Hi, I'm currently testing jumbo frames on a Sunfire 4540 running with FreeBSD 8-Current (build on April 8th). While using the nfe driver I'm having some unexpected problems if i try to bring up the interface with MTU sizes greater than 1970 bytes. The error message (in dmesg) is: nfe2: initialization failed: no memory for rx buffers I tried to deactivate checksum offloading with -rxcsum -txcsum, but that didn't help either. If I change the mtu size on-the-fly without bringing the interface down first, no error is logged. But the interface just isn't working. Does anyone have any ideas how to get jumbo frames working? Regards Pascal -- pciconf -lv -- nfe0@pci0:0:8:0: class=0x068000 card=0xcb8410de chip=0x037310de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Ethernet' class = bridge nfe1@pci0:0:9:0: class=0x068000 card=0xcb8410de chip=0x037310de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Ethernet' class = bridge nfe2@pci0:64:8:0: class=0x068000 card=0xcb8410de chip=0x037310de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Ethernet' class = bridge nfe3@pci0:64:9:0: class=0x068000 card=0xcb8410de chip=0x037310de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Ethernet' class = bridge From owner-freebsd-current@FreeBSD.ORG Tue May 19 09:56:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D45F106568A; Tue, 19 May 2009 09:56:37 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id F033F8FC15; Tue, 19 May 2009 09:56:36 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n4J9uZG2098916; Tue, 19 May 2009 10:56:35 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A128253.7040400@fletchermoorland.co.uk> Date: Tue, 19 May 2009 10:56:35 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: Martin Wilke References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:56:38 -0000 Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! > > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 > RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu > =LoBM > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > Hi, Im still having build issues. This is the same issue I get when compiling this and the last 2 revisions. Have you got any ideas? Cheers Paul demophon# uname -a FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Mon May 18 10:13:13 BST 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 demophon# kBuild: Generating tstVMStructSize - /root/vBox/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.amd64/release/obj/VMM/tstAsmStructsHC.h /root/vBox/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/root/vBox/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/root/vBox/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs.... awk: can't open file /root/vBox/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def source line number 10 objcopy --strip-debug /root/vBox/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko kmk[2]: Leaving directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19801' kmk[2]: Entering directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19801' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19801' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 Stop in /root/vBox/virtualbox. demophon# From owner-freebsd-current@FreeBSD.ORG Tue May 19 10:21:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F231065670 for ; Tue, 19 May 2009 10:21:24 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id BAB558FC08 for ; Tue, 19 May 2009 10:21:23 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n4JALMYM099474; Tue, 19 May 2009 11:21:22 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A128822.9030709@fletchermoorland.co.uk> Date: Tue, 19 May 2009 11:21:22 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: Max Laier References: <4A1123C5.3070507@fletchermoorland.co.uk> <4A122C23.40603@freebsd.org> <200905190637.03323.max@love2party.net> In-Reply-To: <200905190637.03323.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:21:24 -0000 Max Laier wrote: > On Tuesday 19 May 2009 05:48:51 Tim Kientzle wrote: > >> Paul Wootton wrote: >> >>> I am currently in the process of moving all my data around, going >>> from a single zfs drive (ex-mirror) to a zfs raidz. >>> I have used cpio to copy the data to the new pool, but a du shows a >>> big difference in the results. >>> >>> Does anyone have any ideas, or does a "du -h ." not do what I think >>> it should? >>> >> ... ... >> >> >>> demophon# pwd >>> /DemoPool/var/tmp/kdecache-paul/kpc >>> demophon# ls -lah >>> total 1282522 >>> drwx------ 2 paul paul 25B May 15 19:35 . >>> drwx------ 11 paul paul 16B May 15 19:36 .. >>> -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data >>> -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index >>> >> ... ... >> >> >>> demophon# du -h . >>> 1.2G . >>> >>> demophon# pwd >>> /var/tmp/kdecache-paul/kpc >>> demophon# ls -lah >>> total 7833 >>> drwx------ 2 paul paul 25B May 18 09:37 . >>> drwx------ 11 paul paul 16B May 18 09:12 .. >>> -rw-r--r-- 1 paul paul 5.0M May 6 16:47 kapman_cache.data >>> -rw-r--r-- 1 paul paul 1.3M May 6 16:47 kapman_cache.index >>> >> ... ... >> >> >>> demophon# du -h . >>> 7.6M . >>> >> Dmitry Morozovsky wrote: >> > Ehmm, possibly stupid question: sparse files? >> >> Dmitry's probably right here: Files .data/.index are >> probably some kind of database package, which are >> often highly sparse files. >> >> Try "du -k *" in each of these directories to see >> how much disk space is actually allocated to each file; >> that would verify that file sparseness is at issue here. >> > > You can also use "du -hA ." to get the apparent size. But, as I assume > that "/DemoPool" is the destination and "/var" is the source of your cpio > copy, it is quite obvious that sparse files are in play at the source. > > Yes /DemoPool is a raidz pool that is going to replace my single disk pool. Dmitry was right about sparse files demophon# pwd /var/tmp/kdecache-paul/kpc demophon# du -hA . 1.2G . demophon# du -h . 8.9M . Is there a there a better way instead of using cpio for moving an entire filing system from a single disk zfs pool to a raidz zfs pool? Or does making a sparse file in to a none sparse file just consume more disk space and no other side affects Cheers Paul From owner-freebsd-current@FreeBSD.ORG Tue May 19 10:23:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB83106564A; Tue, 19 May 2009 10:23:32 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 880478FC1A; Tue, 19 May 2009 10:23:31 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n4JANStJ004663; Tue, 19 May 2009 12:23:29 +0200 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009051912232796:110367 ; Tue, 19 May 2009 12:23:27 +0200 Message-ID: <4A128891.6010504@entel.upc.edu> Date: Tue, 19 May 2009 12:23:13 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <4A128253.7040400@fletchermoorland.co.uk> In-Reply-To: <4A128253.7040400@fletchermoorland.co.uk> X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 19/05/2009 12:23:28, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 19/05/2009 12:23:29, Serialize complete at 19/05/2009 12:23:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 19 May 2009 12:23:29 +0200 (CEST) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:23:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Wootton wrote: > Martin Wilke wrote: Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. The Patch > files/patch-amd64-r0-exec-alloc was removed in favor of a similar > fix commited to upstream. Also was fixed a bug on HEAD which should > be fix the Kernel crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! > Reporting, For my system : FreeBSD portatil 8.0-CURRENT FreeBSD 8.0-CURRENT #40: Mon May 18 09:09:07 CEST 2009 gus@gusiport:/usr/obj/usr/src/sys/CUSTOM i386 the second run problem (when virtualbox argued about the missing kernel support) has dissapeared. The only problem is that when I try to start the virtual machine, its screen remains gray. Any hint about this particular problem ? Any has an idea where the problem can be, to start looking for a solution ? Moreover, will try to try :) in CURRENT-AMD64 in the same. Will take me long, cause I think I wipe the installation some time ago :( Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoSiJEACgkQAvcpDulVChDw6gCfRFgAxLfLBW5P5HfcKhAa9J3e 4koAn0Scteq4oWU3MSDtWU1T3v0lGipE =eTer -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 10:36:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA055106566B for ; Tue, 19 May 2009 10:36:10 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61B5C8FC1A for ; Tue, 19 May 2009 10:36:10 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n4JAa0SP016010; Tue, 19 May 2009 12:36:00 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n4JAa0wu016009; Tue, 19 May 2009 12:36:00 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Tue, 19 May 2009 12:35:59 +0200 From: Ruben de Groot To: Paul Wootton Message-ID: <20090519103559.GA15608@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Paul Wootton , Max Laier , freebsd-current@freebsd.org References: <4A1123C5.3070507@fletchermoorland.co.uk> <4A122C23.40603@freebsd.org> <200905190637.03323.max@love2party.net> <4A128822.9030709@fletchermoorland.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A128822.9030709@fletchermoorland.co.uk> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Tue, 19 May 2009 12:36:03 +0200 (CEST) Cc: Max Laier , freebsd-current@freebsd.org Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:36:14 -0000 On Tue, May 19, 2009 at 11:21:22AM +0100, Paul Wootton typed: > > > Yes /DemoPool is a raidz pool that is going to replace my single disk > pool. Dmitry was right about sparse files > demophon# pwd > /var/tmp/kdecache-paul/kpc > demophon# du -hA . > 1.2G . > demophon# du -h . > 8.9M . > > Is there a there a better way instead of using cpio for moving an entire > filing system from a single disk zfs pool to a raidz zfs pool? > Or does making a sparse file in to a none sparse file just consume more > disk space and no other side affects zfs send/recv ? Ruben From owner-freebsd-current@FreeBSD.ORG Tue May 19 10:52:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326431065673 for ; Tue, 19 May 2009 10:52:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id F3DD18FC17 for ; Tue, 19 May 2009 10:52:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2147677rvb.43 for ; Tue, 19 May 2009 03:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Jz+kxlYck8S4CLDrDhGt6KcTO+oAtCX9OEC9gwEBkAs=; b=T+iGYVWPXCGZPjl8R6mrS1Fb5jyC3S9yXn4x4icjFrYaqSwDV5/lMD6b7D6WYaWIay 4anHSZdFIMHccGOL6KHMu2Tzd2436DwWAN0mGRHakd0MHDex7uGlbXGmH4fkQ09aJbD3 MmpWmcJQPcTkI4hwY9De3AQ+Pc8yH0qvuHcqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=azi5dlfQnoBjCEESOEwRCNNjZxxU+o0wIcN/j7nlc6YMUnN6vDN0QMMgTBoY8Z8/yP SQxFz8gwNEm6MjWjgznTG80hCBS0T0zNKnekY+fn4JVlJ8I5iUZJ4W5YkvSX0oy4/C0X Jc/RN0jFuHt82xSmYCrixZnW9khjZD4qXXaxY= Received: by 10.141.137.8 with SMTP id p8mr2782524rvn.27.1242729108542; Tue, 19 May 2009 03:31:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id g14sm15916327rvb.52.2009.05.19.03.31.46 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 03:31:47 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Tue, 19 May 2009 19:41:33 +0900 From: Pyun YongHyeon Date: Tue, 19 May 2009 19:41:33 +0900 To: Pascal Braun Message-ID: <20090519104133.GF4697@michelle.cdnetworks.co.kr> References: <4A127C56.6040502@continum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A127C56.6040502@continum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Problems with jumbo frames on nfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:52:24 -0000 On Tue, May 19, 2009 at 11:31:02AM +0200, Pascal Braun wrote: > Hi, > > I'm currently testing jumbo frames on a Sunfire 4540 running with > FreeBSD 8-Current (build on April 8th). While using the nfe driver I'm > having some unexpected problems if i try to bring up the interface with > MTU sizes greater than 1970 bytes. > > The error message (in dmesg) is: > nfe2: initialization failed: no memory for rx buffers > It means you've run out of jumbo clusters. Check the output of "netstat -m" and see how many jumbo cluster requests were denied. > I tried to deactivate checksum offloading with -rxcsum -txcsum, but that > didn't help either. > Yeah, that has nothing to do with jumbo frame support. > If I change the mtu size on-the-fly without bringing the interface down > first, no error is logged. But the interface just isn't working. > nfe(4) is smart enough not to allocate jumbo clusters if interface is DOWN. > Does anyone have any ideas how to get jumbo frames working? > How about increasing 9K jumbo clusters(kern.ipc.nmbjumbo9) with sysctl(8)? > Regards > Pascal From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:04:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02C6E1065676; Tue, 19 May 2009 11:04:24 +0000 (UTC) (envelope-from carl.gustavsson@bahnhofbredband.se) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by mx1.freebsd.org (Postfix) with ESMTP id AEBD88FC0A; Tue, 19 May 2009 11:04:23 +0000 (UTC) (envelope-from carl.gustavsson@bahnhofbredband.se) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 219FC14C226; Tue, 19 May 2009 12:33:06 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mpgAKx-FCz30; Tue, 19 May 2009 12:32:54 +0200 (CEST) Received: from munin.home.swe (c213-100-49-247.swipnet.se [213.100.49.247]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E8DA514C137; Tue, 19 May 2009 12:32:53 +0200 (CEST) Message-ID: <4A120C48.8030709@bahnhofbredband.se> Date: Tue, 19 May 2009 03:32:56 +0200 From: Carl Johan Gustavsson User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: Martin Wilke References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:04:24 -0000 Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! > > Hi, It seems as this version has solved the problems I had with the earlier versions, it hung my machine when starting the VM. I'm running i386 HEAD. Now I'm able to install and boot 32bit Ubuntu and the performance seems very nice. Great job! cjg > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 > RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu > =LoBM > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:14:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20C9106564A; Tue, 19 May 2009 11:14:25 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 645E58FC15; Tue, 19 May 2009 11:14:25 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4JBEKtL025680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 11:14:21 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: Attilio Rao In-Reply-To: <3bbf2fe10905190240g3e6dd267nf1621ca4e54d7a85@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 07:14:20 -0400 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org> <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> <34451C28-9ADF-467B-B2C8-43498C87C0C2@wanderview.com> <3bbf2fe10905190240g3e6dd267nf1621ca4e54d7a85@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:14:26 -0000 On May 19, 2009, at 5:40 AM, Attilio Rao wrote: > 2009/5/19 Ben Kelly : >> On May 18, 2009, at 1:38 PM, Attilio Rao wrote: >>> >>> OMG. >>> This still doesn't explain priorities like 49 or such seen in the >>> first report as long as we don't set priorities by hand, >> >> I'm trying to understand why this particular priority value is so >> concerning, but I'm a little bit confused. Can you elaborate on >> why you >> think its a problem? From previous off-list e-mails I get the >> impression >> that you are concerned that it does not fall on an RQ_PPQ >> boundary. Is this >> the case? Again, I may be completely confused, but ULE does not >> seem to >> consider RQ_PPQ when it assigns priorities for interactive >> threads. Here is >> how I came to this conclusion: > > I'm concerned because the first starvation I saw in this thread was > caused by the proprity lowered inappropriately (it was 49 on 45 IIRC). > 49 means that the thread will never be choosen when the 45s are still > in the runqueue. I'm not concerned on RQ_PPQ boundaries. Ah, ok. Sorry for my confusion. I guess the condition seemed somewhat reasonable to me because the behavior of the 45s probably looks very interactive to the scheduler. The user threads wake up, see that there is no space in the arc, signal the txg threads, then sleep. The txg threads then wake up, see that the spa_zio threads are not done, signal all the user threads, then sleep. They bounce back and forth like this very quickly while waiting for data to be flushed to the disk. (On my system this can take a while since my backup pool is on a set of encrypted external USB drives.) It seems likely that their runtime and sleeptime values are balanced so the scheduler marks them as high priority interactive threads. So to me the interprocess communication within zfs appears to be somewhat brain damaged in low memory conditions, but I do not think it points to a problem in the scheduler. It seems that no matter what algorithm the scheduler uses to determine interactivity an application will be able to devise a perverse work load that will be misclassified. Anyway, that was my rough guestimate of what was happening. If you have time to do a more thorough analysis of the ktr dump that would be great. Thanks again for your help! - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 07:50:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3CB1065676; Tue, 19 May 2009 07:50:34 +0000 (UTC) (envelope-from fb-emulation@psconsult.nl) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 821978FC1C; Tue, 19 May 2009 07:50:33 +0000 (UTC) (envelope-from fb-emulation@psconsult.nl) Received: from mx1.psconsult.nl (localhost [80.89.238.138]) by mx1.psconsult.nl (8.14.2/8.14.2) with ESMTP id n4J7B2uR022472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 09:11:07 +0200 (CEST) (envelope-from fb-emulation@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.2/8.14.2/Submit) id n4J7B2w3022471; Tue, 19 May 2009 09:11:02 +0200 (CEST) (envelope-from fb-emulation@psconsult.nl) Date: Tue, 19 May 2009 09:11:02 +0200 From: Paul Schenkeveld To: freebsd-emulation@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090519071102.GA22062@psconsult.nl> Mail-Followup-To: freebsd-emulation@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org References: <20090514191237.GD70242@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090514191237.GD70242@bsdcrew.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mailman-Approved-At: Tue, 19 May 2009 11:25:12 +0000 Cc: Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:50:34 -0000 On Thu, May 14, 2009 at 09:12:37PM +0200, Martin Wilke wrote: > > Howdy Guys, > > After the announcement from Alexander Eichner about > Virtualbox on FreeBSD, we started the work on a port > for FreeBSD. Now we think that we solved the most > problems and are ready for the first Call for Testing. Many thanks! So far I had a short ride but vbox fails every time after the first try. If the following can help you debug/improve, read on, otherwise I'll just wait for a more stable version. If you want me to test anything or send crash dump, please let me know. - Running 7.2-STABLE i386 as of Thu May 14 19:28:42 CEST 2009 on Dell Precision M4300 notebook (Intel T7500 Core-2 Duo, 2.2GHz VT-x enabled, 3 GB RAM) - /proc is mounted - Downloaded vbox port yesterday evening (~ 18:50 UTC) - make -s install clean (watch many qt4 dependencies, dev86 and vbox install) - kldload vboxdrv (OK, even with X running) - $ VirtualBox - Created a guest with 512MB RAM, 2GB IDE pri master disk - Could not choose bridged network, so fell back to NAT - Installed FreeBSD 7.1 from 7.1 release DVD iso, feels very good, nice performance! - Could not NFS mount anything, vbox NAT translates NFS client to unprivileged port - Wanted to add second virtual disk to hold /usr/src and /usr/obj so stopped vbox, added virtual disk and tried to restart guest many times, no luck - Rebooted computer - kldload vboxdrv (with X11 running), system panics - Reboot and load vboxdrv from loader works - Trying to start existing vbox guest always fails, sometimes with error popup: Unknown error creating VM (VERR_PDM_DEVICE_NOT_FOUND). Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole {a7f17a42-5b64-488d-977b-4b2c639ada27} but mostly I only see the console window appear and disappear within a second (/var/log/messages: pid 1283 (VirtualBox), uid 2506: exited on signal 11 - Creating a new guest (in case disk image of old guest is damaged) never starts (shows same symptoms as original guest) Thanks again for all the good work! -- Paul Schenkeveld From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:25:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A491065670; Tue, 19 May 2009 11:25:18 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 23CAB8FC13; Tue, 19 May 2009 11:25:17 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4JBPD9x025791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 11:25:13 GMT (envelope-from ben@wanderview.com) Message-Id: <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com> From: Ben Kelly To: Kip Macy In-Reply-To: <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 07:25:13 -0400 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:25:18 -0000 On May 18, 2009, at 11:12 PM, Kip Macy wrote: >> http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff >> >> But I trigger it based on kmem thresholds. See arc_reclaim_pages(). >> >> I can try to put together a smaller patch tomorrow evening that >> signals the >> pager based on size vs. c target. The main reason I didn't >> implement it in >> my previous patch was because I was concerned with the arc being >> prevented >> from growing at all once its been shrunk. It only grows when size >> exceeds >> its current target by a certain amount. This may require some >> careful >> balancing or hysteresis or something. >> > > I was actually referring to your comment about telling the ARC to tell > ZFS to reclaim cached vnodes. Not that the kmem changes aren't good, > but I don't think they're necessary on amd64. I thought I was referring to that too. :-) I guess I thought signaling the pageout daemon to move vnodes from active to inactive was the way to do that. Are you saying there is another caching layer of vnodes going on in zfs? I'll look around for that this evening. Thanks. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:34:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B2101065675; Tue, 19 May 2009 11:34:57 +0000 (UTC) (envelope-from sergey.dyatko@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 61D0F8FC1D; Tue, 19 May 2009 11:34:55 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1240723fge.12 for ; Tue, 19 May 2009 04:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=HV4C+XrgiZSZJqzWl9sYmUZv/TqNphQoKpbsw3gaazQ=; b=LgaULLQgFtoKWRPlFPVmOZZSuDQ2HASaY35VpLwMp4sdGanvnFvcNshG9lpDA5J0kH uLLMj9+T0SAZ7sei2RuB808KrvepArlFcwq5xDSohE0jKCLfw1qQS6SZtpirLqN9ShDR zJ+Cp/vjq+2qV6uCtiHa/MmizbG/6BwVOsrjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=fiaoNnE9HGO6QjbbqFxKTkgbMU18YnIPfn7uOkCq7WxjaoOujLsiEbDqpsGTDLSuRp 9H36o24XkX21bwpBiCX+vjdr5ZNGWx+jt9OoiTML3PnZ0k9jk79leBaNrJ8wYf0Wow8E 7Y4k9qZnDMTiEoPvYQbM6fV8Covh3ypNPc9Jo= Received: by 10.86.80.5 with SMTP id d5mr6057fgb.59.1242732894611; Tue, 19 May 2009 04:34:54 -0700 (PDT) Received: from tiger.minsk.domain (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id 4sm9590985fgg.18.2009.05.19.04.34.53 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 04:34:54 -0700 (PDT) Date: Tue, 19 May 2009 14:34:51 +0300 From: "Sergey V. Dyatko" To: Martin Wilke Message-ID: <20090519143451.74c2142d@tiger.minsk.domain> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:34:58 -0000 ÷ Tue, 19 May 2009 11:13:10 +0200 Martin Wilke ÐÉÛÅÔ: MW> -----BEGIN PGP SIGNED MESSAGE----- MW> Hash: SHA1 MW> MW> Howdy .. MW> MW> Next run, MW> MW> We updated the port to 2.2.2r19801. MW> The Patch files/patch-amd64-r0-exec-alloc MW> was removed in favor of a similar fix MW> commited to upstream. Also was fixed a MW> bug on HEAD which should be fix the Kernel MW> crash. Please test test test .. :-) Thanks, after kldload vboxdrv start/stop vm (winxp) is work fine for me. But... kldunload vboxdrv - ok kldload vboxdrv - system hungs. solution: hw reset:( /var/log/messages: May 19 13:22:12 tiger kernel: vboxdrv: fAsync=0 offMin=0x9a8 offMax=0xda0 May 19 14:15:56 tiger kernel: Warning: memory type iprtheap leaked memory on destroy (3 allocations, 192 bytes leaked). May 19 14:16:04 tiger kernel: vboxdrv: fAsync=0 offMin=0x898 offMax=0xb38 [tiger@tiger]~%uname -a FreeBSD tiger.minsk.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #26: Fri May 8 15:32:29 EEST 2009 root@tiger.minsk.domain:/usr/obj/usr/src/sys/tiger-desktop i386 backtrace - http://tiger.ipfw.ru/files/bt.txt MW> MW> PS: Yes this run is for AMD64 and HEAD MW> users! MW> MW> MW> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz MW> MW> MW> Happy Testing! MW> MW> - -- MW> MW> +-----------------------+-------------------------------+ MW> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | MW> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | MW> +-----------------------+-------------------------------+ MW> | Mess with the Best, Die like the Rest! | MW> +-----------------------+-------------------------------+ MW> -----BEGIN PGP SIGNATURE----- MW> Version: GnuPG v2.0.11 (FreeBSD) MW> MW> iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 MW> RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu MW> =LoBM MW> -----END PGP SIGNATURE----- -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:38:54 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB3E106564A; Tue, 19 May 2009 11:38:54 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0C73F8FC16; Tue, 19 May 2009 11:38:53 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 759314AC5D; Tue, 19 May 2009 13:38:52 +0200 (CEST) Date: Tue, 19 May 2009 13:38:52 +0200 From: Martin Wilke To: "Sergey V. Dyatko" Message-ID: <20090519113852.GE71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <20090519143451.74c2142d@tiger.minsk.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20090519143451.74c2142d@tiger.minsk.domain> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:38:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, May 19, 2009 at 02:34:51PM +0300, Sergey V. Dyatko wrote: > ? Tue, 19 May 2009 11:13:10 +0200 > Martin Wilke ?????: > > MW> -----BEGIN PGP SIGNED MESSAGE----- > MW> Hash: SHA1 > MW> > MW> Howdy .. > MW> > MW> Next run, > MW> > MW> We updated the port to 2.2.2r19801. > MW> The Patch files/patch-amd64-r0-exec-alloc > MW> was removed in favor of a similar fix > MW> commited to upstream. Also was fixed a > MW> bug on HEAD which should be fix the Kernel > MW> crash. Please test test test .. :-) > Thanks, > after kldload vboxdrv start/stop vm (winxp) is work fine for me. > But... > kldunload vboxdrv - ok > kldload vboxdrv - system hungs. solution: hw reset:( How old is your src? > > /var/log/messages: > May 19 13:22:12 tiger kernel: vboxdrv: fAsync=0 offMin=0x9a8 > offMax=0xda0 > May 19 14:15:56 tiger kernel: Warning: memory type iprtheap leaked > memory on destroy (3 allocations, 192 bytes leaked). > May 19 14:16:04 tiger kernel: vboxdrv: fAsync=0 offMin=0x898 > offMax=0xb38 > > [tiger@tiger]~%uname -a > FreeBSD tiger.minsk.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #26: Fri > May 8 15:32:29 EEST 2009 > root@tiger.minsk.domain:/usr/obj/usr/src/sys/tiger-desktop i386 > > backtrace - http://tiger.ipfw.ru/files/bt.txt > > MW> > MW> PS: Yes this run is for AMD64 and HEAD > MW> users! > MW> > MW> > MW> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > MW> > MW> > MW> Happy Testing! > MW> > MW> - -- > MW> > MW> +-----------------------+-------------------------------+ > MW> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > MW> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | > MW> +-----------------------+-------------------------------+ > MW> | Mess with the Best, Die like the Rest! | > MW> +-----------------------+-------------------------------+ > MW> -----BEGIN PGP SIGNATURE----- > MW> Version: GnuPG v2.0.11 (FreeBSD) > MW> > MW> iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 > MW> RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu > MW> =LoBM > MW> -----END PGP SIGNATURE----- > > -- > wbr, tiger > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoSmkwACgkQdLJIhLHm/Ony5gCg4iWUTPqjrIJoY+hmLndSD5Ml d6kAoNIE/VCuRHnqShzuywsGOb9pKVcP =IRJZ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:42:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B3461065672; Tue, 19 May 2009 11:42:46 +0000 (UTC) (envelope-from sergey.dyatko@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 551858FC16; Tue, 19 May 2009 11:42:45 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1242245fge.12 for ; Tue, 19 May 2009 04:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=AD9gxIES9HFjg24B7lrHZMML99Le5p07j+DE9XIHi4Q=; b=k2Mtf4rrAsC3pyzyF2dly4opOtnM4cJ3gTJE5ynaPvbvpvBGvrWaMDaFkp8GcikqXd xpwzYSSToROSUAPySmSJkJdRM7tILqDGt7tog01ePdZwTsOtRYmEP/qlaFJBDose04HH arsd9GArYJdhvTuKD8lADWs5q8Yjg1uV7Vjm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=VYYoTbx44ftVcXwayIHXyL9naQ0g4y73tyhBKAcjcWgEC9ue0VJygDLEeYAIURlQ9u T0L22p6eZTK3cwGtcUVAD+Y98DNIxbH8962O2QVqyknFBqS4CMG0JRF9rGdENMVKUJeG 8YVMp0eOHI71s2gth4zl0GmYC6yfhEbGcBT8s= Received: by 10.86.70.12 with SMTP id s12mr6209fga.69.1242733363266; Tue, 19 May 2009 04:42:43 -0700 (PDT) Received: from tiger.minsk.domain (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id 4sm9597575fgg.23.2009.05.19.04.42.42 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 04:42:42 -0700 (PDT) Date: Tue, 19 May 2009 14:42:40 +0300 From: "Sergey V. Dyatko" To: Martin Wilke Message-ID: <20090519144240.2040dd20@tiger.minsk.domain> In-Reply-To: <20090519113852.GE71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <20090519143451.74c2142d@tiger.minsk.domain> <20090519113852.GE71804@bsdcrew.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:42:47 -0000 ÷ Tue, 19 May 2009 13:38:52 +0200 Martin Wilke ÐÉÛÅÔ: MW> -----BEGIN PGP SIGNED MESSAGE----- MW> Hash: SHA1 MW> MW> On Tue, May 19, 2009 at 02:34:51PM +0300, Sergey V. Dyatko wrote: MW> > ? Tue, 19 May 2009 11:13:10 +0200 MW> > Martin Wilke ?????: MW> > MW> > MW> -----BEGIN PGP SIGNED MESSAGE----- MW> > MW> Hash: SHA1 MW> > MW> MW> > MW> Howdy .. MW> > MW> MW> > MW> Next run, MW> > MW> MW> > MW> We updated the port to 2.2.2r19801. MW> > MW> The Patch files/patch-amd64-r0-exec-alloc MW> > MW> was removed in favor of a similar fix MW> > MW> commited to upstream. Also was fixed a MW> > MW> bug on HEAD which should be fix the Kernel MW> > MW> crash. Please test test test .. :-) MW> > Thanks, MW> > after kldload vboxdrv start/stop vm (winxp) is work fine for me. MW> > But... MW> > kldunload vboxdrv - ok MW> > kldload vboxdrv - system hungs. solution: hw reset:( MW> MW> How old is your src? Fri May 8 15:32:29 EEST 2009 virtualbox is 2.2.2r19801 MW> MW> > MW> > /var/log/messages: MW> > May 19 13:22:12 tiger kernel: vboxdrv: fAsync=0 offMin=0x9a8 MW> > offMax=0xda0 MW> > May 19 14:15:56 tiger kernel: Warning: memory type iprtheap leaked MW> > memory on destroy (3 allocations, 192 bytes leaked). MW> > May 19 14:16:04 tiger kernel: vboxdrv: fAsync=0 offMin=0x898 MW> > offMax=0xb38 MW> > MW> > [tiger@tiger]~%uname -a MW> > FreeBSD tiger.minsk.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #26: MW> > Fri May 8 15:32:29 EEST 2009 MW> > root@tiger.minsk.domain:/usr/obj/usr/src/sys/tiger-desktop i386 MW> > MW> > backtrace - http://tiger.ipfw.ru/files/bt.txt MW> > MW> > MW> MW> > MW> PS: Yes this run is for AMD64 and HEAD MW> > MW> users! MW> > MW> MW> > MW> MW> > MW> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz MW> > MW> MW> > MW> MW> > MW> Happy Testing! MW> > MW> MW> > MW> - -- MW> > MW> MW> > MW> +-----------------------+-------------------------------+ MW> > MW> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | MW> > MW> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | MW> > MW> +-----------------------+-------------------------------+ MW> > MW> | Mess with the Best, Die like the MW> > MW> Rest! | MW> > MW> +-----------------------+-------------------------------+ MW> > MW> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) MW> > MW> MW> > MW> iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 MW> > MW> RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu MW> > MW> =LoBM MW> > MW> -----END PGP SIGNATURE----- MW> > MW> > -- MW> > wbr, tiger MW> > MW> MW> - -- MW> MW> +-----------------------+-------------------------------+ MW> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | MW> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | MW> +-----------------------+-------------------------------+ MW> | Mess with the Best, Die like the Rest! | MW> +-----------------------+-------------------------------+ MW> -----BEGIN PGP SIGNATURE----- MW> Version: GnuPG v2.0.11 (FreeBSD) MW> MW> iEYEARECAAYFAkoSmkwACgkQdLJIhLHm/Ony5gCg4iWUTPqjrIJoY+hmLndSD5Ml MW> d6kAoNIE/VCuRHnqShzuywsGOb9pKVcP MW> =IRJZ MW> -----END PGP SIGNATURE----- -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:49:11 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9749F106568B; Tue, 19 May 2009 11:49:11 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 539528FC12; Tue, 19 May 2009 11:49:11 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id D0FFD4AC5D; Tue, 19 May 2009 13:49:09 +0200 (CEST) Date: Tue, 19 May 2009 13:49:09 +0200 From: Martin Wilke To: "Sergey V. Dyatko" Message-ID: <20090519114909.GF71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <20090519143451.74c2142d@tiger.minsk.domain> <20090519113852.GE71804@bsdcrew.de> <20090519144240.2040dd20@tiger.minsk.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20090519144240.2040dd20@tiger.minsk.domain> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:49:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, May 19, 2009 at 02:42:40PM +0300, Sergey V. Dyatko wrote: > ? Tue, 19 May 2009 13:38:52 +0200 > Martin Wilke ?????: > > MW> -----BEGIN PGP SIGNED MESSAGE----- > MW> Hash: SHA1 > MW> > MW> On Tue, May 19, 2009 at 02:34:51PM +0300, Sergey V. Dyatko wrote: > MW> > ? Tue, 19 May 2009 11:13:10 +0200 > MW> > Martin Wilke ?????: > MW> > > MW> > MW> -----BEGIN PGP SIGNED MESSAGE----- > MW> > MW> Hash: SHA1 > MW> > MW> > MW> > MW> Howdy .. > MW> > MW> > MW> > MW> Next run, > MW> > MW> > MW> > MW> We updated the port to 2.2.2r19801. > MW> > MW> The Patch files/patch-amd64-r0-exec-alloc > MW> > MW> was removed in favor of a similar fix > MW> > MW> commited to upstream. Also was fixed a > MW> > MW> bug on HEAD which should be fix the Kernel > MW> > MW> crash. Please test test test .. :-) > MW> > Thanks, > MW> > after kldload vboxdrv start/stop vm (winxp) is work fine for me. > MW> > But... > MW> > kldunload vboxdrv - ok > MW> > kldload vboxdrv - system hungs. solution: hw reset:( > MW> > MW> How old is your src? > > Fri May 8 15:32:29 EEST 2009 > > virtualbox is 2.2.2r19801 > Ok, Can you please update your src/kernel after that please rebuild vbox. That should be fix the crash. - - Martin - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoSnLUACgkQdLJIhLHm/OlnuwCfX1yGFsfMbxiluoDAx+1lDxuB uSEAn1lM2r4xjfJAa2GnJYUAI5nsLlCN =Rn5t -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 11:56:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9657106564A; Tue, 19 May 2009 11:56:22 +0000 (UTC) (envelope-from sergey.dyatko@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 DF9F08FC0C; Tue, 19 May 2009 11:56:21 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1244694fge.12 for ; Tue, 19 May 2009 04:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=29laAnmAYKqA9VymWHGZ8PsX7og0YzPS2sJQ89zfTLA=; b=AqtIkpnKc9mQKtYY+3gLKyyGb8XS0kVM9jRK903sldZGpMfg43ads/m9UtmD2BZvkG RxTWlJa8AtjG8RMQXtGAlDdiyTFxJV/I7mzl1S8wxdENbKWYcg7pMjgwDC1CYPg8TwyP vjGBmUNDmo6P2hJy+xT1hyM7+ueQoTvD3he+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=Ox2dHpykVve5OEN5+MNcJFDYB576pnKKE57VSxpeB9nC+wl6UCNB/eyFzhGH9PphNf enh5UHmSPPLahiglfVWWaJoynuNuK0oX0039khW7AnOl9akU6L0Fqt9/8hqH/wmTFs6o Ekm6EjehL6xWq3MI7hANYs0sfyYDFcEVnjNT0= Received: by 10.86.23.20 with SMTP id 20mr53749fgw.17.1242734180995; Tue, 19 May 2009 04:56:20 -0700 (PDT) Received: from tiger.minsk.domain (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id 4sm9584052fgg.3.2009.05.19.04.56.19 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 04:56:20 -0700 (PDT) Date: Tue, 19 May 2009 14:56:18 +0300 From: "Sergey V. Dyatko" To: Martin Wilke Message-ID: <20090519145618.15cbde42@tiger.minsk.domain> In-Reply-To: <20090519114909.GF71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <20090519143451.74c2142d@tiger.minsk.domain> <20090519113852.GE71804@bsdcrew.de> <20090519144240.2040dd20@tiger.minsk.domain> <20090519114909.GF71804@bsdcrew.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:56:23 -0000 ÷ Tue, 19 May 2009 13:49:09 +0200 Martin Wilke ÐÉÛÅÔ: MW> -----BEGIN PGP SIGNED MESSAGE----- MW> Hash: SHA1 MW> MW> On Tue, May 19, 2009 at 02:42:40PM +0300, Sergey V. Dyatko wrote: MW> > ? Tue, 19 May 2009 13:38:52 +0200 MW> > Martin Wilke ?????: MW> > MW> > MW> -----BEGIN PGP SIGNED MESSAGE----- MW> > MW> Hash: SHA1 MW> > MW> MW> > MW> On Tue, May 19, 2009 at 02:34:51PM +0300, Sergey V. Dyatko MW> > MW> wrote: MW> > MW> > ? Tue, 19 May 2009 11:13:10 +0200 MW> > MW> > Martin Wilke ?????: MW> > MW> > MW> > MW> > MW> -----BEGIN PGP SIGNED MESSAGE----- MW> > MW> > MW> Hash: SHA1 MW> > MW> > MW> MW> > MW> > MW> Howdy .. MW> > MW> > MW> MW> > MW> > MW> Next run, MW> > MW> > MW> MW> > MW> > MW> We updated the port to 2.2.2r19801. MW> > MW> > MW> The Patch files/patch-amd64-r0-exec-alloc MW> > MW> > MW> was removed in favor of a similar fix MW> > MW> > MW> commited to upstream. Also was fixed a MW> > MW> > MW> bug on HEAD which should be fix the Kernel MW> > MW> > MW> crash. Please test test test .. :-) MW> > MW> > Thanks, MW> > MW> > after kldload vboxdrv start/stop vm (winxp) is work fine MW> > MW> > for me. But... MW> > MW> > kldunload vboxdrv - ok MW> > MW> > kldload vboxdrv - system hungs. solution: hw reset:( MW> > MW> MW> > MW> How old is your src? MW> > MW> > Fri May 8 15:32:29 EEST 2009 MW> > MW> > virtualbox is 2.2.2r19801 MW> > MW> MW> MW> Ok, Can you please update your src/kernel after MW> that please rebuild vbox. That should be fix the crash. MW> Ok, I'll try MW> - - Martin MW> MW> - -- MW> MW> +-----------------------+-------------------------------+ MW> | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | MW> | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | MW> +-----------------------+-------------------------------+ MW> | Mess with the Best, Die like the Rest! | MW> +-----------------------+-------------------------------+ MW> -----BEGIN PGP SIGNATURE----- MW> Version: GnuPG v2.0.11 (FreeBSD) MW> MW> iEYEARECAAYFAkoSnLUACgkQdLJIhLHm/OlnuwCfX1yGFsfMbxiluoDAx+1lDxuB MW> uSEAn1lM2r4xjfJAa2GnJYUAI5nsLlCN MW> =Rn5t MW> -----END PGP SIGNATURE----- -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Tue May 19 12:06:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F1D10656B0 for ; Tue, 19 May 2009 12:06:09 +0000 (UTC) (envelope-from hyogeollee@gmail.com) Received: from mail-px0-f106.google.com (mail-px0-f106.google.com [209.85.216.106]) by mx1.freebsd.org (Postfix) with ESMTP id 90DD18FC17 for ; Tue, 19 May 2009 12:06:09 +0000 (UTC) (envelope-from hyogeollee@gmail.com) Received: by pxi4 with SMTP id 4so2634513pxi.3 for ; Tue, 19 May 2009 05:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:from:user-agent:mime-version:to:cc :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=6OD6WuNC3ngrNPJN5lcu/401yFgsLPXRRis1bijn+XY=; b=gNzEi6kGfhn2tBlnXG+zgHY76ciqJ8GF5FpK9k0fuRE3k92nc/t93p9nWufOKVOutL Sy7nRoUV8oLj9rFyKnhK2Bf8FBhUCaeFNsF0TgBpWKNfgH9eJcLV3REty1GA7Ht5WAsU O4HiFjPuBW30sd02Wkcif411YSaqjGwimwlsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:x-enigmail-version:content-type :content-transfer-encoding; b=R+uTPTY9G+cg8GXgKC84qOc2r1tQPnCBKsMxrxkPZl01oIZUfW5WK3C7Fp6twVl2el 92zANR9izMJ0y6WyfXnIpz6KQTUNOlP1lOD/TGY3Tz/Np7Fo62aKDlfMpFag0dBBEpWx DVtftNsGaPpWgO+AN8O03VB54VjANrW79epBs= Received: by 10.114.74.18 with SMTP id w18mr11249022waa.205.1242734749754; Tue, 19 May 2009 05:05:49 -0700 (PDT) Received: from auxo.balanche ([202.30.31.66]) by mx.google.com with ESMTPS id g25sm223288wag.8.2009.05.19.05.05.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 05:05:48 -0700 (PDT) Message-ID: <4A12A098.4070707@gmail.com> Date: Tue, 19 May 2009 21:05:44 +0900 From: Hyogeol Lee User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: miwi@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, freebsd-emulation@freebsd.org, freebsd-current@FreeBSD.org, Hyogeol Lee Subject: Re: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:06:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec- > alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > > Happy Testing! > Hi, I'm using -current/amd64 and it works fine with new port. But it is need to *turn off VT-x/AMD-V* to run VM. I could not run VM when I turn on VT-x/AMD-V. (I'm using VT-X supported processor, Q9450.) Anyway, nice works! Regards, - ---- Hyogeol Lee hyogeollee@gmail.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkoSoJYACgkQ1D7/GiH6QSFeowCglEKXInWYffShYWh4YMYjzupN vbIAoK4XsHsx5ASAnolq1F1aBIFYVgjl =4cD8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 12:32:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8114310656D2; Tue, 19 May 2009 12:32:17 +0000 (UTC) (envelope-from SNasonov@BCC.RU) Received: from extmx.bcc.ru (extmx.bcc.ru [217.170.85.214]) by mx1.freebsd.org (Postfix) with ESMTP id F15B18FC1A; Tue, 19 May 2009 12:32:16 +0000 (UTC) (envelope-from SNasonov@BCC.RU) Received: from localhost (localhost [127.0.0.1]) by extmx.bcc.ru (Postfix) with ESMTP id 3264EF764; Tue, 19 May 2009 16:04:36 +0400 (MSD) Received: from extmx.bcc.ru ([127.0.0.1]) by localhost (extmx.bcc.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27511-06; Tue, 19 May 2009 16:04:34 +0400 (MSD) Received: from mail.bcc (unknown [172.16.250.23]) by extmx.bcc.ru (Postfix) with ESMTP id 6BDABE7D9; Tue, 19 May 2009 16:04:34 +0400 (MSD) Received: from snasonovnbwxp.bcc ([192.168.201.205]) by mail.bcc over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 16:04:27 +0400 From: Sergey G Nasonov Organization: BCC To: freebsd-current@freebsd.org Date: Tue, 19 May 2009 16:06:25 +0400 User-Agent: KMail/1.11.3 (FreeBSD/8.0-CURRENT; KDE/4.2.3; i386; ; ) References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> MIME-Version: 1.0 Message-Id: <200905191606.27514.snasonov@bcc.ru> X-OriginalArrivalTime: 19 May 2009 12:04:27.0709 (UTC) FILETIME=[F56EC6D0:01C9D879] X-Virus-Scanned: amavisd-new at bcc.ru Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:32:18 -0000 On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! FreeBSD snasonovnbwxp.bcc 8.0-CURRENT FreeBSD 8.0-CURRENT #23: Tue May 19 11:26:37 MSD 2009 snasonov@snasonovnbwxp.bcc:/usr/obj/usr/current/src/sys/CUSTOM i386 With this version I can succesfuly run VM (now it Windows XP 32 bit). All previous versions at VM start lead system to hang. Thanks! -- Best Regards, Nasonov Sergey mailto:snasonov@bcc.ru From owner-freebsd-current@FreeBSD.ORG Tue May 19 12:36:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 985BC106566B for ; Tue, 19 May 2009 12:36:24 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 647978FC19 for ; Tue, 19 May 2009 12:36:24 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so2168378rvb.43 for ; Tue, 19 May 2009 05:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:disposition-notification-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=tHIew30x2UTW+cwzCdbe68SWrieGE3kpfec+qNwCNBI=; b=JsNCMkv+0+yLmUxjYZxgIbh8tv6Trfh5HgPWygUhXbN3TBtXP8BK/WmsQ78CF1iV5N j8OnR+bTe+fekc9bvGXQJz8cpyZ2P6irFxqgnaxnc9gQuTtijzgIBiBeL4aPF9u6KYld 4q4bi8Aua+y/rU0KF8OntK/eipO41yC1Lvh0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=NiuTUIRFkreAzXWrT0bk9bcnKwj0siSOKSVe5YGcAakntvN6xs1cdYL6aYk0bspEIa vdw+ZfzSY31osFThbv+Rxr6MS6jBZshyYHF4xH8/Z2wGKrUd7BJmSMm/f9CXp+VSJ+C7 uxTRABuK4235a/nF3ymSC/0OTYAuYWJSuK9bs= Received: by 10.140.157.5 with SMTP id f5mr2751967rve.122.1242735373007; Tue, 19 May 2009 05:16:13 -0700 (PDT) Received: from oleg.nevosoft.local ([195.182.128.54]) by mx.google.com with ESMTPS id g31sm441150rvb.3.2009.05.19.05.16.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 05:16:12 -0700 (PDT) From: subbsd To: freebsd-current@freebsd.org Date: Tue, 19 May 2009 16:16:06 +0400 User-Agent: KMail/1.11.3 (FreeBSD/8.0-CURRENT; KDE/4.2.3; i386; ; ) References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905191616.07296.subbsd@gmail.com> Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:36:24 -0000 Hello On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! I've try to compile this port on i386/8-CURRENT ( kern.osreldate: 800087 ) and job stops with last messages: -- /* ... */ kBuild: xsltproc VBoxSVC - /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Main/idl/xpidl.xsl kBuild: Compiling RuntimeR3 - /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsg.cpp kBuild: Compiling RuntimeR3 - /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsgxpcom.cpp kBuild: Linking RuntimeR0 kBuild: Linking RuntimeGC kBuild: Linking RuntimeEFCPP kBuild: Linking RuntimeR3NoCRTGCC kBuild: Compiling RuntimeR0Drv - /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/alloc/alloc.cpp kBuild: Linking VMMR3 kBuild: Compiling PcBiosBin - /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: error: need ';' /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: error: need variable name kmk[2]: *** [/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s] Error 1 kmk[2]: *** Deleting file `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s' kmk[2]: *** Waiting for unfinished jobs.... kmk[2]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' kmk[2]: Entering directory `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_libraries_this] Error 2 kmk[1]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' kmk: *** [pass_libraries_order] Error 2 *** Error code 2 Stop in /usr/ports/emulators/virtualbox. -- DISABLE_MAKE_JOBS=yes options is not influence In the _rombios__c at 471 i see strings: static char bios_cvs_version_string[] = "VirtualBox " "2.2.51_OSE"; but ';' symbol is presents. From owner-freebsd-current@FreeBSD.ORG Tue May 19 12:42:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954561065705; Tue, 19 May 2009 12:42:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id A5E4A8FC0A; Tue, 19 May 2009 12:42:08 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4JA7lnr014398; Tue, 19 May 2009 20:07:47 +1000 Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4JA7idG029455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 20:07:45 +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.3/8.14.3) with ESMTP id n4JA7i9l006336; Tue, 19 May 2009 20:07:44 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n4JA7iXZ006335; Tue, 19 May 2009 20:07:44 +1000 (EST) (envelope-from peter) Date: Tue, 19 May 2009 20:07:44 +1000 From: Peter Jeremy To: Andrew Thompson Message-ID: <20090519100744.GB5943@server.vk2pj.dyndns.org> References: <20090518162253.GA78829@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: <20090518162253.GA78829@citylink.fud.org.nz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:42:13 -0000 --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-18 09:22:54 -0700, Andrew Thompson wrote: >I used gpart for the first time today and a few things came to mind. You're not alone. Have a look at http://lists.freebsd.org/pipermail/freebsd-arch/2008-November/008731.html --=20 Peter Jeremy --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoShPAACgkQ/opHv/APuIcVkACgwMRM8Ed+VjFDOsRTx6GHg2Ee p64AoI+7kRxFbmFcjUhD9kYDZzWlPZh8 =N4kh -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 12:54:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F301065675; Tue, 19 May 2009 12:54:17 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 029878FC15; Tue, 19 May 2009 12:54:14 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so4668348ewy.43 for ; Tue, 19 May 2009 05:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tCiSnzMdPRzRLa2Ux2Rtz4ZYXtpmeroZIo4uvcSygPk=; b=LdnhbyXsOLQOCbw+1a+BdnsvlumDnQLCj801i2nsPuJaBPMZMk7KW8/CKSnY+FKf8G kUcGy1MQzNPx/QV7Jh9h/gJIWCR61EHdB2JBb+ELedsgMX53BZSE6GxMTerbEhjSbDBA WeWQbJKcHtI8j/qXq/UUyDqRASYKhQZ6ZWHRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RNp3Nc1APBnloU1MqAY8jZ8iBVdtM850Eu2kbM870an/UaKxR2QdxSmTu9llT7aBIH C2KlLb8DDC+h+4qlF6LcsqJN7TIhhnJnyOqdjAdS3aMFAnaeqRmGuQ9pCNJhdl8Mox5/ kom6KTtUtnmP/G01oUq+Bt1YgKolULKdGw//o= MIME-Version: 1.0 Received: by 10.216.8.209 with SMTP id 59mr9103wer.18.1242737653926; Tue, 19 May 2009 05:54:13 -0700 (PDT) In-Reply-To: <4A1264E8.2080707@FreeBSD.org> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> Date: Tue, 19 May 2009 14:54:13 +0200 Message-ID: <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: multipart/mixed; boundary=0016364c749b694ad8046a4368ff X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:54:17 -0000 --0016364c749b694ad8046a4368ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/5/19 Alexander Motin > Magnus Kling wrote: > > I applied the patch and rebuilt the kernel. But when should this be > > printed? At shutdown or boot? I can=B4t see it at all. > > On shutdown before panic. > > > When panic occurs I got the attached text as output on my serial consol= e. > > Attached where? > > > The raidcontroller has two ata disks attached. Using RAID 1. My OS is o= n > > a separate disk using the motherboards ata connector. > > Should I disable(unplug the disks) and add a spare harddrive in non-rai= d > > state to the raid card? > > Yes, I mean this exactly. Unplug your disk and insert some another > without building RAID on it. > > -- > Alexander Motin > Sorry missed the attachment. Will find a spare disk ASAP. /Magnus --0016364c749b694ad8046a4368ff Content-Type: text/plain; charset=windows-1250; name="current_panic_promise_SX4_2.txt" Content-Disposition: attachment; filename="current_panic_promise_SX4_2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fuwlvtjk0 TWF5IDE5IDA4OjQxOjU3IGtsaW5nIHN5c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1DQpXYWl0 aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4u LmRvbmUNCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRh ZW1vbicgdG8gc3RvcC4uLmRvbmUNCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVt IHByb2Nlc3MgYHN5bmNlcicgdG8gc3RvcC4uLg0KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFp bmluZy4uLjMgMCAyIDAgMCBkb25lDQpBbGwgYnVmZmVycyBzeW5jZWQuDQpsb2NrIG9yZGVyIHJl dmVyc2FsOg0KIDFzdCAweGMyY2QzYmRjIHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zm c19tb3VudC5jOjExOTQNCiAybmQgMHhjMmNlNWRmNCBzeW5jZXIgKHN5bmNlcikgQCAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfc3Vici5jOjIyMDYNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJh Y2Vfc2VsZl93cmFwcGVyKGMwYzQyNWFkLGMyNjdkYTE4LGMwODlkMDU1LGMwODhlZjViLGMwYzQ1 MzkyLC4uLikgYXQgZGJfdHINCmFjZV9zZWxmX3dyYXBwZXIrMHgyNg0Ka2RiX2JhY2t0cmFjZShj MDg4ZWY1YixjMGM0NTM5MixjMjkxNGI0MCxjMjkxNGMxMCxjMjY3ZGE3NCwuLi4pIGF0IGtkYl9i YWNrdHJhY2UNCisweDI5DQpfd2l0bmVzc19kZWJ1Z2dlcihjMGM0NTM5MixjMmNlNWRmNCxjMGM0 YzM0ZixjMjkxNGMxMCxjMGM0YzFkMCwuLi4pIGF0IF93aXRuZXNzXw0KZGVidWdnZXIrMHgyNQ0K d2l0bmVzc19jaGVja29yZGVyKGMyY2U1ZGY0LDksYzBjNGMxZDAsODllLDAsLi4uKSBhdCB3aXRu ZXNzX2NoZWNrb3JkZXIrMHg4MzkNCl9fbG9ja21ncl9hcmdzKGMyY2U1ZGY0LDgwMTAwLGMyY2U1 ZTEwLDAsMCwuLi4pIGF0IF9fbG9ja21ncl9hcmdzKzB4Nzk3DQp2b3Bfc3RkbG9jayhjMjY3ZGI3 YyxjMDhlNzkxNyxjMGM0YzFkMCw4MDEwMCxjMmNlNWQ5YywuLi4pIGF0IHZvcF9zdGRsb2NrKzB4 NjINClZPUF9MT0NLMV9BUFYoYzBkMzE3YzAsYzI2N2RiN2MsYzA4NGVhMjMsYzBkNTk1YTAsYzJj ZTVkOWMsLi4uKSBhdCBWT1BfTE9DSzFfQVBWDQorMHhhNQ0KX3ZuX2xvY2soYzJjZTVkOWMsODAx MDAsYzBjNGMxZDAsODllLGMwZWY5NWJjLC4uLikgYXQgX3ZuX2xvY2srMHg1ZQ0KdnJlbGUoYzJj ZTVkOWMsMCxjMGM0YmJhNyw0ZWYsYzA4OGVlYWIsLi4uKSBhdCB2cmVsZSsweDE0Mg0KZG91bm1v dW50KGMyYzc2MjgwLDgwMDAwLGMyOTU2ZDgwLGMyNGIxMjMwLDAsLi4uKSBhdCBkb3VubW91bnQr MHgzY2UNCnZmc191bm1vdW50YWxsKGMwYzNmMDlhLDAsYzBjM2YxNDQsMTJhLDAsLi4uKSBhdCB2 ZnNfdW5tb3VudGFsbCsweDRlDQpib290KGMwZDhjNjkwLDAsYzBjM2YxNDQsYWQsYzI2N2RkMmMs Li4uKSBhdCBib290KzB4NDRmDQpyZWJvb3QoYzI5NTZkODAsYzI2N2RjZjgsNCxjMGM0NjVhYixj MGQyMWU2OCwuLi4pIGF0IHJlYm9vdCsweDRiDQpzeXNjYWxsKGMyNjdkZDM4KSBhdCBzeXNjYWxs KzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwDQotLS0g c3lzY2FsbCAoNTUsIEZyZWVCU0QgRUxGMzIsIHJlYm9vdCksIGVpcCA9IDB4ODA1MGZlMywgZXNw ID0gMHhiZmJmZTg4YywgZWJwDQo9IDB4YmZiZmU5NjggLS0tDQpsb2NrIG9yZGVyIHJldmVyc2Fs Og0KIDFzdCAweGMyY2QzYmRjIHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19tb3Vu dC5jOjExOTQNCiAybmQgMHhjMmNiNmNlOCBkZXZmcyAoZGV2ZnMpIEAgL3Vzci9zcmMvc3lzL3Vm cy9mZnMvZmZzX3Zmc29wcy5jOjExOTUNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vf c2VsZl93cmFwcGVyKGMwYzQyNWFkLGMyNjdkOWE0LGMwODlkMDU1LGMwODhlZjViLGMwYzQ1Mzky LC4uLikgYXQgZGJfdHINCmFjZV9zZWxmX3dyYXBwZXIrMHgyNg0Ka2RiX2JhY2t0cmFjZShjMDg4 ZWY1YixjMGM0NTM5MixjMjkxNGI0MCxjMjkxNGE3MCxjMjY3ZGEwMCwuLi4pIGF0IGtkYl9iYWNr dHJhY2UNCisweDI5DQpfd2l0bmVzc19kZWJ1Z2dlcihjMGM0NTM5MixjMmNiNmNlOCxjMGMzNGI4 NixjMjkxNGE3MCxjMGM2NDUzNywuLi4pIGF0IF93aXRuZXNzXw0KZGVidWdnZXIrMHgyNQ0Kd2l0 bmVzc19jaGVja29yZGVyKGMyY2I2Y2U4LDksYzBjNjQ1MzcsNGFiLGMyY2I2ZDA0LC4uLikgYXQg d2l0bmVzc19jaGVja29yZGVyKzANCng4MzkNCl9fbG9ja21ncl9hcmdzKGMyY2I2Y2U4LDgwNDAw LGMyY2I2ZDA0LDAsMCwuLi4pIGF0IF9fbG9ja21ncl9hcmdzKzB4Nzk3DQp2b3Bfc3RkbG9jayhj MjY3ZGIwOCw1NTcsYzI2N2RiMDAsODA0MDAsYzJjYjZjOTAsLi4uKSBhdCB2b3Bfc3RkbG9jaysw eDYyDQpWT1BfTE9DSzFfQVBWKGMwZDFlNjgwLGMyNjdkYjA4LGMzYjEzNTNjLGMwZDU5NWEwLGMy Y2I2YzkwLC4uLikgYXQgVk9QX0xPQ0sxX0FQVg0KKzB4YTUNCl92bl9sb2NrKGMyY2I2YzkwLDgw NDAwLGMwYzY0NTM3LDRhYixjMmNiNzAwMCwuLi4pIGF0IF92bl9sb2NrKzB4NWUNCmZmc19mbHVz aGZpbGVzKGMyYzc2MjgwLDIsYzI5NTZkODAsNTU3LDMsLi4uKSBhdCBmZnNfZmx1c2hmaWxlcysw eGE3DQpzb2Z0ZGVwX2ZsdXNoZmlsZXMoYzJjNzYyODAsMixjMjk1NmQ4MCxjMGM0YzFkMCw4YmMs Li4uKSBhdCBzb2Z0ZGVwX2ZsdXNoZmlsZXMrMA0KeDJlDQpmZnNfdW5tb3VudChjMmM3NjI4MCw4 MDAwMCxjMjY3ZGJmYyw0ZWYsYzA4OGVlYWIsLi4uKSBhdCBmZnNfdW5tb3VudCsweDE0OQ0KZG91 bm1vdW50KGMyYzc2MjgwLDgwMDAwLGMyOTU2ZDgwLGMyNGIxMjMwLDAsLi4uKSBhdCBkb3VubW91 bnQrMHg0NmQNCnZmc191bm1vdW50YWxsKGMwYzNmMDlhLDAsYzBjM2YxNDQsMTJhLDAsLi4uKSBh dCB2ZnNfdW5tb3VudGFsbCsweDRlDQpib290KGMwZDhjNjkwLDAsYzBjM2YxNDQsYWQsYzI2N2Rk MmMsLi4uKSBhdCBib290KzB4NDRmDQpyZWJvb3QoYzI5NTZkODAsYzI2N2RjZjgsNCxjMGM0NjVh YixjMGQyMWU2OCwuLi4pIGF0IHJlYm9vdCsweDRiDQpzeXNjYWxsKGMyNjdkZDM4KSBhdCBzeXNj YWxsKzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwDQot LS0gc3lzY2FsbCAoNTUsIEZyZWVCU0QgRUxGMzIsIHJlYm9vdCksIGVpcCA9IDB4ODA1MGZlMywg ZXNwID0gMHhiZmJmZTg4YywgZWJwDQo9IDB4YmZiZmU5NjggLS0tDQpVcHRpbWU6IDFoMjNtMTJz DQpLZXJuZWwgcGFnZSBmYXVsdCB3aXRoIHRoZSBmb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2Nr cyBoZWxkOg0KZXhjbHVzaXZlIHNsZWVwIG11dGV4IEFUQSBzdGF0ZSBsb2NrIChBVEEgc3RhdGUg bG9jaykgciA9IDAgKDB4YzJhNDJjZDgpIGxvY2tlZA0KQCAvdXNyL3NyYy9zeXMvZGV2L2F0YS9h dGEtcXVldWUuYzoyMDENCmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBBVEEgcXVldWUgbG9jayAoQVRB IHF1ZXVlIGxvY2spIHIgPSAwICgweGMyYTQyY2YwKSBsb2NrZWQNCkAgL3Vzci9zcmMvc3lzL2Rl di9hdGEvYXRhLXF1ZXVlLmM6MTg0DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3Nl bGZfd3JhcHBlcihjMGM0MjVhZCxjMjY3ZDgzMCxjMDg5ZDA1NSxjMGJmM2Q0MixiOCwuLi4pIGF0 IGRiX3RyYWNlX3NlDQpsZl93cmFwcGVyKzB4MjYNCmtkYl9iYWNrdHJhY2UoYzBiZjNkNDIsYjgs ZmZmZmZmZmYsYzBlY2NkM2MsYzI2N2Q4NjgsLi4uKSBhdCBrZGJfYmFja3RyYWNlKzB4MjkNCl93 aXRuZXNzX2RlYnVnZ2VyKGMwYzQ0OTNlLGMyNjdkODdjLDQsMSwwLC4uLikgYXQgX3dpdG5lc3Nf ZGVidWdnZXIrMHgyNQ0Kd2l0bmVzc193YXJuKDUsMCxjMGM3NmRjNSxjMjkwZjY1OCxjMjk1NGQz NCwuLi4pIGF0IHdpdG5lc3Nfd2FybisweDFmZA0KdHJhcChjMjY3ZDkwOCkgYXQgdHJhcCsweDE3 Mw0KY2FsbHRyYXAoKSBhdCBjYWxsdHJhcCsweDYNCi0tLSB0cmFwIDB4YywgZWlwID0gMHhjMDU2 NzBhOSwgZXNwID0gMHhjMjY3ZDk0OCwgZWJwID0gMHhjMjY3ZDk2MCAtLS0NCmF0YV9wcm9taXNl X3N4NF9jb21tYW5kKGMzM2NiM2U4LGM5LGMyNjdkOTk4LGMwODRlYTIzLGMyYTQyY2Q4LC4uLikg YXQgYXRhX3Byb21pDQpzZV9zeDRfY29tbWFuZCsweDM5DQphdGFfYmVnaW5fdHJhbnNhY3Rpb24o YzMzY2IzZTgsMCxjMGJmM2Q0MixjOSxjMmE0MmNmMCwuLi4pIGF0IGF0YV9iZWdpbl90cmFuc2Fj dA0KaW9uKzB4N2ENCmF0YV9zdGFydChjMmE5MDAwMCwwLGMwYmYzZDQyLDVkLGMyYTQyY2YwLC4u LikgYXQgYXRhX3N0YXJ0KzB4MWRiDQphdGFfcXVldWVfcmVxdWVzdChjMzNjYjNlOCwwLDEwMSww LGU3MDAwMDAwLC4uLikgYXQgYXRhX3F1ZXVlX3JlcXVlc3QrMHg0OTMNCmF0YV9jb250cm9sY21k KGMyYjU4MTgwLGU3LDAsMCwwLC4uLikgYXQgYXRhX2NvbnRyb2xjbWQrMHhkNg0KYWRfc2h1dGRv d24oYzJiNTgxODAsYzJhMTQ4MzAsYzBkMjEwMDQpIGF0IGFkX3NodXRkb3duKzB4NGINCmRldmlj ZV9zaHV0ZG93bihjMmI1ODE4MCxjMmE5MDAwMCxjMjY3ZGE5OCxjMDg4NDFkYyxjMmE5MDAwMCwu Li4pIGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3duKGMyYTkw MDAwLGMyOWU4ODMwLGMwZDIxMDA0KSBhdCBidXNfZ2VuZXJpY19zaHV0ZG93bisweDE5DQpkZXZp Y2Vfc2h1dGRvd24oYzJhOTAwMDAsYzJhNmJiMDAsYzI2N2RhYzAsYzA4ODQxZGMsYzJhNmJiMDAs Li4uKSBhdCBkZXZpY2Vfc2h1dA0KZG93bisweDRjDQpidXNfZ2VuZXJpY19zaHV0ZG93bihjMmE2 YmIwMCxjMmEwNTgzMCxjMGQyMTAwNCkgYXQgYnVzX2dlbmVyaWNfc2h1dGRvd24rMHgxOQ0KZGV2 aWNlX3NodXRkb3duKGMyYTZiYjAwLGMyOTcxOTAwLGMyNjdkYWU4LGMwODg0MWRjLGMyOTcxOTAw LC4uLikgYXQgZGV2aWNlX3NodXQNCmRvd24rMHg0Yw0KYnVzX2dlbmVyaWNfc2h1dGRvd24oYzI5 NzE5MDAsYzJhMDEwMzAsYzBkMjEwMDQpIGF0IGJ1c19nZW5lcmljX3NodXRkb3duKzB4MTkNCmRl dmljZV9zaHV0ZG93bihjMjk3MTkwMCxjMmE1YWE4MCxjMjY3ZGIxMCxjMDg4NDFkYyxjMmE1YWE4 MCwuLi4pIGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3duKGMy YTVhYTgwLGMyOWQ5ODMwLGMwZDIxMDA0KSBhdCBidXNfZ2VuZXJpY19zaHV0ZG93bisweDE5DQpk ZXZpY2Vfc2h1dGRvd24oYzJhNWFhODAsYzJhNWIzMDAsYzI2N2RiMzgsYzA4ODQxZGMsYzJhNWIz MDAsLi4uKSBhdCBkZXZpY2Vfc2h1dA0KZG93bisweDRjDQpidXNfZ2VuZXJpY19zaHV0ZG93bihj MmE1YjMwMCxjMjk4YzAzMCxjMGQyMTAwNCkgYXQgYnVzX2dlbmVyaWNfc2h1dGRvd24rMHgxOQ0K ZGV2aWNlX3NodXRkb3duKGMyYTViMzAwLGMyOTcxZTgwLGMyNjdkYjYwLGMwODg0MWRjLGMyOTcx ZTgwLC4uLikgYXQgZGV2aWNlX3NodXQNCmRvd24rMHg0Yw0KYnVzX2dlbmVyaWNfc2h1dGRvd24o YzI5NzFlODAsYzI5ZGEwMzAsYzBkMjEwMDQpIGF0IGJ1c19nZW5lcmljX3NodXRkb3duKzB4MTkN CmRldmljZV9zaHV0ZG93bihjMjk3MWU4MCxjMmE0NDg4MCxjMjY3ZGI4OCxjMDRjZWMzNSxjMmE0 NDg4MCwuLi4pIGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3du KGMyYTQ0ODgwLDQsYzBiZTY1ZTEsMmYzLGMyNjdkYmEwLC4uLikgYXQgYnVzX2dlbmVyaWNfc2h1 dGRvDQp3bisweDE5DQphY3BpX3NodXRkb3duKGMyYTQ0ODgwLGMyOWRjMDMwLGMwZDIxMDA0KSBh dCBhY3BpX3NodXRkb3duKzB4MzUNCmRldmljZV9zaHV0ZG93bihjMmE0NDg4MCxjMjk1MjI4MCxj MjY3ZGJjOCxjMDg4NDFkYyxjMjk1MjI4MCwuLi4pIGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMN CmJ1c19nZW5lcmljX3NodXRkb3duKGMyOTUyMjgwLGMyYTE0MDMwLGMwZDIxMDA0KSBhdCBidXNf Z2VuZXJpY19zaHV0ZG93bisweDE5DQpkZXZpY2Vfc2h1dGRvd24oYzI5NTIyODAsYzI5NTJjODAs YzI2N2RiZjAsYzA4ODQxZGMsYzI5NTJjODAsLi4uKSBhdCBkZXZpY2Vfc2h1dA0KZG93bisweDRj DQpidXNfZ2VuZXJpY19zaHV0ZG93bihjMjk1MmM4MCxjMjk3OTAzMCxjMGQyMTAwNCkgYXQgYnVz X2dlbmVyaWNfc2h1dGRvd24rMHgxOQ0KZGV2aWNlX3NodXRkb3duKGMyOTUyYzgwLDJkLGMwODEw OTRmLGMyOTMyMTQwLGMyOTBkNDQwLC4uLikgYXQgZGV2aWNlX3NodXRkb3duKzANCng0Yw0Kcm9v dF9idXNfbW9kdWxlX2hhbmRsZXIoYzI5MzIxODAsMiwwLDY3LGMyOTBiNmEwLC4uLikgYXQgcm9v dF9idXNfbW9kdWxlX2hhbmRsZXINCisweDEzZg0KbW9kdWxlX3NodXRkb3duKDAsMCxjMGMzZjE0 NCwxYTcsMCwuLi4pIGF0IG1vZHVsZV9zaHV0ZG93bisweDc4DQpib290KGMwZDhjNjkwLDAsYzBj M2YxNDQsYWQsYzI2N2RkMmMsLi4uKSBhdCBib290KzB4NzVmDQpyZWJvb3QoYzI5NTZkODAsYzI2 N2RjZjgsNCxjMGM0NjVhYixjMGQyMWU2OCwuLi4pIGF0IHJlYm9vdCsweDRiDQpzeXNjYWxsKGMy NjdkZDM4KSBhdCBzeXNjYWxsKzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBf c3lzY2FsbCsweDIwDQotLS0gc3lzY2FsbCAoNTUsIEZyZWVCU0QgRUxGMzIsIHJlYm9vdCksIGVp cCA9IDB4ODA1MGZlMywgZXNwID0gMHhiZmJmZTg4YywgZWJwDQo9IDB4YmZiZmU5NjggLS0tDQoN Cg0KRmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQ0KY3B1aWQg PSAwOyBhcGljIGlkID0gMDANCmZhdWx0IHZpcnR1YWwgYWRkcmVzcyAgID0gMHhjDQpmYXVsdCBj b2RlICAgICAgICAgICAgICA9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBub3QgcHJlc2VudA0KaW5z dHJ1Y3Rpb24gcG9pbnRlciAgICAgPSAweDIwOjB4YzA1NjcwYTkNCnN0YWNrIHBvaW50ZXIgICAg ICAgICAgID0gMHgyODoweGMyNjdkOTQ4DQpmcmFtZSBwb2ludGVyICAgICAgICAgICA9IDB4Mjg6 MHhjMjY3ZDk2MA0KY29kZSBzZWdtZW50ICAgICAgICAgICAgPSBiYXNlIDB4MCwgbGltaXQgMHhm ZmZmZiwgdHlwZSAweDFiDQogICAgICAgICAgICAgICAgICAgICAgICA9IERQTCAwLCBwcmVzIDEs IGRlZjMyIDEsIGdyYW4gMQ0KcHJvY2Vzc29yIGVmbGFncyAgICAgICAgPSBpbnRlcnJ1cHQgZW5h YmxlZCwgcmVzdW1lLCBJT1BMID0gMA0KY3VycmVudCBwcm9jZXNzICAgICAgICAgPSAxIChpbml0 KQ0KW3RocmVhZCBwaWQgMSB0aWQgMTAwMDAyIF0NClN0b3BwZWQgYXQgICAgICBhdGFfcHJvbWlz ZV9zeDRfY29tbWFuZCsweDM5OiAgIG1vdmwgICAgMHhjKCVlYXgpLCVlc2kNCmRiPiAvYm9vdC9r ZXJuZWwva2VybmVsIHRleHQ9MHg4N2U0MjggZGF0YT0weGRhOTIwKzB4MWZlYTE4IHN5bXM9WzB4 NCsweDk2YmIwKzB4DQo0KzB4Y2RiM2RdDQpcDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQog2sTExMTExMTExMTExMTExMTExMTExMTExMTExMTE xMTExMTExMTExMTEvw0KILMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ILMNCiCzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCzICAgICAgX19f X19fDQogsyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgsyAgICAgfCAg X19fX3wgX18gX19fICBfX18NCiCzICAgICAgICAgIFdlbGNvbWUgdG8gRnJlZUJTRCEgICAgICAg ICAgICCzICAgICB8IHxfXyB8ICdfXy8gXyBcLyBfIFwNCiCzICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICCzICAgICB8ICBfX3x8IHwgfCAgX18vICBfXy8NCiCzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCzICAgICB8IHwgICB8IHwgfCAgICB8 ICAgIHwNCiCzICAxLiBCb290IEZyZWVCU0QgW2RlZmF1bHRdICAgICAgICAgICAgICCzICAgICB8 X3wgICB8X3wgIFxfX198XF9fX3wNCiCzICAyLiBCb290IEZyZWVCU0Qgd2l0aCBBQ1BJIGRpc2Fi bGVkICAgICCzICAgICAgX19fXyAgIF9fX19fIF9fX19fDQogsyAgMy4gQm9vdCBGcmVlQlNEIGlu IFNhZmUgTW9kZSAgICAgICAgICAgsyAgICAgfCAgXyBcIC8gX19fX3wgIF9fIFwNCiCzICA0LiBC b290IEZyZWVCU0QgaW4gc2luZ2xlIHVzZXIgbW9kZSAgICCzICAgICB8IHxfKSB8IChfX18gfCB8 ICB8IHwNCiCzICA1LiBCb290IEZyZWVCU0Qgd2l0aCB2ZXJib3NlIGxvZ2dpbmcgICCzICAgICB8 ICBfIDwgXF9fXyBcfCB8ICB8IHwNCiCzICA2LiBFc2NhcGUgdG8gbG9hZGVyIHByb21wdCAgICAg ICAgICAgICCzICAgICB8IHxfKSB8X19fXykgfCB8X198IHwNCiCzICA3LiBSZWJvb3QgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICCzICAgICB8ICAgICB8ICAgICAgfCAgICAgIHwNCiCzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCzICAgICB8X19fXy98X19fX18v fF9fX19fLw0KILMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILMNCiCz ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCzDQogsyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgsw0KILMgIFNlbGVjdCBvcHRpb24sIFtFbnRl cl0gZm9yIGRlZmF1bHQgICAgILMNCiCzICBvciBbU3BhY2VdIHRvIHBhdXNlIHRpbWVyICA2ICAg ICAgICAgICCzDQogwMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTE2Q0K DQpHREI6IG5vIGRlYnVnIHBvcnRzIHByZXNlbnQNCktEQjogZGVidWdnZXIgYmFja2VuZHM6IGRk Yg0KS0RCOiBjdXJyZW50IGJhY2tlbmQ6IGRkYg0KQ29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhl IEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4Niwg MTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJl ZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24u DQpGcmVlQlNEIDguMC1DVVJSRU5UICM1OiBUdWUgTWF5IDE5IDA4OjE1OjIyIENFU1QgMjAwOQ0K ICAgIGtsaW5nQGtsaW5nLnRlbGlhLnNlOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMNCldB Uk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNl Lg0KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDANCkNQ VTogSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAyLjQwR0h6ICgyNDA1LjQ3LU1IeiA2ODYtY2xh c3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweGYyNyAgU3RlcHBpbmcg PSA3DQogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNF LENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQw0KTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxB Q1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+DQogIEZlYXR1cmVzMj0weDQ0MDA8 Q05YVC1JRCx4VFBSPg0KcmVhbCBtZW1vcnkgID0gMjY4NDM1NDU2ICgyNTYgTUIpDQphdmFpbCBt ZW1vcnkgPSAyNDM4NDMwNzIgKDIzMiBNQikNCkFDUEkgQVBJQyBUYWJsZTogPEFTVVMgICBQNFQ1 MzMtQz4NCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmti ZDEgYXQga2JkbXV4MA0KYWNwaTA6IDxBU1VTIFA0VDUzMy1DPiBvbiBtb3RoZXJib2FyZA0KYWNw aTA6IFtJVEhSRUFEXQ0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogcmVzZXJ2 YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAw MCwgZmYwMDAwMCAoMykgZmFpbGVkDQpUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kg MzU3OTU0NSBIeiBxdWFsaXR5IDEwMDANCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMu NTc5NTQ1TUh6PiBwb3J0IDB4ZTQwOC0weGU0MGIgb24gYWNwaTANCmFjcGlfYnV0dG9uMDogPFBv d2VyIEJ1dHRvbj4gb24gYWNwaTANCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQg MHhjZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQphZ3Aw OiA8SW50ZWwgODI4NTAgaG9zdCB0byBBR1AgYnJpZGdlPiBvbiBob3N0YjANCnBjaWIxOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGVl MDAwMDAwLTB4ZWVmZmZmZmYsMHhmMDAwMDAwMC0weGY3ZmZmZmYNCmYgaXJxIDE2IGF0IGRldmlj ZSAwLjAgb24gcGNpMQ0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAu MCBvbiBwY2kwDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMg0Kb2hjaTA6IDxORUMgdVBE IDkyMTAgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGVkODAwMDAwLTB4ZWQ4MDBmZmYgaXJxIDIxIGF0 IGRldmljZQ0KNC4wIG9uIHBjaTINCm9oY2kwOiBbSVRIUkVBRF0NCnVzYnVzMDogPE5FQyB1UEQg OTIxMCBVU0IgY29udHJvbGxlcj4gb24gb2hjaTANCm9oY2kxOiA8TkVDIHVQRCA5MjEwIFVTQiBj b250cm9sbGVyPiBtZW0gMHhlZDAwMDAwMC0weGVkMDAwZmZmIGlycSAyMiBhdCBkZXZpY2UNCjQu MSBvbiBwY2kyDQpvaGNpMTogW0lUSFJFQURdDQp1c2J1czE6IDxORUMgdVBEIDkyMTAgVVNCIGNv bnRyb2xsZXI+IG9uIG9oY2kxDQplaGNpMDogPE5FQyB1UEQgNzIwMTAwIFVTQiAyLjAgY29udHJv bGxlcj4gbWVtIDB4ZWM4MDAwMDAtMHhlYzgwMDBmZiBpcnEgMjMgYXQgZA0KZXZpY2UgNC4yIG9u IHBjaTINCmVoY2kwOiBbSVRIUkVBRF0NCnVzYnVzMjogRUhDSSB2ZXJzaW9uIDAuOTUNCnVzYnVz MjogPE5FQyB1UEQgNzIwMTAwIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTANCmF0YXBjaTA6 IDxQcm9taXNlIFBEQzIwNjIxIFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweGQ4MDAtMHhkOGZm LDB4ZDQwMC0weGQ0ZmYsDQoweGQwMDAtMHhkMGZmIG1lbSAweGVjMDAwMDAwLTB4ZWMwZmZmZmYs MHhlYjgwMDAwMC0weGViODA3ZmZmIGlycSAyMiBhdCBkZXZpY2UgMQ0KMC4wIG9uIHBjaTINCmF0 YXBjaTA6IFtJVEhSRUFEXQ0KYXRhcGNpMDogW0lUSFJFQURdDQphdGFwY2kwOiBESU1NIHNpemUg MTI4TUIgQCAweDAwMDAwMDAwDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0KYXRh MjogW0lUSFJFQURdDQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMA0KYXRhMzogW0lU SFJFQURdDQphdGE0OiA8QVRBIGNoYW5uZWwgMj4gb24gYXRhcGNpMA0KYXRhNDogW0lUSFJFQURd DQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNpMA0KYXRhNTogW0lUSFJFQURdDQp4bDA6 IDwzQ29tIDNjOTA1Qi1UWCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAweGI4MDAtMHhiODdmIG1l bSAweGViMDAwMDAwLTB4ZWIwMA0KMDA3ZiBpcnEgMjAgYXQgZGV2aWNlIDEyLjAgb24gcGNpMg0K bWlpYnVzMDogPE1JSSBidXM+IG9uIHhsMA0KeGxwaHkwOiA8M0NvbSBpbnRlcm5hbCBtZWRpYSBp bnRlcmZhY2U+IFBIWSAyNCBvbiBtaWlidXMwDQp4bHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZE WCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQp4bDA6IEV0aGVybmV0IGFkZHJlc3M6 IDAwOjEwOjRiOjQ1OmJhOmNmDQp4bDA6IFtJVEhSRUFEXQ0KeGwxOiA8M0NvbSAzYzkwNS1UWCBG YXN0IEV0aGVybGluayBYTD4gcG9ydCAweGI0MDAtMHhiNDNmIGlycSAxOCBhdCBkZXZpY2UgMTMu MA0Kb24gcGNpMg0KbWlpYnVzMTogPE1JSSBidXM+IG9uIHhsMQ0KbnNwaHkwOiA8RFA4Mzg0MCAx MC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMjQgb24gbWlpYnVzMQ0KbnNwaHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bw0KeGwxOiBFdGhl cm5ldCBhZGRyZXNzOiAwMDo2MDowODo2Yjo0NTpmMg0KeGwxOiBbSVRIUkVBRF0NCmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBv biBpc2FiMA0KYXRhcGNpMTogPEludGVsIElDSDIgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4 MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4MzcNCjYsMHhhODAwLTB4YTgwZiBhdCBkZXZp Y2UgMzEuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQ0KYXRhMDog W0lUSFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQ0KYXRhMTogW0lUSFJF QURdDQp1aGNpMDogPEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0It QT4gcG9ydCAweGE0MDAtMHhhNDFmIGlycSAxOQ0KIGF0IGRldmljZSAzMS4yIG9uIHBjaTANCnVo Y2kwOiBbSVRIUkVBRF0NCnVoY2kwOiBMZWdTdXAgPSAweDJmMjANCnVzYnVzMzogPEludGVsIDgy ODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTANCnVoY2kxOiA8 SW50ZWwgODI4MDFCQS9CQU0gKElDSDIpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4YTAw MC0weGEwMWYgaXJxIDIzDQogYXQgZGV2aWNlIDMxLjQgb24gcGNpMA0KdWhjaTE6IFtJVEhSRUFE XQ0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMA0KdXNidXM0OiA8SW50ZWwgODI4MDFCQS9CQU0gKElD SDIpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQ0KYXRydGMwOiA8QVQgcmVhbHRpbWUg Y2xvY2s+IHBvcnQgMHg3MC0weDczIGlycSA4IG9uIGFjcGkwDQpwcGMwOiA8UGFyYWxsZWwgcG9y dD4gcG9ydCAweDM3OC0weDM3ZiwweDc3OC0weDc3YiBpcnEgNyBkcnEgMyBvbiBhY3BpMA0KcHBj MDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1v ZGUNCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi85IGJ5dGVzIHRocmVzaG9sZA0KcHBjMDogW0lUSFJF QURdDQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMA0KcGxpcDA6IDxQTElQIG5l dHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czANCnBsaXAwOiBbSVRIUkVBRF0NCmxwdDA6IDxQcmlu dGVyPiBvbiBwcGJ1czANCmxwdDA6IFtJVEhSRUFEXQ0KbHB0MDogSW50ZXJydXB0LWRyaXZlbiBw b3J0DQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czANCnVhcnQwOiA8MTY1NTAgb3IgY29t cGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwDQp1YXJ0 MDogW0ZJTFRFUl0NCnVhcnQwOiBjb25zb2xlICg5NjAwLG4sOCwxKQ0KdWFydDE6IDwxNjU1MCBv ciBjb21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwDQp1YXJ0MTogW0ZJ TFRFUl0NCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCww eDY0IGlycSAxIG9uIGFjcGkwDQphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MA0Ka2JkMCBhdCBhdGtiZDANCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NCmF0a2JkMDogW0lUSFJF QURdDQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRo ZXJtYWwgQ29udHJvbD4gb24gY3B1MA0KcG10aW1lcjAgb24gaXNhMA0Kb3JtMDogPElTQSBPcHRp b24gUk9NPiBhdCBpb21lbSAweGQwMDAwLTB4ZGM3ZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwDQpz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MTAwPg0KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4g YXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMA0KVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI0MDU0NzA0MjAgSHogcXVhbGl0eSA4MDANClRpbWVjb3Vu dGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMNCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNC IHYxLjANCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMjogNDgwTWJw cyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w DQp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wDQp1Z2VuMC4xOiA8TkVDPiBhdCB1 c2J1czANCnVodWIwOiA8TkVDIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2J1czANCnVnZW4xLjE6IDxORUM+IGF0IHVzYnVzMQ0KdWh1YjE6IDxO RUMgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzMQ0KdWdlbjIuMTogPE5FQz4gYXQgdXNidXMyDQp1aHViMjogPE5FQyBFSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyDQp1Z2VuMy4xOiA8 SW50ZWw+IGF0IHVzYnVzMw0KdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzDQp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVz YnVzNA0KdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNidXM0DQphZDA6IDIzODQ3NU1CIDxIaXRhY2hpIEhEUDcyNTAyNUdM QVQ4MCBHTTJPQTQyQT4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMA0KYWQ4OiAyMzg0NzVNQiA8U2Vh Z2F0ZSBTVDMyNTA4MjBBIDMuQUFFPiBhdCBhdGE0LW1hc3RlciBVRE1BMTAwDQpHRU9NOiBhZDBz MTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1NWgsNjNzICE9IDE2aCw2M3MpLg0K YWQxMDogMjM4NDc1TUIgPFNlYWdhdGUgU1QzMjUwODIwQSAzLkFBRT4gYXQgYXRhNS1tYXN0ZXIg VURNQTEwMA0KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxYSBpcyB1ZnNpZC80 OGYyMWQ3YTBkNmEwMGRlLg0KYXIwOiAyMzg0NzVNQiA8UHJvbWlzZSBGYXN0dHJhayBSQUlEMT4g c3RhdHVzOiBSRUFEWQ0KYXIwOiBkaXNrMCBSRUFEWSAobWFzdGVyKSB1c2luZyBhZDggYXQgYXRh NC1tYXN0ZXINCmFyMDogZGlzazEgUkVBRFkgKG1pcnJvcikgdXNpbmcgYWQxMCBhdCBhdGE1LW1h c3Rlcg0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVy Zm9ybWFuY2UuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFkIGlzIHVmc2lk LzQ4ZjIxZDgzZWY3ZTA0OGIuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFl IGlzIHVmc2lkLzQ4ZjIxZDdhZTBjYjdjOWMuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlk ZXIgYWQwczFmIGlzIHVmc2lkLzQ4ZjIxZDdhYTMxYjFhYTV1aHViMzogMiBwb3J0cyB3aQ0KdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkDQouDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ4czEg aXMgdWZzaWQvNDUxNDRkMzQ3NzBmYmNkNC4NCkdFT006IGFkOHMxOiBnZW9tZXRyeSBkb2VzIG5v dCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZoLDYzcykuDQpHRU9NOiB1ZnNpZC80NTE0NGQz NDc3MGZiY2Q0OiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZo LDYzcw0KKS4NCkdFT006IGFkMTBzMTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1 NWgsNjNzICE9IDE2aCw2M3MpLg0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMyIHVzYnVz MSB1c2J1czANCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0K dWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1aHViMjogNSBw b3J0cyB3aXRoIDUgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClRyeWluZyB0byBtb3VudCByb290 IGZyb20gdWZzOi9kZXYvYWQwczFhDQpFbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVwdHMgZXRo ZXJuZXQgcG9pbnRfdG9fcG9pbnQga2lja3N0YXJ0Lg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQv NDhmMjFkN2EwZDZhMDBkZSByZW1vdmVkLg0KT2Rldi9hZDBzMWE6IEZJTEdFIFNZU1RFTSBDTEVB TjsgRVNLSVBQSU5HIENIRUNLUw0KIC9kZXYvYWQwczFhOiBjbE1lYW4sIDEwMzk0OSBmcmVlXyAo MTAxMyBmcmFncywgMTJMODY3IGJsb2NrcywgMC40JUEgZnJhZ21lbnRhdGkNCkJuKQ0KIEVMOiBM YWJlbCBmb3IgcHJvdmlkZXIgYWQwczFhIGlzIHVmc2lkLzQ4ZjIxZDdhMGQ2YTAwZGUuDQpHRU9N X0xBQkVMOiBMYWJlbCB1ZnNpZC80OGYyMWQ3YWUwY2I3YzljIHJlbW92ZWQuDQpPZGV2L2FkMHMx ZTogRklMR0UgU1lTVEVNIENMRUFOOyBFU0tJUFBJTkcgQ0hFQ0tTDQogL2Rldi9hZDBzMWU6IGNs TWVhbiwgMjUzNzI2IGZyZWVfICg0NiBmcmFncywgMzE3MUwwIGJsb2NrcywgMC4wJSBmQXJhZ21l bnRhdGlvbg0KKQ0KQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFlIGlzIHVmc2lkLzQ4ZjIx ZDdhZTBjYjdjOWMuDQovZGV2L2FyMHMxOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hF Q0tTDQpHL2Rldi9hcjBzMTogY2xlYUVuLCAyMTMyMTYzMSBmcmVlTyAoNjU1OSBmcmFncywgMjZN NjQzODQgYmxvY2tzLCAwLl8wJSBmcmFnbWVudA0KYXRpb25MKQ0KQUJFTDogTGFiZWwgdWZzaWQv NDhmMjFkN2FhMzFiMWFhNSByZW1vdmVkLg0KR2Rldi9hZDBzMWY6IEZJTEUgU1lTVEVNIENMRUFO OyBTS0lQUElORyBDSEVDS1MNCiAvZGV2L2FkMHMxZjogY2xFZWFuLCAxMTQxNTEzMTkgZk9yZWUg KDM4MDg3IGZyYWdzTSwgMTQyNjQxNTQgYmxvY2tfcywgMC4wJSBmcmFnDQptZW50TGF0aW9uKQ0K QUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxZiBpcyB1ZnNpZC80OGYyMWQ3YWEzMWIxYWE1 Lg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDhmMjFkODNlZjdlMDQ4YiByZW1vdmVkLg0KT2Rl di9hZDBzMWQ6IEZJTEdFIFNZU1RFTSBDTEVBTjsgRVNLSVBQSU5HIENIRUNLUw0KIC9kZXYvYWQw czFkOiBjbE1lYW4sIDQxOTI1NiBmcmVlXyAoMTc3OTIgZnJhZ3MsIDVMMDE4MyBibG9ja3MsIDEu OEElIGZyYWdtZW50YXQNCmlvbilCDQpFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxZCBpcyB1 ZnNpZC80OGYyMWQ4M2VmN2UwNDhiLg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDhmMjFkN2Ew ZDZhMDBkZSByZW1vdmVkLg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDhmMjFkN2FlMGNiN2M5 YyByZW1vdmVkLg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDhmMjFkN2FhMzFiMWFhNSByZW1v dmVkLg0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDhmMjFkODNlZjdlMDQ4YiByZW1vdmVkLg0K eGwwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCnhsMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQDQpTdGFydGluZyBOZXR3b3JrOiBsbzAgeGwwIHhsMS4NClJlbW92aW5nIHN0YWxlIFNhbWJh IHRkYiBmaWxlczogLi4uLi4uLi4gZG9uZQ0KQ29uZmlndXJpbmcgc3lzY29uczoga2V5bWFwIGJs YW5rdGltZS4NCg0KVHVlIE1heSAxOSAwODo0MzozOCBDRVNUIDIwMDkNCg0KRnJlZUJTRC9pMzg2 IChrbGluZy50ZWxpYS5zZSkgKHR0eXUwKQ0KDQpsb2dpbjogU3RvcHBpbmcgY3Jvbi4NCiAgICAg ICAgICAgICAgICAgICAgIFN0b3BwaW5nIHNzaGQuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFN0b3BwaW5nIHdpbmJpbmRkLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9wcGluZyBzbWJkLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3Bw aW5nIG5tYmQNCi4NCiBTdG9wcGluZyBkZXZkLg0KICAgICAgICAgICAgICAgV3JpdGluZyBlbnRy b3B5IGZpbGU6Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlcm1pbmF0 ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDE5IDA4OjQz OjUxIGtsaW5nIHN5c2xvZ2Q6IGUNCnhpdGluZyBvbiBzaWduYWwgMTUNCldhaXRpbmcgKG1heCA2 MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQ0KV2Fp dGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBz dG9wLi4uZG9uZQ0KV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBg c3luY2VyJyB0byBzdG9wLi4uDQpTeW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uNSAx IDIgMCAwIGRvbmUNCkFsbCBidWZmZXJzIHN5bmNlZC4NCmxvY2sgb3JkZXIgcmV2ZXJzYWw6DQog MXN0IDB4YzJjZDNiZGMgdWZzICh1ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6 MTE5NA0KIDJuZCAweGMyY2I2Y2U4IGRldmZzIChkZXZmcykgQCAvdXNyL3NyYy9zeXMvdWZzL2Zm cy9mZnNfdmZzb3BzLmM6MTE5NQ0KS0RCOiBzdGFjayBiYWNrdHJhY2U6DQpkYl90cmFjZV9zZWxm X3dyYXBwZXIoYzBjNDI2NjcsYzI2N2Q5YTQsYzA4OWQwYzUsYzA4OGVmY2IsYzBjNDU0NGMsLi4u KSBhdCBkYl90cg0KYWNlX3NlbGZfd3JhcHBlcisweDI2DQprZGJfYmFja3RyYWNlKGMwODhlZmNi LGMwYzQ1NDRjLGMyOTE0YjQwLGMyOTE0YTcwLGMyNjdkYTAwLC4uLikgYXQga2RiX2JhY2t0cmFj ZQ0KKzB4MjkNCl93aXRuZXNzX2RlYnVnZ2VyKGMwYzQ1NDRjLGMyY2I2Y2U4LGMwYzM0YzQwLGMy OTE0YTcwLGMwYzY0NWYxLC4uLikgYXQgX3dpdG5lc3NfDQpkZWJ1Z2dlcisweDI1DQp3aXRuZXNz X2NoZWNrb3JkZXIoYzJjYjZjZTgsOSxjMGM2NDVmMSw0YWIsYzJjYjZkMDQsLi4uKSBhdCB3aXRu ZXNzX2NoZWNrb3JkZXIrMA0KeDgzOQ0KX19sb2NrbWdyX2FyZ3MoYzJjYjZjZTgsODA0MDAsYzJj YjZkMDQsMCwwLC4uLikgYXQgX19sb2NrbWdyX2FyZ3MrMHg3OTcNCnZvcF9zdGRsb2NrKGMyNjdk YjA4LDU1NyxjMjY3ZGIwMCw4MDQwMCxjMmNiNmM5MCwuLi4pIGF0IHZvcF9zdGRsb2NrKzB4NjIN ClZPUF9MT0NLMV9BUFYoYzBkMWU3NDAsYzI2N2RiMDgsYzJjZTYwMDAsYzBkNTk2NjAsYzJjYjZj OTAsLi4uKSBhdCBWT1BfTE9DSzFfQVBWDQorMHhhNQ0KX3ZuX2xvY2soYzJjYjZjOTAsODA0MDAs YzBjNjQ1ZjEsNGFiLGMyY2I3MDAwLC4uLikgYXQgX3ZuX2xvY2srMHg1ZQ0KZmZzX2ZsdXNoZmls ZXMoYzJjNzYyODAsMixjMjk1NmQ4MCw1NTcsMywuLi4pIGF0IGZmc19mbHVzaGZpbGVzKzB4YTcN CnNvZnRkZXBfZmx1c2hmaWxlcyhjMmM3NjI4MCwyLGMyOTU2ZDgwLGMwYzRjMjhhLDhiYywuLi4p IGF0IHNvZnRkZXBfZmx1c2hmaWxlcyswDQp4MmUNCmZmc191bm1vdW50KGMyYzc2MjgwLDgwMDAw LGMyNjdkYmZjLDRlZixjMDg4ZWYxYiwuLi4pIGF0IGZmc191bm1vdW50KzB4MTQ5DQpkb3VubW91 bnQoYzJjNzYyODAsODAwMDAsYzI5NTZkODAsYzI0YjEyMzAsMCwuLi4pIGF0IGRvdW5tb3VudCsw eDQ2ZA0KdmZzX3VubW91bnRhbGwoYzBjM2YxNTQsMCxjMGMzZjFmZSwxMmEsMCwuLi4pIGF0IHZm c191bm1vdW50YWxsKzB4NGUNCmJvb3QoYzBkOGM3MTAsMCxjMGMzZjFmZSxhZCxjMjY3ZGQyYywu Li4pIGF0IGJvb3QrMHg0NGYNCnJlYm9vdChjMjk1NmQ4MCxjMjY3ZGNmOCw0LGMwYzQ2NjY1LGMw ZDIxZjI4LC4uLikgYXQgcmVib290KzB4NGINCnN5c2NhbGwoYzI2N2RkMzgpIGF0IHN5c2NhbGwr MHgyYTMNClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjANCi0tLSBz eXNjYWxsICg1NSwgRnJlZUJTRCBFTEYzMiwgcmVib290KSwgZWlwID0gMHg4MDUwZmUzLCBlc3Ag PSAweGJmYmZlODhjLCBlYnANCj0gMHhiZmJmZTk2OCAtLS0NClVwdGltZTogNDBzDQpLZXJuZWwg cGFnZSBmYXVsdCB3aXRoIHRoZSBmb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2NrcyBoZWxkOg0K ZXhjbHVzaXZlIHNsZWVwIG11dGV4IEFUQSBzdGF0ZSBsb2NrIChBVEEgc3RhdGUgbG9jaykgciA9 IDAgKDB4YzJhNDJjZDgpIGxvY2tlZA0KQCAvdXNyL3NyYy9zeXMvZGV2L2F0YS9hdGEtcXVldWUu YzoyMDENCmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBBVEEgcXVldWUgbG9jayAoQVRBIHF1ZXVlIGxv Y2spIHIgPSAwICgweGMyYTQyY2YwKSBsb2NrZWQNCkAgL3Vzci9zcmMvc3lzL2Rldi9hdGEvYXRh LXF1ZXVlLmM6MTg0DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3NlbGZfd3JhcHBl cihjMGM0MjY2NyxjMjY3ZDgyYyxjMDg5ZDBjNSxjMGJmM2RhMixiOCwuLi4pIGF0IGRiX3RyYWNl X3NlDQpsZl93cmFwcGVyKzB4MjYNCmtkYl9iYWNrdHJhY2UoYzBiZjNkYTIsYjgsZmZmZmZmZmYs YzBlY2NkYmMsYzI2N2Q4NjQsLi4uKSBhdCBrZGJfYmFja3RyYWNlKzB4MjkNCl93aXRuZXNzX2Rl YnVnZ2VyKGMwYzQ0OWY4LGMyNjdkODc4LDQsMSwwLC4uLikgYXQgX3dpdG5lc3NfZGVidWdnZXIr MHgyNQ0Kd2l0bmVzc193YXJuKDUsMCxjMGM3NmU3ZixjMjk1NmQ4MCxjMjk1NGQzNCwuLi4pIGF0 IHdpdG5lc3Nfd2FybisweDFmZA0KdHJhcChjMjY3ZDkwNCkgYXQgdHJhcCsweDE3Mw0KY2FsbHRy YXAoKSBhdCBjYWxsdHJhcCsweDYNCi0tLSB0cmFwIDB4YywgZWlwID0gMHhjMDU2NzExMCwgZXNw ID0gMHhjMjY3ZDk0NCwgZWJwID0gMHhjMjY3ZDk2MCAtLS0NCmF0YV9wcm9taXNlX3N4NF9jb21t YW5kKGMyZjQ4M2U4LGM5LGMyNjdkOTk4LGMwODRlYTkzLGMyYTQyY2Q4LC4uLikgYXQgYXRhX3By b21pDQpzZV9zeDRfY29tbWFuZCsweGEwDQphdGFfYmVnaW5fdHJhbnNhY3Rpb24oYzJmNDgzZTgs MCxjMGJmM2RhMixjOSxjMmE0MmNmMCwuLi4pIGF0IGF0YV9iZWdpbl90cmFuc2FjdA0KaW9uKzB4 N2ENCmF0YV9zdGFydChjMmE5MDAwMCwwLGMwYmYzZGEyLDVkLGMyYTQyY2YwLC4uLikgYXQgYXRh X3N0YXJ0KzB4MWRiDQphdGFfcXVldWVfcmVxdWVzdChjMmY0ODNlOCwwLDEwMSwwLGU3MDAwMDAw LC4uLikgYXQgYXRhX3F1ZXVlX3JlcXVlc3QrMHg0OTMNCmF0YV9jb250cm9sY21kKGMyYjU4MTgw LGU3LDAsMCwwLC4uLikgYXQgYXRhX2NvbnRyb2xjbWQrMHhkNg0KYWRfc2h1dGRvd24oYzJiNTgx ODAsYzJhMTQ4MzAsYzBkMjEwYzQpIGF0IGFkX3NodXRkb3duKzB4NGINCmRldmljZV9zaHV0ZG93 bihjMmI1ODE4MCxjMmE5MDAwMCxjMjY3ZGE5OCxjMDg4NDI0YyxjMmE5MDAwMCwuLi4pIGF0IGRl dmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3duKGMyYTkwMDAwLGMyOWU4 ODMwLGMwZDIxMGM0KSBhdCBidXNfZ2VuZXJpY19zaHV0ZG93bisweDE5DQpkZXZpY2Vfc2h1dGRv d24oYzJhOTAwMDAsYzJhNmJiMDAsYzI2N2RhYzAsYzA4ODQyNGMsYzJhNmJiMDAsLi4uKSBhdCBk ZXZpY2Vfc2h1dA0KZG93bisweDRjDQpidXNfZ2VuZXJpY19zaHV0ZG93bihjMmE2YmIwMCxjMmEw NTgzMCxjMGQyMTBjNCkgYXQgYnVzX2dlbmVyaWNfc2h1dGRvd24rMHgxOQ0KZGV2aWNlX3NodXRk b3duKGMyYTZiYjAwLGMyOTcxOTAwLGMyNjdkYWU4LGMwODg0MjRjLGMyOTcxOTAwLC4uLikgYXQg ZGV2aWNlX3NodXQNCmRvd24rMHg0Yw0KYnVzX2dlbmVyaWNfc2h1dGRvd24oYzI5NzE5MDAsYzJh MDEwMzAsYzBkMjEwYzQpIGF0IGJ1c19nZW5lcmljX3NodXRkb3duKzB4MTkNCmRldmljZV9zaHV0 ZG93bihjMjk3MTkwMCxjMmE1YWE4MCxjMjY3ZGIxMCxjMDg4NDI0YyxjMmE1YWE4MCwuLi4pIGF0 IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3duKGMyYTVhYTgwLGMy OWQ5ODMwLGMwZDIxMGM0KSBhdCBidXNfZ2VuZXJpY19zaHV0ZG93bisweDE5DQpkZXZpY2Vfc2h1 dGRvd24oYzJhNWFhODAsYzJhNWIzMDAsYzI2N2RiMzgsYzA4ODQyNGMsYzJhNWIzMDAsLi4uKSBh dCBkZXZpY2Vfc2h1dA0KZG93bisweDRjDQpidXNfZ2VuZXJpY19zaHV0ZG93bihjMmE1YjMwMCxj Mjk4YzAzMCxjMGQyMTBjNCkgYXQgYnVzX2dlbmVyaWNfc2h1dGRvd24rMHgxOQ0KZGV2aWNlX3No dXRkb3duKGMyYTViMzAwLGMyOTcxZTgwLGMyNjdkYjYwLGMwODg0MjRjLGMyOTcxZTgwLC4uLikg YXQgZGV2aWNlX3NodXQNCmRvd24rMHg0Yw0KYnVzX2dlbmVyaWNfc2h1dGRvd24oYzI5NzFlODAs YzI5ZGEwMzAsYzBkMjEwYzQpIGF0IGJ1c19nZW5lcmljX3NodXRkb3duKzB4MTkNCmRldmljZV9z aHV0ZG93bihjMjk3MWU4MCxjMmE0NDg4MCxjMjY3ZGI4OCxjMDRjZWMzNSxjMmE0NDg4MCwuLi4p IGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5lcmljX3NodXRkb3duKGMyYTQ0ODgw LDQsYzBiZTY2NDEsMmYzLGMyNjdkYmEwLC4uLikgYXQgYnVzX2dlbmVyaWNfc2h1dGRvDQp3bisw eDE5DQphY3BpX3NodXRkb3duKGMyYTQ0ODgwLGMyOWRjMDMwLGMwZDIxMGM0KSBhdCBhY3BpX3No dXRkb3duKzB4MzUNCmRldmljZV9zaHV0ZG93bihjMmE0NDg4MCxjMjk1MjI4MCxjMjY3ZGJjOCxj MDg4NDI0YyxjMjk1MjI4MCwuLi4pIGF0IGRldmljZV9zaHV0DQpkb3duKzB4NGMNCmJ1c19nZW5l cmljX3NodXRkb3duKGMyOTUyMjgwLGMyYTE0MDMwLGMwZDIxMGM0KSBhdCBidXNfZ2VuZXJpY19z aHV0ZG93bisweDE5DQpkZXZpY2Vfc2h1dGRvd24oYzI5NTIyODAsYzI5NTJjODAsYzI2N2RiZjAs YzA4ODQyNGMsYzI5NTJjODAsLi4uKSBhdCBkZXZpY2Vfc2h1dA0KZG93bisweDRjDQpidXNfZ2Vu ZXJpY19zaHV0ZG93bihjMjk1MmM4MCxjMjk3OTAzMCxjMGQyMTBjNCkgYXQgYnVzX2dlbmVyaWNf c2h1dGRvd24rMHgxOQ0KZGV2aWNlX3NodXRkb3duKGMyOTUyYzgwLDJkLGMwODEwOWJmLGMyOTMy MTQwLGMyOTBkNDQwLC4uLikgYXQgZGV2aWNlX3NodXRkb3duKzANCng0Yw0Kcm9vdF9idXNfbW9k dWxlX2hhbmRsZXIoYzI5MzIxODAsMiwwLDY3LGMyOTBiNmEwLC4uLikgYXQgcm9vdF9idXNfbW9k dWxlX2hhbmRsZXINCisweDEzZg0KbW9kdWxlX3NodXRkb3duKDAsNDAwMCxjMGMzZjFmZSwxYTcs MCwuLi4pIGF0IG1vZHVsZV9zaHV0ZG93bisweDc4DQpib290KGMwZDhjNzEwLDAsYzBjM2YxZmUs YWQsYzI2N2RkMmMsLi4uKSBhdCBib290KzB4NzVmDQpyZWJvb3QoYzI5NTZkODAsYzI2N2RjZjgs NCxjMGM0NjY2NSxjMGQyMWYyOCwuLi4pIGF0IHJlYm9vdCsweDRiDQpzeXNjYWxsKGMyNjdkZDM4 KSBhdCBzeXNjYWxsKzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2Fs bCsweDIwDQotLS0gc3lzY2FsbCAoNTUsIEZyZWVCU0QgRUxGMzIsIHJlYm9vdCksIGVpcCA9IDB4 ODA1MGZlMywgZXNwID0gMHhiZmJmZTg4YywgZWJwDQo9IDB4YmZiZmU5NjggLS0tDQoNCg0KRmF0 YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQ0KY3B1aWQgPSAwOyBh cGljIGlkID0gMDANCmZhdWx0IHZpcnR1YWwgYWRkcmVzcyAgID0gMHhjDQpmYXVsdCBjb2RlICAg ICAgICAgICAgICA9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBub3QgcHJlc2VudA0KaW5zdHJ1Y3Rp b24gcG9pbnRlciAgICAgPSAweDIwOjB4YzA1NjcxMTANCnN0YWNrIHBvaW50ZXIgICAgICAgICAg ID0gMHgyODoweGMyNjdkOTQ0DQpmcmFtZSBwb2ludGVyICAgICAgICAgICA9IDB4Mjg6MHhjMjY3 ZDk2MA0KY29kZSBzZWdtZW50ICAgICAgICAgICAgPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwg dHlwZSAweDFiDQogICAgICAgICAgICAgICAgICAgICAgICA9IERQTCAwLCBwcmVzIDEsIGRlZjMy IDEsIGdyYW4gMQ0KcHJvY2Vzc29yIGVmbGFncyAgICAgICAgPSBpbnRlcnJ1cHQgZW5hYmxlZCwg cmVzdW1lLCBJT1BMID0gMA0KY3VycmVudCBwcm9jZXNzICAgICAgICAgPSAxIChpbml0KQ0KW3Ro cmVhZCBwaWQgMSB0aWQgMTAwMDAyIF0NClN0b3BwZWQgYXQgICAgICBhdGFfcHJvbWlzZV9zeDRf Y29tbWFuZCsweGEwOiAgIG1vdmwgICAgMHhjKCVlYXgpLCVlc2kNCmRiPg== --0016364c749b694ad8046a4368ff-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:14:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6CD1065673 for ; Tue, 19 May 2009 13:14:42 +0000 (UTC) (envelope-from pascal.braun@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1D75F8FC1A for ; Tue, 19 May 2009 13:14:41 +0000 (UTC) (envelope-from pascal.braun@continum.net) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.73]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6P9Z-0007OZ-5I; Tue, 19 May 2009 15:14:45 +0200 Message-ID: <4A12B0B8.5020507@continum.net> Date: Tue, 19 May 2009 15:14:32 +0200 From: Pascal Braun User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4A127C56.6040502@continum.net> <20090519104133.GF4697@michelle.cdnetworks.co.kr> In-Reply-To: <20090519104133.GF4697@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with jumbo frames on nfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:14:42 -0000 Pyun YongHyeon wrote: > On Tue, May 19, 2009 at 11:31:02AM +0200, Pascal Braun wrote: >> Hi, >> >> I'm currently testing jumbo frames on a Sunfire 4540 running with >> FreeBSD 8-Current (build on April 8th). While using the nfe driver I'm >> having some unexpected problems if i try to bring up the interface with >> MTU sizes greater than 1970 bytes. >> >> The error message (in dmesg) is: >> nfe2: initialization failed: no memory for rx buffers >> > > It means you've run out of jumbo clusters. Check the output of > "netstat -m" and see how many jumbo cluster requests were denied. 771/1149/1920 mbufs in use (current/cache/total) 770/680/1450/25600 mbuf clusters in use (current/cache/total/max) 770/510 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/16384 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1732K/1683K/3416K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines There are no denied requests. MTU size was about 1800. But I have to add, that i cant even get the interface up if the mtu size is above 1970. >> Does anyone have any ideas how to get jumbo frames working? >> > > How about increasing 9K jumbo clusters(kern.ipc.nmbjumbo9) with > sysctl(8)? sunfire# sysctl -a | grep jumbo kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 16384 kern.ipc.nmbjumbop: 12800 I increased kern.ipc.nmbjumbo9 to 16384 (was 6400) but that didn't seem to help. Do you have another idea? Regards Pascal From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:22:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A5C106567D; Tue, 19 May 2009 13:22:53 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 3208D8FC28; Tue, 19 May 2009 13:22:52 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so4689187ewy.43 for ; Tue, 19 May 2009 06:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BxfW4cwxEolEZhuJdVy2GH8rKnvj5JZCwY10urQKeiw=; b=WrUyIfXjWEs90aaL/V5GcRUkDEmJuTeBlaqawueGviBTHRXTJckLQbD3c8wzoPHKLT jPyqX5XoyFVOiftErsoEWzh+lBZhTqcxUcD4MZyiQd8ABm/xy/WB8Y1m5PSk3z/Scehm ocrHSmLJyRhfhhcByxcHU/bKyn9vg5RNQrWOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Mj9ByBmexBlJrSsRmHSrcOisDUEykDIl9UVbb65SbKT0TQ8aYNHPNpFoumx+X9JWme 9ntJ3EYwrXv3B/ScgvJlCe6lnC0GhRIt/9QLXWYUK7Kw9jWGaWMNgF9yBniwebptijuZ BjIrdRNQh+cqzl0mYvVqvxw1fcRIm43dQn3oU= MIME-Version: 1.0 Received: by 10.216.8.213 with SMTP id 63mr8275wer.161.1242739372133; Tue, 19 May 2009 06:22:52 -0700 (PDT) In-Reply-To: <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> Date: Tue, 19 May 2009 15:22:52 +0200 Message-ID: <43b1bb350905190622t5e52b6e1kbb85af95e98debeb@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:22:54 -0000 2009/5/19 Magnus Kling > 2009/5/19 Alexander Motin > >> Magnus Kling wrote: >> >> > I applied the patch and rebuilt the kernel. But when should this be >> > printed? At shutdown or boot? I can=B4t see it at all. >> >> On shutdown before panic. >> >> > When panic occurs I got the attached text as output on my serial >> console. >> >> Attached where? >> >> > The raidcontroller has two ata disks attached. Using RAID 1. My OS is = on >> > a separate disk using the motherboards ata connector. >> > Should I disable(unplug the disks) and add a spare harddrive in non-ra= id >> > state to the raid card? >> >> Yes, I mean this exactly. Unplug your disk and insert some another >> without building RAID on it. >> >> -- >> Alexander Motin >> > > Sorry missed the attachment. > Will find a spare disk ASAP. > > /Magnus Tried with a spare disk. Added it as a JBOD on one channel and mounted it i= n the OS. Guess what... Reboot works! At reboot the disks are synced and then the computer is rebooted. /Magnus From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:31:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34E81065670; Tue, 19 May 2009 13:31:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6ADF48FC12; Tue, 19 May 2009 13:31:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so6738732qyk.3 for ; Tue, 19 May 2009 06:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Ad/wgvh1RyQEEWphH+4okAyZKXbVI2PUp5cZBlXEWgc=; b=f1P9QyUiFoNpvAhcCckPZl/11u9J6rkaRipbdnZ3icAgtWsze+yTXwUtnF8wPue5p1 8EUt2R+V4RTgU7Ly32eKPRFkijSvPciMX1PlyLB4TNELQJA/RHfLGfbfjluMIp57MlG3 ZAUzDAZNJUY/sOJTTo3n+vZwS5rI8C3Tb1WTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Kku4i9WwqkmE8pkbdtu2E4ubkVJDYKAIqmr2UFiq+XBzEJK6luuDKFA2C9n3fDYnuZ oF7dgyNkynr3I6otINQmnPWyhX5Ax3hwDIslDngwFqR9UuDjDWFatAn7EBmP8xGGiXC8 bwSxbM2CNt3OuIkqLCQGZikmCunyXU9y8pzvA= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.74.71 with SMTP id t7mr9653qcj.67.1242739867464; Tue, 19 May 2009 06:31:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2009 21:31:07 +0800 X-Google-Sender-Auth: e4355dfded71b240 Message-ID: From: Adrian Chadd To: Saifi Khan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:31:09 -0000 2009/5/19 Saifi Khan : > =A0. is dom0 support something that FreeBSD will target at some > =A0 point in time or would be happy to be domU ? If Kip (and other Xen-clueful people get funding) - and there's time - then I bet so. > =A0. there was some mention of vimage/bitvisor in one of the > =A0 slides (i think on scribd.com). So, is it that jails getting > =A0 extended to support virtualization+containers and thus a > =A0 entirely different approach which does not use Xen ? These solve different problem sets. :) People seem to think "virtualisation" is "virtualisation". It isn't. It depends on what kind(s) of problems you're trying to solve. Xen solves a certain set of virtualisation problems. > =A0. is it envisaged that a stable NetBSD dom0 implementation > =A0 would then be ported to FreeBSD (maybe) ? No idea. Is it stable? :) Personally, I'd prefer to see the FreeBSD DomU stuff 100% bulletproof and documented before more stuff is hacked on, but as I said before, I'm just interested in getting the current pieces into some kind of documented shape; I'm not hacking on Xen by any stretch of the imagination! Adrian From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:35:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02CF106566B for ; Tue, 19 May 2009 13:35:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 80F418FC18 for ; Tue, 19 May 2009 13:35:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 328A746B09; Tue, 19 May 2009 09:35:29 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0FB7F8A028; Tue, 19 May 2009 09:35:28 -0400 (EDT) From: John Baldwin To: Ben Kelly Date: Tue, 19 May 2009 08:31:48 -0400 User-Agent: KMail/1.9.7 References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190831.48523.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 19 May 2009 09:35:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Adam McDougall , freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:35:29 -0000 On Monday 18 May 2009 10:16:46 pm Ben Kelly wrote: > On May 18, 2009, at 11:29 AM, John Baldwin wrote: > > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: > >> 1) It changes the kproc(9) API by adding a kproc_create_priority() > >> function that allows you to set the priority of the newly created > >> thread. I'm not sure how people feel about this. > > > > Actually, I almost think we should just add a priority argument to > > each of the > > routines that creates a new kthread/kproc. Perhaps allow a priority > > of 0 to > > let the thread run with the default priority. Hmm, it looks like > > kthreads > > default to running with whatever thread0 runs at (PVM) which is > > probably not > > really ideal. Having an explicit priority for every kthread would > > probably > > be best. Most kthreads should probably be at PZERO by default I > > think. > > If this approach was taken would it make sense to use a flag to > indicate "use the specified priority" since 0 is a valid priority value? Well, 0 isn't truly valid (it's sort of reserved I guess), and we already use 0 for tsleep() to mean "don't change my priority". However, I would almost be inclined to just KASSERT() that the priority argument is not 0 and require each place that creates a kthread to explicitly set the new thread's priority. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:43:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ABAD106566B; Tue, 19 May 2009 13:43:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3718FC13; Tue, 19 May 2009 13:43:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6PbR-0001fz-6n; Tue, 19 May 2009 13:43:33 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 11B4A17C275B; Tue, 19 May 2009 06:43:33 -0700 (PDT) Date: Tue, 19 May 2009 06:43:32 -0700 Message-ID: From: Randy Bush To: Peter Jeremy In-Reply-To: <20090519100744.GB5943@server.vk2pj.dyndns.org> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Marcel Moolenaar , current@freebsd.org, Andrew Thompson Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:43:34 -0000 >> I used gpart for the first time today and a few things came to mind. > You're not alone. Have a look at > http://lists.freebsd.org/pipermail/freebsd-arch/2008-November/008731.html and how the hell do i use it on a raw install? it is not on snapshot 200905 disk1 or livecd. randy From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:52:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEDCD1065676 for ; Tue, 19 May 2009 13:52:32 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9E16E8FC22 for ; Tue, 19 May 2009 13:52:31 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id EC4BF3A581 for ; Tue, 19 May 2009 15:35:16 +0200 (CEST) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Tue, 19 May 2009 15:35:16 +0200 Message-ID: <20090519153516.yki2cyqpwg48sk04@0x20.net> X-Priority: 3 (Normal) Date: Tue, 19 May 2009 15:35:16 +0200 From: Lars Engels To: freebsd-current@freebsd.org References: <4A11A08B.6090309@errno.com> In-Reply-To: <4A11A08B.6090309@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_6wapwxlldbks"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:52:33 -0000 This message is in MIME format and has been PGP signed. --=_6wapwxlldbks Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Sam Leffler : > The patch here: > > http://people.freebsd.org/~sam/monitor-20090518.patch > > has significant changes to monitor mode operation. Most importantly it > replaces DLT_IEEE802_11 support in net80211 by DLT_IEEE802_11_RADIO and > removes the latter from the underlying device. The upshot is that you > can no longer do: > > tcpdump -i ath0 > > instead you will now need a wlanX ifnet; e.g. > > ifconfig wlan create wlandev ath0 wlanmode monitor channel 6 up > tcpdump -i wlan0 -y IEEE802_11_RADIO > > This addresses the longstanding issue that applications like kismet > that want radiotap data needed to open two ifnets, one to receive data > and one to do channel changes. My main concern is whether losing > DLT_IEEE802_11 support will affect any apps. Those that depend on it > should be easy to change; you just request a different DLT and strip > the radiotap header from tap'd frames (or similar). > > In sweeping the drivers to do these changes I've made radiotap support > more consistent and improved some drivers. Drivers not tested so far: > malo, ipw, wpi, and upgt. I tested iwi and it appears broken in that > no frames are rx'd but I'm not sure I'll look at it before 8.0. > > I plan to commit these changes by the end of the week. > > Sam Thanks, this should improve operability of aircrack-ng, too. I will try this tomorrow. --=_6wapwxlldbks Content-Type: application/pgp-signature Content-Description: PGP Digital Signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkoStZQACgkQKc512sD3afiKXQCgnXhbQxozDkONr1ORG2hJdl9S nwIAoLua4ceSQLHPB8bHT0esekXV/kZg =g65P -----END PGP SIGNATURE----- --=_6wapwxlldbks-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 13:52:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E98B1065722 for ; Tue, 19 May 2009 13:52:43 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id B32558FC17 for ; Tue, 19 May 2009 13:52:42 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 63FAE4AC5D; Tue, 19 May 2009 15:52:40 +0200 (CEST) Date: Tue, 19 May 2009 15:52:40 +0200 From: Martin Wilke To: subbsd Message-ID: <20090519135240.GH71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <200905191616.07296.subbsd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200905191616.07296.subbsd@gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:52:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, May 19, 2009 at 04:16:06PM +0400, subbsd wrote: > Hello > > On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: > > Howdy .. > > > > Next run, > > > > We updated the port to 2.2.2r19801. > > The Patch files/patch-amd64-r0-exec-alloc > > was removed in favor of a similar fix > > commited to upstream. Also was fixed a > > bug on HEAD which should be fix the Kernel > > crash. Please test test test .. :-) > > > > PS: Yes this run is for AMD64 and HEAD > > users! > > > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > > > > Happy Testing! > > I've try to compile this port on i386/8-CURRENT ( kern.osreldate: 800087 ) and > job stops with last messages: please update your src/kernel and rebuild vbox > -- > /* ... */ > kBuild: xsltproc VBoxSVC - > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Main/idl/xpidl.xsl > kBuild: Compiling RuntimeR3 - > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsg.cpp > kBuild: Compiling RuntimeR3 - > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsgxpcom.cpp > kBuild: Linking RuntimeR0 > kBuild: Linking RuntimeGC > kBuild: Linking RuntimeEFCPP > kBuild: Linking RuntimeR3NoCRTGCC > kBuild: Compiling RuntimeR0Drv - > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/alloc/alloc.cpp > kBuild: Linking VMMR3 > kBuild: Compiling PcBiosBin - > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: > error: need ';' > /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: > error: need variable name > kmk[2]: *** > [/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s] > Error 1 > kmk[2]: *** Deleting file > `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s' > kmk[2]: *** Waiting for unfinished jobs.... > kmk[2]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > kmk[2]: Entering directory > `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_libraries_this] Error 2 > kmk[1]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > kmk: *** [pass_libraries_order] Error 2 > *** Error code 2 > > Stop in /usr/ports/emulators/virtualbox. > > -- > > DISABLE_MAKE_JOBS=yes options is not influence > In the _rombios__c at 471 i see strings: > > static char bios_cvs_version_string[] = "VirtualBox " "2.2.51_OSE"; > > but ';' symbol is presents. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoSuagACgkQdLJIhLHm/Om5MACdFj88b4lDffxr2+22UIrL2Oeg 28wAn2dB6eijdy/a0lu88kI+aeFeUzJG =LD+Z -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 15:24:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B6B9106564A for ; Tue, 19 May 2009 15:24:21 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA078FC16 for ; Tue, 19 May 2009 15:24:20 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4JFAd5p037412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 17:10:42 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A12CBE9.5010206@omnilan.de> Date: Tue, 19 May 2009 17:10:33 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9399A85234520E566FBB6E4F" Subject: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:24:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9399A85234520E566FBB6E4F Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, recently I switched to -current again since 7.2 hasn't fixed some=20 longstanding problems for me. Unfortunately -current also doesn't. 1. Setting dev.cpu.0.freq to reduced freq _increases_ power consumtion. This also is true with powerd. When machine is idle, the primary power=20 consumtion is a little over 75W (which is quiet good for a triple-head=20 system). When I alter cpu.0.freq to anything other than native speed=20 (3000 in my case) the power consumption slightly incresaes about 1W. Here's the relevant dmesg part (`dmesg | grep -i cpu`): CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3003.02-MHz=20 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu0: on acpi0 acpi_perf0: on cpu0 coretemp0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a092006000920 p4tcc1: on cpu1 SMP: AP CPU #1 Launched! 2. acpiconf -s3 hasn't worked for me regardless which vga card used. When I use the nvidia driver, system refuses to go into S3 (acpi0:=20 device_suspend failed). If I don't load the module, the system suspends=20 but never wakes up. After repowering everything seems to be up=20 (consuming ~80W) but there's no VGA output. I also changed my two nvidia = cards with one radeon, no matter. 3. I can't write a DVD image with growisofs. After booting I get these messages: acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 (cd1:ata3:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 (cd1:ata3:0:0:0): CAM Status: SCSI Status Error (cd1:ata3:0:0:0): SCSI Status: Check Condition (cd1:ata3:0:0:0): ILLEGAL REQUEST asc:24,0 (cd1:ata3:0:0:0): Invalid field in CDB (cd1:ata3:0:0:0): Unretryable error Using `growisofs -dvd-compat -speed=3D8 -Z /dev/cd1=3D/udfimage.iso` free= zes=20 the system. First it seems nothing happens but after some minutes the=20 system is completely unresponsive, even mouse doesn't move any more.=20 Here's some output I got at this event: =2E.. acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request acd1: WARNING - PREVENT_ALLOW taskqueue timeout - completing request=20 directly acd1: WARNING - PREVENT_ALLOW freeing taskqueue zombie request acd1: WARNING - TEST_UNIT_READY taskqueue timeout - completing request=20 directly acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request acd1: WARNING - READ_TOC taskqueue timeout - completing request directly acd1: WARNING - READ_TOC freeing taskqueue zombie reques =2E.. 4. Starting with 8-current I get this for me unknown botting message: atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. 5. For at least 2 years I see this to me unknown booting message: acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Thanks for any hints/explanations/clarifications in advance! -Harry --------------enig9399A85234520E566FBB6E4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoSy+8ACgkQLDqVQ9VXb8iC9gCfedoGImU2CMYx0KdYwX/x8qZZ aLwAoMhf8C5BNGAuor7fSmEtG2nSeVKR =/iwY -----END PGP SIGNATURE----- --------------enig9399A85234520E566FBB6E4F-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 15:45:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 815FC1065672; Tue, 19 May 2009 15:45:51 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 551488FC20; Tue, 19 May 2009 15:45:51 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:43106 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6RVk-000MCi-J2; Tue, 19 May 2009 10:45:50 -0500 Date: Tue, 19 May 2009 10:45:22 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Kip Macy In-Reply-To: <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> Message-ID: References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.3 (--) X-LERCTR-Spam-Score: -2.3 (--) X-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: Adam McDougall , current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:45:51 -0000 On Mon, 18 May 2009, Kip Macy wrote: > > > Please update to r192360 and let me know if that helps. > This seems MUCH better behaved. I still see the wired count go really high, but we don't start paging, and the system stays up on multiple differential backups running consecutively, and a buildworld running in the background. I don't mind the wired count going very high, as long as it's released if the system needs it for "real work" other than cache. Thanks! LER > > Thanks, > Kip > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue May 19 15:53:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFAEA1065673; Tue, 19 May 2009 15:53:17 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 66EA48FC0A; Tue, 19 May 2009 15:53:17 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4JFrDUW037946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 17:53:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A12D5E9.5060109@omnilan.de> Date: Tue, 19 May 2009 17:53:13 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: "O. Hartmann" References: <49F56337.8040900@zedat.fu-berlin.de> In-Reply-To: <49F56337.8040900@zedat.fu-berlin.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9719598ED429A4CEF3573244" Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PAM/ldap_pam/NFSv4: How let users of a speicific group log into a specific box? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:53:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9719598ED429A4CEF3573244 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable O. Hartmann schrieb am 27.04.2009 09:48 (localtime): =2E.. > This is what I wish to get and need: >=20 > A simple capability of selecting users into a specific group. Members o= f=20 > such a group should then log into a set of specific hosts. > Infrastructure is FreeBSD 8.0-CURRENT/amd64 and some 7.2-STABLE boxes=20 > (acting as server) as well as OpenLDAP backend. I've done something similar with specifying allowed hosts per user with=20 pam_ldap required for "account". Let me know if this was an option for you. Regards, -Harry --------------enig9719598ED429A4CEF3573244 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoS1ekACgkQLDqVQ9VXb8h3nQCeLEQ4+75nlT1nrDYjzbR1ysNA 0qYAn2+n1LIHPkdHGkNNem8ZIhrNQkYv =eg2r -----END PGP SIGNATURE----- --------------enig9719598ED429A4CEF3573244-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 15:59:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E10B106564A for ; Tue, 19 May 2009 15:59:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88C118FC26 for ; Tue, 19 May 2009 15:59:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA21178; Tue, 19 May 2009 18:59:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A12D754.4020607@icyb.net.ua> Date: Tue, 19 May 2009 18:59:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4A12CBE9.5010206@omnilan.de> In-Reply-To: <4A12CBE9.5010206@omnilan.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:59:29 -0000 on 19/05/2009 18:10 Harald Schmalzbauer said the following: > 5. For at least 2 years I see this to me unknown booting message: > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fde0000 (3) failed This one is innocent - ACPI ASL defines regions for "free" RAM. OS handling is to reserve all ACPI defined regions to acpi driver. And obviously these two regions can not and need not be reserved in reality. Let me guess - you have 2GB of RAM on this machine :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 19 16:25:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F971065678 for ; Tue, 19 May 2009 16:25:14 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8128FC21 for ; Tue, 19 May 2009 16:25:12 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 26494 invoked by uid 1002); 19 May 2009 16:25:10 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.92.196.6) by s217.sureserver.com with ESMTPA; 19 May 2009 16:25:10 -0000 Date: Tue, 19 May 2009 21:57:48 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: Adrian Chadd In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:25:15 -0000 On Tue, 19 May 2009, Adrian Chadd wrote: > > People seem to think "virtualisation" is "virtualisation". It isn't. > It depends on what kind(s) of problems you're trying to solve. Xen > solves a certain set of virtualisation problems. > Could you please share 'your insight' on the 'set of virtualization problems' that Xen solves ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Tue May 19 16:29:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D58106566B for ; Tue, 19 May 2009 16:29:41 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 4327A8FC1A for ; Tue, 19 May 2009 16:29:41 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id CFC1416C8B5; Tue, 19 May 2009 18:29:39 +0200 (CEST) Received: from carrot.geeknest.org (gaupe.stud.ntnu.no [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 54EEF16C8B2; Tue, 19 May 2009 18:29:38 +0200 (CEST) Date: Tue, 19 May 2009 18:29:36 +0200 From: Ulf Lilleengen To: Randy Bush Message-ID: <20090519162936.GB1457@carrot.geeknest.org> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:29:42 -0000 On Tue, May 19, 2009 at 06:43:32AM -0700, Randy Bush wrote: > >> I used gpart for the first time today and a few things came to mind. > > You're not alone. Have a look at > > http://lists.freebsd.org/pipermail/freebsd-arch/2008-November/008731.html > > and how the hell do i use it on a raw install? it is not on snapshot > 200905 disk1 or livecd. > I've been using gpart on the livecd for a long time. You might want to do a chroot to /dist or something first though. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:07:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419D2106566B for ; Tue, 19 May 2009 17:07:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 213C38FC1C for ; Tue, 19 May 2009 17:07:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6SmK-00026t-PL; Tue, 19 May 2009 17:07:00 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 9C92717D69A5; Tue, 19 May 2009 10:07:00 -0700 (PDT) Date: Tue, 19 May 2009 10:07:00 -0700 Message-ID: From: Randy Bush To: Ulf Lilleengen In-Reply-To: <20090519162936.GB1457@carrot.geeknest.org> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:07:02 -0000 >>>> I used gpart for the first time today and a few things came to mind. >>> You're not alone. Have a look at >>> http://lists.freebsd.org/pipermail/freebsd-arch/2008-November/008731.html >> and how the hell do i use it on a raw install? it is not on snapshot >> 200905 disk1 or livecd. > I've been using gpart on the livecd for a long time. You might want to do a > chroot to /dist or something first though. ok, kinda ad4 ad5 and ad6 are in my dmesg Fixit# gpart create -s gpt /dev/ad4 gpart: No such file or directory Fixit# gpart create -s GPT /dev/ad4 gpart: No such file or directory Fixit# gpart create -s GPT ad4 gpart: No such file or directory randy From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:10:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE4BE106564A for ; Tue, 19 May 2009 17:10:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7698FC13 for ; Tue, 19 May 2009 17:10:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 478BBFF12; Wed, 20 May 2009 05:10:35 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGTSFSe-oakI; Wed, 20 May 2009 05:10:31 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 20 May 2009 05:10:31 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 1181011434; Wed, 20 May 2009 05:10:31 +1200 (NZST) Date: Tue, 19 May 2009 10:10:30 -0700 From: Andrew Thompson To: Randy Bush Message-ID: <20090519171030.GG78829@citylink.fud.org.nz> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org, Ulf Lilleengen Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:10:36 -0000 On Tue, May 19, 2009 at 10:07:00AM -0700, Randy Bush wrote: > >>>> I used gpart for the first time today and a few things came to mind. > >>> You're not alone. Have a look at > >>> http://lists.freebsd.org/pipermail/freebsd-arch/2008-November/008731.html > >> and how the hell do i use it on a raw install? it is not on snapshot > >> 200905 disk1 or livecd. > > I've been using gpart on the livecd for a long time. You might want to do a > > chroot to /dist or something first though. > > ok, kinda > > ad4 ad5 and ad6 are in my dmesg > > Fixit# gpart create -s gpt /dev/ad4 > gpart: No such file or directory > > Fixit# gpart create -s GPT /dev/ad4 > gpart: No such file or directory > > Fixit# gpart create -s GPT ad4 > gpart: No such file or directory > > If you have done a chroot then you need to make sure devfs is also mounted within it mount -t devfs devfs /dist/dev Andrew From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:28:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 363A21065670 for ; Tue, 19 May 2009 17:28:39 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B1A258FC12 for ; Tue, 19 May 2009 17:28:38 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4JHSYOB041490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 19:28:37 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A12EC37.2020904@omnilan.de> Date: Tue, 19 May 2009 19:28:23 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5989888A14A89D146DBD6777" Subject: Need help with "xptioctl: pass driver is not in the kernel" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:28:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5989888A14A89D146DBD6777 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, when I plug in a UFD I get the message from the topic. But of course I do have pass in my kernel. That may be the reason why hal/xfce-volman isn't working for me any more = with -current (which worked fine with 7.1-7.2). After the UFD plugin=20 there's no hald-addonstorage anymore... Thanks for any hints, -Harry --------------enig5989888A14A89D146DBD6777 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoS7EIACgkQLDqVQ9VXb8gFggCguXAECGnJ0eUYvhsXrHhf9Scs VqMAoKUyOq8S6Q37aUQ+mnMrZbVlO3lL =8/Nx -----END PGP SIGNATURE----- --------------enig5989888A14A89D146DBD6777-- From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:33:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C7E1065676; Tue, 19 May 2009 17:33:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 741F78FC18; Tue, 19 May 2009 17:33:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6TC1-0002A4-29; Tue, 19 May 2009 17:33:33 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CCBFC17D920F; Tue, 19 May 2009 10:33:32 -0700 (PDT) Date: Tue, 19 May 2009 10:33:32 -0700 Message-ID: From: Randy Bush To: Andrew Thompson In-Reply-To: <20090519171030.GG78829@citylink.fud.org.nz> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org, Ulf Lilleengen Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:33:34 -0000 > If you have done a chroot then you need to make sure devfs is also > mounted within it > > mount -t devfs devfs /dist/dev thanks. Fixit# gpart create -s gpt /dev/ad4 gpart: geom 'ad4': File exists Fixit# gpart create -s gpt ad4 gpart: geom 'ad4': File exists sorry to be such a pita From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:56:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7638B1065687; Tue, 19 May 2009 17:56:38 +0000 (UTC) (envelope-from mickael.torres@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 64A7C8FC25; Tue, 19 May 2009 17:56:37 +0000 (UTC) (envelope-from mickael.torres@gmail.com) Received: by bwz9 with SMTP id 9so3980152bwz.43 for ; Tue, 19 May 2009 10:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=UJSc/RCua0szbP8QZfyZ8P/x+C5u1kLNQ4fc1RSsMKA=; b=xdfD/tqHAYU7fmqNsE9GzbKy3c2VVTgY/jualt75y+dl55gpktKglCaa0UFkhqHhYk 3BCVe6Jl/8HeYvqEI1dhwsG1IwOxuTHTGtN/UIH29DOa7qrmNEOZHXrjQRJThrMguLAT yJh9L2988Hh5kfP7aDc8rTmsIhqrJX+j+fDjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=NSHDqI19E09+3/SqIdx1Sv0GXw7lJG1IbUWlO/mV13/agHzUYD/s8PHUSvoU75Nmuh YwipoJ4kF39HFCCtAkwduKOQnbVBtElJhoyJBOIt0cz8CWWhKVssNvUDrhOF/MRLgbxE BbaHd5eoH9R9efj9Zog/ZAEkhU+KOt9b8qDAk= Received: by 10.204.55.1 with SMTP id s1mr254741bkg.132.1242754224991; Tue, 19 May 2009 10:30:24 -0700 (PDT) Received: from ?10.21.22.241? ([193.253.141.89]) by mx.google.com with ESMTPS id h2sm246452fkh.36.2009.05.19.10.30.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 10:30:24 -0700 (PDT) References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> Message-Id: From: Mickael Torres To: Martin Wilke In-Reply-To: <20090517180920.GY71804@bsdcrew.de> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5G77) Mime-Version: 1.0 (iPhone Mail 5G77) Date: Tue, 19 May 2009 19:30:13 +0200 Cc: "ports@FreeBSD.org" , "freebsd-emulation@freebsd.org" , "freebsd-current@FreeBSD.org" Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:56:40 -0000 On 17 mai 09, at 20:09, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We rolled a new tarball with the patch from Juergen Lock [1] > with a posible fix for AMD64 users, tested on 3 machines > which now works without problems. Many Thanks to him for > his nice work! > > http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz > > Martin > Tested on a 7-stable/amd64 from yesterday. Works great with VT with win64 / openbsd64 guests. Thanks :) Mike. > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEUEARECAAYFAkoQUtAACgkQdLJIhLHm/OlY2QCg1KZW2YCvE1VhqKgSQ/xhjKIx > U60Al2UMniKg+KvQ6m9RcP92eOMddfQ= > =kB6c > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From owner-freebsd-current@FreeBSD.ORG Tue May 19 18:22:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10A86106566C; Tue, 19 May 2009 18:22:02 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCC88FC13; Tue, 19 May 2009 18:21:52 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by gxk10 with SMTP id 10so1513gxk.19 for ; Tue, 19 May 2009 11:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qXPChlMpEdogv5JT62u8Mr1o1Jwd8paEFwTqV2eKy/U=; b=PMYWiXUg0F3eBLK6tPzQfDjB6bU5Igwn1M677P4ACnUVirUQ1RPUbOQyJjtcLcsJkl L18f0ikB9HyDfYKq/tEzpNaVg7eG1YE85k06S6fdt80cVjmWVLmZpcBV8WTXbZFHzJ7q uqkNRVzEd6epWLaGtmmtrdfpTvR9mqW/AOt2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iEqhKO/58UpKYzqt2wd1Qk7+J6dii3FfY/eAW0d9+HUR5L4eeqJ5Sg9JpyRwe874Vx 11tmIbs4o2I+ofKtZlfL8XsEJDLeLd6HeAOaVVpHhzwKZaTVEPzNgkCx8ZCKImd4dpZm r3fGmIX5UVTD92HxWWeMtKXZ5zw20meqLrzlQ= MIME-Version: 1.0 Received: by 10.151.129.3 with SMTP id g3mr771945ybn.84.1242757282500; Tue, 19 May 2009 11:21:22 -0700 (PDT) In-Reply-To: <20090519044941.GC42412@weongyo.cdnetworks.kr> References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <200905181050.03154.hselasky@c2i.net> <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> <20090519044941.GC42412@weongyo.cdnetworks.kr> Date: Tue, 19 May 2009 20:21:22 +0200 Message-ID: <90a5caac0905191121r7da4f6e8t733eff327cf551e0@mail.gmail.com> From: Lucius Windschuh To: Weongyo Jeong , freebsd-current@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:22:02 -0000 2009/5/19 Weongyo Jeong : > On Tue, May 19, 2009 at 12:08:45AM +0200, Lucius Windschuh wrote: >> 2009/5/18 Hans Petter Selasky : >> > Regarding the first panic, there seems to be a detach race in both upg= t and >> > uath, which is not USB related. Try this patch: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=3D162250 >> >> This fixes not only the first panic. >> I can't provoke any panic by pulling out the active device. Thanks. > > Could you please test with this patch that is slightly different with > Hans's patch? =A0It try to unsetup after stopping the device. > > If no problems I'd commit it. This works also. I cannot produce panics with it. Lucius From owner-freebsd-current@FreeBSD.ORG Tue May 19 18:27:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310881065701 for ; Tue, 19 May 2009 18:27:54 +0000 (UTC) (envelope-from lwindschuh@googlemail.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 DE9AC8FC0A for ; Tue, 19 May 2009 18:27:53 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so2500134ywe.13 for ; Tue, 19 May 2009 11:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4CYwuB0RNCdfulNHW3na9Sxr8u2D4kEDlL2VkWEodzk=; b=BCku8Z9oJ9XLlgtGl8ggXOFkhGpQdwHk7vGLXRat8D9P5Jfmb+unZV0EJVj9VteCI6 UorLrBKRXxIThmzNTZcmomnBUeyUCnFuf1KzCoW0uBu2w9OknAnyhnG5+EoIoI5peMhl 2wHOZNx+7dsrxruhyxixZZHujZVLCunSZYDuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WngcKXFRncGXGkx+BIezQ3cIYT6oyOCkCJbds3tBv+xfDaw7wZ6S2eApSD1vVn/Wen Veob0T4/yUs0mzFBD9eAt6Ryn81dCwKf/5BIoadh8PWfFnOQRKe3KxRh6ryHysoAucBr OLjGfUSHqi9WtJo2on5s86UTFO1C/Er+ukpqI= MIME-Version: 1.0 Received: by 10.150.140.19 with SMTP id n19mr697667ybd.312.1242757673300; Tue, 19 May 2009 11:27:53 -0700 (PDT) In-Reply-To: <200905190916.06460.hselasky@c2i.net> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <4A0F419A.2020700@freebsd.org> <20090519050132.GE42412@weongyo.cdnetworks.kr> <200905190916.06460.hselasky@c2i.net> Date: Tue, 19 May 2009 20:27:53 +0200 Message-ID: <90a5caac0905191127y5677bea9s827bb3d6a9f82176@mail.gmail.com> From: Lucius Windschuh To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:27:55 -0000 2009/5/19 Hans Petter Selasky : [missing device initialization message] > > Fix here: > > http://perforce.freebsd.org/chv.cgi?CH=162306 The output is nice now. Lucius. From owner-freebsd-current@FreeBSD.ORG Tue May 19 18:46:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56122106566B for ; Tue, 19 May 2009 18:46:52 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: from hisar.endersys.com (hisar.endersys.com [213.144.99.107]) by mx1.freebsd.org (Postfix) with ESMTP id 4063A8FC19 for ; Tue, 19 May 2009 18:46:50 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: (surgate 77942 invoked by uid 1001); 19 May 2009 18:15:20 -0000 Received: from unknown (HELO ISMAILYENIGUL) (ismail.yenigul@endersys.com@127.0.0.1) by 0 with ESMTPA; 19 May 2009 18:15:20 -0000 Date: Tue, 19 May 2009 21:19:59 +0300 From: Ismail YENIGUL Organization: =?windows-1254?Q?Endersys_Dan=FD=FEmanl=FDk_ve_Yaz=FDl=FDm_Ltd.?= X-Priority: 3 (Normal) Message-ID: <611494930.20090519211959@endersys.com> To: Martin Wilke In-Reply-To: <20090519135240.GH71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de><20090517180920.GY71804@bsdcrew.de><20090519091310.GB71804@bsdcrew.de><200905191616.07296.subbsd@gmail.com> <20090519135240.GH71804@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1254 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re[2]: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ismail YENIGUL List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:46:52 -0000 Hello Martin, I installed http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz on FreeB= SD 8 snapshot-200905 amd64. It compiled successfully, But When I create a virtual server (Redhat) and c= lick on start, FreeBSD 8 crashed. I am not in the office at the moment. I will check the e= rror messages tomorrow. Thaks. Tuesday, May 19, 2009, 4:52:40 PM, you wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > On Tue, May 19, 2009 at 04:16:06PM +0400, subbsd wrote: >> Hello >> On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: >> > Howdy .. >> > >> > Next run, >> > >> > We updated the port to 2.2.2r19801. >> > The Patch files/patch-amd64-r0-exec-alloc >> > was removed in favor of a similar fix >> > commited to upstream. Also was fixed a >> > bug on HEAD which should be fix the Kernel >> > crash. Please test test test .. :-) >> > >> > PS: Yes this run is for AMD64 and HEAD >> > users! >> > >> > >> > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz >> > >> > >> > Happy Testing! >> I've try to compile this port on i386/8-CURRENT ( kern.osreldate: 800087= ) and=20 >> job stops with last messages: > please update your src/kernel and rebuild vbox >> -- >> /* ... */ >> kBuild: xsltproc VBoxSVC -=20 >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Mai= n/idl/xpidl.xsl >> kBuild: Compiling RuntimeR3 -=20 >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Run= time/common/err/errmsg.cpp >> kBuild: Compiling RuntimeR3 -=20 >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Run= time/common/err/errmsgxpcom.cpp >> kBuild: Linking RuntimeR0 >> kBuild: Linking RuntimeGC >> kBuild: Linking RuntimeEFCPP >> kBuild: Linking RuntimeR3NoCRTGCC >> kBuild: Compiling RuntimeR0Drv -=20 >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Run= time/common/alloc/alloc.cpp >> kBuild: Linking VMMR3 >> kBuild: Compiling PcBiosBin -=20 >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.= x86/release/obj/PcBiosBin/_rombios_.c >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.= x86/release/obj/PcBiosBin/_rombios_.c:471.66:=20 >> error: need ';' >> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.= x86/release/obj/PcBiosBin/_rombios_.c:471.66:=20 >> error: need variable name >> kmk[2]: ***=20 >> [/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd= .x86/release/obj/PcBiosBin/rombios0.s]=20 >> Error 1 >> kmk[2]: *** Deleting file=20 >> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd= .x86/release/obj/PcBiosBin/rombios0.s' >> kmk[2]: *** Waiting for unfinished jobs.... >> kmk[2]: Leaving directory=20 >> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >> kmk[2]: Entering directory=20 >> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >> kmk[2]: *** Exiting with status 2 >> kmk[1]: *** [pass_libraries_this] Error 2 >> kmk[1]: Leaving directory=20 >> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >> kmk: *** [pass_libraries_order] Error 2 >> *** Error code 2 >> Stop in /usr/ports/emulators/virtualbox. >> -- >> DISABLE_MAKE_JOBS=3Dyes options is not influence >> In the _rombios__c at 471 i see strings: >> static char bios_cvs_version_string[] =3D "VirtualBox " "2.2.51_OSE"; >> but ';' symbol is presents.=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" --=20 Ismail YENIGUL Endersys Ltd. Genel Koordinat=F6r / General Coordinator Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 Fax :+90 216-4709508 | web: http://www.endersys.com.tr Endersys blog a=E7=FDld=FD. http://blog.endersys.com From owner-freebsd-current@FreeBSD.ORG Tue May 19 18:50:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039101065687; Tue, 19 May 2009 18:50:18 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id 41B018FC0C; Tue, 19 May 2009 18:50:16 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm12 with SMTP id 12so4062274fxm.43 for ; Tue, 19 May 2009 11:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.63.20 with SMTP id z20mr281659bkh.200.1242757417260; Tue, 19 May 2009 11:23:37 -0700 (PDT) In-Reply-To: <20090519091310.GB71804@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> Date: Tue, 19 May 2009 20:23:37 +0200 Message-ID: <367b2c980905191123p66e36eb5j243b1b1701f729a7@mail.gmail.com> From: Olivier SMEDTS To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:50:19 -0000 2009/5/19 Martin Wilke : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Howdy .. > > Next run, > > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) > > PS: Yes this run is for AMD64 and HEAD > =A0 =A0users! > > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > > Happy Testing! Tested, installed fine but I can only run guests without VT (so only 32-bit= s). I'm using latest -CURRENT on amd64 (Intel Core2 Quad Q9450). Seems to work fine (but slowly) for 32-bit guests without VT. Thanks ! > - -- > > +-----------------------+-------------------------------+ > | =A0PGP =A0 =A0: 0xB1E6FCE9 =A0| =A0Jabber : miwi(at)BSDCrew.de =A0| > | =A0ICQ =A0 =A0: 169139903 =A0 | =A0Mail =A0 : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | =A0 =A0 =A0 Mess with the Best, Die like the Rest! =A0 =A0 =A0 =A0 =A0| > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkoSeCYACgkQdLJIhLHm/OkuOQCfVzr7yTxydbo6npBgO2LyZNk1 > RpUAnAmxjlHTBsM8pJ5SIiPIqQRCWElu > =3DLoBM > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:00:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7D91065674; Tue, 19 May 2009 19:00:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id 538AF8FC16; Tue, 19 May 2009 19:00:30 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJW00DAIM5V2V00@asmtp013.mac.com>; Tue, 19 May 2009 11:36:04 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Randy Bush In-reply-to: Date: Tue, 19 May 2009 11:32:19 -0700 References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> X-Mailer: Apple Mail (2.935.3) Cc: current@freebsd.org, Andrew Thompson , Ulf Lilleengen Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:00:30 -0000 On May 19, 2009, at 10:33 AM, Randy Bush wrote: >> If you have done a chroot then you need to make sure devfs is also >> mounted within it >> >> mount -t devfs devfs /dist/dev > > thanks. > > Fixit# gpart create -s gpt /dev/ad4 > gpart: geom 'ad4': File exists > > Fixit# gpart create -s gpt ad4 > gpart: geom 'ad4': File exists > > sorry to be such a pita Try and read the feedback (i.e. error) you get and interpret it. Close your email program for a second and stop typing alrady. Use your brain! Ok, so you get an error and the error tells you that something exists already. It says "geom 'ad4'" and not "device 'ad4'", so let's not take "File exists" literally and wonder if it's /dev/ad4. A simple ls(1) should eliminate any doubts there. So, maybe there's already some partitioning on the disk? Hmmm, how to find that out. Tough one... Hang on, let's do: gpart show ad4 What does that say? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:28:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FB7F1065689; Tue, 19 May 2009 19:28:10 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B16648FC2E; Tue, 19 May 2009 19:28:09 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 49643615B; Tue, 19 May 2009 15:28:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1242761288; bh=aUQfRCkDVrYZgxY8FUY14A3yH8fdjWhIT6Cvwlfv35o=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LAgdEYibGWuBKlZp0133GzbSDh+MX6tv7cdk8I7Z7bFOyU13flXMHDBMmAWF9urBU 8fluvQGhs7C4bbZQ20/QpILTVS58NF+ctfaDmo2dDk/DHtddqC0fqSYPFdyleGC DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=iru4nUHyQB9NTi1zA6xBPF6kIrKcWSm6ubobWL0NWWWhLug5v5YO4qz2FIGr9HU93 tBIZZgUeoVpKJtG7/sP9dxLh4KIn0GXR6CJ6mjZN2vmi3vADcIdRawBWwPJrR7H Message-ID: <4A130842.5020407@protected-networks.net> Date: Tue, 19 May 2009 15:28:02 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Martin Wilke , freebsd-current References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> In-Reply-To: <20090517180920.GY71804@bsdcrew.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:28:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Wilke wrote: > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz With the latest tarball, I still don't see my DVD in the drop-down list even though I have tweaked the devd.conf file such that .. imb@toshi:/home/imb> ll /dev/*cd* crw-rw-rw- 1 root operator 0, 97 May 19 10:55 /dev/acd0 crw-rw-rw- 1 root operator 0, 104 May 19 10:55 /dev/cd0 lrwxr-xr-x 1 root wheel 3 May 19 10:55 /dev/cdrom -> cd0 This is on a Toshiba Satellite with today's -current .. imb@toshi:/home/imb> uname -a FreeBSD toshi.auburn.protected-networks.net 8.0-CURRENT FreeBSD 8.0-CURRENT #89: Tue May 19 07:29:32 EDT 2009 root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI i386 Is this expected? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoTCEIACgkQQv9rrgRC1JIsXACfQiATgNTSkjmrg1O/f5XMXXoc gc8AoMBQARVPh9UNxetXuGHaMXkd3oL4 =tdVE -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:35:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34490106564A for ; Tue, 19 May 2009 19:35:22 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id EA1428FC1A for ; Tue, 19 May 2009 19:35:21 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 800344AC5D; Tue, 19 May 2009 21:35:17 +0200 (CEST) Date: Tue, 19 May 2009 21:35:17 +0200 From: Martin Wilke To: Michael Butler Message-ID: <20090519193517.GA9909@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <4A130842.5020407@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <4A130842.5020407@protected-networks.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:35:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, May 19, 2009 at 03:28:02PM -0400, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Wilke wrote: > > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > With the latest tarball, I still don't see my DVD in the drop-down list > even though I have tweaked the devd.conf file such that .. > > imb@toshi:/home/imb> ll /dev/*cd* > crw-rw-rw- 1 root operator 0, 97 May 19 10:55 /dev/acd0 > crw-rw-rw- 1 root operator 0, 104 May 19 10:55 /dev/cd0 > lrwxr-xr-x 1 root wheel 3 May 19 10:55 /dev/cdrom -> cd0 > > This is on a Toshiba Satellite with today's -current .. > > imb@toshi:/home/imb> uname -a > FreeBSD toshi.auburn.protected-networks.net 8.0-CURRENT FreeBSD > 8.0-CURRENT #89: Tue May 19 07:29:32 EDT 2009 > root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI i386 at the moment a now issus we will take a look later. All in one seems that by most peoples now vbox works \o/ > > > Is this expected? > > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (FreeBSD) > > iEYEARECAAYFAkoTCEIACgkQQv9rrgRC1JIsXACfQiATgNTSkjmrg1O/f5XMXXoc > gc8AoMBQARVPh9UNxetXuGHaMXkd3oL4 > =tdVE > -----END PGP SIGNATURE----- > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoTCfMACgkQdLJIhLHm/OmI0gCcCVaMgOViql5m31dj0LVyQVXd 8sYAoIG2RQKqmwPiDSHTp4iGgJ/xUl35 =owma -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:43:26 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4361065676 for ; Tue, 19 May 2009 19:43:26 +0000 (UTC) (envelope-from mat.macy@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 7943F8FC17 for ; Tue, 19 May 2009 19:43:26 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so6508ywe.13 for ; Tue, 19 May 2009 12:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=lZw5cL7NeihD4ERxWt22v6zjRlqZAix9+RRj2FaD6Ik=; b=ZDX/M8/Bxj92+oBiIHmxABB31U2GRSjdTygYZhnxV2r0gREo/Fo6CuA2hZhIR0sF3v rc/TldisZ316fW3lPXoOmjBFzGbyekl3j32nUPXH2xUcIiFS1t2GqA6KfId1QCHvO7Dp 57TGh1w+QSnYiIK3qbrVCMmfei/fXZfWYi24E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YG1k569vqxm1sC/jBlVoG+XfwBAdtkh7G+kne6JBnjedUcuSgKkLvyEi6MDdhUOspA tgt4Xk57hZ/bYKXd8ydMKann8yTdZMPvaIHp2ngvcx5XTqTkvI2Bc11ISX7ueD6+YxxU isFVlz5piBu+Xd692oOUcD3SVHBdjGlySHWIA= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.3.13 with SMTP id 13mr809197anc.75.1242762180238; Tue, 19 May 2009 12:43:00 -0700 (PDT) In-Reply-To: <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@mail.gmail.com> <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com> Date: Tue, 19 May 2009 12:43:00 -0700 X-Google-Sender-Auth: a8992f9b49aa3c44 Message-ID: <3c1674c90905191243h4c188c93j71d68b060e54dbf5@mail.gmail.com> From: Kip Macy To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:43:27 -0000 > I thought I was referring to that too. =A0:-) =A0I guess I thought signal= ing the > pageout daemon to move vnodes from active to inactive was the way to do > that. =A0Are you saying there is another caching layer of vnodes going on= in > zfs? =A0I'll look around for that this evening. I apologize. Again you are correct. However, I don't see that helping. The VM doesn't associate arc cache pages with ZFS vnodes. So I don't see that helping in this case. We need some way of coupling the two. The challenge with the ARC is that it caches logical disk blocks, not file pages. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:43:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D6B1065673 for ; Tue, 19 May 2009 19:43:29 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 85C2A8FC19 for ; Tue, 19 May 2009 19:43:28 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by ewy3 with SMTP id 3so10980ewy.43 for ; Tue, 19 May 2009 12:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=lZw5cL7NeihD4ERxWt22v6zjRlqZAix9+RRj2FaD6Ik=; b=SBsXbIDn6edNCv3cl2E/vRlxrtgFKw6BdFgtBBV2LfljHNV7BSEmGTeFzONShhw/gD ZewbuKM2XyRJI6/77Uth7zGyB2QiBmLJQsy0yiu+6z9MTpciV5VbZf/C9seWxKnlCW1K FBZrB2GvyjPm8bVc3FcseOCyo8v3IMM3lUd0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UObmI5MuOkIus5TDIONl75GeKv1ZuBy8oqDOpfAGVMwQigcJyqsfOoCbpMsdJ7ShT9 JNJlJtBtFn1U4d//9Kq49hLmtp9xO54QCUqbJsZVLeE16hLOlzT2JtVTn7pZH9r+vWuM HLeWoBGNRslwiAWEg5ZhkruN3t/Ngd0D1/pSY= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.216.11.67 with SMTP id 45mr101620wew.53.1242762207593; Tue, 19 May 2009 12:43:27 -0700 (PDT) In-Reply-To: <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> <3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com> <68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com> <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@mail.gmail.com> <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com> Date: Tue, 19 May 2009 12:43:26 -0700 X-Google-Sender-Auth: d82d34a4e014a0ec Message-ID: <3c1674c90905191243v471cbeb4p633b9a21dbc7d87c@mail.gmail.com> From: Kip Macy To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:43:29 -0000 > I thought I was referring to that too. =A0:-) =A0I guess I thought signal= ing the > pageout daemon to move vnodes from active to inactive was the way to do > that. =A0Are you saying there is another caching layer of vnodes going on= in > zfs? =A0I'll look around for that this evening. I apologize. Again you are correct. However, I don't see that helping. The VM doesn't associate arc cache pages with ZFS vnodes. So I don't see that helping in this case. We need some way of coupling the two. The challenge with the ARC is that it caches logical disk blocks, not file pages. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:43:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 978A91065686; Tue, 19 May 2009 19:43:50 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 208648FC17; Tue, 19 May 2009 19:43:49 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n4JJhmvA021655; Tue, 19 May 2009 21:43:48 +0200 Received: from [192.168.100.199] ([88.11.103.20]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009051921434788:116971 ; Tue, 19 May 2009 21:43:47 +0200 Message-ID: <4A130BE1.7060204@entel.upc.edu> Date: Tue, 19 May 2009 21:43:29 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin Wilke References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <4A130842.5020407@protected-networks.net> <20090519193517.GA9909@bsdcrew.de> In-Reply-To: <20090519193517.GA9909@bsdcrew.de> X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 19/05/2009 21:43:48, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 19/05/2009 21:43:48, Serialize complete at 19/05/2009 21:43:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 19 May 2009 21:43:48 +0200 (CEST) Cc: freebsd-current Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:43:50 -0000 Martin Wilke wrote: > On Tue, May 19, 2009 at 03:28:02PM -0400, Michael Butler wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > Martin Wilke wrote: > >> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > With the latest tarball, I still don't see my DVD in the drop-down list > > even though I have tweaked the devd.conf file such that .. > > > imb@toshi:/home/imb> ll /dev/*cd* > > crw-rw-rw- 1 root operator 0, 97 May 19 10:55 /dev/acd0 > > crw-rw-rw- 1 root operator 0, 104 May 19 10:55 /dev/cd0 > > lrwxr-xr-x 1 root wheel 3 May 19 10:55 /dev/cdrom -> cd0 > > > This is on a Toshiba Satellite with today's -current .. > > > imb@toshi:/home/imb> uname -a > > FreeBSD toshi.auburn.protected-networks.net 8.0-CURRENT FreeBSD > > 8.0-CURRENT #89: Tue May 19 07:29:32 EDT 2009 > > root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI > i386 > > at the moment a now issus we will take a look later. > > All in one seems that by most peoples now vbox works \o/ > Hi, as I reported this morning, for me is not working. My system is a DELL D630 laptop with 3Gb of RAM. i386/CURRENT update today : FreeBSD gusiport 8.0-CURRENT FreeBSD 8.0-CURRENT #41: Tue May 19 14:24:05 CEST 2009 gus@gusiport:/usr/obj/usr/src/sys/CUSTOM i386 Last version fixed the problem with the kernel module not being detected the second time vbox is run, but I still have vbox booting the virtual machine in wit a gray screen. I've observed the machine is supposed to be running, but making top shows no activity. Also tried VBoxSDL -startvm win (win is the id given to the vmachine, yes I know, it took me little time to give it a name :) ) and the virtual machine shows a black screen. No CPU activity at all. Tried disabling VT-x/AMD-v extensions (the laptop supports VT-x) still no go. Anything I can try ? Thanks, Gus -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:45:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AF81065701 for ; Tue, 19 May 2009 19:45:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 011C88FC1C for ; Tue, 19 May 2009 19:45:34 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243255296; Tue, 19 May 2009 22:45:33 +0300 Message-ID: <4A130C5C.6090104@FreeBSD.org> Date: Tue, 19 May 2009 22:45:32 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> In-Reply-To: <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:45:35 -0000 Magnus Kling wrote: > 2009/5/19 Alexander Motin > > > Magnus Kling wrote: > > I applied the patch and rebuilt the kernel. But when should this be > > printed? At shutdown or boot? I can´t see it at all. > > On shutdown before panic. > > > When panic occurs I got the attached text as output on my serial > console. Hmm. I don't see our debug messages there. Or it didn't shot due to some stupid reason or problem is in different line. Could you try addr2line utility to identify source line of 0xc0567110 address? Also try to change our if (ctlr == NULL) { with if (request->u.ata.command == ATA_FLUSHCACHE || request->u.ata.command == ATA_FLUSHCACHE48) { May be you could give me access to your server and it's serial console? I would make debugging faster. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue May 19 19:48:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E521910656C7 for ; Tue, 19 May 2009 19:48:39 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 625FF8FC12 for ; Tue, 19 May 2009 19:48:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243255368; Tue, 19 May 2009 22:48:38 +0300 Message-ID: <4A130D10.5090002@FreeBSD.org> Date: Tue, 19 May 2009 22:48:32 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> <43b1bb350905190622t5e52b6e1kbb85af95e98debeb@mail.gmail.com> In-Reply-To: <43b1bb350905190622t5e52b6e1kbb85af95e98debeb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:48:40 -0000 Magnus Kling wrote: > Tried with a spare disk. Added it as a JBOD on one channel and mounted > it in the OS. > Guess what... Reboot works! > At reboot the disks are synced and then the computer is rebooted. Interesting, but does not helps much. Just shows that problem is somewhere else, but not in shutdown sequence of drive itself. How is about two separate drives on the same channels as with RAID? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue May 19 20:01:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF98106566B for ; Tue, 19 May 2009 20:01:12 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFE48FC1E for ; Tue, 19 May 2009 20:01:11 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by fxm12 with SMTP id 12so18645fxm.43 for ; Tue, 19 May 2009 13:01:10 -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 :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=5mmMguUq5mpnAp6QoyePxzeUQRzOngHAwIbBsK20TCE=; b=LlHpo9VB48/srKMiZPBQiYtsxxV2xvBAp+Bnt1WKJaYmr958H3tULDD0loCzB4U1qh V9b1Ag0Q3lmufjDF/aMsV3vjGKm9+cX9/X44yOcfLfiKEUp161553ZS733RmGWf5EJJE AaUBkR6ZDGP1e5L4A0jYUmacI9SMphMFu6nqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=ZmnY4yhuJgbNO0LinmtPhY3xQ9WIRzryEvJrb+rt977spu7ZBnkwo8wNSWSF32B8zB Sz6sbW/zM6z2ti0ZQiD3nV64lKlq0n65quQ+/LVCf5qcMDjPsONt2JvKp36BhTugsein W5sRG7MKgyIVZQ+Dnnzz5LuxS+jW6ab031LhA= Received: by 10.103.241.15 with SMTP id t15mr235289mur.85.1242763270691; Tue, 19 May 2009 13:01:10 -0700 (PDT) Received: from beastie.lan ([195.60.175.243]) by mx.google.com with ESMTPS id s10sm1031698muh.27.2009.05.19.13.01.09 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 13:01:10 -0700 (PDT) Message-ID: <4A130FB7.7070205@gmail.com> Date: Tue, 19 May 2009 22:59:51 +0300 From: Andrey User-Agent: Thunderbird 2.0.0.21 (X11/20090418) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [Fwd: Re: [snd_hda][AD1981HD] microphone doesn't work] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:01:12 -0000 Alexander Motin wrote: > This patch was merged to 7-stable 4 months ago, together with the rest > of driver changes. 7.2-PRERELEASE had snd_hda driver almost (or may be > even completely) identical to the CURRENT of that time. So I don't > understand the difference. To find any difference in driver operation, > try to compare verbose dmesg of the driver in working and not working > systems. > > By the way, are you sure that problem is in driver itself? Can't be > linuxulator, Skype, settings or whatever else problem? What are you > using to record sound? Have you tried to use something trivial like > rawrec and rawplay? > > What microphone are you using: external or internal? Have you tried > another one? Are you recording silence or some noise? What mixer > settings do you use? Oh, sorry, I didn't mention type of microphone :(. It goes about internal one I guess (or in terms of snd_hda 'Connection type=Fixed'). External ('Connection type=Jack') works fine. Attepts to record using rawrec\rawplay, skype test call, audacity etc. produce only monotonous hissing. Not sure if I understood you correctly regarding mixer settings. Well, all channels are set to 100, i.e. smth. like: mixer | egrep -i 'mixer' | awk ' { print $2; } ' | xargs -I % mixer % 100 Unfortunately, I have no 7.2 alongside. Will try to obtain verbose output from it and compare against current. > PS: Next time, please, put file somewhere. Inlining broke lines, making > difficult to read it. Sure, will take into account. Thanks a lot for reply! --- WBR, Andrey Kosachenko From owner-freebsd-current@FreeBSD.ORG Tue May 19 20:49:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E13C1065672 for ; Tue, 19 May 2009 20:49:48 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 47BFF8FC13 for ; Tue, 19 May 2009 20:49:48 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 72C655C34; Tue, 19 May 2009 16:49:47 -0400 (EDT) Date: Tue, 19 May 2009 16:49:47 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090519204947.GA39529@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <20090518161148.GA56646@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:49:48 -0000 On Mon, May 18, 2009 at 06:18:38PM +0200, Thomas Backman wrote: > > On May 18, 2009, at 06:11 PM, Wesley Shields wrote: > > > On Wed, May 13, 2009 at 03:19:05PM +0200, Thomas Backman wrote: > >> OK, so I first posted a thread on the forums about this in 7.2- > >> RELEASE: > >> http://forums.freebsd.org/showthread.php?t=3834 > >> Then filed a PR, kern/134408: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 > >> > >> The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) > >> GMT+2. > >> > >> Steps to reproduce: > >> 1) Build DTrace capable kernel (I followed the wiki DTrace > >> instructions) > >> 2) Reboot; kldload dtraceall > >> 3) dtrace -n 'syscall::open:entry { self->path = arg0; } > >> syscall::open:return { printf("%s\n", copyinstr(self->path)); }' > >> 4) Crash. I just noticed this but shouldn't you be using copyinstr() on the first probe. It should look something like this: syscall::open:entry { self->path = copyinstr(arg0); } syscall::open:return / self->path / { printf("%s\n", self->path); } This still doesn't solve the problem of copyinstr() causing a crash though. > >> Backtrace: > >> [...] > > > > It's not the probe that is the problem. I suspect it's the copyinstr. > > > >> Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB > >> RAM; > >> and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and > >> 8.0. > > > > I can easily reproduce this also. > > > > -- WXS > > Yup, it's copyinstr() crashing. It works if you simply replace > printf(...) with printf("file opened\n") which doesn't copy anything > in, and the backtrace seems (even to me ;) to point towards it. Did this ever work? If so, can you do a binary search to help narrow down when it broke? -- WXS From owner-freebsd-current@FreeBSD.ORG Tue May 19 21:18:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0E9106564A for ; Tue, 19 May 2009 21:18:45 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 760068FC13 for ; Tue, 19 May 2009 21:18:45 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 097035C38; Tue, 19 May 2009 17:18:45 -0400 (EDT) Date: Tue, 19 May 2009 17:18:44 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090519211844.GB39529@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <20090518161148.GA56646@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:18:45 -0000 On Mon, May 18, 2009 at 06:18:38PM +0200, Thomas Backman wrote: > > On May 18, 2009, at 06:11 PM, Wesley Shields wrote: > > > On Wed, May 13, 2009 at 03:19:05PM +0200, Thomas Backman wrote: > >> OK, so I first posted a thread on the forums about this in 7.2- > >> RELEASE: > >> http://forums.freebsd.org/showthread.php?t=3834 > >> Then filed a PR, kern/134408: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 > >> > >> The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) > >> GMT+2. > >> > >> Steps to reproduce: > >> 1) Build DTrace capable kernel (I followed the wiki DTrace > >> instructions) > >> 2) Reboot; kldload dtraceall > >> 3) dtrace -n 'syscall::open:entry { self->path = arg0; } > >> syscall::open:return { printf("%s\n", copyinstr(self->path)); }' > >> 4) Crash. > >> > >> Backtrace: > >> [...] > > > > It's not the probe that is the problem. I suspect it's the copyinstr. > > > >> Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB > >> RAM; > >> and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and > >> 8.0. > > > > I can easily reproduce this also. > > > > -- WXS > > Yup, it's copyinstr() crashing. It works if you simply replace > printf(...) with printf("file opened\n") which doesn't copy anything > in, and the backtrace seems (even to me ;) to point towards it. It's also worth noting that copyin() also causes the same panic. The ASSERT() in dtrace_copycheck() is catching it. The "Solaris Dynamic Tracing Guide" mentions that the specified address must correspond to a faulted-in page in the current process. I'm not sure how I could go about finding that out. -- WXS From owner-freebsd-current@FreeBSD.ORG Tue May 19 21:35:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039651065674; Tue, 19 May 2009 21:35:48 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D25DB8FC19; Tue, 19 May 2009 21:35:47 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6WyO-0002dI-O8; Tue, 19 May 2009 21:35:44 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 8D55217F0526; Tue, 19 May 2009 14:35:44 -0700 (PDT) Date: Tue, 19 May 2009 14:35:44 -0700 Message-ID: From: Randy Bush To: Marcel Moolenaar In-Reply-To: References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org, Andrew Thompson , Ulf Lilleengen Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:35:48 -0000 >>> mount -t devfs devfs /dist/dev >> >> thanks. >> >> Fixit# gpart create -s gpt /dev/ad4 >> gpart: geom 'ad4': File exists >> >> Fixit# gpart create -s gpt ad4 >> gpart: geom 'ad4': File exists >> >> sorry to be such a pita > > Try and read the feedback (i.e. error) you get and > interpret it. Close your email program for a second > and stop typing alrady. Use your brain! there are some issue with that, mainly two, jet lag and in the background trying to build a linux dom0 with zero linux experience. neither improves the mind. and i was googling. but the "file" threw me off. thanks for the clue. i dded the disks and moved forward again. randy From owner-freebsd-current@FreeBSD.ORG Tue May 19 21:48:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 630B910656CB; Tue, 19 May 2009 21:48:24 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id D0A578FC1D; Tue, 19 May 2009 21:48:23 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail53.abv.bg (mail53.ni.bg [192.168.151.29]) by smtp-out.abv.bg (Postfix) with ESMTP id 8850087D2B; Wed, 20 May 2009 00:48:32 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=r23O7NjBagmweFQhOZVZIsME8cQpcUzdnLwaZuumxSslTP+5gRNiHzHuhNl1B3GwS GiiTClDXz+n7gO6dXqBLDCoYr0NCqxz8Kl7/RIN39nKch8jFm++fd5Ofn2S8Kkxvog6 gwJolfTztrj76sqAp7yCjzB7p1FTfhWu7KHxoRs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1242769712; bh=IBS1n4KDKxRvLWooYBbAmZB22o22GtcFumxRKfB0IHA=; h=Date:From:To:Cc:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=LBKpD7HZlr7J2GhL6kd+sZS9Chk23D3NAIKa86oEwheWeIVduvGT8rUGppgZm36U+ 0LTZj2tMCkCB6ipan1yj5qrDS8GUoOqj/XaVm8f+lLg4Y2+MNOYwziETZOY0NBxE3/ uJZTGoZ+QVfscP1QBZY59c82pDAmdJQY1CDFOfn8= Received: from mail53.abv.bg (localhost.localdomain [127.0.0.1]) by mail53.abv.bg (Postfix) with ESMTP id 9B9F31E4B0A; Wed, 20 May 2009 00:48:20 +0300 (EEST) Date: Wed, 20 May 2009 00:48:20 +0300 (EEST) From: Mario Pavlov To: Hans Petter Selasky Message-ID: <438704678.26539.1242769700629.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Re: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:48:25 -0000 Hi, I tired CURRENT and it's working for me :) I only have one small issue... when I unplug the reader pcscd goes to some sort of infinite loop it would print this forever: 48111939 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2): Device busy 00000020 ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00 00402930 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 00000021 ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00 00402953 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 00000016 ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00 ... ... ... firefox does almost the same thing: [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found ... ... ... I guess this is not FreeBSD's fault, is it ? thanks regards, mgp >On Monday 18 May 2009, Mario Pavlov wrote: >> Hi, >> no I haven't tried it on CURRENT >> should I do that ? >> is there something new in the USB stuff there ? > >There is a new USB stack in 8-current and a new libusb which is installed as a >part of the base system. > >--HPS > From owner-freebsd-current@FreeBSD.ORG Tue May 19 22:27:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0001065672 for ; Tue, 19 May 2009 22:27:55 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 331A58FC1B for ; Tue, 19 May 2009 22:27:54 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4JJ9Xx6009731 for ; Wed, 20 May 2009 05:09:33 +1000 Received: from camelot.theinternet.com.au (d122-105-150-189.bla11.nsw.optusnet.com.au [122.105.150.189]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4JJ9PAX011929; Wed, 20 May 2009 05:09:31 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id E8BB317022; Wed, 20 May 2009 05:06:48 +1000 (EST) Date: Wed, 20 May 2009 05:06:48 +1000 From: Andrew Milton To: Marcel Moolenaar Message-ID: <20090519190648.GD1050@camelot.theinternet.com.au> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> 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: current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 22:27:55 -0000 +-------[ Marcel Moolenaar ]---------------------- | | On May 19, 2009, at 10:33 AM, Randy Bush wrote: | | >>If you have done a chroot then you need to make sure devfs is also | >>mounted within it | >> | >>mount -t devfs devfs /dist/dev | > | > thanks. | > | >Fixit# gpart create -s gpt /dev/ad4 | >gpart: geom 'ad4': File exists | > | >Fixit# gpart create -s gpt ad4 | >gpart: geom 'ad4': File exists | > | >sorry to be such a pita | | Try and read the feedback (i.e. error) you get and | interpret it. Close your email program for a second | and stop typing alrady. Use your brain! | | Ok, so you get an error and the error tells you that | something exists already. It says "geom 'ad4'" and | not "device 'ad4'", so let's not take "File exists" | literally and wonder if it's /dev/ad4. A simple ls(1) | should eliminate any doubts there. | | So, maybe there's already some partitioning on the | disk? Hmmm, how to find that out. Tough one... | | Hang on, let's do: | gpart show ad4 | | What does that say? Instead of having to send multiple snide emails like this about it, why not just make the error message more descriptive and less BSOD-like? Surely fixing the error messages would take less time than dealing with the emails... -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Wed May 20 00:30:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE79106566B; Wed, 20 May 2009 00:30:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 42C218FC13; Wed, 20 May 2009 00:30:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so88885qwe.7 for ; Tue, 19 May 2009 17:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=memFkR/8MskyjvizZkQAApRcrLz5sBFuqefHAlgxnrI=; b=QwwMidKHLu9hfI1Sint+/sO1T2tQXwUyPZJ4ywoe8ClckiNQpalE0NIc9QURq0H960 rcvwllYQbaWORLiMbknvmv8MxtWWBkjVThzGiRvu8B166M7uXhueheRtkxP8ECjKzvb9 TIA8k3Q1iyrqESw356pMLkEoEFCV/beG15COE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eTsI1kBUNTUGNL+JHCThW6s7Yb9fgVJGkzhnDRn3QvPNhmuzTjGuIbtAxW73qLNrig xLt9tDtvV5BXQWNNevCqQP8QRphdY8Lv/TUwOYmMcylmf+4dEA6BNgSBM+D+eNGf4NRN y2nGG78c2hkWJcEbGRbCRYWMRQuUpAds1OFQQ= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.96.73 with SMTP id g9mr242960qcn.45.1242779409662; Tue, 19 May 2009 17:30:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2009 08:30:09 +0800 X-Google-Sender-Auth: 3bd29d3f5446f850 Message-ID: From: Adrian Chadd To: Saifi Khan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 00:30:11 -0000 2009/5/20 Saifi Khan : > Could you please share 'your insight' on the > 'set of virtualization problems' that Xen solves ? Xen lets you run multiple versions of modified OSes on the same box. Each OS for the most part can treat its small pool of resources as its own. It hides the underlying hardware from the virtual domain (although its apparently quite popular to break out bits of hardware to appear in the virtual domain.) The Xen paravirtualisation stuff in -theory- should be more lightweight than full hardware virtualisation and it should perform better. In practice? That's very much workload dependant. Xen also lets you write "other" OSes without needing to care about the hardware. One of my friends bootstrapped a toy OS of his inside Xen. He can then run it on any and all Xen boxes, unmodified, regardless of the underlying hardware. That really hasn't been exploited to its full potential though. Adrian From owner-freebsd-current@FreeBSD.ORG Wed May 20 01:04:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210631065675 for ; Wed, 20 May 2009 01:04:50 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id EC65A8FC18 for ; Wed, 20 May 2009 01:04:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6aEi-0003OK-DB; Wed, 20 May 2009 01:04:48 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 2720217FDACF; Tue, 19 May 2009 18:04:48 -0700 (PDT) Date: Tue, 19 May 2009 18:04:47 -0700 Message-ID: From: Randy Bush To: Andrew Milton In-Reply-To: <20090519190648.GD1050@camelot.theinternet.com.au> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> <20090519190648.GD1050@camelot.theinternet.com.au> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 01:04:50 -0000 as punishment, here is yet another email so i have it all partitioned using fixit/dist. ad4p1 64k freebsd-boot ad4p2 64g freebsd-zfs (to use as zfs mirror) ad4p3 64g freebsd-swap ad4p4 2tb freebsd-zfs (to use as raidz2) same for ad5. ad6 and ad7 have only p1 to join the raidz2. but i can not build the boot zfs mirror because i can not follow the destructions at http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ http://wiki.freebsd.org/AppleMacbook etc because fixit/dist is a world where i can not mount the zfs pool because / is read-only md0. so i can not set up the bootable zfs mirror system. and, to add to the fun. due to time pressure, i go to back off to my old faithful hack of small gmirrored boot partitions with big zfs. i dd whomp the base drives (dd if=/dev/zero of=/dev/da4 count=1000000). but it seems not to stomp them. the sysinstall fdisk partiton editor keeps seeing ad4p[1-4]! coffee or sleep, tough call. randy From owner-freebsd-current@FreeBSD.ORG Wed May 20 02:25:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A08106564A for ; Wed, 20 May 2009 02:25:24 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id E735F8FC12 for ; Wed, 20 May 2009 02:25:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n4K2PDna093045; Tue, 19 May 2009 19:25:13 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 7w5k8isskcqqpjmr8kq5mzk94w; Tue, 19 May 2009 19:25:12 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A136A08.9050908@freebsd.org> Date: Tue, 19 May 2009 19:25:12 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Paul Wootton , freebsd-current@freebsd.org References: <4A1123C5.3070507@fletchermoorland.co.uk> <4A122C23.40603@freebsd.org> <200905190637.03323.max@love2party.net> <4A128822.9030709@fletchermoorland.co.uk> <20090519103559.GA15608@ei.bzerk.org> In-Reply-To: <20090519103559.GA15608@ei.bzerk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 02:25:24 -0000 On Tue, May 19, 2009 at 11:21:22AM +0100, Paul Wootton typed: > > Or does making a sparse file in to a none sparse file just consume more > disk space and no other side affects No other side effects. Tim From owner-freebsd-current@FreeBSD.ORG Wed May 20 02:50:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83E6C1065673 for ; Wed, 20 May 2009 02:50:15 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id EF5D48FC14 for ; Wed, 20 May 2009 02:50:13 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4K2o8s3053832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 04:50:12 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A136FD6.9040208@omnilan.de> Date: Wed, 20 May 2009 04:49:58 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Martin Wilke References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> In-Reply-To: <20090519091310.GB71804@bsdcrew.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0203CC2C130DBCE6634D2A7F" Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 02:50:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0203CC2C130DBCE6634D2A7F Content-Type: multipart/mixed; boundary="------------000605090201040202090305" This is a multi-part message in MIME format. --------------000605090201040202090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Martin Wilke schrieb am 19.05.2009 11:13 (localtime): > Howdy .. >=20 > Next run, >=20 > We updated the port to 2.2.2r19801. > The Patch files/patch-amd64-r0-exec-alloc > was removed in favor of a similar fix > commited to upstream. Also was fixed a > bug on HEAD which should be fix the Kernel > crash. Please test test test .. :-) >=20 > PS: Yes this run is for AMD64 and HEAD > users! >=20 >=20 > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz >=20 >=20 > Happy Testing! Howdy too :) And KUDOS to the VirtualBox porters and developers! I'm=20 impressed and I've been missing this way of realizing a=20 fashion-bits-laucher ;) (qemu is also very nice, but magnitudes slower) One problem I recognized so far: If I "enable additional controller", regardless which type (but I'd like = to have AHCI), the vbox doesn't start at all. Please find attached the=20 log file. Of course I'd highly appreciate USB support :)) Best regards, -Harry --------------000605090201040202090305 Content-Type: text/plain; name="VBox.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="VBox.log" 00:00:00.352 VirtualBox 2.2.51_OSE r19761 freebsd.x86 (May 20 2009 03:40:= 48) release log 00:00:00.352 Log opened 2009-05-20T02:47:52.169566000Z 00:00:00.352 OS Product: FreeBSD 00:00:00.352 OS Release: 8.0-CURRENT 00:00:00.352 OS Version: FreeBSD 8.0-CURRENT #3: Mon May 18 14:25:16 CEST= 2009 harry@titan.flintsbach.schmalzbauer.de:/usr/obj/usr/src/sys/TIT= AN 00:00:00.352 Executable: /usr/local/lib/virtualbox/VirtualBox 00:00:00.352 Process ID: 3762 00:00:00.352 Package type: BSD_32BITS_GENERIC (OSE) 00:00:00.356 SUP: Loaded VMMR0.r0 (/usr/local/lib/virtualbox/VMMR0.r0) at= 0xc712c060 - ModuleInit at 00000000c713e8c0 and ModuleTerm at 00000000c7= 13e880 00:00:00.356 SUP: VMMR0EntryEx located at 00000000c713e750, VMMR0EntryFas= t at 00000000c713e940 and VMMR0EntryInt at 00000000c713d9d0 00:00:00.400 SUPR3HardenedLdrLoadAppPriv: "/usr/local/lib/virtualbox/VBox= SharedClipboard.so" not found 00:00:00.400 HGCM: Failed to load the service library: [VBoxSharedClipboa= rd], rc =3D VERR_FILE_NOT_FOUND. The service will be not available. 00:00:00.400 VBoxSharedClipboard is not available. rc =3D VERR_FILE_NOT_F= OUND 00:00:00.449 ************************* CFGM dump ************************= * 00:00:00.449 pRoot=3D36557ed0:{/} 00:00:00.449 [/] (level 0) 00:00:00.449 Name =3D "XPsp3proMSDN" (cch=3D13)= 00:00:00.449 UUID =3D "fb 38 e3 73 e3 cd b1 4b = 91 fc f5 0a 5a 0d 72 db" (cb=3D16) 00:00:00.449 RamSize =3D 0x0000000018400000 (40684= 7488) 00:00:00.449 RamHoleSize =3D 0x0000000020000000 (53687= 0912) 00:00:00.449 NumCPUs =3D 0x0000000000000001 (1) 00:00:00.449 TimerMillies =3D 0x000000000000000a (10) 00:00:00.449 RawR3Enabled =3D 0x0000000000000001 (1) 00:00:00.449 RawR0Enabled =3D 0x0000000000000001 (1) 00:00:00.449 PATMEnabled =3D 0x0000000000000001 (1) 00:00:00.449 CSAMEnabled =3D 0x0000000000000001 (1) 00:00:00.449 HwVirtExtForced =3D 0x0000000000000000 (0) 00:00:00.449 EnableNestedPaging =3D 0x0000000000000000 (0) 00:00:00.449 EnableVPID =3D 0x0000000000000000 (0) 00:00:00.449 EnablePAE =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/HWVirtExt/] (level 1) 00:00:00.449 Enabled =3D 0x0000000000000001 (1) 00:00:00.449 64bitEnabled =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/PDM/] (level 1) 00:00:00.449=20 00:00:00.449 [/PDM/Drivers/] (level 2) 00:00:00.449=20 00:00:00.449 [/PDM/Drivers/VBoxC/] (level 3) 00:00:00.449 Path =3D "/usr/local/lib/virtualbox/components/V= BoxC" (cch=3D43) 00:00:00.449=20 00:00:00.449 [/Devices/] (level 1) 00:00:00.449=20 00:00:00.449 [/Devices/pcarch/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/pcarch/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/pcarch/0/Config/] (level 4) 00:00:00.449=20 00:00:00.449 [/Devices/pcbios/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/pcbios/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/pcbios/0/Config/] (level 4) 00:00:00.449 RamSize =3D 0x0000000018400000 (4= 06847488) 00:00:00.449 RamHoleSize =3D 0x0000000020000000 (5= 36870912) 00:00:00.449 NumCPUs =3D 0x0000000000000001 (1= ) 00:00:00.449 HardDiskDevice =3D "piix3ide" (cch=3D9) 00:00:00.449 FloppyDevice =3D "i82078" (cch=3D7) 00:00:00.449 IOAPIC =3D 0x0000000000000000 (0= ) 00:00:00.449 PXEDebug =3D 0x0000000000000000 (0= ) 00:00:00.449 UUID =3D "fb 38 e3 73 e3 cd b1= 4b 91 fc f5 0a 5a 0d 72 db" (cb=3D16) 00:00:00.449 BootDevice0 =3D "DVD" (cch=3D4) 00:00:00.449 BootDevice1 =3D "IDE" (cch=3D4) 00:00:00.449 BootDevice2 =3D "NONE" (cch=3D5) 00:00:00.449 BootDevice3 =3D "NONE" (cch=3D5) 00:00:00.449 SataHardDiskDevice =3D "ahci" (cch=3D5) 00:00:00.449 SataPrimaryMasterLUN =3D 0x0000000000000000 (0= ) 00:00:00.449 SataPrimarySlaveLUN =3D 0x0000000000000001 (1= ) 00:00:00.449 SataSecondaryMasterLUN =3D 0x0000000000000002 (2= ) 00:00:00.449 SataSecondarySlaveLUN =3D 0x0000000000000003 (3= ) 00:00:00.449=20 00:00:00.449 [/Devices/8237A/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/8237A/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/pci/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/pci/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/pci/0/Config/] (level 4) 00:00:00.449 IOAPIC =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/Config/] (level 4) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#0/] (level 4) 00:00:00.449 Driver =3D "KeyboardQueue" (cch=3D14) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#0/Config/] (level 5) 00:00:00.449 QueueSize =3D 0x0000000000000040 (64) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#0/AttachedDriver/] (level 5) 00:00:00.449 Driver =3D "MainKeyboard" (cch=3D13) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#0/AttachedDriver/Config/] (level 6) 00:00:00.449 Object =3D 0x0000000035f36100 (905142528) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#1/] (level 4) 00:00:00.449 Driver =3D "MouseQueue" (cch=3D11) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#1/Config/] (level 5) 00:00:00.449 QueueSize =3D 0x0000000000000080 (128) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#1/AttachedDriver/] (level 5) 00:00:00.449 Driver =3D "MainMouse" (cch=3D10) 00:00:00.449=20 00:00:00.449 [/Devices/pckbd/0/LUN#1/AttachedDriver/Config/] (level 6) 00:00:00.449 Object =3D 0x0000000035f36080 (905142400) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/Config/] (level 4) 00:00:00.449 IRQ =3D 0x0000000000000006 (6) 00:00:00.449 DMA =3D 0x0000000000000002 (2) 00:00:00.449 MemMapped =3D 0x0000000000000000 (0) 00:00:00.449 IOBase =3D 0x00000000000003f0 (1008) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/LUN#999/] (level 4) 00:00:00.449 Driver =3D "MainStatus" (cch=3D11) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/LUN#999/Config/] (level 5) 00:00:00.449 papLeds =3D 0x0000000035f279e4 (905083364) 00:00:00.449 First =3D 0x0000000000000000 (0) 00:00:00.449 Last =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/LUN#0/] (level 4) 00:00:00.449 Driver =3D "Block" (cch=3D6) 00:00:00.449=20 00:00:00.449 [/Devices/i82078/0/LUN#0/Config/] (level 5) 00:00:00.449 Type =3D "Floppy 1.44" (cch=3D12) 00:00:00.449 Mountable =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/acpi/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/acpi/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449 PCIDeviceNo =3D 0x0000000000000007 (7) 00:00:00.449 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/Devices/acpi/0/Config/] (level 4) 00:00:00.449 RamSize =3D 0x0000000018400000 (406847488) 00:00:00.449 RamHoleSize =3D 0x0000000020000000 (536870912) 00:00:00.449 NumCPUs =3D 0x0000000000000001 (1) 00:00:00.449 IOAPIC =3D 0x0000000000000000 (0) 00:00:00.449 FdcEnabled =3D 0x0000000000000001 (1) 00:00:00.449 ShowRtc =3D 0x0000000000000000 (0) 00:00:00.449 ShowCpu =3D 0x0000000000000000 (0) 00:00:00.449=20 00:00:00.449 [/Devices/acpi/0/LUN#0/] (level 4) 00:00:00.449 Driver =3D "ACPIHost" (cch=3D9) 00:00:00.449=20 00:00:00.449 [/Devices/acpi/0/LUN#0/Config/] (level 5) 00:00:00.449=20 00:00:00.449 [/Devices/i8254/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/i8254/0/] (level 3) 00:00:00.449=20 00:00:00.449 [/Devices/i8254/0/Config/] (level 4) 00:00:00.449=20 00:00:00.449 [/Devices/i8259/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/i8259/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/i8259/0/Config/] (level 4) 00:00:00.449=20 00:00:00.449 [/Devices/apic/] (level 2) 00:00:00.449=20 00:00:00.449 [/Devices/apic/0/] (level 3) 00:00:00.449 Trusted =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/apic/0/Config/] (level 4) 00:00:00.449 IOAPIC =3D 0x0000000000000000 (0) 00:00:00.449 NumCPUs =3D 0x0000000000000001 (1) 00:00:00.449=20 00:00:00.449 [/Devices/mc146818/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/mc146818/0/] (level 3) 00:00:00.450=20 00:00:00.450 [/Devices/mc146818/0/Config/] (level 4) 00:00:00.450=20 00:00:00.450 [/Devices/vga/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/vga/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x0000000000000002 (2) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/vga/0/Config/] (level 4) 00:00:00.450 VRamSize =3D 0x0000000000c00000 (1258291= 2) 00:00:00.450 FadeIn =3D 0x0000000000000001 (1) 00:00:00.450 FadeOut =3D 0x0000000000000001 (1) 00:00:00.450 LogoTime =3D 0x0000000000000000 (0) 00:00:00.450 LogoFile =3D "" (cch=3D1) 00:00:00.450 ShowBootMenu =3D 0x0000000000000002 (2) 00:00:00.450 CustomVideoModes =3D 0x0000000000000000 (0) 00:00:00.450 HeightReduction =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/vga/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "MainDisplay" (cch=3D12) 00:00:00.450=20 00:00:00.450 [/Devices/vga/0/LUN#0/Config/] (level 5) 00:00:00.450 Object =3D 0x0000000035f4b400 (905229312) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x0000000000000001 (1) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000001 (1) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/Config/] (level 4) 00:00:00.450 Type =3D "ICH6" (cch=3D5) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#999/] (level 4) 00:00:00.450 Driver =3D "MainStatus" (cch=3D11) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#999/Config/] (level 5) 00:00:00.450 papLeds =3D 0x0000000035f279ec (905083372) 00:00:00.450 First =3D 0x0000000000000000 (0) 00:00:00.450 Last =3D 0x0000000000000003 (3) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#2/] (level 4) 00:00:00.450 Driver =3D "Block" (cch=3D6) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#2/Config/] (level 5) 00:00:00.450 Type =3D "DVD" (cch=3D4) 00:00:00.450 Mountable =3D 0x0000000000000001 (1) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#2/AttachedDriver/] (level 5) 00:00:00.450 Driver =3D "MediaISO" (cch=3D9) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#2/AttachedDriver/Config/] (level 6)= 00:00:00.450 Path =3D "/GUNE/OS-Archiv/Microsoft MSDN Deutsch= /XP professional SP3/de_windows_xp_professional_with_service_pack_3_x86_c= d_vl_x14-73985.iso" (cch=3D130) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "Block" (cch=3D6) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#0/Config/] (level 5) 00:00:00.450 Type =3D "HardDisk" (cch=3D9) 00:00:00.450 Mountable =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#0/AttachedDriver/] (level 5) 00:00:00.450 Driver =3D "VD" (cch=3D3) 00:00:00.450=20 00:00:00.450 [/Devices/piix3ide/0/LUN#0/AttachedDriver/Config/] (level 6)= 00:00:00.450 Path =3D "/space/vbox/XPsp3proMSDN.vdi" (cch=3D= 29) 00:00:00.450 Format =3D "VDI" (cch=3D4) 00:00:00.450=20 00:00:00.450 [/Devices/ahci/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/ahci/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x000000000000000d (13) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/ahci/0/Config/] (level 4) 00:00:00.450 PortCount =3D 0x0000000000000001 (1) 00:00:00.450 PrimaryMaster =3D 0x0000000000000000 (0) 00:00:00.450 PrimarySlave =3D 0x0000000000000001 (1) 00:00:00.450 SecondaryMaster =3D 0x0000000000000002 (2) 00:00:00.450 SecondarySlave =3D 0x0000000000000003 (3) 00:00:00.450=20 00:00:00.450 [/Devices/ahci/0/LUN#999/] (level 4) 00:00:00.450 Driver =3D "MainStatus" (cch=3D11) 00:00:00.450=20 00:00:00.450 [/Devices/ahci/0/LUN#999/Config/] (level 5) 00:00:00.450 papLeds =3D 0x0000000035f279fc (905083388) 00:00:00.450 First =3D 0x0000000000000000 (0) 00:00:00.450 Last =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x0000000000000003 (3) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/Config/] (level 4) 00:00:00.450 Am79C973 =3D 0x0000000000000001 (1) 00:00:00.450 MAC =3D "08 00 27 7e 63 6d" (cb=3D6) 00:00:00.450 CableConnected =3D 0x0000000000000001 (1) 00:00:00.450 LineSpeed =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/LUN#999/] (level 4) 00:00:00.450 Driver =3D "MainStatus" (cch=3D11) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/LUN#999/Config/] (level 5) 00:00:00.450 papLeds =3D 0x0000000035f27ab4 (905083572) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "NAT" (cch=3D4) 00:00:00.450=20 00:00:00.450 [/Devices/pcnet/0/LUN#0/Config/] (level 5) 00:00:00.450 TFTPPrefix =3D "/home/Intern/harry/.VirtualBox/T= FTP" (cch=3D36) 00:00:00.450 BootFile =3D "XPsp3proMSDN.pxe" (cch=3D17) 00:00:00.450=20 00:00:00.450 [/Devices/e1000/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/serial/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/parallel/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x0000000000000004 (4) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/Config/] (level 4) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "MainVMMDev" (cch=3D11) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/LUN#0/Config/] (level 5) 00:00:00.450 Object =3D 0x0000000033fbcf60 (872140640) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/LUN#999/] (level 4) 00:00:00.450 Driver =3D "MainStatus" (cch=3D11) 00:00:00.450=20 00:00:00.450 [/Devices/VMMDev/0/LUN#999/Config/] (level 5) 00:00:00.450 papLeds =3D 0x0000000035f27ad4 (905083604) 00:00:00.450 First =3D 0x0000000000000000 (0) 00:00:00.450 Last =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/AudioSniffer/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/AudioSniffer/0/] (level 3) 00:00:00.450=20 00:00:00.450 [/Devices/AudioSniffer/0/Config/] (level 4) 00:00:00.450=20 00:00:00.450 [/Devices/AudioSniffer/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "MainAudioSniffer" (cch=3D17) 00:00:00.450=20 00:00:00.450 [/Devices/AudioSniffer/0/LUN#0/Config/] (level 5) 00:00:00.450 Object =3D 0x0000000035e924d0 (904471760) 00:00:00.450=20 00:00:00.450 [/Devices/ichac97/] (level 2) 00:00:00.450=20 00:00:00.450 [/Devices/ichac97/0/] (level 3) 00:00:00.450 Trusted =3D 0x0000000000000001 (1) 00:00:00.450 PCIDeviceNo =3D 0x0000000000000005 (5) 00:00:00.450 PCIFunctionNo =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 [/Devices/ichac97/0/Config/] (level 4) 00:00:00.450=20 00:00:00.450 [/Devices/ichac97/0/LUN#0/] (level 4) 00:00:00.450 Driver =3D "AUDIO" (cch=3D6) 00:00:00.450=20 00:00:00.450 [/Devices/ichac97/0/LUN#0/Config/] (level 5) 00:00:00.450 AudioDriver =3D "oss" (cch=3D4) 00:00:00.450 StreamName =3D "XPsp3proMSDN" (cch=3D13) 00:00:00.450=20 00:00:00.450 [/TM/] (level 1) 00:00:00.450 UTCOffset =3D 0x0000000000000000 (0) 00:00:00.450=20 00:00:00.450 ********************* End of CFGM dump *********************= * 00:00:00.450 MM: cbHyperHeap=3D0x140000 (1310720) 00:00:00.451 Logical host processors: 2, processor active mask: 000000000= 0000001 00:00:00.451 ************************* CPUID dump ***********************= * 00:00:00.451 RAW Standard CPUIDs 00:00:00.451 Function eax ebx ecx edx 00:00:00.452 Gst: 00000000 00000002 756e6547 6c65746e 49656e69 00:00:00.452 Hst: 0000000a 756e6547 6c65746e 49656e69 00:00:00.452 Gst: 00000001 00010676 00000800 00000009 078bf1bf 00:00:00.452 Hst: 00010676 00020800 0008e3fd bfebfbff 00:00:00.452 Gst: 00000002 05b0b101 005657f0 00000000 2cb4304e 00:00:00.452 Hst: 05b0b101 005657f0 00000000 2cb4304e 00:00:00.452 Gst: 00000003 07280202 00000000 00000000 00000503* 00:00:00.452 Hst: 00000000 00000000 00000000 00000000 00:00:00.452 Gst: 00000004 00000000 00000000 00000000 00000503* 00:00:00.452 Hst: 04000121 01c0003f 0000003f 00000001 00:00:00.452 Gst: 00000005 07280202 00000000 00000000 00000503* 00:00:00.452 Hst: 00000040 00000040 00000003 00022220 00:00:00.452 Name: GenuineIntel 00:00:00.452 Supports: 0-2 00:00:00.452 Family: 6 Extended: 0 Effective:= 6 00:00:00.452 Model: 7 Extended: 1 Effective:= 23 00:00:00.452 Stepping: 6 00:00:00.452 APIC ID: 0x00 00:00:00.452 Logical CPUs: 0 00:00:00.452 CLFLUSH Size: 8 00:00:00.452 Brand ID: 0x00 00:00:00.452 Mnemonic - Description =3D guest (host) 00:00:00.452 FPU - x87 FPU on Chip =3D 1 (1) 00:00:00.452 VME - Virtual 8086 Mode Enhancements =3D 1 (1) 00:00:00.452 DE - Debugging extensions =3D 1 (1) 00:00:00.452 PSE - Page Size Extension =3D 1 (1) 00:00:00.452 TSC - Time Stamp Counter =3D 1 (1) 00:00:00.452 MSR - Model Specific Registers =3D 1 (1) 00:00:00.452 PAE - Physical Address Extension =3D 0 (1) 00:00:00.452 MCE - Machine Check Exception =3D 1 (1) 00:00:00.452 CX8 - CMPXCHG8B instruction =3D 1 (1) 00:00:00.452 APIC - APIC On-Chip =3D 0 (1) 00:00:00.452 Reserved =3D 0 (0) 00:00:00.452 SEP - SYSENTER and SYSEXIT =3D 0 (1) 00:00:00.452 MTRR - Memory Type Range Registers =3D 1 (1) 00:00:00.452 PGE - PTE Global Bit =3D 1 (1) 00:00:00.452 MCA - Machine Check Architecture =3D 1 (1) 00:00:00.452 CMOV - Conditional Move Instructions =3D 1 (1) 00:00:00.452 PAT - Page Attribute Table =3D 1 (1) 00:00:00.452 PSE-36 - 36-bit Page Size Extention =3D 1 (1) 00:00:00.452 PSN - Processor Serial Number =3D 0 (0) 00:00:00.452 CLFSH - CLFLUSH Instruction. =3D 1 (1) 00:00:00.452 Reserved =3D 0 (0) 00:00:00.452 DS - Debug Store =3D 0 (1) 00:00:00.452 ACPI - Thermal Mon. & Soft. Clock Ctrl.=3D 0 (1) 00:00:00.452 MMX - Intel MMX Technology =3D 1 (1) 00:00:00.452 FXSR - FXSAVE and FXRSTOR Instructions =3D 1 (1) 00:00:00.452 SSE - SSE Support =3D 1 (1) 00:00:00.452 SSE2 - SSE2 Support =3D 1 (1) 00:00:00.452 SS - Self Snoop =3D 0 (1) 00:00:00.452 HTT - Hyper-Threading Technolog =3D 0 (1) 00:00:00.452 TM - Thermal Monitor =3D 0 (1) 00:00:00.452 30 - Reserved =3D 0 (0) 00:00:00.452 PBE - Pending Break Enable =3D 0 (1) 00:00:00.452 Supports SSE3 or not =3D 1 (1) 00:00:00.452 Reserved =3D 0 (2) 00:00:00.452 Supports MONITOR/MWAIT =3D 1 (1) 00:00:00.452 CPL-DS - CPL Qualified Debug Store =3D 0 (1) 00:00:00.452 VMX - Virtual Machine Technology =3D 0 (1) 00:00:00.452 Reserved =3D 0 (1) 00:00:00.452 Enhanced SpeedStep Technology =3D 0 (1) 00:00:00.452 Terminal Monitor 2 =3D 0 (1) 00:00:00.452 Supports Supplemental SSE3 or not =3D 0 (1) 00:00:00.452 L1 Context ID =3D 0 (0) 00:00:00.452 Reserved =3D 0x0 (0x0) 00:00:00.452 CMPXCHG16B =3D 0 (1) 00:00:00.452 xTPR Update Control =3D 0 (1) 00:00:00.452 Reserved =3D 0x0 (0x11) 00:00:00.452=20 00:00:00.452 RAW Extended CPUIDs 00:00:00.452 Function eax ebx ecx edx 00:00:00.452 Gst: 80000000 80000008 00000000 00000000 00000000 00:00:00.452 Hst: 80000008 00000000 00000000 00000000 00:00:00.452 Gst: 80000001 00000000 00000000 00000000 00000000 00:00:00.452 Hst: 00000000 00000000 00000001 20100000 00:00:00.452 Gst: 80000002 65746e49 2952286c 726f4320 4d542865 00:00:00.452 Hst: 65746e49 2952286c 726f4320 4d542865 00:00:00.452 Gst: 80000003 44203229 43206f75 20205550 45202020 00:00:00.452 Hst: 44203229 43206f75 20205550 45202020 00:00:00.452 Gst: 80000004 30303438 20402020 30302e33 007a4847 00:00:00.452 Hst: 30303438 20402020 30302e33 007a4847 00:00:00.452 Gst: 80000005 00000000 00000000 00000000 00000000 00:00:00.452 Hst: 00000000 00000000 00000000 00000000 00:00:00.452 Gst: 80000006 00000000 00000000 18008040 00000000 00:00:00.452 Hst: 00000000 00000000 18008040 00000000 00:00:00.452 Gst: 80000007 00000000 00000000 00000000 00000000 00:00:00.452 Hst: 00000000 00000000 00000000 00000000 00:00:00.452 Gst: 80000008 00003024 00000000 00000000 00000000 00:00:00.452 Hst: 00003024 00000000 00000000 00000000 00:00:00.452 Gst: 80000009 07280202 00000000 00000000 00000503* 00:00:00.452 Hst: 07280202 00000000 00000000 00000503 00:00:00.452 Ext Name: =20 00:00:00.452 Ext Supports: 0x80000000-0x80000008 00:00:00.452 Family: 0 Extended: 0 Effective:= 0 00:00:00.452 Model: 0 Extended: 0 Effective:= 0 00:00:00.452 Stepping: 0 00:00:00.452 Brand ID: 0x000 00:00:00.452 Mnemonic - Description =3D guest (host) 00:00:00.452 FPU - x87 FPU on Chip =3D 0 (0) 00:00:00.452 VME - Virtual 8086 Mode Enhancements =3D 0 (0) 00:00:00.452 DE - Debugging extensions =3D 0 (0) 00:00:00.452 PSE - Page Size Extension =3D 0 (0) 00:00:00.452 TSC - Time Stamp Counter =3D 0 (0) 00:00:00.452 MSR - K86 Model Specific Registers =3D 0 (0) 00:00:00.452 PAE - Physical Address Extension =3D 0 (0) 00:00:00.452 MCE - Machine Check Exception =3D 0 (0) 00:00:00.452 CX8 - CMPXCHG8B instruction =3D 0 (0) 00:00:00.452 APIC - APIC On-Chip =3D 0 (0) 00:00:00.452 10 - Reserved =3D 0 (0) 00:00:00.452 SEP - SYSCALL and SYSRET =3D 0 (0) 00:00:00.452 MTRR - Memory Type Range Registers =3D 0 (0) 00:00:00.452 PGE - PTE Global Bit =3D 0 (0) 00:00:00.452 MCA - Machine Check Architecture =3D 0 (0) 00:00:00.452 CMOV - Conditional Move Instructions =3D 0 (0) 00:00:00.452 PAT - Page Attribute Table =3D 0 (0) 00:00:00.452 PSE-36 - 36-bit Page Size Extention =3D 0 (0) 00:00:00.452 18 - Reserved =3D 0 (0) 00:00:00.452 19 - Reserved =3D 0 (0) 00:00:00.452 NX - No-Execute Page Protection =3D 0 (1) 00:00:00.452 DS - Debug Store =3D 0 (0) 00:00:00.452 AXMMX - AMD Extensions to MMX Instr. =3D 0 (0) 00:00:00.452 MMX - Intel MMX Technology =3D 0 (0) 00:00:00.452 FXSR - FXSAVE and FXRSTOR Instructions =3D 0 (0) 00:00:00.452 25 - AMD fast FXSAVE and FXRSTOR Instr.=3D 0 (0) 00:00:00.452 26 - 1 GB large page support =3D 0 (0) 00:00:00.452 27 - RDTSCP instruction =3D 0 (0) 00:00:00.452 28 - Reserved =3D 0 (0) 00:00:00.452 29 - AMD Long Mode =3D 0 (1) 00:00:00.452 30 - AMD Extensions to 3DNow =3D 0 (0) 00:00:00.452 31 - AMD 3DNow =3D 0 (0) 00:00:00.452 LahfSahf - LAHF/SAHF in 64-bit mode =3D 0 (1) 00:00:00.452 CmpLegacy - Core MP legacy mode (depr) =3D 0 (0) 00:00:00.452 SVM - AMD VM Extensions =3D 0 (0) 00:00:00.452 APIC registers starting at 0x400 =3D 0 (0) 00:00:00.452 AltMovCR8 - LOCK MOV CR0 means MOV CR8 =3D 0 (0) 00:00:00.452 Advanced bit manipulation =3D 0 (0) 00:00:00.452 SSE4A instruction support =3D 0 (0) 00:00:00.452 Misaligned SSE mode =3D 0 (0) 00:00:00.452 PREFETCH and PREFETCHW instruction =3D 0 (0) 00:00:00.452 OS visible workaround =3D 0 (0) 00:00:00.452 Instruction based sampling =3D 0 (0) 00:00:00.452 SSE5 support =3D 0 (0) 00:00:00.452 SKINIT, STGI, and DEV support =3D 0 (0) 00:00:00.452 Watchdog timer support. =3D 0 (0) 00:00:00.452 31:14 - Reserved =3D 0x0 (0x0) 00:00:00.452 Full Name: Intel(R) Core(TM)2 Duo CPU = E8400 @ 3.00GHz 00:00:00.452 TLB 2/4M Instr/Uni: res0 0 entries 00:00:00.452 TLB 2/4M Data: res0 0 entries 00:00:00.452 TLB 4K Instr/Uni: res0 0 entries 00:00:00.452 TLB 4K Data: res0 0 entries 00:00:00.452 L1 Instr Cache Line Size: 0 bytes 00:00:00.452 L1 Instr Cache Lines Per Tag: 0 00:00:00.452 L1 Instr Cache Associativity: res0 =20 00:00:00.452 L1 Instr Cache Size: 0 KB 00:00:00.452 L1 Data Cache Line Size: 0 bytes 00:00:00.452 L1 Data Cache Lines Per Tag: 0 00:00:00.452 L1 Data Cache Associativity: res0 =20 00:00:00.452 L1 Data Cache Size: 0 KB 00:00:00.452 L2 TLB 2/4M Instr/Uni: off 0 entries 00:00:00.452 L2 TLB 2/4M Data: off 0 entries 00:00:00.452 L2 TLB 4K Instr/Uni: off 0 entries 00:00:00.452 L2 TLB 4K Data: off 0 entries 00:00:00.452 L2 Cache Line Size: 0 bytes 00:00:00.452 L2 Cache Lines Per Tag: 0 00:00:00.452 L2 Cache Associativity: off =20 00:00:00.452 L2 Cache Size: 0 KB 00:00:00.452 APM Features: =20 00:00:00.452 Physical Address Width: 36 bits 00:00:00.452 Virtual Address Width: 48 bits 00:00:00.452 Physical Core Count: 0 00:00:00.452=20 00:00:00.452 RAW Centaur CPUIDs 00:00:00.452 Function eax ebx ecx edx 00:00:00.452 Gst: c0000000 07280202 00000000 00000000 00000503 00:00:00.452 Hst: 07280202 00000000 00000000 00000503 00:00:00.452 Gst: c0000001 07280202 00000000 00000000 00000503 00:00:00.452 Hst: 07280202 00000000 00000000 00000503 00:00:00.452 Gst: c0000002 07280202 00000000 00000000 00000503 00:00:00.452 Hst: 07280202 00000000 00000000 00000503 00:00:00.452 Gst: c0000003 07280202 00000000 00000000 00000503 00:00:00.452 Hst: 07280202 00000000 00000000 00000503 00:00:00.452 Centaur Supports: 0xc0000000-0x07280202 00:00:00.452 Mnemonic - Description =3D guest (host) 00:00:00.452 AIS - Alternate Instruction Set =3D 0 (1) 00:00:00.452 AIS-E - AIS enabled =3D 0 (1) 00:00:00.452 RNG - Random Number Generator =3D 0 (0) 00:00:00.452 RNG-E - RNG enabled =3D 0 (0) 00:00:00.452 LH - LongHaul MSR 0000_110Ah =3D 0 (0) 00:00:00.452 FEMMS - FEMMS =3D 0 (0) 00:00:00.452 ACE - Advanced Cryptography Engine =3D 0 (0) 00:00:00.452 ACE-E - ACE enabled =3D 0 (0) 00:00:00.452 ACE2 - Advanced Cryptography Engine 2 =3D 0 (1) 00:00:00.452 ACE2-E - ACE enabled =3D 0 (0) 00:00:00.452 PHE - Hash Engine =3D 0 (1) 00:00:00.452 PHE-E - PHE enabled =3D 0 (0) 00:00:00.452 PMM - Montgomery Multiplier =3D 0 (0) 00:00:00.452 PMM-E - PMM enabled =3D 0 (0) 00:00:00.452=20 00:00:00.452=20 00:00:00.452 ******************** End of CPUID dump *********************= * 00:00:00.454 REM: VBoxREM32 00:00:00.465 TM: GIP - u32Mode=3D1 (SyncTSC) u32UpdateHz=3D100 00:00:00.499 TM: cTSCTicksPerSecond=3D0xb132afa8 (2972889000) fTSCVirtual= ized=3Dtrue fTSCUseRealTSC=3Dfalse 00:00:00.499 TM: fMaybeUseOffsettedHostTSC=3Dtrue TSCTiedToExecution=3Df= alse TSCNotTiedToHalt=3Dfalse 00:00:00.499 CoreCode: R3=3D357fe000 R0=3Dec586000 RC=3Da0330000 Phys=3D0= 00000003a054000 cb=3D0x2000 --------------000605090201040202090305-- --------------enig0203CC2C130DBCE6634D2A7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoTb+AACgkQLDqVQ9VXb8hyAwCgyUNWE4LKA8EzAkUZ37kSFaHT Y9IAoKhyA1djtRbv67xy2ZSmq2Ftsi7B =hNVH -----END PGP SIGNATURE----- --------------enig0203CC2C130DBCE6634D2A7F-- From owner-freebsd-current@FreeBSD.ORG Wed May 20 03:44:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A13081065676 for ; Wed, 20 May 2009 03:44:34 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 525DA8FC18 for ; Wed, 20 May 2009 03:44:34 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n4K3Qpec092270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 May 2009 22:26:51 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n4K3QoSw045426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 May 2009 22:26:51 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n4K3QmZb045363; Tue, 19 May 2009 22:26:48 -0500 (CDT) (envelope-from dan) Date: Tue, 19 May 2009 22:26:48 -0500 From: Dan Nelson To: Ruben de Groot , Paul Wootton , Max Laier , freebsd-current@freebsd.org Message-ID: <20090520032647.GF52703@dan.emsphone.com> References: <4A1123C5.3070507@fletchermoorland.co.uk> <4A122C23.40603@freebsd.org> <200905190637.03323.max@love2party.net> <4A128822.9030709@fletchermoorland.co.uk> <20090519103559.GA15608@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090519103559.GA15608@ei.bzerk.org> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 19 May 2009 22:26:51 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Subject: Re: discrepancies in used space after cpio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 03:44:34 -0000 In the last episode (May 19), Ruben de Groot said: > On Tue, May 19, 2009 at 11:21:22AM +0100, Paul Wootton typed: > > Yes /DemoPool is a raidz pool that is going to replace my single disk > > pool. Dmitry was right about sparse files > > demophon# pwd > > /var/tmp/kdecache-paul/kpc > > demophon# du -hA . > > 1.2G . > > demophon# du -h . > > 8.9M . > > > > Is there a there a better way instead of using cpio for moving an entire > > filing system from a single disk zfs pool to a raidz zfs pool? Or does > > making a sparse file in to a none sparse file just consume more disk > > space and no other side affects > > zfs send/recv ? cpio has a --sparse option that might recreate the sparse on the destination filesystem. Another solution would be to enable compression on your pool: "zfs set compress=on /DemoPool". The default compression (lzjb) consumes very little CPU and compresses zeros well :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed May 20 03:50:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C60106566B for ; Wed, 20 May 2009 03:50:05 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2A88FC08 for ; Wed, 20 May 2009 03:50:04 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by pzk3 with SMTP id 3so165057pzk.3 for ; Tue, 19 May 2009 20:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=m41dPR7Bpq09RHhSAymCOUosG187jd8x/E4erOB+noc=; b=tXi7n/ZvuxMdXTgypJhLxOGGibtFwQdKzb8rqcF9XeH0v5tUZjQ+X2KUuWZUzku7nn k0GMmN+QcaGdEKKg6s3Fr8Zh/7t1CAWUbCRQinmihNMIAw95idl8nyJHIq98i1ZRnGqV Tj2WmIDT8V/banhKdwQFar9DRi3gi5dAJrILs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=lVSiTTJM/MKuflgl/Cw9uXtZ08PMu5CKmZ6KsIa5wGpeB4wtcrl6zXc72oyiPpuEkF gRGFMnSkSBn909OBNQLz9+sI8dMx8XRC3GC5O7y5zkD9C9sKUtP9mfrGk/1hCai3inGB 8urW1fGi+Mw/cIFwHu0gPXD7kpp3HHG06SN7Y= Received: by 10.142.200.3 with SMTP id x3mr318902wff.63.1242791404771; Tue, 19 May 2009 20:50:04 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm14157966rvb.4.2009.05.19.20.50.01 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 20:50:03 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Wed, 20 May 2009 12:49:58 +0900 From: Weongyo Jeong Date: Wed, 20 May 2009 12:49:58 +0900 To: Lucius Windschuh Message-ID: <20090520034958.GJ42412@weongyo.cdnetworks.kr> Mail-Followup-To: Lucius Windschuh , freebsd-current@freebsd.org, Hans Petter Selasky References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <200905181050.03154.hselasky@c2i.net> <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> <20090519044941.GC42412@weongyo.cdnetworks.kr> <90a5caac0905191121r7da4f6e8t733eff327cf551e0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90a5caac0905191121r7da4f6e8t733eff327cf551e0@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 03:50:05 -0000 On Tue, May 19, 2009 at 08:21:22PM +0200, Lucius Windschuh wrote: > 2009/5/19 Weongyo Jeong : > > On Tue, May 19, 2009 at 12:08:45AM +0200, Lucius Windschuh wrote: > >> 2009/5/18 Hans Petter Selasky : > >> > Regarding the first panic, there seems to be a detach race in both upgt and > >> > uath, which is not USB related. Try this patch: > >> > > >> > http://perforce.freebsd.org/chv.cgi?CH=162250 > >> > >> This fixes not only the first panic. > >> I can't provoke any panic by pulling out the active device. Thanks. > > > > Could you please test with this patch that is slightly different with > > Hans's patch? ?It try to unsetup after stopping the device. > > > > If no problems I'd commit it. > > This works also. I cannot produce panics with it. The patch is committed at r192419. Thanks you for reporting! :-) regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Wed May 20 05:57:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC92C1065673 for ; Wed, 20 May 2009 05:57:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 772C68FC08 for ; Wed, 20 May 2009 05:57:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so96016rvb.43 for ; Tue, 19 May 2009 22:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=QDcADHy2j+TtqEH/mNXYLxbFAWquDEE+Fm72qfJpxFc=; b=KoR7tqgUU6lbtTpq7Gn+mZN2TsGCobBWlxsDuSkFTydNJzwDwQsCnUIqnVRKBDNAJA UYKTZL9yqovjYX+IY3qE7AKEQNqU18NWJ/xbG+OWpDM50flgnUSK7H1DEqZVtioYgEpx 4fTybT8IryObq/8PicdSqXppaTkzsET7A3DzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GpWONDQXHef661LPQwGZh8TpnIucjy/o6+bp9t10iHsEDh5OMx6oV6AZAdDb4TnqvL Wj3ANtTR7LoQFOYZAF6QIWpTXobxEnWerg6ZcAePomQ6DPCKfddpHMAID7g5dVbHkI0r FzMWBp4fybp7q9EErkeCvxXXMDLqBZqXaa0d0= Received: by 10.142.163.13 with SMTP id l13mr359961wfe.284.1242799049243; Tue, 19 May 2009 22:57:29 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm14362264rvb.10.2009.05.19.22.57.26 (version=SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 22:57:27 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Wed, 20 May 2009 15:07:23 +0900 From: Pyun YongHyeon Date: Wed, 20 May 2009 15:07:23 +0900 To: Pascal Braun Message-ID: <20090520060723.GH9043@michelle.cdnetworks.co.kr> References: <4A127C56.6040502@continum.net> <20090519104133.GF4697@michelle.cdnetworks.co.kr> <4A12B0B8.5020507@continum.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: <4A12B0B8.5020507@continum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Problems with jumbo frames on nfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 05:57:29 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 19, 2009 at 03:14:32PM +0200, Pascal Braun wrote: > Pyun YongHyeon wrote: > >On Tue, May 19, 2009 at 11:31:02AM +0200, Pascal Braun wrote: > >>Hi, > >> > >>I'm currently testing jumbo frames on a Sunfire 4540 running with > >>FreeBSD 8-Current (build on April 8th). While using the nfe driver I'm > >>having some unexpected problems if i try to bring up the interface with > >>MTU sizes greater than 1970 bytes. > >> > >>The error message (in dmesg) is: > >>nfe2: initialization failed: no memory for rx buffers > >> > > > >It means you've run out of jumbo clusters. Check the output of > >"netstat -m" and see how many jumbo cluster requests were denied. > > 771/1149/1920 mbufs in use (current/cache/total) > 770/680/1450/25600 mbuf clusters in use (current/cache/total/max) > 770/510 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/16384 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 1732K/1683K/3416K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > There are no denied requests. MTU size was about 1800. > But I have to add, that i cant even get the interface up if the mtu size > is above 1970. > > >>Does anyone have any ideas how to get jumbo frames working? > >> > > > >How about increasing 9K jumbo clusters(kern.ipc.nmbjumbo9) with > >sysctl(8)? > > sunfire# sysctl -a | grep jumbo > kern.ipc.nmbjumbo16: 3200 > kern.ipc.nmbjumbo9: 16384 > kern.ipc.nmbjumbop: 12800 > > I increased kern.ipc.nmbjumbo9 to 16384 (was 6400) but that didn't seem > to help. Do you have another idea? > Ok, would you try attached patch? --24zk1gE8NUlDmwG9 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="nfe.jumbo.patch" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 192411) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -1153,7 +1153,7 @@ /* Create DMA tag for jumbo Rx buffers. */ error = bus_dma_tag_create(sc->nfe_parent_tag, - PAGE_SIZE, 0, /* alignment, boundary */ + 1, 0, /* alignment, boundary */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ --24zk1gE8NUlDmwG9-- From owner-freebsd-current@FreeBSD.ORG Wed May 20 06:03:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B961065687 for ; Wed, 20 May 2009 06:03:11 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: from hisar.endersys.com (hisar.endersys.com [213.144.99.107]) by mx1.freebsd.org (Postfix) with ESMTP id 9D30B8FC0A for ; Wed, 20 May 2009 06:03:10 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: (surgate 20902 invoked by uid 1001); 20 May 2009 05:58:20 -0000 Received: from unknown (HELO 202.ofis.endersys.com.tr) (ismail.yenigul@endersys.com@127.0.0.1) by 0 with ESMTPA; 20 May 2009 05:58:19 -0000 Date: Wed, 20 May 2009 09:03:03 +0300 From: Ismail YENIGUL Organization: =?windows-1254?Q?Endersys_Dan=FD=FEmanl=FDk_ve_Yaz=FDl=FDm_Ltd.?= X-Priority: 3 (Normal) Message-ID: <1902762373.20090520090303@endersys.com> To: Martin Wilke , freebsd-current@freebsd.org In-Reply-To: <611494930.20090519211959@endersys.com> References: <20090514191237.GD70242@bsdcrew.de><20090517180920.GY71804@bsdcrew.de><20090519091310.GB71804@bsdcrew.de><200905191616.07296.subbsd@gmail.com><20090519135240.GH71804@bsdcrew.de> <611494930.20090519211959@endersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1254 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re[3]: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ismail YENIGUL List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 06:03:11 -0000 Hi, Here is the error messages when I try to start a virtual server. May 19 15:08:01 freebsd8 kernel: lock order reversal: May 19 15:08:01 freebsd8 kernel: 1st 0xfffffffe69c94230 bufwait (bufwait) @= /usr/src/sys/kern/vfs_bio.c:2555 May 19 15:08:01 freebsd8 kernel: 2nd 0xffffff00044d3c00 dirhash (dirhash) @= /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 May 19 15:08:01 freebsd8 kernel: KDB: stack backtrace: May 19 15:08:01 freebsd8 kernel: db_trace_self_wrapper() at db_trace_self_w= rapper+0x2a May 19 15:08:01 freebsd8 kernel: _witness_debugger() at _witness_debugger+0= x2e May 19 15:08:01 freebsd8 kernel: witness_checkorder() at witness_checkorder= +0x81e May 19 15:08:01 freebsd8 kernel: _sx_xlock() at _sx_xlock+0x55 May 19 15:08:01 freebsd8 kernel: ufsdirhash_acquire() at ufsdirhash_acquire= +0x33 May 19 15:08:01 freebsd8 kernel: ufsdirhash_add() at ufsdirhash_add+0x19 May 19 15:08:01 freebsd8 kernel: ufs_direnter() at ufs_direnter+0x88b May 19 15:08:01 freebsd8 kernel: ufs_makeinode() at ufs_makeinode+0x31c May 19 15:08:01 freebsd8 kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d May 19 15:08:01 freebsd8 kernel: vn_open_cred() at vn_open_cred+0x3fd May 19 15:08:01 freebsd8 kernel: kern_openat() at kern_openat+0x159 May 19 15:08:01 freebsd8 kernel: syscall() at syscall+0x1bf May 19 15:08:01 freebsd8 kernel: Xfast_syscall() at Xfast_syscall+0xd0 May 19 15:08:01 freebsd8 kernel: --- syscall (5, FreeBSD ELF64, open), rip = =3D 0x800e23e2c, rsp =3D 0x7fffffffe688, rbp =3D 0x124 --- May 19 15:22:05 freebsd8 kernel: kldload: unexpected relocation type 10 May 19 15:22:05 freebsd8 last message repeated 11 times May 19 15:22:05 freebsd8 kernel: vboxdrv: fAsync=3D0 offMin=3D0x1d8 offMax= =3D0x950 May 20 08:56:26 freebsd8 syslogd: kernel boot file is /boot/kernel/kernel May 20 08:56:26 freebsd8 kernel: Copyright (c) 1992-2009 The FreeBSD Projec= t. Ma Tuesday, May 19, 2009, 9:19:59 PM, you wrote: > Hello Martin, > I installed http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > on FreeBSD 8 snapshot-200905 amd64. > It compiled successfully, But When I create a virtual server (Redhat) and= click on start, > FreeBSD 8 crashed. I am not in the office at the moment. I will > check the error messages tomorrow. > Thaks. > Tuesday, May 19, 2009, 4:52:40 PM, you wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> On Tue, May 19, 2009 at 04:16:06PM +0400, subbsd wrote: >>> Hello >>> On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: >>> > Howdy .. >>> > >>> > Next run, >>> > >>> > We updated the port to 2.2.2r19801. >>> > The Patch files/patch-amd64-r0-exec-alloc >>> > was removed in favor of a similar fix >>> > commited to upstream. Also was fixed a >>> > bug on HEAD which should be fix the Kernel >>> > crash. Please test test test .. :-) >>> > >>> > PS: Yes this run is for AMD64 and HEAD >>> > users! >>> > >>> > >>> > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz >>> > >>> > >>> > Happy Testing! >>> I've try to compile this port on i386/8-CURRENT ( kern.osreldate: 80008= 7 ) and=20 >>> job stops with last messages: >> please update your src/kernel and rebuild vbox >>> -- >>> /* ... */ >>> kBuild: xsltproc VBoxSVC -=20 >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Ma= in/idl/xpidl.xsl >>> kBuild: Compiling RuntimeR3 -=20 >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Ru= ntime/common/err/errmsg.cpp >>> kBuild: Compiling RuntimeR3 -=20 >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Ru= ntime/common/err/errmsgxpcom.cpp >>> kBuild: Linking RuntimeR0 >>> kBuild: Linking RuntimeGC >>> kBuild: Linking RuntimeEFCPP >>> kBuild: Linking RuntimeR3NoCRTGCC >>> kBuild: Compiling RuntimeR0Drv -=20 >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Ru= ntime/common/alloc/alloc.cpp >>> kBuild: Linking VMMR3 >>> kBuild: Compiling PcBiosBin -=20 >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd= .x86/release/obj/PcBiosBin/_rombios_.c >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd= .x86/release/obj/PcBiosBin/_rombios_.c:471.66:=20 >>> error: need ';' >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd= .x86/release/obj/PcBiosBin/_rombios_.c:471.66:=20 >>> error: need variable name >>> kmk[2]: ***=20 >>> [/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebs= d.x86/release/obj/PcBiosBin/rombios0.s]=20 >>> Error 1 >>> kmk[2]: *** Deleting file=20 >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebs= d.x86/release/obj/PcBiosBin/rombios0.s' >>> kmk[2]: *** Waiting for unfinished jobs.... >>> kmk[2]: Leaving directory=20 >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >>> kmk[2]: Entering directory=20 >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >>> kmk[2]: *** Exiting with status 2 >>> kmk[1]: *** [pass_libraries_this] Error 2 >>> kmk[1]: Leaving directory=20 >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' >>> kmk: *** [pass_libraries_order] Error 2 >>> *** Error code 2 >>> Stop in /usr/ports/emulators/virtualbox. >>> -- >>> DISABLE_MAKE_JOBS=3Dyes options is not influence >>> In the _rombios__c at 471 i see strings: >>> static char bios_cvs_version_string[] =3D "VirtualBox " "2.2.51_OSE"; >>> but ';' symbol is presents.=20 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --=20 Ismail YENIGUL Endersys Ltd. Genel Koordinat=F6r / General Coordinator Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 Fax :+90 216-4709508 | web: http://www.endersys.com.tr Endersys blog a=E7=FDld=FD. http://blog.endersys.com From owner-freebsd-current@FreeBSD.ORG Wed May 20 06:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03AF1065673; Wed, 20 May 2009 06:21:53 +0000 (UTC) (envelope-from klingfon@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 4FDCF8FC23; Wed, 20 May 2009 06:21:53 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so904914fga.12 for ; Tue, 19 May 2009 23:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X+CVvR/pphrSAuYPn3O7G+tR/VWSlgL28MmRBxe33FU=; b=LCiMyuXNVXDgnF7k5xKX5g8LYQR7+jZMc2d4rsNBpaQOhMQ+3kwFO+tg6YCkKsbgt0 c7EqpIPt2czUwcViAasC34dvLzvj3McM01nHIlVzXqaugau1WxTvSMMjnoljO2LEgoWA Eq/d13GgNSyL79tR0ZnkKsKaQAH+F9oOSUMQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oh+IROCIXCNNLWogo//n2wacEZQf3wg/guXSFZzi79VUF54Qa4V1OsLyQXpoTJm1q8 dLHFfCzhMVUskpQ1Eg6MrB/XsRs/8GBtue15VH6k34yesQG/RJSsMtODNqqqOhRsUIwp X9qKON2YxOUPtD9JEJIe0q/aI96WirHQA6U1s= MIME-Version: 1.0 Received: by 10.239.161.132 with SMTP id h4mr78455hbd.14.1242800512208; Tue, 19 May 2009 23:21:52 -0700 (PDT) In-Reply-To: <4A130C5C.6090104@FreeBSD.org> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> <4A130C5C.6090104@FreeBSD.org> Date: Wed, 20 May 2009 08:21:52 +0200 Message-ID: <43b1bb350905192321h4e43e178vc9a00b646d0e2340@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 06:21:54 -0000 2009/5/19 Alexander Motin > Magnus Kling wrote: > >> 2009/5/19 Alexander Motin > >> >> Magnus Kling wrote: >> > I applied the patch and rebuilt the kernel. But when should this b= e >> > printed? At shutdown or boot? I can=B4t see it at all. >> >> On shutdown before panic. >> >> > When panic occurs I got the attached text as output on my serial >> console. >> > > Hmm. I don't see our debug messages there. Or it didn't shot due to some > stupid reason or problem is in different line. Could you try addr2line > utility to identify source line of 0xc0567110 address? > > Also try to change our > if (ctlr =3D=3D NULL) { > with > if (request->u.ata.command =3D=3D ATA_FLUSHCACHE || request->u.ata.comman= d =3D=3D > ATA_FLUSHCACHE48) { > > May be you could give me access to your server and it's serial console? I > would make debugging faster. > > -- > Alexander Motin > Addr2line gives me /usr/src/sys/dev/ata/chipsets/ata-promise.c:1066 struct ata_dma_prdentry *prd =3D request->dma->sg; Can we do an if statement with pointer prd? Or check what "sg" is at the moment? What is "sg"? /Magnus From owner-freebsd-current@FreeBSD.ORG Wed May 20 06:57:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0161065675 for ; Wed, 20 May 2009 06:57:18 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id B93EA8FC15 for ; Wed, 20 May 2009 06:57:17 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id D36684AC5D; Wed, 20 May 2009 08:57:12 +0200 (CEST) Date: Wed, 20 May 2009 08:57:12 +0200 From: Martin Wilke To: Ismail YENIGUL Message-ID: <20090520065712.GB9909@bsdcrew.de> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <200905191616.07296.subbsd@gmail.com> <20090519135240.GH71804@bsdcrew.de> <611494930.20090519211959@endersys.com> <1902762373.20090520090303@endersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1902762373.20090520090303@endersys.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 06:57:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, May 20, 2009 at 09:03:03AM +0300, Ismail YENIGUL wrote: > Hi, > > Here is the error messages when I try to start a virtual server. > > May 19 15:08:01 freebsd8 kernel: lock order reversal: > May 19 15:08:01 freebsd8 kernel: 1st 0xfffffffe69c94230 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 > May 19 15:08:01 freebsd8 kernel: 2nd 0xffffff00044d3c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 > May 19 15:08:01 freebsd8 kernel: KDB: stack backtrace: > May 19 15:08:01 freebsd8 kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > May 19 15:08:01 freebsd8 kernel: _witness_debugger() at _witness_debugger+0x2e > May 19 15:08:01 freebsd8 kernel: witness_checkorder() at witness_checkorder+0x81e > May 19 15:08:01 freebsd8 kernel: _sx_xlock() at _sx_xlock+0x55 > May 19 15:08:01 freebsd8 kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > May 19 15:08:01 freebsd8 kernel: ufsdirhash_add() at ufsdirhash_add+0x19 > May 19 15:08:01 freebsd8 kernel: ufs_direnter() at ufs_direnter+0x88b > May 19 15:08:01 freebsd8 kernel: ufs_makeinode() at ufs_makeinode+0x31c > May 19 15:08:01 freebsd8 kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d > May 19 15:08:01 freebsd8 kernel: vn_open_cred() at vn_open_cred+0x3fd > May 19 15:08:01 freebsd8 kernel: kern_openat() at kern_openat+0x159 > May 19 15:08:01 freebsd8 kernel: syscall() at syscall+0x1bf > May 19 15:08:01 freebsd8 kernel: Xfast_syscall() at Xfast_syscall+0xd0 > May 19 15:08:01 freebsd8 kernel: --- syscall (5, FreeBSD ELF64, open), rip = 0x800e23e2c, rsp = 0x7fffffffe688, rbp = 0x124 --- > May 19 15:22:05 freebsd8 kernel: kldload: unexpected relocation type 10 > May 19 15:22:05 freebsd8 last message repeated 11 times > May 19 15:22:05 freebsd8 kernel: vboxdrv: fAsync=0 offMin=0x1d8 offMax=0x950 > May 20 08:56:26 freebsd8 syslogd: kernel boot file is /boot/kernel/kernel > May 20 08:56:26 freebsd8 kernel: Copyright (c) 1992-2009 The FreeBSD Project. > Ma That is a FreeBSD LOR, that can you ignore :) > > Tuesday, May 19, 2009, 9:19:59 PM, you wrote: > > > Hello Martin, > > > I installed http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > > on FreeBSD 8 snapshot-200905 amd64. > > It compiled successfully, But When I create a virtual server (Redhat) and click on start, > > FreeBSD 8 crashed. I am not in the office at the moment. I will > > check the error messages tomorrow. > > > Thaks. > > > > Tuesday, May 19, 2009, 4:52:40 PM, you wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > > >> On Tue, May 19, 2009 at 04:16:06PM +0400, subbsd wrote: > >>> Hello > > >>> On Tuesday 19 May 2009 13:13:10 Martin Wilke wrote: > >>> > Howdy .. > >>> > > >>> > Next run, > >>> > > >>> > We updated the port to 2.2.2r19801. > >>> > The Patch files/patch-amd64-r0-exec-alloc > >>> > was removed in favor of a similar fix > >>> > commited to upstream. Also was fixed a > >>> > bug on HEAD which should be fix the Kernel > >>> > crash. Please test test test .. :-) > >>> > > >>> > PS: Yes this run is for AMD64 and HEAD > >>> > users! > >>> > > >>> > > >>> > http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz > >>> > > >>> > > >>> > Happy Testing! > > >>> I've try to compile this port on i386/8-CURRENT ( kern.osreldate: 800087 ) and > >>> job stops with last messages: > > >> please update your src/kernel and rebuild vbox > > >>> -- > >>> /* ... */ > >>> kBuild: xsltproc VBoxSVC - > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Main/idl/xpidl.xsl > >>> kBuild: Compiling RuntimeR3 - > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsg.cpp > >>> kBuild: Compiling RuntimeR3 - > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/err/errmsgxpcom.cpp > >>> kBuild: Linking RuntimeR0 > >>> kBuild: Linking RuntimeGC > >>> kBuild: Linking RuntimeEFCPP > >>> kBuild: Linking RuntimeR3NoCRTGCC > >>> kBuild: Compiling RuntimeR0Drv - > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/src/VBox/Runtime/common/alloc/alloc.cpp > >>> kBuild: Linking VMMR3 > >>> kBuild: Compiling PcBiosBin - > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: > >>> error: need ';' > >>> /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/_rombios_.c:471.66: > >>> error: need variable name > >>> kmk[2]: *** > >>> [/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s] > >>> Error 1 > >>> kmk[2]: *** Deleting file > >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801/out/freebsd.x86/release/obj/PcBiosBin/rombios0.s' > >>> kmk[2]: *** Waiting for unfinished jobs.... > >>> kmk[2]: Leaving directory > >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > >>> kmk[2]: Entering directory > >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > >>> kmk[2]: *** Exiting with status 2 > >>> kmk[1]: *** [pass_libraries_this] Error 2 > >>> kmk[1]: Leaving directory > >>> `/usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19801' > >>> kmk: *** [pass_libraries_order] Error 2 > >>> *** Error code 2 > > >>> Stop in /usr/ports/emulators/virtualbox. > > >>> -- > > >>> DISABLE_MAKE_JOBS=yes options is not influence > >>> In the _rombios__c at 471 i see strings: > > >>> static char bios_cvs_version_string[] = "VirtualBox " "2.2.51_OSE"; > > >>> but ';' symbol is presents. > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > > > -- > > Ismail YENIGUL > Endersys Ltd. > Genel Koordinatör / General Coordinator > > Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 > Fax :+90 216-4709508 | web: http://www.endersys.com.tr > Endersys blog aç?ld?. http://blog.endersys.com - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoTqcgACgkQdLJIhLHm/OlSFgCgi/hAnS8DDJeobXZ041/XSz1C qzcAnR/2Vaulyl9Q4GwcZYhofyfuTLrB =0f4w -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed May 20 06:57:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08CBC106564A for ; Wed, 20 May 2009 06:57:25 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 786068FC13 for ; Wed, 20 May 2009 06:57:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 243286064; Wed, 20 May 2009 09:57:23 +0300 Message-ID: <4A13A9D0.5080706@FreeBSD.org> Date: Wed, 20 May 2009 09:57:20 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Magnus Kling References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <4A10F3E3.40306@FreeBSD.org> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> <4A130C5C.6090104@FreeBSD.org> <43b1bb350905192321h4e43e178vc9a00b646d0e2340@mail.gmail.com> In-Reply-To: <43b1bb350905192321h4e43e178vc9a00b646d0e2340@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------020809000101070208030201" Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 06:57:25 -0000 This is a multi-part message in MIME format. --------------020809000101070208030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Magnus Kling wrote: > Addr2line gives me /usr/src/sys/dev/ata/chipsets/ata-promise.c:1066 > > struct ata_dma_prdentry *prd = request->dma->sg; > > Can we do an if statement with pointer prd? Or check what "sg" is at the > moment? What is "sg"? A-ha! That explains a lot! I have got it! Flush command has no data and does not uses DMA. Dereference of NULL request->dma pointer crashes the system. That dereference is just not needed there. Try please attached patch. -- Alexander Motin --------------020809000101070208030201 Content-Type: text/plain; name="ata-promise.c.nodma.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ata-promise.c.nodma.patch" --- ata-promise.c.prev 2009-05-20 01:24:31.000000000 +0300 +++ ata-promise.c 2009-05-20 09:51:13.000000000 +0300 @@ -1054,7 +1054,7 @@ ata_promise_sx4_command(struct ata_reque device_t gparent = GRANDPARENT(request->dev); struct ata_pci_controller *ctlr = device_get_softc(gparent); struct ata_channel *ch = device_get_softc(request->parent); - struct ata_dma_prdentry *prd = request->dma->sg; + struct ata_dma_prdentry *prd; caddr_t window = rman_get_virtual(ctlr->r_res1); u_int32_t *wordp; int i, idx, length = 0; @@ -1098,6 +1098,7 @@ ata_promise_sx4_command(struct ata_reque case ATA_READ_DMA48: case ATA_WRITE_DMA: case ATA_WRITE_DMA48: + prd = request->dma->sg; wordp = (u_int32_t *) (window + (ch->unit * ATA_PDC_CHN_OFFSET) + ATA_PDC_HSG_OFFSET); i = idx = 0; --------------020809000101070208030201-- From owner-freebsd-current@FreeBSD.ORG Wed May 20 07:06:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6013D1065670; Wed, 20 May 2009 07:06:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 6B05F8FC1E; Wed, 20 May 2009 07:06:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=_BEwgaXNDRcA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=V50a3v_1zrum5RoV-bUA:9 a=9zMBEmXqMLWEkf-GpcHAju-93XIA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 498045201; Wed, 20 May 2009 09:06:05 +0200 From: Hans Petter Selasky To: Mario Pavlov Date: Wed, 20 May 2009 09:10:01 +0200 User-Agent: KMail/1.9.7 References: <438704678.26539.1242769700629.JavaMail.apache@mail53.abv.bg> In-Reply-To: <438704678.26539.1242769700629.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905200910.03093.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Unable to read from CCID USB reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 07:06:09 -0000 On Tuesday 19 May 2009, Mario Pavlov wrote: > Hi, > I tired CURRENT and it's working for me :) > I only have one small issue... > when I unplug the reader pcscd goes to some sort of infinite loop > it would print this forever: > > 48111939 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2): > Device busy 00000020 ifdwrapper.c:469:IFDStatusICC() Card not transacted: > 612 > 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 00402930 ccid_usb.c:491:WriteUSB() > usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 00000021 > ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 > 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 00402953 ccid_usb.c:491:WriteUSB() > usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 00000016 > ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 > 00000010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 ... Maybe a bug in the pcsc driver. > ... > ... > > firefox does almost the same thing: > > [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No > readers found [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: > SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] > reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found > [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: > SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] > reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found > ... > ... > ... > > I guess this is not FreeBSD's fault, is it ? If the usb device /dev/usb/xxx for your device is not accessible to firefox then firefox can't open it. --HPS From owner-freebsd-current@FreeBSD.ORG Wed May 20 07:59:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783E0106564A; Wed, 20 May 2009 07:59:25 +0000 (UTC) (envelope-from klingfon@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 C76A48FC0A; Wed, 20 May 2009 07:59:24 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so77986eyd.7 for ; Wed, 20 May 2009 00:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DFTI52QHgBTRXSy95KPMlH34jTx/0xb26uOzIXr7FvE=; b=uqhJdPwjfuZ291FAW1JCki+FDuSOWxodDSgclDhbfs5shXvy0VD1f+YyvRSr69BwUY KI9XEi9xit2dsGJIfwSErZMfXBiC9OzLIGIMMNH6Z060gts1WxvQ9BG8iVjzIV1kLZyk VMLNGehiuLrbqZIztT9VFYpj8gNcR4OUR4Zro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bku5gmN5E1CQGiCnqJbpRKhoj+nSp24f8ROB1Edc33EDvToXxLic9uBDyH0XUbEfr/ 8w7oo8+vPxALl3w+QOLKI5uedtbAVa0XnzV9fgFBJ+0wxiw/GBqz81Ur6D4iMSlZoAB/ lmj2+gxh2LKs3kXLtarTVzd7xN9GEh31IiT8Y= MIME-Version: 1.0 Received: by 10.216.45.71 with SMTP id o49mr230609web.57.1242806363682; Wed, 20 May 2009 00:59:23 -0700 (PDT) In-Reply-To: <4A13A9D0.5080706@FreeBSD.org> References: <43b1bb350905150939s5d503f00x27116e7ffe79a37@mail.gmail.com> <43b1bb350905180025g682d3764qba5a450d85d8f961@mail.gmail.com> <43b1bb350905181331r44b35b13i22aa1ba6a18103ed@mail.gmail.com> <4A121C40.7040201@FreeBSD.org> <43b1bb350905182353v3812c523pa52cdf41ce886907@mail.gmail.com> <4A1264E8.2080707@FreeBSD.org> <43b1bb350905190554i511c1b32sa9320b10a86e2af2@mail.gmail.com> <4A130C5C.6090104@FreeBSD.org> <43b1bb350905192321h4e43e178vc9a00b646d0e2340@mail.gmail.com> <4A13A9D0.5080706@FreeBSD.org> Date: Wed, 20 May 2009 09:59:23 +0200 Message-ID: <43b1bb350905200059w115b02bcy339d20570b590504@mail.gmail.com> From: Magnus Kling To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when reboot on server with a Promise SX4000 and two ATA disks RAID1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 07:59:25 -0000 2009/5/20 Alexander Motin > Magnus Kling wrote: > >> Addr2line gives me /usr/src/sys/dev/ata/chipsets/ata-promise.c:1066 >> >> struct ata_dma_prdentry *prd = request->dma->sg; >> >> Can we do an if statement with pointer prd? Or check what "sg" is at the >> moment? What is "sg"? >> > > A-ha! That explains a lot! I have got it! > > Flush command has no data and does not uses DMA. Dereference of NULL > request->dma pointer crashes the system. That dereference is just not needed > there. Try please attached patch. > > -- > Alexander Motin > > --- ata-promise.c.prev 2009-05-20 01:24:31.000000000 +0300 > +++ ata-promise.c 2009-05-20 09:51:13.000000000 +0300 > @@ -1054,7 +1054,7 @@ ata_promise_sx4_command(struct ata_reque > device_t gparent = GRANDPARENT(request->dev); > struct ata_pci_controller *ctlr = device_get_softc(gparent); > struct ata_channel *ch = device_get_softc(request->parent); > - struct ata_dma_prdentry *prd = request->dma->sg; > + struct ata_dma_prdentry *prd; > caddr_t window = rman_get_virtual(ctlr->r_res1); > u_int32_t *wordp; > int i, idx, length = 0; > @@ -1098,6 +1098,7 @@ ata_promise_sx4_command(struct ata_reque > case ATA_READ_DMA48: > case ATA_WRITE_DMA: > case ATA_WRITE_DMA48: > + prd = request->dma->sg; > wordp = (u_int32_t *) > (window + (ch->unit * ATA_PDC_CHN_OFFSET) + ATA_PDC_HSG_OFFSET); > i = idx = 0; > > I can confirm that the above patch works fine! Thank you for taking your time to solve this bug. /Magnus From owner-freebsd-current@FreeBSD.ORG Wed May 20 09:06:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79E6106566B for ; Wed, 20 May 2009 09:06:31 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3550C8FC2B for ; Wed, 20 May 2009 09:06:31 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.0) with ESMTP id n4K96sJF098052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 May 2009 10:06:55 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4A13C812.5070206@unsane.co.uk> Date: Wed, 20 May 2009 10:06:26 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Randy Bush References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> <20090519190648.GD1050@camelot.theinternet.com.au> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 09:06:32 -0000 On 20/5/09 02:04, Randy Bush wrote: > as punishment, here is yet another email > > so i have it all partitioned using fixit/dist. > ad4p1 64k freebsd-boot > ad4p2 64g freebsd-zfs (to use as zfs mirror) > ad4p3 64g freebsd-swap > ad4p4 2tb freebsd-zfs (to use as raidz2) > > same for ad5. ad6 and ad7 have only p1 to join the raidz2. > > but i can not build the boot zfs mirror because i can not follow the > destructions at > > http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ > http://wiki.freebsd.org/AppleMacbook > etc > > because fixit/dist is a world where i can not mount the zfs pool because > / is read-only md0. so i can not set up the bootable zfs mirror system. > > and, to add to the fun. due to time pressure, i go to back off to my > old faithful hack of small gmirrored boot partitions with big zfs. i dd > whomp the base drives (dd if=/dev/zero of=/dev/da4 count=1000000). but > it seems not to stomp them. the sysinstall fdisk partiton editor keeps > seeing ad4p[1-4]! > > Try using gpart destroy -i X da4 where X is the partition index as seen from gpart show or possibly gpart destroy da4 I think your problem is that gpt keeps a secondary header at the end of the disk http://en.wikipedia.org/wiki/GUID_Partition_Table Vince > coffee or sleep, tough call. > > randy > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed May 20 09:28:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722CC1065673 for ; Wed, 20 May 2009 09:28:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 211198FC16 for ; Wed, 20 May 2009 09:28:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=FGqWH142ByHijgfNtNh00H+jO6QlPF7k9tHA8j23YumIlNki6VdH/JL1u7qSGqZHYuVb42UEQwIB/LkCLPF0dWXl2cGlWBfaaK20p+OnystamcQT8jKzX5MWRH6Xsb2XnCVWkbxHLZ8RvrJqh626p07rJbyx+znng+0/nsQT8ns=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M6i6N-0007Jg-41; Wed, 20 May 2009 13:28:43 +0400 Date: Wed, 20 May 2009 13:28:41 +0400 From: Eygene Ryabinkin To: Harald Schmalzbauer Message-ID: <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> References: <4A12CBE9.5010206@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A12CBE9.5010206@omnilan.de> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 09:28:45 -0000 Harald, good day. Tue, May 19, 2009 at 05:10:33PM +0200, Harald Schmalzbauer wrote: > 1. Setting dev.cpu.0.freq to reduced freq _increases_ power consumtion. > This also is true with powerd. When machine is idle, the primary power > consumtion is a little over 75W (which is quiet good for a triple-head > system). When I alter cpu.0.freq to anything other than native speed > (3000 in my case) the power consumption slightly incresaes about 1W. > Here's the relevant dmesg part (`dmesg | grep -i cpu`): > CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3003.02-MHz > 686-class CPU) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu0: on acpi0 > acpi_perf0: on cpu0 > coretemp0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > coretemp1: on cpu1 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a092006000920 > p4tcc1: on cpu1 > SMP: AP CPU #1 Launched! Could you, please, provide the output from 'acpidump -dt | grep -i cpu | grep -i alias' and your MB model. This may not help to decrease power consumption with lower frequencies, but may be your case is covered by the PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134192 and after the patch your second processor will be attached properly to the est1. And let me guess, you have kernel message like "device_attach: estX attach returned 6"? > 3. I can't write a DVD image with growisofs. > After booting I get these messages: > acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > (cd1:ata3:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 > (cd1:ata3:0:0:0): CAM Status: SCSI Status Error > (cd1:ata3:0:0:0): SCSI Status: Check Condition > (cd1:ata3:0:0:0): ILLEGAL REQUEST asc:24,0 > (cd1:ata3:0:0:0): Invalid field in CDB > (cd1:ata3:0:0:0): Unretryable error > > Using `growisofs -dvd-compat -speed=8 -Z /dev/cd1=/udfimage.iso` freezes > the system. First it seems nothing happens but after some minutes the > system is completely unresponsive, even mouse doesn't move any more. > Here's some output I got at this event: > ... > acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request > acd1: WARNING - PREVENT_ALLOW taskqueue timeout - completing request > directly > acd1: WARNING - PREVENT_ALLOW freeing taskqueue zombie request > acd1: WARNING - TEST_UNIT_READY taskqueue timeout - completing request > directly > acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request > acd1: WARNING - READ_TOC taskqueue timeout - completing request directly > acd1: WARNING - READ_TOC freeing taskqueue zombie reques Could you try to add atapicam(4) device into your kernel and use /dev/cdX instead of /dev/acdX for burning? I don't believe that this will help you, given the messages you're receiving, but you can at least give a shot for SCSI emulation on ATAPI devices. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed May 20 10:28:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976C5106566B for ; Wed, 20 May 2009 10:28:05 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 62F318FC20 for ; Wed, 20 May 2009 10:28:05 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 75F5D7E837; Wed, 20 May 2009 02:28:03 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 20 May 2009 12:27:46 +0200 User-Agent: KMail/1.11.3 (FreeBSD/8.0-CURRENT; KDE/4.2.3; i386; ; ) References: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> In-Reply-To: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905201227.46674.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Nenhum_de_Nos Subject: Re: is my slow for this ? hostap related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:28:05 -0000 Hi Nenhum, On Monday 18 May 2009 01:08:09 Nenhum_de_Nos wrote: > I have an atheros wlan card: > > ath0@pci0:0:11:0: class=0x020000 card=0x3a131186 chip=0x0013168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' > class = network > subclass = ethernet > May 17 13:19:36 floyd kernel: ath0: stuck beacon; resetting (bmiss count 4) > May 17 13:20:07 floyd last message repeated 89 times > May 17 13:22:08 floyd last message repeated 376 times > > I've read this: > > http://www.nabble.com/ath0:-stuck-beacon--resetting-(bmiss-count-4)-td22359 >155.html > > and I'm thinking my pc is slow for the job, as said. > > floyd# cat dmesg.today > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0: Tue May 5 23:08:28 BRT 2009 > root@floyd.apartnet:/usr/obj/usr/src/sys/Floyd8 > WARNING: WITNESS option enabled, expect reduced performance. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Read /usr/src/UPDATING about WITNESS options and which to delete from GENERIC kernel. I think once you turn those options off, your machine should be able to handle this, though I wouldn't run anything else on it. On a single 1.8Ghz 686, I got these occasionally, when backups were done over gigabit and a movie was playing on it. I've since reconfigured the machine as dedicated media server and replaced the router with a headless 3Ghz 686, also running squid. This is overkill for my home network, though. -- Mel From owner-freebsd-current@FreeBSD.ORG Wed May 20 10:31:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01576106568F for ; Wed, 20 May 2009 10:31:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC908FC54 for ; Wed, 20 May 2009 10:31:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4KASq0A064130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 12:28:56 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A13DB5D.1070708@omnilan.de> Date: Wed, 20 May 2009 12:28:45 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <4A12CBE9.5010206@omnilan.de> <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> In-Reply-To: <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6B5414FE79C5FE687D25917" Cc: freebsd-current@freebsd.org Subject: Re: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:31:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6B5414FE79C5FE687D25917 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eygene Ryabinkin schrieb am 20.05.2009 11:28 (localtime): > Harald, good day. =2E.. > Could you, please, provide the output from 'acpidump -dt | grep -i cpu = | > grep -i alias' and your MB model. This may not help to decrease power Thanks for your answer and a good da also, Eygene. Here's the reqested output, only without alias greped. Since I found a=20 BIOS updates I also get est0, but like you correctly assumed with=20 "attach returned 6". acpidump -dt | grep -i cpu ACPI CPU=3D0 ACPI CPU=3D1 ACPI CPU=3D2 ACPI CPU=3D3 ACPI CPU=3D0 ACPI CPU=3D1 ACPI CPU=3D2 ACPI CPU=3D3 OEMID=3DPmRef, OEM Table ID=3DCpuPm, OEM Revision=3D0x3000, Processor (\_PR.CPU0, 0x00, 0x00000410, 0x06) {} Processor (\_PR.CPU1, 0x01, 0x00000410, 0x06) {} Processor (\_PR.CPU2, 0x02, 0x00000410, 0x06) {} Processor (\_PR.CPU3, 0x03, 0x00000410, 0x06) {} "CPU0IST ", "CPU1IST ", "CPU0CST ", "CPU1CST ", "CPU2IST ", "CPU3IST ", "CPU2CST ", "CPU3CST ", Scope (\_PR.CPU0) Scope (\_PR.CPU1) Scope (\_PR.CPU2) Scope (\_PR.CPU3) The motherboard is a GigaByte P35DS4 =2E.. >=20 >> 3. I can't write a DVD image with growisofs. >> After booting I get these messages: >> acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 >> (cd1:ata3:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 >> (cd1:ata3:0:0:0): CAM Status: SCSI Status Error >> (cd1:ata3:0:0:0): SCSI Status: Check Condition >> (cd1:ata3:0:0:0): ILLEGAL REQUEST asc:24,0 >> (cd1:ata3:0:0:0): Invalid field in CDB >> (cd1:ata3:0:0:0): Unretryable error >> >> Using `growisofs -dvd-compat -speed=3D8 -Z /dev/cd1=3D/udfimage.iso` f= reezes=20 >> the system. First it seems nothing happens but after some minutes the = >> system is completely unresponsive, even mouse doesn't move any more.=20 >> Here's some output I got at this event: >> ... >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - PREVENT_ALLOW taskqueue timeout - completing request=20 >> directly >> acd1: WARNING - PREVENT_ALLOW freeing taskqueue zombie request >> acd1: WARNING - TEST_UNIT_READY taskqueue timeout - completing request= =20 >> directly >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - READ_TOC taskqueue timeout - completing request direct= ly >> acd1: WARNING - READ_TOC freeing taskqueue zombie reques >=20 > Could you try to add atapicam(4) device into your kernel and use > /dev/cdX instead of /dev/acdX for burning? I don't believe that this > will help you, given the messages you're receiving, but you can at leas= t > give a shot for SCSI emulation on ATAPI devices. I already used cd1 as device, hence the atapicam device. Fortunately I=20 need the ODD really seldom, but for the last two years I had to boot=20 another software because none of my drives worked. Am I the only one=20 with that massive problems? Could the AHCI mode be the culprit? Thanks for your time! Best gregards, -Harry --------------enigF6B5414FE79C5FE687D25917 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoT22QACgkQLDqVQ9VXb8hdrgCeLlEM2YiojbVldsz0wi7kTtPi f6QAoK/zxzDvY8g3LYLMMXmJAe2MVxWH =AuHa -----END PGP SIGNATURE----- --------------enigF6B5414FE79C5FE687D25917-- From owner-freebsd-current@FreeBSD.ORG Wed May 20 10:51:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E97106566C for ; Wed, 20 May 2009 10:51:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 869E18FC18 for ; Wed, 20 May 2009 10:51:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=H0zxABvSIjRlwNx8cvCBk1wXK87X0h8HSPIVEyJ/tE3ndDoUFn0pM1igu3siClzvn49QexERJo6mxtWVPPx3Ht+G+/FvSkZrM5AxHoyF7hzUEFSxLurDWf+X8tlO6vv9M3DfhQZ4l+tMJvUSAa7nPZeZKJCtiHtUSe57G3/rBvc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M6jOm-000FnV-Fg; Wed, 20 May 2009 14:51:48 +0400 Date: Wed, 20 May 2009 14:51:46 +0400 From: Eygene Ryabinkin To: Harald Schmalzbauer Message-ID: References: <4A12CBE9.5010206@omnilan.de> <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> <4A13DB5D.1070708@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A13DB5D.1070708@omnilan.de> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:51:50 -0000 Harald, Wed, May 20, 2009 at 12:28:45PM +0200, Harald Schmalzbauer wrote: > Eygene Ryabinkin schrieb am 20.05.2009 11:28 (localtime): > > Harald, good day. > ... > > Could you, please, provide the output from 'acpidump -dt | grep -i cpu | > > grep -i alias' and your MB model. This may not help to decrease power > > Thanks for your answer and a good da also, Eygene. No problems ;)) > Here's the reqested output, only without alias greped. Since I found a > BIOS updates I also get est0, but like you correctly assumed with > "attach returned 6". > acpidump -dt | grep -i cpu [...] No aliases. Pity, then the mentioned PR won't be able to help you. I could try to glance over the est attach issue if you'll post full dmesg, 'acpidump -dt', 'sysctl dev.cpu', 'sysctl dev.est' and 'sysctl dev.cpufreq'. Regarding the original problem about increased power consumption: you seem to have desktop CPU with only one SpeedStep frequency, but with TCC cycle throttling. This can be easily verified: you should see only one frequency in dev.est.0.freq_settings, but multiple (8, with stepping of 12.5%) frequencies in dev.cpu.0.freq_levels. Throttling is known not to decrease power consumption and your increase of 1W can be attributes as a measurment error (can't say for sure -- statistics and knowledge on how you had measured the consumption is needed). There is good set of notes from Alexander Motin on the power consumption on 8-CURRENT, http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006436.html perhaps this will give you some further ideas. > The motherboard is a GigaByte P35DS4 And you're running the latest known BIOS, aren't you? > I already used cd1 as device, hence the atapicam device. Fortunately I > need the ODD really seldom, but for the last two years I had to boot > another software because none of my drives worked. Am I the only one > with that massive problems? Could the AHCI mode be the culprit? Once I had similar messages with AHCI mode turned on some Asus MBs, so I am turning it off regularily. You can also try just enhanced SATA mode set via BIOS -- it could help. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed May 20 12:01:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF30F106566C; Wed, 20 May 2009 12:01:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 868B18FC15; Wed, 20 May 2009 12:01:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:42207 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M6kTh-0000ae-3X; Wed, 20 May 2009 14:00:58 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 016A76CD83; Wed, 20 May 2009 14:00:48 +0200 (CEST) Message-Id: From: Thomas Backman To: Wesley Shields In-Reply-To: <20090519204947.GA39529@atarininja.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 14:00:49 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <20090518161148.GA56646@atarininja.org> <20090519204947.GA39529@atarininja.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M6kTh-0000ae-3X. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M6kTh-0000ae-3X 9cb1ba1742a400c0df02dcc83950e01b Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 12:01:02 -0000 On May 19, 2009, at 10:49 PM, Wesley Shields wrote: > I just noticed this but shouldn't you be using copyinstr() on the > first > probe. It should look something like this: > > syscall::open:entry > { > self->path = copyinstr(arg0); > } > > syscall::open:return > / self->path / > { > printf("%s\n", self->path); > } > > This still doesn't solve the problem of copyinstr() causing a crash > though. I don't remember why, but I do remember that it was said (in older versions) in the Solaris DTrace guide to always copy in variables after the function return, not quite sure why (Possibly because they could be undefined in :::entry?). Brendan Gregg, who wrote the DTrace Toolkit, does this, anyway (see the opensnoop.d script). Sun liked his work so much that they hired him. :-) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Wed May 20 12:29:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78EB01065672; Wed, 20 May 2009 12:29:44 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 037528FC20; Wed, 20 May 2009 12:29:44 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id ECA534C12; Wed, 20 May 2009 14:29:42 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:2:2d29:1:9::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n4KCTdRA052970; Wed, 20 May 2009 14:29:39 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1242822582; bh=0/H6cEye/Cosmlh/ohqVMn7EFjfKosC+Od2WjGKCGls=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YV7otuJiut2NNN6gajOQfPvyo8v3zpw+P00z/8sAS+iS836uNTX25zSkpipLqV7Wn A4Ca3AMJXjJ6haGVF1S/Q== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=Wd8te1kutN866YHShMg4D18RvubkoTdOqTv/NImabTL2+ALKDOOOJnNCoorIbt476 TuZzqtEqf9cyiMJRx9ISQ== Message-ID: <4A13F7B3.5070404@restart.be> Date: Wed, 20 May 2009 14:29:39 +0200 From: Henri Hennebert User-Agent: Thunderbird 2.0.0.21 (X11/20090514) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gustau_P=E9rez?= References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <4A130842.5020407@protected-networks.net> <20090519193517.GA9909@bsdcrew.de> <4A130BE1.7060204@entel.upc.edu> In-Reply-To: <4A130BE1.7060204@entel.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 12:29:44 -0000 Gustau P=E9rez wrote: > Martin Wilke wrote: >> On Tue, May 19, 2009 at 03:28:02PM -0400, Michael Butler wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> Martin Wilke wrote: >>>> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz >>> With the latest tarball, I still don't see my DVD in the drop-down li= st >>> even though I have tweaked the devd.conf file such that .. >>> imb@toshi:/home/imb> ll /dev/*cd* >>> crw-rw-rw- 1 root operator 0, 97 May 19 10:55 /dev/acd0 >>> crw-rw-rw- 1 root operator 0, 104 May 19 10:55 /dev/cd0 >>> lrwxr-xr-x 1 root wheel 3 May 19 10:55 /dev/cdrom -> cd0= >>> This is on a Toshiba Satellite with today's -current .. >>> imb@toshi:/home/imb> uname -a >>> FreeBSD toshi.auburn.protected-networks.net 8.0-CURRENT FreeBSD >>> 8.0-CURRENT #89: Tue May 19 07:29:32 EDT 2009 >>> root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI=20 >> i386 >> >> at the moment a now issus we will take a look later. >> >> All in one seems that by most peoples now vbox works \o/ >> >=20 > Hi, >=20 > as I reported this morning, for me is not working. My system is a > DELL D630 laptop with 3Gb of RAM. i386/CURRENT update today : >=20 > FreeBSD gusiport 8.0-CURRENT FreeBSD 8.0-CURRENT #41: Tue May 1= 9 > 14:24:05 CEST 2009 =20 > gus@gusiport:/usr/obj/usr/src/sys/CUSTOM i386 >=20 > Last version fixed the problem with the kernel module not being > detected the second time vbox is run, but I still have vbox booting the= > virtual machine in wit a gray screen. I've observed the machine is > supposed to be running, but making top shows no activity. Also tried > VBoxSDL -startvm win (win is the id given to the vmachine, yes I know, > it took me little time to give it a name :) ) and the virtual machine > shows a black screen. No CPU activity at all. Tried disabling VT-x/AMD-= v > extensions (the laptop supports VT-x) still no go. Same problem here FreeBSD chamonix.restart.bel 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon May = 18 16:47:40 CEST 2009=20 root@chamonix.restart.bel:/usr/obj/usr/src/sys/CHAMONIX i386 I am using nvidia-driver-180.44 (II) LoadModule: "nvidia" (II) Loading /usr/local/lib/xorg/modules/drivers//nvidia_drv.so (II) Module nvidia: vendor=3D"NVIDIA Corporation" compiled for 4.0.2, module version =3D 1.0.0 Module class: X.Org Video Driver (II) NVIDIA dlloader X Driver 180.44 Mon Mar 23 05:42:54 PST 2009 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs (II) NVIDIA(0): NVIDIA GPU Quadro NVS 285 (NV44GL) at PCI:3:0:0 (GPU-0) (--) NVIDIA(0): Memory: 131072 kBytes (--) NVIDIA(0): VideoBIOS: 05.44.02.64.03 (II) NVIDIA(0): Detected PCI Express Link width: 1X (--) NVIDIA(0): Interlaced video modes are supported on this GPU (--) NVIDIA(0): Connected display device(s) on Quadro NVS 285 at PCI:3:0:= 0: (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0) (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0): 400.0 MHz maximum pixel clock (II) NVIDIA(0): Assigned Display Device: CRT-0 (II) NVIDIA(0): Validated modes: (II) NVIDIA(0): "1680x1050" (II) NVIDIA(0): Virtual screen size determined to be 1680 x 1050 (--) NVIDIA(0): DPI set to (90, 88); computed from "UseEdidDpi" X config (--) NVIDIA(0): option (=3D=3D) NVIDIA(0): Enabling 32-bit ARGB GLX visuals. Henri >=20 > Anything I can try ? >=20 > Thanks, >=20 > Gus From owner-freebsd-current@FreeBSD.ORG Wed May 20 12:51:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81DCD106566B for ; Wed, 20 May 2009 12:51:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 793A88FC1E for ; Wed, 20 May 2009 12:51:44 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4KCnXmK066151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 14:49:39 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A13FC57.3030109@omnilan.de> Date: Wed, 20 May 2009 14:49:27 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <4A12CBE9.5010206@omnilan.de> <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> <4A13DB5D.1070708@omnilan.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2FD014DA11C8CB65CA102E58" Cc: freebsd-current@freebsd.org Subject: Re: Various problems, atapi, acpi (S3), cpufreq (est) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 12:51:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2FD014DA11C8CB65CA102E58 Content-Type: multipart/mixed; boundary="------------010806050506050006050103" This is a multi-part message in MIME format. --------------010806050506050006050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eygene Ryabinkin schrieb am 20.05.2009 12:51 (localtime): =2E.. > No aliases. Pity, then the mentioned PR won't be able to help you. > I could try to glance over the est attach issue if you'll post full > dmesg, 'acpidump -dt', 'sysctl dev.cpu', 'sysctl dev.est' and 'sysctl > dev.cpufreq'. Please find attached the outputs besides the dev.cpufreq and the=20 dev.est. The latter is empty and I have disabled throttling, so since=20 est isn't available, there's no cpufreq. Insted I attached the est=20 relevant dmesg output. =2E.. > 12.5%) frequencies in dev.cpu.0.freq_levels. Throttling is known not t= o > decrease power consumption and your increase of 1W can be attributes as= > a measurment error (can't say for sure -- statistics and knowledge on > how you had measured the consumption is needed). I had done some testings a decent time ago regarding power savings. I=20 also read the thread you mentioned, but for me, throttling never=20 decreased power consumption. Measuring is quiet simple: A not too bad=20 230V power meter with VA/W "knowledge". =2E.. >> The motherboard is a GigaByte P35DS4 >=20 > And you're running the latest known BIOS, aren't you? Yes, I also tried the beta one. No recognizable difference... =2E.. >> another software because none of my drives worked. Am I the only one=20 >> with that massive problems? Could the AHCI mode be the culprit? >=20 > Once I had similar messages with AHCI mode turned on some Asus MBs, so = I > am turning it off regularily. You can also try just enhanced SATA mode= > set via BIOS -- it could help. I have two external hot-swap-drive-stations on the ICH9 controller and=20 since `atacontrol detach` and attach works fine with AHCI I preferred=20 that mode. I often have to add HDDs at runtime. Possibly it would also=20 work with IDE mode, but this is too risky at the moment; I don't have a=20 spare machine and seeing my workhorse freezing means alsways lost work...= Thank you! Best regards, -Harry --------------010806050506050006050103 Content-Type: text/plain; name="acpidump-dt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="acpidump-dt" /* RSD PTR: OEM=3DGBT, ACPI_Rev=3D1.0x (0) RSDT=3D0x7fee3040, cksum=3D199 */ /* RSDT: Length=3D56, Revision=3D1, Checksum=3D72, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x42302e31, Creator ID=3DGBTU, Creator Revision=3D0x1010101 Entries=3D{ 0x7fee30c0, 0x7fee7e00, 0x7fee7e80, 0x7fee7d00, 0x7fee8520 }= */ /* FACP: Length=3D116, Revision=3D1, Checksum=3D176, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x42302e31, Creator ID=3DGBTU, Creator Revision=3D0x1010101 FACS=3D0x7fee0000, DSDT=3D0x7fee3180 INT_MODEL=3DAPIC Preferred_PM_Profile=3DDesktop (1) SCI_INT=3D9 SMI_CMD=3D0xb2, ACPI_ENABLE=3D0xa1, ACPI_DISABLE=3D0xa0, S4BIOS_REQ=3D0x= 0 PSTATE_CNT=3D0x34 PM1a_EVT_BLK=3D0x400-0x403 PM1a_CNT_BLK=3D0x404-0x405 PM_TMR_BLK=3D0x408-0x40b GPE0_BLK=3D0x420-0x42f P_LVL2_LAT=3D101 us, P_LVL3_LAT=3D1001 us FLUSH_SIZE=3D0, FLUSH_STRIDE=3D0 DUTY_OFFSET=3D1, DUTY_WIDTH=3D3 DAY_ALRM=3D13, MON_ALRM=3D0, CENTURY=3D0 IAPC_BOOT_ARCH=3D} Flags=3D{WBINVD,PROC_C1,SLP_BUTTON,RTC_S4,RESET_REG} RESET_REG=3D0x00000000:0[0] (Memory), RESET_VALUE=3D0 */ /* FACS: Length=3D64, HwSig=3D0x00000000, Firm_Wake_Vec=3D0x00000000 Global_Lock=3D Flags=3D Version=3D0 */ /* DSDT: Length=3D19242, Revision=3D1, Checksum=3D193, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x1000, Creator ID=3DMSFT, Creator Revision=3D0x100000c */ /* HPET: Length=3D56, Revision=3D1, Checksum=3D232, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x42302e31, Creator ID=3DGBTU, Creator Revision=3D0x98 HPET Number=3D0 ADDR=3D0xfed00000:0[0] (Memory) HW Rev=3D0x1 Comparitors=3D2 Counter Size=3D1 Legacy IRQ routing capable=3D{TRUE} PCI Vendor ID=3D0x8086 Minimal Tick=3D16 */ /* MCFG: Length=3D60, Revision=3D1, Checksum=3D228, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x42302e31, Creator ID=3DGBTU, Creator Revision=3D0x1010101 Base Address=3D 0x00000000f0000000 Segment Group=3D 0x0000 Start Bus=3D 0 End Bus=3D 63 */ /* APIC: Length=3D132, Revision=3D1, Checksum=3D134, OEMID=3DGBT, OEM Table ID=3DGBTUACPI, OEM Revision=3D0x42302e31, Creator ID=3DGBTU, Creator Revision=3D0x1010101 Local APIC ADDR=3D0xfee00000 Flags=3D{PC-AT} Type=3DLocal APIC ACPI CPU=3D0 Flags=3D{ENABLED} APIC ID=3D0 Type=3DLocal APIC ACPI CPU=3D1 Flags=3D{ENABLED} APIC ID=3D1 Type=3DLocal APIC ACPI CPU=3D2 Flags=3D{DISABLED} APIC ID=3D2 Type=3DLocal APIC ACPI CPU=3D3 Flags=3D{DISABLED} APIC ID=3D3 Type=3DIO APIC APIC ID=3D2 INT BASE=3D0 ADDR=3D0x00000000fec00000 Type=3DINT Override BUS=3D0 IRQ=3D0 INTR=3D2 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DINT Override BUS=3D0 IRQ=3D9 INTR=3D9 Flags=3D{Polarity=3Dactive-hi, Trigger=3Dlevel} Type=3DLocal NMI ACPI CPU=3D0 LINT Pin=3D1 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DLocal NMI ACPI CPU=3D1 LINT Pin=3D1 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DLocal NMI ACPI CPU=3D2 LINT Pin=3D1 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DLocal NMI ACPI CPU=3D3 LINT Pin=3D1 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} */ /* SSDT: Length=3D939, Revision=3D1, Checksum=3D97, OEMID=3DPmRef, OEM Table ID=3DCpuPm, OEM Revision=3D0x3000, Creator ID=3DINTL, Creator Revision=3D0x20040311 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20070320 * * Disassembly of /tmp/acpidump.Xvq7LK, Wed May 20 14:30:49 2009 * * * Original Table Header: * Signature "DSDT" * Length 0x00004EB1 (20145) * Revision 0x01 * OEM ID "GBT " * OEM Table ID "GBTUACPI" * OEM Revision 0x00001000 (4096) * Creator ID "MSFT" * Creator Revision 0x0100000C (16777228) */ DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "GBT ", "GBTUACPI", 0x= 00001000) { Scope (\_PR) { Processor (\_PR.CPU0, 0x00, 0x00000410, 0x06) {} Processor (\_PR.CPU1, 0x01, 0x00000410, 0x06) {} Processor (\_PR.CPU2, 0x02, 0x00000410, 0x06) {} Processor (\_PR.CPU3, 0x03, 0x00000410, 0x06) {} } Name (\_S0, Package (0x04) { 0x00,=20 0x00,=20 0x00,=20 0x00 }) Name (\SS1, Package (0x04) { 0x01,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S3, Package (0x04) { 0x05,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S4, Package (0x04) { 0x06,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S5, Package (0x04) { 0x07,=20 0x00,=20 0x00,=20 0x00 }) Name (FLAG, 0x00) Name (STAT, 0x00) OperationRegion (SMOD, SystemMemory, 0x000FF840, 0x01) Field (SMOD, ByteAcc, NoLock, Preserve) { , 7,=20 SUSF, 1 } OperationRegion (\DEBG, SystemIO, 0x80, 0x01) Field (\DEBG, ByteAcc, NoLock, Preserve) { DBG1, 8 } OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000) Field (RCRB, DWordAcc, Lock, Preserve) { Offset (0x3404),=20 , 7,=20 HPTF, 1 } OperationRegion (ELKM, SystemMemory, 0x000FFFEA, 0x01) Field (ELKM, ByteAcc, NoLock, Preserve) { , 1,=20 , 1,=20 ELSO, 1,=20 , 1,=20 , 1,=20 , 1,=20 , 1 } OperationRegion (EXTM, SystemMemory, 0x000FF830, 0x10) Field (EXTM, WordAcc, NoLock, Preserve) { ROM1, 16,=20 RMS1, 16,=20 ROM2, 16,=20 RMS2, 16,=20 ROM3, 16,=20 RMS3, 16,=20 AMEM, 32 } OperationRegion (\SMIC, SystemIO, 0xB2, 0x01) Field (\SMIC, ByteAcc, NoLock, Preserve) { SCP, 8 } OperationRegion (\GP2C, SystemIO, 0x042C, 0x02) Field (\GP2C, ByteAcc, NoLock, Preserve) { G2C1, 8,=20 G2C2, 8 } OperationRegion (\GBLE, SystemIO, 0x0421, 0x01) Field (\GBLE, ByteAcc, NoLock, Preserve) { ESMI, 8 } OperationRegion (APMP, SystemIO, 0xB2, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8,=20 APMD, 8 } OperationRegion (\AGPS, SystemIO, 0x0438, 0x04) Field (\AGPS, ByteAcc, NoLock, Preserve) { GPSE, 16,=20 GPSS, 16 } OperationRegion (\GPCN, SystemIO, 0x0442, 0x01) Field (\GPCN, ByteAcc, NoLock, Preserve) { , 1,=20 SWGC, 1,=20 Offset (0x01) } Name (OSFX, 0x01) Name (OSFL, 0x01) Method (STRC, 2, NotSerialized) { If (LNotEqual (SizeOf (Arg0), SizeOf (Arg1))) { Return (0x00) } Add (SizeOf (Arg0), 0x01, Local0) Name (BUF0, Buffer (Local0) {}) Name (BUF1, Buffer (Local0) {}) Store (Arg0, BUF0) Store (Arg1, BUF1) While (Local0) { Decrement (Local0) If (LNotEqual (DerefOf (Index (BUF0, Local0)), DerefOf (Index= ( BUF1, Local0)))) { Return (Zero) } } Return (One) } OperationRegion (INFO, SystemMemory, 0x000FF840, 0x02) Field (INFO, ByteAcc, NoLock, Preserve) { KBDI, 1,=20 RTCW, 1,=20 PS2F, 1,=20 IRFL, 2,=20 DISE, 1,=20 SSHU, 1 } Scope (\) { Name (PICF, 0x00) Method (_PIC, 1, NotSerialized) { Store (Arg0, PICF) } } Method (\_PTS, 1, NotSerialized) { Or (Arg0, 0xF0, Local0) Store (Local0, DBG1) OSTP () If (LEqual (Arg0, 0x01)) {} If (LEqual (Arg0, 0x03)) {} If (LEqual (Arg0, 0x05)) { Store (ESMI, Local0) And (Local0, 0xFB, Local0) Store (Local0, ESMI) } If (LEqual (Arg0, 0x04)) { If (LNot (PICF)) { Sleep (0x64) } } } Method (\_WAK, 1, NotSerialized) { Store (0xFF, DBG1) If (LEqual (Arg0, 0x03)) { Store (0x8F, SCP) } If (LEqual (Arg0, 0x04)) { If (LEqual (OSFL, 0x00)) { If (LEqual (OSFX, 0x03)) { Store (0x59, SMIP) } Else { Store (0x58, SMIP) } } If (LEqual (OSFL, 0x01)) { Store (0x56, SMIP) } If (LEqual (OSFL, 0x02)) { Store (0x57, SMIP) } If (LEqual (OSFX, 0x03)) { Store (0x59, SMIP) } } If (LEqual (Arg0, 0x01)) {} If (OSFL) { Notify (\_SB.PWRB, 0x02) } Else { If (LEqual (RTCW, 0x00)) { Notify (\_SB.PWRB, 0x02) } } Notify (\_SB.PCI0.USB0, 0x00) Notify (\_SB.PCI0.USB1, 0x00) Notify (\_SB.PCI0.USB2, 0x00) Notify (\_SB.PCI0.USB3, 0x00) Notify (\_SB.PCI0.USB4, 0x00) Notify (\_SB.PCI0.USB5, 0x00) } Scope (\_SI) { Method (_MSG, 1, NotSerialized) { Store (Local0, Local0) } Method (_SST, 1, NotSerialized) { Store (Local0, Local0) } } Scope (\_GPE) { Method (_L08, 0, NotSerialized) { Notify (\_SB.PCI0.PX40.UAR1, 0x02) } Method (_L03, 0, NotSerialized) { Notify (\_SB.PCI0.USB0, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L04, 0, NotSerialized) { Notify (\_SB.PCI0.USB1, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0C, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0E, 0, NotSerialized) { Notify (\_SB.PCI0.USB3, 0x02) Notify (\_SB.PWRB, 0x02) Notify (\_SB.PCI0.US31, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.USB4, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L20, 0, NotSerialized) { Notify (\_SB.PCI0.USB5, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0D, 0, NotSerialized) { Notify (\_SB.PCI0.USBE, 0x02) Notify (\_SB.PCI0.USE2, 0x02) Notify (\_SB.PWRB, 0x02) Notify (\_SB.PCI0.AZAL, 0x02) } Method (_L02, 0, NotSerialized) { Store (0x00, SWGC) ShiftLeft (0x01, 0x0F, Local0) Store (0x02, Local2) Store (0x01, Local3) Store (Local3, Local4) While (LAnd (LNotEqual (Local4, 0x00), LNotEqual (Local2, 0x0= 0))) { Sleep (0x01) Decrement (Local2) And (GPSS, Local0, Local1) If (LNotEqual (Local1, Local0)) { Decrement (Local4) } Else { Store (Local3, Local4) } } And (GPSS, Local0, GPSS) Or (GPSE, Local0, GPSE) } Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.HUB0, 0x02) } Method (_L09, 0, NotSerialized) { Notify (\_SB.PCI0.PEX0, 0x02) Notify (\_SB.PCI0.PEX1, 0x02) Notify (\_SB.PCI0.PEX2, 0x02) Notify (\_SB.PCI0.PEX3, 0x02) Notify (\_SB.PCI0.PEX4, 0x02) Notify (\_SB.PCI0.PEX5, 0x02) } } Scope (\_SB) { Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Method (_STA, 0, NotSerialized) { Return (0x0B) } } Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00) Name (_UID, 0x01) Name (_BBN, 0x00) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Else { Return (0x03) } } Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { WordBusNumber (ResourceConsumer, MinNotFixed, MaxNotF= ixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x003F, // Range Maximum 0x0000, // Translation Offset 0x0040, // Length ,, ) IO (Decode16, 0x0CF8, // Range Minimum 0x0CF8, // Range Maximum 0x01, // Alignment 0x08, // Length ) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDeco= de, EntireRange, 0x0000, // Granularity 0x0000, // Range Minimum 0x0CF7, // Range Maximum 0x0000, // Translation Offset 0x0CF8, // Length ,, , TypeStatic) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDeco= de, EntireRange, 0x0000, // Granularity 0x0D00, // Range Minimum 0xFFFF, // Range Maximum 0x0000, // Translation Offset 0xF300, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, M= axFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000A0000, // Range Minimum 0x000BFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, M= axFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C0000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, M= axFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00100000, // Range Minimum 0xFEBFFFFF, // Range Maximum 0x00000000, // Translation Offset 0xFFF00000, // Length ,, _Y00, AddressRangeMemory, TypeStatic) }) CreateDWordField (BUF0, \_SB.PCI0._CRS._Y00._MIN, TCMM) CreateDWordField (BUF0, \_SB.PCI0._CRS._Y00._LEN, TOMM) Add (AMEM, 0x00010000, TCMM) Add (TCMM, 0x00010000, TCMM) Subtract (0xFEC00000, TCMM, TOMM) Return (BUF0) } Name (PICM, Package (0x16) { Package (0x04) { 0x001BFFFF,=20 0x00,=20 \_SB.PCI0.LNK0,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x03,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x01,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x03,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x01,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x00,=20 \_SB.PCI0.LNK1,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x01,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x03,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x001AFFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x001AFFFF,=20 0x01,=20 \_SB.PCI0.LNKF,=20 0x00 },=20 Package (0x04) { 0x001AFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x001AFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 } }) Name (APIC, Package (0x16) { Package (0x04) { 0x001BFFFF,=20 0x00,=20 0x00,=20 0x16 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0x0001FFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x0001FFFF,=20 0x03,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001CFFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0x001CFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001CFFFF,=20 0x03,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001CFFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0x001DFFFF,=20 0x00,=20 0x00,=20 0x17 },=20 Package (0x04) { 0x001DFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001DFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001DFFFF,=20 0x03,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001FFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001AFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001AFFFF,=20 0x01,=20 0x00,=20 0x15 },=20 Package (0x04) { 0x001AFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001AFFFF,=20 0x02,=20 0x00,=20 0x12 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PICM) } Else { Return (APIC) } } Device (PEX0) { Name (_ADR, 0x001C0000) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC0, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKD,=20 0x00 } }) Name (API0, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x13 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC0) } Else { Return (API0) } } } Device (PEX1) { Name (_ADR, 0x001C0001) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC1, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKA,=20 0x00 } }) Name (API1, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x10 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC1) } Else { Return (API1) } } } Device (PEX2) { Name (_ADR, 0x001C0002) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC2, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKB,=20 0x00 } }) Name (API2, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x11 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC2) } Else { Return (API2) } } } Device (PEX3) { Name (_ADR, 0x001C0003) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC3, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKC,=20 0x00 } }) Name (API3, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x12 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC3) } Else { Return (API3) } } } Device (PEX4) { Name (_ADR, 0x001C0004) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC4, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKD,=20 0x00 } }) Name (API4, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x13 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC4) } Else { Return (API4) } } } Device (PEX5) { Name (_ADR, 0x001C0005) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x09,=20 0x05 }) } Name (PIC5, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKA,=20 0x00 } }) Name (API5, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x10 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PIC5) } Else { Return (API5) } } } Device (\_SB.PCI0.PEX4.JMB0) { Name (_ADR, 0x00) Name (PIOT, Package (0x05) { 0x0258,=20 0x0186,=20 0x014A,=20 0xB4,=20 0x78 }) Name (MDMA, Package (0x03) { 0x01E0,=20 0x96,=20 0x78 }) Name (UDMA, Package (0x07) { 0x78,=20 0x50,=20 0x3C,=20 0x28,=20 0x1E,=20 0x14,=20 0x0F }) OperationRegion (CF40, PCI_Config, 0x40, 0x04) Field (CF40, ByteAcc, NoLock, Preserve) { , 3,=20 CAB0, 1,=20 , 18,=20 SWAP, 1,=20 CHN0, 1,=20 Offset (0x04) } OperationRegion (CF80, PCI_Config, 0x80, 0x04) Field (CF80, ByteAcc, NoLock, Preserve) { , 19,=20 CAB1, 1,=20 Offset (0x03),=20 CHN1, 1,=20 Offset (0x04) } Name (IDEB, Buffer (0x14) {}) CreateDWordField (IDEB, 0x00, GTM0) CreateDWordField (IDEB, 0x04, GTM1) CreateDWordField (IDEB, 0x08, GTM2) CreateDWordField (IDEB, 0x0C, GTM3) CreateDWordField (IDEB, 0x10, GTM4) Name (PMIO, 0x04) Name (PMDM, 0x06) Name (PSIO, 0x04) Name (PSDM, 0x06) Name (SMIO, 0x04) Name (SMDM, 0x06) Name (SSIO, 0x04) Name (SSDM, 0x06) Name (MODP, 0x05) Name (MODS, 0x05) Device (SDE0) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store (DerefOf (Index (PIOT, PMIO)), Local0) Store (DerefOf (Index (PIOT, PSIO)), Local2) Store (0x1A, Local4) If (LAnd (MODP, 0x01)) { Store (DerefOf (Index (UDMA, PMDM)), Local1) If (LGreater (PMDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN1, 0x01))) { If (CAB1) { Store (0x02, PMDM) Store (DerefOf (Index (UDMA, PMDM= )), Local1) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N0, 0x01))) { If (CAB0) { Store (0x02, PMDM) Store (DerefOf (Index (UDMA, PMDM= )), Local1) } } } Or (Local4, 0x01, Local4) } Else { Store (DerefOf (Index (MDMA, PMDM)), Local1) } If (LAnd (MODP, 0x04)) { Store (DerefOf (Index (UDMA, PSDM)), Local3) If (LGreater (PSDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN1, 0x01))) { If (CAB1) { Store (0x02, PSDM) Store (DerefOf (Index (UDMA, PSDM= )), Local3) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N0, 0x01))) { If (CAB0) { Store (0x02, PSDM) Store (DerefOf (Index (UDMA, PSDM= )), Local3) } } } Or (Local4, 0x04, Local4) } Else { Store (DerefOf (Index (MDMA, PSDM)), Local3) } Store (Local0, GTM0) Store (Local1, GTM1) Store (Local2, GTM2) Store (Local3, GTM3) Store (Local4, GTM4) Return (IDEB) } Method (_STM, 3, NotSerialized) { Store (Arg0, IDEB) Store (GTM0, Local0) Store (GTM1, Local1) Store (GTM2, Local2) Store (GTM3, Local3) Store (GTM4, Local4) If (LAnd (LNotEqual (Local0, 0xFFFFFFFF), LNotEqu= al (Local0, 0x00))) { Store (Match (PIOT, MEQ, Local0, MTR, 0x00, 0= x00), PMIO) } If (LAnd (LNotEqual (Local1, 0xFFFFFFFF), LNotEqu= al (Local1, 0x00))) { If (LAnd (Local4, 0x01)) { Store (Match (UDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), PMDM) } Else { Store (Match (MDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), PMDM) } } If (LAnd (LNotEqual (Local2, 0xFFFFFFFF), LNotEqu= al (Local2, 0x00))) { Store (Match (PIOT, MEQ, Local2, MTR, 0x00, 0= x00), PSIO) } If (LAnd (LNotEqual (Local3, 0xFFFFFFFF), LNotEqu= al (Local3, 0x00))) { If (LAnd (Local4, 0x04)) { Store (Match (UDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), PSDM) } Else { Store (Match (MDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), PSDM) } } Store (Local4, MODP) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (PMIO, PIOM) Or (PIOM, 0x08, PIOM) Store (PMDM, DMAM) If (LAnd (MODP, 0x01)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (PSIO, PIOM) Or (PIOM, 0x08, PIOM) Store (PSDM, DMAM) If (LAnd (MODP, 0x04)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } } Device (SDE1) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store (DerefOf (Index (PIOT, SMIO)), Local0) Store (DerefOf (Index (PIOT, SSIO)), Local2) Store (0x1A, Local4) If (LAnd (MODS, 0x01)) { Store (DerefOf (Index (UDMA, SMDM)), Local1) If (LGreater (SMDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN0, 0x01))) { If (CAB0) { Store (0x02, SMDM) Store (DerefOf (Index (UDMA, SMDM= )), Local1) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N1, 0x01))) { If (CAB1) { Store (0x02, SMDM) Store (DerefOf (Index (UDMA, SMDM= )), Local1) } } } Or (Local4, 0x01, Local4) } Else { Store (DerefOf (Index (MDMA, SMDM)), Local1) } If (LAnd (MODS, 0x04)) { Store (DerefOf (Index (UDMA, SSDM)), Local3) If (LGreater (SSDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN0, 0x01))) { If (CAB0) { Store (0x02, SSDM) Store (DerefOf (Index (UDMA, SSDM= )), Local3) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N1, 0x01))) { If (CAB1) { Store (0x02, SSDM) Store (DerefOf (Index (UDMA, SSDM= )), Local3) } } } Or (Local4, 0x04, Local4) } Else { Store (DerefOf (Index (MDMA, SSDM)), Local3) } Store (Local0, GTM0) Store (Local1, GTM1) Store (Local2, GTM2) Store (Local3, GTM3) Store (Local4, GTM4) Return (IDEB) } Method (_STM, 3, NotSerialized) { Store (Arg0, IDEB) Store (GTM0, Local0) Store (GTM1, Local1) Store (GTM2, Local2) Store (GTM3, Local3) Store (GTM4, Local4) If (LAnd (LNotEqual (Local0, 0xFFFFFFFF), LNotEqu= al (Local0, 0x00))) { Store (Match (PIOT, MEQ, Local0, MTR, 0x00, 0= x00), SMIO) } If (LAnd (LNotEqual (Local1, 0xFFFFFFFF), LNotEqu= al (Local1, 0x00))) { If (LAnd (Local4, 0x01)) { Store (Match (UDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), SMDM) } Else { Store (Match (MDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), SMDM) } } If (LAnd (LNotEqual (Local2, 0xFFFFFFFF), LNotEqu= al (Local2, 0x00))) { Store (Match (PIOT, MEQ, Local2, MTR, 0x00, 0= x00), SSIO) } If (LAnd (LNotEqual (Local3, 0xFFFFFFFF), LNotEqu= al (Local3, 0x00))) { If (LAnd (Local4, 0x04)) { Store (Match (UDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), SSDM) } Else { Store (Match (MDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), SSDM) } } Store (Local4, MODS) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (SMIO, PIOM) Or (PIOM, 0x08, PIOM) Store (SMDM, DMAM) If (LAnd (MODS, 0x01)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (SSIO, PIOM) Or (PIOM, 0x08, PIOM) Store (SSDM, DMAM) If (LAnd (MODS, 0x04)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } } } Device (\_SB.PCI0.PEX4.JMB1) { Name (_ADR, 0x01) Name (PIOT, Package (0x05) { 0x0258,=20 0x0186,=20 0x014A,=20 0xB4,=20 0x78 }) Name (MDMA, Package (0x03) { 0x01E0,=20 0x96,=20 0x78 }) Name (UDMA, Package (0x07) { 0x78,=20 0x50,=20 0x3C,=20 0x28,=20 0x1E,=20 0x14,=20 0x0F }) OperationRegion (CF40, PCI_Config, 0x40, 0x04) Field (CF40, ByteAcc, NoLock, Preserve) { , 3,=20 CAB0, 1,=20 , 18,=20 SWAP, 1,=20 CHN0, 1,=20 Offset (0x04) } OperationRegion (CF80, PCI_Config, 0x80, 0x04) Field (CF80, ByteAcc, NoLock, Preserve) { , 19,=20 CAB1, 1,=20 Offset (0x03),=20 CHN1, 1,=20 Offset (0x04) } Name (IDEB, Buffer (0x14) {}) CreateDWordField (IDEB, 0x00, GTM0) CreateDWordField (IDEB, 0x04, GTM1) CreateDWordField (IDEB, 0x08, GTM2) CreateDWordField (IDEB, 0x0C, GTM3) CreateDWordField (IDEB, 0x10, GTM4) Name (PMIO, 0x04) Name (PMDM, 0x06) Name (PSIO, 0x04) Name (PSDM, 0x06) Name (SMIO, 0x04) Name (SMDM, 0x06) Name (SSIO, 0x04) Name (SSDM, 0x06) Name (MODP, 0x05) Name (MODS, 0x05) Device (SDE0) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store (DerefOf (Index (PIOT, PMIO)), Local0) Store (DerefOf (Index (PIOT, PSIO)), Local2) Store (0x1A, Local4) If (LAnd (MODP, 0x01)) { Store (DerefOf (Index (UDMA, PMDM)), Local1) If (LGreater (PMDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN1, 0x01))) { If (CAB1) { Store (0x02, PMDM) Store (DerefOf (Index (UDMA, PMDM= )), Local1) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N0, 0x01))) { If (CAB0) { Store (0x02, PMDM) Store (DerefOf (Index (UDMA, PMDM= )), Local1) } } } Or (Local4, 0x01, Local4) } Else { Store (DerefOf (Index (MDMA, PMDM)), Local1) } If (LAnd (MODP, 0x04)) { Store (DerefOf (Index (UDMA, PSDM)), Local3) If (LGreater (PSDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN1, 0x01))) { If (CAB1) { Store (0x02, PSDM) Store (DerefOf (Index (UDMA, PSDM= )), Local3) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N0, 0x01))) { If (CAB0) { Store (0x02, PSDM) Store (DerefOf (Index (UDMA, PSDM= )), Local3) } } } Or (Local4, 0x04, Local4) } Else { Store (DerefOf (Index (MDMA, PSDM)), Local3) } Store (Local0, GTM0) Store (Local1, GTM1) Store (Local2, GTM2) Store (Local3, GTM3) Store (Local4, GTM4) Return (IDEB) } Method (_STM, 3, NotSerialized) { Store (Arg0, IDEB) Store (GTM0, Local0) Store (GTM1, Local1) Store (GTM2, Local2) Store (GTM3, Local3) Store (GTM4, Local4) If (LAnd (LNotEqual (Local0, 0xFFFFFFFF), LNotEqu= al (Local0, 0x00))) { Store (Match (PIOT, MEQ, Local0, MTR, 0x00, 0= x00), PMIO) } If (LAnd (LNotEqual (Local1, 0xFFFFFFFF), LNotEqu= al (Local1, 0x00))) { If (LAnd (Local4, 0x01)) { Store (Match (UDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), PMDM) } Else { Store (Match (MDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), PMDM) } } If (LAnd (LNotEqual (Local2, 0xFFFFFFFF), LNotEqu= al (Local2, 0x00))) { Store (Match (PIOT, MEQ, Local2, MTR, 0x00, 0= x00), PSIO) } If (LAnd (LNotEqual (Local3, 0xFFFFFFFF), LNotEqu= al (Local3, 0x00))) { If (LAnd (Local4, 0x04)) { Store (Match (UDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), PSDM) } Else { Store (Match (MDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), PSDM) } } Store (Local4, MODP) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (PMIO, PIOM) Or (PIOM, 0x08, PIOM) Store (PMDM, DMAM) If (LAnd (MODP, 0x01)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (PSIO, PIOM) Or (PIOM, 0x08, PIOM) Store (PSDM, DMAM) If (LAnd (MODP, 0x04)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } } Device (SDE1) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store (DerefOf (Index (PIOT, SMIO)), Local0) Store (DerefOf (Index (PIOT, SSIO)), Local2) Store (0x1A, Local4) If (LAnd (MODS, 0x01)) { Store (DerefOf (Index (UDMA, SMDM)), Local1) If (LGreater (SMDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN0, 0x01))) { If (CAB0) { Store (0x02, SMDM) Store (DerefOf (Index (UDMA, SMDM= )), Local1) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N1, 0x01))) { If (CAB1) { Store (0x02, SMDM) Store (DerefOf (Index (UDMA, SMDM= )), Local1) } } } Or (Local4, 0x01, Local4) } Else { Store (DerefOf (Index (MDMA, SMDM)), Local1) } If (LAnd (MODS, 0x04)) { Store (DerefOf (Index (UDMA, SSDM)), Local3) If (LGreater (SSDM, 0x02)) { If (LAnd (LNotEqual (SWAP, 0x01), LEqual = (CHN0, 0x01))) { If (CAB0) { Store (0x02, SSDM) Store (DerefOf (Index (UDMA, SSDM= )), Local3) } } If (LAnd (LEqual (SWAP, 0x01), LEqual (CH= N1, 0x01))) { If (CAB1) { Store (0x02, SSDM) Store (DerefOf (Index (UDMA, SSDM= )), Local3) } } } Or (Local4, 0x04, Local4) } Else { Store (DerefOf (Index (MDMA, SSDM)), Local3) } Store (Local0, GTM0) Store (Local1, GTM1) Store (Local2, GTM2) Store (Local3, GTM3) Store (Local4, GTM4) Return (IDEB) } Method (_STM, 3, NotSerialized) { Store (Arg0, IDEB) Store (GTM0, Local0) Store (GTM1, Local1) Store (GTM2, Local2) Store (GTM3, Local3) Store (GTM4, Local4) If (LAnd (LNotEqual (Local0, 0xFFFFFFFF), LNotEqu= al (Local0, 0x00))) { Store (Match (PIOT, MEQ, Local0, MTR, 0x00, 0= x00), SMIO) } If (LAnd (LNotEqual (Local1, 0xFFFFFFFF), LNotEqu= al (Local1, 0x00))) { If (LAnd (Local4, 0x01)) { Store (Match (UDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), SMDM) } Else { Store (Match (MDMA, MEQ, Local1, MTR, 0x0= 0, 0x00), SMDM) } } If (LAnd (LNotEqual (Local2, 0xFFFFFFFF), LNotEqu= al (Local2, 0x00))) { Store (Match (PIOT, MEQ, Local2, MTR, 0x00, 0= x00), SSIO) } If (LAnd (LNotEqual (Local3, 0xFFFFFFFF), LNotEqu= al (Local3, 0x00))) { If (LAnd (Local4, 0x04)) { Store (Match (UDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), SSDM) } Else { Store (Match (MDMA, MEQ, Local3, MTR, 0x0= 0, 0x00), SSDM) } } Store (Local4, MODS) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (SMIO, PIOM) Or (PIOM, 0x08, PIOM) Store (SMDM, DMAM) If (LAnd (MODS, 0x01)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local0) Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0= xEF }, Local1) CreateByteField (Local0, 0x01, PIOM) CreateByteField (Local1, 0x01, DMAM) Store (SSIO, PIOM) Or (PIOM, 0x08, PIOM) Store (SSDM, DMAM) If (LAnd (MODS, 0x04)) { Or (DMAM, 0x40, DMAM) } Else { Or (DMAM, 0x20, DMAM) } Concatenate (Local0, Local1, Local2) Return (Local2) } } } } Device (HUB0) { Name (_ADR, 0x001E0000) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (PICM, Package (0x0C) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.PCI0.LNKE,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 \_SB.PCI0.LNKD,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x02,=20 \_SB.PCI0.LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x03,=20 \_SB.PCI0.LNKE,=20 0x00 },=20 Package (0x04) { 0x0006FFFF,=20 0x00,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x0006FFFF,=20 0x01,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x0006FFFF,=20 0x02,=20 \_SB.PCI0.LNKC,=20 0x00 },=20 Package (0x04) { 0x0006FFFF,=20 0x03,=20 \_SB.PCI0.LNKC,=20 0x00 } }) Name (APIC, Package (0x0C) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x14 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x0001FFFF,=20 0x02,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x0001FFFF,=20 0x03,=20 0x00,=20 0x14 },=20 Package (0x04) { 0x0006FFFF,=20 0x00,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x0006FFFF,=20 0x01,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x0006FFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x0006FFFF,=20 0x03,=20 0x00,=20 0x12 } }) Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PICM) } Else { Return (APIC) } } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0B,=20 0x05 }) } } Device (PX40) { Name (_ADR, 0x001F0000) OperationRegion (PREV, PCI_Config, 0x08, 0x01) Scope (\) { Field (\_SB.PCI0.PX40.PREV, ByteAcc, NoLock, Preserve= ) { REV0, 8 } } OperationRegion (PIRQ, PCI_Config, 0x60, 0x04) Scope (\) { Field (\_SB.PCI0.PX40.PIRQ, ByteAcc, NoLock, Preserve= ) { PIRA, 8,=20 PIRB, 8,=20 PIRC, 8,=20 PIRD, 8 } } OperationRegion (PIR2, PCI_Config, 0x68, 0x04) Scope (\) { Field (\_SB.PCI0.PX40.PIR2, ByteAcc, NoLock, Preserve= ) { PIRE, 8,=20 PIRF, 8,=20 PIRG, 8,=20 PIRH, 8 } } OperationRegion (LPIO, PCI_Config, 0x80, 0x0E) Scope (\) { Field (\_SB.PCI0.PX40.LPIO, ByteAcc, NoLock, Preserve= ) { UAIO, 8,=20 PRIO, 8,=20 LPE1, 8,=20 LPE2, 8,=20 GN1L, 8,=20 GN1H, 8,=20 GN2L, 8,=20 GN2H, 8 } Method (DISD, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { And (LPE1, 0xFE, LPE1) } If (LEqual (Arg0, 0x01)) { And (LPE1, 0xFD, LPE1) } If (LEqual (Arg0, 0x02)) { And (LPE1, 0xFB, LPE1) } If (LEqual (Arg0, 0x03)) { And (LPE1, 0xF7, LPE1) } If (LEqual (Arg0, 0x04)) { And (LPE2, 0xFC, LPE2) } If (LEqual (Arg0, 0x05)) { And (LPE1, 0xDF, LPE1) } If (LEqual (Arg0, 0x06)) { And (GN2L, 0xFE, GN2L) } } Method (CKIO, 2, NotSerialized) { If (LEqual (Arg1, 0x00)) { Or (LPE1, 0x01, LPE1) And (UAIO, 0xF0, Local0) If (LEqual (Arg0, 0x03F8)) { Or (Local0, 0x00, UAIO) } If (LEqual (Arg0, 0x02F8)) { Or (Local0, 0x01, UAIO) } If (LEqual (Arg0, 0x02E8)) { Or (Local0, 0x05, UAIO) } If (LEqual (Arg0, 0x03E8)) { Or (Local0, 0x07, UAIO) } } If (LEqual (Arg1, 0x01)) { Or (LPE1, 0x02, LPE1) And (UAIO, 0x0F, Local0) If (LEqual (Arg0, 0x03F8)) { Or (Local0, 0x00, UAIO) } If (LEqual (Arg0, 0x02F8)) { Or (Local0, 0x10, UAIO) } If (LEqual (Arg0, 0x02E8)) { Or (Local0, 0x50, UAIO) } If (LEqual (Arg0, 0x03E8)) { Or (Local0, 0x70, UAIO) } } If (LEqual (Arg1, 0x02)) { Or (LPE1, 0x04, LPE1) And (PRIO, 0xFC, Local0) If (LEqual (Arg0, 0x0378)) { Or (Local0, 0x00, PRIO) } If (LEqual (Arg0, 0x0278)) { Or (Local0, 0x01, PRIO) } If (LEqual (Arg0, 0x03BC)) { Or (Local0, 0x02, PRIO) } } If (LEqual (Arg1, 0x03)) { Or (LPE1, 0x08, LPE1) } If (LEqual (Arg1, 0x04)) { If (LEqual (Arg0, 0x0201)) { Or (LPE2, 0x01, LPE2) } If (LEqual (Arg0, 0x0209)) { Or (LPE2, 0x02, LPE2) } } If (LEqual (Arg1, 0x06)) { If (LNotEqual (Arg0, 0xFFFF)) { And (Arg0, 0xFF, Local0) Or (Local0, 0x01, GN2L) ShiftRight (Arg0, 0x08, GN2H) } Else { Store (Zero, GN2H) Store (Zero, GN2L) } } } } Scope (\) { Method (SLDM, 2, NotSerialized) { } } Scope (\) { OperationRegion (\SCPP, SystemIO, 0xB2, 0x01) Field (\SCPP, ByteAcc, NoLock, Preserve) { SMIP, 8 } } Method (\_SB.PCI0._INI, 0, NotSerialized) { If (STRC (\_OS, "Microsoft Windows")) { Store (0x56, SMIP) } Else { If (STRC (\_OS, "Microsoft Windows NT")) { If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Windows 2001")) { Store (0x59, SMIP) Store (0x00, OSFL) Store (0x03, OSFX) } } Else { Store (0x58, SMIP) Store (0x00, OSFL) } } Else { Store (0x57, SMIP) Store (0x02, OSFL) } } } Scope (\) { Method (OSTP, 0, NotSerialized) { If (LEqual (OSFL, 0x01)) { Store (0x56, SMIP) } If (LEqual (OSFL, 0x02)) { Store (0x57, SMIP) } If (LEqual (OSFL, 0x00)) { If (LEqual (OSFX, 0x03)) { Store (0x59, SMIP) } Else { Store (0x58, SMIP) } } If (LEqual (OSFX, 0x03)) { Store (0x59, SMIP) } } } Device (SYSR) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x01) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0010, // Range Minimum 0x0010, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0022, // Range Minimum 0x0022, // Range Maximum 0x01, // Alignment 0x1E, // Length ) IO (Decode16, 0x0044, // Range Minimum 0x0044, // Range Maximum 0x01, // Alignment 0x1C, // Length ) IO (Decode16, 0x0062, // Range Minimum 0x0062, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0065, // Range Minimum 0x0065, // Range Maximum 0x01, // Alignment 0x0B, // Length ) IO (Decode16, 0x0074, // Range Minimum 0x0074, // Range Maximum 0x01, // Alignment 0x0C, // Length ) IO (Decode16, 0x0091, // Range Minimum 0x0091, // Range Maximum 0x01, // Alignment 0x03, // Length ) IO (Decode16, 0x00A2, // Range Minimum 0x00A2, // Range Maximum 0x01, // Alignment 0x1E, // Length ) IO (Decode16, 0x00E0, // Range Minimum 0x00E0, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x04D0, // Range Minimum 0x04D0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0290, // Range Minimum 0x0290, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0800, // Range Minimum 0x0800, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0x0290, // Range Minimum 0x0290, // Range Maximum 0x01, // Alignment 0x05, // Length ) IO (Decode16, 0x0880, // Range Minimum 0x0880, // Range Maximum 0x01, // Alignment 0x10, // Length ) }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, // Range Minimum 0x0020, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A0, // Range Minimum 0x00A0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IRQNoFlags () {2} }) } Device (DMA1) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { DMA (Compatibility, BusMaster, Transfer8, ) {4} IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0080, // Range Minimum 0x0080, // Range Maximum 0x01, // Alignment 0x11, // Length ) IO (Decode16, 0x0094, // Range Minimum 0x0094, // Range Maximum 0x01, // Alignment 0x0C, // Length ) IO (Decode16, 0x00C0, // Range Minimum 0x00C0, // Range Maximum 0x01, // Alignment 0x20, // Length ) }) } Device (TMR) { Name (_HID, EisaId ("PNP0100")) Name (ATT5, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {0} }) Name (ATT6, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) }) Method (_CRS, 0, NotSerialized) { If (LGreaterEqual (OSFX, 0x03)) { If (HPTF) { Return (ATT6) } Else { Return (ATT5) } } Else { Return (ATT5) } } } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (ATT3, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Name (ATT4, ResourceTemplate () { }) Method (_STA, 0, NotSerialized) { If (LGreaterEqual (OSFX, 0x03)) { If (HPTF) { Return (0x0F) } Else { Return (0x00) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { If (LGreaterEqual (OSFX, 0x03)) { If (HPTF) { Return (ATT3) } Else { Return (ATT4) } } Else { Return (ATT4) } } } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (ATT0, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {8} }) Name (ATT1, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x04, // Length ) }) Method (_CRS, 0, NotSerialized) { If (LGreaterEqual (OSFX, 0x03)) { If (HPTF) { Return (ATT1) } Else { Return (ATT0) } } Else { Return (ATT0) } } } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, // Range Minimum 0x0061, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) } Device (COPR) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, // Range Minimum 0x00F0, // Range Maximum 0x01, // Alignment 0x10, // Length ) IRQNoFlags () {13} }) } Scope (\) { OperationRegion (WIN1, SystemIO, 0x2E, 0x02) Field (WIN1, ByteAcc, NoLock, Preserve) { INDP, 8,=20 DATP, 8 } OperationRegion (GPIO, SystemIO, 0x0800, 0x05) Field (GPIO, ByteAcc, NoLock, Preserve) { GO01, 8,=20 GO02, 8,=20 GO03, 8,=20 GO04, 8,=20 GO05, 8 } IndexField (INDP, DATP, ByteAcc, NoLock, Preserve) { Offset (0x02),=20 CFG, 8,=20 Offset (0x07),=20 LDN, 8,=20 Offset (0x20),=20 IDHI, 8,=20 IDLO, 8,=20 POWC, 8,=20 Offset (0x30),=20 ACTR, 8,=20 Offset (0x60),=20 IOAH, 8,=20 IOAL, 8,=20 IO2H, 8,=20 IO2L, 8,=20 Offset (0x70),=20 INTR, 8,=20 Offset (0x72),=20 INT1, 8,=20 Offset (0x74),=20 DMCH, 8,=20 Offset (0xC0),=20 GP40, 8,=20 Offset (0xF0),=20 OPT1, 8,=20 OPT2, 8,=20 OPT3, 8,=20 OPT4, 8 } Method (ENFG, 0, NotSerialized) { Store (0x87, INDP) Store (0x01, INDP) Store (0x55, INDP) Store (0x55, INDP) } Method (EXFG, 0, NotSerialized) { Store (0x02, CFG) } Method (GSRG, 1, NotSerialized) { Store (Arg0, INDP) Return (DATP) } Method (SSRG, 2, NotSerialized) { Store (Arg0, INDP) Store (Arg1, DATP) } } Device (FDC0) { Name (_HID, EisaId ("PNP0700")) Method (_STA, 0, NotSerialized) { ENFG () Store (Zero, LDN) If (ACTR) { EXFG () Return (0x0F) } Else { If (LOr (IOAH, IOAL)) { EXFG () Return (0x0D) } Else { EXFG () Return (0x00) } } } Method (_DIS, 0, NotSerialized) { ENFG () Store (0x00, LDN) Store (Zero, ACTR) SLDM (DMCH, 0x04) EXFG () DISD (0x03) } Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length _Y01) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8, = ) {2} }) CreateByteField (BUF0, \_SB.PCI0.PX40.FDC0._CRS._= Y01._MIN, IOLO) CreateByteField (BUF0, 0x03, IOHI) CreateByteField (BUF0, \_SB.PCI0.PX40.FDC0._CRS._= Y01._MAX, IORL) CreateByteField (BUF0, 0x05, IORH) ENFG () EXFG () Return (BUF0) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8, = ) {2} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) CreateWordField (Arg0, 0x02, IOAD) CreateWordField (Arg0, 0x19, IRQW) CreateByteField (Arg0, 0x1C, DMAV) ENFG () Store (Zero, LDN) Store (One, ACTR) SLDM (DMCH, DMCH) CKIO (IOAD, 0x03) EXFG () } } Device (UAR1) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { ENFG () Store (0x01, LDN) If (ACTR) { EXFG () Return (0x0F) } Else { If (LOr (IOAH, IOAL)) { EXFG () Return (0x0D) } Else { EXFG () Return (0x00) } } EXFG () } Method (_DIS, 0, NotSerialized) { ENFG () Store (0x01, LDN) Store (Zero, ACTR) EXFG () DISD (0x00) } Method (_CRS, 0, NotSerialized) { Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x08, // Length _Y02) IRQNoFlags (_Y03) {} }) CreateByteField (BUF1, \_SB.PCI0.PX40.UAR1._CRS._= Y02._MIN, IOLO) CreateByteField (BUF1, 0x03, IOHI) CreateByteField (BUF1, \_SB.PCI0.PX40.UAR1._CRS._= Y02._MAX, IORL) CreateByteField (BUF1, 0x05, IORH) CreateWordField (BUF1, \_SB.PCI0.PX40.UAR1._CRS._= Y03._INT, IRQW) ENFG () Store (0x01, LDN) Store (IOAL, IOLO) Store (IOAL, IORL) Store (IOAH, IOHI) Store (IOAH, IORH) Store (One, Local0) ShiftLeft (Local0, INTR, IRQW) EXFG () Return (BUF1) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) CreateWordField (Arg0, 0x02, IOAD) CreateWordField (Arg0, 0x09, IRQW) ENFG () Store (0x01, LDN) Store (One, ACTR) Store (IOLO, IOAL) Store (IOHI, IOAH) FindSetRightBit (IRQW, Local0) Subtract (Local0, 0x01, INTR) EXFG () CKIO (IOAD, 0x00) } Method (_PRW, 0, NotSerialized) { If (SUSF) { Return (Package (0x02) { 0x08,=20 0x03 }) } Else { Return (Package (0x02) { 0x08,=20 0x01 }) } } Method (_PSW, 1, NotSerialized) { If (Arg0) { Or (G2C2, 0x01, G2C2) } Else { And (G2C2, 0xFE, G2C2) } } } Device (LPT1) { Name (_HID, EisaId ("PNP0400")) Method (_STA, 0, NotSerialized) { ENFG () Store (0x03, LDN) And (OPT1, 0x02, Local0) If (LNotEqual (Local0, 0x02)) { If (ACTR) { EXFG () Return (0x0F) } Else { If (LOr (IOAH, IOAL)) { EXFG () Return (0x0D) } Else { EXFG () Return (0x00) } } } Else { EXFG () Return (0x00) } } Method (_DIS, 0, NotSerialized) { ENFG () Store (0x03, LDN) Store (Zero, ACTR) EXFG () DISD (0x02) } Method (_CRS, 0, NotSerialized) { Name (BUF5, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x08, // Length _Y04) IRQNoFlags (_Y05) {} }) CreateByteField (BUF5, \_SB.PCI0.PX40.LPT1._CRS._= Y04._MIN, IOLO) CreateByteField (BUF5, 0x03, IOHI) CreateByteField (BUF5, \_SB.PCI0.PX40.LPT1._CRS._= Y04._MAX, IORL) CreateByteField (BUF5, 0x05, IORH) CreateByteField (BUF5, \_SB.PCI0.PX40.LPT1._CRS._= Y04._LEN, IOLE) CreateWordField (BUF5, \_SB.PCI0.PX40.LPT1._CRS._= Y05._INT, IRQW) ENFG () Store (0x03, LDN) Store (IOAL, IOLO) Store (IOLO, IORL) Store (IOAH, IOHI) Store (IOHI, IORH) If (LEqual (IOLO, 0xBC)) { Store (0x04, IOLE) } Else { Store (0x08, IOLE) } Store (One, Local0) Store (INTR, Local5) ShiftLeft (Local0, Local5, IRQW) EXFG () Return (BUF5) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) CreateWordField (Arg0, 0x02, IOAD) CreateByteField (Arg0, 0x04, IORL) CreateByteField (Arg0, 0x05, IORH) CreateWordField (Arg0, 0x09, IRQW) ENFG () Store (0x03, LDN) Store (One, ACTR) Store (IOLO, IOAL) Store (IOHI, IOAH) FindSetLeftBit (IRQW, Local0) Subtract (Local0, 0x01, Local0) Store (Local0, INTR) EXFG () CKIO (IOAD, 0x02) } } Device (ECP1) { Name (_HID, EisaId ("PNP0401")) Method (_STA, 0, NotSerialized) { ENFG () Store (0x03, LDN) And (OPT1, 0x02, Local0) If (LEqual (Local0, 0x02)) { If (ACTR) { EXFG () Return (0x0F) } Else { If (LOr (IOAH, IOAL)) { EXFG () Return (0x0D) } Else { EXFG () Return (0x00) } } } Else { EXFG () Return (0x00) } } Method (_DIS, 0, NotSerialized) { ENFG () Store (0x03, LDN) Store (Zero, ACTR) SLDM (DMCH, 0x04) EXFG () DISD (0x02) } Method (_CRS, 0, NotSerialized) { Name (BUF6, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x04, // Length _Y06) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x04, // Length _Y07) IRQNoFlags (_Y08) {} DMA (Compatibility, NotBusMaster, Transfer8, = _Y09) {} }) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y06._MIN, IOLO) CreateByteField (BUF6, 0x03, IOHI) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y06._MAX, IORL) CreateByteField (BUF6, 0x05, IORH) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y06._LEN, IOLE) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y07._MIN, IOEL) CreateByteField (BUF6, 0x0B, IOEH) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y07._MAX, IOML) CreateByteField (BUF6, 0x0D, IOMH) CreateWordField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y08._INT, IRQW) CreateByteField (BUF6, \_SB.PCI0.PX40.ECP1._CRS._= Y09._DMA, DMAC) ENFG () Store (0x03, LDN) Store (IOAL, Local2) Store (Local2, IOLO) Store (IOAH, Local3) Store (Local3, IOHI) Or (Local3, 0x04, Local3) Store (Local3, IOEH) Store (Local3, IOMH) Store (IOLO, IORL) Store (IOLO, IOEL) Store (IOLO, IOML) Store (IOHI, IORH) If (LEqual (IOLO, 0xBC)) { Store (0x04, IOLE) } Else { Store (0x08, IOLE) } Store (One, Local0) Store (INTR, Local5) ShiftLeft (Local0, Local5, IRQW) Store (One, Local0) Store (DMCH, Local5) ShiftLeft (Local0, Local5, DMAC) EXFG () Return (BUF6) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x00, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, = ) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x00, // Alignment 0x08, // Length ) IO (Decode16, 0x0678, // Range Minimum 0x0678, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, = ) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x00, // Alignment 0x04, // Length ) IO (Decode16, 0x07BC, // Range Minimum 0x07BC, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {3,4,5,7,9,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, = ) {0,1,3} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) CreateWordField (Arg0, 0x02, IOAD) CreateWordField (Arg0, 0x11, IRQW) CreateByteField (Arg0, 0x14, DMAC) ENFG () Store (0x03, LDN) Store (One, ACTR) Store (IOLO, IOAL) Store (IOHI, IOAH) FindSetLeftBit (IRQW, Local0) Subtract (Local0, 0x01, Local0) Store (Local0, INTR) FindSetLeftBit (DMAC, Local1) Store (DMCH, Local0) Subtract (Local1, 0x01, DMCH) SLDM (Local0, DMCH) EXFG () CKIO (IOAD, 0x02) } } OperationRegion (KBCT, SystemIO, 0x60, 0x05) Field (KBCT, ByteAcc, NoLock, Preserve) { P060, 8,=20 Offset (0x04),=20 P064, 8 } Device (PS2M) { Name (_HID, EisaId ("PNP0F13")) Method (_STA, 0, NotSerialized) { If (LEqual (PS2F, 0x00)) { Return (0x0F) } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { Name (BUF1, ResourceTemplate () { IRQNoFlags () {12} }) Name (BUF2, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {12} }) If (LEqual (KBDI, 0x01)) { If (LEqual (OSFL, 0x02)) { Return (BUF1) } If (LEqual (OSFL, 0x01)) { Return (BUF1) } Else { Return (BUF2) } } Else { Return (BUF1) } } } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Method (_STA, 0, NotSerialized) { If (LEqual (KBDI, 0x01)) { Return (0x00) } Else { Return (0x0F) } } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {1} }) } Device (PSMR) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { If (LEqual (KBDI, 0x00)) { Return (0x00) } If (LEqual (PS2F, 0x00)) { If (LEqual (OSFL, 0x02)) { Return (0x0F) } If (LEqual (OSFL, 0x01)) { Return (0x0F) } Return (0x00) } Return (0x00) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) } Device (PMIO) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x02) Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0400, // Range Minimum 0x0400, // Range Maximum 0x01, // Alignment 0xC0, // Length ) }) Return (BUF0) } } } Device (USB0) { Name (_ADR, 0x001D0000) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x03,=20 0x03 }) } Device (USB1) { Name (_ADR, 0x001D0001) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x04,=20 0x03 }) } Device (USB2) { Name (_ADR, 0x001D0002) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x0C,=20 0x03 }) } Device (USB3) { Name (_ADR, 0x001D0003) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x0E,=20 0x03 }) } Device (US31) { Name (_ADR, 0x001A0000) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x0E,=20 0x03 }) } Device (USB4) { Name (_ADR, 0x001A0001) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x05,=20 0x03 }) } Device (USB5) { Name (_ADR, 0x001A0002) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x20,=20 0x03 }) } Device (USBE) { Name (_ADR, 0x001D0007) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x0D,=20 0x03 }) } Device (USE2) { Name (_ADR, 0x001A0007) Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Return (0x03) } Name (_PRW, Package (0x02) { 0x0D,=20 0x03 }) } Device (IDE1) { Name (_ADR, 0x001F0002) OperationRegion (PCI, PCI_Config, 0x40, 0x20) Field (PCI, DWordAcc, NoLock, Preserve) { ITM0, 16,=20 ITM1, 16,=20 SIT0, 4,=20 SIT1, 4,=20 Offset (0x08),=20 UDC0, 2,=20 UDC1, 2,=20 Offset (0x0A),=20 UDT0, 8,=20 UDT1, 8,=20 Offset (0x14),=20 ICF0, 2,=20 ICF1, 2,=20 , 6,=20 WPPE, 1,=20 , 1,=20 FAS0, 2,=20 FAS1, 2 } Device (PRIM) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store (GTM (ITM0, SIT0, UDC0, UDT0, ICF0, FAS0), = Local0) Return (Local0) } Method (_STM, 3, NotSerialized) { Store (STM (Arg0, Arg1, Arg2), Local0) CreateDWordField (Local0, 0x00, ITM) CreateDWordField (Local0, 0x04, SIT) CreateDWordField (Local0, 0x08, UDC) CreateDWordField (Local0, 0x0C, UDT) CreateDWordField (Local0, 0x10, ICF) CreateDWordField (Local0, 0x14, FAS) Store (UDC, UDC0) Store (UDT, UDT0) Store (ICF, ICF0) Store (FAS, FAS0) } Device (DRV0) { Name (_ADR, 0x00) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF0 (ITM0, SIT0, UDC0, UDT0, ICF0, H1= 5F, FAS0), Local0) Return (Local0) } } Device (DRV1) { Name (_ADR, 0x01) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF1 (ITM0, SIT0, UDC0, UDT0, ICF0, H1= 5F, FAS0), Local0) Return (Local0) } } } Device (SECD) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store (GTM (ITM1, SIT1, UDC1, UDT1, ICF1, FAS1), = Local0) Return (Local0) } Method (_STM, 3, NotSerialized) { Store (STM (Arg0, Arg1, Arg2), Local0) CreateDWordField (Local0, 0x00, ITM) CreateDWordField (Local0, 0x04, SIT) CreateDWordField (Local0, 0x08, UDC) CreateDWordField (Local0, 0x0C, UDT) CreateDWordField (Local0, 0x10, ICF) CreateDWordField (Local0, 0x14, FAS) Store (UDC, UDC1) Store (UDT, UDT1) Store (ICF, ICF1) Store (FAS, FAS1) } Device (DRV0) { Name (_ADR, 0x00) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF0 (ITM1, SIT1, UDC1, UDT1, ICF1, H1= 5F, FAS1), Local0) Return (Local0) } } Device (DRV1) { Name (_ADR, 0x01) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF1 (ITM1, SIT1, UDC1, UDT1, ICF1, H1= 5F, FAS1), Local0) Return (Local0) } } } } Device (IDE2) { Name (_ADR, 0x001F0005) OperationRegion (PCI, PCI_Config, 0x40, 0x20) Field (PCI, DWordAcc, NoLock, Preserve) { ITM0, 16,=20 ITM1, 16,=20 SIT0, 4,=20 SIT1, 4,=20 Offset (0x08),=20 UDC0, 1,=20 , 1,=20 UDC1, 1,=20 Offset (0x0A),=20 UDT0, 8,=20 UDT1, 8,=20 Offset (0x14),=20 ICF0, 2,=20 ICF1, 2,=20 , 6,=20 WPPE, 1,=20 , 1,=20 FAS0, 2,=20 FAS1, 2 } Device (PRIM) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store (GTM (ITM0, SIT0, UDC0, UDT0, ICF0, FAS0), = Local0) Return (Local0) } Method (_STM, 3, NotSerialized) { Store (STM (Arg0, Arg1, Arg2), Local0) CreateDWordField (Local0, 0x00, ITM) CreateDWordField (Local0, 0x04, SIT) CreateDWordField (Local0, 0x08, UDC) CreateDWordField (Local0, 0x0C, UDT) CreateDWordField (Local0, 0x10, ICF) CreateDWordField (Local0, 0x14, FAS) Store (UDC, UDC0) Store (UDT, UDT0) Store (ICF, ICF0) Store (FAS, FAS0) } Device (DRV0) { Name (_ADR, 0x00) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF0 (ITM0, SIT0, UDC0, UDT0, ICF0, H1= 5F, FAS0), Local0) Return (Local0) } } Device (DRV1) { Name (_ADR, 0x01) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF1 (ITM0, SIT0, UDC0, UDT0, ICF0, H1= 5F, FAS0), Local0) Return (Local0) } } } Device (SECD) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store (GTM (ITM1, SIT1, UDC1, UDT1, ICF1, FAS1), = Local0) Return (Local0) } Method (_STM, 3, NotSerialized) { Store (STM (Arg0, Arg1, Arg2), Local0) CreateDWordField (Local0, 0x00, ITM) CreateDWordField (Local0, 0x04, SIT) CreateDWordField (Local0, 0x08, UDC) CreateDWordField (Local0, 0x0C, UDT) CreateDWordField (Local0, 0x10, ICF) CreateDWordField (Local0, 0x14, FAS) Store (UDC, UDC1) Store (UDT, UDT1) Store (ICF, ICF1) Store (FAS, FAS1) } Device (DRV0) { Name (_ADR, 0x00) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF0 (ITM1, SIT1, UDC1, UDT1, ICF1, H1= 5F, FAS1), Local0) Return (Local0) } } Device (DRV1) { Name (_ADR, 0x01) Name (H15F, Zero) Method (_GTF, 0, NotSerialized) { Store (GTF1 (ITM1, SIT1, UDC1, UDT1, ICF1, H1= 5F, FAS1), Local0) Return (Local0) } } } } Method (GTM, 6, NotSerialized) { Store (Buffer (0x14) {}, Local0) CreateDWordField (Local0, 0x00, PIO0) CreateDWordField (Local0, 0x04, DMA0) CreateDWordField (Local0, 0x08, PIO1) CreateDWordField (Local0, 0x0C, DMA1) CreateDWordField (Local0, 0x10, FLAG) Store (0x10, FLAG) If (LOr (And (Arg0, 0x08), LNot (And (Arg0, 0x01 )))) { Store (0x0384, PIO0) } Else { Add (ShiftRight (And (Arg0, 0x0300), 0x08), ShiftRigh= t (And ( Arg0, 0x3000), 0x0C), Local1) Multiply (Subtract (0x09, Local1), 0x1E, PIO0) } If (LOr (LAnd (Arg0, 0x4000), LAnd (Arg2, 0x01))) { If (LOr (And (Arg0, 0x80), LNot (And (Arg0, 0x10 )))) { Store (0x0384, PIO1) } Else { Add (And (Arg1, 0x03), ShiftRight (And (Arg1, 0x0= C),=20 0x02), Local1) Multiply (Subtract (0x09, Local1), 0x1E, PIO1) } } Else { Store (PIO0, PIO1) } If (And (Arg2, 0x01)) { Subtract (0x04, And (Arg3, 0x03), Local1) If (And (Arg5, 0x01)) { Store (0x14, DMA0) } Else { If (And (Arg4, 0x01)) { Multiply (Local1, 0x0F, DMA0) } Else { Multiply (Local1, 0x1E, DMA0) } } } Else { Store (PIO0, DMA0) } If (LOr (LAnd (Arg0, 0x4000), LAnd (Arg2, 0x01))) { If (And (Arg2, 0x02)) { Subtract (0x04, ShiftRight (And (Arg3, 0x30), 0x0= 4), Local1) If (And (Arg5, 0x02)) { Store (0x14, DMA1) } Else { If (And (Arg4, 0x02)) { Multiply (Local1, 0x0F, DMA1) } Else { Multiply (Local1, 0x1E, DMA1) } } } Else { Store (PIO1, DMA1) } } Else { Store (DMA0, DMA1) } Store (Zero, FLAG) If (And (Arg0, 0x01)) { Or (FLAG, 0x10, FLAG) } If (And (Arg2, 0x01)) { Or (FLAG, 0x01, FLAG) } If (And (Arg0, 0x02)) { Or (FLAG, 0x02, FLAG) } If (And (Arg2, 0x02)) { Or (FLAG, 0x04, FLAG) } If (And (Arg0, 0x20)) { Or (FLAG, 0x08, FLAG) } Return (Local0) } Method (STM, 3, NotSerialized) { Store (Buffer (0x18) {}, Local7) CreateDWordField (Local7, 0x00, ITM) CreateDWordField (Local7, 0x04, SIT) CreateDWordField (Local7, 0x08, UDC) CreateDWordField (Local7, 0x0C, UDT) CreateDWordField (Local7, 0x10, ICF) CreateDWordField (Local7, 0x14, FAS) CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (FLAG, Local4) Store (0x8000, Local0) If (And (Local4, 0x02)) { Or (Local0, 0x07, Local0) } If (And (Local4, 0x08)) { Or (Local0, 0x4000, Local0) Or (Local0, 0x70, Local0) } If (LAnd (LLess (DMA0, PIO0), LNot (And (Local4, 0x01))))= { Or (Local0, 0x08, Local0) } If (LAnd (LLess (DMA1, PIO1), LNot (And (Local4, 0x04))))= { Or (Local0, 0x80, Local0) } If (PIO0) { If (LLess (PIO0, 0x0384)) { Or (Local0, 0x01, Local0) } } If (PIO1) { If (LLess (PIO1, 0x0384)) { Or (Local0, 0x10, Local0) } } If (And (Local4, 0x01)) { Store (PIO0, Local1) } Else { Store (DMA0, Local1) } If (Local1) { If (LLessEqual (Local1, 0x78)) { Or (Local0, 0x2300, Local0) } Else { If (LLessEqual (Local1, 0xB4)) { Or (Local0, 0x2100, Local0) } Else { If (LLessEqual (Local1, 0xF0)) { Or (Local0, 0x1000, Local0) } } } } Store (Local0, ITM) Store (Zero, Local0) If (And (Local4, 0x04)) { Store (PIO1, Local1) } Else { Store (DMA1, Local1) } If (Local1) { If (LLessEqual (Local1, 0x78)) { Store (0x0B, Local0) } Else { If (LLessEqual (Local1, 0xB4)) { Store (0x09, Local0) } Else { If (LLessEqual (Local1, 0xF0)) { Store (0x04, Local0) } } } } Store (Local0, SIT) Store (0x00, Local0) If (And (Local4, 0x01)) { Or (Local0, 0x01, Local0) } If (And (Local4, 0x04)) { Or (Local0, 0x02, Local0) } Store (Local0, UDC) Store (0x00, Local0) If (And (Local4, 0x01)) { If (LEqual (DMA0, 0x14)) { Store (0x01, Local0) } Else { If (LLess (DMA0, 0x3C)) { Divide (DMA0, 0x0F, , Local1) } Else { Divide (DMA0, 0x1E, , Local1) } Subtract (0x04, Local1, Local0) } } If (And (Local4, 0x04)) { If (LEqual (DMA1, 0x14)) { Store (0x01, Local1) } Else { If (LLess (DMA1, 0x3C)) { Divide (DMA1, 0x0F, , Local1) } Else { Divide (DMA1, 0x1E, , Local1) } Subtract (0x04, Local1, Local1) } ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) } Store (Local0, UDT) Store (0x00, Local0) If (DMA0) { If (LGreater (DMA0, 0x14)) { If (LLess (DMA0, 0x3C)) { Or (Local0, 0x01, Local0) } } } If (DMA1) { If (LGreater (DMA1, 0x14)) { If (LLess (DMA1, 0x3C)) { Or (Local0, 0x02, Local0) } } } Store (Local0, ICF) Store (0x00, Local0) If (LEqual (DMA0, 0x14)) { Or (Local0, 0x01, Local0) } If (LEqual (DMA1, 0x14)) { Or (Local0, 0x02, Local0) } Store (Local0, FAS) Return (Local7) } Method (H15P, 1, NotSerialized) { Name (BUFF, Buffer (0x08) { /* 0000 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0= 0, 0x00 }) Store (Arg0, Local0) Store (BUFF, Local1) Concatenate (Local0, Local1, Local7) CreateWordField (Local7, 0x02, CYL) CreateWordField (Local7, 0x06, HEAD) CreateWordField (Local7, 0x0C, SPT) If (LAnd (LGreaterEqual (HEAD, 0x10), LGreaterEqual (CYL,= 0x2000))) { Return (SPT) } Else { Return (Zero) } } Method (GTF0, 7, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local7) CreateByteField (Local7, 0x01, MODE) If (And (Arg2, 0x01)) { And (Arg3, 0x03, Local0) If (And (Arg6, 0x01)) { Add (Local0, 0x04, Local0) } Else { If (And (Arg4, 0x01)) { Add (Local0, 0x02, Local0) } } Or (Local0, 0x40, MODE) } Else { Add (ShiftRight (And (Arg0, 0x0300), 0x08), ShiftRigh= t (And ( Arg0, 0x3000), 0x0C), Local0) If (LGreaterEqual (Local0, 0x05)) { Store (0x22, MODE) } Else { If (LGreaterEqual (Local0, 0x03)) { Store (0x21, MODE) } Else { Store (0x20, MODE) } } } Concatenate (Local7, Local7, Local6) If (LOr (And (Arg0, 0x08), LNot (And (Arg0, 0x01 )))) { If (And (Arg0, 0x02)) { Store (0x00, MODE) } Else { Store (0x01, MODE) } } Else { Add (ShiftRight (And (Arg0, 0x0300), 0x08), ShiftRigh= t (And ( Arg0, 0x3000), 0x0C), Local0) If (LGreaterEqual (Local0, 0x05)) { Store (0x0C, MODE) } Else { If (LGreaterEqual (Local0, 0x03)) { Store (0x0B, MODE) } Else { Store (0x0A, MODE) } } } Concatenate (Local6, Local7, Local5) If (Arg5) { Store (Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0xAE, 0x91 }, Local4) CreateByteField (Local4, 0x01, SPT) Store (Arg5, SPT) Concatenate (Local5, Local4, Local6) Return (Local6) } Else { Return (Local5) } } Method (GTF1, 7, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }, Local7) CreateByteField (Local7, 0x01, MODE) If (And (Arg2, 0x02)) { ShiftRight (And (Arg3, 0x30), 0x04, Local0) If (And (Arg6, 0x02)) { Add (Local0, 0x04, Local0) } Else { If (And (Arg4, 0x02)) { Add (Local0, 0x02, Local0) } } Or (Local0, 0x40, MODE) } Else { Add (ShiftRight (And (Arg1, 0x03), 0x02), And (Arg1, = 0x0C), Local0) If (LGreaterEqual (Local0, 0x05)) { Store (0x22, MODE) } Else { If (LGreaterEqual (Local0, 0x03)) { Store (0x21, MODE) } Else { Store (0x20, MODE) } } } Concatenate (Local7, Local7, Local6) If (LOr (And (Arg0, 0x80), LNot (And (Arg0, 0x10 )))) { If (And (Arg0, 0x20)) { Store (0x00, MODE) } Else { Store (0x01, MODE) } } Else { Add (ShiftRight (And (Arg1, 0x03), 0x02), And (Arg1, = 0x0C), Local0) If (LGreaterEqual (Local0, 0x05)) { Store (0x0C, MODE) } Else { If (LGreaterEqual (Local0, 0x03)) { Store (0x0B, MODE) } Else { Store (0x0A, MODE) } } } Concatenate (Local6, Local7, Local5) If (Arg5) { Store (Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0xBE, 0x91 }, Local4) CreateByteField (Local4, 0x01, SPT) Store (Arg5, SPT) Concatenate (Local5, Local4, Local6) Return (Local6) } Else { Return (Local5) } } Device (PX43) { Name (_ADR, 0x001F0003) OperationRegion (PBAS, PCI_Config, 0x20, 0x02) Field (PBAS, ByteAcc, NoLock, Preserve) { BAS0, 16 } Method (SMBB, 0, NotSerialized) { And (BAS0, 0xFFFE, Local0) Return (Local0) } } Device (AZAL) { Name (_ADR, 0x001B0000) Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0D,=20 0x05 }) } } Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,6,7,9,10,11,12,14,15} }) Name (BUFB, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, _Y0A) {} }) CreateWordField (BUFB, \_SB.PCI0._Y0A._INT, IRQV) Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { And (PIRA, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRA, 0x80, PIRA) } Method (_CRS, 0, NotSerialized) { And (PIRA, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { And (PIRB, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRB, 0x80, PIRB) } Method (_CRS, 0, NotSerialized) { And (PIRB, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { And (PIRC, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRC, 0x80, PIRC) } Method (_CRS, 0, NotSerialized) { And (PIRC, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { And (PIRD, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRD, 0x80, PIRD) } Method (_CRS, 0, NotSerialized) { And (PIRD, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRD) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { And (PIRE, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRE, 0x80, PIRE) } Method (_CRS, 0, NotSerialized) { And (PIRE, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRE) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_STA, 0, NotSerialized) { And (PIRF, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRF, 0x80, PIRF) } Method (_CRS, 0, NotSerialized) { And (PIRF, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRF) } } Device (LNK0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { And (PIRG, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRG, 0x80, PIRG) } Method (_CRS, 0, NotSerialized) { And (PIRG, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRG) } } Device (LNK1) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { And (PIRH, 0x80, Local0) If (LEqual (Local0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (BUFA) } Method (_DIS, 0, NotSerialized) { Or (PIRH, 0x80, PIRH) } Method (_CRS, 0, NotSerialized) { And (PIRH, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQV) Return (BUFB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ1) FindSetRightBit (IRQ1, Local0) Decrement (Local0) Store (Local0, PIRH) } } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0B,=20 0x05 }) } } Device (MEM) { Name (_HID, EisaId ("PNP0C01")) Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x000F0000, // Address Base 0x00004000, // Address Length _Y0C) Memory32Fixed (ReadWrite, 0x000F4000, // Address Base 0x00004000, // Address Length _Y0D) Memory32Fixed (ReadWrite, 0x000F8000, // Address Base 0x00004000, // Address Length _Y0E) Memory32Fixed (ReadWrite, 0x000FC000, // Address Base 0x00004000, // Address Length _Y0F) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00010000, // Address Length _Y0B) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x000A0000, // Address Length ) Memory32Fixed (ReadWrite, 0x00100000, // Address Base 0x00000000, // Address Length _Y11) Memory32Fixed (ReadWrite, 0xFEC00000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED10000, // Address Base 0x0000E000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED20000, // Address Base 0x00070000, // Address Length ) Memory32Fixed (ReadWrite, 0xFEE00000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFFB00000, // Address Base 0x00080000, // Address Length ) Memory32Fixed (ReadWrite, 0xFFF00000, // Address Base 0x00100000, // Address Length ) Memory32Fixed (ReadWrite, 0x000E0000, // Address Base 0x00010000, // Address Length _Y10) }) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0B._BAS, ACMM) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0B._LEN, ASSM) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0C._BAS, RMA1) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0C._LEN, RSS1) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0D._BAS, RMA2) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0D._LEN, RSS2) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0E._BAS, RMA3) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0E._LEN, RSS3) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0F._BAS, RMA4) CreateDWordField (BUF0, \_SB.MEM._CRS._Y0F._LEN, RSS4) CreateDWordField (BUF0, \_SB.MEM._CRS._Y10._BAS, ERMA) CreateDWordField (BUF0, \_SB.MEM._CRS._Y10._LEN, ERMS) CreateDWordField (BUF0, \_SB.MEM._CRS._Y11._LEN, EXTM) Subtract (AMEM, 0x00100000, EXTM) If (LNotEqual (ROM1, Zero)) { Store (RMA1, RMA2) ShiftLeft (ROM1, 0x08, Local0) Store (Local0, RMA1) ShiftLeft (RMS1, 0x08, Local0) Store (Local0, RSS1) Store (0x8000, RSS2) } If (LNotEqual (ROM2, Zero)) { Store (RMA2, RMA3) ShiftLeft (ROM2, 0x08, Local0) Store (Local0, RMA2) ShiftLeft (RMS2, 0x08, Local0) Store (Local0, RSS2) Store (0xC000, RSS3) } If (LNotEqual (ROM3, Zero)) { Store (RMA3, RMA4) ShiftLeft (ROM3, 0x08, Local0) Store (Local0, RMA3) ShiftLeft (RMS3, 0x08, Local0) Store (Local0, RSS3) Store (0x00010000, RSS4) } Store (ERMA, Local1) If (LGreater (RMA1, 0x000D0000)) { If (LLess (RMA1, 0x000F0000)) { Add (RMA1, RSS1, Local0) If (LGreater (Local0, 0x000E0000)) { If (LGreater (Local0, Local1)) { Store (Local0, Local1) } } } } If (LGreater (RMA2, 0x000D0000)) { If (LLess (RMA2, 0x000F0000)) { Add (RMA2, RSS2, Local0) If (LGreater (Local0, 0x000E0000)) { If (LGreater (Local0, Local1)) { Store (Local0, Local1) } } } } If (LGreater (RMA3, 0x000D0000)) { If (LLess (RMA3, 0x000F0000)) { Add (RMA3, RSS3, Local0) If (LGreater (Local0, 0x000E0000)) { If (LGreater (Local0, Local1)) { Store (Local0, Local1) } } } } If (LGreater (Local1, ERMA)) { Subtract (Local1, ERMA, Local0) If (LLessEqual (Local0, 0x00010000)) { Store (Local1, ERMA) Subtract (0x00010000, Local0, ERMS) } } Store (AMEM, ACMM) And (AMEM, 0x000FFFFF, Local0) Subtract (0x00100000, Local0, ASSM) Return (BUF0) } } Device (FWH) { Name (_HID, EisaId ("INT0800")) Method (_CRS, 0, NotSerialized) { Name (FWH0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFFB80000, // Address Base 0x00080000, // Address Length ) }) Return (FWH0) } } Device (\_SB.PCI0.EXPL) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x04) Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xF0000000, // Address Base 0x04000000, // Address Length ) }) Return (BUF0) } } } Scope (\) { Name (SSDT, Package (0x18) { "CPU0IST ",=20 0x7FEE7F00,=20 0x0000022A,=20 "CPU1IST ",=20 0x7FEE83C0,=20 0x00000152,=20 "CPU0CST ",=20 0x00000000,=20 0xF000E816,=20 "CPU1CST ",=20 0x00000000,=20 0xF000E816,=20 "CPU2IST ",=20 0x00000000,=20 0xF000E816,=20 "CPU3IST ",=20 0x00000000,=20 0xF000E816,=20 "CPU2CST ",=20 0x00000000,=20 0xF000E816,=20 "CPU3CST ",=20 0x00000000,=20 0xF000E816 }) Name (CFGD, 0x02030302) Name (\PDC0, 0x80000000) Name (\PDC1, 0x80000000) Name (\PDC2, 0x80000000) Name (\PDC3, 0x80000000) } Scope (\_PR.CPU0) { Name (HI0, 0x00) Name (HC0, 0x00) Name (TLD0, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP0) Store (CAP0, PDC0) If (LEqual (TLD0, 0x00)) { If (LEqual (And (PDC0, 0x0A), 0x0A)) { If (And (CFGD, 0x02)) { OperationRegion (IST0, SystemMemory, DerefOf (Ind= ex (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02 ))) Load (IST0, HI0) } Store (0x01, TLD0) } } } } Scope (\_PR.CPU1) { Name (HI1, 0x00) Name (HC1, 0x00) Name (TLD1, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP1) Store (CAP1, PDC1) If (LEqual (TLD1, 0x00)) { If (LEqual (And (PDC1, 0x0A), 0x0A)) { If (And (CFGD, 0x02)) { OperationRegion (IST1, SystemMemory, DerefOf (Ind= ex (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05 ))) Load (IST1, HI1) } If (And (CFGD, 0x10)) { OperationRegion (CST1, SystemMemory, DerefOf (Ind= ex (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B ))) Load (CST1, HC1) } Store (0x01, TLD1) } } } } Scope (\_PR.CPU2) { Name (HI2, 0x00) Name (HC2, 0x00) Name (TLD2, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP2) Store (CAP2, PDC2) If (LEqual (TLD2, 0x00)) { If (LEqual (And (PDC2, 0x0A), 0x0A)) { If (And (CFGD, 0x02)) { OperationRegion (IST2, SystemMemory, DerefOf (Ind= ex (SSDT, 0x0D)), DerefOf (Index (SSDT, 0x0E ))) Load (IST2, HI2) } If (And (CFGD, 0x10)) { OperationRegion (CST2, SystemMemory, DerefOf (Ind= ex (SSDT, 0x13)), DerefOf (Index (SSDT, 0x14 ))) Load (CST2, HC2) } Store (0x01, TLD2) } } } } Scope (\_PR.CPU3) { Name (HI3, 0x00) Name (HC3, 0x00) Name (TLD3, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP3) Store (CAP3, PDC3) If (LEqual (TLD3, 0x00)) { If (LEqual (And (PDC3, 0x0A), 0x0A)) { If (And (CFGD, 0x02)) { OperationRegion (IST3, SystemMemory, DerefOf (Ind= ex (SSDT, 0x10)), DerefOf (Index (SSDT, 0x11 ))) Load (IST3, HI3) } If (And (CFGD, 0x10)) { OperationRegion (CST3, SystemMemory, DerefOf (Ind= ex (SSDT, 0x16)), DerefOf (Index (SSDT, 0x17 ))) Load (CST3, HC3) } Store (0x01, TLD3) } } } } } --------------010806050506050006050103 Content-Type: text/plain; name="sysctl-dev-cpu_with_p4tcc_disabled" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="sysctl-dev-cpu_with_p4tcc_disabled" dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 49 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 37 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us --------------010806050506050006050103 Content-Type: text/plain; name="est.dmesg" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="est.dmesg" cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a092006000920 device_attach: est0 attach returned 6 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a092006000920 device_attach: est1 attach returned 6 pmtimer0 on isa0 --------------010806050506050006050103-- --------------enig2FD014DA11C8CB65CA102E58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoT/F0ACgkQLDqVQ9VXb8js4wCfao56D6kbB5DmcPoPVTK1TfEf IaQAnRf9y319Z88HaKqtoyQOuz7+jVtu =pqlA -----END PGP SIGNATURE----- --------------enig2FD014DA11C8CB65CA102E58-- From owner-freebsd-current@FreeBSD.ORG Wed May 20 16:35:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA16A106564A for ; Wed, 20 May 2009 16:35:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5B38FC0A for ; Wed, 20 May 2009 16:35:43 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by ewy3 with SMTP id 3so638893ewy.43 for ; Wed, 20 May 2009 09:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZZ5sfd1xfE75mAPabMzTjsdoLX/Z6yWVEIPOelKfWtc=; b=tsla3ExQItQk59qW8E4t5Ljrv7a2Q5LWKOUkLNjUdJCd3ZPeqTemSFut+86eEiVXcX /8CGK9fewUvk7CkiYlvduT/BS/2BWH+R8ZMQxDo7haothY46Jpaz+/itH2wL4yC0tHPV JOQhy+GifA8rGPHTXXeW3iiUomOHxEZMOpNJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JChY2SWjdHFSHVT4IFqAd2Q7Q39zjWN6xWgKGpxcXCQF7LdvlnZS96afizamgrKF2Y ENNY+U5G77w6bb4xvNYmngpEV5kf5mBIaW9HVtZSM94Fuufnapi5lLgJ92XV6xyrdwfF A91wnWSDr2RbQpfc7K4JIFcU33QL8Cpzd2qkk= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr7749542ebc.83.1242837342931; Wed, 20 May 2009 09:35:42 -0700 (PDT) In-Reply-To: <1902762373.20090520090303@endersys.com> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> <200905191616.07296.subbsd@gmail.com> <20090519135240.GH71804@bsdcrew.de> <611494930.20090519211959@endersys.com> <1902762373.20090520090303@endersys.com> Date: Wed, 20 May 2009 12:35:42 -0400 Message-ID: From: Ryan Stone To: Ismail YENIGUL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Martin Wilke Subject: Re: Re[3]: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:35:45 -0000 unexpected relocation type 10 is the error that you'll get if you try to load a kernel module with debug symbols into an amd64 kernel. You have to load a stripped kernel module. Ryan Stone From owner-freebsd-current@FreeBSD.ORG Wed May 20 16:36:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A4B5106564A for ; Wed, 20 May 2009 16:36:38 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 715778FC0A for ; Wed, 20 May 2009 16:36:38 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6omR-00057A-06; Wed, 20 May 2009 16:36:35 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C072C1801F30; Wed, 20 May 2009 09:36:34 -0700 (PDT) Date: Wed, 20 May 2009 09:36:34 -0700 Message-ID: From: Randy Bush To: Vincent Hoffman In-Reply-To: <4A13C812.5070206@unsane.co.uk> References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> <20090519190648.GD1050@camelot.theinternet.com.au> <4A13C812.5070206@unsane.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:36:38 -0000 > Try using > gpart destroy -i X da4 > where X is the partition index as seen from gpart show > or possibly > gpart destroy da4 > I think your problem is that gpt keeps a secondary header at the end of > the disk > http://en.wikipedia.org/wiki/GUID_Partition_Table i had to remake and then dedlete and then destroy, but it seems to have worked. thank you! randy From owner-freebsd-current@FreeBSD.ORG Wed May 20 16:51:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD73106564A for ; Wed, 20 May 2009 16:51:26 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: from hisar.endersys.com (hisar.endersys.com [213.144.99.107]) by mx1.freebsd.org (Postfix) with ESMTP id 606CF8FC1E for ; Wed, 20 May 2009 16:51:25 +0000 (UTC) (envelope-from ismail.yenigul@endersys.com) Received: (surgate 60053 invoked by uid 1001); 20 May 2009 16:46:34 -0000 Received: from unknown (HELO 202.ofis.endersys.com.tr) (ismail.yenigul@endersys.com@127.0.0.1) by 0 with ESMTPA; 20 May 2009 16:46:34 -0000 Date: Wed, 20 May 2009 19:51:19 +0300 From: Ismail YENIGUL Organization: =?utf-8?B?RW5kZXJzeXMgRGFuxLHFn21hbmzEsWsgdmUgWWF6xLFsxLFtIEx0ZC4=?= X-Priority: 3 (Normal) Message-ID: <1567498652.20090520195119@endersys.com> To: Ryan Stone In-Reply-To: References: <20090514191237.GD70242@bsdcrew.de><20090517180920.GY71804@bsdcrew.de><20090519091310.GB71804@bsdcrew.de><200905191616.07296.subbsd@gmail.com><20090519135240.GH71804@bsdcrew.de><611494930.20090519211959@endersys.com><1902762373.20090520090303@endersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Martin Wilke Subject: Re[5]: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ismail YENIGUL List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:51:26 -0000 Hello Ryan, Thanks for the info.=20 Anyway, I would like to test virtualbox and give feedback. FreeBSD crashes, when I start a guest operating system. Thanks. Wednesday, May 20, 2009, 7:35:42 PM, you wrote: > unexpected relocation type 10 is the error that you'll get if you try to > load a kernel module with debug symbols into an amd64 kernel. You have to > load a stripped kernel module. > Ryan Stone > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" --=20 Ismail YENIGUL Endersys Ltd. Genel Koordinat=F6r / General Coordinator Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 Fax :+90 216-4709508 | web: http://www.endersys.com.tr Endersys blog a=E7?ld?. http://blog.endersys.com From owner-freebsd-current@FreeBSD.ORG Wed May 20 18:05:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59AC5106568A for ; Wed, 20 May 2009 18:05:33 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 109858FC1B for ; Wed, 20 May 2009 18:05:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M6qAT-0001Mv-Hd for freebsd-current@freebsd.org; Wed, 20 May 2009 18:05:29 +0000 Received: from 200.41.broadband11.iol.cz ([90.178.41.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 May 2009 18:05:29 +0000 Received: from gamato by 200.41.broadband11.iol.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 May 2009 18:05:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: martinko Date: Wed, 20 May 2009 20:05:13 +0200 Lines: 46 Message-ID: References: <4A08A132.3070503@users.sf.net> <20090511224957.GB52703@dan.emsphone.com> <4A09DCF3.3010600@users.sf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 200.41.broadband11.iol.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.18) Gecko/20081125 SeaMonkey/1.1.13 In-Reply-To: <4A09DCF3.3010600@users.sf.net> Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:05:33 -0000 Hallo, I'm adding current@ to this communication as I've tried the latest snapshot and it failed the same way. Well, actually I've already tried versions 5, 6, 7, 8 and none of them finished booting on this motherboard. Is there a way to fix this issue please ? Cheers, Martin martinko wrote: > Dan Nelson wrote: >> In the last episode (May 12), martinko said: >>> I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and >>> booting got stuck with the following: >>> >>> run_interrupt_driven_hooks: still waiting after 300 seconds for >>> xpt_config >>> >>> From what I've found via Google it should be fixed already but >>> apparently >>> it is not. :-( >>> >>> Is there a way to work around this issue and successfully boot and >>> install >>> FreeBSD, please ? >> >> Do you have a connected firewire device? Try unplugging it during >> bootup, >> or kldload the sbp module after bootup instead of via loader.conf. >> > > This is booting on fresh new computer from DVD installation media. > And nothing is attached (except USB keyboard and VGA monitor;)). > > Btw, I've just tried booting recent PC-BSD (7.1) from USB drive but it > failed the same way, unfortunately. > > Any other ideas how to install FreeBSD on this system, please ? > > Cheers, > > Martin > From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:06:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C191065771; Wed, 20 May 2009 20:06:06 +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 305228FC1D; Wed, 20 May 2009 20:06:06 +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 ESMTPS id DDE6146B86; Wed, 20 May 2009 16:06:05 -0400 (EDT) Date: Wed, 20 May 2009 21:06:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4A1460A3.2010202@freebsd.org> Message-ID: References: <4A1460A3.2010202@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@uoguelph.ca, freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:06:06 -0000 On Wed, 20 May 2009, Andre Oppermann wrote: > While working on an optimized soreceive_stream() function [1] and checking > the code how it is used I've come across quite a bit of code duplication in > the various NFS directories. > > Socket (read) operations are handled multiple times in a very similar manner > in these places: My recommendation would be to do this analysis against the new NFS client and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, which is the NFSv234 implementation. Note in particular that in the new world order there's a centralize RPC implementation. The code you're looking at is a blend of the old NFSv23 client/server (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if which are on a gradual de-orbit burn. Robert N M Watson Computer Laboratory University of Cambridge > > sys/rpc > sys/nfsclient > sys/nfsserver > > Also how the soreceive call is used is interesting. It certainly can be made > more efficient overall. > > My questions/observations/suggestions are as follows: > > a) Can the socket handling code be unified in one place for all NFS? > > b) The socket upcall mechanism is done per packet and can get expensive > for fast networks. It also has some additional unlock/lock overhead > plus that is delays protocol processing (even more so with netisr > direct dispatch where the code is run from an ithread). > > c) Can NFS be made to use a select() mechanism where it gets notified > when new data arrives? Just like in userspace. > > d) If not, it may be beneficial to have a taskqueue handle the upcall and > have the soappend call return immediately to complete processing of > the the protocol. > > e) The socket buffer is most efficient when it can aggregate a number of > packets together before they are processed. Can the NFS code set a low > water mark on the socket to get called only after a few packets have > arrived instead of each one? (In the select and taskqueue model.) > > f) I've been thinking of an modular socket filter approach (much like the > accept filter) scanning for upper layer specific markers or boundaries > and then signalling data availability. > > -- > Andre > > [1] Perforce: > //depot/user/andre/soreceive_stream/kern/uipc_socket.c::soreceive_stream() > From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:15:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A18106566B for ; Wed, 20 May 2009 20:15:19 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id EDC138FC25 for ; Wed, 20 May 2009 20:15:18 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:43588 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M6sBs-0007lH-62 for freebsd-current@freebsd.org; Wed, 20 May 2009 22:15:06 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 4DD91F7A38 for ; Wed, 20 May 2009 22:15:03 +0200 (CEST) Message-Id: From: Thomas Backman To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 22:15:03 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M6sBs-0007lH-62. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M6sBs-0007lH-62 769bc1d71ea7e2f65c874cedf45a2b5d Subject: How to duplicate a pool with zfs send/recv without breaking mountpoints? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:15:19 -0000 I'll let the output speak for itself. This is after running zpool create slave X && zfs create slave/received && NOW=$(date +"backup-%Y%m%d-%H%M"); zfs snapshot -r tank@$NOW && zfs send -R tank@ $NOW | zfs recv -vFd slave/received && zpool export slave && zpool import slave [root@chaos ~]# mount tank/root on / (zfs, local, noatime) devfs on /dev (devfs, local) /dev/ad0s1a on /bootdir (ufs, local, soft-updates) tank/tmp on /tmp (zfs, local, noatime) tank/usr on /usr (zfs, local, noatime) tank/usr/ports on /usr/ports (zfs, local, noatime) tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) tank/usr/src on /usr/src (zfs, local, noatime) tank/var on /var (zfs, local, noatime) //SERENITY@EXSCAPE/FBSDBACKUP on /mnt/backup (smbfs) slave/received/root on / (zfs, local, noatime) slave on /slave (zfs, local) slave/received/tmp on /tmp (zfs, local, noatime) slave/received/usr on /usr (zfs, local, noatime) slave/received/usr/ports on /usr/ports (zfs, local, noatime) slave/received/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) slave/received/usr/src on /usr/src (zfs, local, noatime) slave/received/var on /var (zfs, local, noatime) [root@chaos ~]# ls /dev [root@chaos ~]# zfs list internal error: failed to initialize ZFS library (shocking!) Any ideas? I tried setting the mountpoint property on the slave, but I'm pretty sure that didn't help (as the next (incremental) backup resets the mountpoints to /... again, I suppose). Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:24:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCA0106564A for ; Wed, 20 May 2009 20:24:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 30EBA8FC16 for ; Wed, 20 May 2009 20:24:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 35005 invoked from network); 20 May 2009 19:51:03 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 May 2009 19:51:03 -0000 Message-ID: <4A1460A3.2010202@freebsd.org> Date: Wed, 20 May 2009 21:57:23 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: rmacklem@uoguelph.ca, dfr@rabson.org, rwatson@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:24:04 -0000 While working on an optimized soreceive_stream() function [1] and checking the code how it is used I've come across quite a bit of code duplication in the various NFS directories. Socket (read) operations are handled multiple times in a very similar manner in these places: sys/rpc sys/nfsclient sys/nfsserver Also how the soreceive call is used is interesting. It certainly can be made more efficient overall. My questions/observations/suggestions are as follows: a) Can the socket handling code be unified in one place for all NFS? b) The socket upcall mechanism is done per packet and can get expensive for fast networks. It also has some additional unlock/lock overhead plus that is delays protocol processing (even more so with netisr direct dispatch where the code is run from an ithread). c) Can NFS be made to use a select() mechanism where it gets notified when new data arrives? Just like in userspace. d) If not, it may be beneficial to have a taskqueue handle the upcall and have the soappend call return immediately to complete processing of the the protocol. e) The socket buffer is most efficient when it can aggregate a number of packets together before they are processed. Can the NFS code set a low water mark on the socket to get called only after a few packets have arrived instead of each one? (In the select and taskqueue model.) f) I've been thinking of an modular socket filter approach (much like the accept filter) scanning for upper layer specific markers or boundaries and then signalling data availability. -- Andre [1] Perforce: //depot/user/andre/soreceive_stream/kern/uipc_socket.c::soreceive_stream() From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:57:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5992B106586B; Wed, 20 May 2009 20:57:50 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id B76AF8FC17; Wed, 20 May 2009 20:57:49 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by fxm12 with SMTP id 12so685309fxm.43 for ; Wed, 20 May 2009 13:57:49 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dCpYCv+Kjg/LfNYqwJg5sR5KSMcM8u0VC5mIbf6cDqI=; b=WsGbvPMtCfiwUIQtQjvR06zZii7O8mPZ69LSk9QvhquU2P/rT+8r9bEBoGTeu7R2w2 2l7ZyUqXNk5hjHfwSSnLB5+X6kbQ81+3HALBVJQZH2b4RzGCKXbg+901kaKvTBaLm/kI /WkI6mWrYXm7GRE34HZhqYY3mvWnF1Nta7xTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TA3nAX/2jiGVHQeiIR62lYOOOe+NMvmT1PHvqlgB+3TNc/Ci+AF6a4iKY1tolpynrt I6tc9DTx/1gy0iLVr8cC+zBDnnPP71SrBNrLwB6Vf2LeADxeLIktBcQlwKskKo47a5v5 agVfUslgDHOGIAMSrhbI2lhv8iGZJ0ZkCwhpI= Received: by 10.103.227.13 with SMTP id e13mr973490mur.2.1242853068880; Wed, 20 May 2009 13:57:48 -0700 (PDT) Received: from beastie.lan ([195.60.175.243]) by mx.google.com with ESMTPS id y37sm562012mug.49.2009.05.20.13.57.48 (version=SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 13:57:48 -0700 (PDT) Message-ID: <4A146E7C.8010407@gmail.com> Date: Wed, 20 May 2009 23:56:28 +0300 From: Andrey User-Agent: Thunderbird 2.0.0.21 (X11/20090418) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4A1208C0.2000605@FreeBSD.org> In-Reply-To: <4A1208C0.2000605@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: Re: [solved][snd_hda][AD1981HD] microphone doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:57:50 -0000 Hello, Alexander Motin wrote: > Hi. > > Andrey wrote: >> There is a laptop with Intel HD Audio Controller on board (HDA Codec >> AD1981HD) and FreeBSD8.0 CURRENT installed. Unfortunately I can't get >> microphone working. (7.2-PRERELEASE had been used before switching to >> CURRENT and microphone had been known as working out-of-the-box on >> that version of FreeBSD). >> >> Looking through the list exposed message where similar issue was >> reported: >> http://www.mailinglistarchive.com/freebsd-current@freebsd.org/msg22832.html >> >> But it looks like requestor didn't provide feedback regarding enclosed >> patch. Also, as far as I can judge, that patch is already in CURRENT, >> but it seems issue is not solved yet (well, at least I think so). > > This patch was merged to 7-stable 4 months ago, together with the rest > of driver changes. 7.2-PRERELEASE had snd_hda driver almost (or may be > even completely) identical to the CURRENT of that time. So I don't > understand the difference. To find any difference in driver operation, > try to compare verbose dmesg of the driver in working and not working > systems. > > By the way, are you sure that problem is in driver itself? Can't be > linuxulator, Skype, settings or whatever else problem? What are you > using to record sound? Have you tried to use something trivial like > rawrec and rawplay? > > What microphone are you using: external or internal? Have you tried > another one? Are you recording silence or some noise? What mixer > settings do you use? sorry for the noise. The real root of the issue was my fault: I selected improper recording device for external microphone. (JFR: switching recording device to 'monitor' (i.e. 'mixer =rec monitor') was the proper setting in my case). Many thanks to Alexander Motin for helping me to reveal misconfiguration. --- WBR, Andrey Kosachenko From owner-freebsd-current@FreeBSD.ORG Wed May 20 23:22:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 617871065670; Wed, 20 May 2009 23:22:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 399B18FC0A; Wed, 20 May 2009 23:22:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4KNMcAA097773; Wed, 20 May 2009 19:22:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4KNMcXa021456; Wed, 20 May 2009 19:22:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2B6C17302F; Wed, 20 May 2009 19:22:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090520232238.2B6C17302F@freebsd-current.sentex.ca> Date: Wed, 20 May 2009 19:22:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 23:22:44 -0000 TB --- 2009-05-20 21:37:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-20 21:37:12 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-20 21:37:12 - cleaning the object tree TB --- 2009-05-20 21:37:44 - cvsupping the source tree TB --- 2009-05-20 21:37:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-20 21:37:57 - building world TB --- 2009-05-20 21:37:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-20 21:37:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-20 21:37:57 - TARGET=pc98 TB --- 2009-05-20 21:37:57 - TARGET_ARCH=i386 TB --- 2009-05-20 21:37:57 - TZ=UTC TB --- 2009-05-20 21:37:57 - __MAKE_CONF=/dev/null TB --- 2009-05-20 21:37:57 - cd /src TB --- 2009-05-20 21:37:57 - /usr/bin/make -B buildworld >>> World build started on Wed May 20 21:37:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 20 23:02:12 UTC 2009 TB --- 2009-05-20 23:02:12 - generating LINT kernel config TB --- 2009-05-20 23:02:12 - cd /src/sys/pc98/conf TB --- 2009-05-20 23:02:12 - /usr/bin/make -B LINT TB --- 2009-05-20 23:02:12 - building LINT kernel TB --- 2009-05-20 23:02:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-20 23:02:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-20 23:02:12 - TARGET=pc98 TB --- 2009-05-20 23:02:12 - TARGET_ARCH=i386 TB --- 2009-05-20 23:02:12 - TZ=UTC TB --- 2009-05-20 23:02:12 - __MAKE_CONF=/dev/null TB --- 2009-05-20 23:02:12 - cd /src TB --- 2009-05-20 23:02:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 20 23:02:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk if_lagg.kld export_syms | xargs -J% objcopy % if_lagg.kld ld -Bshareable -d -warn-common -o if_lagg.ko if_lagg.kld objcopy --strip-debug if_lagg.ko ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_scan_results': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:3411: error: too many arguments to function 'ieee80211_add_scan' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-20 23:22:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-20 23:22:37 - ERROR: failed to build lint kernel TB --- 2009-05-20 23:22:37 - 4926.55 user 467.55 system 6325.45 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed May 20 23:30:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B34371065672 for ; Wed, 20 May 2009 23:30:47 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 38F038FC13 for ; Wed, 20 May 2009 23:30:46 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by fxm12 with SMTP id 12so746200fxm.43 for ; Wed, 20 May 2009 16:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=kGr0oPtTzo/aPyWwL3oK2BDzhGx4G4QPrKqaz0HFKeU=; b=LP/IfTnkbkKhtwaYQqQ1lG2KQzq16VaSG6bFzwDwwk9duv98nYoO8TkcsQOcBWsWag i57cHEI9pCxajIR4yQwL9Qh0y479pxGPxxWgfvqqWuWpZsBZ/F98WxpDXjGIjkKg4NKd LohDAE3ggGdtFArbyqkEsDozn8WcQJztOJi9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=rn3WY/H2x3sle/O2RMzBWtfN/GREiuQMNyKef9FAWhlkeztppju+YhfLzZp0bDG3G1 ZhKiYDY7nNJt9qNFLu3ypH/l5+f4JiiZ4x2I6b/rTkarrwoA8R1F38m/RLl7jVUcXBYy eN6d3XVA0l+w8joQGK4jrC4zax+abAB9ZK3y8= Received: by 10.103.39.17 with SMTP id r17mr1013742muj.75.1242862246128; Wed, 20 May 2009 16:30:46 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.14.66]) by mx.google.com with ESMTPS id j6sm2858580mue.1.2009.05.20.16.30.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 16:30:45 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 20CD0B8143; Wed, 20 May 2009 20:30:38 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Wed, 20 May 2009 20:30:38 -0300 (BRT) Message-ID: <4a36be1c432cfacf71ffa75ce3abbdd0.squirrel@10.1.1.10> In-Reply-To: <200905201227.46674.mel.flynn+fbsd.current@mailing.thruhere.net> References: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> <200905201227.46674.mel.flynn+fbsd.current@mailing.thruhere.net> Date: Wed, 20 May 2009 20:30:38 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: is my slow for this ? hostap related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 23:30:48 -0000 On Wed, May 20, 2009 07:27, Mel Flynn wrote: > Hi Nenhum, > > On Monday 18 May 2009 01:08:09 Nenhum_de_Nos wrote: > >> I have an atheros wlan card: >> >> ath0@pci0:0:11:0: class=0x020000 card=0x3a131186 chip=0x0013168c >> rev=0x01 hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' >> class = network >> subclass = ethernet > > > >> May 17 13:19:36 floyd kernel: ath0: stuck beacon; resetting (bmiss count >> 4) >> May 17 13:20:07 floyd last message repeated 89 times >> May 17 13:22:08 floyd last message repeated 376 times >> >> I've read this: >> >> http://www.nabble.com/ath0:-stuck-beacon--resetting-(bmiss-count-4)-td22359 >>155.html >> >> and I'm thinking my pc is slow for the job, as said. >> >> floyd# cat dmesg.today >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-CURRENT #0: Tue May 5 23:08:28 BRT 2009 >> root@floyd.apartnet:/usr/obj/usr/src/sys/Floyd8 >> WARNING: WITNESS option enabled, expect reduced performance. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Read /usr/src/UPDATING about WITNESS options and which to delete from > GENERIC I did, both read and recompile ... no good. I put: ral0@pci0:0:11:0: class=0x028000 card=0x3a711186 chip=0x03021814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' device = 'RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless a/b' class = network on there, no good also. is slow in the beginning, and then dies forever. I tried on a 950MHz duron and got the same results (atheros card only). unfortunately I can't test this duron anymore as it died from bad PSU. what made atheros happy was a Core 2 Duo, 2.66GHz at work. faster downloads and no even one of those lines :( too bad I just have an AthlonXP I can use as AP :( and soekris in future would be a way, now I think is slow as well ... thanks, matheus > kernel. I think once you turn those options off, your machine should be > able > to handle this, though I wouldn't run anything else on it. On a single > 1.8Ghz > 686, I got these occasionally, when backups were done over gigabit and a > movie > was playing on it. I've since reconfigured the machine as dedicated media > server and replaced the router with a headless 3Ghz 686, also running > squid. > This is overkill for my home network, though. > -- > Mel > -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Wed May 20 23:44:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72A691065689 for ; Wed, 20 May 2009 23:44:15 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA428FC16 for ; Wed, 20 May 2009 23:44:14 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 32789 invoked from network); 20 May 2009 23:44:14 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 20 May 2009 23:44:14 -0000 Message-ID: <4A14956E.2040608@acm.poly.edu> Date: Wed, 20 May 2009 19:42:38 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: Nenhum_de_Nos References: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> <200905201227.46674.mel.flynn+fbsd.current@mailing.thruhere.net> <4a36be1c432cfacf71ffa75ce3abbdd0.squirrel@10.1.1.10> In-Reply-To: <4a36be1c432cfacf71ffa75ce3abbdd0.squirrel@10.1.1.10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: is my slow for this ? hostap related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 23:44:16 -0000 Nenhum_de_Nos wrote: > On Wed, May 20, 2009 07:27, Mel Flynn wrote: > >> Hi Nenhum, >> >> On Monday 18 May 2009 01:08:09 Nenhum_de_Nos wrote: >> >> >>> I have an atheros wlan card: >>> >>> ath0@pci0:0:11:0: class=0x020000 card=0x3a131186 chip=0x0013168c >>> rev=0x01 hdr=0x00 >>> vendor = 'Atheros Communications Inc.' >>> device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' >>> class = network >>> subclass = ethernet >>> >> >> >> >>> May 17 13:19:36 floyd kernel: ath0: stuck beacon; resetting (bmiss count >>> 4) >>> May 17 13:20:07 floyd last message repeated 89 times >>> May 17 13:22:08 floyd last message repeated 376 times >>> >>> I've read this: >>> >>> http://www.nabble.com/ath0:-stuck-beacon--resetting-(bmiss-count-4)-td22359 >>> 155.html >>> >>> and I'm thinking my pc is slow for the job, as said. >>> >>> floyd# cat dmesg.today >>> Copyright (c) 1992-2009 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.0-CURRENT #0: Tue May 5 23:08:28 BRT 2009 >>> root@floyd.apartnet:/usr/obj/usr/src/sys/Floyd8 >>> WARNING: WITNESS option enabled, expect reduced performance. >>> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Read /usr/src/UPDATING about WITNESS options and which to delete from >> GENERIC >> > > I did, both read and recompile ... no good. > > I put: > ral0@pci0:0:11:0: class=0x028000 card=0x3a711186 chip=0x03021814 rev=0x00 > hdr=0x00 > vendor = 'Ralink Technology, Corp' > device = 'RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless a/b' > class = network > > on there, no good also. is slow in the beginning, and then dies forever. > > I tried on a 950MHz duron and got the same results (atheros card only). > unfortunately I can't test this duron anymore as it died from bad PSU. > > what made atheros happy was a Core 2 Duo, 2.66GHz at work. faster > downloads and no even one of those lines :( > > too bad I just have an AthlonXP I can use as AP :( > and soekris in future would be a way, now I think is slow as well ... > > thanks, > > matheus > > >> kernel. I think once you turn those options off, your machine should be >> able >> to handle this, though I wouldn't run anything else on it. On a single >> 1.8Ghz >> 686, I got these occasionally, when backups were done over gigabit and a >> movie >> was playing on it. I've since reconfigured the machine as dedicated media >> server and replaced the router with a headless 3Ghz 686, also running >> squid. >> This is overkill for my home network, though. >> -- >> Mel >> >> > > > I don't think your CPU is at fault. While I don't have any Crusoes, I have several machines, ranging from Pentiums running at 200 MHz to Pentium IIIs running at 933 MHz, with AR5212 cards in them. They run 7.0-, 7.1-, and 7.2-RELEASE. While I do get some "stuck beacon" and "device timeout" messages on them, they can all push at least 2 MB/s on the AR5212 cards, and I am assuming that your Crusoe is faster than a Pentium 200. -Boris From owner-freebsd-current@FreeBSD.ORG Thu May 21 01:50:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0291065680 for ; Thu, 21 May 2009 01:50:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id BEEEB8FC21 for ; Thu, 21 May 2009 01:50:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id B371EFF17 for ; Thu, 21 May 2009 13:50:41 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB8m4ji2G+Z1 for ; Thu, 21 May 2009 13:50:37 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP for ; Thu, 21 May 2009 13:50:37 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id B98D311432; Thu, 21 May 2009 13:50:36 +1200 (NZST) Date: Wed, 20 May 2009 18:50:36 -0700 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090521015036.GA27948@citylink.fud.org.nz> References: <200905210148.n4L1mgJV050522@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905210148.n4L1mgJV050522@svn.freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: svn commit: r192502 - in head: . sys/dev/usb sys/dev/usb/controller sys/dev/usb/input sys/dev/usb/misc sys/dev/usb/net sys/dev/usb/serial sys/dev/usb/storage sys/dev/usb/wlan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 01:50:46 -0000 On Thu, May 21, 2009 at 01:48:42AM +0000, Andrew Thompson wrote: > Author: thompsa > Date: Thu May 21 01:48:42 2009 > New Revision: 192502 > URL: http://svn.freebsd.org/changeset/base/192502 > > Log: > Rename the usb sysctl tree from hw.usb2.* back to hw.usb.*. > > Submitted by: Hans Petter Selasky FYI, the temporary change in sysctl naming from the usb stack changeover has been reverted. Andrew From owner-freebsd-current@FreeBSD.ORG Thu May 21 01:56:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2A61065670 for ; Thu, 21 May 2009 01:56:14 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id EA7168FC1E for ; Thu, 21 May 2009 01:56:13 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 0820F5C34; Wed, 20 May 2009 21:56:13 -0400 (EDT) Date: Wed, 20 May 2009 21:56:13 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090521015612.GA2630@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <20090518161148.GA56646@atarininja.org> <20090519204947.GA39529@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 01:56:14 -0000 On Wed, May 20, 2009 at 02:00:49PM +0200, Thomas Backman wrote: > > On May 19, 2009, at 10:49 PM, Wesley Shields wrote: > > I just noticed this but shouldn't you be using copyinstr() on the > > first > > probe. It should look something like this: > > > > syscall::open:entry > > { > > self->path = copyinstr(arg0); > > } > > > > syscall::open:return > > / self->path / > > { > > printf("%s\n", self->path); > > } > > > > This still doesn't solve the problem of copyinstr() causing a crash > > though. > > I don't remember why, but I do remember that it was said (in older > versions) in the Solaris DTrace guide to always copy in variables > after the function return, not quite sure why (Possibly because they > could be undefined in :::entry?). Brendan Gregg, who wrote the DTrace > Toolkit, does this, anyway (see the opensnoop.d script). Sun liked his > work so much that they hired him. :-) It's still mentioned in the guide (page 346, "Avoiding Errors"). The reason is the one I mentioned (the argument being copied in has to be in a page that is faulted-in). It's quite possible that on entry into the syscall that page is not yet faulted in. -- WXS From owner-freebsd-current@FreeBSD.ORG Thu May 21 02:05:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 588E41065676; Thu, 21 May 2009 02:05:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF858FC46; Thu, 21 May 2009 02:05:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L25XGn011133; Wed, 20 May 2009 22:05:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L25XQJ097665; Wed, 20 May 2009 22:05:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E03037302F; Wed, 20 May 2009 22:05:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090521020532.E03037302F@freebsd-current.sentex.ca> Date: Wed, 20 May 2009 22:05:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 02:05:37 -0000 TB --- 2009-05-21 00:29:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-21 00:29:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-21 00:29:43 - cleaning the object tree TB --- 2009-05-21 00:30:15 - cvsupping the source tree TB --- 2009-05-21 00:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-21 00:30:34 - building world TB --- 2009-05-21 00:30:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 00:30:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 00:30:34 - TARGET=powerpc TB --- 2009-05-21 00:30:34 - TARGET_ARCH=powerpc TB --- 2009-05-21 00:30:34 - TZ=UTC TB --- 2009-05-21 00:30:34 - __MAKE_CONF=/dev/null TB --- 2009-05-21 00:30:34 - cd /src TB --- 2009-05-21 00:30:34 - /usr/bin/make -B buildworld >>> World build started on Thu May 21 00:30:35 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu May 21 01:57:31 UTC 2009 TB --- 2009-05-21 01:57:31 - generating LINT kernel config TB --- 2009-05-21 01:57:31 - cd /src/sys/powerpc/conf TB --- 2009-05-21 01:57:31 - /usr/bin/make -B LINT TB --- 2009-05-21 01:57:31 - building LINT kernel TB --- 2009-05-21 01:57:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 01:57:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 01:57:31 - TARGET=powerpc TB --- 2009-05-21 01:57:31 - TARGET_ARCH=powerpc TB --- 2009-05-21 01:57:31 - TZ=UTC TB --- 2009-05-21 01:57:31 - __MAKE_CONF=/dev/null TB --- 2009-05-21 01:57:31 - cd /src TB --- 2009-05-21 01:57:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 21 01:57:31 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pcm/mixer.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/sound/pcm/mixer_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror mixer_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pcm/sndstat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pcm/sound.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pcm/vchan.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/usb/uaudio.c /src/sys/dev/sound/usb/uaudio.c: In function 'uaudio_probe': /src/sys/dev/sound/usb/uaudio.c:535: error: 'struct usb2_attach_arg' has no member named 'usb2_mode' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-21 02:05:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-21 02:05:32 - ERROR: failed to build lint kernel TB --- 2009-05-21 02:05:32 - 4466.52 user 421.21 system 5749.09 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu May 21 02:42:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52DA21065670; Thu, 21 May 2009 02:42:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 28E158FC08; Thu, 21 May 2009 02:42:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L2geuU054069; Wed, 20 May 2009 22:42:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L2get8014510; Wed, 20 May 2009 22:42:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6E3247302F; Wed, 20 May 2009 22:42:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090521024240.6E3247302F@freebsd-current.sentex.ca> Date: Wed, 20 May 2009 22:42:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 02:42:44 -0000 TB --- 2009-05-21 01:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-21 01:10:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-21 01:10:00 - cleaning the object tree TB --- 2009-05-21 01:10:35 - cvsupping the source tree TB --- 2009-05-21 01:10:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-21 01:10:52 - building world TB --- 2009-05-21 01:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 01:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 01:10:52 - TARGET=sparc64 TB --- 2009-05-21 01:10:52 - TARGET_ARCH=sparc64 TB --- 2009-05-21 01:10:52 - TZ=UTC TB --- 2009-05-21 01:10:52 - __MAKE_CONF=/dev/null TB --- 2009-05-21 01:10:52 - cd /src TB --- 2009-05-21 01:10:52 - /usr/bin/make -B buildworld >>> World build started on Thu May 21 01:10:54 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu May 21 02:33:13 UTC 2009 TB --- 2009-05-21 02:33:13 - generating LINT kernel config TB --- 2009-05-21 02:33:13 - cd /src/sys/sparc64/conf TB --- 2009-05-21 02:33:13 - /usr/bin/make -B LINT TB --- 2009-05-21 02:33:13 - building LINT kernel TB --- 2009-05-21 02:33:13 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 02:33:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 02:33:13 - TARGET=sparc64 TB --- 2009-05-21 02:33:13 - TARGET_ARCH=sparc64 TB --- 2009-05-21 02:33:13 - TZ=UTC TB --- 2009-05-21 02:33:13 - __MAKE_CONF=/dev/null TB --- 2009-05-21 02:33:13 - cd /src TB --- 2009-05-21 02:33:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 21 02:33:13 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wi/if_wi.c cc1: warnings being treated as errors /src/sys/dev/wi/if_wi.c: In function 'wi_rx_intr': /src/sys/dev/wi/if_wi.c:1385: warning: right shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: right shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: left shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: left shift count >= width of type *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-21 02:42:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-21 02:42:40 - ERROR: failed to build lint kernel TB --- 2009-05-21 02:42:40 - 4287.73 user 417.24 system 5560.03 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu May 21 03:30:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF3ED1065676; Thu, 21 May 2009 03:30:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B4F5D8FC24; Thu, 21 May 2009 03:30:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L3Ue37056579; Wed, 20 May 2009 23:30:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4L3UeRe074629; Wed, 20 May 2009 23:30:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0A4FE7302F; Wed, 20 May 2009 23:30:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090521033040.0A4FE7302F@freebsd-current.sentex.ca> Date: Wed, 20 May 2009 23:30:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 03:30:43 -0000 TB --- 2009-05-21 02:05:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-21 02:05:33 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-05-21 02:05:33 - cleaning the object tree TB --- 2009-05-21 02:06:09 - cvsupping the source tree TB --- 2009-05-21 02:06:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-21 02:06:28 - building world TB --- 2009-05-21 02:06:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 02:06:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 02:06:28 - TARGET=sun4v TB --- 2009-05-21 02:06:28 - TARGET_ARCH=sparc64 TB --- 2009-05-21 02:06:28 - TZ=UTC TB --- 2009-05-21 02:06:28 - __MAKE_CONF=/dev/null TB --- 2009-05-21 02:06:28 - cd /src TB --- 2009-05-21 02:06:28 - /usr/bin/make -B buildworld >>> World build started on Thu May 21 02:06:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu May 21 03:22:27 UTC 2009 TB --- 2009-05-21 03:22:27 - generating LINT kernel config TB --- 2009-05-21 03:22:27 - cd /src/sys/sun4v/conf TB --- 2009-05-21 03:22:27 - /usr/bin/make -B LINT TB --- 2009-05-21 03:22:28 - building LINT kernel TB --- 2009-05-21 03:22:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 03:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 03:22:28 - TARGET=sun4v TB --- 2009-05-21 03:22:28 - TARGET_ARCH=sparc64 TB --- 2009-05-21 03:22:28 - TZ=UTC TB --- 2009-05-21 03:22:28 - __MAKE_CONF=/dev/null TB --- 2009-05-21 03:22:28 - cd /src TB --- 2009-05-21 03:22:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 21 03:22:28 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wi/if_wi.c cc1: warnings being treated as errors /src/sys/dev/wi/if_wi.c: In function 'wi_rx_intr': /src/sys/dev/wi/if_wi.c:1385: warning: right shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: right shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: left shift count >= width of type /src/sys/dev/wi/if_wi.c:1385: warning: left shift count >= width of type *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-21 03:30:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-21 03:30:39 - ERROR: failed to build lint kernel TB --- 2009-05-21 03:30:39 - 4253.29 user 413.07 system 5106.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu May 21 03:37:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53533106566C for ; Thu, 21 May 2009 03:37:35 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from packrat.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD298FC0A for ; Thu, 21 May 2009 03:37:34 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.3/8.14.3) with ESMTP id n4L3RL7c073513 for ; Wed, 20 May 2009 22:27:21 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.3/8.14.3/Submit) with ESMTP id n4L3RLFA073504 for ; Wed, 20 May 2009 22:27:21 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Wed, 20 May 2009 22:27:19 -0500 (CDT) From: Greg Rivers To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: USB-to-serial adapter works on -STABLE but not -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 03:37:35 -0000 I have a Belkin USB serial adapter (http://catalog.belkin.com/IWCatProductPage.process?Product_Id=459431) that works with the umct(4) driver under 7.2-STABLE. When the adapter is plugged in the driver attaches, /dev/cuaU0 is created, and I can connect with cu(1) and type at a modem. But on 8.0-CURRENT, only the ugen driver attaches and no /dev/cuaU* device is created. "usbconfig dump_device_desc" shows: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0010 idVendor = 0x050d idProduct = 0x0109 bcdDevice = 0x0102 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <106930> bNumConfigurations = 0x0001 Why does umct fail to attach under 8.0-CURRENT? -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Thu May 21 03:48:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB008106566B for ; Thu, 21 May 2009 03:48:17 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 710448FC13 for ; Thu, 21 May 2009 03:48:17 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so321037rvb.43 for ; Wed, 20 May 2009 20:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=TzA1ShbTzvmegPbxH/lFMqkPhOWGl9ekdqAbztJlpzQ=; b=O6iQnDR+Z1uPYLKAFnS+r7EG8Kz34wNSUMrJp9x4/8f1EGdRSUJUnMHTEy+Tep7iAX PhfCXVbKHAgBbjBHzxP+ionkr1dICz+IbWHhQtjBojbX5FIdOx/dpqItaX/+1sklwDDb AYauk0jc4sMXw7+cFfPVShISuzNGkUuWYDjHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=RLoQPl+ZUpVf/gAiqRgAUgGBFYgk5VA9cN3ybjHhwsNx/8C7Wo4LbtiQx5AdgMqvZy 34KziqDueRtTRKQ69VqbAE68eeh/LpF5CfIwopVSye4ceoS04lz3BNIURpkMf726ywBg coE7tsqLr+5RjpTbBZuG52yzOlAYygdyLsbB0= Received: by 10.141.20.6 with SMTP id x6mr929891rvi.40.1242877697025; Wed, 20 May 2009 20:48:17 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm5626880rvf.0.2009.05.20.20.48.14 (version=SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 20:48:15 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Thu, 21 May 2009 12:48:11 +0900 From: Weongyo Jeong Date: Thu, 21 May 2009 12:48:11 +0900 To: Hans Petter Selasky Message-ID: <20090521034811.GA88745@weongyo.cdnetworks.kr> Mail-Followup-To: Hans Petter Selasky , freebsd-current@freebsd.org, Lucius Windschuh References: <90a5caac0905171354k6e7c008eye18bd69aa543eaa6@mail.gmail.com> <90a5caac0905181508m7024377as8d70c89694a21e26@mail.gmail.com> <20090519044941.GC42412@weongyo.cdnetworks.kr> <200905190911.01576.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905190911.01576.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Lucius Windschuh , freebsd-current@freebsd.org Subject: Re: Panics and potential memory corruption when pulling out a uath device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 03:48:17 -0000 On Tue, May 19, 2009 at 09:11:01AM +0200, Hans Petter Selasky wrote: > On Tuesday 19 May 2009, Weongyo Jeong wrote: > > On Tue, May 19, 2009 at 12:08:45AM +0200, Lucius Windschuh wrote: > > > 2009/5/18 Hans Petter Selasky : > > > > Regarding the first panic, there seems to be a detach race in both upgt > > > > and uath, which is not USB related. Try this patch: > > > > > > > > http://perforce.freebsd.org/chv.cgi?CH=162250 > > > > > > This fixes not only the first panic. > > > I can't provoke any panic by pulling out the active device. Thanks. > > > > Could you please test with this patch that is slightly different with > > Hans's patch? It try to unsetup after stopping the device. > > > > If no problems I'd commit it. > > > > regards, > > Weongyo Jeong > > Hi, > > I had added the wrong ID to the driver. Now it seems to almost work. What does > the following error code mean? When I run wpa_cli I see some valid scan > results. I have not tried to associate yet. > > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 > uath0: uath_cmdsend: empty inactive queue > uath0: could not set channel, error 55 It means that by some reasons the device didn't answer to the command request the driver queued on the command queue, so all of commands are waiting the device's responses. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Thu May 21 04:09:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8DDC1065670 for ; Thu, 21 May 2009 04:09:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8BD8FC08 for ; Thu, 21 May 2009 04:09:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pzk3 with SMTP id 3so734013pzk.3 for ; Wed, 20 May 2009 21:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mime-version:content-type:content-disposition :user-agent; bh=MxTB9km2sSEbZIRtArEiZemWVXHnf8lB2RFbqyS/JSA=; b=DQ1VPbEf2wkxlk83cW6AvJH+57zSfPRsb1cKsk0ivQD9zFakUUWMspG9TowGv+Cstl qvIZuntQfYPaRhjqsRus1MFgkreDwxZoceIgn3gixszmNp2MDsxt13iZ0gR4U994tr4u OLbPp8QN6JHOzXTiGVa0F9fac2/4FSaGNQBkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; b=F1tgAuRHGRFW2yOoxKNACxHWj6pUP2maegMc+knW66oZLTxVmpjWHLjXE1FolsLTqU 0EjcJkM3U1fN/dwbqzrhKOh7ab2GVMjcYryKonfoQHPbIOQ3dsHnwi4EOVe963td9GtA WAHvBcWtTklXjSfMcooK83k/YBAjKREcMg5Lk= Received: by 10.114.160.17 with SMTP id i17mr4300648wae.125.1242878963011; Wed, 20 May 2009 21:09:23 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm17729956rvb.0.2009.05.20.21.09.21 (version=SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 21:09:22 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 21 May 2009 13:19:29 +0900 From: Pyun YongHyeon Date: Thu, 21 May 2009 13:19:29 +0900 To: freebsd-current@freebsd.org Message-ID: <20090521041929.GN9043@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: CFT: msk(4) and Yukon FE+(88E8040, 88E8040T, 88E8048, 88E8070) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 04:09:23 -0000 Hi, I had been working on supporting Yukon FE+ for more than a year. Lack of hardware and documentation was one of major issue to write support code. Recently one user, Tanguy Bouzeloc, submitted fix and the patch seems to make msk(4) work on Yukon FE+. You can get the latest patch at the following URL. http://people.freebsd.org/~yongari/msk/msk.88E8040.patch26 Since the patch changes a lot of code flow of driver all msk(4) users would be affected. If you use msk(4) or have Yukon FE+, please give it try and let me know how it goes on your box. Thanks. From owner-freebsd-current@FreeBSD.ORG Thu May 21 06:33:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58935106566B for ; Thu, 21 May 2009 06:33:09 +0000 (UTC) (envelope-from sfourman@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 DC9E78FC12 for ; Thu, 21 May 2009 06:33:08 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so224776eyd.7 for ; Wed, 20 May 2009 23:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dcpXefBoPxiHWgJDRkvyAN95CNxR3FFljoUsDuCxigY=; b=uva0qnGZWoZGx9e3bASWg+J8mDTRAgGAgyhCgZxgbfIuSX3vriv4sCmAzwFzdGpz6c HaWf0REe8VpYhobIhXdc3TnPzzP+fiSdjCse+c37+y75vIWejMGgdtPQMdlRNWx2ZdIy lmtdRKWyhKNKY/vvBTWhT9AkrOZFUW73Ss/so= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jfCIej81yqdfUTw6m4asj9T0TsnqjVWlOslEzzOpa6XyIecGKV3bFjnsCbytyKKJkv 1g5Nmy4zHXzQQDjw9u1fOOGPi9J1ilJ03Bb/oLs7mViMXM6N2P5noYi+nuuauDNmjHbC tlz9Ej07ohkzJwkS1yED31ZBjB3z9qKu6oASw= MIME-Version: 1.0 Received: by 10.216.50.76 with SMTP id y54mr472382web.70.1242887587920; Wed, 20 May 2009 23:33:07 -0700 (PDT) In-Reply-To: <20090519153516.yki2cyqpwg48sk04@0x20.net> References: <4A11A08B.6090309@errno.com> <20090519153516.yki2cyqpwg48sk04@0x20.net> Date: Thu, 21 May 2009 01:33:07 -0500 Message-ID: <11167f520905202333m47d26277mb03967c39c6bc7a@mail.gmail.com> From: "Sam Fourman Jr." To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 06:33:09 -0000 > >> The patch here: >> >> http://people.freebsd.org/~sam/monitor-20090518.patch >> >> has significant changes to monitor mode operation. =A0Most importantly i= t >> replaces DLT_IEEE802_11 support in net80211 by DLT_IEEE802_11_RADIO and >> removes the latter from the underlying device. =A0The upshot is that you >> can no longer do: Does anyone know if the kismet in ports will function properly with this pa= tch? Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Thu May 21 06:39:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7E1106564A for ; Thu, 21 May 2009 06:39:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 164098FC08 for ; Thu, 21 May 2009 06:39:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ReFjGRNPLF4A:10 a=1ZRv1tzC3DYA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=6I5d2MoRAAAA:8 a=vBApm749eCF0Mn0fT3sA:9 a=dAmVx25OR9oSC4TcxDVYgluG1rgA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1072967990; Thu, 21 May 2009 08:39:11 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 21 May 2009 08:43:09 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905210843.09606.hselasky@c2i.net> Cc: Subject: Re: USB-to-serial adapter works on -STABLE but not -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 06:39:13 -0000 On Thursday 21 May 2009, Greg Rivers wrote: > Greg Rivers There seems to be a minor probe information error in the umct driver. Try this patch: http://perforce.freebsd.org/chv.cgi?CH=162438 --HPS From owner-freebsd-current@FreeBSD.ORG Thu May 21 08:35:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E96ED1065675 for ; Thu, 21 May 2009 08:35:50 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 776078FC25 for ; Thu, 21 May 2009 08:35:50 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id BE1B74BB8; Thu, 21 May 2009 10:35:49 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n4L8Zled075230; Thu, 21 May 2009 10:35:47 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1242894949; bh=KOW61PD+bCEHgIQG00umUVNidHwy97+W8a+jEE6uT0M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KUl+uEUI98OLMSyllu1JyHkNqtqXEUSPrxRdrtJIZypm7hSm139OK9d05lRJz0qdA b8NBHUiqAxP21bfj4mudA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=16ixiod500/v+vhGhJsve7FjbGH2aGfkViX4pCbqXsKJCHzwjXgs8occqz39f3M5H iUKiIX6J/h09OvDnTc6/A== Message-ID: <4A151263.2070708@restart.be> Date: Thu, 21 May 2009 10:35:47 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Thomas Backman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org Subject: Re: How to duplicate a pool with zfs send/recv without breaking mountpoints? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 08:35:51 -0000 Thomas Backman wrote: > I'll let the output speak for itself. This is after running > zpool create slave X && zfs create slave/received && NOW=$(date > +"backup-%Y%m%d-%H%M"); zfs snapshot -r tank@$NOW && zfs send -R > tank@$NOW | zfs recv -vFd slave/received && zpool export slave && zpool > import slave > > [root@chaos ~]# mount > tank/root on / (zfs, local, noatime) > devfs on /dev (devfs, local) > /dev/ad0s1a on /bootdir (ufs, local, soft-updates) > tank/tmp on /tmp (zfs, local, noatime) > tank/usr on /usr (zfs, local, noatime) > tank/usr/ports on /usr/ports (zfs, local, noatime) > tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) > tank/usr/src on /usr/src (zfs, local, noatime) > tank/var on /var (zfs, local, noatime) > //SERENITY@EXSCAPE/FBSDBACKUP on /mnt/backup (smbfs) > slave/received/root on / (zfs, local, noatime) > slave on /slave (zfs, local) > slave/received/tmp on /tmp (zfs, local, noatime) > slave/received/usr on /usr (zfs, local, noatime) > slave/received/usr/ports on /usr/ports (zfs, local, noatime) > slave/received/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, > noatime) > slave/received/usr/src on /usr/src (zfs, local, noatime) > slave/received/var on /var (zfs, local, noatime) > [root@chaos ~]# ls /dev > [root@chaos ~]# zfs list > internal error: failed to initialize ZFS library (shocking!) > > Any ideas? I tried setting the mountpoint property on the slave, but I'm > pretty sure that didn't help (as the next (incremental) backup resets > the mountpoints to /... again, I suppose). How about creating slave like this: mkdir /slave zpool create -R /slave -m none slave X Henri > > Regards, > Thomas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu May 21 08:42:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8857A1065670 for ; Thu, 21 May 2009 08:42:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 18B148FC0C for ; Thu, 21 May 2009 08:42:47 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:47633 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M73rL-000782-5H; Thu, 21 May 2009 10:42:41 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 81C20335DE; Thu, 21 May 2009 10:42:27 +0200 (CEST) Message-Id: <7AB57D31-AE15-480D-8D2D-7AA000555CD2@exscape.org> From: Thomas Backman To: Henri Hennebert In-Reply-To: <4A151263.2070708@restart.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 10:42:27 +0200 References: <4A151263.2070708@restart.be> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M73rL-000782-5H. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M73rL-000782-5H 45b1d53c2f5ae0585ec18c0a651e0d26 Cc: freebsd-current@freebsd.org Subject: Re: How to duplicate a pool with zfs send/recv without breaking mountpoints? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 08:42:48 -0000 On May 21, 2009, at 10:35 AM, Henri Hennebert wrote: > Thomas Backman wrote: >> I'll let the output speak for itself. This is after running >> zpool create slave X && zfs create slave/received && NOW=$(date >> +"backup-%Y%m%d-%H%M"); zfs snapshot -r tank@$NOW && zfs send -R >> tank@$NOW | zfs recv -vFd slave/received && zpool export slave && >> zpool import slave >> [root@chaos ~]# mount >> tank/root on / (zfs, local, noatime) >> devfs on /dev (devfs, local) >> /dev/ad0s1a on /bootdir (ufs, local, soft-updates) >> tank/tmp on /tmp (zfs, local, noatime) >> tank/usr on /usr (zfs, local, noatime) >> tank/usr/ports on /usr/ports (zfs, local, noatime) >> tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, >> noatime) >> tank/usr/src on /usr/src (zfs, local, noatime) >> tank/var on /var (zfs, local, noatime) >> //SERENITY@EXSCAPE/FBSDBACKUP on /mnt/backup (smbfs) >> slave/received/root on / (zfs, local, noatime) >> slave on /slave (zfs, local) >> slave/received/tmp on /tmp (zfs, local, noatime) >> slave/received/usr on /usr (zfs, local, noatime) >> slave/received/usr/ports on /usr/ports (zfs, local, noatime) >> slave/received/usr/ports/distfiles on /usr/ports/distfiles (zfs, >> local, noatime) >> slave/received/usr/src on /usr/src (zfs, local, noatime) >> slave/received/var on /var (zfs, local, noatime) >> [root@chaos ~]# ls /dev >> [root@chaos ~]# zfs list >> internal error: failed to initialize ZFS library (shocking!) >> Any ideas? I tried setting the mountpoint property on the slave, >> but I'm pretty sure that didn't help (as the next (incremental) >> backup resets the mountpoints to /... again, I suppose). > > How about creating slave like this: > > mkdir /slave > zpool create -R /slave -m none slave X > > Henri As always, when asking for help, the solution pops up right after posting. :-) I fixed it this morning, using pretty much your approach. However, according to the man pages, altroot isn't a permanent property, so I simply import it with zpool import -R every time. It'd be great if there is a better way, but this seems to work just fine. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu May 21 08:52:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CB5E106566B; Thu, 21 May 2009 08:52:34 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id CE2C78FC23; Thu, 21 May 2009 08:52:33 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:39204 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M73lq-0000fW-3m; Thu, 21 May 2009 10:37:06 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 29B38335EC; Thu, 21 May 2009 10:36:54 +0200 (CEST) Message-Id: From: Thomas Backman To: Kip Macy In-Reply-To: <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 10:36:54 +0200 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M73lq-0000fW-3m. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M73lq-0000fW-3m 409936a4669b1a76da0e6a730d04844e Cc: current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 08:52:34 -0000 On May 19, 2009, at 03:15 AM, Kip Macy wrote: > > Please update to r192360 and let me know if that helps. > > > Thanks, > Kip Hey, I (not the OP) am still having trouble with this. The panics appear to be gone since I set arc_min to 30M and arc_max to 100M, though (2GB RAM). I get/got them during a full zfs send -R | zfs recv -Fvd of a ~3.3GB pool. The only modification I've done to the source tree is the libzfs_sendrecv patch here: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html FreeBSD chaos.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed May 20 21:19:29 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/src/sys/ DTRACE amd64 (GENERIC + the 3 DTrace lines added) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8085e89a stack pointer = 0x28:0xffffff803ea4e4d0 frame pointer = 0x28:0xffffff803ea4e590 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1281 (zfs) vmstat -s from core.txt shows 388955 pages wired down - I take it that's 388955*4 kiB or almost 1.5GB out of 2GB. 110685 pages are still free, if that's relevant (I'm not sure why the crash occurs, but I guess it might be). Backtrace: #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80576089 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff805764dc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801d5a97 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801d5ea1 in db_command (last_cmdp=0xffffffff80bd7c20, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801d60f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801d8089 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805a6bb5 in kdb_trap (type=12, code=0, tf=0xffffff803ea4e420) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff808603bd in trap_fatal (frame=0xffffff803ea4e420, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #9 0xffffffff80860794 in trap_pfault (frame=0xffffff803ea4e420, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #10 0xffffffff80861283 in trap (frame=0xffffff803ea4e420) at /usr/src/sys/amd64/amd64/trap.c:494 #11 0xffffffff8083ae57 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #12 0xffffffff8085e89a in bzero () at /usr/src/sys/amd64/amd64/ support.S:64 #13 0xffffffff80e8aab1 in dbuf_read () from /boot/kernel/zfs.ko #14 0xffffffff80e8a12e in dmu_buf_rele () from /boot/kernel/zfs.ko #15 0xffffff0002e34460 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x000000003ea4e570 in ?? () #19 0xffffff003533c2d0 in ?? () #20 0xffffff803ea4e588 in ?? () #21 0xffffff8004619240 in ?? () #22 0xffffff00415591c0 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x000000044153f300 in ?? () #26 0x0000000000000000 in ?? () #27 0xffffff0002e34460 in ?? () #28 0x0000000000000005 in ?? () #29 0xffffff004153f300 in ?? () #30 0x0000000000000000 in ?? () #31 0x000000000000da01 in ?? () #32 0xffffff803ea4e5c0 in ?? () #33 0xffffffff80e963ea in dmu_tx_check_ioerr () from /boot/kernel/zfs.ko Regards, Thomas PS. I have the full core.txt if it'd help. DS. From owner-freebsd-current@FreeBSD.ORG Thu May 21 09:29:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14F710656E0; Thu, 21 May 2009 09:29:41 +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 BF3778FC19; Thu, 21 May 2009 09:29:41 +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 ESMTPS id 4FF4046B6C; Thu, 21 May 2009 05:29:41 -0400 (EDT) Date: Thu, 21 May 2009 10:29:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: arch@FreeBSD.org, rmacklem@FreeBSD.org Subject: HEADS UP: old UMich nfs4client to be removed, replaced with new NFSv234 client/server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 09:29:42 -0000 Dear all: This is advance warning that we'll be garbage-collecting the UMich NFSv4 client (src/sys/nfs4client and supporting RPC code, daemons, and mount tool) prior to 8.0 now that Rick Macklems NFSv234 client and server are in the base tree. This removal will likely be in the next week, as the 8.0 feature freeze is at the end of the month. The new client and server provide significantly improved support for NFSv4, and while they remain experimental, they should offer both more reliable, more complete, and actively maintained NFSv4 support. Anyone using nfs4client (probably not many) is encouraged to try out and provide feedback on the new NFSv4 code as soon as possible. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu May 21 10:36:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C7EB106564A; Thu, 21 May 2009 10:36:50 +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 77AD88FC19; Thu, 21 May 2009 10:36:50 +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 ESMTPS id 04F0846B17; Thu, 21 May 2009 06:36:50 -0400 (EDT) Date: Thu, 21 May 2009 11:36:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: Message-ID: References: <4A1460A3.2010202@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@uoguelph.ca, freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 10:36:50 -0000 On Wed, 20 May 2009, Robert Watson wrote: > On Wed, 20 May 2009, Andre Oppermann wrote: > >> While working on an optimized soreceive_stream() function [1] and checking >> the code how it is used I've come across quite a bit of code duplication in >> the various NFS directories. >> >> Socket (read) operations are handled multiple times in a very similar >> manner in these places: > > My recommendation would be to do this analysis against the new NFS client > and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, which is > the NFSv234 implementation. Note in particular that in the new world order > there's a centralize RPC implementation. > > The code you're looking at is a blend of the old NFSv23 client/server > (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if > which are on a gradual de-orbit burn. After re-reading this e-mail, I realize that I'd mislabeled src/sys/rpc as being only used by the old code -- this is in fact not the case, it's also used by the new code. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu May 21 11:15:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405271065673; Thu, 21 May 2009 11:15:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id EDB548FC12; Thu, 21 May 2009 11:15:00 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by itchy.rabson.org (Postfix, from userid 80) id A5CF25DBA; Thu, 21 May 2009 11:50:38 +0100 (BST) To: Robert Watson MIME-Version: 1.0 Date: Thu, 21 May 2009 11:50:38 +0100 From: Doug Rabson In-Reply-To: References: <4A1460A3.2010202@freebsd.org> Message-ID: X-Sender: dfr@rabson.org User-Agent: RoundCube Webmail/0.2.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: rmacklem@uoguelph.ca, Andre Oppermann , freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 11:15:01 -0000 On Thu, 21 May 2009 11:36:49 +0100 (BST), Robert Watson wrote: > On Wed, 20 May 2009, Robert Watson wrote: > >> On Wed, 20 May 2009, Andre Oppermann wrote: >> >>> While working on an optimized soreceive_stream() function [1] and >>> checking >>> the code how it is used I've come across quite a bit of code duplication >>> in >>> the various NFS directories. >>> >>> Socket (read) operations are handled multiple times in a very similar >>> manner in these places: >> >> My recommendation would be to do this analysis against the new NFS client >> >> and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, which >> is >> the NFSv234 implementation. Note in particular that in the new world >> order >> there's a centralize RPC implementation. >> >> The code you're looking at is a blend of the old NFSv23 client/server >> (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if >> which are on a gradual de-orbit burn. > > After re-reading this e-mail, I realize that I'd mislabeled src/sys/rpc as > being only used by the old code -- this is in fact not the case, it's also > used by the new code. Everything in src/sys/rpc except rpcclient.[ch] is part of the new RPC transport. The files rpcclient.c and rpcclient.h are part of the old broken NFSv4 client which is scheduled for removal. There is older RPC transport code in src/sys/nfsclient and src/sys/nfsserver which is currently used if the user uses the NFS_LEGACYRPC option. This too should be removed before 8.0 ships. From owner-freebsd-current@FreeBSD.ORG Thu May 21 11:48:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C207106566B for ; Thu, 21 May 2009 11:48:13 +0000 (UTC) (envelope-from tinkysama@mukaibo.com) Received: from outbound-mail-150.bluehost.com (outbound-mail-150.bluehost.com [67.222.38.40]) by mx1.freebsd.org (Postfix) with SMTP id 318C98FC1F for ; Thu, 21 May 2009 11:48:13 +0000 (UTC) (envelope-from tinkysama@mukaibo.com) Received: (qmail 3334 invoked by uid 0); 21 May 2009 11:21:33 -0000 Received: from unknown (HELO box477.bluehost.com) (74.220.219.77) by outboundproxy5.bluehost.com with SMTP; 21 May 2009 11:21:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=mukaibo.com; h=Received:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer:X-Identified-User; b=ad6eFQfFUcegNSUG6LvwU1AEO3gJsEro2EpOU4xbb/Yu2LQxEvpNmXn1jJiTcZw0g1Jg079HrQVyzBVGc3pokRDHrmzu6AvfK0jn6R7HKkao+ShNPJPHxlJZ92bnojnn; Received: from 12.41.233.220.exetel.com.au ([220.233.41.12] helo=[192.168.1.182]) by box477.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1M76L6-0007j3-QI for freebsd-current@freebsd.org; Thu, 21 May 2009 05:21:33 -0600 Message-Id: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> From: Timothy Mukaibo To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 21 May 2009 21:21:27 +1000 X-Mailer: Apple Mail (2.928.1) X-Identified-User: {2165:box477.bluehost.com:mukaiboc:mukaibo.com} {sentby:smtp auth 220.233.41.12 authed with timothy+mukaibo.com} Subject: ACPI Panic on Current, AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 11:48:13 -0000 Hello there, I've tried to boot 2009-05-20 AMD64 current, but it crashes out. I can't produce a full dmesg as the screen scrolls too quickly for me type, and I don't have a serial console. If there's any other way to capture the full dmesg, please let me know. This is as much as I can see: ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a000 (3) failed acpi0: reservation of 100000, bfdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acip_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 panic: Assertion link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ failed at /usr/src/sys/dev/acpica/acpi_pci_link.c:744 cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3d: movq $0,0x677da0(%rip) db> System hardware: CPU: AMD X2 4600 Motherboard: Foxconn C51XEM2AA. Latest BIOS. Uses the Nvidia Nforce 590 SLI chipset RAM: 2x1GB 533MHz modules, 1x1GB 800MHz module The system works under 7.2-Stable, hower the first 4 sata ports don't detect hdds (the last two do), but are present in atacontrol. I was hoping this was fixed in current, which is why I downloaded the snapshot. Please let me know what other information I can provide. Kind regards, Timothy. From owner-freebsd-current@FreeBSD.ORG Thu May 21 12:57:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 302F81065673 for ; Thu, 21 May 2009 12:57:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id D8FB28FC08 for ; Thu, 21 May 2009 12:57:05 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=SqXJ2v9DoQwSZDdvYbcgxKBqS9sH6t54BIWIxAtcBS1bVD2qBj2DEudwUvTQhroCz+5Bh/wlYlwHZwP2fNFl0oolkChsWGJTeP71LJtkllGuiMH/avwCVEe+s7XpmqrtaKy7hEskLfGkA23L4/MoxiI58Cno+iCzoX5ie5JkKrg=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M77pX-000JyG-RP; Thu, 21 May 2009 16:57:03 +0400 Date: Thu, 21 May 2009 16:57:01 +0400 From: Eygene Ryabinkin To: Timothy Mukaibo Message-ID: References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: ACPI Panic on Current, AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 12:57:06 -0000 Timothy, good day. Thu, May 21, 2009 at 09:21:27PM +1000, Timothy Mukaibo wrote: > I've tried to boot 2009-05-20 AMD64 current, but it crashes out. I > can't produce a full dmesg as the screen scrolls too quickly for me > type, and I don't have a serial console. If there's any other way to > capture the full dmesg, please let me know. This is as much as I can > see: > > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a000 (3) failed > acpi0: reservation of 100000, bfdf0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acip_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > panic: Assertion link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ > failed at /usr/src/sys/dev/acpica/acpi_pci_link.c:744 > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3d: movq $0,0x677da0(%rip) > db> I like to be wrong, but since at the time of the panic your disk subsystem isn't yet initialized, you can't make crashdump. The best way it still to get serial console working. The first thing that you can try is to type 'bt' (without quotes) at the 'db>' prompt and present the backtrace. The second thing to try if you can compile your own kernel (you can do in on the 7.x partition, just compile kernel for 8-CURRENT, set it to boot with nextboot(8) and try to load the kernel) -- you can try to add the following simple patch to see what device provokes assertion: ----- --- sys/dev/acpica/acpi_pci_link.c.orig 2009-05-21 16:43:49.000000000 +0400 +++ sys/dev/acpica/acpi_pci_link.c 2009-05-21 16:54:59.000000000 +0400 @@ -740,6 +740,8 @@ resptr = NULL; break; case ACPI_RESOURCE_TYPE_IRQ: + acpi_pci_link_dump(sc, 1, "MPASS"); + printf("link type is %d\n", link->l_prs_template.Type); MPASS(i < sc->pl_num_links); MPASS(link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ); newres = link->l_prs_template; ----- And, perhaps, the output from 'acpidump -dt' will be interesting. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Thu May 21 14:33:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33917106566C; Thu, 21 May 2009 14:33:22 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D72348FC19; Thu, 21 May 2009 14:33:21 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4LEXK4F066652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2009 07:33:21 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A156630.5080507@freebsd.org> Date: Thu, 21 May 2009 07:33:20 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Doug Rabson References: <4A1460A3.2010202@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Andre Oppermann , rmacklem@uoguelph.ca, Robert Watson , freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 14:33:22 -0000 Doug Rabson wrote: > On Thu, 21 May 2009 11:36:49 +0100 (BST), Robert Watson > wrote: > >> On Wed, 20 May 2009, Robert Watson wrote: >> >> >>> On Wed, 20 May 2009, Andre Oppermann wrote: >>> >>> >>>> While working on an optimized soreceive_stream() function [1] and >>>> checking >>>> the code how it is used I've come across quite a bit of code >>>> > duplication > >>>> in >>>> the various NFS directories. >>>> >>>> Socket (read) operations are handled multiple times in a very similar >>>> manner in these places: >>>> >>> My recommendation would be to do this analysis against the new NFS >>> > client > >>> and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, >>> > which > >>> is >>> the NFSv234 implementation. Note in particular that in the new world >>> order >>> there's a centralize RPC implementation. >>> >>> The code you're looking at is a blend of the old NFSv23 client/server >>> (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if >>> which are on a gradual de-orbit burn. >>> >> After re-reading this e-mail, I realize that I'd mislabeled src/sys/rpc >> > as > >> being only used by the old code -- this is in fact not the case, it's >> > also > >> used by the new code. >> > > Everything in src/sys/rpc except rpcclient.[ch] is part of the new RPC > transport. The files rpcclient.c and rpcclient.h are part of the old broken > NFSv4 client which is scheduled for removal. > > There is older RPC transport code in src/sys/nfsclient and > src/sys/nfsserver which is currently used if the user uses the > NFS_LEGACYRPC option. This too should be removed before 8.0 ships. > NFS_LEGACYRPC is the only code that works reliably for me on xscale (BE arm). The new code randomly causes alignment faults. I've not had time to track down this problem but gonzo@ also reported this problem on mips and I believe sent you a line# and stack trace of a fault. Until this problem is fixed removing legacy support cannot happen. Sam From owner-freebsd-current@FreeBSD.ORG Thu May 21 14:41:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63221065680 for ; Thu, 21 May 2009 14:41:19 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from packrat.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 917438FC26 for ; Thu, 21 May 2009 14:41:19 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.3/8.14.3) with ESMTP id n4LEfGbM074404; Thu, 21 May 2009 09:41:16 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.3/8.14.3/Submit) with ESMTP id n4LEfFPH074401; Thu, 21 May 2009 09:41:16 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Thu, 21 May 2009 09:41:15 -0500 (CDT) From: Greg Rivers To: Hans Petter Selasky In-Reply-To: <200905210843.09606.hselasky@c2i.net> Message-ID: References: <200905210843.09606.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: USB-to-serial adapter works on -STABLE but not -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 14:41:20 -0000 On Thu, 21 May 2009, Hans Petter Selasky wrote: > There seems to be a minor probe information error in the umct driver. > Try this patch: > > http://perforce.freebsd.org/chv.cgi?CH=162438 > > --HPS > This patch works. Thanks! -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Thu May 21 14:53:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F42C1065687; Thu, 21 May 2009 14:53:19 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0C82F8FC26; Thu, 21 May 2009 14:53:18 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by itchy.rabson.org (Postfix, from userid 80) id 1031E5DBA; Thu, 21 May 2009 15:53:56 +0100 (BST) To: Sam Leffler MIME-Version: 1.0 Date: Thu, 21 May 2009 15:53:56 +0100 From: Doug Rabson In-Reply-To: <4A156630.5080507@freebsd.org> References: <4A1460A3.2010202@freebsd.org> <4A156630.5080507@freebsd.org> Message-ID: X-Sender: dfr@rabson.org User-Agent: RoundCube Webmail/0.2.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: Andre Oppermann , rmacklem@uoguelph.ca, Robert Watson , freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 14:53:20 -0000 On Thu, 21 May 2009 07:33:20 -0700, Sam Leffler wrote: > Doug Rabson wrote: >> On Thu, 21 May 2009 11:36:49 +0100 (BST), Robert Watson >> wrote: >> >>> On Wed, 20 May 2009, Robert Watson wrote: >>> >>> >>>> On Wed, 20 May 2009, Andre Oppermann wrote: >>>> >>>> >>>>> While working on an optimized soreceive_stream() function [1] and >>>>> checking >>>>> the code how it is used I've come across quite a bit of code >>>>> >> duplication >> >>>>> in >>>>> the various NFS directories. >>>>> >>>>> Socket (read) operations are handled multiple times in a very similar >>>>> manner in these places: >>>>> >>>> My recommendation would be to do this analysis against the new NFS >>>> >> client >> >>>> and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, >>>> >> which >> >>>> is >>>> the NFSv234 implementation. Note in particular that in the new world >>>> order >>>> there's a centralize RPC implementation. >>>> >>>> The code you're looking at is a blend of the old NFSv23 client/server >>>> (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if >>>> >>>> which are on a gradual de-orbit burn. >>>> >>> After re-reading this e-mail, I realize that I'd mislabeled src/sys/rpc >>> >> as >> >>> being only used by the old code -- this is in fact not the case, it's >>> >> also >> >>> used by the new code. >>> >> >> Everything in src/sys/rpc except rpcclient.[ch] is part of the new RPC >> transport. The files rpcclient.c and rpcclient.h are part of the old >> broken >> NFSv4 client which is scheduled for removal. >> >> There is older RPC transport code in src/sys/nfsclient and >> src/sys/nfsserver which is currently used if the user uses the >> NFS_LEGACYRPC option. This too should be removed before 8.0 ships. >> > > NFS_LEGACYRPC is the only code that works reliably for me on xscale (BE > arm). The new code randomly causes alignment faults. I've not had time > to track down this problem but gonzo@ also reported this problem on mips > and I believe sent you a line# and stack trace of a fault. Until this > problem is fixed removing legacy support cannot happen. I'm aware of this one but I'm not exactly certain where the problem is. I did spend some time dredging through email archives trying to find out without success. I have a good idea where the bug is but I'd like to see at least one stacktrace or similar which confirms my suspicion before I commit a fix. When I get home, I'll take another look and see if I can find your original report. I'm certainly not going to be removing the NFS_LEGACYRPC option until this is fixed. From owner-freebsd-current@FreeBSD.ORG Thu May 21 15:06:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 225E5106564A for ; Thu, 21 May 2009 15:06:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay11.ispgateway.de (smtprelay11.ispgateway.de [80.67.31.45]) by mx1.freebsd.org (Postfix) with ESMTP id D2A738FC1C for ; Thu, 21 May 2009 15:06:44 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.132.243] (helo=localhost) by smtprelay11.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1M79r1-0003dg-GZ for freebsd-current@freebsd.org; Thu, 21 May 2009 17:06:43 +0200 Date: Thu, 21 May 2009 17:06:37 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090521170637.73619418@fabiankeil.de> In-Reply-To: <4A11A08B.6090309@errno.com> References: <4A11A08B.6090309@errno.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/B24wT_Ipm3avrLRq2dxiOuw"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:06:45 -0000 --Sig_/B24wT_Ipm3avrLRq2dxiOuw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sam Leffler wrote: > In sweeping the drivers to do these changes I've made radiotap support=20 > more consistent and improved some drivers. Drivers not tested so far:=20 > malo, ipw, wpi, and upgt. I tested iwi and it appears broken in that no= =20 > frames are rx'd but I'm not sure I'll look at it before 8.0. I'm not sure I understand you correctly. Are you saying iwi is known to be completely broken and unlikely to get fixed in the near future, or are you only talking about the monitor mode? =20 > I plan to commit these changes by the end of the week. With r192468 I can no longer get iwi to associate to the AP. "ifconfig wlan0 list scan" shows the AP, but S:N is listed as -95:-95 (IIRC). It works with the old kernel from May 15 14:37:49 CEST (and the new userlan= d). Fabian --Sig_/B24wT_Ipm3avrLRq2dxiOuw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoVbgIACgkQBYqIVf93VJ0pbwCgyUESzCffray+IoskzDsV+GdS wMcAoKPhGW7FCGCI3R0moGErCOtZ8YTH =9kAE -----END PGP SIGNATURE----- --Sig_/B24wT_Ipm3avrLRq2dxiOuw-- From owner-freebsd-current@FreeBSD.ORG Thu May 21 15:10:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67AC106566C for ; Thu, 21 May 2009 15:10:17 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAC28FC13 for ; Thu, 21 May 2009 15:10:17 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4LFAEGu066924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2009 08:10:15 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A156ED6.5060801@freebsd.org> Date: Thu, 21 May 2009 08:10:14 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Fabian Keil References: <4A11A08B.6090309@errno.com> <20090521170637.73619418@fabiankeil.de> In-Reply-To: <20090521170637.73619418@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:10:18 -0000 Fabian Keil wrote: > Sam Leffler wrote: > > >> In sweeping the drivers to do these changes I've made radiotap support >> more consistent and improved some drivers. Drivers not tested so far: >> malo, ipw, wpi, and upgt. I tested iwi and it appears broken in that no >> frames are rx'd but I'm not sure I'll look at it before 8.0. >> > > I'm not sure I understand you correctly. Are you saying iwi is > known to be completely broken and unlikely to get fixed in the > near future, or are you only talking about the monitor mode? > monitor mode did not work as expected for on my 2195 (I saw no packets received). > > >> I plan to commit these changes by the end of the week. >> > > With r192468 I can no longer get iwi to associate to the AP. > "ifconfig wlan0 list scan" shows the AP, but S:N is listed > as -95:-95 (IIRC). > > It works with the old kernel from May 15 14:37:49 CEST (and the new userland). > I will have to test later; these changes should not have affected sta mode operation. The kernel changes did not require rebuilding world. Sam From owner-freebsd-current@FreeBSD.ORG Thu May 21 16:04:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B82D106566B for ; Thu, 21 May 2009 16:04:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E25AA8FC12 for ; Thu, 21 May 2009 16:04:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAG8WFUqDaFvK/2dsb2JhbACOBQHERoQJBQ X-IronPort-AV: E=Sophos;i="4.41,228,1241409600"; d="scan'208";a="34060986" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 May 2009 11:54:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 1B76C109C257 for ; Thu, 21 May 2009 11:54:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S31tRoruXnlZ for ; Thu, 21 May 2009 11:54:49 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 693A5109C24A for ; Thu, 21 May 2009 11:54:49 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4LFtX407682 for ; Thu, 21 May 2009 11:55:33 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 21 May 2009 11:55:33 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: review of changes to mountd.c to add experimental server support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 16:04:22 -0000 In case anyone would like to review them, here are my proposed changes to src/usr.sbin/mountd.c so that it supports the experimental server as well as the regular one. It will run the experimental server if that is the only one loaded into the kernel or the "-4" option is specified on the command line. It parses one additional line in the exports file, which defines where the root of the nfsv4 file system is. This line is parsed but ignored for the regular server. Thanks in advance for any comments, rick --- diff -u mountd.c --- --- freebsd-svn/usr-src/usr.sbin/mountd/mountd.c 2009-05-17 15:59:31.000000000 -0400 +++ usr-src/usr.sbin/mountd/mountd.c 2009-05-19 09:47:58.000000000 -0400 @@ -61,7 +61,9 @@ #include #include #include +#include #include +#include #include @@ -200,6 +202,7 @@ struct sockaddr *samask); int scan_tree(struct dirlist *, struct sockaddr *); static void usage(void); +void parse_v4root(char *, char *, int, struct xucred *); int xdr_dir(XDR *, char *); int xdr_explist(XDR *, caddr_t); int xdr_explist_brief(XDR *, caddr_t); @@ -233,6 +236,10 @@ int opt_flags; static int have_v6 = 1; +int v4root_phase = 0; +int run_v4server = 0; +int has_publicfh = 0; + struct pidfh *pfh = NULL; /* Bits for opt_flags above */ #define OP_MAPROOT 0x01 @@ -288,17 +295,15 @@ have_v6 = 0; else close(s); - if (modfind("nfsserver") < 0) { - /* Not present in kernel, try loading it */ - if (kldload("nfsserver") < 0 || modfind("nfsserver") < 0) - errx(1, "NFS server is not available or loadable"); - } - while ((c = getopt(argc, argv, "2dh:lnp:r")) != -1) + while ((c = getopt(argc, argv, "24dh:lnp:r")) != -1) switch (c) { case '2': force_v2 = 1; break; + case '4': + run_v4server = 1; + break; case 'n': resvport_only = 0; break; @@ -343,6 +348,26 @@ default: usage(); }; + + /* + * If the "-4" option was specified OR only the nfsd module is + * found in the server, run "nfsd". + * Otherwise, try and run "nfsserver". + */ + if (run_v4server > 0) { + if (modfind("nfsd") < 0) { + /* Not present in kernel, try loading it */ + if (kldload("nfsd") < 0 || modfind("nfsd") < 0) + errx(1, "NFS server is not available"); + } + } else if (modfind("nfsserver") < 0 && modfind("nfsd") >= 0) { + run_v4server = 1; + } else if (modfind("nfsserver") < 0) { + /* Not present in kernel, try loading it */ + if (kldload("nfsserver") < 0 || modfind("nfsserver") < 0) + errx(1, "NFS server is not available"); + } + argc -= optind; argv += optind; grphead = (struct grouplist *)NULL; @@ -707,7 +732,7 @@ usage() { fprintf(stderr, - "usage: mountd [-2] [-d] [-l] [-n] [-p ] [-r] " + "usage: mountd [-2] [-4] [-d] [-l] [-n] [-p ] [-r] " "[-h ] [export_file ...]\n"); exit(1); } @@ -1166,6 +1191,26 @@ ep = (struct exportlist *)NULL; /* + * Handle the V4 root dir. + */ + if (*cp == 'V' && *(cp + 1) == '4' && *(cp + 2) == ':') { + /* + * V4: just indicates that it is the v4 root point, + * so skip over that and set v4root_phase. + */ + if (v4root_phase > 0) { + syslog(LOG_ERR, "V4:duplicate line, ignored"); + goto nextline; + } + v4root_phase = 1; + cp += 3; + nextfield(&cp, &endcp); + if (run_v4server > 0) + parse_v4root(cp, endcp, exflags, &anon); + goto nextline; + } + + /* * Create new exports list entry */ len = endcp-cp; @@ -1382,7 +1427,9 @@ int dirplen, num, i; int iovlen; int done; + struct nfsex_args eargs; + v4root_phase = 0; bzero(&export, sizeof(export)); export.ex_flags = MNT_DELEXPORT; dirp = NULL; @@ -1411,6 +1458,21 @@ grphead = (struct grouplist *)NULL; /* + * and the old V4 root dir. + */ + bzero(&eargs, sizeof (eargs)); + eargs.export.ex_flags = MNT_DELEXPORT; + if (run_v4server > 0 && + nfssvc(NFSSVC_V4ROOTEXPORT, (caddr_t)&eargs) < 0 && + errno != ENOENT) + syslog(LOG_ERR, "Can't delete exports for V4:"); + + /* + * and clear flag that notes if a public fh has been exported. + */ + has_publicfh = 0; + + /* * And delete exports that are in the kernel for all local * filesystems. * XXX: Should know how to handle all local exportable filesystems. @@ -1491,6 +1553,12 @@ syslog(LOG_ERR, "can't open any exports file"); exit(2); } + + /* + * If there was no public fh, clear any previous one set. + */ + if (run_v4server > 0 && has_publicfh == 0) + (void) nfssvc(NFSSVC_NOPUBLICFH, NULL); } /* @@ -1936,6 +2004,12 @@ syslog(LOG_ERR, "bad opt %s", cpopt); return (1); } + if (v4root_phase == 1 && + ((*exflagsp & ~MNT_EXPORTED) || + (opt_flags & ~OP_SEC))) { + syslog(LOG_ERR, "Bad opt %s on V4:", cpopt); + return (1); + } if (usedarg >= 0) { *endcp = savedc2; **endcpp = savedc; @@ -2233,6 +2307,29 @@ goto error_exit; } } + + /* + * For the experimental server: + * If this is the public directory, get the file handle + * and load it into the kernel via the nfssvc() syscall. + */ + if (run_v4server > 0 && (exflags & MNT_EXPUBLIC) != 0) { + fhandle_t fh; + char *public_name; + + if (eap.ex_indexfile != NULL) + public_name = eap.ex_indexfile; + else + public_name = dirp; + if (getfh(public_name, &fh) < 0) + syslog(LOG_ERR, + "Can't get public fh for %s", public_name); + else if (nfssvc(NFSSVC_PUBLICFH, (caddr_t)&fh) < 0) + syslog(LOG_ERR, + "Can't set public fh for %s", public_name); + else + has_publicfh = 1; + } skip: if (ai != NULL) ai = ai->ai_next; @@ -2688,7 +2785,7 @@ struct dirlist *dp; { - if (dp == (struct dirlist *)NULL) + if (v4root_phase != 1 && dp == NULL) return (1); if ((opt_flags & (OP_MAPROOT | OP_MAPALL)) == (OP_MAPROOT | OP_MAPALL)) { syslog(LOG_ERR, "-mapall and -maproot mutually exclusive"); @@ -2710,6 +2807,12 @@ syslog(LOG_ERR, "-alldirs has multiple directories"); return (1); } + if (v4root_phase == 1) { + if ((opt_flags & ~OP_SEC) != 0) { + syslog(LOG_ERR, "only -sec option allowed on V4:"); + return (1); + } + } return (0); } @@ -2871,3 +2974,86 @@ rpcb_unset(RPCPROG_MNT, RPCMNT_VER3, NULL); exit (0); } + +/* + * Parse the V4: line. + */ +void +parse_v4root(char *cp, char *endcp, int exflags, struct xucred *anonp) +{ + char *dirp, savedc; + struct grouplist gr; + struct exportlist ea; + struct nfsex_args nfsea; + int len, has_host, i; + + exflags = MNT_EXPORTED; + bzero(&nfsea, sizeof (nfsea)); + bzero(&ea, sizeof (ea)); + bzero(&gr, sizeof (gr)); + dirp = NULL; + len = endcp - cp; + while (len > 0) { + if (len > RPCMNT_NAMELEN) { + syslog(LOG_ERR, "V4: line too long, ignored"); + v4root_phase = 2; + return; + } + if (*cp == '-') { + if (debug) + warnx("doing opt %s", cp); + if (do_opt(&cp, &endcp, &ea, &gr, &has_host, + &exflags, anonp)) { + v4root_phase = 2; + return; + } + } else if (*cp == '/') { + savedc = *endcp; + *endcp = '\0'; + if (check_dirpath(cp)) { + if (dirp != NULL) { + syslog(LOG_ERR, "Multiple V4 dirs"); + v4root_phase = 2; + return; + } + dirp = cp; + } else { + syslog(LOG_ERR, "V4: dir %s invalid", cp); + v4root_phase = 2; + return; + } + *endcp = savedc; + } + cp = endcp; + nextfield(&cp, &endcp); + len = endcp - cp; + } + + /* Check the options */ + if (check_options(NULL)) { + v4root_phase = 2; + return; + } + + /* + * Now, do the nfssvc() syscall. + */ + nfsea.export.ex_flags = exflags; + nfsea.export.ex_anon = *anonp; + if (ea.ex_numsecflavors == 0) { + nfsea.export.ex_numsecflavors = 4; + nfsea.export.ex_secflavors[0] = AUTH_SYS; + nfsea.export.ex_secflavors[1] = RPCSEC_GSS_KRB5; + nfsea.export.ex_secflavors[2] = RPCSEC_GSS_KRB5I; + nfsea.export.ex_secflavors[3] = RPCSEC_GSS_KRB5P; + } else { + nfsea.export.ex_numsecflavors = ea.ex_numsecflavors; + for (i = 0; i < ea.ex_numsecflavors; i++) + nfsea.export.ex_secflavors[i] = ea.ex_secflavors[i]; + } + nfsea.fspec = dirp; + if (nfssvc(NFSSVC_V4ROOTEXPORT, (caddr_t)&nfsea) < 0) + syslog(LOG_ERR, "Exporting V4: failed"); + v4root_phase = 2; +} + From owner-freebsd-current@FreeBSD.ORG Thu May 21 16:19:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DE4106564A for ; Thu, 21 May 2009 16:19:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5B68FC32 for ; Thu, 21 May 2009 16:19:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAEMVFUqDaFvK/2dsb2JhbACOBQHEGoJBgUgF X-IronPort-AV: E=Sophos;i="4.41,228,1241409600"; d="scan'208";a="36194390" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 21 May 2009 11:50:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 9A838109C24A for ; Thu, 21 May 2009 11:50:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjz83jUTyDvX for ; Thu, 21 May 2009 11:50:25 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id CFA0B109C29F for ; Thu, 21 May 2009 11:50:25 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4LFp9q06973 for ; Thu, 21 May 2009 11:51:09 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 21 May 2009 11:51:09 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: review of changes to nfsd.c to add experimental server support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 16:19:32 -0000 In case anyone is interested in reviewing them, here are the changes I've proposed to src/usr.sbin/nfsd.c so that it supports the experimental server which handles nfsv4 as well as nfsv2,3 along with the regular server. It uses the experimental server if it is the only one loaded into the kernel or the "-4" option is specified on the command line. Thanks in advance for any comments, rick --- diff -u nfsd.c --- --- freebsd-svn/usr-src/usr.sbin/nfsd/nfsd.c 2009-05-17 15:59:55.000000000 -0400 +++ usr-src/usr.sbin/nfsd/nfsd.c 2009-05-21 11:33:32.000000000 -0400 @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -59,6 +60,7 @@ #include #include #include +#include #include #include @@ -77,11 +79,14 @@ int debug = 0; #endif +#define NFSD_STABLERESTART "/var/db/stablerestart" #define MAXNFSDCNT 256 #define DEFNFSDCNT 4 pid_t children[MAXNFSDCNT]; /* PIDs of children */ int nfsdcnt; /* number of children */ int new_syscall; +int run_v4server = 0; /* Force running of nfsv4 server */ +int nfssvc_nfsd; /* Set to correct NFSSVC_xxx flag */ void cleanup(int); void child_cleanup(int); @@ -112,6 +117,7 @@ * -d - unregister with rpcbind * -t - support tcp nfs clients * -u - support udp nfs clients + * -4 - forces it to run a server that supports nfsv4 * followed by "n" which is the number of nfsds' to fork off */ int @@ -131,20 +137,15 @@ int tcp6sock, ip6flag, tcpflag, tcpsock; int udpflag, ecode, s, srvcnt; int bindhostc, bindanyflag, rpcbreg, rpcbregcnt; + int stablefd, nfssvc_addsock; char **bindhost = NULL; pid_t pid; - if (modfind("nfsserver") < 0) { - /* Not present in kernel, try loading it */ - if (kldload("nfsserver") < 0 || modfind("nfsserver") < 0) - errx(1, "NFS server is not available"); - } - nfsdcnt = DEFNFSDCNT; unregister = reregister = tcpflag = maxsock = 0; bindanyflag = udpflag = connect_type_cnt = bindhostc = 0; -#define GETOPT "ah:n:rdtu" -#define USAGE "[-ardtu] [-n num_servers] [-h bindip]" +#define GETOPT "ah:n:rdtu4" +#define USAGE "[-ardtu4] [-n num_servers] [-h bindip]" while ((ch = getopt(argc, argv, GETOPT)) != -1) switch (ch) { case 'a': @@ -179,6 +180,9 @@ case 'u': udpflag = 1; break; + case '4': + run_v4server = 1; + break; default: case '?': usage(); @@ -203,6 +207,25 @@ } } + /* + * If the "-4" option was specified OR only the nfsd module is + * found in the server, run "nfsd". + * Otherwise, try and run "nfsserver". + */ + if (run_v4server > 0) { + if (modfind("nfsd") < 0) { + /* Not present in kernel, try loading it */ + if (kldload("nfsd") < 0 || modfind("nfsd") < 0) + errx(1, "NFS server is not available"); + } + } else if (modfind("nfsserver") < 0 && modfind("nfsd") >= 0) { + run_v4server = 1; + } else if (modfind("nfsserver") < 0) { + /* Not present in kernel, try loading it */ + if (kldload("nfsserver") < 0 || modfind("nfsserver") < 0) + errx(1, "NFS server is not available"); + } + ip6flag = 1; s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); if (s == -1) { @@ -328,15 +351,47 @@ openlog("nfsd", LOG_PID, LOG_DAEMON); /* - * Figure out if the kernel supports the new-style - * NFSSVC_NFSD. Old kernels will return ENXIO because they - * don't recognise the flag value, new ones will return EINVAL - * because argp is NULL. + * For V4, we open the stablerestart file and call nfssvc() + * to get it loaded. This is done before the daemons do the + * regular nfssvc() call to service NFS requests. + * (This way the file remains open until the last nfsd is killed + * off.) + * Note that this file is not created by this daemon and can + * only be relocated by recompiling the daemon, in order to + * minimize accidentally starting up with the wrong file. + * If should be created as an empty file Read and Write for + * root before the first time you run NFS v4 and should never + * be re-initialized if at all possible. It should live on a + * local, non-volatile storage device that does not do hardware + * level write-back caching. (See SCSI doc for more information + * on how to prevent write-back caching on SCSI disks.) */ - new_syscall = FALSE; - if (nfssvc(NFSSVC_NFSD, NULL) < 0 && errno == EINVAL) + if (run_v4server > 0) { + stablefd = open(NFSD_STABLERESTART, O_RDWR, 0); + if (stablefd < 0) { + syslog(LOG_ERR, "Can't open %s\n", NFSD_STABLERESTART); + exit(1); + } + if (nfssvc(NFSSVC_STABLERESTART, (caddr_t)&stablefd) < 0) { + syslog(LOG_ERR, "Can't read stable storage file\n"); + exit(1); + } + nfssvc_addsock = NFSSVC_NFSDADDSOCK; + nfssvc_nfsd = NFSSVC_NFSDNFSD; new_syscall = TRUE; - new_syscall = FALSE; + } else { + nfssvc_addsock = NFSSVC_ADDSOCK; + nfssvc_nfsd = NFSSVC_NFSD; + /* + * Figure out if the kernel supports the new-style + * NFSSVC_NFSD. Old kernels will return ENXIO because they + * don't recognise the flag value, new ones will return EINVAL + * because argp is NULL. + */ + new_syscall = FALSE; + if (nfssvc(NFSSVC_NFSD, NULL) < 0 && errno == EINVAL) + new_syscall = TRUE; + } if (!new_syscall) { /* If we use UDP only, we start the last server below. */ @@ -413,7 +468,7 @@ addsockargs.sock = sock; addsockargs.name = NULL; addsockargs.namelen = 0; - if (nfssvc(NFSSVC_ADDSOCK, &addsockargs) < 0) { + if (nfssvc(nfssvc_addsock, &addsockargs) < 0) { syslog(LOG_ERR, "can't Add UDP socket"); nfsd_exit(1); } @@ -481,7 +536,7 @@ addsockargs.sock = sock; addsockargs.name = NULL; addsockargs.namelen = 0; - if (nfssvc(NFSSVC_ADDSOCK, &addsockargs) < 0) { + if (nfssvc(nfssvc_addsock, &addsockargs) < 0) { syslog(LOG_ERR, "can't add UDP6 socket"); nfsd_exit(1); @@ -711,7 +766,7 @@ addsockargs.sock = msgsock; addsockargs.name = (caddr_t)&inetpeer; addsockargs.namelen = len; - nfssvc(NFSSVC_ADDSOCK, &addsockargs); + nfssvc(nfssvc_addsock, &addsockargs); (void)close(msgsock); } else if (FD_ISSET(tcpsock, &v6bits)) { len = sizeof(inet6peer); @@ -733,7 +788,7 @@ addsockargs.sock = msgsock; addsockargs.name = (caddr_t)&inet6peer; addsockargs.namelen = len; - nfssvc(NFSSVC_ADDSOCK, &addsockargs); + nfssvc(nfssvc_addsock, &addsockargs); (void)close(msgsock); } } @@ -861,19 +916,47 @@ void start_server(int master) { - char principal[128]; - char hostname[128]; + char principal[MAXHOSTNAMELEN + 5]; struct nfsd_nfsd_args nfsdargs; - int status; + int status, error; + char hostname[MAXHOSTNAMELEN + 1], *cp; + struct addrinfo *aip, hints; status = 0; if (new_syscall) { - gethostname(hostname, sizeof(hostname)); - snprintf(principal, sizeof(principal), "nfs@%s", hostname); + gethostname(hostname, sizeof (hostname)); + snprintf(principal, sizeof (principal), "nfs@%s", hostname); + if ((cp = strchr(hostname, '.')) == NULL || + *(cp + 1) == '\0') { + /* If not fully qualified, try getaddrinfo() */ + memset((void *)&hints, 0, sizeof (hints)); + hints.ai_flags = AI_CANONNAME; + error = getaddrinfo(hostname, NULL, &hints, &aip); + if (error == 0) { + if (aip->ai_canonname != NULL && + (cp = strchr(aip->ai_canonname, '.')) != + NULL && *(cp + 1) != '\0') + snprintf(principal, sizeof (principal), + "nfs@%s", aip->ai_canonname); + freeaddrinfo(aip); + } + } nfsdargs.principal = principal; nfsdargs.minthreads = nfsdcnt; nfsdargs.maxthreads = nfsdcnt; - if (nfssvc(NFSSVC_NFSD, &nfsdargs) < 0) { + error = nfssvc(nfssvc_nfsd, &nfsdargs); + if (error < 0 && errno == EAUTH) { + /* + * This indicates that it could not register the + * rpcsec_gss credentials, usually because the + * gssd daemon isn't running. + * (only the experimental server with nfsv4) + */ + syslog(LOG_ERR, "No gssd, using AUTH_SYS only"); + principal[0] = '\0'; + error = nfssvc(nfssvc_nfsd, &nfsdargs); + } + if (error < 0) { syslog(LOG_ERR, "nfssvc: %m"); status = 1; } From owner-freebsd-current@FreeBSD.ORG Thu May 21 16:54:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2CDC106564A for ; Thu, 21 May 2009 16:54:10 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6518FC15 for ; Thu, 21 May 2009 16:54:10 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:44057 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M7BWq-00007M-4N for freebsd-current@freebsd.org; Thu, 21 May 2009 18:54:02 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id DB7353477D for ; Thu, 21 May 2009 18:53:56 +0200 (CEST) Message-Id: <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> From: Thomas Backman To: freebsd-current@freebsd.org In-Reply-To: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 18:53:56 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M7BWq-00007M-4N. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M7BWq-00007M-4N c7bedfb053bd26a8e55269b312bbed48 Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 16:54:11 -0000 On May 13, 2009, at 03:19 PM, Thomas Backman wrote: > OK, so I first posted a thread on the forums about this in 7.2- > RELEASE: > http://forums.freebsd.org/showthread.php?t=3834 > Then filed a PR, kern/134408: > http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 > > The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) > GMT+2. > > Steps to reproduce: > 1) Build DTrace capable kernel (I followed the wiki DTrace > instructions) > 2) Reboot; kldload dtraceall > 3) dtrace -n 'syscall::open:entry { self->path = arg0; } > syscall::open:return { printf("%s\n", copyinstr(self->path)); }' > 4) Crash. > > Backtrace: > [root@vmware /usr/obj/usr/src/sys/DTRACE]# kgdb kernel.debug /var/ > crash/vmcore.3 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: from debugger > cpuid = 0 > Uptime: 3m10s > Physical memory: 368 MB > Dumping 81 MB: 66 50 34 18 2 > > Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols > from /boot/kernel/dtraceall.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtraceall.ko > Reading symbols from /boot/kernel/profile.ko...Reading symbols from / > boot/kernel/profile.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/profile.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols > from /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from / > boot/kernel/cyclic.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/cyclic.ko > Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from / > boot/kernel/dtrace.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtrace.ko > Reading symbols from /boot/kernel/systrace.ko...Reading symbols > from /boot/kernel/systrace.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/systrace.ko > Reading symbols from /boot/kernel/sdt.ko...Reading symbols from / > boot/kernel/sdt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sdt.ko > Reading symbols from /boot/kernel/fbt.ko...Reading symbols from / > boot/kernel/fbt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/fbt.ko > Reading symbols from /boot/kernel/dtnfsclient.ko...Reading symbols > from /boot/kernel/dtnfsclient.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtnfsclient.ko > Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols > from /boot/kernel/dtmalloc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/dtmalloc.ko > #0 doadump () at pcpu.h:223 > 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff80566b23 in boot (howto=260) at /usr/src/sys/kern/ > kern_shutdown.c:420 > #2 0xffffffff80566fac in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xffffffff801d3ef7 in db_panic (addr=Variable "addr" is not > available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801d43a1 in db_command (last_cmdp=0xffffffff80bd3620, > cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801d45f0 in db_command_loop () at /usr/src/sys/ddb/ > db_command.c:498 > #6 0xffffffff801d6599 in db_trap (type=Variable "type" is not > available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff80597135 in kdb_trap (type=10, code=0, > tf=0xfffffffe4e64e450) at /usr/src/sys/kern/subr_kdb.c:534 > #8 0xffffffff80843f81 in trap (frame=0xfffffffe4e64e450) at /usr/ > src/sys/amd64/amd64/trap.c:606 > #9 0xffffffff8081edc7 in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:223 > #10 0xffffffff8123c128 in dtrace_panic (format=Variable "format" is > not available. > ) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:601 > #11 0xffffffff8123c200 in dtrace_copycheck > (uaddr=18446744071581326184, kaddr=Variable "kaddr" is not available. > ) at dtrace_isa.c:527 > #12 0xffffffff8123c2bc in dtrace_copyinstr (uaddr=34365395808, > kaddr=18446744066201920856, size=256, > flags=0xffffffff8122f120) at dtrace_isa.c:558 > #13 0xffffffff81249e84 in dtrace_dif_emulate > (difo=0xffffff00026a2d80, mstate=0xfffffffe4e64ea00, > vstate=0xffffff0002548838, state=0xffffff0002548800) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:3446 > #14 0xffffffff8124b20a in dtrace_probe (id=Variable "id" is not > available. > ) > at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ > opensolaris/uts/common/dtrace/dtrace.c:6220 > #15 0xffffffff8137b155 in systrace_probe () from /boot/kernel/ > systrace.ko > #16 0xffffffff80843c4d in syscall (frame=0xfffffffe4e64ec90) at /usr/ > src/sys/amd64/amd64/trap.c:990 > #17 0xffffffff8081f050 in Xfast_syscall () at /usr/src/sys/amd64/ > amd64/exception.S:364 > #18 0x00000008005411fc in ?? () > Previous frame inner to this frame (corrupt stack?) > > Hope this helps to fix this bug - I assume syscall::open isn't the > only probe > affected as it's simply the very first one I tried. > > Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB > RAM; > and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and > 8.0. OK, a follow-up on this one... Let me preface it: WTF? OK, now that's out of my system. Well, not really. So, I'm not a programmer. I program mostly high-level languages (such as Objective-C/Cocoa for OS X, some python, perl etc) and have NO clue what I'm doing in kernel modules.... BUT... Being curious, I tried to see if I could add some printf statements to dtrace_copycheck() to see what it'd print before crashing. What happens? Well, this is what I changed (the types may well be screwed up - as I said, I'm not a competent C programmer! Heck, I can see right now that they are): In /sys/cddl/dev/dtrace/amd64/dtrace_isa.c: static int dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) { printf("in dtrace_copycheck(), pre-ASSERT:\n"); printf("kaddr = %u, kernelbase = %u, size = %d, kaddr+size = %u\n \n", (unsigned int)kaddr, (unsigned int)kernelbase, (unsigned int)size, (unsigned int)(kaddr+size)); ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); if (uaddr + size >= kernelbase || uaddr + size < uaddr) { ... So, I added two printf statements. What happens? IT BECOMES STABLE. How the hell does this happen? I figured "oh, someone must have fixed the bug!", commented my lines, unloaded the modules, recompiled, re- loaded "my" modules without printf... PANIC! I tried it again with the printf, and... it works. This deserves a big "WTF" in my opinion. Any clues as to what's going on here? In the meantime, I added printf("%s", ""); above the ASSERT line, which fixes the bug! I'm as confused as one can get here, could I get some insights as to why this works?! :-) Does having something above the ASSERT line make the assertion not execute? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu May 21 18:31:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C9F106564A for ; Thu, 21 May 2009 18:31:40 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 743948FC14 for ; Thu, 21 May 2009 18:31:40 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so755370ana.13 for ; Thu, 21 May 2009 11:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=f7o6xqKHNg0vzvHX6URNS/F2Dx2gQbYw4+nWi8BKpMQ=; b=sgQwwVCFFbuMLDh2csply0X8guoCPii+zGWmgn5tOl9kLTQKnHGY6T3X1TKpCWPVDJ GKE7u9mezW+5g+usn+41/ZlWeu9r+2iQmI2jGE9QdzBT7HIt/Ba6EzE85LFqImXsFKjg E8Syx+91Zgvhk1K3hsz8zZxQ3/d5LXPjVQZWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GQa4NUQRg0M75upM1MHDkfdiEKO94ezkyljFRE77d7LPAxLSo8ogA05lpKH0WcuZ4z 6MrB7+eyiT1DfOCpR9qzP7xZZBMJ/Uly9SdJmMKMS82tIJY2RYxG/G96pUdd46fgV0Xa R1MGDdA8/uECWaYJMXA+1oHP930w1xDtCPe1c= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.47.10 with SMTP id u10mr5620052anu.17.1242930699150; Thu, 21 May 2009 11:31:39 -0700 (PDT) In-Reply-To: References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> Date: Thu, 21 May 2009 11:31:38 -0700 X-Google-Sender-Auth: daa477fd119c91fd Message-ID: <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> From: Kip Macy To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 18:31:41 -0000 > Hey, I (not the OP) am still having trouble with this. The panics appear = to > be gone since I set arc_min to 30M and arc_max to 100M, though (2GB RAM). > I get/got them during a full zfs send -R | zfs recv -Fvd of a ~3.3GB pool= . > The only modification I've done to the source tree is the libzfs_sendrecv > patch here: > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html I'll apply the patch this weekend. If I get time I'll also try to reproduce your panic. Thanks, Kip > > FreeBSD chaos.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed May 20 > 21:19:29 CEST 2009 =A0 =A0 root@chaos.exscape.org:/usr/obj/usr/src/sys/DT= RACE > =A0amd64 > (GENERIC + the 3 DTrace lines added) > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x0 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page not= present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff8085e89a > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803ea4e4d0 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803ea4e590 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 1281 (zfs) > > vmstat -s from core.txt shows 388955 pages wired down - I take it that's > 388955*4 kiB or almost 1.5GB out of 2GB. 110685 pages are still free, if > that's relevant (I'm not sure why the crash occurs, but I guess it might > be). > > Backtrace: > #0 =A0doadump () at pcpu.h:223 > 223 =A0 =A0 pcpu.h: No such file or directory. > =A0 =A0 =A0 =A0in pcpu.h > (kgdb) #0 =A0doadump () at pcpu.h:223 > #1 =A00xffffffff80576089 in boot (howto=3D260) > =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:420 > #2 =A00xffffffff805764dc in panic (fmt=3DVariable "fmt" is not available. > ) > =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:576 > #3 =A00xffffffff801d5a97 in db_panic (addr=3DVariable "addr" is not avail= able. > ) > =A0 =A0at /usr/src/sys/ddb/db_command.c:478 > #4 =A00xffffffff801d5ea1 in db_command (last_cmdp=3D0xffffffff80bd7c20, > cmd_table=3DVariable "cmd_table" is not available. > > ) at /usr/src/sys/ddb/db_command.c:445 > #5 =A00xffffffff801d60f0 in db_command_loop () > =A0 =A0at /usr/src/sys/ddb/db_command.c:498 > #6 =A00xffffffff801d8089 in db_trap (type=3DVariable "type" is not availa= ble. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 =A00xffffffff805a6bb5 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff8= 03ea4e420) > =A0 =A0at /usr/src/sys/kern/subr_kdb.c:534 > #8 =A00xffffffff808603bd in trap_fatal (frame=3D0xffffff803ea4e420, eva= =3DVariable > "eva" is not available. > ) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:847 > #9 =A00xffffffff80860794 in trap_pfault (frame=3D0xffffff803ea4e420, user= mode=3D0) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:768 > #10 0xffffffff80861283 in trap (frame=3D0xffffff803ea4e420) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:494 > #11 0xffffffff8083ae57 in calltrap () > =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:223 > #12 0xffffffff8085e89a in bzero () at /usr/src/sys/amd64/amd64/support.S:= 64 > #13 0xffffffff80e8aab1 in dbuf_read () from /boot/kernel/zfs.ko > #14 0xffffffff80e8a12e in dmu_buf_rele () from /boot/kernel/zfs.ko > #15 0xffffff0002e34460 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x000000003ea4e570 in ?? () > #19 0xffffff003533c2d0 in ?? () > #20 0xffffff803ea4e588 in ?? () > #21 0xffffff8004619240 in ?? () > #22 0xffffff00415591c0 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x000000044153f300 in ?? () > #26 0x0000000000000000 in ?? () > #27 0xffffff0002e34460 in ?? () > #28 0x0000000000000005 in ?? () > #29 0xffffff004153f300 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x000000000000da01 in ?? () > #32 0xffffff803ea4e5c0 in ?? () > #33 0xffffffff80e963ea in dmu_tx_check_ioerr () from /boot/kernel/zfs.ko > > Regards, > Thomas > > PS. I have the full core.txt if it'd help. DS. > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Thu May 21 18:48:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C746A106566B for ; Thu, 21 May 2009 18:48:02 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by mx1.freebsd.org (Postfix) with ESMTP id 836848FC0C for ; Thu, 21 May 2009 18:48:01 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.132.243] (helo=localhost) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1M7DJA-0000f8-Bq for freebsd-current@freebsd.org; Thu, 21 May 2009 20:48:00 +0200 Date: Thu, 21 May 2009 20:47:52 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090521204752.43aa3adc@fabiankeil.de> In-Reply-To: <20090521170637.73619418@fabiankeil.de> References: <4A11A08B.6090309@errno.com> <20090521170637.73619418@fabiankeil.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/_NDFLh_SzsW1ga=Fdlt6NXn"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 18:48:03 -0000 --Sig_/_NDFLh_SzsW1ga=Fdlt6NXn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > With r192468 I can no longer get iwi to associate to the AP. > "ifconfig wlan0 list scan" shows the AP, but S:N is listed > as -95:-95 (IIRC). Fixed in r192541. Fabian --Sig_/_NDFLh_SzsW1ga=Fdlt6NXn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoVod8ACgkQBYqIVf93VJ27XQCgkLvc9exgxqyy4nvUDXBjy+QE Ze0AnjAfxwF/tuKcKq+egRkRN/fkfKze =3y5G -----END PGP SIGNATURE----- --Sig_/_NDFLh_SzsW1ga=Fdlt6NXn-- From owner-freebsd-current@FreeBSD.ORG Thu May 21 18:48:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E981065676 for ; Thu, 21 May 2009 18:48:33 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 481D08FC16 for ; Thu, 21 May 2009 18:48:33 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by ewy3 with SMTP id 3so1440324ewy.43 for ; Thu, 21 May 2009 11:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tk/sLjrjg/4p8kLFnMYnRugQpRlw/GJrH1D4f4lUye4=; b=Xle2B+ghekDAoKIZ7cnEDkG+jEF7Ur375TUImj5GJypv88OYJ18wuuoyIaMEm+aUOP 8LqQOywG786hlHcPNllQkzp+PJIpFvEjmW+Ei/6I/vVaFr2ry/yMQGBH+PtINfRZzZ1g ZUnwZye3pDeGncJfzG65APddwQJfPGSilcU8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DEjkJWCMvaZ9qBH858mH0xonp0D46YITL+MuayRrsKtMRYVbuCJOtdtn2rgY+lVMdZ 6vBCev+MuLe0JerDa4p8qH9uVfxyU1B/36fOqj0JKdgVpxtGdIFRVNngtNIlZWvMSYxC h8zZRD0W7YZgnQAW5PVMcX67CbfIJsyTWAU0c= MIME-Version: 1.0 Received: by 10.216.29.66 with SMTP id h44mr597234wea.136.1242931712030; Thu, 21 May 2009 11:48:32 -0700 (PDT) In-Reply-To: <90a5caac0905191127y5677bea9s827bb3d6a9f82176@mail.gmail.com> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <4A0F419A.2020700@freebsd.org> <20090519050132.GE42412@weongyo.cdnetworks.kr> <200905190916.06460.hselasky@c2i.net> <90a5caac0905191127y5677bea9s827bb3d6a9f82176@mail.gmail.com> Date: Thu, 21 May 2009 13:48:31 -0500 Message-ID: <11167f520905211148u34071232hbf95e45ca373708f@mail.gmail.com> From: "Sam Fourman Jr." To: Lucius Windschuh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 18:48:34 -0000 I have a uath device the Engenius NUB-362-EXT, it will not attach to the uath driver it says ugen7.3: at usbus7 I should note that this device attaches in OpenBSD 4.x I am running FreeBSD 8 -CURRENT as of 10 hours ago, I do not know the usb2 equivalent of usbdevs -v I am confused as to why this device will not attach to uath, I have the driver loaded with kldload if_uath I do not know if this will help, but here is output from OpenBSD 4.5 after you plugin the device I get: uath0 at uhub0 port 5 "Atheros Communications Inc AR5523" rev 2.00/0.01 addr 2 uath0 detached uath0 at uhub0 port 5 "Atheros Communications Inc AR5523" rev 2.00/0.01 addr 2 uath0: MAC/BBP AR5523, RF AR2112, address 00:02:6f:3d:66:58 usbdevs -v Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x8086), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 2: high speed, power 500 mA, config 1, AR5523(0x0001), Atheros Communications Inc(0x0cf3), rev 0.01, iSerialNumber 1.0 port 6 powered port 7 powered port 8 powered Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Thu May 21 19:29:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA04106566C for ; Thu, 21 May 2009 19:29:51 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id B64318FC20 for ; Thu, 21 May 2009 19:29:51 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id CFA637E837; Thu, 21 May 2009 11:29:49 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Thu, 21 May 2009 21:29:47 +0200 User-Agent: KMail/1.11.3 (FreeBSD/8.0-CURRENT; KDE/4.2.3; i386; ; ) References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> In-Reply-To: <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Thomas Backman Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 19:29:52 -0000 On Thursday 21 May 2009 18:53:56 Thomas Backman wrote: > On May 13, 2009, at 03:19 PM, Thomas Backman wrote: > > #11 0xffffffff8123c200 in dtrace_copycheck > > (uaddr=18446744071581326184, kaddr=Variable "kaddr" is not available. > > ) at dtrace_isa.c:527 > In /sys/cddl/dev/dtrace/amd64/dtrace_isa.c: > static int > dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) > { > printf("in dtrace_copycheck(), pre-ASSERT:\n"); > printf("kaddr = %u, kernelbase = %u, size = %d, kaddr+size = %u\n > \n", > (unsigned int)kaddr, (unsigned int)kernelbase, (unsigned > int)size, (unsigned int)(kaddr+size)); > ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); > > if (uaddr + size >= kernelbase || uaddr + size < uaddr) { > ... > > So, I added two printf statements. What happens? IT BECOMES STABLE. I'm no kernel hacker, but.. if you apply the patch below, does it still panic? Make sure to get rid of the printf() you added. The theory behind this patch is that kernbase isn't initialized at the time of that assert, yet code from printf initializes it. --- dtrace_isa.c.orig 2009-05-21 21:18:54.000000000 +0200 +++ dtrace_isa.c 2009-05-21 21:23:40.000000000 +0200 @@ -40,7 +40,8 @@ #include #include -extern uintptr_t kernbase; +//extern uintptr_t kernbase; +static uintptr_t kernbase = KERNBASE; uintptr_t kernelbase = (uintptr_t) &kernbase; #define INKERNEL(va) (((vm_offset_t)(va)) >= USRSTACK && \ -- Mel From owner-freebsd-current@FreeBSD.ORG Thu May 21 20:31:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5B921065670; Thu, 21 May 2009 20:31:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 620F58FC13; Thu, 21 May 2009 20:31:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAONWFUqDaFvH/2dsb2JhbADTB4QLBQ X-IronPort-AV: E=Sophos;i="4.41,229,1241409600"; d="scan'208";a="36223976" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 21 May 2009 16:31:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 763CB108459B; Thu, 21 May 2009 16:31:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhdSDqYV9b+e; Thu, 21 May 2009 16:31:21 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 044AB1084597; Thu, 21 May 2009 16:31:21 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4LKW3d20072; Thu, 21 May 2009 16:32:03 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 21 May 2009 16:32:03 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Andre Oppermann In-Reply-To: <4A1460A3.2010202@freebsd.org> Message-ID: References: <4A1460A3.2010202@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rwatson@freebsd.org, freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 20:31:24 -0000 On Wed, 20 May 2009, Andre Oppermann wrote: > > e) The socket buffer is most efficient when it can aggregate a number of > packets together before they are processed. Can the NFS code set a low > water mark on the socket to get called only after a few packets have > arrived instead of each one? (In the select and taskqueue model.) > I think the answer to this one is "no". NFS traffic is RPC requests and replies, which are mostly rather small messages (the write request, read reply and readdir reply are the exceptions). NFS performance is very sensition to RPC RTT, which means anything that introduces delay in getting an RPC message through (such as waiting a little while for more data/messages) is normally a detrement from what I've seen. It might be possible to handle the exceptions as a special case, but it isn't going to be easy, since TCP doesn't handle record marks, so knowing when a large message is coming would require something like "peeking" in the data for the RPC record marks. (Sun RPC puts a 32bit number in network byte order in front of each RPC message, which is it's length in bytes. A quirk on top of this is the definition of the high order bit of this mark indicating whether or not it is the last segment of a message. ie. An RPC message can be several record marked segments.) > f) I've been thinking of an modular socket filter approach (much like the > accept filter) scanning for upper layer specific markers or boundaries > and then signalling data availability. > If by this you mean scanning for the RPC message boundaries in the TCP stream (similar to what I said above), this could be very useful. So long as a message gets passed along as soon as you have a complete one, this sounds like a good idea to me. Btw, although FreeBSD currently uses 32Kbyte reads/writes, Solaris10 is using up to 1Mbyte and I'd like to see that happenning in FreeBSD too. (When you have 1Mbyte write request and read reply messages, delaying an upcall until you have an entire message, might work well.) Good luck with it, it sounds like an interesting project, rick From owner-freebsd-current@FreeBSD.ORG Thu May 21 20:35:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1831065677; Thu, 21 May 2009 20:35:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 14B908FC14; Thu, 21 May 2009 20:35:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABpYFUqDaFvI/2dsb2JhbADSeoQLBQ X-IronPort-AV: E=Sophos;i="4.41,229,1241409600"; d="scan'208";a="34092752" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 May 2009 16:35:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 10910940025; Thu, 21 May 2009 16:35:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SUfVpS61Xwt; Thu, 21 May 2009 16:35:36 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 596FC940020; Thu, 21 May 2009 16:35:36 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4LKaJo20784; Thu, 21 May 2009 16:36:19 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 21 May 2009 16:36:19 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Andre Oppermann In-Reply-To: Message-ID: References: <4A1460A3.2010202@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 20:35:39 -0000 On Thu, 21 May 2009, Rick Macklem wrote: > sensition to RPC RTT, which means anything that introduces delay in ^^^^^^^^^ Oops, make that "sensitive", rick From owner-freebsd-current@FreeBSD.ORG Thu May 21 20:45:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50BBB1065672 for ; Thu, 21 May 2009 20:45:50 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id C31188FC08 for ; Thu, 21 May 2009 20:45:49 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n4LKOxAS054334; Fri, 22 May 2009 00:24:59 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 22 May 2009 00:24:59 +0400 (MSD) From: Dmitry Morozovsky To: Randy Bush In-Reply-To: Message-ID: References: <20090518162253.GA78829@citylink.fud.org.nz> <20090519100744.GB5943@server.vk2pj.dyndns.org> <20090519162936.GB1457@carrot.geeknest.org> <20090519171030.GG78829@citylink.fud.org.nz> <20090519190648.GD1050@camelot.theinternet.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Fri, 22 May 2009 00:25:00 +0400 (MSD) Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 20:45:50 -0000 On Tue, 19 May 2009, Randy Bush wrote: RB> as punishment, here is yet another email RB> RB> so i have it all partitioned using fixit/dist. RB> ad4p1 64k freebsd-boot RB> ad4p2 64g freebsd-zfs (to use as zfs mirror) RB> ad4p3 64g freebsd-swap RB> ad4p4 2tb freebsd-zfs (to use as raidz2) RB> RB> same for ad5. ad6 and ad7 have only p1 to join the raidz2. RB> RB> but i can not build the boot zfs mirror because i can not follow the RB> destructions at RB> RB> http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ RB> http://wiki.freebsd.org/AppleMacbook RB> etc RB> RB> because fixit/dist is a world where i can not mount the zfs pool because RB> / is read-only md0. so i can not set up the bootable zfs mirror system. this can be avoided by mounting small md to local /boot/zfs and then copying zpool.cache to the original place. Or, you can even null-mount the "future" /boot/zfs to /dist/boot/zfs to have this automagically done. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 21 21:06:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7FA01065672 for ; Thu, 21 May 2009 21:06:24 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 74FBF8FC15 for ; Thu, 21 May 2009 21:06:24 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by k7.mavetju.org (Postfix, from userid 1001) id 60151450BE; Fri, 22 May 2009 06:46:07 +1000 (EST) Date: Fri, 22 May 2009 06:46:07 +1000 From: Edwin Groothuis To: freebsd-current@freebsd.org Message-ID: <20090521204607.GA34381@mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Update of tzcode from 2004a to 2009e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:06:25 -0000 Please be informed that I will commit an update to the tzcode related code (zic, zdump, stdtime of libc) in the coming days. Last year[1] I announced it on -arch that I had it running and that everything went fine. Recently I updated it to 2009e and asked around for help to get it commited. So today I got approval of all parties involved to go forward. The code for head and the code for releng-7 is very similar and right now the plans are to MFC it in a month time. And as Peter Jeremy hinted, after the commit I will go on holiday for seven weeks without having any internet connection. If it breaks something please fix it for me. <<<<--- joke :-) Edwin 1. http://www.mavetju.org/mail/view_message.php?list=freebsd-arch&id=2814457&thread=no -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-current@FreeBSD.ORG Thu May 21 21:27:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E5A41065670; Thu, 21 May 2009 21:27:31 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 196CF8FC26; Thu, 21 May 2009 21:27:30 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A572B9CB086; Thu, 21 May 2009 23:10:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY2+LMYuMS1t; Thu, 21 May 2009 23:10:14 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 219649CB0F9; Thu, 21 May 2009 23:10:14 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n4LLAELc076483; Thu, 21 May 2009 23:10:14 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 21 May 2009 23:10:14 +0200 From: Roman Divacky To: Edwin Groothuis Message-ID: <20090521211013.GA76374@freebsd.org> References: <20090521204607.GA34381@mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090521204607.GA34381@mavetju.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Update of tzcode from 2004a to 2009e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:27:31 -0000 On Fri, May 22, 2009 at 06:46:07AM +1000, Edwin Groothuis wrote: > Please be informed that I will commit an update to the tzcode related > code (zic, zdump, stdtime of libc) in the coming days. Last year[1] what new is there? what will it improve? just curious roman From owner-freebsd-current@FreeBSD.ORG Thu May 21 21:52:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D6B1065672; Thu, 21 May 2009 21:52:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2038FC1A; Thu, 21 May 2009 21:52:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4LLqN95011775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 07:52:24 +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.3/8.14.3) with ESMTP id n4LLqNEj010820; Fri, 22 May 2009 07:52:23 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n4LLqLA4010819; Fri, 22 May 2009 07:52:21 +1000 (EST) (envelope-from peter) Date: Fri, 22 May 2009 07:52:21 +1000 From: Peter Jeremy To: Adrian Chadd Message-ID: <20090521215221.GA98253@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, Saifi Khan , freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:52:28 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-20 08:30:09 +0800, Adrian Chadd wrote: >Xen also lets you write "other" OSes without needing to care about the >hardware. One of my friends bootstrapped a toy OS of his inside Xen. >He can then run it on any and all Xen boxes, unmodified, regardless of >the underlying hardware. That really hasn't been exploited to its full >potential though. This isn't a particularly new idea: The 'CMS' part of IBM VM/CMS was a hypervisor-aware OS that couldn't run on bare metal. Relying on the hypervisor for some "traditional" OS services offers plenty of scope for interesting developments. One area would be in University Operating Systems courses - it would again be possible to offer practical coursework on operating systems that are comprehendable in their entirety (ala V6 and Minix). --=20 Peter Jeremy --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoVzRUACgkQ/opHv/APuIfQCwCeLwqoTwMdt0p5z86D/NoP5mPA jtwAnAoIbSA3YzF816uP5rWrkMcTG0CN =OdBk -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Thu May 21 21:57:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB64A106567F for ; Thu, 21 May 2009 21:57:04 +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 989A18FC25 for ; Thu, 21 May 2009 21:57:04 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.146.201] (port=42298 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7GG7-0001Yk-01 for freebsd-current@freebsd.org; Fri, 22 May 2009 01:57:03 +0400 Message-ID: <4A15CE34.9000907@lissyara.su> Date: Fri, 22 May 2009 01:57:08 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49E41A2F.9080105@lissyara.su> In-Reply-To: <49E41A2F.9080105@lissyara.su> 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-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:57:05 -0000 Alex Keda пишет: > I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) > Boot not success: > > agp0: on host0 > agp0: aperture size is 128M > NMI ISA 2c, EISA ff > NMI ... going to debugger > [thread pid0 tid 100000 ] > Stopped at pmap_remove+0x158: testl %eax,%eax > db> > > If I do not unplug hard drive - reboot with 2-3 seconds > If unplug - not reboot, but, 'db>' go to down - kind of press enter > (~10-20 seconds period) > System - i386, GENERIC, from yesterday sources I found reason (build more than 50 kernels for it - get very long time =)) without kernel options HWPMC_HOOKS all build and work fine for CURRENT sources. It not hardware bug. It FreeBSD bug. From owner-freebsd-current@FreeBSD.ORG Fri May 22 00:53:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D7C106564A for ; Fri, 22 May 2009 00:53:57 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 8B57C8FC1D for ; Fri, 22 May 2009 00:53:57 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by k7.mavetju.org (Postfix, from userid 1001) id 05707450C8; Fri, 22 May 2009 10:53:05 +1000 (EST) Date: Fri, 22 May 2009 10:53:05 +1000 From: Edwin Groothuis To: Roman Divacky Message-ID: <20090522005304.GA10028@mavetju.org> References: <20090521204607.GA34381@mavetju.org> <20090521211013.GA76374@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090521211013.GA76374@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Update of tzcode from 2004a to 2009e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 00:53:58 -0000 Hello Roman, On Thu, May 21, 2009 at 11:10:14PM +0200, Roman Divacky wrote: > On Fri, May 22, 2009 at 06:46:07AM +1000, Edwin Groothuis wrote: > > Please be informed that I will commit an update to the tzcode related > > code (zic, zdump, stdtime of libc) in the coming days. Last year[1] > > what new is there? what will it improve? > > just curious The original issue why I dived into it was because zdump on the 64 bit platforms didn't work properly. Pretty lame reason I admit, but that's how all big things start :-) The new code and format of the output of zic adds support for 64 bit time_t while staying compatible with applications which don't support it. Plus general fixes. >From now on I will try to keep the code updated with the changes just like I do for tzdata. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-current@FreeBSD.ORG Fri May 22 01:14:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02172106564A for ; Fri, 22 May 2009 01:14:51 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 57DD38FC1E for ; Fri, 22 May 2009 01:14:49 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4M0xeGW021497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 May 2009 02:59:41 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> From: Stefan Bethke To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 02:59:40 +0200 X-Mailer: Apple Mail (2.935.3) Subject: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 01:14:51 -0000 Just updated my month-old current. On boot, ifconfig triggers this panic: Trying to mount root from ufs:/dev/mirror/diesel_root (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Entropy harvesting: interrupts ethernet point_to_point(probe0:umass- sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:1): Medium not present (probe0:umass-sim0:0:0:1): Unretryable error da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present kickstart. /odev/mirror/diesel_root: FILE SYSTEM CLEAN; SKIPPING CHECKS /deirror/diesel_root: clean, 759914 free (27202 frags, 91589 blocks, 1.3% fragmentation) bridge0: Ethernet address: d6:a8:2e:5f:c3:64 tap0: Ethernet address: 00:bd:4b:24:00:00 tap0: promiscuous mode enabled vlan1: promiscuous mode enabled kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff80323f5b stack pointer = 0x28:0xffffff80771c2760 frame pointer = 0x28:0xffffff80771c2770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 536 (ifconfig) [thread pid 536 tid 100085 ] Stopped at turnstile_setowner+0x2b: movq %rcx,0x68(%rdx) db> bt Tracing pid 536 tid 100085 td 0xffffff0004533ab0 turnstile_setowner() at turnstile_setowner+0x2b turnstile_wait() at turnstile_wait+0x296 _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 _mtx_lock_flags() at _mtx_lock_flags+0x43 ifaof_ifpforaddr() at ifaof_ifpforaddr+0x57 rt_getifa_fib() at rt_getifa_fib+0xa8 rtrequest1_fib() at rtrequest1_fib+0x3d9 in_ifinit() at in_ifinit+0x3ba in_control() at in_control+0xd81 ifioctl() at ifioctl+0x2de kern_ioctl() at kern_ioctl+0xb6 ioctl() at ioctl+0xfd syscall() at syscall+0x1a5 Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a6efbc, rsp = 0x7fffffffe4c8, rbp = 0x7fffffffef6d --- db> I've added an additional debug to network.subr to find out which ifconfig exactly it trips over, and it appears to be: /etc/rc: DEBUG: Cloned: bridge0 tap0 vlan1 vlan2 vlan3 /etc/rc: DEBUG: ifconfig lo0 inet 127.0.0.1 /etc/rc: DEBUG: ifconfig em0 up /etc/rc: DEBUG: tifconfig bridge0a ether 02:00:00:p00:00:01 addm ta0p0 addm vlan1 : promiscuous mode enabled vlan1: promiscuous mode enabled kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff80323f5b stack pointer = 0x28:0xffffff80771c7760 frame pointer = 0x28:0xffffff80771c7770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 581 (ifconfig) (The serial link is only 3wire, so it's slightly garbled.) This corresponds to these rc.conf settings: ifconfig_bridge0="ether 02:00:00:00:00:01" ifconfig_bridge0_alias0="addm tap0 addm vlan1" It appears that adding vlan1 triggers the panic. Using the month-old kernel manages to bring up the system, but I'm getting a generic "login: Could not determine audit condition" on the console. Additionally, while changing configuration in single user with the up- to-date kernel, I got this on reboot: Syncing disks, vnodes remaining...0 done All buffers synced. GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed. Uptime: 6m32s GEOM_MIRROR: Device diesel_root destroyed. Rebooting... cpu_reset: Stopping other CPUs spin lock 0xffffffff8078c900 (sched lock 1) held by 0xffffff00014d4ab0 (tid 100002) too long panic: spin lock held too long cpuid = 0 KDB: enter: panic [thread pid 77 tid 100090 ] Stopped at kdb_enter+0x3d: movq $0,0x48bbd0(%rip) db> bt Tracing pid 77 tid 100090 td 0xffffff000457bab0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 sched_balance_group() at sched_balance_group+0xc5 sched_balance_group() at sched_balance_group+0x1f8 sched_balance() at sched_balance+0xa2 sched_clock() at sched_clock+0xf6 statclock() at statclock+0xbd lapic_handle_timer() at lapic_handle_timer+0x197 Xtimerint() at Xtimerint+0x8c --- interrupt, rip = 0xffffffff80541cc4, rsp = 0xffffff80771dba90, rbp = 0xffffff80771dbab0 --- DELAY() at DELAY+0x64 cpu_reset() at cpu_reset+0xdd boot() at boot+0x2e6 reboot() at reboot+0x42 syscall() at syscall+0x1a5 Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x800788eec, rsp = 0x7fffffffeca8, rbp = 0 --- Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri May 22 04:40:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08583106568F for ; Fri, 22 May 2009 04:40:08 +0000 (UTC) (envelope-from weongyo.jeong@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 A664D8FC0A for ; Fri, 22 May 2009 04:40:07 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so616424rvb.43 for ; Thu, 21 May 2009 21:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=Il9ZHyNRcmfhScM1ZfltUUG+nF1lOVSOP6KEWALQpY4=; b=uSi3CffEU/xlhy62Wf+zTnmaeMBGxcZ5DicF7+oR0xZtBVwKVmeGvUbtAH8p65qOGx lSkC6/JMK9UubMeFmLn2rmhVYvrpEytb7JL8DlAi+YKJfec981j4Yhe430pyucdAPnjq k9qKaU8cO+Ys8IH/fNMVcmjQMFjaqje9MfdC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=aaSw4CCKnemepiuilC6n7JuXKnzZSxmsGWE+InG+Zu2W8PQFsdPwkM4Eu/vHdOy0Dk uwaKLzcLe4Ax/IKRI9PGyVQifhzzWfmIQoCCokxTGcRykVu1AfJ2OIUa9A1zdASOoC4n WtY8jI9Cr4YYtaxs5zRfrouO145p8uQsC94KQ= Received: by 10.141.179.5 with SMTP id g5mr1500986rvp.130.1242967207246; Thu, 21 May 2009 21:40:07 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id k37sm9146518rvb.48.2009.05.21.21.40.04 (version=SSLv3 cipher=RC4-MD5); Thu, 21 May 2009 21:40:06 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Fri, 22 May 2009 13:40:00 +0900 From: Weongyo Jeong Date: Fri, 22 May 2009 13:40:00 +0900 To: "Sam Fourman Jr." Message-ID: <20090522044000.GC88745@weongyo.cdnetworks.kr> Mail-Followup-To: "Sam Fourman Jr." , Lucius Windschuh , freebsd-current@freebsd.org, Hans Petter Selasky References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <4A0F419A.2020700@freebsd.org> <20090519050132.GE42412@weongyo.cdnetworks.kr> <200905190916.06460.hselasky@c2i.net> <90a5caac0905191127y5677bea9s827bb3d6a9f82176@mail.gmail.com> <11167f520905211148u34071232hbf95e45ca373708f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520905211148u34071232hbf95e45ca373708f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Lucius Windschuh , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 04:40:08 -0000 On Thu, May 21, 2009 at 01:48:31PM -0500, Sam Fourman Jr. wrote: > I have a uath device the Engenius NUB-362-EXT, it will not attach to > the uath driver > it says ugen7.3: at usbus7 > > I should note that this device attaches in OpenBSD 4.x > I am running FreeBSD 8 -CURRENT as of 10 hours ago, I do not know the > usb2 equivalent of usbdevs -v > > I am confused as to why this device will not attach to uath, I have > the driver loaded with kldload if_uath > > I do not know if this will help, but here is output from OpenBSD 4.5 > after you plugin the device I get: > > uath0 at uhub0 port 5 "Atheros Communications Inc AR5523" rev 2.00/0.01 addr 2 > uath0 detached > uath0 at uhub0 port 5 "Atheros Communications Inc AR5523" rev 2.00/0.01 addr 2 > uath0: MAC/BBP AR5523, RF AR2112, address 00:02:6f:3d:66:58 > > usbdevs -v > Controller /dev/usb0: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > Intel(0x8086), rev 1.00 > port 1 powered > port 2 powered > port 3 powered > port 4 powered > port 5 addr 2: high speed, power 500 mA, config 1, AR5523(0x0001), > Atheros Communications Inc(0x0cf3), rev 0.01, iSerialNumber 1.0 > port 6 powered > port 7 powered > port 8 powered Did you try to upload the firmware using uathload(8) like as follow after loading if_uath module? # /usr/sbin/uathload -d /dev/ugen7.3 regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Fri May 22 07:32:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3931065678 for ; Fri, 22 May 2009 07:32:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id EEB898FC1E for ; Fri, 22 May 2009 07:31:56 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:45243 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M7PEM-0000DR-50; Fri, 22 May 2009 09:31:52 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 655853357A; Fri, 22 May 2009 09:31:46 +0200 (CEST) Message-Id: <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> From: Thomas Backman To: Mel Flynn In-Reply-To: <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 09:31:44 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M7PEM-0000DR-50. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M7PEM-0000DR-50 3264c8b5388051d3a9e12196620d36e2 Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:32:01 -0000 On May 21, 2009, at 09:29 PM, Mel Flynn wrote: > On Thursday 21 May 2009 18:53:56 Thomas Backman wrote: >> On May 13, 2009, at 03:19 PM, Thomas Backman wrote: > > > >>> #11 0xffffffff8123c200 in dtrace_copycheck >>> (uaddr=3D18446744071581326184, kaddr=3DVariable "kaddr" is not =20 >>> available. >>> ) at dtrace_isa.c:527 > >> In /sys/cddl/dev/dtrace/amd64/dtrace_isa.c: >> static int >> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) >> { >> printf("in dtrace_copycheck(), pre-ASSERT:\n"); >> printf("kaddr =3D %u, kernelbase =3D %u, size =3D %d, kaddr+size = =3D %u\n >> \n", >> (unsigned int)kaddr, (unsigned int)kernelbase, (unsigned >> int)size, (unsigned int)(kaddr+size)); >> ASSERT(kaddr >=3D kernelbase && kaddr + size >=3D kaddr); >> >> if (uaddr + size >=3D kernelbase || uaddr + size < uaddr) { >> ... >> >> So, I added two printf statements. What happens? IT BECOMES STABLE. > > I'm no kernel hacker, but.. if you apply the patch below, does it =20 > still panic? > Make sure to get rid of the printf() you added. > > The theory behind this patch is that kernbase isn't initialized at =20 > the time of > that assert, yet code from printf initializes it. > > --- dtrace_isa.c.orig 2009-05-21 21:18:54.000000000 +0200 > +++ dtrace_isa.c 2009-05-21 21:23:40.000000000 +0200 > @@ -40,7 +40,8 @@ > #include > #include > > -extern uintptr_t kernbase; > +//extern uintptr_t kernbase; > +static uintptr_t kernbase =3D KERNBASE; > uintptr_t kernelbase =3D (uintptr_t) &kernbase; > > #define INKERNEL(va) (((vm_offset_t)(va)) >=3D USRSTACK && \ Hmmmmm. Nope, still panics with your patch, unfortunately. So I =20 reverted to my hack, but that doesn't work anymore, either! I did a =20 full buildworld/buildkernel yesterday, WITHOUT csup'ing before, so the =20= source should have stayed the same. Now I get this: # dtrace -n 'syscall::open:entry { trace(copyinstr(arg0)); }' dtrace: description 'syscall::open:entry ' matched 1 probe CPU ID FUNCTION:NAME 0 38977 open:entry 0 1 2 3 4 5 6 7 8 9 a b c d e f =20 0123456789abcdef 0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =20 00 ................ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =20 00 ................ [...snip...] dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): =20 invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): =20 invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): =20 invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 Same error using opensnoop and/or printing and copying in =20 in :::return, so something happened with the kernel (modules): dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return): =20= invalid address (0xffffff803e9faae0) in action #10 at DIF offset 28 710400 1970 Jan 1 01:00:00 0 1370 5509120 =20 2 vnstat\0 718047 1970 Jan 1 01:00:00 0 1370 5509120 =20 0 vnstat\0 dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return): =20= invalid address (0xffffff803e9afae0) in action #10 at DIF offset 28 dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return): =20= invalid address (0xffffff803e9afae0) in action #10 at DIF offset 28 742667 1970 Jan 1 01:00:00 0 1370 46927872 2 =20 =EF=BF=BD;=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDX=C4=BB = vnstat\0 750430 1970 Jan 1 01:00:00 0 1370 46927872 0 =20 =EF=BF=BD;=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDX=C4=BB = vnstat\0 (If this appears broken, beyond a few characters, that's because it IS =20= on my screen as well.) The address (0xffffff803e9afae0) changes without restarting dtrace, =20 but it appears fairly constant. ----------- Now, after reinstalling the modules and rebooting (rather than =20 kldunload dtraceall && make install && kldload dtraceall), it works =20 with my ugly hack again. Weird. Since it's all modules, why would it =20 not work to unload, recompile and reload? Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Fri May 22 07:38:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79157106564A; Fri, 22 May 2009 07:38:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 011338FC1E; Fri, 22 May 2009 07:38:14 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n4M7cC0j020542; Fri, 22 May 2009 09:38:12 +0200 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009052209381171:140565 ; Fri, 22 May 2009 09:38:11 +0200 Message-ID: <4A16564A.5040604@entel.upc.edu> Date: Fri, 22 May 2009 09:37:46 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Henri Hennebert References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <4A130842.5020407@protected-networks.net> <20090519193517.GA9909@bsdcrew.de> <4A130BE1.7060204@entel.upc.edu> <4A13F7B3.5070404@restart.be> In-Reply-To: <4A13F7B3.5070404@restart.be> X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 09:38:11, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 09:38:13, Serialize complete at 22/05/2009 09:38:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 22 May 2009 09:38:12 +0200 (CEST) Cc: freebsd-current , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:38:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> Last version fixed the problem with the kernel module not being >> detected the second time vbox is run, but I still have vbox booting >> the >> virtual machine in wit a gray screen. I've observed the machine is >> supposed to be running, but making top shows no activity. Also tried >> VBoxSDL -startvm win (win is the id given to the vmachine, yes I know, >> it took me little time to give it a name :) ) and the virtual machine >> shows a black screen. No CPU activity at all. Tried disabling >> VT-x/AMD-v >> extensions (the laptop supports VT-x) still no go. > > Same problem here > > FreeBSD chamonix.restart.bel 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon > May 18 16:47:40 CEST 2009 > root@chamonix.restart.bel:/usr/obj/usr/src/sys/CHAMONIX i386 > > I am using nvidia-driver-180.44 > > (II) LoadModule: "nvidia" > (II) Loading /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > (II) Module nvidia: vendor="NVIDIA Corporation" > compiled for 4.0.2, module version = 1.0.0 > Module class: X.Org Video Driver > (II) NVIDIA dlloader X Driver 180.44 Mon Mar 23 05:42:54 PST 2009 > (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs > > (II) NVIDIA(0): NVIDIA GPU Quadro NVS 285 (NV44GL) at PCI:3:0:0 (GPU-0) > (--) NVIDIA(0): Memory: 131072 kBytes > (--) NVIDIA(0): VideoBIOS: 05.44.02.64.03 > (II) NVIDIA(0): Detected PCI Express Link width: 1X > (--) NVIDIA(0): Interlaced video modes are supported on this GPU > (--) NVIDIA(0): Connected display device(s) on Quadro NVS 285 at > PCI:3:0:0: > (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0) > (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0): 400.0 MHz maximum pixel clock > (II) NVIDIA(0): Assigned Display Device: CRT-0 > (II) NVIDIA(0): Validated modes: > (II) NVIDIA(0): "1680x1050" > (II) NVIDIA(0): Virtual screen size determined to be 1680 x 1050 > (--) NVIDIA(0): DPI set to (90, 88); computed from "UseEdidDpi" X > config > (--) NVIDIA(0): option > (==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals. > > Henri > Hi, I tried starting vbox with current with VBoxSDL --startvm win (win is the id I gave to the virtual machine). With that, a black window appears, but the "Press F12 ..." messages doesn't appear. I checked with top, and vbox is doing nothing. With the same machine (Dell D630) and using 7.2-RELEASE (with nvidia driver loader, sound, etc ...) , it works (and it is pretty fast, don't know how could I live with qemu). So that makes me think either it is a problem with some config file (/boot/loader.conf, /etc/syslog.conf, for tunning purposes) or maybe my version of current. For /boot/loader.conf and /etc/syslog.conf, I removed the changes I made related to kern.maxdsiz and others, left kern.hz=100, removed kqemu and aio. I only have usb, ehci and friends, linux, nvidia and other hardware modules that shouldn't be the source of the problem. Can anyone with current and vbox working tolds us when you guys updated your sources ? Anyone has an idea what to check, hack ? Regards and thanks, Gusi - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoWVkoACgkQAvcpDulVChBUPQCaA+GhJRChUkhlVM/xy8CI6PtD DOEAnjGJ6XwrACVj6zUE5uRI2ssuN3rB =SBYN -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri May 22 08:01:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B9AF106564A for ; Fri, 22 May 2009 08:01:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id DD7018FC0A for ; Fri, 22 May 2009 08:01:00 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:33602 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M7PgX-00064p-4n for freebsd-current@freebsd.org; Fri, 22 May 2009 10:00:59 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 9EBA5335AA for ; Fri, 22 May 2009 10:00:56 +0200 (CEST) Message-Id: <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> From: Thomas Backman To: freebsd-current@freebsd.org In-Reply-To: <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 10:00:56 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M7PgX-00064p-4n. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M7PgX-00064p-4n 3cbe62735e126a8435cea250fe1162a6 Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 08:01:01 -0000 On May 22, 2009, at 09:31 AM, Thomas Backman wrote: > > ... > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > Actually, I still get these. Bummer. [root@chaos /usr/local/sbin]# execsnoop UID PID PPID ARGS 0 1931 1924 /bin/sh 0 1931 1924 /bin/sh 0 1932 1931 /bin/mkdir 0 1932 1931 /bin/mkdir dtrace: error on enabled probe ID 2 (ID 39086: syscall::execve:return): invalid address (0xffffff803e8cfae0) in action #8 dtrace: error on enabled probe ID 3 (ID 39086: syscall::execve:return): invalid address (0xffffff803e8cfae0) in action #8 0 1944 1933 mktemp 0 1944 1933 mktemp dtrace: error on enabled probe ID 2 (ID 39086: syscall::execve:return): invalid address (0xffffff803ea58ae0) in action #8 dtrace: error on enabled probe ID 3 (ID 39086: syscall::execve:return): invalid address (0xffffff803ea58ae0) in action #8 dtrace: error on enabled probe ID 2 (ID 39086: syscall::execve:return): invalid address (0xffffff803ea9eae0) in action #8 dtrace: error on enabled probe ID 3 (ID 39086: syscall::execve:return): invalid address (0xffffff803ea9eae0) in action #8 0 1948 1947 /bin/sh 0 1948 1947 /bin/sh 0 1949 1948 vnstat 0 1949 1948 vnstat 0 1950 1933 /bin/rm 0 1950 1933 /bin/rm 0 1951 1907 /bin/sh 0 1951 1907 /bin/sh 0 1952 1951 make 0 1952 1951 make (No idea why everything is printed twice either.) Also, the DTrace variable "walltimestamp" seems to return "1970 Jan 1 01:00:00" (I'm in GMT+2 right now, btw) every time. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri May 22 09:04:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FE83106566B for ; Fri, 22 May 2009 09:04:43 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4F62A8FC1A for ; Fri, 22 May 2009 09:04:43 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from localhost.my.domain (cazador.sisis.de [193.31.11.193]) by dd12710.kasserver.com (Postfix) with ESMTP id 67E181851E255; Fri, 22 May 2009 11:04:43 +0200 (CEST) Received: (from guru@localhost) by localhost.my.domain (8.14.3/8.14.3/Submit) id n4M94iaQ002176; Fri, 22 May 2009 11:04:44 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 22 May 2009 11:04:44 +0200 From: Matthias Apitz To: kde-freebsd@kde.org, freebsd-current@freebsd.org Message-ID: <20090522090443.GA2021@current.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: Subject: CURRENT && Konqueror 3.5.10: not using Flash9 in all sites X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 09:04:43 -0000 Hello, I've a relatively actual CURRENT on my laptop and configured Flash 9 for firefox3 as described in http://freebsd.kde.org/howtos/konqueror-flash.php http://crnl.org/blog/2008/11/01/flash-9-for-freebsd-71 Firefox3 plays nicely the flash9 stream from (for example): http://www.telesurtv.net/noticias/canal/senalenvivo.php Konqueror is showing the plugin in ~/.mozilla/plugins/npwrapper.libflashplayer.so as explained in http://freebsd.kde.org/img/pics/flash2.png and also a 'about:plugins' shows support for Flash9, but with the shared object libkmplayerpart.so; it even plays nicely the movies from YouTube, but can't play the above TeleSur channel (in which I'm more interested in than in YouTube :-)). In www.telesurtv.net it always ask me the install Flash9 from Adobe. Any ideas what could be the reason for this? I can live with Firefox3, but would prefer Konqueror for this. Thx in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Fri May 22 10:33:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91580106566C for ; Fri, 22 May 2009 10:33:54 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3CEE18FC14 for ; Fri, 22 May 2009 10:33:54 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 162DE125424; Fri, 22 May 2009 19:15:22 +0900 (JST) Message-ID: <4A167B39.2090405@ongs.co.jp> Date: Fri, 22 May 2009 19:15:21 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Stefan Bethke References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> In-Reply-To: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 10:33:54 -0000 I have ifconfig(8) panic issue like you. With current, just do ifconfig(8) like follow leads panic. ifconfig re0 inet xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy I have tried on board re0 and attached fxp0, both have the same result. Anyone has any ideas around these panic issues? By my little research, kernel/world up until to 12/05/2009 03:00 has no problem. At least, kernel/world at 19/05/2009 JST has above panic issue. Stefan Bethke wrote: > Just updated my month-old current. On boot, ifconfig triggers this panic: > > Trying to mount root from ufs:/dev/mirror/diesel_root > > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 > (probe0:umass-sim0:0:0:0): Medium not present > (probe0:umass-sim0:0:0:0): Unretryable error > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > Entropy harvesting: interrupts ethernet > point_to_point(probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 > (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 > (probe0:umass-sim0:0:0:1): Medium not present > (probe0:umass-sim0:0:0:1): Unretryable error > da1 at umass-sim0 bus 0 target 0 lun 1 > da1: Removable Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > kickstart. > /odev/mirror/diesel_root: FILE SYSTEM CLEAN; SKIPPING CHECKS > /deirror/diesel_root: clean, 759914 free (27202 frags, 91589 blocks, > 1.3% fragmentation) > bridge0: Ethernet address: d6:a8:2e:5f:c3:64 > tap0: Ethernet address: 00:bd:4b:24:00:00 > tap0: promiscuous mode enabled > vlan1: promiscuous mode enabled > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xffffffff80323f5b > stack pointer = 0x28:0xffffff80771c2760 > frame pointer = 0x28:0xffffff80771c2770 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 536 (ifconfig) > [thread pid 536 tid 100085 ] > Stopped at turnstile_setowner+0x2b: movq %rcx,0x68(%rdx) > db> bt > Tracing pid 536 tid 100085 td 0xffffff0004533ab0 > turnstile_setowner() at turnstile_setowner+0x2b > turnstile_wait() at turnstile_wait+0x296 > _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 > _mtx_lock_flags() at _mtx_lock_flags+0x43 > ifaof_ifpforaddr() at ifaof_ifpforaddr+0x57 > rt_getifa_fib() at rt_getifa_fib+0xa8 > rtrequest1_fib() at rtrequest1_fib+0x3d9 > in_ifinit() at in_ifinit+0x3ba > in_control() at in_control+0xd81 > ifioctl() at ifioctl+0x2de > kern_ioctl() at kern_ioctl+0xb6 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a6efbc, rsp = > 0x7fffffffe4c8, rbp = 0x7fffffffef6d --- > db> > > > I've added an additional debug to network.subr to find out which > ifconfig exactly it trips over, and it appears to be: > > /etc/rc: DEBUG: Cloned: bridge0 tap0 vlan1 vlan2 vlan3 > /etc/rc: DEBUG: ifconfig lo0 inet 127.0.0.1 > /etc/rc: DEBUG: ifconfig em0 up > /etc/rc: DEBUG: tifconfig bridge0a ether 02:00:00:p00:00:01 addm ta0p0 > addm vlan1 > : promiscuous mode enabled > vlan1: promiscuous mode enabled > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xffffffff80323f5b > stack pointer = 0x28:0xffffff80771c7760 > frame pointer = 0x28:0xffffff80771c7770 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 581 (ifconfig) > > (The serial link is only 3wire, so it's slightly garbled.) > > This corresponds to these rc.conf settings: > ifconfig_bridge0="ether 02:00:00:00:00:01" > ifconfig_bridge0_alias0="addm tap0 addm vlan1" > > It appears that adding vlan1 triggers the panic. > > Using the month-old kernel manages to bring up the system, but I'm > getting a generic "login: Could not determine audit condition" on the > console. > > Additionally, while changing configuration in single user with the > up-to-date kernel, I got this on reboot: > > Syncing disks, vnodes remaining...0 done > All buffers synced. > GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed. > Uptime: 6m32s > GEOM_MIRROR: Device diesel_root destroyed. > Rebooting... > cpu_reset: Stopping other CPUs > spin lock 0xffffffff8078c900 (sched lock 1) held by 0xffffff00014d4ab0 > (tid 100002) too long > panic: spin lock held too long > cpuid = 0 > KDB: enter: panic > [thread pid 77 tid 100090 ] > Stopped at kdb_enter+0x3d: movq $0,0x48bbd0(%rip) > db> bt > Tracing pid 77 tid 100090 td 0xffffff000457bab0 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 > _mtx_lock_spin() at _mtx_lock_spin+0x9e > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 > sched_balance_group() at sched_balance_group+0xc5 > sched_balance_group() at sched_balance_group+0x1f8 > sched_balance() at sched_balance+0xa2 > sched_clock() at sched_clock+0xf6 > statclock() at statclock+0xbd > lapic_handle_timer() at lapic_handle_timer+0x197 > Xtimerint() at Xtimerint+0x8c > --- interrupt, rip = 0xffffffff80541cc4, rsp = 0xffffff80771dba90, rbp = > 0xffffff80771dbab0 --- > DELAY() at DELAY+0x64 > cpu_reset() at cpu_reset+0xdd > boot() at boot+0x2e6 > reboot() at reboot+0x42 > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (55, FreeBSD ELF64, reboot), rip = 0x800788eec, rsp = > 0x7fffffffeca8, rbp = 0 --- > > > > Stefan -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Fri May 22 11:09:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19F181065677 for ; Fri, 22 May 2009 11:09:09 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 923CA8FC1A for ; Fri, 22 May 2009 11:09:08 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4MB93UJ014045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 13:09:06 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A1687C2.2090606@omnilan.de> Date: Fri, 22 May 2009 13:08:50 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A12EC37.2020904@omnilan.de> In-Reply-To: <4A12EC37.2020904@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8FE3E58877E4F15E5A911DE" Subject: Re: Need help with "xptioctl: pass driver is not in the kernel" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 11:09:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8FE3E58877E4F15E5A911DE Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 19.05.2009 19:28 (localtime): =2E.. > when I plug in a UFD I get the message from the topic. > But of course I do have pass in my kernel. > That may be the reason why hal/xfce-volman isn't working for me any mor= e=20 > with -current (which worked fine with 7.1-7.2). After the UFD plugin=20 > there's no hald-addonstorage anymore... =2E.. Hello, anyone out there who knows how comes that kernel thinks it hasn't = device pass? For sure, there is device pass, but I still get kernel: xptioctl: pass driver is not in the kernel kernel: xptioctl: put "device pass" in your kernel config file The hal mounting was quiet convenient, I'm missing that with -current. Thanks, -Harry --------------enigC8FE3E58877E4F15E5A911DE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoWh88ACgkQLDqVQ9VXb8huowCgqnoWP8Qp04MGvCdieRTZBfhw BhAAn0gvvAtwldpxpG6RdQ3pYtGswZi2 =KSAU -----END PGP SIGNATURE----- --------------enigC8FE3E58877E4F15E5A911DE-- From owner-freebsd-current@FreeBSD.ORG Fri May 22 11:41:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B2D106567A; Fri, 22 May 2009 11:41:47 +0000 (UTC) (envelope-from mdc@prgmr.com) Received: from mail.prgmr.com (mail.prgmr.com [64.62.173.114]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECC38FC33; Fri, 22 May 2009 11:41:47 +0000 (UTC) (envelope-from mdc@prgmr.com) Received: from frylock.local (c-71-198-249-174.hsd1.ca.comcast.net [71.198.249.174]) by mail.prgmr.com (Postfix) with ESMTP id 3B76268B5F; Fri, 22 May 2009 04:22:06 -0700 (PDT) Message-ID: <4A168ADA.3040505@prgmr.com> Date: Fri, 22 May 2009 04:22:02 -0700 From: Michael David Crawford Organization: Prgmr.com User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-xen@freebsd.org References: <9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com> In-Reply-To: <9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 11:41:47 -0000 > VIMAGE and jails are OS-level virtualization, orthogonal to Xen. I want to run Xen so I can build and test Ogg Frog[1] on each of the target platforms I plan to support. I built a fancy Xeon box so that I could even build and test on all the platforms simultaneously. I also operate a couple Internet servers, which are themselves Xen DomUs at commercial Xen Virtual Private Server hosting services. I'd like to place each service that they operate into a jail, so that if someone manages to bust in because of a security hole in one of the server programs, they would only be able to get at the contents of that particular jail. But all of the jails are just subdivisions of a single operating system; I can't run other OSes within them. [1] http://www.oggfrog.com/free-music-software/ No, there is nothing to download yet. Real Soon Now. Mike -- Michael David Crawford mdc@prgmr.com prgmr.com - We Don't Assume You Are Stupid. Xen-Powered Virtual Private Servers: http://prgmr.com/xen From owner-freebsd-current@FreeBSD.ORG Fri May 22 11:53:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931431065674 for ; Fri, 22 May 2009 11:53:21 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 292CE8FC1E for ; Fri, 22 May 2009 11:53:20 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4MBrJDe031568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 13:53:19 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> From: Stefan Bethke To: Daichi GOTO In-Reply-To: <4A167B39.2090405@ongs.co.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 13:53:19 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <4A167B39.2090405@ongs.co.jp> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 11:53:22 -0000 Am 22.05.2009 um 12:15 schrieb Daichi GOTO: > I have ifconfig(8) panic issue like you. > > With current, just do ifconfig(8) like follow leads panic. > > ifconfig re0 inet xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy > > I have tried on board re0 and attached fxp0, both have the > same result. > > Anyone has any ideas around these panic issues? By my > little research, kernel/world up until to 12/05/2009 03:00 > has no problem. At least, kernel/world at 19/05/2009 JST > has above panic issue. I've checked from single-user mode, and the panic is indeed triggered by the address assignment. # sh ifc ifconfig bridge0ke inet 44.128.65.rn1/28 + ifconfigel bridge0 inet 44 t.128.65.1/28 rap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80323f5b stack pointer = 0x28:0xffffff8076524760 frame pointer = 0x28:0xffffff8076524770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 48 (ifconfig) [thread pid 48 tid 100056 ] Stopped at turnstile_setowner+0x2b: movq %rcx,0x68(%rdx) A kernel compiled from the same sources with practically identical configuration (GENERIC minus most devices) running inside VMware (but also SMP) does not exhibit this issue. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri May 22 12:09:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B2311065676 for ; Fri, 22 May 2009 12:09:06 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by mx1.freebsd.org (Postfix) with ESMTP id F2BBD8FC18 for ; Fri, 22 May 2009 12:09:04 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0A16F81818F for ; Fri, 22 May 2009 14:09:00 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp3-g21.free.fr (Postfix) with ESMTP id 9673D81811C for ; Fri, 22 May 2009 14:08:57 +0200 (CEST) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n4MC8fdu015932; Fri, 22 May 2009 14:08:42 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 22 May 2009 14:08:34 +0200 User-Agent: KMail/1.9.10 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <4A167B39.2090405@ongs.co.jp> <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> In-Reply-To: <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200905221408.35557.thierry.herbelot@free.fr> Cc: Daichi GOTO , Stefan Bethke Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 12:09:06 -0000 Le Friday 22 May 2009, Stefan Bethke a écrit : > Am 22.05.2009 um 12:15 schrieb Daichi GOTO: > > I have ifconfig(8) panic issue like you. > > > > With current, just do ifconfig(8) like follow leads panic. > > > > ifconfig re0 inet xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy > > > > I have tried on board re0 and attached fxp0, both have the > > same result. > > > > Anyone has any ideas around these panic issues? By my > > little research, kernel/world up until to 12/05/2009 03:00 > > has no problem. At least, kernel/world at 19/05/2009 JST > > has above panic issue. > > I've checked from single-user mode, and the panic is indeed triggered > by the address assignment. > > # sh ifc > ifconfig bridge0ke inet 44.128.65.rn1/28 > + ifconfigel bridge0 inet 44 t.128.65.1/28 > rap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff80323f5b > stack pointer = 0x28:0xffffff8076524760 > frame pointer = 0x28:0xffffff8076524770 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 48 (ifconfig) > [thread pid 48 tid 100056 ] > Stopped at turnstile_setowner+0x2b: movq %rcx,0x68(%rdx) > > A kernel compiled from the same sources with practically identical > configuration (GENERIC minus most devices) running inside VMware (but > also SMP) does not exhibit this issue. > Hello, FWIW, I'm running two machines with recent -current builds (one csuped yesterday, around 1800GMT, the other the day before), and the network interfaces are working fine (dc(4) for one and rl(4) for the other). In both cases, the kernel config is GENERIC, minus SMP, WITNESS and INVARIANTS. TfH > > Stefan From owner-freebsd-current@FreeBSD.ORG Fri May 22 12:31:20 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0998106566C for ; Fri, 22 May 2009 12:31:20 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5F70E8FC0C for ; Fri, 22 May 2009 12:31:18 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 4908F4C80D7 for ; Fri, 22 May 2009 14:31:14 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g21.free.fr (Postfix) with ESMTP id 6D23C4C8034 for ; Fri, 22 May 2009 14:31:12 +0200 (CEST) Received: from obiwan.tataz.chchile.org (obiwan.tataz.chchile.org [192.168.1.222]) by endor.tataz.chchile.org (Postfix) with ESMTP id AE42633E5F for ; Fri, 22 May 2009 12:30:35 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 9761450835; Fri, 22 May 2009 14:30:35 +0200 (CEST) Date: Fri, 22 May 2009 14:30:35 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20090522123035.GA45358@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: bin/134856: sed(1) "addr1,+N" address range X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 12:31:21 -0000 Hi! Yesterday there has been a sudden CPU burst on my workstation. In case it would happen again, I wanted to use something like top -n | sed -n /PID/,+5p in a loop. Unfortunately, the above address range is not recognized by sed(1) on FreeBSD. I thought it was because I use it very often in Vim. PR bin/134856 includes a patch to implement this. The manpage has been updated as well and this extension is referenced as non-standard along with the other ones. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri May 22 12:36:22 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30D65106564A; Fri, 22 May 2009 12:36: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 0C50A8FC12; Fri, 22 May 2009 12:36: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 ESMTPS id A33D946B0D; Fri, 22 May 2009 08:36:21 -0400 (EDT) Date: Fri, 22 May 2009 13:36:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: HEADS UP: old UMich nfs4client to be removed, replaced with new NFSv234 client/server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 12:36:22 -0000 On Thu, 21 May 2009, Robert Watson wrote: > This is advance warning that we'll be garbage-collecting the UMich NFSv4 > client (src/sys/nfs4client and supporting RPC code, daemons, and mount tool) > prior to 8.0 now that Rick Macklems NFSv234 client and server are in the > base tree. This removal will likely be in the next week, as the 8.0 feature > freeze is at the end of the month. > > The new client and server provide significantly improved support for NFSv4, > and while they remain experimental, they should offer both more reliable, > more complete, and actively maintained NFSv4 support. Anyone using > nfs4client (probably not many) is encouraged to try out and provide feedback > on the new NFSv4 code as soon as possible. This has now been committed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri May 22 12:55:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D495106568E for ; Fri, 22 May 2009 12:55:45 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCF48FC13 for ; Fri, 22 May 2009 12:55:44 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4MCtgKA042164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 May 2009 14:55:43 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <8FE57686-E9EE-4118-A0F5-0DBF0B154D27@lassitu.de> From: Stefan Bethke To: FreeBSD Current In-Reply-To: <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 14:55:42 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <4A167B39.2090405@ongs.co.jp> <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> X-Mailer: Apple Mail (2.935.3) Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 12:55:45 -0000 Am 22.05.2009 um 13:53 schrieb Stefan Bethke: > Am 22.05.2009 um 12:15 schrieb Daichi GOTO: > >> I have ifconfig(8) panic issue like you. >> >> With current, just do ifconfig(8) like follow leads panic. >> >> ifconfig re0 inet xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy >> >> I have tried on board re0 and attached fxp0, both have the >> same result. >> >> Anyone has any ideas around these panic issues? By my >> little research, kernel/world up until to 12/05/2009 03:00 >> has no problem. At least, kernel/world at 19/05/2009 JST >> has above panic issue. > > I've checked from single-user mode, and the panic is indeed > triggered by the address assignment. > > # sh ifc > ifconfig bridge0ke inet 44.128.65.rn1/28 > + ifconfigel bridge0 inet 44 t.128.65.1/28 > rap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff80323f5b > stack pointer = 0x28:0xffffff8076524760 > frame pointer = 0x28:0xffffff8076524770 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 48 (ifconfig) > [thread pid 48 tid 100056 ] > Stopped at turnstile_setowner+0x2b: movq %rcx, > 0x68(%rdx) > > A kernel compiled from the same sources with practically identical > configuration (GENERIC minus most devices) running inside VMware > (but also SMP) does not exhibit this issue. Using the failing kernel in VMware triggers the same panic, so it does appear to be configuration dependant. I'll see what's different between the two configs. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri May 22 12:58:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB69C106564A for ; Fri, 22 May 2009 12:58:21 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 646708FC1E for ; Fri, 22 May 2009 12:58:21 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M7UKK-0000gV-48 for freebsd-current@freebsd.org; Fri, 22 May 2009 12:58:20 +0000 Received: from pd95d6d08.dip.t-dialin.net ([217.93.109.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 May 2009 12:58:20 +0000 Received: from js by pd95d6d08.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 May 2009 12:58:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Followup-To: poster Date: Fri, 22 May 2009 14:57:54 +0200 Lines: 32 Message-ID: <87pre1nvl9.fsf@tabernacle.lan> References: <20090521215221.GA98253@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd95d6d08.dip.t-dialin.net X-Archive: encrypt User-Agent: Gnus/5.101 (Gnus v5.10.10) Cancel-Lock: sha1:TLV86IYUCh1ei2cmHzSb5cDhFDg= Sender: news Cc: freebsd-xen@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 12:58:22 -0000 Peter Jeremy writes: > On 2009-May-20 08:30:09 +0800, Adrian Chadd wrote: >>Xen also lets you write "other" OSes without needing to care about the >>hardware. One of my friends bootstrapped a toy OS of his inside Xen. >>He can then run it on any and all Xen boxes, unmodified, regardless of >>the underlying hardware. That really hasn't been exploited to its full >>potential though. > > This isn't a particularly new idea: The 'CMS' part of IBM VM/CMS was a > hypervisor-aware OS that couldn't run on bare metal. > > Relying on the hypervisor for some "traditional" OS services offers > plenty of scope for interesting developments. One area would be in > University Operating Systems courses - it would again be possible to > offer practical coursework on operating systems that are comprehendable > in their entirety (ala V6 and Minix). You can use microkernels[1] for almost the same thing. It's what we do at Technische Universität Dresden. Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge Footnotes: [1] There is a sexy new microhypervisor to be released Real Soon Now(tm) too: http://eurosys09dw.systems.ethz.ch/steinberg.pdf From owner-freebsd-current@FreeBSD.ORG Fri May 22 14:20:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F589106566B for ; Fri, 22 May 2009 14:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48CB68FC14 for ; Fri, 22 May 2009 14:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 12F0541C72F; Fri, 22 May 2009 16:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id bHyRAdF2FYEg; Fri, 22 May 2009 16:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id A808C41C6FC; Fri, 22 May 2009 16:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 899234448E6; Fri, 22 May 2009 14:19:42 +0000 (UTC) Date: Fri, 22 May 2009 14:19:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Stefan Bethke In-Reply-To: <8FE57686-E9EE-4118-A0F5-0DBF0B154D27@lassitu.de> Message-ID: <20090522141756.A72053@maildrop.int.zabbadoz.net> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <4A167B39.2090405@ongs.co.jp> <15095A18-F361-4F8E-8253-0B675C771FC4@lassitu.de> <8FE57686-E9EE-4118-A0F5-0DBF0B154D27@lassitu.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 14:20:07 -0000 On Fri, 22 May 2009, Stefan Bethke wrote: Hi, >> A kernel compiled from the same sources with practically identical >> configuration (GENERIC minus most devices) running inside VMware (but also >> SMP) does not exhibit this issue. > > Using the failing kernel in VMware triggers the same panic, so it does appear > to be configuration dependant. I'll see what's different between the two > configs. The problem itself has been known for a week and while we had some people seeing it we could not reproduce it ourselves. Thanks for those extra pointers. As you seem to be in my TZ and debugging this, I sent you a private follow-up so we can possibly figure things out to get this fixed. We'll report back to the list once we know more. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri May 22 14:33:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA504106568A; Fri, 22 May 2009 14:33:12 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 422928FC1A; Fri, 22 May 2009 14:33:12 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 1295C484B; Fri, 22 May 2009 16:33:11 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n4MEX6t5008114; Fri, 22 May 2009 16:33:07 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243002790; bh=oGXMJHahvgpKadlzAYOvwg73bLCAXnFuNVpnmag1Jwk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KLp8CU8QMPP2QR99Uxb0LzINObECCYSHfVZl7zpi/cQ9jgdIsvd7yq9A3BnEce89A zYSVHhyzB5awzsimNuu7Q== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=XCCwUMat6xwR/xDY3BIGFsM1zP/uLbSQ1i5HlIBICGGpCnj2+entbOJZT0epqu1MW qHGLsstuIZHGqHc//QIwA== Message-ID: <4A16B7A2.9040300@restart.be> Date: Fri, 22 May 2009 16:33:06 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gustau_P=E9rez?= References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <4A130842.5020407@protected-networks.net> <20090519193517.GA9909@bsdcrew.de> <4A130BE1.7060204@entel.upc.edu> <4A13F7B3.5070404@restart.be> In-Reply-To: <4A13F7B3.5070404@restart.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 14:33:13 -0000 Henri Hennebert wrote: > > > Gustau Pérez wrote: >> Martin Wilke wrote: >>> On Tue, May 19, 2009 at 03:28:02PM -0400, Michael Butler wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> Martin Wilke wrote: >>>>> http://people.freebsd.org/~miwi/vbox/virtualbox_3.tgz >>>> With the latest tarball, I still don't see my DVD in the drop-down list >>>> even though I have tweaked the devd.conf file such that .. >>>> imb@toshi:/home/imb> ll /dev/*cd* >>>> crw-rw-rw- 1 root operator 0, 97 May 19 10:55 /dev/acd0 >>>> crw-rw-rw- 1 root operator 0, 104 May 19 10:55 /dev/cd0 >>>> lrwxr-xr-x 1 root wheel 3 May 19 10:55 /dev/cdrom -> cd0 >>>> This is on a Toshiba Satellite with today's -current .. >>>> imb@toshi:/home/imb> uname -a >>>> FreeBSD toshi.auburn.protected-networks.net 8.0-CURRENT FreeBSD >>>> 8.0-CURRENT #89: Tue May 19 07:29:32 EDT 2009 >>>> root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI >>> i386 >>> >>> at the moment a now issus we will take a look later. >>> >>> All in one seems that by most peoples now vbox works \o/ >>> >> >> Hi, >> >> as I reported this morning, for me is not working. My system is a >> DELL D630 laptop with 3Gb of RAM. i386/CURRENT update today : >> >> FreeBSD gusiport 8.0-CURRENT FreeBSD 8.0-CURRENT #41: Tue May 19 >> 14:24:05 CEST 2009 >> gus@gusiport:/usr/obj/usr/src/sys/CUSTOM i386 >> >> Last version fixed the problem with the kernel module not being >> detected the second time vbox is run, but I still have vbox booting the >> virtual machine in wit a gray screen. I've observed the machine is >> supposed to be running, but making top shows no activity. Also tried >> VBoxSDL -startvm win (win is the id given to the vmachine, yes I know, >> it took me little time to give it a name :) ) and the virtual machine >> shows a black screen. No CPU activity at all. Tried disabling VT-x/AMD-v >> extensions (the laptop supports VT-x) still no go. > > Same problem here > > FreeBSD chamonix.restart.bel 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon May > 18 16:47:40 CEST 2009 > root@chamonix.restart.bel:/usr/obj/usr/src/sys/CHAMONIX i386 > > I am using nvidia-driver-180.44 > > (II) LoadModule: "nvidia" > (II) Loading /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > (II) Module nvidia: vendor="NVIDIA Corporation" > compiled for 4.0.2, module version = 1.0.0 > Module class: X.Org Video Driver > (II) NVIDIA dlloader X Driver 180.44 Mon Mar 23 05:42:54 PST 2009 > (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs > > (II) NVIDIA(0): NVIDIA GPU Quadro NVS 285 (NV44GL) at PCI:3:0:0 (GPU-0) > (--) NVIDIA(0): Memory: 131072 kBytes > (--) NVIDIA(0): VideoBIOS: 05.44.02.64.03 > (II) NVIDIA(0): Detected PCI Express Link width: 1X > (--) NVIDIA(0): Interlaced video modes are supported on this GPU > (--) NVIDIA(0): Connected display device(s) on Quadro NVS 285 at PCI:3:0:0: > (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0) > (--) NVIDIA(0): FUS P22W-5 ECO (CRT-0): 400.0 MHz maximum pixel clock > (II) NVIDIA(0): Assigned Display Device: CRT-0 > (II) NVIDIA(0): Validated modes: > (II) NVIDIA(0): "1680x1050" > (II) NVIDIA(0): Virtual screen size determined to be 1680 x 1050 > (--) NVIDIA(0): DPI set to (90, 88); computed from "UseEdidDpi" X config > (--) NVIDIA(0): option > (==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals. > > Henri > I Try on FreeBSD-STABLE and get a black screen. I reboot without nvidia driver and with vboxdrv loaded at boot. I use vesa driver for xorg no change, a black screen. I try VirtualBox --startvm pcbsd --rmode image And still got a black screen. Henri > >> >> Anything I can try ? >> >> Thanks, >> >> Gus > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri May 22 16:58:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826E1106564A for ; Fri, 22 May 2009 16:58:13 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 503A08FC1A for ; Fri, 22 May 2009 16:58:13 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id n4MGwB39004314; Fri, 22 May 2009 11:58:12 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4A16D9A3.9000302@missouri.edu> Date: Fri, 22 May 2009 11:58:11 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.21) Gecko/20090519 SeaMonkey/1.1.16 MIME-Version: 1.0 To: pyunyh@gmail.com References: <20090521041929.GN9043@michelle.cdnetworks.co.kr> In-Reply-To: <20090521041929.GN9043@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CFT: msk(4) and Yukon FE+(88E8040, 88E8040T, 88E8048, 88E8070) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 16:58:13 -0000 Pyun YongHyeon wrote: > Hi, > > I had been working on supporting Yukon FE+ for more than a year. > Lack of hardware and documentation was one of major issue to write > support code. Recently one user, Tanguy Bouzeloc, submitted fix > and the patch seems to make msk(4) work on Yukon FE+. You can get > the latest patch at the following URL. > http://people.freebsd.org/~yongari/msk/msk.88E8040.patch26 > > Since the patch changes a lot of code flow of driver all msk(4) > users would be affected. If you use msk(4) or have Yukon FE+, > please give it try and let me know how it goes on your box. > > Thanks. It works great for me! I have a Marvell Yukon 88E8040 Fast Ethernet, and you may remember that a while back, you tried to get this to work for me, without success. But this driver worked! Thanks, Stephen From owner-freebsd-current@FreeBSD.ORG Fri May 22 17:46:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C6E21065670 for ; Fri, 22 May 2009 17:46:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E51E8FC15 for ; Fri, 22 May 2009 17:46:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E9E7646B7E; Fri, 22 May 2009 13:46:35 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 16E718A026; Fri, 22 May 2009 13:46:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, pyunyh@gmail.com Date: Fri, 22 May 2009 13:14:05 -0400 User-Agent: KMail/1.9.7 References: <20090521041929.GN9043@michelle.cdnetworks.co.kr> In-Reply-To: <20090521041929.GN9043@michelle.cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905221314.06146.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 May 2009 13:46:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: CFT: msk(4) and Yukon FE+(88E8040, 88E8040T, 88E8048, 88E8070) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 17:46:36 -0000 On Thursday 21 May 2009 12:19:29 am Pyun YongHyeon wrote: > Hi, > > I had been working on supporting Yukon FE+ for more than a year. > Lack of hardware and documentation was one of major issue to write > support code. Recently one user, Tanguy Bouzeloc, submitted fix > and the patch seems to make msk(4) work on Yukon FE+. You can get > the latest patch at the following URL. > http://people.freebsd.org/~yongari/msk/msk.88E8040.patch26 > > Since the patch changes a lot of code flow of driver all msk(4) > users would be affected. If you use msk(4) or have Yukon FE+, > please give it try and let me know how it goes on your box. FYI, I am using this on 7.x along with some other patches to get an 88E8072 working (it's the Yukon Extreme (0xb5) chip ID). I finally got it to somewhat work today (it is having TX issues with TSO and TXCSUM enabled, haven't figured out which one breaks it yet). When I get 8 up and running I will send you the current patch I have. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 22 18:00:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46D311065672; Fri, 22 May 2009 18:00:01 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 04BFC8FC19; Fri, 22 May 2009 18:00:00 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 207F64AC5C; Fri, 22 May 2009 19:59:57 +0200 (CEST) Date: Fri, 22 May 2009 19:59:57 +0200 From: Martin Wilke To: ports@FreeBSD.org Message-ID: <20090522175956.GA33004@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 18:00:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. - - Martin PS: Should this work for all maybe we can commit vbox this weekend to the portstree. - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoW6BwACgkQdLJIhLHm/Omb0wCfYh2BlN12YQMV2mtpRdXIy/cW WYIAniofRUneutcXfxXJz+DDZ2dwDJuG =6sXC -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri May 22 19:34:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61C5106564A for ; Fri, 22 May 2009 19:34:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 62CEA8FC0A for ; Fri, 22 May 2009 19:34:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz9 with SMTP id 9so1898226bwz.43 for ; Fri, 22 May 2009 12:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=FAEl5UwkZMShMIYDHh4uCCQUg32+doMaLghYpS+ar+Y=; b=aFvmlVF+/75RQ7ViP5m6Dk/O/yrr4sQvLgeCEgUIwFtM3fzwncJvgTULf54yWFjbtV REb1Z5WnbrEVBHXgbeCSdAi3Uc5aryywDZfFwdEugxDH2R4356AGHnC7DTpR/2zleZSP 9bznkjkVKhQhJhfN4kBO1UnG1l7mpyzVy5oCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=omV3tpOe36gk+yOxcajgPBzNhgQUuh1y0jcth+xPk8lmN1EMO5IWWgdmMM7oqEEENJ Yz3eCPlt9uf+DKzG19kVR2wAKug430iXH3s31zh8w99J1P0Fzbv1+yF9brigufmfQ44i +l1fmoOp6bKwKB4PTMweWbBgIBFXfP7yZ7vOA= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.107.19 with SMTP id z19mr2580971fao.27.1243020867218; Fri, 22 May 2009 12:34:27 -0700 (PDT) In-Reply-To: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> Date: Fri, 22 May 2009 21:34:27 +0200 X-Google-Sender-Auth: 164cfd43be68d703 Message-ID: <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> From: Attilio Rao To: Stefan Bethke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 19:34:29 -0000 2009/5/22 Stefan Bethke : > Just updated my month-old current. =C2=A0On boot, ifconfig triggers this = panic: > > Trying to mount root from ufs:/dev/mirror/diesel_root > > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 > (probe0:umass-sim0:0:0:0): Medium not present > (probe0:umass-sim0:0:0:0): Unretryable error > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > Entropy harvesting: interrupts ethernet > point_to_point(probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0= 0 > (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 > (probe0:umass-sim0:0:0:1): Medium not present > (probe0:umass-sim0:0:0:1): Unretryable error > da1 at umass-sim0 bus 0 target 0 lun 1 > da1: Removable Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > =C2=A0kickstart. > /odev/mirror/diesel_root: FILE SYSTEM CLEAN; SKIPPING CHECKS > /deirror/diesel_root: clean, 759914 free (27202 frags, 91589 blocks, 1.3% > fragmentation) > bridge0: Ethernet address: d6:a8:2e:5f:c3:64 > tap0: Ethernet address: 00:bd:4b:24:00:00 > tap0: promiscuous mode enabled > vlan1: promiscuous mode enabled > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > instruction pointer =C2=A0 =C2=A0 =3D 0x20:0xffffffff80323f5b > stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xffffff80771c2= 760 > frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xffffff80771c2= 770 > code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, limit= 0xfffff, type 0x1b > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D resume, IOPL =3D 0 > current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 536 (ifconfig) > [thread pid 536 tid 100085 ] > Stopped at =C2=A0 =C2=A0 =C2=A0turnstile_setowner+0x2b: =C2=A0 =C2=A0 =C2= =A0 =C2=A0movq =C2=A0 =C2=A0%rcx,0x68(%rdx) > db> bt > Tracing pid 536 tid 100085 td 0xffffff0004533ab0 > turnstile_setowner() at turnstile_setowner+0x2b > turnstile_wait() at turnstile_wait+0x296 > _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 > _mtx_lock_flags() at _mtx_lock_flags+0x43 > ifaof_ifpforaddr() at ifaof_ifpforaddr+0x57 > rt_getifa_fib() at rt_getifa_fib+0xa8 > rtrequest1_fib() at rtrequest1_fib+0x3d9 > in_ifinit() at in_ifinit+0x3ba > in_control() at in_control+0xd81 > ifioctl() at ifioctl+0x2de > kern_ioctl() at kern_ioctl+0xb6 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x800a6efbc, rsp =3D > 0x7fffffffe4c8, rbp =3D 0x7fffffffef6d --- > db> > > > I've added an additional debug to network.subr to find out which ifconfig > exactly it trips over, and it appears to be: > > /etc/rc: DEBUG: Cloned: bridge0 tap0 vlan1 vlan2 vlan3 > /etc/rc: DEBUG: ifconfig lo0 inet 127.0.0.1 > /etc/rc: DEBUG: ifconfig em0 up > /etc/rc: DEBUG: tifconfig bridge0a ether 02:00:00:p00:00:01 addm ta0p0 ad= dm > vlan1 > : promiscuous mode enabled > vlan1: promiscuous mode enabled > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > instruction pointer =C2=A0 =C2=A0 =3D 0x20:0xffffffff80323f5b > stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xffffff80771c7= 760 > frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xffffff80771c7= 770 > code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, limit= 0xfffff, type 0x1b > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D resume, IOPL =3D 0 > current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 581 (ifconfig) > > (The serial link is only 3wire, so it's slightly garbled.) > > This corresponds to these rc.conf settings: > ifconfig_bridge0=3D"ether 02:00:00:00:00:01" > ifconfig_bridge0_alias0=3D"addm tap0 addm vlan1" > > It appears that adding vlan1 triggers the panic. > > Using the month-old kernel manages to bring up the system, but I'm gettin= g a > generic "login: Could not determine audit condition" on the console. > > Additionally, while changing configuration in single user with the > up-to-date kernel, I got this on reboot: > > Syncing disks, vnodes remaining...0 done > All buffers synced. > GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed. > Uptime: 6m32s > GEOM_MIRROR: Device diesel_root destroyed. > Rebooting... > cpu_reset: Stopping other CPUs > spin lock 0xffffffff8078c900 (sched lock 1) held by 0xffffff00014d4ab0 (t= id > 100002) too long > panic: spin lock held too long > cpuid =3D 0 > KDB: enter: panic > [thread pid 77 tid 100090 ] > Stopped at =C2=A0 =C2=A0 =C2=A0kdb_enter+0x3d: movq =C2=A0 =C2=A0$0,0x48b= bd0(%rip) > db> bt > Tracing pid 77 tid 100090 td 0xffffff000457bab0 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 > _mtx_lock_spin() at _mtx_lock_spin+0x9e > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 > sched_balance_group() at sched_balance_group+0xc5 > sched_balance_group() at sched_balance_group+0x1f8 > sched_balance() at sched_balance+0xa2 > sched_clock() at sched_clock+0xf6 > statclock() at statclock+0xbd > lapic_handle_timer() at lapic_handle_timer+0x197 > Xtimerint() at Xtimerint+0x8c > --- interrupt, rip =3D 0xffffffff80541cc4, rsp =3D 0xffffff80771dba90, rb= p =3D > 0xffffff80771dbab0 --- > DELAY() at DELAY+0x64 > cpu_reset() at cpu_reset+0xdd > boot() at boot+0x2e6 > reboot() at reboot+0x42 > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (55, FreeBSD ELF64, reboot), rip =3D 0x800788eec, rsp =3D > 0x7fffffffeca8, rbp =3D 0 --- Did this happen inside VMware or with normal running? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri May 22 19:46:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D4F1065670 for ; Fri, 22 May 2009 19:46:21 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 21EDF8FC1C for ; Fri, 22 May 2009 19:46:21 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1171413ywe.13 for ; Fri, 22 May 2009 12:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=yxA4r+CkoEAk9lxij0XuORTj451KmCbrBg4Fq7kUFVU=; b=p39+TwJNsVvVL7j4UXmNguXqASrqJUcZuv5d5+hsdIkujGylbLqM68O/D48CUaoNFo +YKIM9BlHHrhq9uGxQ7/ai+MKTopf1pJLrqbOcZYR2GWA7J80AMCUCJ7Kz5a5gvUJ24r vMs9JYQ3cQJEmkXPc1EtuV/X1xU6J++gc+Kpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AlI92jS2Zo3Xooqoagzlm/QQtP9UvSnF8FYrceSic9V9H8aa9WvDZL/I7TOx2S8Srm Tn0AkLxJnHHmsI6VCoZzpFmI3a1WtXrQfFP58gk4m80JSLlnGhWNzR4RhQ6wUOpDxXMT lyDMnhBkZr8KiRgNLVkO/ofnxZNReFWyte5YY= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.215.12 with SMTP id n12mr7873454ang.133.1243021580124; Fri, 22 May 2009 12:46:20 -0700 (PDT) In-Reply-To: <87pre1nvl9.fsf@tabernacle.lan> References: <20090521215221.GA98253@server.vk2pj.dyndns.org> <87pre1nvl9.fsf@tabernacle.lan> Date: Fri, 22 May 2009 12:46:20 -0700 X-Google-Sender-Auth: 57c82705d4d1557f Message-ID: <3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com> From: Kip Macy To: Julian Stecklina Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 19:46:21 -0000 > You can use microkernels[1] for almost the same thing. It's what we do > at Technische Universit=E4t Dresden. > > Regards, > -- > Julian Stecklina > > The day Microsoft makes something that doesn't suck is probably the day > they start making vacuum cleaners - Ernst Jan Plugge > > Footnotes: > [1] =A0There is a sexy new microhypervisor to be released Real Soon > =A0 =A0 Now(tm) too: > =A0 =A0 http://eurosys09dw.systems.ethz.ch/steinberg.pdf > Based on L4Linux, I believe that the amount of work required for porting a PV OS is much less than creating a new "personality" for a microkernel. That said, isn't a hypervisor really a microkernel with device and virtual memory abstraction API? Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Fri May 22 19:54:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847D11065670; Fri, 22 May 2009 19:54:10 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 551B08FC15; Fri, 22 May 2009 19:54:10 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n4MJs8D0028349; Fri, 22 May 2009 21:54:08 +0200 Received: from [192.168.100.199] ([88.11.0.226]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009052221540839:147858 ; Fri, 22 May 2009 21:54:08 +0200 Message-ID: <4A1702A4.3010102@entel.upc.edu> Date: Fri, 22 May 2009 21:53:08 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin Wilke References: <20090522175956.GA33004@bsdcrew.de> In-Reply-To: <20090522175956.GA33004@bsdcrew.de> X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 21:54:08, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 21:54:09, Serialize complete at 22/05/2009 21:54:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 22 May 2009 21:54:09 +0200 (CEST) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 19:54:13 -0000 > > We rolled a new version with a fix for all users where has problems > with kernel load and unload. Many thanks to Shin-ichi Okano where > submitted this patch to the vbox ml. > > http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz > > happy testing. > > Hi everyone, I'm using i386/CURRENT updated today two hours ago. procfs mounted. Cleaned emulators/virtualbox directory. Unpacked virtualbox_4.tgz, recompiled and reinstalled. Rebooted the machine. Kldloaded vboxdrv.ko. When starting a virtual machine the screen remains gray. No cpu usage at all. As I said in a previous mail, in the same machine it works with STABLE. Any hint ? Regards, -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:03:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B060106566C for ; Fri, 22 May 2009 20:03:07 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1237E8FC15 for ; Fri, 22 May 2009 20:03:07 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 5F4235C34; Fri, 22 May 2009 16:03:06 -0400 (EDT) Date: Fri, 22 May 2009 16:03:06 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090522200306.GE2630@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:03:07 -0000 On Fri, May 22, 2009 at 10:00:56AM +0200, Thomas Backman wrote: > On May 22, 2009, at 09:31 AM, Thomas Backman wrote: > > > > ... > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > > > Actually, I still get these. Bummer. > > [root@chaos /usr/local/sbin]# execsnoop > UID PID PPID ARGS > 0 1931 1924 /bin/sh > 0 1931 1924 /bin/sh > 0 1932 1931 /bin/mkdir > 0 1932 1931 /bin/mkdir > dtrace: error on enabled probe ID 2 (ID 39086: > syscall::execve:return): invalid address (0xffffff803e8cfae0) in > action #8 > dtrace: error on enabled probe ID 3 (ID 39086: > syscall::execve:return): invalid address (0xffffff803e8cfae0) in > action #8 > 0 1944 1933 mktemp > 0 1944 1933 mktemp > dtrace: error on enabled probe ID 2 (ID 39086: > syscall::execve:return): invalid address (0xffffff803ea58ae0) in > action #8 > dtrace: error on enabled probe ID 3 (ID 39086: > syscall::execve:return): invalid address (0xffffff803ea58ae0) in > action #8 > dtrace: error on enabled probe ID 2 (ID 39086: > syscall::execve:return): invalid address (0xffffff803ea9eae0) in > action #8 > dtrace: error on enabled probe ID 3 (ID 39086: > syscall::execve:return): invalid address (0xffffff803ea9eae0) in > action #8 > 0 1948 1947 /bin/sh > 0 1948 1947 /bin/sh > 0 1949 1948 vnstat > 0 1949 1948 vnstat > 0 1950 1933 /bin/rm > 0 1950 1933 /bin/rm > 0 1951 1907 /bin/sh > 0 1951 1907 /bin/sh > 0 1952 1951 make > 0 1952 1951 make > > (No idea why everything is printed twice either.) > Also, the DTrace variable "walltimestamp" seems to return "1970 Jan 1 > 01:00:00" (I'm in GMT+2 right now, btw) every time. This leads me to believe it's a race somewhere. Another datapoint: whatever was changed also made it into 7.2 as that is broken in the same fashion. I just installed a 7.1 VM and tried it there and it works. -- WXS From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:21:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F203106564A; Fri, 22 May 2009 20:21:07 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3578FC27; Fri, 22 May 2009 20:21:06 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 546F54AC5C; Fri, 22 May 2009 22:21:02 +0200 (CEST) Date: Fri, 22 May 2009 22:21:02 +0200 From: Martin Wilke To: Gustau =?iso-8859-1?Q?P=E9rez?= Message-ID: <20090522202102.GB33004@bsdcrew.de> References: <20090522175956.GA33004@bsdcrew.de> <4A1702A4.3010102@entel.upc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A1702A4.3010102@entel.upc.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:21:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, May 22, 2009 at 09:53:08PM +0200, Gustau Pérez wrote: > > > > > We rolled a new version with a fix for all users where has problems > > with kernel load and unload. Many thanks to Shin-ichi Okano where > > submitted this patch to the vbox ml. > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz > > > > happy testing. > > > > > Hi everyone, > > I'm using i386/CURRENT updated today two hours ago. procfs mounted. > Cleaned emulators/virtualbox directory. Unpacked virtualbox_4.tgz, > recompiled and reinstalled. Rebooted the machine. Kldloaded > vboxdrv.ko. When starting a virtual machine the screen remains gray. > No cpu usage at all. > > As I said in a previous mail, in the same machine it works with > STABLE. > > Any hint ? > > Regards, rm -rf /tmp/.vbox-* doesen't help ? > > -- > PGP KEY : http://www-entel.upc.edu/gus/gus.asc > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoXCS4ACgkQdLJIhLHm/OndLQCfd2eMo8fhBPGyBQ8VWNf9LMr9 SMsAoKAMie6Ehso0d1KV9fUMXT/oHkbO =jVGl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:24:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E02B0106566B; Fri, 22 May 2009 20:24:37 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0CD8FC1B; Fri, 22 May 2009 20:24:37 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n4MKOPKR030133; Fri, 22 May 2009 22:24:25 +0200 Received: from [192.168.100.199] ([88.11.0.226]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009052222243476:147904 ; Fri, 22 May 2009 22:24:34 +0200 Message-ID: <4A1709EA.2000207@entel.upc.edu> Date: Fri, 22 May 2009 22:24:10 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin Wilke References: <20090522175956.GA33004@bsdcrew.de> <4A1702A4.3010102@entel.upc.edu> <20090522202102.GB33004@bsdcrew.de> In-Reply-To: <20090522202102.GB33004@bsdcrew.de> X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 22:24:34, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 22/05/2009 22:24:35, Serialize complete at 22/05/2009 22:24:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 22 May 2009 22:24:25 +0200 (CEST) Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:24:38 -0000 > > > rm -rf /tmp/.vbox-* doesen't help ? > Nope. Vbox recreates the directory /tmp/.vbox-root-ipc. Nothing in /var/log/messages. Do you want an screenshot of it ? Regards, Gus -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:26:40 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD49610656E8; Fri, 22 May 2009 20:26:40 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3188FC15; Fri, 22 May 2009 20:26:40 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 0D9574AC5C; Fri, 22 May 2009 22:26:36 +0200 (CEST) Date: Fri, 22 May 2009 22:26:36 +0200 From: Martin Wilke To: Gustau =?iso-8859-1?Q?P=E9rez?= Message-ID: <20090522202635.GC33004@bsdcrew.de> References: <20090522175956.GA33004@bsdcrew.de> <4A1702A4.3010102@entel.upc.edu> <20090522202102.GB33004@bsdcrew.de> <4A1709EA.2000207@entel.upc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A1709EA.2000207@entel.upc.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:26:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, May 22, 2009 at 10:24:10PM +0200, Gustau Pérez wrote: > > > > > > > rm -rf /tmp/.vbox-* doesen't help ? > > > > Nope. Vbox recreates the directory /tmp/.vbox-root-ipc. Nothing in > /var/log/messages. Do you want an screenshot of it ? Recreates are ok and normal, could you please vbox start with truss and send me the output? - - Martin > > Regards, > > Gus > > > -- > PGP KEY : http://www-entel.upc.edu/gus/gus.asc > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoXCnsACgkQdLJIhLHm/Ok4TwCg00ky7mVkvPhm/+p8Yuhkg8tH su0An2ccm2vd8jjIwAZI9HOyM0vUoaa5 =io6Y -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:32:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C259D106568A for ; Fri, 22 May 2009 20:32:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCC58FC1D for ; Fri, 22 May 2009 20:32:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D3E4.dip.t-dialin.net [217.226.211.228]) by redbull.bpaserver.net (Postfix) with ESMTP id 4099F2E0EF; Fri, 22 May 2009 22:32:40 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id 8A648243A8E; Fri, 22 May 2009 22:32:36 +0200 (CEST) Date: Fri, 22 May 2009 22:32:35 +0200 From: Alexander Leidinger To: Roman Divacky Message-ID: <20090522223235.000030c8@unknown> In-Reply-To: <20090521211013.GA76374@freebsd.org> References: <20090521204607.GA34381@mavetju.org> <20090521211013.GA76374@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.10.13; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4099F2E0EF.30D0D X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.823, required 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, TW_TD 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org, Edwin Groothuis Subject: Re: Update of tzcode from 2004a to 2009e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:32:47 -0000 On Thu, 21 May 2009 23:10:14 +0200 Roman Divacky wrote: > On Fri, May 22, 2009 at 06:46:07AM +1000, Edwin Groothuis wrote: > > Please be informed that I will commit an update to the tzcode Yeah! > > related code (zic, zdump, stdtime of libc) in the coming days. Last > > year[1] > > what new is there? what will it improve? One point is: linux_base-fX with X >= at least 8 will work without problems related to the local time (the linux date will print the right time). Bye, Alexander. From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:33:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8A5106564A for ; Fri, 22 May 2009 20:33:51 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 8B74D8FC16 for ; Fri, 22 May 2009 20:33:50 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by bwz9 with SMTP id 9so1926951bwz.43 for ; Fri, 22 May 2009 13:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=wgM9ti/uTsWfSZ3lL8/Gxny4u5bA0GVqLejonv5SNZw=; b=qziuD3tY9zuZG6PYLhhGY8idJteGxgHC8mddbjexBLbihiNSoO1m2vNu0tw54hBT7O 2TkZTt4yYGlhCAoAejeT9IRkcIZZXblTkoeRjAcJqgxXyu32eIsjVZ2c3uy/yjitIVBJ YM40KMLp0xfL+hVKpaGLE1UITR4lyY2XB9VSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IYJMUnL33lkRMEkqE+2H82SvOQHZ/Rt6T1ZlOcUnyCz39HW5m5iG14rO89eO1p+/pP mfL73jMXP7BqRyvuJGD5IagQ6whDp56tamUIDs4PXN8uNKTdDCpP/PreeReoawOrKiN4 SJC/vNz2gbGDRJViQXm5aRlLhkrEyauXuAT7Q= MIME-Version: 1.0 Received: by 10.204.58.9 with SMTP id e9mr3964605bkh.15.1243024429123; Fri, 22 May 2009 13:33:49 -0700 (PDT) Date: Fri, 22 May 2009 17:33:49 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Who is the current maintainer of BSNMP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:33:51 -0000 Hi, I sent an email to -hackers two days ago, cc Harti Brandt and Shteryana Shopova , asking about IPv6 support in bsnmp and bsnmptools. No answer, so far, so I suspect that the packages are orphaned. Is this true? Now I have some fixes and enhancements that I'd like to discuss but I'm not sure about the correct forum. bsnmp is part of the basic system (under contrib), but bsnmptools is available as a port. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-current@FreeBSD.ORG Fri May 22 20:55:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9596E106564A for ; Fri, 22 May 2009 20:55:06 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-px0-f106.google.com (mail-px0-f106.google.com [209.85.216.106]) by mx1.freebsd.org (Postfix) with ESMTP id 54E288FC18 for ; Fri, 22 May 2009 20:55:06 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by pxi4 with SMTP id 4so1774024pxi.3 for ; Fri, 22 May 2009 13:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=xkJDu+a06amfQlNY6XqdlN+IjKTWmZ+ayjHz/T3hECc=; b=ARp0yZ8CxMVZDIPrXuTeybST1gkWDyEov1gGjKtlNH/MW8JvHvK9rL/E9Et0H+ScDP Ush3z0iuCLuGki0WAjaMc41RmUUsWry7ZPI2o5ugwpJ+gtbQQXm2QZ5+kypby4gJNdOw 8a3T/UeJcNZisISO2+dcwAj4hy+daadQwcJy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=sTl617fCP2hs10EpwFP99fv29cV8CHXBUNnBLc/wSHJABRKMMjkRKm6Bb7xYuCxsMW o1KqaHFXNYnsjTrEXs3MJnbAk1UWWDyYYhrEKh4eJ0egDyv9uLIiEbL2FEJ3L5N08UBS IZce+uZLVMzDxzzRJbkiM1Bvth8KuM0uoGc7w= Received: by 10.115.110.15 with SMTP id n15mr8651454wam.16.1243025705976; Fri, 22 May 2009 13:55:05 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.14.66]) by mx.google.com with ESMTPS id l28sm809822waf.54.2009.05.22.13.55.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 May 2009 13:55:04 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 8CA60B8143; Fri, 22 May 2009 17:54:56 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Fri, 22 May 2009 17:54:56 -0300 (BRT) Message-ID: <8b8495f28364f457eebb2262fdae7e03.squirrel@10.1.1.10> In-Reply-To: <4A14956E.2040608@acm.poly.edu> References: <726e1882eb2ec94370bfec1666ec20f2.squirrel@10.1.1.10> <200905201227.46674.mel.flynn+fbsd.current@mailing.thruhere.net> <4a36be1c432cfacf71ffa75ce3abbdd0.squirrel@10.1.1.10> <4A14956E.2040608@acm.poly.edu> Date: Fri, 22 May 2009 17:54:56 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: is my slow for this ? hostap related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:55:06 -0000 On Wed, May 20, 2009 20:42, Boris Kochergin wrote: > Nenhum_de_Nos wrote: >> On Wed, May 20, 2009 07:27, Mel Flynn wrote: >> >>> Hi Nenhum, >>> >>> On Monday 18 May 2009 01:08:09 Nenhum_de_Nos wrote: >>> >>> >>>> I have an atheros wlan card: >>>> >>>> ath0@pci0:0:11:0: class=0x020000 card=0x3a131186 chip=0x0013168c >>>> rev=0x01 hdr=0x00 >>>> vendor = 'Atheros Communications Inc.' >>>> device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' >>>> class = network >>>> subclass = ethernet >>>> >>> >>> >>> >>>> May 17 13:19:36 floyd kernel: ath0: stuck beacon; resetting (bmiss >>>> count >>>> 4) >>>> May 17 13:20:07 floyd last message repeated 89 times >>>> May 17 13:22:08 floyd last message repeated 376 times >>>> >>>> I've read this: >>>> >>>> http://www.nabble.com/ath0:-stuck-beacon--resetting-(bmiss-count-4)-td22359 >>>> 155.html >>>> >>>> and I'm thinking my pc is slow for the job, as said. >>>> >>>> floyd# cat dmesg.today >>>> Copyright (c) 1992-2009 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, >>>> 1994 >>>> The Regents of the University of California. All rights reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 8.0-CURRENT #0: Tue May 5 23:08:28 BRT 2009 >>>> root@floyd.apartnet:/usr/obj/usr/src/sys/Floyd8 >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> Read /usr/src/UPDATING about WITNESS options and which to delete from >>> GENERIC >>> >> >> I did, both read and recompile ... no good. >> >> I put: >> ral0@pci0:0:11:0: class=0x028000 card=0x3a711186 chip=0x03021814 >> rev=0x00 >> hdr=0x00 >> vendor = 'Ralink Technology, Corp' >> device = 'RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless >> a/b' >> class = network >> >> on there, no good also. is slow in the beginning, and then dies forever. >> >> I tried on a 950MHz duron and got the same results (atheros card only). >> unfortunately I can't test this duron anymore as it died from bad PSU. >> >> what made atheros happy was a Core 2 Duo, 2.66GHz at work. faster >> downloads and no even one of those lines :( >> >> too bad I just have an AthlonXP I can use as AP :( >> and soekris in future would be a way, now I think is slow as well ... >> >> thanks, >> >> matheus >> >> >>> kernel. I think once you turn those options off, your machine should be >>> able >>> to handle this, though I wouldn't run anything else on it. On a single >>> 1.8Ghz >>> 686, I got these occasionally, when backups were done over gigabit and >>> a >>> movie >>> was playing on it. I've since reconfigured the machine as dedicated >>> media >>> server and replaced the router with a headless 3Ghz 686, also running >>> squid. >>> This is overkill for my home network, though. >>> -- >>> Mel >>> >>> >> >> >> > I don't think your CPU is at fault. While I don't have any Crusoes, I > have several machines, ranging from Pentiums running at 200 MHz to > Pentium IIIs running at 933 MHz, with AR5212 cards in them. They run > 7.0-, 7.1-, and 7.2-RELEASE. While I do get some "stuck beacon" and > "device timeout" messages on them, they can all push at least 2 MB/s on > the AR5212 cards, and I am assuming that your Crusoe is faster than a > Pentium 200. > > -Boris well, there is some magic in this. as I do agree they are faster (at least the time to compile world + kernel is about half of my PII 333MHz). but I just got it running on the Core 2. crusoe just last some minutes, and stuck beacons do take over :( if anyone have any idea, of other things that could have to do with this. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Fri May 22 22:53:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E814106566B; Fri, 22 May 2009 22:53:13 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id A62698FC13; Fri, 22 May 2009 22:53:12 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4MMr997048843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 May 2009 00:53:10 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Attilio Rao , "Bjoern A. Zeeb" In-Reply-To: <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 23 May 2009 00:53:09 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 22:53:13 -0000 Am 22.05.2009 um 21:34 schrieb Attilio Rao: > Did this happen inside VMware or with normal running? I encountered this originally on my main server: FreeBSD 8.0-CURRENT #4: Sat Mar 28 12:46:14 CET 2009 root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.77-MHz K8- class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features = 0xbfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP ,MTRR ,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2 =0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant Cores per package: 2 usable memory = 4177514496 (3983 MB) avail memory = 4009562112 (3823 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This is an Intel DG45FC board. The same kernel from May 21 also crashes in a VMware instance. Using the same kernel config to create a kernel on the VMware instance also panics. GENERIC from the same sources does not crash in a VMware instance; I haven't tried on real hardware yet. Configs and the kernels are at http://www.lassitu.de/freebsd/ifconfig-panic/ I'm currently trying to take out things from the DIESEL config until it stops panicking or I end up with stock GENERIC, using my VMware instance. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri May 22 22:41:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C3A106567A; Fri, 22 May 2009 22:41:38 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 74FC98FC17; Fri, 22 May 2009 22:41:37 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by k7.mavetju.org (Postfix, from userid 1001) id BADC6450BE; Sat, 23 May 2009 08:40:45 +1000 (EST) Date: Sat, 23 May 2009 08:40:45 +1000 From: Edwin Groothuis To: Alexander Leidinger Message-ID: <20090522224045.GN55280@mavetju.org> References: <20090521204607.GA34381@mavetju.org> <20090521211013.GA76374@freebsd.org> <20090522223235.000030c8@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090522223235.000030c8@unknown> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 22 May 2009 22:58:06 +0000 Cc: Roman Divacky , freebsd-current@freebsd.org, Edwin Groothuis Subject: Re: Update of tzcode from 2004a to 2009e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 22:41:39 -0000 On Fri, May 22, 2009 at 10:32:35PM +0200, Alexander Leidinger wrote: > On Thu, 21 May 2009 23:10:14 +0200 Roman Divacky > wrote: > > > > On Fri, May 22, 2009 at 06:46:07AM +1000, Edwin Groothuis wrote: > > > Please be informed that I will commit an update to the tzcode > > Yeah! > > > > related code (zic, zdump, stdtime of libc) in the coming days. Last > > > year[1] > > > > what new is there? what will it improve? > > One point is: > linux_base-fX with X >= at least 8 will work without problems related > to the local time (the linux date will print the right time). Yeah, I forgot about that reason which was more or less the main reason I took up chasing it up again :-) Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-current@FreeBSD.ORG Fri May 22 23:05:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E632B106564A for ; Fri, 22 May 2009 23:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7CB8FC1B for ; Fri, 22 May 2009 23:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 705DC41C7A4; Sat, 23 May 2009 01:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id sLY+pJriSU3f; Sat, 23 May 2009 01:05:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 17BF741C7A3; Sat, 23 May 2009 01:05:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2520A4448E6; Fri, 22 May 2009 23:04:33 +0000 (UTC) Date: Fri, 22 May 2009 23:04:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Stefan Bethke In-Reply-To: Message-ID: <20090522230333.X72053@maildrop.int.zabbadoz.net> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 23:05:08 -0000 On Sat, 23 May 2009, Stefan Bethke wrote: Hi, SVN r192612 [1] is believed to fix the problems. Let us know if it doesn't. /bz [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=192612 -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri May 22 23:12:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED86106566C; Fri, 22 May 2009 23:12:48 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 218898FC0C; Fri, 22 May 2009 23:12:47 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4MNCk9r052100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 May 2009 01:12:46 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <8F9221D5-B16C-488D-A28B-342B315F507C@lassitu.de> From: Stefan Bethke To: "Bjoern A. Zeeb" In-Reply-To: <20090522230333.X72053@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 23 May 2009 01:12:45 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.935.3) Cc: Attilio Rao , FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 23:12:48 -0000 Am 23.05.2009 um 01:04 schrieb Bjoern A. Zeeb: > On Sat, 23 May 2009, Stefan Bethke wrote: > > Hi, > > SVN r192612 [1] is believed to fix the problems. Let us know if it > doesn't. Will try asap. I just confirmed that the relevant difference between the working and panicking kernels is indeed options ROUTETABLES. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri May 22 23:20:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC924106566C; Fri, 22 May 2009 23:20:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8605A8FC1B; Fri, 22 May 2009 23:20:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DA54041C7A3; Sat, 23 May 2009 01:20:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 8NfQzGWwy9ut; Sat, 23 May 2009 01:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 7F16E41C7A6; Sat, 23 May 2009 01:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D7F9B4448E6; Fri, 22 May 2009 23:16:27 +0000 (UTC) Date: Fri, 22 May 2009 23:16:27 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Attila Nagy In-Reply-To: <4A1057D2.5090800@fsn.hu> Message-ID: <20090522231449.K72053@maildrop.int.zabbadoz.net> References: <4A1057D2.5090800@fsn.hu> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list , net@freebsd.org Subject: Re: Routing related crash in -CURRENT, introduced between 5th May and yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 23:20:07 -0000 On Sun, 17 May 2009, Attila Nagy wrote: Hi, > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: SVN r192612 [1] ishould fix the problems. Let us know if it does not. /bz [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=192612 -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat May 23 00:49:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5367A106564A for ; Sat, 23 May 2009 00:49:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 049768FC0C for ; Sat, 23 May 2009 00:49:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQGAFLlFkqDaFvK/2dsb2JhbACOBwHDbYQLBQ X-IronPort-AV: E=Sophos;i="4.41,235,1241409600"; d="scan'208";a="34219096" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 May 2009 20:49:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 3F9C9109C28B for ; Fri, 22 May 2009 20:49:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRmTX1Qx0jix for ; Fri, 22 May 2009 20:49:36 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id B9E3B109C24A for ; Fri, 22 May 2009 20:49:36 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4N0oMX05996 for ; Fri, 22 May 2009 20:50:22 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 22 May 2009 20:50:21 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: sys/nfsserver/nfs_srvkrpc.c doesn't build with KGSSAPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 00:49:38 -0000 I just noticed that sys/nfsserver/nfs_srvkrpc.c doesn't build when options KGSSAPI is specified. "hostname" is undefined This appears to be because it is now inside: #ifdef VIMAGE_GLOBALS ... #endif in sys/sys/kernel.h. I figured I'd let someone more familiar with what VIMAGE_GLOBALS is used for decide how best to fix this. rick From owner-freebsd-current@FreeBSD.ORG Sat May 23 01:00:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D15F106566B for ; Sat, 23 May 2009 01:00:13 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id E5BA38FC13 for ; Sat, 23 May 2009 01:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7E5CD41C7A4; Sat, 23 May 2009 03:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ISw-RlFucZTr; Sat, 23 May 2009 03:00:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 2105B41C7A3; Sat, 23 May 2009 03:00:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5F79C4448E6; Sat, 23 May 2009 00:58:13 +0000 (UTC) Date: Sat, 23 May 2009 00:58:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Rick Macklem In-Reply-To: Message-ID: <20090523005657.W72053@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sys/nfsserver/nfs_srvkrpc.c doesn't build with KGSSAPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 01:00:13 -0000 On Fri, 22 May 2009, Rick Macklem wrote: > I just noticed that sys/nfsserver/nfs_srvkrpc.c doesn't build when > options KGSSAPI is specified. > > "hostname" is undefined > > This appears to be because it is now inside: > > #ifdef VIMAGE_GLOBALS > ... > #endif > in sys/sys/kernel.h. > > I figured I'd let someone more familiar with what VIMAGE_GLOBALS is used > for decide how best to fix this. This is because you neither use G_hostname (always global as in base system) or V_hostname (viertualized one; per network stack). See sys/vimage.h and other usages in sys/ for how to properly handle this. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat May 23 01:24:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D220B106566C; Sat, 23 May 2009 01:24:01 +0000 (UTC) (envelope-from js@alien8.de) Received: from mail.skyhub.de (cl-3117.ham-01.de.sixxs.net [IPv6:2001:6f8:900:c2c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 45E5A8FC12; Sat, 23 May 2009 01:24:00 +0000 (UTC) (envelope-from js@alien8.de) Received: from localhost (localhost [127.0.0.1]) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id 349F11D9CFC; Sat, 23 May 2009 03:23:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1243041839; bh=2n/VkNwwzG1NMoSnbnBr01vWZBEPMWOhR1lacuMnppI=; h=To:Cc:Subject:References:From:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=PBWt4Ne4zhJMU8IaibQASj33MZKt2AueB4laX ubF53RZL0lkEELOnaC41o4Kpsmt1apr0QzBDEhpSzCiXc3fEWqBoD/P8LAM1yrbu29i Vr6ibUiHUU8wil9PCUaHOqTFoX/9uzkEu52xMzthcLpXPyQInP8YrECF5cQBJolhAvc = X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H3ey5ZAF72fm; Sat, 23 May 2009 03:23:59 +0200 (CEST) Received: from tabernacle.localnet (cl-76.dus-01.de.sixxs.net [IPv6:2a01:198:200:4b::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 86A681D9CE7; Sat, 23 May 2009 03:23:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1243041839; bh=2n/VkNwwzG1NMoSnbnBr01vWZBEPMWOhR1lacuMnppI=; h=To:Cc:Subject:References:From:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=PBWt4Ne4zhJMU8IaibQASj33MZKt2AueB4laX ubF53RZL0lkEELOnaC41o4Kpsmt1apr0QzBDEhpSzCiXc3fEWqBoD/P8LAM1yrbu29i Vr6ibUiHUU8wil9PCUaHOqTFoX/9uzkEu52xMzthcLpXPyQInP8YrECF5cQBJolhAvc = To: Kip Macy References: <20090521215221.GA98253@server.vk2pj.dyndns.org> <87pre1nvl9.fsf@tabernacle.lan> <3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com> X-Archive: encrypt From: Julian Stecklina X-Hashcash: 1:23:090523:kmacy@freebsd.org::qb6TbMwRT4GY+8oG:00000000000000000000000000000000000000000000wQxv X-Hashcash: 1:23:090523:freebsd-current@freebsd.org::EHGjR14AIpUfmsuO:00000000000000000000000000000000014mzw X-Hashcash: 1:23:090523:freebsd-xen@freebsd.org::a5DBnYZlCYFmQ6Rj:00000000000000000000000000000000000000dgFB X-Hashcash: 1:23:090523:freebsd-questions@freebsd.org::9yAgXMAOhqAsldAb:00000000000000000000000000000000BVn+ Date: Sat, 23 May 2009 03:23:56 +0200 In-Reply-To: <3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com> (Kip Macy's message of "Fri\, 22 May 2009 12\:46\:20 -0700") Message-ID: <87octk4no3.fsf@tabernacle.lan> User-Agent: Gnus/5.101 (Gnus v5.10.10) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: My FreeBSD-current/Xen install notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 01:24:02 -0000 Kip Macy writes: > Based on L4Linux, I believe that the amount of work required for > porting a PV OS is much less than creating a new "personality" for a > microkernel. That said, isn't a hypervisor really a microkernel with > device and virtual memory abstraction API? OS personalities were a promise that was always brought up with microkernels, but never really delivered. Although, L4Linux could be seen as "Linux personality" for L4. The nice thing about microkernels is that they abstract enough of the underlying hardware to be open for a lot of experimenting. I think this is quite nice for student projects. On the microkernel vs. hypervisor topic: L4 has a very nice virtual memory abstraction and you can build device abstraction quite easily on top of it. If you only want paravirtualization, L4 could have delivered that years before Xen did. And actually it did: L4Linux exists for quite some time and I believe that there was also a paper on live migration of L4Linux instances way before Xen did that. IMHO given some commercial support (and some foresight), L4 could have been the better Xen. Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Sat May 23 01:46:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0176D1065674 for ; Sat, 23 May 2009 01:46:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 75F858FC12 for ; Sat, 23 May 2009 01:46:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz9 with SMTP id 9so2030575bwz.43 for ; Fri, 22 May 2009 18:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=S9GsmgbJU3PoHdAbarAX5VxLNab1gHu6NV3/FMsSGC0=; b=toCn5H8mfegcu4D7C7XBBfc+vyw+bkIpCtX+UjiKnzclpBoZcNqh6efqDI+SbnWpfF S3wOYKeQCKTI7E8rlz0qm6VGVndlGTdLOujrGlyB2f6/jD1bzJPHbKIYT+mXHMc2bHeI 4zVz2Ua6JpevO7xn/B22qsQ91s9oBiZbWNEfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GqpiGY3Q0ycztVFu6KLtHxZv9vc+q5gzAgzIXmqHNiS44L1SxZbbuDOHDJ6nLRafVR lbZ2KSn4KekKktZMbwOlHn3V8VSwGfRq2txf3LwPyX9t2iXL6DquBxGwod9NK5aYm1f8 FEOeGy5WmwGWQPg6edY5BQsNW62MzwtVLYl4c= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.106.14 with SMTP id v14mr2634163fao.49.1243043163449; Fri, 22 May 2009 18:46:03 -0700 (PDT) In-Reply-To: <20090522230333.X72053@maildrop.int.zabbadoz.net> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> Date: Sat, 23 May 2009 03:46:03 +0200 X-Google-Sender-Auth: 7db91599c0074daf Message-ID: <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> From: Attilio Rao To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Stefan Bethke Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 01:46:05 -0000 2009/5/23 Bjoern A. Zeeb : > On Sat, 23 May 2009, Stefan Bethke wrote: > > Hi, > > SVN r192612 [1] is believed to fix the problems. =C2=A0Let us know if it > doesn't. I'm not sure it does for the panic 'spinlock held too long' on reboot. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat May 23 02:45:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED31F106564A for ; Sat, 23 May 2009 02:45:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id BA2078FC24 for ; Sat, 23 May 2009 02:45:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so857586rvb.43 for ; Fri, 22 May 2009 19:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=QfmpP8pW9Z8YJyaUpACfzfW1HOTuy2TuIxvcwUKb80o=; b=tXMJsCZfW9clUMT4ZiT6rw9W3+CEgh4ymRNpvCncyLbbN5E5ywKP8HUgN0oCeYsLch eoAQ0cn9kNYOtyo1GuNjZ87h/xQcRAXPq4r6UPH62ic9qE6yTMaRIu8u3rVz21faKT6R mVMW8c1SOoU01lmUn4t2T0R4zHO+L7HGsIxjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=OO62bIApGUjv3JtI/qaEIk3pVsir0d7AUY2VLR7KLdEXK+90uPl/u3mUXvtzGCU5YP bYh/ZQC2bKTq/qEHaRii9K0j9ItttxN3P+Gb0bhuc97ekZTRowUHVPcMXshhS9H4cUxO o9eFSUYgr1dZ1UJrith3VJ4lKRXxT9A/+Wz0s= Received: by 10.141.97.5 with SMTP id z5mr1960832rvl.212.1243046715534; Fri, 22 May 2009 19:45:15 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm12396788rvf.30.2009.05.22.19.45.13 (version=SSLv3 cipher=RC4-MD5); Fri, 22 May 2009 19:45:14 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 23 May 2009 11:55:46 +0900 From: Pyun YongHyeon Date: Sat, 23 May 2009 11:55:46 +0900 To: Stephen Montgomery-Smith Message-ID: <20090523025546.GD22204@michelle.cdnetworks.co.kr> References: <20090521041929.GN9043@michelle.cdnetworks.co.kr> <4A16D9A3.9000302@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A16D9A3.9000302@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: CFT: msk(4) and Yukon FE+(88E8040, 88E8040T, 88E8048, 88E8070) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 02:45:16 -0000 On Fri, May 22, 2009 at 11:58:11AM -0500, Stephen Montgomery-Smith wrote: > Pyun YongHyeon wrote: > >Hi, > > > >I had been working on supporting Yukon FE+ for more than a year. > >Lack of hardware and documentation was one of major issue to write > >support code. Recently one user, Tanguy Bouzeloc, submitted fix > >and the patch seems to make msk(4) work on Yukon FE+. You can get > >the latest patch at the following URL. > >http://people.freebsd.org/~yongari/msk/msk.88E8040.patch26 > > > >Since the patch changes a lot of code flow of driver all msk(4) > >users would be affected. If you use msk(4) or have Yukon FE+, > >please give it try and let me know how it goes on your box. > > > >Thanks. > > It works great for me! > > I have a Marvell Yukon 88E8040 Fast Ethernet, and you may remember that > a while back, you tried to get this to work for me, without success. > Yeah, you are one of users who helped to add Yukon FE+ support. > But this driver worked! > Thanks for testing. One user reported he had to UP the interface first in order to make dhclient work. I'm working on it but no clue yet. > Thanks, Stephen From owner-freebsd-current@FreeBSD.ORG Sat May 23 02:50:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5ECA1065676 for ; Sat, 23 May 2009 02:50:38 +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 92C708FC18 for ; Sat, 23 May 2009 02:50:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so858407rvb.43 for ; Fri, 22 May 2009 19:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=qhBssd3xofnKKNX0KknPYXA4gQnOzn/04c/kjrDcF/g=; b=nNrmVlP4DMnuJ8jBPdrk/X4u0yAB6bKBzc1DSGeS4pVMGpLzVcPIlMui9hCE8lIlGP az352tHVhwLG335ZSQcCUhpOj2i3E1Bw7mAnhmibWUmFWZlj8W89ySlBfH26CGr+wQTO Nh0/uvDNZaI9kVhyW9Sn4Xw87GKSapiJ7Che8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tJMfj7sFBRo/A95VJlNKdUieuTIA7KN0qWonzjU63BhAr6M6/E74Id9sBSK7Psmdpc of9EYIUMaPOVEXLXvA7AsepB9kGPIQxF0isRpcgUzpA6AchjsQt0T8n6ChtzwKq/lmsM lFwqN4zSHIvEZG52GGIgCkxAPkaj9YxRaJZ5o= Received: by 10.141.211.8 with SMTP id n8mr2060312rvq.167.1243047038333; Fri, 22 May 2009 19:50:38 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k41sm1427037rvb.7.2009.05.22.19.50.36 (version=SSLv3 cipher=RC4-MD5); Fri, 22 May 2009 19:50:37 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 23 May 2009 12:01:09 +0900 From: Pyun YongHyeon Date: Sat, 23 May 2009 12:01:09 +0900 To: John Baldwin Message-ID: <20090523030109.GE22204@michelle.cdnetworks.co.kr> References: <20090521041929.GN9043@michelle.cdnetworks.co.kr> <200905221314.06146.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905221314.06146.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: CFT: msk(4) and Yukon FE+(88E8040, 88E8040T, 88E8048, 88E8070) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 02:50:39 -0000 On Fri, May 22, 2009 at 01:14:05PM -0400, John Baldwin wrote: > On Thursday 21 May 2009 12:19:29 am Pyun YongHyeon wrote: > > Hi, > > > > I had been working on supporting Yukon FE+ for more than a year. > > Lack of hardware and documentation was one of major issue to write > > support code. Recently one user, Tanguy Bouzeloc, submitted fix > > and the patch seems to make msk(4) work on Yukon FE+. You can get > > the latest patch at the following URL. > > http://people.freebsd.org/~yongari/msk/msk.88E8040.patch26 > > > > Since the patch changes a lot of code flow of driver all msk(4) > > users would be affected. If you use msk(4) or have Yukon FE+, > > please give it try and let me know how it goes on your box. > > FYI, I am using this on 7.x along with some other patches to get an 88E8072 > working (it's the Yukon Extreme (0xb5) chip ID). I finally got it to AFAIK Yukon Extreme also requires some workarounds for silicon bugs as other variants of Yukon controllers. > somewhat work today (it is having TX issues with TSO and TXCSUM enabled, > haven't figured out which one breaks it yet). When I get 8 up and running I Yukon Extreme uses the new descriptor format, the same as Yukon FE+, so you should have 88E8072 use that. I guess it wouldn't be hard to add support for Yukon Extreme once msk(4) got working code for Yukon FE+. > will send you the current patch I have. > Ok, thanks. From owner-freebsd-current@FreeBSD.ORG Sat May 23 07:25:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DDF1106566C; Sat, 23 May 2009 07:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 511FB8FC18; Sat, 23 May 2009 07:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2450441C712; Sat, 23 May 2009 09:25:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id OfxHqLtVy8PM; Sat, 23 May 2009 09:25:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BC44F41C730; Sat, 23 May 2009 09:25:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 016974448E6; Sat, 23 May 2009 07:22:13 +0000 (UTC) Date: Sat, 23 May 2009 07:22:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Attilio Rao In-Reply-To: <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> Message-ID: <20090523072046.H72053@maildrop.int.zabbadoz.net> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-490215599-1243063333=:72053" Cc: FreeBSD Current , Stefan Bethke Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 07:25:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-490215599-1243063333=:72053 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 23 May 2009, Attilio Rao wrote: > 2009/5/23 Bjoern A. Zeeb : >> On Sat, 23 May 2009, Stefan Bethke wrote: >> >> Hi, >> >> SVN r192612 [1] is believed to fix the problems. =A0Let us know if it >> doesn't. > > I'm not sure it does for the panic 'spinlock held too long' on reboot. We are talking about the panic by ifconfig upon boot, when rc.d/netif start runs, here. /bz --=20 Bjoern A. Zeeb The greatest risk is not taking one. --0-490215599-1243063333=:72053-- From owner-freebsd-current@FreeBSD.ORG Sat May 23 08:37:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9681065674; Sat, 23 May 2009 08:37:05 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5707F8FC1D; Sat, 23 May 2009 08:37:05 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4N8b3ID050331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 May 2009 10:37:03 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <48CB609F-B827-4BD8-A131-421ED86180A0@lassitu.de> From: Stefan Bethke To: "Bjoern A. Zeeb" In-Reply-To: <20090522230333.X72053@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 23 May 2009 10:37:02 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.935.3) Cc: Attilio Rao , FreeBSD Current Subject: Re: ifconfig triggers kernel trap on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 08:37:06 -0000 Am 23.05.2009 um 01:04 schrieb Bjoern A. Zeeb: > On Sat, 23 May 2009, Stefan Bethke wrote: > > Hi, > > SVN r192612 [1] is believed to fix the problems. Let us know if it > doesn't. That did indeed fix it for me. Thank you! Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat May 23 08:41:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232E6106566B; Sat, 23 May 2009 08:41:25 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id A8D458FC18; Sat, 23 May 2009 08:41:24 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n4N8fMcg051061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 May 2009 10:41:23 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <226F1AFF-45D8-4E4C-BE7F-D2EDC35EC8F6@lassitu.de> From: Stefan Bethke To: Attilio Rao In-Reply-To: <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 23 May 2009 10:41:22 +0200 References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: "Bjoern A. Zeeb" , FreeBSD Current Subject: Re: spinlock held too long on reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 08:41:25 -0000 I wrote: > Syncing disks, vnodes remaining...0 done > All buffers synced. > GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root > destroyed. > Uptime: 6m32s > GEOM_MIRROR: Device diesel_root destroyed. > Rebooting... > cpu_reset: Stopping other CPUs > spin lock 0xffffffff8078c900 (sched lock 1) held by > 0xffffff00014d4ab0 (tid 100002) too long > panic: spin lock held too long > cpuid = 0 > KDB: enter: panic > [thread pid 77 tid 100090 ] > Stopped at kdb_enter+0x3d: movq $0,0x48bbd0(%rip) > db> bt > Tracing pid 77 tid 100090 td 0xffffff000457bab0 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 > _mtx_lock_spin() at _mtx_lock_spin+0x9e > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 > sched_balance_group() at sched_balance_group+0xc5 > sched_balance_group() at sched_balance_group+0x1f8 > sched_balance() at sched_balance+0xa2 > sched_clock() at sched_clock+0xf6 > statclock() at statclock+0xbd > lapic_handle_timer() at lapic_handle_timer+0x197 > Xtimerint() at Xtimerint+0x8c > --- interrupt, rip = 0xffffffff80541cc4, rsp = 0xffffff80771dba90, > rbp = 0xffffff80771dbab0 --- > DELAY() at DELAY+0x64 > cpu_reset() at cpu_reset+0xdd > boot() at boot+0x2e6 > reboot() at reboot+0x42 > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (55, FreeBSD ELF64, reboot), rip = 0x800788eec, rsp = > 0x7fffffffeca8, rbp = 0 --- I've only seen this once. If I should encounter it again, is there something you'd like me to look at? Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat May 23 11:40:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E677E1065672; Sat, 23 May 2009 11:40: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 BDC9C8FC12; Sat, 23 May 2009 11:40: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 ESMTPS id 7597E46B4C; Sat, 23 May 2009 07:40:29 -0400 (EDT) Date: Sat, 23 May 2009 12:40:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stefan Bethke In-Reply-To: <226F1AFF-45D8-4E4C-BE7F-D2EDC35EC8F6@lassitu.de> Message-ID: References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> <226F1AFF-45D8-4E4C-BE7F-D2EDC35EC8F6@lassitu.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , "Bjoern A. Zeeb" , FreeBSD Current Subject: Re: spinlock held too long on reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 11:40:30 -0000 On Sat, 23 May 2009, Stefan Bethke wrote: > I've only seen this once. If I should encounter it again, is there > something you'd like me to look at? I've now seen this twice, both times on SMP VMWare installations. I theorized that perhaps it was because one of the virtual CPUs wasn't time sliced for over our spinlock wait threshold due to load in the host OS, but if it's also being seen on real hardware it's presumably not that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat May 23 12:39:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9DE106564A for ; Sat, 23 May 2009 12:39:30 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by mx1.freebsd.org (Postfix) with ESMTP id C6C468FC12 for ; Sat, 23 May 2009 12:39:29 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from libero.it (192.168.17.6) by cp-out3.libero.it (8.5.107) id 4A1119550057CB57; Sat, 23 May 2009 14:39:28 +0200 Date: Sat, 23 May 2009 14:39:28 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "freebsd-current" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 79.18.239.252 X-Mailman-Approved-At: Sat, 23 May 2009 12:55:08 +0000 Cc: rwatson , stb Subject: spinlock held too long on reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 12:39:30 -0000 I don't know if it's related, but I've seen something similar about 3 tim= es on 7-STABLE. On real hardware. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/134584 From owner-freebsd-current@FreeBSD.ORG Sat May 23 12:57:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE5B1065673; Sat, 23 May 2009 12:57:01 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3778FC1D; Sat, 23 May 2009 12:57:01 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: by pzk3 with SMTP id 3so2033079pzk.3 for ; Sat, 23 May 2009 05:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:to:cc :subject:from:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=WJS+z0le3uTjq3o5+NT5BZwS8vs0wTmf4PfKsXAYRyw=; b=qaGj78oMU7ZK56D3MInmmNFWvBUimIxnJyGcGDM+IAsltl4s+T+Qe3FW/5z9cqyAo9 N+cXH0ccFtBiRtK0X6sOKaqwKAUKd6lBaNy/jmKorcqrKS/YhsjonNDQv58NZ+T2sdxH 9bedSt07z71/BfcBHxH9SpMCcOQ9HdzE2jXYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:to:cc:subject:from:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=v+XlG6GM5V3VUfmRfDpo+1tZGakrKkQOQvVOLNFLgk20m/wg5iIjL7yhGuszRpMq3r wU8LlyEzj3g18LTF6iezLfim3nQCII2UmtYjb4lUVmKUhuImx2rdzzJCvkEvQuSBDJCA 2Ysr8Pa/1pUrcgTkrx0sbfIWl5oFu4KCw/Lfc= Received: by 10.142.185.21 with SMTP id i21mr1598582wff.220.1243082100960; Sat, 23 May 2009 05:35:00 -0700 (PDT) Received: from localhost (rikad42.riken.jp [134.160.214.42]) by mx.google.com with ESMTPS id 28sm10096595wfd.3.2009.05.23.05.34.58 (version=SSLv3 cipher=RC4-MD5); Sat, 23 May 2009 05:34:59 -0700 (PDT) Sender: Maho NAKATA Date: Sat, 23 May 2009 21:32:52 +0900 (JST) Message-Id: <20090523.213252.193744936.chat95@mac.com> To: miwi@FreeBSD.org From: Maho NAKATA In-Reply-To: <20090522202635.GC33004@bsdcrew.de> References: <20090522202102.GB33004@bsdcrew.de> <4A1709EA.2000207@entel.upc.edu> <20090522202635.GC33004@bsdcrew.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_May_23_21_32_52_2009_908)--" Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-emulation@FreeBSD.org, gperez@entel.upc.edu Subject: Adding Guestadditions.iso Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 12:57:02 -0000 ----Security_Multipart(Sat_May_23_21_32_52_2009_908)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi miwi, Here is a patch adding "WITH_GUESTADDITIONS" knob. With this knob we also installs Guest additions.iso. This driver makes Windows XP, Linux and Solaris faster. I'm a newbie to VirtualBox so it is not the correct patch. I don't check it thoroughly but ISO image itself is not a GPL one. Best, --- Makefile 2009-05-23 01:59:37.000000000 +0900 +++ Makefile 2009-05-23 21:14:52.000000000 +0900 @@ -6,16 +6,26 @@ # PORTNAME= virtualbox -PORTVERSION= 2.2.2r19852 +PORTVERSION= ${VBOXVER}r19852 CATEGORIES= emulators kld MASTER_SITES= http://tmp.chruetertee.ch/ \ http://freebsd.unixfreunde.de/sources/ \ http://disasterarea.chruetertee.ch/ \ http://mirror.4bit.ws/ +.if defined(WITH_GUESTADDITIONS) +MASTER_SITES+= http://dlc.sun.com/virtualbox/${VBOXVER}/:guestadditons +DISTFILES= ${DISTNAME}${EXTRACT_SUFX} ${GUESTADDITIONS}:guestaddtions +EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} +.endif MAINTAINER= decke@bluelife.at COMMENT= A general-purpose full virtualizer for x86 hardware +VBOXVER= 2.2.2 +FETCH_ARGS= -pRr +GUESTADDITIONS_GENERICNAME= VBoxGuestAdditions.iso +GUESTADDITIONS= VBoxGuestAdditions_${VBOXVER}.iso + BUILD_DEPENDS= yasm:${PORTSDIR}/devel/yasm \ as86:${PORTSDIR}/devel/dev86 \ xsltproc:${PORTSDIR}/textproc/libxslt \ @@ -52,6 +62,9 @@ KMODDIR= /boot/modules PLIST_SUB+= KMODDIR=${KMODDIR} +.if defined(WITH_GUESTADDITIONS) +PLIST_FILES+= lib/virtualbox/${GUESTADDITIONS} lib/virtualbox/${GUESTADDITIONS_GENERICNAME} +.endif KMK_CONFIG= VBOX_LIBPATH_X11=${LOCALBASE} @@ -127,7 +140,10 @@ ${MKDIR} ${PREFIX}/lib/virtualbox (cd ${WRKSRC}/out/${KMK_ARCH}/release/bin && ${COPYTREE_SHARE} "*.so *.gc *.r0 components" ${PREFIX}/lib/virtualbox) - +.if defined(WITH_GUESTADDITIONS) + ${INSTALL_DATA} ${DISTDIR}/${GUESTADDITIONS} ${PREFIX}/lib/virtualbox/ + ${LN} -sf ${PREFIX}/lib/virtualbox/${GUESTADDITIONS} ${PREFIX}/lib/virtualbox/${GUESTADDITIONS_GENERICNAME} +.endif ${MKDIR} ${PREFIX}/bin .for f in VBoxBFE VBoxHeadless VBoxManage VBoxNetDHCP VBoxSDL VBoxSVC VBoxXPCOMIPCD VirtualBox ${INSTALL_PROGRAM} ${WRKSRC}/out/${KMK_ARCH}/release/bin/$f ${PREFIX}/lib/virtualbox/ --- distinfo 2009-05-23 01:59:37.000000000 +0900 +++ distinfo 2009-05-23 20:17:28.000000000 +0900 @@ -1,3 +1,6 @@ MD5 (virtualbox-2.2.2r19852.tar.gz) = ff1e05bd04fd7974a90e12394cb58626 SHA256 (virtualbox-2.2.2r19852.tar.gz) = 7b898c643551f5b74d169a79ad41801cc5675b5e57a7da0f700875dd11265a5f SIZE (virtualbox-2.2.2r19852.tar.gz) = 58070688 +MD5 (VBoxGuestAdditions_2.2.2.iso) = 9c09a9e88abe9edd8fec6fd3cf453535 +SHA256 (VBoxGuestAdditions_2.2.2.iso) = 3727c024d8d426443158b1063a9d7355d492da3725470c4c01fafbe4bc382687 +SIZE (VBoxGuestAdditions_2.2.2.iso) = 28755968 ----Security_Multipart(Sat_May_23_21_32_52_2009_908)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoX7PYACgkQpcQqaPiEzfkSlwCeJExFJmCKaGXex7VvW63KZx3L hisAnRmu4/U9VBTStn9rfakEK1yq2Uqi =/U2l -----END PGP SIGNATURE----- ----Security_Multipart(Sat_May_23_21_32_52_2009_908)---- From owner-freebsd-current@FreeBSD.ORG Sat May 23 13:04:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7441E10656D3 for ; Sat, 23 May 2009 13:04:37 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.154]) by mx1.freebsd.org (Postfix) with ESMTP id 036078FC16 for ; Sat, 23 May 2009 13:04:36 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from 6nq.u-strasbg.fr (mojito.u-strasbg.fr [IPv6:2001:660:2402:1001::202]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n4ND3KVi063708 for ; Sat, 23 May 2009 15:03:20 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id DC9BDA317; Sat, 23 May 2009 14:54:09 +0200 (CEST) Date: Sat, 23 May 2009 14:54:09 +0200 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20090523125409.GC12903@unistra.fr> References: <20090514191237.GD70242@bsdcrew.de> <20090517180920.GY71804@bsdcrew.de> <20090519091310.GB71804@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20090519091310.GB71804@bsdcrew.de> Organization: Direction Informatique, =?iso-8859-15?Q?Un?= =?iso-8859-15?Q?iversit=E9?= de Strasbourg, France x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.19 (2009-01-05) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::154]); Sat, 23 May 2009 15:03:20 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9383/Fri May 22 17:58:11 2009 on mr4.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=-100.0 required=5.0 tests=NO_RELAYS, USER_IN_WHITELIST autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr4.u-strasbg.fr Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 13:04:38 -0000 Martin Wilke (miwi@freebsd.org) on 19/05/2009 at 11:13 wrote: > We updated the port to 2.2.2r19801. FreeBSD 8.0-CURRENT #12: Wed May 13 11:22:30 CEST 2009 amd64 + virtualbox-2.2.2r19852 works like a charm. I only had to disable the VT/AMD option from the setting as already pointed in this list. Thank you for your work! -- bug From owner-freebsd-current@FreeBSD.ORG Sat May 23 17:21:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A116D106564A for ; Sat, 23 May 2009 17:21:26 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 035CC8FC15 for ; Sat, 23 May 2009 17:21:25 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: by bwz9 with SMTP id 9so2316236bwz.43 for ; Sat, 23 May 2009 10:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=B/85XW5d+i0VoUTUZXIZO7qqAfXHIFDEP/3KVJ2I0kU=; b=BA2uzSALmaYo1V72kt6rVljOV1sReQpMt+92SGUU+lrANfU6k5GQ8BuNQh0KzGvlSR USbtaUxT2AzQqOheiezUrFmiHYJCoyRxWmXJNHMMo+xRQysWif0OUXIScttCZdJ7LtuJ V4IOaSkr9tP9PJ1cKJtIlgBZGhXz4CRUI7Ylk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=TI8TcggbpJTF/RZ6WRhUny8q8H0voOsDiUJmccd4UL9/sw+Z9iQ74onLQE6zNU4lC7 EM0O256wraC7IxkTctgru/ocwlqzO+j2SaI5KW7IFn9wsCyRoLWe6ccB4HfQ43AIHMST RdOHqiqI2krkN4Jo0BLZv7yTchZ5T9vJEfIzk= MIME-Version: 1.0 Sender: clkroot@gmail.com Received: by 10.204.70.135 with SMTP id d7mr4893249bkj.87.1243097882230; Sat, 23 May 2009 09:58:02 -0700 (PDT) Date: Sat, 23 May 2009 12:58:02 -0400 X-Google-Sender-Auth: 6d62cc502ad7a2fa Message-ID: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> From: Nicolas Blais To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 17:21:26 -0000 I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I get the following message at boot: syslogd: bind: Can't assign requested address syslogd: bind: Can't assign requested address syslogd: child pid 250 exited with return code 1 and syslogd obviously fails to start. Apparently this problem has been reported before, but no actual solution other than start syslogd from rc.local was given. Here's my rcorder /etc/rc.d/* if it helps: /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/early.sh /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/hostid /etc/rc.d/mdconfig /etc/rc.d/mountcritlocal /etc/rc.d/zfs /etc/rc.d/FILESYSTEMS /etc/rc.d/var /etc/rc.d/cleanvar /etc/rc.d/random /etc/rc.d/adjkerntz /etc/rc.d/atm1 /etc/rc.d/hostname /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/kldxref /etc/rc.d/sppp /etc/rc.d/addswap /etc/rc.d/auto_linklocal /etc/rc.d/sysctl /etc/rc.d/serial /etc/rc.d/netif /etc/rc.d/ip6addrctl /etc/rc.d/atm2 /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ip6fw /etc/rc.d/network_ipv6 /etc/rc.d/devd /etc/rc.d/ipsec /etc/rc.d/ipfw /etc/rc.d/nsswitch /etc/rc.d/resolv /etc/rc.d/mroute6d /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/defaultroute /etc/rc.d/netoptions /etc/rc.d/NETWORKING /etc/rc.d/mountcritremote /etc/rc.d/devfs /etc/rc.d/ipmon /etc/rc.d/mdconfig2 /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/savecore /etc/rc.d/ldconfig /etc/rc.d/archdep /etc/rc.d/abi /etc/rc.d/SERVERS /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/rpcbind /etc/rc.d/nisdomain /etc/rc.d/ypserv /etc/rc.d/ypxfrd /etc/rc.d/ypupdated /etc/rc.d/ypbind /etc/rc.d/ypset /etc/rc.d/yppasswdd /etc/rc.d/wpa_supplicant /etc/rc.d/accounting /etc/rc.d/nfsclient /etc/rc.d/amd /etc/rc.d/atm3 /etc/rc.d/auditd /etc/rc.d/tmp /etc/rc.d/cleartmp /etc/rc.d/dmesg /etc/rc.d/ipxrouted /etc/rc.d/kerberos /etc/rc.d/kadmind /etc/rc.d/keyserv /etc/rc.d/kpasswdd /etc/rc.d/gssd /etc/rc.d/quota /etc/rc.d/nfsserver /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/statd /etc/rc.d/lockd /etc/rc.d/pppoed /etc/rc.d/pwcheck /etc/rc.d/virecover /etc/rc.d/DAEMON /etc/rc.d/watchdogd /etc/rc.d/ugidfw /etc/rc.d/timed /etc/rc.d/apm /etc/rc.d/apmd /etc/rc.d/bootparams /etc/rc.d/hcsecd /etc/rc.d/bthidd /etc/rc.d/local /etc/rc.d/lpd /etc/rc.d/motd /etc/rc.d/mountlate /etc/rc.d/nscd /etc/rc.d/ntpd /etc/rc.d/powerd /etc/rc.d/rarpd /etc/rc.d/sdpd /etc/rc.d/rfcomm_pppd_server /etc/rc.d/rtadvd /etc/rc.d/rwho /etc/rc.d/LOGIN /etc/rc.d/syscons /etc/rc.d/sshd /etc/rc.d/sendmail /etc/rc.d/cron /etc/rc.d/jail /etc/rc.d/localpkg /etc/rc.d/securelevel /etc/rc.d/power_profile /etc/rc.d/othermta /etc/rc.d/natd /etc/rc.d/msgs /etc/rc.d/moused /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/idmapd /etc/rc.d/hostapd /etc/rc.d/geli2 /etc/rc.d/ftpd /etc/rc.d/ftp-proxy /etc/rc.d/dhclient /etc/rc.d/bsnmpd /etc/rc.d/bridge /etc/rc.d/bluetooth /etc/rc.d/bgfsck Although it would seem syslogd should start after network_ipv6, it is not actually the case during the boot. I'll be glad to test any suggestions, Nicolas. From owner-freebsd-current@FreeBSD.ORG Sat May 23 17:11:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679751065673; Sat, 23 May 2009 17:11:21 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail.itac.at (mail.itac.at [213.47.211.116]) by mx1.freebsd.org (Postfix) with ESMTP id 18EE28FC1A; Sat, 23 May 2009 17:11:20 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from localhost ([127.0.0.1] helo=webmail.itac.at) by mail.itac.at with esmtpa (Exim 4.63) (envelope-from ) id 1M7uke-0001IX-0v; Sat, 23 May 2009 19:11:16 +0200 Received: from 78.142.74.81 (SquirrelMail authenticated user decke@bluelife.at) by webmail.itac.at with HTTP; Sat, 23 May 2009 19:11:16 +0200 (CEST) Message-ID: <8cecb22a6543c2983d85131c931cd9f5.squirrel@webmail.itac.at> In-Reply-To: <20090523.213252.193744936.chat95@mac.com> References: <20090522202102.GB33004@bsdcrew.de> <4A1709EA.2000207@entel.upc.edu> <20090522202635.GC33004@bsdcrew.de> <20090523.213252.193744936.chat95@mac.com> Date: Sat, 23 May 2009 19:11:16 +0200 (CEST) From: Bernhard =?iso-8859-1?Q?Fr=F6hlich?= To: "Maho NAKATA" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sat, 23 May 2009 17:26:44 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, gperez@entel.upc.edu, miwi@freebsd.org Subject: Re: Adding Guestadditions.iso Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 17:11:22 -0000 On Sat, May 23, 2009 2:32 pm, Maho NAKATA wrote: > Hi miwi, > > Here is a patch adding "WITH_GUESTADDITIONS" knob. > With this knob we also installs > Guest additions.iso. This driver makes Windows XP, Linux and Solaris > faster. > I'm a newbie to VirtualBox so it is not the correct patch. > I don't check it thoroughly but ISO image itself is not a GPL one. Thanks, it's commited with a few modifications. -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Sat May 23 18:51:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB373106566B for ; Sat, 23 May 2009 18:51:04 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3838FC08 for ; Sat, 23 May 2009 18:51:04 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:811f:127:3e4c:b207] (unknown [IPv6:2001:7b8:3a7:0:811f:127:3e4c:b207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BB61C5C43; Sat, 23 May 2009 20:51:03 +0200 (CEST) Message-ID: <4A184596.8040205@andric.com> Date: Sat, 23 May 2009 20:51:02 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090520 Shredder/3.0b3pre MIME-Version: 1.0 To: Nicolas Blais References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> In-Reply-To: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 18:51:05 -0000 On 2009-05-23 18:58, Nicolas Blais wrote: > I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I > get the following message at boot: > > syslogd: bind: Can't assign requested address > syslogd: bind: Can't assign requested address I have not seen any problems with either -STABLE or -CURRENT using IPv6 and syslogd. Can you please post the IPv6-related setting(s) from your /etc/rc.conf? From owner-freebsd-current@FreeBSD.ORG Sat May 23 19:00:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48492106564A for ; Sat, 23 May 2009 19:00:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 313688FC16 for ; Sat, 23 May 2009 19:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 27DA641C757; Sat, 23 May 2009 21:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ygkSIihWN-+7; Sat, 23 May 2009 21:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BD9A441C75B; Sat, 23 May 2009 21:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 6D9E74448E6; Sat, 23 May 2009 18:59:04 +0000 (UTC) Date: Sat, 23 May 2009 18:59:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nicolas Blais In-Reply-To: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> Message-ID: <20090523185635.V72053@maildrop.int.zabbadoz.net> References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 19:00:15 -0000 On Sat, 23 May 2009, Nicolas Blais wrote: > I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I > get the following message at boot: ... > and syslogd obviously fails to start. Apparently this problem has been > reported before, but no actual solution other than start syslogd from > rc.local was given. It's theoretically the same issue with IPv6 + pf, etc. BUT (se further down) > Here's my rcorder /etc/rc.d/* if it helps: > ... > /etc/rc.d/netif > /etc/rc.d/ip6addrctl > /etc/rc.d/atm2 > /etc/rc.d/pfsync > /etc/rc.d/pflog > /etc/rc.d/pf > /etc/rc.d/ppp > /etc/rc.d/routing > /etc/rc.d/ip6fw > /etc/rc.d/network_ipv6 ^^^^^^ this needs to move up to around atm2. ... > /etc/rc.d/syslogd syslog comes later. > Although it would seem syslogd should start after network_ipv6, it is not > actually the case during the boot. So do you have console output from rc? Maybe turn on rc debugging and see what's going on? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat May 23 19:40:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED174106566B for ; Sat, 23 May 2009 19:40:16 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 7DAAC8FC08 for ; Sat, 23 May 2009 19:40:16 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: by fxm12 with SMTP id 12so2395721fxm.43 for ; Sat, 23 May 2009 12:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=qABYEOq58dD6JFm8CHr8Mm2fF2FXjU5uqr966VbrUCs=; b=BzA/VSEX8uqSANc8Tm88G0K99kPRYq2+hg1umFZ0AayEXvVQqJby3xVTugcfdN/oeB Mldv39ddWOuVE7CJ71iaRzwZAErHIA9AHPHDKN3aiOPsoWRXEDkff1fWM10Z04KjC0HV i0f0a4grP0Xut5069gPaDiAIiBpsCKmIXQibI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wDzqYCReMw4+f6DCr7IAupV9d3DMqKzm1hkgY18sX5BnGiKd68YdaxOlhhNUQS4SYf HN0lt9RbCcphHncIKDdgCbmuMaBGfyQAi4E9CLESz+dRtU3U6P6mT/crxNBfEJ+aJNSE ZdKUzk7r6AxzKNYF8g3WkqUEFRN0gSJiqAFPU= MIME-Version: 1.0 Sender: clkroot@gmail.com Received: by 10.204.68.130 with SMTP id v2mr1015107bki.131.1243107615482; Sat, 23 May 2009 12:40:15 -0700 (PDT) In-Reply-To: <4A184596.8040205@andric.com> References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> <4A184596.8040205@andric.com> Date: Sat, 23 May 2009 15:40:15 -0400 X-Google-Sender-Auth: 3c09435401cbc5fe Message-ID: <7061d9f50905231240n33f562efpcd3a0ebfb950f167@mail.gmail.com> From: Nicolas Blais To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 19:40:17 -0000 On Sat, May 23, 2009 at 2:51 PM, Dimitry Andric wrote: > On 2009-05-23 18:58, Nicolas Blais wrote: > > I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I > > get the following message at boot: > > > > syslogd: bind: Can't assign requested address > > syslogd: bind: Can't assign requested address > > I have not seen any problems with either -STABLE or -CURRENT using IPv6 > and syslogd. Can you please post the IPv6-related setting(s) from your > /etc/rc.conf? > Certainly: ipv6_enable="YES" ipv6_gateway_enable="YES" rtadvd_enable="YES" rtadvd_interfaces="em0" hostname="daemon" ifconfig_em0="DHCP" freenet6_enable="NO" I get my ipv6 address from freenet6 once the tunnel is established. Nicolas. From owner-freebsd-current@FreeBSD.ORG Sat May 23 19:44:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B630106566B for ; Sat, 23 May 2009 19:44:41 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 9B38E8FC1C for ; Sat, 23 May 2009 19:44:40 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: by fxm12 with SMTP id 12so2397071fxm.43 for ; Sat, 23 May 2009 12:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=V4sLjWBknUL0AzmZxz84Wr/9DtDVgacuQhVwrRAd1yw=; b=sZ15+vlfnXFJbcciDpYLF6uSYBhhBt0Stf4OjN140NsMr4tJbvpgmd6W8j1pn9iK4E BUylRo+ql4X3It7Tz04GFuimlf0IBhknFVkheogwGRXfwf2cy1DOqztuMlRxD3t5xdgv /iTxothBy9OU071HnmHxa/r1aa1qPq45O6fac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XMAnWvrVKaFSW8TrOZ5y9xwcdGiMq0hqtWvob70J2jogMndkmNGp8yF7zA67WcIgjk X4R6BFCb/yDf7tOnxZxPxtQf5MhStnrFbM6ozZIJ9myFrho7bXyfCafVW10aD2Ht0Hjy EOJhztJ2VYKYzGC/e+Y0n/Q3Hc0PnGpTYF8JM= MIME-Version: 1.0 Sender: clkroot@gmail.com Received: by 10.204.64.67 with SMTP id d3mr5053657bki.142.1243107879540; Sat, 23 May 2009 12:44:39 -0700 (PDT) In-Reply-To: <7061d9f50905231240n33f562efpcd3a0ebfb950f167@mail.gmail.com> References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> <4A184596.8040205@andric.com> <7061d9f50905231240n33f562efpcd3a0ebfb950f167@mail.gmail.com> Date: Sat, 23 May 2009 15:44:39 -0400 X-Google-Sender-Auth: ea34a3385c6e8a7a Message-ID: <7061d9f50905231244g1399168an5f113f0d217e8e2a@mail.gmail.com> From: Nicolas Blais To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 19:44:41 -0000 > > >> I have not seen any problems with either -STABLE or -CURRENT using IPv6 >> and syslogd. Can you please post the IPv6-related setting(s) from your >> /etc/rc.conf? >> > > Certainly: > > ipv6_enable="YES" > ipv6_gateway_enable="YES" > rtadvd_enable="YES" > rtadvd_interfaces="em0" > hostname="daemon" > ifconfig_em0="DHCP" > freenet6_enable="NO" > > I get my ipv6 address from freenet6 once the tunnel is established. > > Nicolas. > Oh, forgot to mention before someone ask why freenet6_enable="NO". If I enable it, freenet6 will also start before the ipv4 network is up and hang forever, therefore I start it manually after everything is finished. Nicolas. From owner-freebsd-current@FreeBSD.ORG Sat May 23 19:57:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE441065743 for ; Sat, 23 May 2009 19:57:35 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 297FF8FC15 for ; Sat, 23 May 2009 19:57:34 +0000 (UTC) (envelope-from clkroot@gmail.com) Received: by bwz9 with SMTP id 9so2367843bwz.43 for ; Sat, 23 May 2009 12:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=5s7BUpCGOgSiGpuaMS4mmV/Feq5YUJjz5eLsCwm8vS4=; b=itvMG+ORfpWKKIrvhWseUVoxUa8FDqThKG5M5WDDyOgNl+p5udbWWi9D6gcauFvk35 Unr0Wmb42nWCwCYBZd5GwplJY82sDEA7iM2/7KLj+cm94bk/Yb3IEK8TIvoL1fJmN+ca yVcEj+qZappU+LJ0Q8FAF0Sg4H/ZMndclV81k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=mFTS04fz0LdZeYaC0tTudvjmTCpc8xtF6pZro6IVI2/fM3TXW2CIF/ZqnbWnQcCabM UBMxhsb/XCwiF24hVbgERXBtOzrdsHo031D2CuyiKi1OaPxQHQ5TvXVaT9MmKOufrm+Z nPdQktwvUi35w7dqUDpa2IVuvdaTT9IA0faq0= MIME-Version: 1.0 Sender: clkroot@gmail.com Received: by 10.204.112.205 with SMTP id x13mr5013537bkp.170.1243108653989; Sat, 23 May 2009 12:57:33 -0700 (PDT) In-Reply-To: <4A1853A7.8080606@digiware.nl> References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> <4A1853A7.8080606@digiware.nl> Date: Sat, 23 May 2009 15:57:33 -0400 X-Google-Sender-Auth: 236cbe21bb2558f5 Message-ID: <7061d9f50905231257n29d9e75ehb827ffdc9c077353@mail.gmail.com> From: Nicolas Blais To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 19:57:35 -0000 On Sat, May 23, 2009 at 3:51 PM, Willem Jan Withagen wrote: > Nicolas Blais wrote: > >> I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I >> get the following message at boot: >> >> syslogd: bind: Can't assign requested address >> syslogd: bind: Can't assign requested address >> syslogd: >> child pid 250 exited with return code 1 >> >> and syslogd obviously fails to start. Apparently this problem has been >> reported before, but no actual solution other than start syslogd from >> rc.local was given. >> > > It is not because net.inet6.ip6.v6only is off? > > Because than you otherwise get ip4 in ip6 mapping. > It should be of in recent releases, but in 5.x I remember it being on. > > --WjW > > Perhaps you are right, but that interface requires ip4 to connect to the tunnel broker and become ip6-capable. I don't understand why that sysctl should have an effect on the rcorder. I checked and net.inet6.ip6.v6only: 1 Here's my dmesg: /etc/rc: WARNING: failed to start syslogd Starting Network: lo0 em0. May 22 15:59:53 pflogd[620]: [priv]: msg PRIV_OPEN_LOG received pf enabled add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 -> 1 net.inet6.ip6.accept_rtadv: 0 -> 0 em0: flags=8843 metric 0 mtu 1500 options=19b inet6 fe80::221:9bff:fe34:a235%em0 prefixlen 64 scopeid 0x1 xl0: flags=8843 metric 0 mtu 1500 options=9 inet6 fe80::20a:5eff:fe20:c915%xl0 prefixlen 64 scopeid 0x2 plip0: flags=8851 metric 0 mtu 1500 pflog0: flags=141 metric 0 mtu 33152 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 pfsync0: flags=41 metric 0 mtu 1460 add net fe80::: gateway ::1 add net ff02::: gateway ::1 IPv4 mapped IPv6 address support=NO Configuring keyboard: keymap . DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 192.168.15.1 bound to 192.168.15.58 -- renewal in 1800 seconds. Nicolas From owner-freebsd-current@FreeBSD.ORG Sat May 23 20:28:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3E8B106564A for ; Sat, 23 May 2009 20:28:58 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id A3E758FC18 for ; Sat, 23 May 2009 20:28:58 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 0AF6D1710E; Sat, 23 May 2009 22:13:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kGZkFS8f7s1; Sat, 23 May 2009 22:13:02 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id EFD241710A; Sat, 23 May 2009 22:13:01 +0200 (CEST) Message-ID: <4A1858CE.8050803@withagen.nl> Date: Sat, 23 May 2009 22:13:02 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Blais References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> <4A1853A7.8080606@digiware.nl> <7061d9f50905231257n29d9e75ehb827ffdc9c077353@mail.gmail.com> In-Reply-To: <7061d9f50905231257n29d9e75ehb827ffdc9c077353@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 20:28:59 -0000 Nicolas Blais wrote: > On Sat, May 23, 2009 at 3:51 PM, Willem Jan Withagen wrote: > >> Nicolas Blais wrote: >> >>> I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I >>> get the following message at boot: >>> >>> syslogd: bind: Can't assign requested address >>> syslogd: bind: Can't assign requested address >>> syslogd: >>> child pid 250 exited with return code 1 >>> >>> and syslogd obviously fails to start. Apparently this problem has been >>> reported before, but no actual solution other than start syslogd from >>> rc.local was given. >>> >> It is not because net.inet6.ip6.v6only is off? >> >> Because than you otherwise get ip4 in ip6 mapping. >> It should be of in recent releases, but in 5.x I remember it being on. > Perhaps you are right, but that interface requires ip4 to connect to the > tunnel broker and become ip6-capable. I don't understand why that sysctl > should have an effect on the rcorder. I checked and net.inet6.ip6.v6only: 1 > > Here's my dmesg: > > /etc/rc: WARNING: failed to start syslogd > Starting Network: lo0 em0. > May 22 15:59:53 pflogd[620]: [priv]: msg PRIV_OPEN_LOG received > pf enabled .... > IPv4 mapped IPv6 address support=NO Well that should not be the case given what you have. You could use lsof to see what has the socket open already. Or start syslog with strace and see where it fails. Or first check when booting without firewall --WjW From owner-freebsd-current@FreeBSD.ORG Sat May 23 20:08:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A898106564A for ; Sat, 23 May 2009 20:08:59 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAD38FC12 for ; Sat, 23 May 2009 20:08:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id A90A71767A; Sat, 23 May 2009 21:51:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EwhmvuOxOr0; Sat, 23 May 2009 21:51:03 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id 2D59D17669; Sat, 23 May 2009 21:51:03 +0200 (CEST) Message-ID: <4A1853A7.8080606@digiware.nl> Date: Sat, 23 May 2009 21:51:03 +0200 From: Willem Jan Withagen Organization: Digiware Management User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Blais References: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> In-Reply-To: <7061d9f50905230958n5fd7d434t790a964e79511d6b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 May 2009 21:02:59 +0000 Cc: freebsd-current@freebsd.org Subject: Re: syslogd starting before IPv6 network is up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 20:08:59 -0000 Nicolas Blais wrote: > I migrated one of my 8-CURRENT (Thu May 21) box to IPv6 and since then, I > get the following message at boot: > > syslogd: bind: Can't assign requested address > syslogd: bind: Can't assign requested address > syslogd: > child pid 250 exited with return code 1 > > and syslogd obviously fails to start. Apparently this problem has been > reported before, but no actual solution other than start syslogd from > rc.local was given. It is not because net.inet6.ip6.v6only is off? Because than you otherwise get ip4 in ip6 mapping. It should be of in recent releases, but in 5.x I remember it being on. --WjW From owner-freebsd-current@FreeBSD.ORG Sat May 23 21:43:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15E32106567C for ; Sat, 23 May 2009 21:43:57 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id C45068FC0C for ; Sat, 23 May 2009 21:43:56 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so1459496ywe.13 for ; Sat, 23 May 2009 14:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=93HhCZT3Loe+QBuO20BAmkxQEPe8hx8dmmJ8eKjRftI=; b=hJptnKWYc5rD0D88zO6/xCqHvahxg0a7WQc6PwIsjitrev8g4cTuwCbZcCTH3StpmX kbrecbIUkajbAJjJ/IWrWnusIFixZ0qop679HXh/iHlcqltKkKWkcdeoknI9W6fD6XzZ muRpPmUth316uwhD6mMPvJYXBYpkw8PPsb8dg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=pMVP9kIyf4sjXdA0WkS/JzoaZ5MnKpSJSUJV8komWODHAWBPG9+jY1Id2hX0DzLScr TRJSFV+Mrqa9mBp9bBqWxBBVlSYlqQnH8KnK2d5ZIpBZPZq/dmdpQwWrUrepFOJh23H+ Vw2RKFvns9KUx2h0WrQTEC/qYejpy0VclzDwA= MIME-Version: 1.0 Received: by 10.150.136.15 with SMTP id j15mr10635864ybd.265.1243115036285; Sat, 23 May 2009 14:43:56 -0700 (PDT) In-Reply-To: <4A11A08B.6090309@errno.com> References: <4A11A08B.6090309@errno.com> Date: Sat, 23 May 2009 23:43:56 +0200 Message-ID: <90a5caac0905231443l6d275f79t8e8024268aca2bbb@mail.gmail.com> From: Lucius Windschuh To: Sam Leffler , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 21:43:57 -0000 2009/5/18 Sam Leffler : > I plan to commit these changes by the end of the week. Hi Sam. Since updating from r192372 to r192667, ending "tcpdump -ni uath0" with ^C results in this witness warning: taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex bpf global lock (bpf global lock) r = 0 (0xc0bdafd8) locked @ /usr/src/sys/net/bpf.c:605 KDB: stack backtrace: db_trace_self_wrapper(c09bbd1c,eb107a24,c06da925,c09c6d24,25d,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09c6d24,25d,ffffffff,c0baabcc,eb107a5c,...) at kdb_backtrace+0x29 _witness_debugger(c09be0ad,eb107a70,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0967968,137,c712ec1c,...) at witness_warn+0x1fd taskqueue_drain(c712ec00,c72400b8,c7240000,eb107ad0,c0773f49,...) at taskqueue_drain+0xa9 ieee80211_waitfor_parent(c7240000,0,c09cc970,caf,c7240014,...) at ieee80211_waitfor_parent+0x7b ieee80211_ioctl(c64ac400,80206910,eb107af0,eb107b20,8903,...) at ieee80211_ioctl+0x1a9 if_setflag(c64ac44c,0,c09b71f8,ca,0,...) at if_setflag+0x10a ifpromisc(c64ac400,0,c09c6d24,236,c615ad4c,...) at ifpromisc+0x33 bpf_detachd(c0bdafd8,0,c09c6d24,25d,c6863400,...) at bpf_detachd+0x242 bpf_dtor(c6f4ba00,0,c09ab531,9f,c771a578,...) at bpf_dtor+0xb0 devfs_destroy_cdevpriv(c6863400,0,c09ab531,a9,eb107be8,...) at devfs_destroy_cdevpriv+0xac devfs_fpdrop(c771a578,c77356c0,3,0,c771a578,...) at devfs_fpdrop+0x68 _fdrop(c771a578,c77356c0,eb107c1c,c06da76c,0,c7735764,c0baabc8,c0a26b14,c09b3b14,c6f0972c,45b,c09b3b14,eb107c44,c06a2c90,c6f0972c,8,c09b3b14,45b) at _fdrop+0x53 closef(c771a578,c77356c0,45b,440,c771a578,...) at closef+0x290 kern_close(c77356c0,3,eb107d2c,c09285d3,c77356c0,...) at kern_close+0x102 close(c77356c0,eb107cf8,4,c09b53e8,c0a1ec10,...) at close+0x1a syscall(eb107d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2838f9b3, esp = 0xbfbfe54c, ebp = 0xbfbfe568 -- Well, I have no perfect evidence that your changes caused this behaviour, but since it happens only on 802.11 interfaces and not in my previous CURRENT, this looks like fallout from your monitor works. Lucius From owner-freebsd-current@FreeBSD.ORG Sat May 23 22:13:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87461065674; Sat, 23 May 2009 22:13:45 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8815C8FC12; Sat, 23 May 2009 22:13:45 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so747634wfg.7 for ; Sat, 23 May 2009 15:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:to:cc :subject:from:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=4L9nzgp81dH1FgovJe78v+nidcSDOuNiNrGxQ7xbYEY=; b=mPBApMQ4D5/PNSHI0LxKs+LXFjARhSEdq38M8nOKY3b9Jpg84r7xp8EVBfNY1ZSt39 imU2e2eSw6i5h7aND59DnlMmtVBwe2fJMtMT0z35MQe8OWq0Ss7zfbAltvdGCqJzXuSk s8WdfGH5XzPZtJfRzn8YQTKvHjhaI3srASjfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:to:cc:subject:from:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=CXtEd32ecxOl8ZFqaVLJFxcw7CaBZkK2vbQwp2KLw/jdbm4w2W5vpLoMuRloteE4mq xbEp4h0xKI3nY2vFA8VgENx/Z+U214wa+Tkr00mDemb7DPEzhyLLRBPmnD6GdT9RlAZM sTTUXGRs7Azg2xAoIdi2QXFhGAvB178mv71Ow= Received: by 10.142.135.16 with SMTP id i16mr1989624wfd.335.1243116825280; Sat, 23 May 2009 15:13:45 -0700 (PDT) Received: from localhost (rikad42.riken.jp [134.160.214.42]) by mx.google.com with ESMTPS id 30sm3889471wfc.18.2009.05.23.15.13.42 (version=SSLv3 cipher=RC4-MD5); Sat, 23 May 2009 15:13:44 -0700 (PDT) Sender: Maho NAKATA Date: Sun, 24 May 2009 07:11:43 +0900 (JST) Message-Id: <20090524.071143.179888312.chat95@mac.com> To: decke@bluelife.at From: Maho NAKATA In-Reply-To: <8cecb22a6543c2983d85131c931cd9f5.squirrel@webmail.itac.at> References: <20090522202635.GC33004@bsdcrew.de> <20090523.213252.193744936.chat95@mac.com> <8cecb22a6543c2983d85131c931cd9f5.squirrel@webmail.itac.at> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_May_24_07_11_43_2009_600)--" Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, gperez@entel.upc.edu, miwi@freebsd.org Subject: Re: Adding Guestadditions.iso Re: [Call For Testing] VirtualBox for FreeBSD! take 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 22:13:46 -0000 ----Security_Multipart(Sun_May_24_07_11_43_2009_600)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: Bernhard Fr=F6hlich Subject: Re: Adding Guestadditions.iso Re: [Call For Testing] VirtualBo= x for FreeBSD! take 3 Date: Sat, 23 May 2009 19:11:16 +0200 (CEST) > On Sat, May 23, 2009 2:32 pm, Maho NAKATA wrote: >> Hi miwi, >> >> Here is a patch adding "WITH_GUESTADDITIONS" knob. >> With this knob we also installs >> Guest additions.iso. This driver makes Windows XP, Linux and Solaris= >> faster. >> I'm a newbie to VirtualBox so it is not the correct patch. >> I don't check it thoroughly but ISO image itself is not a GPL one. > = > Thanks, it's commited with a few modifications. You're welcome! -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ = Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.tx= t ----Security_Multipart(Sun_May_24_07_11_43_2009_600)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoYdKAACgkQpcQqaPiEzflKMwCgk1WiImZ52yGU8ybAz3xKyPbJ DggAoJdoKe/tveuGalJESLLWjmD+IgGk =n5Gx -----END PGP SIGNATURE----- ----Security_Multipart(Sun_May_24_07_11_43_2009_600)---- From owner-freebsd-current@FreeBSD.ORG Sat May 23 22:47:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AAEB106564A for ; Sat, 23 May 2009 22:47:01 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2F98FC1A for ; Sat, 23 May 2009 22:47:00 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4NMIoRX084052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 15:18:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A18764A.3000806@errno.com> Date: Sat, 23 May 2009 15:18:50 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Lucius Windschuh References: <4A11A08B.6090309@errno.com> <90a5caac0905231443l6d275f79t8e8024268aca2bbb@mail.gmail.com> In-Reply-To: <90a5caac0905231443l6d275f79t8e8024268aca2bbb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 22:47:01 -0000 Lucius Windschuh wrote: > 2009/5/18 Sam Leffler : > >> I plan to commit these changes by the end of the week. >> > > Hi Sam. > Since updating from r192372 to r192667, ending "tcpdump -ni uath0" > with ^C results in this witness warning: > > taskqueue_drain with the following non-sleepable locks held: > exclusive sleep mutex bpf global lock (bpf global lock) r = 0 > (0xc0bdafd8) locked @ /usr/src/sys/net/bpf.c:605 > KDB: stack backtrace: > db_trace_self_wrapper(c09bbd1c,eb107a24,c06da925,c09c6d24,25d,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c09c6d24,25d,ffffffff,c0baabcc,eb107a5c,...) at kdb_backtrace+0x29 > _witness_debugger(c09be0ad,eb107a70,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0967968,137,c712ec1c,...) at witness_warn+0x1fd > taskqueue_drain(c712ec00,c72400b8,c7240000,eb107ad0,c0773f49,...) at > taskqueue_drain+0xa9 > ieee80211_waitfor_parent(c7240000,0,c09cc970,caf,c7240014,...) at > ieee80211_waitfor_parent+0x7b > ieee80211_ioctl(c64ac400,80206910,eb107af0,eb107b20,8903,...) at > ieee80211_ioctl+0x1a9 > if_setflag(c64ac44c,0,c09b71f8,ca,0,...) at if_setflag+0x10a > ifpromisc(c64ac400,0,c09c6d24,236,c615ad4c,...) at ifpromisc+0x33 > bpf_detachd(c0bdafd8,0,c09c6d24,25d,c6863400,...) at bpf_detachd+0x242 > bpf_dtor(c6f4ba00,0,c09ab531,9f,c771a578,...) at bpf_dtor+0xb0 > devfs_destroy_cdevpriv(c6863400,0,c09ab531,a9,eb107be8,...) at > devfs_destroy_cdevpriv+0xac > devfs_fpdrop(c771a578,c77356c0,3,0,c771a578,...) at devfs_fpdrop+0x68 > _fdrop(c771a578,c77356c0,eb107c1c,c06da76c,0,c7735764,c0baabc8,c0a26b14,c09b3b14,c6f0972c,45b,c09b3b14,eb107c44,c06a2c90,c6f0972c,8,c09b3b14,45b) > at _fdrop+0x53 > closef(c771a578,c77356c0,45b,440,c771a578,...) at closef+0x290 > kern_close(c77356c0,3,eb107d2c,c09285d3,c77356c0,...) at kern_close+0x102 > close(c77356c0,eb107cf8,4,c09b53e8,c0a1ec10,...) at close+0x1a > syscall(eb107d38) at syscall+0x283 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x2838f9b3, esp = > 0xbfbfe54c, ebp = 0xbfbfe568 -- > > Well, I have no perfect evidence that your changes caused this > behaviour, but since it happens only on 802.11 interfaces and not in > my previous CURRENT, this looks like fallout from your monitor works. > It's been like that for a while. bpf holds a lock over the ifpromisc call which causes many issues. This is a problem that needs to be fixed in bpf. Sam