From owner-freebsd-current@FreeBSD.ORG Sun May 3 03:33: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 E2591106566B; Sun, 3 May 2009 03:33:26 +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 B87588FC13; Sun, 3 May 2009 03:33:26 +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 n433XO49012829; Sat, 2 May 2009 23:33:24 -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 n433XNp7030015; Sat, 2 May 2009 23:33:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BE8AE7302F; Sat, 2 May 2009 23:33:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090503033323.BE8AE7302F@freebsd-current.sentex.ca> Date: Sat, 2 May 2009 23:33:23 -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 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: Sun, 03 May 2009 03:33:27 -0000 TB --- 2009-05-03 01:54:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-03 01:54:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-03 01:54:21 - cleaning the object tree TB --- 2009-05-03 01:54:42 - cvsupping the source tree TB --- 2009-05-03 01:54:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-03 01:54:49 - building world TB --- 2009-05-03 01:54:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 01:54:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 01:54:49 - TARGET=pc98 TB --- 2009-05-03 01:54:49 - TARGET_ARCH=i386 TB --- 2009-05-03 01:54:49 - TZ=UTC TB --- 2009-05-03 01:54:49 - __MAKE_CONF=/dev/null TB --- 2009-05-03 01:54:49 - cd /src TB --- 2009-05-03 01:54:49 - /usr/bin/make -B buildworld >>> World build started on Sun May 3 01:54:51 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 Sun May 3 03:16:53 UTC 2009 TB --- 2009-05-03 03:16:53 - generating LINT kernel config TB --- 2009-05-03 03:16:53 - cd /src/sys/pc98/conf TB --- 2009-05-03 03:16:53 - /usr/bin/make -B LINT TB --- 2009-05-03 03:16:53 - building LINT kernel TB --- 2009-05-03 03:16:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 03:16:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 03:16:53 - TARGET=pc98 TB --- 2009-05-03 03:16:53 - TARGET_ARCH=i386 TB --- 2009-05-03 03:16:53 - TZ=UTC TB --- 2009-05-03 03:16:53 - __MAKE_CONF=/dev/null TB --- 2009-05-03 03:16:53 - cd /src TB --- 2009-05-03 03:16:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 3 03:16:53 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel mp_machdep.o(.text+0x94c): In function `ipi_bitmap_handler': : undefined reference to `profclockintr' mp_machdep.o(.text+0x95d): In function `ipi_bitmap_handler': : undefined reference to `statclockintr' mp_machdep.o(.text+0x96a): In function `ipi_bitmap_handler': : undefined reference to `hardclockintr' *** 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-03 03:33:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-03 03:33:23 - ERROR: failed to build lint kernel TB --- 2009-05-03 03:33:23 - 4703.70 user 448.91 system 5942.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 3 22:18: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 0B2E8106564A; Sun, 3 May 2009 22:18: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 BAE548FC17; Sun, 3 May 2009 22:18:23 +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 241853410; Mon, 04 May 2009 01:18:22 +0300 Message-ID: <49FE1826.4060000@FreeBSD.org> Date: Mon, 04 May 2009 01:18:14 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: FreeBSD-Current , freebsd-mobile@freebsd.org, FreeBSD acpi Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 May 2009 22:18:25 -0000 I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Modern systems, especially laptops, are implementing big number of power-saving technologies. Some of them are working automatically, other have significant requirements and need special system tuning or trade-offs to be effectively used. So here is the steps: 1. CPU CPU is the most consuming part of the system. Under the full load it alone may consume more then 40W of power, but for real laptop usage the most important is idle consumption. Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: P-states and throttling Enabling powerd allows to effectively control CPU frequency/voltage depending on CPU load. powerd on recent system can handle it quite transparently. By default, frequency controlled via mix of EIST and throttling technologies. First one controls both core frequency and voltage, second - only core frequency. Both technologies give positive power-saving effect. But effect of throttling is small and can be completely hidden by using C2 state, that's why I recommend to disable throttling control by adding to /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 In my case frequency/voltage control saves about 5W of idle power. C-states - C1 stops clock on some parts of CPU core during inactivity. It is safe, cheap and supported by CPUs for ages. System uses C1 state by default. - C2 state allows CPU to turn off all core clocks on idle. It is also cheap, but requires correct ACPI-chipset-CPU interoperation to be used. Use of C2 state can be enabled by adding to /etc/rc.conf: performance_cx_lowest="C2" economy_cx_lowest="C2" Effect from this state is not so big when powerd is used, but still noticeable, - C3 state allows CPU completely stop all internal clocks, reduce voltage and disconnect from system bus. This state gives additional power saving effect, but it is not cheap and require trade-offs. As soon as CPU is completely stopped in C3 state, local APIC timers in each CPU core, used by FreeBSD as event sources on SMP, are not functioning. It stops system time, breaks scheduling that makes system close to dead. The only solution for this problem is to use some external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to resurrect them for SMP systems. To use them, you can disable local APIC timers by adding to /boot/loader.conf: hint.apic.0.clock=0 Also, to drop/rise voltage on C3, CPU needs time (57us for my system). It means that C3 state can't be effectively used when system is waking up often. To increase inactivity periods we should reduce interrupt rate as much as possible by adding to loader.conf: kern.hz=100 It may increase system response time a bit, but it is not significant for laptop. Also we may avoid additional 128 interrupts per second per core, by the cost of scheduling precision, with using i8254 timer also for statistic collection purposes instead of RTC clock, by using another newly added option: hint.atrtc.0.clock=0 As result, system has only 100 interrupts per core and CPUs are using C3 with high efficiency: %sysctl dev.cpu |grep cx dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us Result of effective C3 state usage, comparing to C2+powerd, is about 2W. 2. PCI devices PCI bus provides method to control device power. For example, I have completely no use for my FireWire controller and most of time - EHCI USB controller. Disabling them allows me to save about 3W of power. To disable all unneeded PCI devices you should build kernel without their drivers and add to loader.conf: hw.pci.do_power_nodriver=3 To enable devices back all you need to do is just load their drivers as modules. 3. Radios WiFi and Bluetooth adapters can consume significant power when used (up to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling them with mechanical switch on laptop case saves energy even when they are not connected. 4. HDA modem I was surprised, but integrated HDA modem consumed about 1W of power even when not used. I have used the most radical solution - removed it mechanically from socket. Case surface in that area become much cooler. 5. HDA sound To reduce number of sound generated interrupts I have added to the loader.conf: hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 6. HDD First common recommendation is use tmpfs for temporary files. RAM is cheap, fast and anyway with you. Also you may try to setup automatic idle drive spin-down, but if it is the only system drive you should be careful, as every spin-up reduces drive's life time. For several months (until I have bought SATA SSD) I have successfully used SDHC card in built-in PCI sdhci card reader as main filesystem. On random read requests it is much faster then HDD, but it is very slow on random write. Same time it consumes almost nothing. USB drives could also be used, but effect is much less as EHCI USB controller consumes much power. Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing it completely saves 2W. 7. SATA Comparing to PATA, SATA interface uses differential signaling for data transfer. To work properly it has to transmit pseudo-random scrambled sequence even when idle. As you understand, that requires power. But SATA implements two power saving modes: PARTIAL and SLUMBER. These modes could be activated by either host or device if both sides support them. PARTIAL mode just stops scrambling, but keeps neutral link state, resume time is 50-100us. SLUMBER mode powers down interface completely, but respective resume time is 3-10ms. I have added minimal SATA power management to AHCI driver. There are hint.ata.X.pm_level loader tunables can be used to control it now. Setting it to 1 allows drive itself to initiate power saving, when it wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and SLUMBER transitions after every command completion. Note that SATA power saving is not compatible with drive hot-swap, as controller unable to detect drive presence when link is powered-down. In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. So what have I got? To monitor real system power consumption I am using information provided by ACPI battery via `acpiconf -i0` command: Original system: Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 93% Remaining time: 2:24 Present rate: 1621 mA Voltage: 12033 mV Tuned system: %acpiconf -i0 Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 94% Remaining time: 4:47 Present rate: 826 mA Voltage: 12231 mV So I have really doubled my on-battery time by this tuning - 4:47 hours instead of 2:24 with default settings. Preinstalled vendor-tuned Windows XP on the same system, provides maximum 3:20 hours. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun May 3 22:43: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 CB2141065670 for ; Sun, 3 May 2009 22:43:03 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 872BE8FC12 for ; Sun, 3 May 2009 22:43:03 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M0kOj-0001a5-Bd for freebsd-current@freebsd.org; Mon, 04 May 2009 02:43:01 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 7958EB84D for ; Mon, 4 May 2009 02:41:46 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id B6BE4108841; Mon, 4 May 2009 02:42:05 +0400 (MSD) Date: Mon, 4 May 2009 02:42:05 +0400 From: Dmitry Marakasov To: freebsd-current@freebsd.org Message-ID: <20090503224205.GB1414@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: geom_part X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 May 2009 22:43:04 -0000 Hi! I've upgraded one of my boxes to current recently and ran into some problems with new geom_part. First, it's impossible to edit bsd label online. # bsdlabel -e /dev/ad8 [edit] bsdlabel: Class not found re-edit the label? [y]: Setting sysctl kern.geom.debugflags to 16 helps. Next, it's no longer possible to use nested configuration. If I add bsd label to, say, /dev/ad8f, no subpartitions (ad8fa, ad8fd ...) will be shown. They pop up after loading geom_bsd. Finally, seems like bsd label support is broken: # bsdlabel /dev/ad8 # /dev/ad8: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 2048 16384 28528 b: 20971520 2097152 swap c: 390721968 0 unused 0 0 # "raw" part, don't edit d: 20971520 23068672 4.2BSD 2048 16384 28528 e: 2097152 44040192 4.2BSD 2048 16384 28528 f: 20971520 46137344 4.2BSD 2048 16384 28528 g: 41943040 67108864 unused 0 0 h: 281670064 109051904 unused 0 0 # ls /dev/ad8* /dev/ad8 /dev/ad8b /dev/ad8e /dev/ad8g /dev/ad8a /dev/ad8d /dev/ad8f No h partition! -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sun May 3 23:33: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 D1E271065670; Sun, 3 May 2009 23:33:06 +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 A5A338FC17; Sun, 3 May 2009 23:33:06 +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 n43NX4M2080934; Sun, 3 May 2009 19:33:04 -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 n43NX4MK095999; Sun, 3 May 2009 19:33:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 026677302F; Sun, 3 May 2009 19:33:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090503233304.026677302F@freebsd-current.sentex.ca> Date: Sun, 3 May 2009 19:33:03 -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 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: Sun, 03 May 2009 23:33:07 -0000 TB --- 2009-05-03 21:53:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-03 21:53:53 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-03 21:53:53 - cleaning the object tree TB --- 2009-05-03 21:54:25 - cvsupping the source tree TB --- 2009-05-03 21:54:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-03 21:54:34 - building world TB --- 2009-05-03 21:54:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 21:54:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 21:54:34 - TARGET=pc98 TB --- 2009-05-03 21:54:34 - TARGET_ARCH=i386 TB --- 2009-05-03 21:54:34 - TZ=UTC TB --- 2009-05-03 21:54:34 - __MAKE_CONF=/dev/null TB --- 2009-05-03 21:54:34 - cd /src TB --- 2009-05-03 21:54:34 - /usr/bin/make -B buildworld >>> World build started on Sun May 3 21:54:36 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 Sun May 3 23:16:33 UTC 2009 TB --- 2009-05-03 23:16:33 - generating LINT kernel config TB --- 2009-05-03 23:16:33 - cd /src/sys/pc98/conf TB --- 2009-05-03 23:16:33 - /usr/bin/make -B LINT TB --- 2009-05-03 23:16:33 - building LINT kernel TB --- 2009-05-03 23:16:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 23:16:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 23:16:33 - TARGET=pc98 TB --- 2009-05-03 23:16:33 - TARGET_ARCH=i386 TB --- 2009-05-03 23:16:33 - TZ=UTC TB --- 2009-05-03 23:16:33 - __MAKE_CONF=/dev/null TB --- 2009-05-03 23:16:33 - cd /src TB --- 2009-05-03 23:16:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 3 23:16:33 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x109a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** 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-03 23:33:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-03 23:33:03 - ERROR: failed to build lint kernel TB --- 2009-05-03 23:33:03 - 4701.93 user 452.49 system 5950.70 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 3 23:44: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 3BAB21065673; Sun, 3 May 2009 23:44:31 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi053.prodigy.net (nlpi053.sbcis.sbc.com [207.115.36.82]) by mx1.freebsd.org (Postfix) with ESMTP id 10D328FC14; Sun, 3 May 2009 23:44:30 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-5-28.dsl.snfc21.pacbell.net [71.139.5.28]) (authenticated bits=0) by nlpi053.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n43NWpPQ009414; Sun, 3 May 2009 18:32:51 -0500 Message-ID: <49FE29A4.30507@root.org> Date: Sun, 03 May 2009 16:32:52 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alexander Motin References: <49FE1826.4060000@FreeBSD.org> In-Reply-To: <49FE1826.4060000@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 May 2009 23:44:31 -0000 Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. Very nice summary. Thanks for doing the research. > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 When I first wrote cpufreq, there was some question if vendors (even non-Intel) might use throttling for more than just cutting the duty cycle. It turns out they haven't, and have focused more on dropping the voltage with P-state transitions (EIST, PowerNow) and are treating throttling as a legacy feature. The time may have come to disable p4tcc and throttling by default, as long as it's easy for a user to enable them again. Perhaps just a change to boot/default/device.hints? > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by > default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" The default settings in rc.conf should allow the lowest Cx setting available to be used. Perhaps that changed? Really, we want C3+ to be enabled by default without the user doing anything. > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=100 Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=0 The real solution for C3 (and C4, etc.) is to implement tickless scheduling and to fix the current dependence on LAPIC for timer interrupts. Hopefully someone will do that soon. With that change, this change isn't needed. > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. Most modems support the ACPI Dx states, where D3 = device powered off. I'd think the PCI "power no driver option" would disable the soft modem since it's unlikely you have a driver for it. > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. Did you increase the fsflush delay also? > So I have really doubled my on-battery time by this tuning - 4:47 hours > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > XP on the same system, provides maximum 3:20 hours. Very nice. I think tickless scheduling is the single largest win for power mgmt we could get. Second best would be S4 (suspend to disk). -- Nate From owner-freebsd-current@FreeBSD.ORG Mon May 4 01:14: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 7E5721065670; Mon, 4 May 2009 01:14:22 +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 511428FC1C; Mon, 4 May 2009 01:14:22 +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 A600771EFEB; Sun, 3 May 2009 21:14:21 -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 nNISy7un-t4T; Sun, 3 May 2009 21:14:21 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 839B871EFE4; Sun, 3 May 2009 21:14:21 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 80A0E68D; Sun, 3 May 2009 21:14:21 -0400 (EDT) Date: Sun, 3 May 2009 21:14:21 -0400 From: Adam McDougall To: Alexander Motin Message-ID: <20090504011421.GI6901@egr.msu.edu> References: <49FE1826.4060000@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FE1826.4060000@FreeBSD.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 01:14:22 -0000 On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Great list! May I suggest screen brightness and DPMS as another tool to save power, I've measured a 5W difference from the screen draw. Keeping the brightness as low as tolerable helps considerably, but also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to turn off the screen after 2 minutes helps when the laptop isn't being used every second. May need this in xorg.conf: Option "dpms" From owner-freebsd-current@FreeBSD.ORG Mon May 4 02:50:37 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 1A91A1065674; Mon, 4 May 2009 02:50:37 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1B88FC17; Mon, 4 May 2009 02:50:31 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from glorfindel.gritton.org (c-76-27-80-223.hsd1.ut.comcast.net [76.27.80.223]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n442VZl1020415; Sun, 3 May 2009 20:31:36 -0600 (MDT) Message-ID: <49FE5387.3020503@FreeBSD.org> Date: Sun, 03 May 2009 20:31:35 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090220) MIME-Version: 1.0 To: jail@FreeBSD.org, virtualization@FreeBSD.org, current@FreeBSD.org Content-Type: multipart/mixed; boundary="------------080804010107070301060002" X-Virus-Scanned: ClamAV 0.94.2/9321/Sun May 3 16:33:47 2009 on gritton.org X-Virus-Status: Clean Cc: Subject: New jail framework - the userland side X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 02:50:37 -0000 This is a multi-part message in MIME format. --------------080804010107070301060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all. I recently added some new jail-related system calls to extend the current jail system with an nmount-inspired name=value interface. This not only adds a new interface to the jail system, but allows for future extensions. For the first step, I've just added new system calls to set and read jail parameters. This is step 2: altering jail(8) and jls(8) to work with the new jails. With the included patch, the old "jail path hostname ip-number command..." command line turns to a more general "jail foo=bar baz=bletch ...". There's a set of core parameters to set the things jails can already do, plus the ability to set any parameters that other subsystems may want to tie to jails - work in progress includes the Linux MIB parameters, future ideas include separate namespaces for things like SYSV/Posix IPC. And of course, the plan is to use these new jails to tie in to the Vimage project. This patch is for the jail admin programs, and uses the current kernel as of r191673. You won't yet be able to do anything jails don't do already, but the interface is how I plan for things to look in the future. I'd appreciate comments from anyone who's interested in the future of lightweight virtualization. As a bonus, there are man pages included :-). - Jamie --------------080804010107070301060002 Content-Type: text/plain; name="ju.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ju.diff" Index: usr.bin/killall/killall.1 =================================================================== --- usr.bin/killall/killall.1 (revision 191694) +++ usr.bin/killall/killall.1 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 9, 2007 +.Dd April 30, 2009 .Os .Dt KILLALL 1 .Sh NAME @@ -34,7 +34,7 @@ .Nm .Op Fl delmsvz .Op Fl help -.Op Fl j Ar jid +.Op Fl j Ar jail .Op Fl u Ar user .Op Fl t Ar tty .Op Fl c Ar procname @@ -91,9 +91,9 @@ (with or without a leading .Dq Li SIG ) , or numerically. -.It Fl j Ar jid -Kill processes in the jail specified by -.Ar jid . +.It Fl j Ar jail +Kill processes in the specified +.Ar jail . .It Fl u Ar user Limit potentially matching processes to those belonging to the specified Index: usr.bin/killall/killall.c =================================================================== --- usr.bin/killall/killall.c (revision 191694) +++ usr.bin/killall/killall.c (working copy) @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -51,7 +52,7 @@ usage(void) { - fprintf(stderr, "usage: killall [-delmsvz] [-help] [-j jid]\n"); + fprintf(stderr, "usage: killall [-delmsvz] [-help] [-j jail]\n"); fprintf(stderr, " [-u user] [-t tty] [-c cmd] [-SIGNAL] [cmd]...\n"); fprintf(stderr, "At least one option or argument to specify processes must be given.\n"); @@ -100,6 +101,7 @@ int main(int ac, char **av) { + struct iovec jparams[2]; struct kinfo_proc *procs = NULL, *newprocs; struct stat sb; struct passwd *pw; @@ -159,12 +161,21 @@ } jflag++; if (*av == NULL) - errx(1, "must specify jid"); - jid = strtol(*av, &ep, 10); - if (!*av || *ep) - errx(1, "illegal jid: %s", *av); + errx(1, "must specify jail"); + jid = strtoul(*av, &ep, 10); + if (!**av || *ep) { + *(const void **)&jparams[0].iov_base = + "name"; + jparams[0].iov_len = sizeof("name"); + jparams[1].iov_base = *av; + jparams[1].iov_len = strlen(*av) + 1; + jid = jail_get(jparams, 2, 0); + if (jid < 0) + errx(1, "unknown jail: %s", + *av); + } if (jail_attach(jid) == -1) - err(1, "jail_attach(): %d", jid); + err(1, "jail_attach(%d)", jid); break; case 'u': ++*av; Index: usr.sbin/jls/jls.c =================================================================== --- usr.sbin/jls/jls.c (revision 191694) +++ usr.sbin/jls/jls.c (working copy) @@ -1,6 +1,7 @@ /*- * Copyright (c) 2003 Mike Barcroft * Copyright (c) 2008 Bjoern A. Zeeb + * Copyright (c) 2009 James Gritton * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -23,18 +24,20 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. - * - * $FreeBSD$ */ +#include +__FBSDID("$FreeBSD$"); + #include -#include #include +#include #include +#include -#include +#include #include -#include + #include #include #include @@ -43,215 +46,672 @@ #include #include -#define FLAG_A 0x00001 -#define FLAG_V 0x00002 +#define SJPARAM "security.jail.param" +#define ARRAY_SLOP 5 -#ifdef SUPPORT_OLD_XPRISON -static -char *print_xprison_v1(void *p, char *end, unsigned flags) +#define CTLTYPE_BOOL (CTLTYPE + 1) +#define CTLTYPE_NOBOOL (CTLTYPE + 2) +#define CTLTYPE_IPADDR (CTLTYPE + 3) +#define CTLTYPE_IP6ADDR (CTLTYPE + 4) + +#define PARAM_KEY 0x1 +#define PARAM_USER 0x2 +#define PARAM_ARRAY 0x4 +#define PARAM_OPT 0x8 + +#define PRINT_DEFAULT 0x01 +#define PRINT_VDEFAULT 0x02 +#define PRINT_HEADER 0x04 +#define PRINT_NAMEVAL 0x08 +#define PRINT_QUOTED 0x10 + +struct param { + char *name; + void *value; + size_t size; + int type; + unsigned flags; +}; + +struct iovec2 { + struct iovec name; + struct iovec value; +}; + +static struct param *params; +static int nparams; +static char errmsg[256]; + +static void add_param(const char *name, void *value, unsigned flags); +static int get_param(const char *name, struct param *param); +static int sort_param(const void *a, const void *b); +static char *noname(const char *name); +static char *nononame(const char *name); +static int print_jail(int pflags, int jflags); +static void quoted_print(char *str, int len); + +int +main(int argc, char **argv) { - struct xprison_v1 *xp; - struct in_addr in; + char *ep, *jname; + int c, i, jflags, jid, lastjid, pflags; - if ((char *)p + sizeof(struct xprison_v1) > end) - errx(1, "Invalid length for jail"); + jname = NULL; + pflags = jflags = jid = 0; + while ((c = getopt(argc, argv, "dj:hnqv")) >= 0) + switch (c) { + case 'd': + jflags |= JAIL_DYING; + break; + case 'j': + jid = strtoul(optarg, &ep, 10); + if (!*optarg || *ep) + jname = optarg; + break; + case 'h': + pflags |= PRINT_HEADER; + break; + case 'n': + pflags |= PRINT_NAMEVAL; + break; + case 'q': + pflags |= PRINT_QUOTED; + break; + case 'v': + pflags |= PRINT_VDEFAULT; + break; + default: + errx(1, "usage: jls [-dhnqv] [-j jail] [param ...]"); + } - xp = (struct xprison_v1 *)p; - if (flags & FLAG_V) { - printf("%6d %-29.29s %.74s\n", - xp->pr_id, xp->pr_host, xp->pr_path); - /* We are not printing an empty line here for state and name. */ - /* We are not printing an empty line here for cpusetid. */ - /* IPv4 address. */ - in.s_addr = htonl(xp->pr_ip); - printf("%6s %-15.15s\n", "", inet_ntoa(in)); + /* Add the parameters to print. */ + if (optind == argc) { + if (pflags & PRINT_VDEFAULT) { + add_param("jid", NULL, PARAM_USER); + add_param("host.hostname", NULL, PARAM_USER); + add_param("path", NULL, PARAM_USER); + add_param("name", NULL, PARAM_USER); + add_param("dying", NULL, PARAM_USER); + add_param("cpuset", NULL, PARAM_USER); + add_param("ip4.addr", NULL, PARAM_USER); + add_param("ip6.addr", NULL, PARAM_USER | PARAM_OPT); + } else { + pflags |= PRINT_DEFAULT; + add_param("jid", NULL, PARAM_USER); + add_param("ip4.addr", NULL, PARAM_USER); + add_param("host.hostname", NULL, PARAM_USER); + add_param("path", NULL, PARAM_USER); + } + } else + while (optind < argc) + add_param(argv[optind++], NULL, PARAM_USER); + + /* Add the index key and errmsg parameters. */ + if (jid != 0) + add_param("jid", &jid, PARAM_KEY); + else if (jname != NULL) + add_param("name", jname, PARAM_KEY); + else + add_param("lastjid", &lastjid, PARAM_KEY); + add_param("errmsg", errmsg, PARAM_KEY); + + /* Print a header line if requested. */ + if (pflags & PRINT_VDEFAULT) + printf(" JID Hostname Path\n" + " Name State\n" + " CPUSetID\n" + " IP Address(es)\n"); + else if (pflags & PRINT_DEFAULT) + printf(" JID IP Address " + "Hostname Path\n"); + else if (pflags & PRINT_HEADER) { + for (i = 0; i < nparams; i++) + if (params[i].flags & PARAM_USER) { + if (i > 0) + putchar(' '); + fputs(params[i].name, stdout); + } + putchar('\n'); + } + + /* Fetch the jail(s) and print the paramters. */ + if (jid != 0 || jname != NULL) { + if (print_jail(pflags, jflags) < 0) { + if (errmsg[0]) + errx(1, "%s", errmsg); + err(1, "jail_get"); + } } else { - printf("%6d %-15.15s %-29.29s %.74s\n", - xp->pr_id, inet_ntoa(in), xp->pr_host, xp->pr_path); + for (lastjid = 0; + (lastjid = print_jail(pflags, jflags)) >= 0; ) + ; + if (errno != 0 && errno != ENOENT) { + if (errmsg[0]) + errx(1, "%s", errmsg); + err(1, "jail_get"); + } } - return ((char *)(xp + 1)); + return (0); } -#endif -static -char *print_xprison_v3(void *p, char *end, unsigned flags) +static void +add_param(const char *name, void *value, unsigned flags) { - struct xprison *xp; - struct in_addr *iap, in; - struct in6_addr *ia6p; - char buf[INET6_ADDRSTRLEN]; - const char *state; - char *q; - uint32_t i; + struct param *param; + char *nname; + size_t mlen1, mlen2, buflen; + int mib1[CTL_MAXNAME], mib2[CTL_MAXNAME - 2]; + int i, tnparams; + char buf[MAXPATHLEN]; - if ((char *)p + sizeof(struct xprison) > end) - errx(1, "Invalid length for jail"); - xp = (struct xprison *)p; + static int paramlistsize; - if (xp->pr_state < 0 || xp->pr_state >= (int) - ((sizeof(prison_states) / sizeof(struct prison_state)))) - state = "(bogus)"; - else - state = prison_states[xp->pr_state].state_name; + /* The pseudo-parameter "all" scans the list of available parameters. */ + if (!strcmp(name, "all")) { + tnparams = nparams; + mib1[0] = 0; + mib1[1] = 2; + mlen1 = CTL_MAXNAME - 2; + if (sysctlnametomib(SJPARAM, mib1 + 2, &mlen1) < 0) + err(1, "sysctlnametomib(" SJPARAM ")"); + for (;;) { + /* Get the next parameter. */ + mlen2 = sizeof(mib2); + if (sysctl(mib1, mlen1 + 2, mib2, &mlen2, NULL, 0) < 0) + err(1, "sysctl(0.2)"); + if (mib2[0] != mib1[2] || mib2[1] != mib1[3] || + mib2[2] != mib1[4]) + break; + /* Convert it to an ascii name. */ + memcpy(mib1 + 2, mib2, mlen2); + mlen1 = mlen2 / sizeof(int); + mib1[1] = 1; + buflen = sizeof(buf); + if (sysctl(mib1, mlen1 + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.1)"); + add_param(buf + sizeof(SJPARAM), NULL, flags); + /* + * Convert nobool parameters to bool if their + * counterpart is a node, ortherwise discard them. + */ + param = ¶ms[nparams - 1]; + if (param->type == CTLTYPE_NOBOOL) { + nname = nononame(param->name); + if (get_param(nname, param) >= 0 && + param->type != CTLTYPE_NODE) { + free(nname); + nparams--; + } else { + free(param->name); + param->name = nname; + param->type = CTLTYPE_BOOL; + param->size = sizeof(int); + param->value = NULL; + } + } + mib1[1] = 2; + } - /* See if we should print non-ACTIVE jails. No? */ - if ((flags & FLAG_A) == 0 && strcmp(state, "ALIVE")) { - q = (char *)(xp + 1); - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - return (q); + qsort(params + tnparams, (size_t)(nparams - tnparams), + sizeof(struct param), sort_param); + return; } - if (flags & FLAG_V) - printf("%6d %-29.29s %.74s\n", - xp->pr_id, xp->pr_host, xp->pr_path); + /* Check for repeat parameters. */ + for (i = 0; i < nparams; i++) + if (!strcmp(name, params[i].name)) { + params[i].value = value; + params[i].flags |= flags; + return; + } - /* Jail state and name. */ - if (flags & FLAG_V) - printf("%6s %-29.29s %.74s\n", - "", (xp->pr_name[0] != '\0') ? xp->pr_name : "", state); + /* Make sure there is room for the new param record. */ + if (!nparams) { + paramlistsize = 32; + params = malloc(paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "malloc"); + } else if (nparams >= paramlistsize) { + paramlistsize *= 2; + params = realloc(params, paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "realloc"); + } - /* cpusetid. */ - if (flags & FLAG_V) - printf("%6s %-6d\n", - "", xp->pr_cpusetid); + /* Look up the parameter. */ + param = params + nparams++; + memset(param, 0, sizeof *param); + param->name = strdup(name); + if (param->name == NULL) + err(1, "strdup"); + param->flags = flags; + /* We have to know about pseudo-parameters without asking. */ + if (!strcmp(param->name, "lastjid")) { + param->type = CTLTYPE_INT; + param->size = sizeof(int); + goto got_type; + } + if (!strcmp(param->name, "errmsg")) { + param->type = CTLTYPE_STRING; + param->size = sizeof(errmsg); + goto got_type; + } + if (get_param(name, param) < 0) { + if (errno != ENOENT) + err(1, "sysctl(0.3.%s)", name); + /* See if this the "no" part of an existing boolean. */ + if ((nname = nononame(name))) { + i = get_param(nname, param); + free(nname); + if (i >= 0 && param->type == CTLTYPE_BOOL) { + param->type = CTLTYPE_NOBOOL; + goto got_type; + } + } + if (flags & PARAM_OPT) { + nparams--; + return; + } + errx(1, "unknown parameter: %s", name); + } + if (param->type == CTLTYPE_NODE) { + /* + * A node isn't normally a parameter, but may be a boolean + * if its "no" counterpart exists. + */ + nname = noname(name); + i = get_param(nname, param); + free(nname); + if (i >= 0 && param->type == CTLTYPE_NOBOOL) { + param->type = CTLTYPE_BOOL; + goto got_type; + } + errx(1, "unknown parameter: %s", name); + } - q = (char *)(xp + 1); - /* IPv4 addresses. */ - iap = (struct in_addr *)(void *)q; - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - in.s_addr = 0; - for (i = 0; i < xp->pr_ip4s; i++) { - if (i == 0 || flags & FLAG_V) - in.s_addr = iap[i].s_addr; - if (flags & FLAG_V) - printf("%6s %-15.15s\n", "", inet_ntoa(in)); + got_type: + param->value = value; +} + +static int +get_param(const char *name, struct param *param) +{ + char *bufi, *p; + size_t buflen, mlen; + int mib[CTL_MAXNAME]; + char buf[MAXPATHLEN]; + + /* Look up the MIB. */ + mib[0] = 0; + mib[1] = 3; + snprintf(buf, sizeof(buf), SJPARAM ".%s", name); + mlen = sizeof(mib) - 2 * sizeof(int); + if (sysctl(mib, 2, mib + 2, &mlen, buf, strlen(buf)) < 0) + return (-1); + /* Get the type and size. */ + mib[1] = 4; + buflen = sizeof(buf); + if (sysctl(mib, (mlen / sizeof(int)) + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.4.%s)", name); + param->type = *(int *)buf & CTLTYPE; + bufi = buf + sizeof(int); + p = strchr(bufi, '\0'); + if (p - 2 >= bufi && !strcmp(p - 2, ",a")) { + p[-2] = 0; + param->flags |= PARAM_ARRAY; } - /* IPv6 addresses. */ - ia6p = (struct in6_addr *)(void *)q; - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - for (i = 0; i < xp->pr_ip6s; i++) { - if (flags & FLAG_V) { - inet_ntop(AF_INET6, &ia6p[i], buf, sizeof(buf)); - printf("%6s %s\n", "", buf); + switch (param->type) { + case CTLTYPE_INT: + /* An integer parameter might be a boolean. */ + if (bufi[0] == 'B') + param->type = bufi[1] == 'N' + ? CTLTYPE_NOBOOL : CTLTYPE_BOOL; + case CTLTYPE_UINT: + param->size = sizeof(int); + break; + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + param->size = sizeof(long); + break; + case CTLTYPE_STRUCT: + if (!strcmp(bufi, "S,in_addr")) { + param->type = CTLTYPE_IPADDR; + param->size = sizeof(struct in_addr); + } else if (!strcmp(bufi, "S,in6_addr")) { + param->type = CTLTYPE_IP6ADDR; + param->size = sizeof(struct in6_addr); } + break; + case CTLTYPE_STRING: + buf[0] = 0; + sysctl(mib + 2, mlen / sizeof(int), buf, &buflen, NULL, 0); + param->size = strtoul(buf, NULL, 10); + if (param->size == 0) + param->size = BUFSIZ; } + return (0); +} - /* If requested print the old style single line version. */ - if (!(flags & FLAG_V)) - printf("%6d %-15.15s %-29.29s %.74s\n", - xp->pr_id, (in.s_addr) ? inet_ntoa(in) : "", - xp->pr_host, xp->pr_path); +static int +sort_param(const void *a, const void *b) +{ + const struct param *parama, *paramb; + char *ap, *bp; - return (q); + /* Put top-level parameters first. */ + parama = a; + paramb = b; + ap = strchr(parama->name, '.'); + bp = strchr(paramb->name, '.'); + if (ap && !bp) + return (1); + if (bp && !ap) + return (-1); + return (strcmp(parama->name, paramb->name)); } -static void -usage(void) +static char * +noname(const char *name) { + char *nname, *p; - (void)fprintf(stderr, "usage: jls [-av]\n"); - exit(1); + nname = malloc(strlen(name) + 3); + if (nname == NULL) + err(1, "malloc"); + p = strrchr(name, '.'); + if (p != NULL) + sprintf(nname, "%.*s.no%s", p - name, name, p + 1); + else + sprintf(nname, "no%s", name); + return nname; } -int -main(int argc, char *argv[]) -{ - int ch, version; - unsigned flags; - size_t i, j, len; - void *p, *q; +static char * +nononame(const char *name) +{ + char *nname, *p; - flags = 0; - while ((ch = getopt(argc, argv, "av")) != -1) { - switch (ch) { - case 'a': - flags |= FLAG_A; - break; - case 'v': - flags |= FLAG_V; - break; - default: - usage(); - } - } - argc -= optind; - argv += optind; + p = strrchr(name, '.'); + if (strncmp(p ? p + 1 : name, "no", 2)) + return NULL; + nname = malloc(strlen(name) - 1); + if (nname == NULL) + err(1, "malloc"); + if (p != NULL) + sprintf(nname, "%.*s.%s", p - name, name, p + 3); + else + strcpy(nname, name + 2); + return nname; +} - if (sysctlbyname("security.jail.list", NULL, &len, NULL, 0) == -1) - err(1, "sysctlbyname(): security.jail.list"); +static int +print_jail(int pflags, int jflags) +{ + char *nname; + int i, ai, jid, count, sanity; + char ipbuf[INET6_ADDRSTRLEN]; - j = len; - for (i = 0; i < 4; i++) { - if (len <= 0) - exit(0); - p = q = malloc(len); - if (p == NULL) - err(1, "malloc()"); + static struct iovec2 *iov, *aiov; + static int narray, nkey; - if (sysctlbyname("security.jail.list", q, &len, NULL, 0) == -1) { - if (errno == ENOMEM) { - free(p); - p = NULL; - len += j; + /* Set up the parameter list(s) the first time around. */ + if (iov == NULL) { + iov = malloc(nparams * sizeof(struct iovec2)); + if (iov == NULL) + err(1, "malloc"); + for (i = narray = 0; i < nparams; i++) { + iov[i].name.iov_base = params[i].name; + iov[i].name.iov_len = strlen(params[i].name) + 1; + iov[i].value.iov_base = params[i].value; + iov[i].value.iov_len = + params[i].type == CTLTYPE_STRING && + params[i].value != NULL && + ((char *)params[i].value)[0] != '\0' + ? strlen(params[i].value) + 1 : params[i].size; + if (params[i].flags & (PARAM_KEY | PARAM_ARRAY)) { + narray++; + if (params[i].flags & PARAM_KEY) + nkey++; + } + } + if (narray > nkey) { + aiov = malloc(narray * sizeof(struct iovec2)); + if (aiov == NULL) + err(1, "malloc"); + for (i = ai = 0; i < nparams; i++) + if (params[i].flags & + (PARAM_KEY | PARAM_ARRAY)) + aiov[ai++] = iov[i]; + } + } + /* If there are array parameters, find their sizes. */ + if (aiov != NULL) { + for (ai = 0; ai < narray; ai++) + if (aiov[ai].value.iov_base == NULL) + aiov[ai].value.iov_len = 0; + if (jail_get((struct iovec *)aiov, 2 * narray, jflags) < 0) + return (-1); + } + /* Allocate storage for all parameters. */ + for (i = ai = 0; i < nparams; i++) { + if (params[i].flags & (PARAM_KEY | PARAM_ARRAY)) { + if (params[i].flags & PARAM_ARRAY) { + iov[i].value.iov_len = aiov[ai].value.iov_len + + ARRAY_SLOP * params[i].size; + iov[i].value.iov_base = + malloc(iov[i].value.iov_len); + } + ai++; + } else + iov[i].value.iov_base = malloc(params[i].size); + if (iov[i].value.iov_base == NULL) + err(1, "malloc"); + if (params[i].value == NULL) + memset(iov[i].value.iov_base, 0, iov[i].value.iov_len); + } + /* + * Get the actual prison. If there are array elements, retry a few + * times in case the size changed from under us. + */ + if ((jid = jail_get((struct iovec *)iov, 2 * nparams, jflags)) < 0) { + if (errno != EINVAL || aiov == NULL || errmsg[0]) + return (-1); + for (sanity = 0;; sanity++) { + if (sanity == 10) + return (-1); + for (ai = 0; ai < narray; ai++) + if (params[i].flags & PARAM_ARRAY) + aiov[ai].value.iov_len = 0; + if (jail_get((struct iovec *)iov, 2 * narray, jflags) < + 0) + return (-1); + for (i = ai = 0; i < nparams; i++) { + if (!(params[i].flags & + (PARAM_KEY | PARAM_ARRAY))) + continue; + if (params[i].flags & PARAM_ARRAY) { + iov[i].value.iov_len = + aiov[ai].value.iov_len + + ARRAY_SLOP * params[i].size; + iov[i].value.iov_base = + realloc(iov[i].value.iov_base, + iov[i].value.iov_len); + if (iov[i].value.iov_base == NULL) + err(1, "malloc"); + } + ai++; + } + } + } + if (pflags & PRINT_VDEFAULT) { + printf("%6d %-29.29s %.74s\n" + "%6s %-29.29s %.74s\n" + "%6s %-6d\n", + *(int *)iov[0].value.iov_base, + (char *)iov[1].value.iov_base, + (char *)iov[2].value.iov_base, + "", + (char *)iov[3].value.iov_base, + *(int *)iov[4].value.iov_base ? "DYING" : "ACTIVE", + "", + *(int *)iov[5].value.iov_base); + count = iov[6].value.iov_len / sizeof(struct in_addr); + for (ai = 0; ai < count; ai++) + if (inet_ntop(AF_INET, + &((struct in_addr *)iov[6].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%6s %-15.15s\n", "", ipbuf); + if (!strcmp(params[7].name, "ip6.addr")) { + count = iov[7].value.iov_len / sizeof(struct in6_addr); + for (ai = 0; ai < count; ai++) + if (inet_ntop(AF_INET6, &((struct in_addr *) + iov[7].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%6s %-15.15s\n", "", ipbuf); + } + } else if (pflags & PRINT_DEFAULT) + printf("%6d %-15.15s %-29.29s %.74s\n", + *(int *)iov[0].value.iov_base, + iov[1].value.iov_len == 0 ? "-" + : inet_ntoa(*(struct in_addr *)iov[1].value.iov_base), + (char *)iov[2].value.iov_base, + (char *)iov[3].value.iov_base); + else { + for (i = 0; i < nparams; i++) { + if (!(params[i].flags & PARAM_USER)) continue; + if (i > 0) + putchar(' '); + if (pflags & PRINT_NAMEVAL) { + /* + * Generally "name=value", but for booleans + * either "name" or "noname". + */ + switch (params[i].type) { + case CTLTYPE_BOOL: + if (*(int *)iov[i].value.iov_base) + printf("%s", params[i].name); + else { + nname = noname(params[i].name); + printf("%s", nname); + free(nname); + } + break; + case CTLTYPE_NOBOOL: + if (*(int *)iov[i].value.iov_base) + printf("%s", params[i].name); + else { + nname = + nononame(params[i].name); + printf("%s", nname); + free(nname); + } + break; + default: + printf("%s=", params[i].name); + } } - err(1, "sysctlbyname(): security.jail.list"); + count = params[i].flags & PARAM_ARRAY + ? iov[i].value.iov_len / params[i].size : 1; + if (count == 0) + putchar('-'); + for (ai = 0; ai < count; ai++) { + if (ai > 0) + putchar(','); + switch (params[i].type) { + case CTLTYPE_INT: + printf("%d", ((int *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_UINT: + printf("%u", ((int *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_IPADDR: + if (inet_ntop(AF_INET, + &((struct in_addr *) + iov[i].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%s", ipbuf); + break; + case CTLTYPE_IP6ADDR: + if (inet_ntop(AF_INET6, + &((struct in6_addr *) + iov[i].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%s", ipbuf); + break; + case CTLTYPE_LONG: + printf("%ld", ((long *) + iov[i].value.iov_base)[ai]); + case CTLTYPE_ULONG: + printf("%lu", ((long *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_STRING: + if (pflags & PRINT_QUOTED) + quoted_print((char *) + iov[i].value.iov_base, + params[i].size); + else + printf("%.*s", + params[i].size, (char *) + iov[i].value.iov_base); + break; + case CTLTYPE_BOOL: + case CTLTYPE_NOBOOL: + if (!(pflags & PRINT_NAMEVAL)) + printf(((int *) + iov[i].value.iov_base)[ai] + ? "true" : "false"); + } + } } - break; + putchar('\n'); } - if (p == NULL) - err(1, "sysctlbyname(): security.jail.list"); - if (len < sizeof(int)) - errx(1, "This is no prison. Kernel and userland out of sync?"); - version = *(int *)p; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); + for (i = 0; i < nparams; i++) + if (params[i].value == NULL) + free(iov[i].value.iov_base); + return (jid); +} - if (flags & FLAG_V) { - printf(" JID Hostname Path\n"); - printf(" Name State\n"); - printf(" CPUSetID\n"); - printf(" IP Address(es)\n"); - } else { - printf(" JID IP Address Hostname" - " Path\n"); +static void +quoted_print(char *str, int len) +{ + int c, qc; + char *p = str; + char *ep = str + len; + + /* An empty string needs quoting. */ + if (!*p) { + fputs("\"\"", stdout); + return; } - for (; q != NULL && (char *)q + sizeof(int) < (char *)p + len;) { - version = *(int *)q; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - switch (version) { -#ifdef SUPPORT_OLD_XPRISON - case 1: - q = print_xprison_v1(q, (char *)p + len, flags); - break; - case 2: - errx(1, "Version 2 was used by multi-IPv4 jail " - "implementations that never made it into the " - "official kernel."); - /* NOTREACHED */ - break; -#endif - case 3: - q = print_xprison_v3(q, (char *)p + len, flags); - break; - default: - errx(1, "Prison unknown. Kernel/userland out of sync?"); - /* NOTREACHED */ - break; - } + + /* + * The value will be surrounded by quotes if it contains spaces + * or quotes. + */ + qc = strchr(p, '\'') ? '"' + : strchr(p, '"') ? '\'' + : strchr(p, ' ') || strchr(p, '\t') ? '"' + : 0; + if (qc) + putchar(qc); + while (p < ep && (c = *p++)) { + if (c == '\\' || c == qc) + putchar('\\'); + putchar(c); } - - free(p); - exit(0); + if (qc) + putchar(qc); } Index: usr.sbin/jls/Makefile =================================================================== --- usr.sbin/jls/Makefile (revision 191694) +++ usr.sbin/jls/Makefile (working copy) @@ -4,6 +4,4 @@ MAN= jls.8 WARNS?= 6 -CFLAGS+= -DSUPPORT_OLD_XPRISON - .include Index: usr.sbin/jls/jls.8 =================================================================== --- usr.sbin/jls/jls.8 (revision 191694) +++ usr.sbin/jls/jls.8 (working copy) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 29, 2008 +.Dd April 30, 2009 .Dt JLS 8 .Os .Sh NAME @@ -33,38 +33,59 @@ .Nd "list jails" .Sh SYNOPSIS .Nm -.Op Fl av +.Op Fl dhnqv +.Op Fl j Ar jail +.Op Ar parameter ... .Sh DESCRIPTION The .Nm -utility lists all jails. -By default only active jails are listed. +utility lists all active jails, or the specified jail. +Each jail is represented by one row which contains space-separated values of +the listed +.Ar parameters , +including the pseudo-parameter +.Va all +which will show all available jail parameters. +A list of available parameters can be retrieved via +.Dq Nm sysctl Fl d Va security.jail.param . .Pp -The options are as follows: -.Bl -tag -width ".Fl a" -.It Fl a -Show jails in all states, not only active ones. +If no +.Ar parameters +are given, the following four columns will be printed: +jail identifier (jid), IP address (ip4.addr), hostname (host.hostname), +and path (path). +.Pp +The following options are available: +.Bl -tag -width indent +.It Fl d +List +.Va dying +as well as active jails. +.It Fl h +Print a header line containing the parameters listed. +If no parameters are given on the command line, the default four-column +output always contains a header. +.It Fl n +Print parameters in +.Dq name=value +format, where each parameter is preceded by its name. +This option is ignored for the default four-column output. +.It Fl q +Put quotes around string parameters if they contain spaces or quotes, or are +the empty string. .It Fl v -Show more verbose information. -This also lists cpusets, jail state, multi-IP, etc. instead of the -classic single-IP jail output. +Print a multiple-line summary per jail, with the following parameters: +jail identifier (jid), hostname (host.hostname), path (path), +jail name (name), jail state (dying), cpuset ID (cpuset), +IP address(es) (ip4.addr and ip6.addr). +.It Fl j Ar jail +The jid or name of the +.Ar jail +to list. +Without this option, all active jails will be listed. .El -.Pp -Each jail is represented by rows which, depending on -.Fl v , -contain the following columns: -.Bl -item -offset indent -compact -.It -jail identifier (JID), hostname and path -.It -jail state and name -.It -jail cpuset -.It -followed by one IP adddress per line. -.El .Sh SEE ALSO -.Xr jail 2 , +.Xr jail_get 2 , .Xr jail 8 , .Xr jexec 8 .Sh HISTORY @@ -72,3 +93,5 @@ .Nm utility was added in .Fx 5.1 . +Extensible jail parameters were introduced in +.Fx 8.0 . Index: usr.sbin/jexec/jexec.c =================================================================== --- usr.sbin/jexec/jexec.c (revision 191694) +++ usr.sbin/jexec/jexec.c (working copy) @@ -29,12 +29,16 @@ #include #include +#include #include +#include +#include #include #include #include +#include #include #include #include @@ -43,154 +47,8 @@ #include static void usage(void); +static int addr2jid(const char *addr); -#ifdef SUPPORT_OLD_XPRISON -static -char *lookup_xprison_v1(void *p, char *end, int *id) -{ - struct xprison_v1 *xp; - - if (id == NULL) - errx(1, "Internal error. Invalid ID pointer."); - - if ((char *)p + sizeof(struct xprison_v1) > end) - errx(1, "Invalid length for jail"); - - xp = (struct xprison_v1 *)p; - - *id = xp->pr_id; - return ((char *)(xp + 1)); -} -#endif - -static -char *lookup_xprison_v3(void *p, char *end, int *id, char *jailname) -{ - struct xprison *xp; - char *q; - int ok; - - if (id == NULL) - errx(1, "Internal error. Invalid ID pointer."); - - if ((char *)p + sizeof(struct xprison) > end) - errx(1, "Invalid length for jail"); - - xp = (struct xprison *)p; - ok = 1; - - /* Jail state and name. */ - if (xp->pr_state < 0 || xp->pr_state >= - (int)((sizeof(prison_states) / sizeof(struct prison_state)))) - errx(1, "Invalid jail state."); - else if (xp->pr_state != PRISON_STATE_ALIVE) - ok = 0; - if (jailname != NULL) { - if (xp->pr_name[0] == '\0') - ok = 0; - else if (strcmp(jailname, xp->pr_name) != 0) - ok = 0; - } - - q = (char *)(xp + 1); - /* IPv4 addresses. */ - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if ((char *)q > end) - errx(1, "Invalid length for jail"); - /* IPv6 addresses. */ - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if ((char *)q > end) - errx(1, "Invalid length for jail"); - - if (ok) - *id = xp->pr_id; - return (q); -} - -static int -lookup_jail(int jid, char *jailname) -{ - size_t i, j, len; - void *p, *q; - int version, id, xid, count; - - if (sysctlbyname("security.jail.list", NULL, &len, NULL, 0) == -1) - err(1, "sysctlbyname(): security.jail.list"); - - j = len; - for (i = 0; i < 4; i++) { - if (len == 0) - return (-1); - p = q = malloc(len); - if (p == NULL) - err(1, "malloc()"); - - if (sysctlbyname("security.jail.list", q, &len, NULL, 0) == -1) { - if (errno == ENOMEM) { - free(p); - p = NULL; - len += j; - continue; - } - err(1, "sysctlbyname(): security.jail.list"); - } - break; - } - if (p == NULL) - err(1, "sysctlbyname(): security.jail.list"); - if (len < sizeof(int)) - errx(1, "This is no prison. Kernel and userland out of sync?"); - version = *(int *)p; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - - count = 0; - xid = -1; - for (; q != NULL && (char *)q + sizeof(int) < (char *)p + len;) { - version = *(int *)q; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - id = -1; - switch (version) { -#ifdef SUPPORT_OLD_XPRISON - case 1: - if (jailname != NULL) - errx(1, "Version 1 prisons did not " - "support jail names."); - q = lookup_xprison_v1(q, (char *)p + len, &id); - break; - case 2: - errx(1, "Version 2 was used by multi-IPv4 jail " - "implementations that never made it into the " - "official kernel."); - /* NOTREACHED */ - break; -#endif - case 3: - q = lookup_xprison_v3(q, (char *)p + len, &id, jailname); - break; - default: - errx(1, "Prison unknown. Kernel/userland out of sync?"); - /* NOTREACHED */ - break; - } - /* Possible match; see if we have a jail ID to match as well. */ - if (id > 0 && (jid <= 0 || id == jid)) { - xid = id; - count++; - } - } - - free(p); - - if (count == 1) - return (xid); - else if (count > 1) - errx(1, "Could not uniquely identify the jail."); - else - return (-1); -} - #define GET_USER_INFO do { \ pwd = getpwnam(username); \ if (pwd == NULL) { \ @@ -210,22 +68,18 @@ int main(int argc, char *argv[]) { + struct iovec params[2]; int jid; login_cap_t *lcap = NULL; struct passwd *pwd = NULL; gid_t groups[NGROUPS]; - int ch, ngroups, uflag, Uflag; - char *jailname, *username; + int ch, ngroups, uflag, Uflag, hflag; + char *ep, *username; + ch = uflag = Uflag = hflag = 0; + username = NULL; - ch = uflag = Uflag = 0; - jailname = username = NULL; - jid = -1; - - while ((ch = getopt(argc, argv, "i:n:u:U:")) != -1) { + while ((ch = getopt(argc, argv, "u:U:h")) != -1) { switch (ch) { - case 'n': - jailname = optarg; - break; case 'u': username = optarg; uflag = 1; @@ -234,6 +88,9 @@ username = optarg; Uflag = 1; break; + case 'h': + hflag = 1; + break; default: usage(); } @@ -242,22 +99,24 @@ argv += optind; if (argc < 2) usage(); - if (strlen(argv[0]) > 0) { - jid = (int)strtol(argv[0], NULL, 10); - if (errno) - err(1, "Unable to parse jail ID."); - } - if (jid <= 0 && jailname == NULL) { - fprintf(stderr, "Neither jail ID nor jail name given.\n"); - usage(); - } if (uflag && Uflag) usage(); if (uflag) GET_USER_INFO; - jid = lookup_jail(jid, jailname); - if (jid <= 0) - errx(1, "Cannot identify jail."); + if (hflag) + jid = addr2jid(argv[0]); + else { + jid = strtoul(argv[0], &ep, 10); + if (!*argv[0] || *ep) { + *(const void **)¶ms[0].iov_base = "name"; + params[0].iov_len = sizeof("name"); + params[1].iov_base = argv[0]; + params[1].iov_len = strlen(argv[0]) + 1; + jid = jail_get(params, 2, 0); + if (jid < 0) + errx(1, "Unknown jail: %s", argv[0]); + } + } if (jail_attach(jid) == -1) err(1, "jail_attach(): %d", jid); if (chdir("/") == -1) @@ -285,6 +144,108 @@ fprintf(stderr, "%s%s\n", "usage: jexec [-u username | -U username]", - " [-n jailname] jid command ..."); + " [-h hostname | -h ip-number | jail] command ..."); exit(1); } + +static int +addr2jid(const char *addr) +{ + struct iovec params[6]; + struct in_addr ia; + struct in6_addr ia6; + int cnt, doip, foundjid, ii, jid, lastjid, sanity; + char hostbuf[MAXHOSTNAMELEN]; + + if (inet_pton(AF_INET, addr, &ia) > 0) + doip = 4; + else if (inet_pton(AF_INET6, addr, &ia6) > 0) + doip = 6; + else + doip = 0; + + *(const void **)¶ms[0].iov_base = "lastjid"; + params[0].iov_len = sizeof("lastjid"); + params[1].iov_base = &lastjid; + params[1].iov_len = sizeof(lastjid); + switch (doip) { + case 4: + *(const void **)¶ms[2].iov_base = "ip4.addr"; + params[2].iov_len = sizeof("ip4.addr"); + *(const void **)¶ms[4].iov_base = "host.hostname"; + params[4].iov_len = sizeof("host.hostname"); + params[5].iov_base = hostbuf; + params[5].iov_len = MAXHOSTNAMELEN; + break; + case 6: + *(const void **)¶ms[2].iov_base = "ip6.addr"; + params[2].iov_len = sizeof("ip6.addr"); + *(const void **)¶ms[4].iov_base = "host.hostname"; + params[4].iov_len = sizeof("host.hostname"); + params[5].iov_base = hostbuf; + params[5].iov_len = MAXHOSTNAMELEN; + break; + default: + *(const void **)¶ms[2].iov_base = "host.hostname"; + params[2].iov_len = sizeof("host.hostname"); + params[3].iov_base = hostbuf; + params[3].iov_len = MAXHOSTNAMELEN; + } + + cnt = foundjid = sanity = 0; + for (jid = 0;; jid = lastjid) { + if (doip != 0) { + params[3].iov_base = NULL; + params[3].iov_len = 0; + if (jail_get(params, 4, 0) < 0) + break; + params[3].iov_len += 5 * sizeof(struct in6_addr); + params[3].iov_base = malloc(params[3].iov_len); + jid = jail_get(params, 6, 0); + } else + jid = jail_get(params, 4, 0); + if (jid > 0) { + sanity = 0; + if (!strcmp(hostbuf, addr)) { + cnt++; + foundjid = jid; + } else switch (doip) { + case 4: + for (ii = (params[3].iov_len / + sizeof(struct in_addr)) - 1; ii >= 0; ii--) + if (((struct in_addr *)params[3]. + iov_base)[ii].s_addr == ia.s_addr) { + cnt++; + foundjid = jid; + break; + } + break; + case 6: + for (ii = (params[3].iov_len / + sizeof(struct in6_addr)) - 1; ii >= 0; + ii--) + if (IN6_ARE_ADDR_EQUAL(&ia6, + &((struct in6_addr *) + params[3].iov_base)[ii])) { + cnt++; + foundjid = jid; + break; + } + } + } else if (errno == ENOENT || ++sanity > 10) + break; + else + jid = lastjid; + if (doip != 0) + free(params[3].iov_base); + } + switch (cnt) + { + case 0: + errx(1, "Unknown jail: %s", addr); + case 1: + return foundjid; + default: + errx(1, "Could not uniquely identify the jail: %s", addr); + } +} Index: usr.sbin/jexec/jexec.8 =================================================================== --- usr.sbin/jexec/jexec.8 (revision 191694) +++ usr.sbin/jexec/jexec.8 (working copy) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 29, 2008 +.Dd April 30, 2009 .Dt JEXEC 8 .Os .Sh NAME @@ -34,36 +34,22 @@ .Sh SYNOPSIS .Nm .Op Fl u Ar username | Fl U Ar username -.Op Fl n Ar jailname -.Ar jid command ... +.Op Fl h Ar hostname | Fl h Ar ip | Ar jid | Ar name +.Ar command ... .Sh DESCRIPTION The .Nm utility executes .Ar command -inside the jail identified by either -.Ar jailname +inside the jail identified by +.Ar hostname , +.Ar ip , +.Ar jid , or -.Ar jid -or both. +.Ar name . .Pp -If the jail cannot be identified uniquely by the given parameters, -an error message is printed. -.Nm -will also check the state of the jail (once supported) to be -.Dv ALIVE -and ignore jails in other states. -The mandatory argument -.Ar jid -is the unique jail identifier as given by -.Xr jls 8 . -In case you only want to match on other criteria, give an empty string. -.Pp The following options are available: .Bl -tag -width indent -.It Fl n Ar jailname -The name of the jail, if given upon creation of the jail. -This is not the hostname of the jail. .It Fl u Ar username The user name from host environment as whom the .Ar command @@ -73,6 +59,9 @@ .Ar command should run. .El +.Sh "CAUTIONS" +Only a jail's jid or name is guaranteed to uniquely identify the jail. +Hostname or ip only work here if matched to one unique jail. .Sh SEE ALSO .Xr jail_attach 2 , .Xr jail 8 , Index: usr.sbin/jexec/Makefile =================================================================== --- usr.sbin/jexec/Makefile (revision 191694) +++ usr.sbin/jexec/Makefile (working copy) @@ -6,6 +6,4 @@ LDADD= -lutil WARNS?= 6 -CFLAGS+= -DSUPPORT_OLD_XPRISON - .include Index: usr.sbin/jail/jail.c =================================================================== --- usr.sbin/jail/jail.c (revision 191694) +++ usr.sbin/jail/jail.c (working copy) @@ -1,5 +1,6 @@ /*- * Copyright (c) 1999 Poul-Henning Kamp. + * Copyright (c) 2009 James Gritton * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -29,51 +30,43 @@ #include #include -#include #include #include -#include +#include +#include #include -#include -#include +#include #include #include #include #include +#include #include #include #include #include -#include #include #include -static void usage(void); -static int add_addresses(struct addrinfo *); -static struct in_addr *copy_addr4(void); -#ifdef INET6 -static struct in6_addr *copy_addr6(void); -#endif +#define SJPARAM "security.jail.param" +#define ERRMSG_SIZE 256 -extern char **environ; - -struct addr4entry { - STAILQ_ENTRY(addr4entry) addr4entries; - struct in_addr ip4; - int count; +struct param { + struct iovec name; + struct iovec value; }; -struct addr6entry { - STAILQ_ENTRY(addr6entry) addr6entries; -#ifdef INET6 - struct in6_addr ip6; -#endif - int count; -}; -STAILQ_HEAD(addr4head, addr4entry) addr4 = STAILQ_HEAD_INITIALIZER(addr4); -STAILQ_HEAD(addr6head, addr6entry) addr6 = STAILQ_HEAD_INITIALIZER(addr6); +static struct param *params; +static int nparams; + +static void set_param(const char *name, char *value); +static void set_param_ip_hostname(char *value, int family); +static void usage(void); + +extern char **environ; + #define GET_USER_INFO do { \ pwd = getpwnam(username); \ if (pwd == NULL) { \ @@ -94,27 +87,28 @@ main(int argc, char **argv) { login_cap_t *lcap = NULL; - struct jail j; + struct iovec rparams[2]; struct passwd *pwd = NULL; gid_t groups[NGROUPS]; - int ch, error, i, ngroups, securelevel; - int hflag, iflag, Jflag, lflag, uflag, Uflag; - char path[PATH_MAX], *jailname, *ep, *username, *JidFile, *ip; + int ch, cmdarg, i, jail_set_flags, jid, ngroups, oldargs, securelevel; + int iflag, Jflag, lflag, rflag, uflag, Uflag; + char *ep, *username, *JidFile; + char errmsg[ERRMSG_SIZE]; static char *cleanenv; const char *shell, *p = NULL; long ltmp; FILE *fp; - struct addrinfo hints, *res0; - hflag = iflag = Jflag = lflag = uflag = Uflag = 0; - securelevel = -1; - jailname = username = JidFile = cleanenv = NULL; + iflag = Jflag = lflag = rflag = uflag = Uflag = 0; + jail_set_flags = JAIL_CREATE | JAIL_UPDATE; + cmdarg = jid = securelevel = -1; + username = JidFile = cleanenv = NULL; fp = NULL; - while ((ch = getopt(argc, argv, "hiln:s:u:U:J:")) != -1) { + while ((ch = getopt(argc, argv, "cdilor:s:u:U:J:")) != -1) { switch (ch) { - case 'h': - hflag = 1; + case 'd': + jail_set_flags |= JAIL_DYING; break; case 'i': iflag = 1; @@ -123,9 +117,6 @@ JidFile = optarg; Jflag = 1; break; - case 'n': - jailname = optarg; - break; case 's': ltmp = strtol(optarg, &ep, 0); if (*ep || ep == optarg || ltmp > INT_MAX || !ltmp) @@ -143,13 +134,41 @@ case 'l': lflag = 1; break; + case 'c': + jail_set_flags = + (jail_set_flags & ~JAIL_UPDATE) | JAIL_CREATE; + break; + case 'o': + jail_set_flags = + (jail_set_flags & ~JAIL_CREATE) | JAIL_UPDATE; + break; + case 'r': + jid = strtoul(optarg, &ep, 10); + if (!*optarg || *ep) { + *(const void **)&rparams[0].iov_base = "name"; + rparams[0].iov_len = sizeof("name"); + rparams[1].iov_base = optarg; + rparams[1].iov_len = strlen(optarg) + 1; + jid = jail_get(rparams, 2, 0); + if (jid < 0) + errx(1, "unknown jail: %s", optarg); + } + rflag = 1; + break; default: usage(); } } argc -= optind; argv += optind; - if (argc < 4) + if (rflag) { + if (argc > 0 || iflag || Jflag || lflag || uflag || Uflag) + usage(); + if (jail_remove(jid) < 0) + err(1, "jail_remove"); + exit (0); + } + if (argc == 0) usage(); if (uflag && Uflag) usage(); @@ -157,92 +176,70 @@ usage(); if (uflag) GET_USER_INFO; - if (realpath(argv[0], path) == NULL) - err(1, "realpath: %s", argv[0]); - if (chdir(path) != 0) - err(1, "chdir: %s", path); - /* Initialize struct jail. */ - memset(&j, 0, sizeof(j)); - j.version = JAIL_API_VERSION; - j.path = path; - j.hostname = argv[1]; - if (jailname != NULL) - j.jailname = jailname; - /* Handle IP addresses. If requested resolve hostname too. */ - bzero(&hints, sizeof(struct addrinfo)); - hints.ai_protocol = IPPROTO_TCP; - hints.ai_socktype = SOCK_STREAM; - if (JAIL_API_VERSION < 2) - hints.ai_family = PF_INET; - else - hints.ai_family = PF_UNSPEC; - /* Handle hostname. */ - if (hflag != 0) { - error = getaddrinfo(j.hostname, NULL, &hints, &res0); - if (error != 0) - errx(1, "failed to handle hostname: %s", - gai_strerror(error)); - error = add_addresses(res0); - freeaddrinfo(res0); - if (error != 0) - errx(1, "failed to add addresses."); + /* + * If the first argument (path) starts with a slash, and the third + * argument (IP address) starts with a digit, it is likely to be + * an old-style fixed-parameter command line. + */ + oldargs = argc >= 4 && argv[0][0] == '/' && isdigit(argv[2][0]); + if (oldargs) { + if ((jail_set_flags & (JAIL_CREATE | JAIL_UPDATE)) != + (JAIL_CREATE | JAIL_UPDATE)) + usage(); + jail_set_flags = JAIL_CREATE | JAIL_ATTACH; + set_param("path", argv[0]); + set_param("host.hostname", argv[1]); + set_param("ip4.addr", argv[2]); + cmdarg = 3; + } else { + for (i = 0; i < argc; i++) + if (!strncmp(argv[i], "command=", 8)) { + cmdarg = i; + argv[cmdarg] += 8; + jail_set_flags |= JAIL_ATTACH; + break; + } else + set_param(NULL, argv[i]); } - /* Handle IP addresses. */ - hints.ai_flags = AI_NUMERICHOST; - ip = strtok(argv[2], ","); - while (ip != NULL) { - error = getaddrinfo(ip, NULL, &hints, &res0); - if (error != 0) - errx(1, "failed to handle ip: %s", gai_strerror(error)); - error = add_addresses(res0); - freeaddrinfo(res0); - if (error != 0) - errx(1, "failed to add addresses."); - ip = strtok(NULL, ","); - } - /* Count IP addresses and add them to struct jail. */ - if (!STAILQ_EMPTY(&addr4)) { - j.ip4s = STAILQ_FIRST(&addr4)->count; - j.ip4 = copy_addr4(); - if (j.ip4s > 0 && j.ip4 == NULL) - errx(1, "copy_addr4()"); - } -#ifdef INET6 - if (!STAILQ_EMPTY(&addr6)) { - j.ip6s = STAILQ_FIRST(&addr6)->count; - j.ip6 = copy_addr6(); - if (j.ip6s > 0 && j.ip6 == NULL) - errx(1, "copy_addr6()"); - } -#endif + errmsg[0] = 0; + set_param("errmsg", errmsg); if (Jflag) { fp = fopen(JidFile, "w"); if (fp == NULL) errx(1, "Could not create JidFile: %s", JidFile); } - i = jail(&j); - if (i == -1) - err(1, "syscall failed with"); + jid = jail_set(¶ms->name, 2 * nparams, jail_set_flags); + if (jid < 0) { + if (errmsg[0] != '\0') + errx(1, "%s", errmsg); + err(1, "jail_set"); + } if (iflag) { - printf("%d\n", i); + printf("%d\n", jid); fflush(stdout); } if (Jflag) { - if (fp != NULL) { + if (oldargs) fprintf(fp, "%d\t%s\t%s\t%s\t%s\n", - i, j.path, j.hostname, argv[2], argv[3]); - (void)fclose(fp); - } else { - errx(1, "Could not write JidFile: %s", JidFile); + jid, (char *)params[0].value.iov_base, + argv[1], argv[2], argv[3]); + else { + fprintf(fp, "%d", jid); + for (i = 0; i < argc; i++) + fprintf(fp, "\t%s", argv[i]); + fprintf(fp, "\n"); } + (void)fclose(fp); } if (securelevel > 0) { if (sysctlbyname("kern.securelevel", NULL, 0, &securelevel, sizeof(securelevel))) err(1, "Can not set securelevel to %d", securelevel); } + if (cmdarg < 0) + exit(0); if (username != NULL) { if (Uflag) GET_USER_INFO; @@ -272,158 +269,256 @@ if (p) setenv("TERM", p, 1); } - if (execv(argv[3], argv + 3) != 0) - err(1, "execv: %s", argv[3]); - exit(0); + execvp(argv[cmdarg], argv + cmdarg); + err(1, "execvp: %s", argv[cmdarg]); } static void -usage(void) +set_param(const char *name, char *value) { + struct param *param; + char *ep, *p; + size_t buflen, mlen; + int i, nval, mib[CTL_MAXNAME]; + char buf[MAXPATHLEN]; - (void)fprintf(stderr, "%s%s%s\n", - "usage: jail [-hi] [-n jailname] [-J jid_file] ", - "[-s securelevel] [-l -u username | -U username] ", - "path hostname [ip[,..]] command ..."); - exit(1); -} + static int paramlistsize; -static int -add_addresses(struct addrinfo *res0) -{ - int error; - struct addrinfo *res; - struct addr4entry *a4p; - struct sockaddr_in *sai; + /* Separate the name from the value, if not done already. */ + if (name == NULL) { + name = value; + if ((value = strchr(value, '='))) + *value++ = '\0'; + } + + /* Handle pseudo-parameters separately. */ + if (!strcmp(name, "ip4_hostname")) { + set_param_ip_hostname(value, AF_INET); + return; + } #ifdef INET6 - struct addr6entry *a6p; - struct sockaddr_in6 *sai6; + if (!strcmp(name, "ip6_hostname")) { + set_param_ip_hostname(value, AF_INET6); + return; + } #endif - int count; - error = 0; - for (res = res0; res && error == 0; res = res->ai_next) { - switch (res->ai_family) { - case AF_INET: - sai = (struct sockaddr_in *)(void *)res->ai_addr; - STAILQ_FOREACH(a4p, &addr4, addr4entries) { - if (bcmp(&sai->sin_addr, &a4p->ip4, - sizeof(struct in_addr)) == 0) { - err(1, "Ignoring duplicate IPv4 address."); - break; - } - } - a4p = (struct addr4entry *) malloc( - sizeof(struct addr4entry)); - if (a4p == NULL) { - error = 1; - break; - } - bzero(a4p, sizeof(struct addr4entry)); - bcopy(&sai->sin_addr, &a4p->ip4, - sizeof(struct in_addr)); - if (!STAILQ_EMPTY(&addr4)) - count = STAILQ_FIRST(&addr4)->count; - else - count = 0; - STAILQ_INSERT_TAIL(&addr4, a4p, addr4entries); - STAILQ_FIRST(&addr4)->count = count + 1; + /* Check for repeat parameters */ + for (i = 0; i < nparams; i++) + if (!strcmp(name, params[i].name.iov_base)) { + memcpy(params + i, params + i + 1, + (--nparams - i) * sizeof(struct param)); break; + } + + /* Make sure there is room for the new param record. */ + if (!nparams) { + paramlistsize = 32; + params = malloc(paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "malloc"); + } else if (nparams >= paramlistsize) { + paramlistsize *= 2; + params = realloc(params, paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "realloc"); + } + + /* Look up the paramter. */ + param = params + nparams++; + *(const void **)¶m->name.iov_base = name; + param->name.iov_len = strlen(name) + 1; + /* Trivial values - no value or errmsg. */ + if (value == NULL) { + param->value.iov_base = value; + param->value.iov_len = 0; + return; + } + if (!strcmp(name, "errmsg")) { + param->value.iov_base = value; + param->value.iov_len = ERRMSG_SIZE; + return; + } + mib[0] = 0; + mib[1] = 3; + snprintf(buf, sizeof(buf), SJPARAM ".%s", name); + mlen = sizeof(mib) - 2 * sizeof(int); + if (sysctl(mib, 2, mib + 2, &mlen, buf, strlen(buf)) < 0) + errx(1, "unknown parameter: %s", name); + mib[1] = 4; + buflen = sizeof(buf); + if (sysctl(mib, (mlen / sizeof(int)) + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.4.%s)", name); + /* + * See if this is an array type. + * Treat non-arrays as an array of one. + */ + p = strchr(buf + sizeof(int), '\0'); + nval = 1; + if (p - 2 >= buf && !strcmp(p - 2, ",a")) { + if (value[0] == '\0' || + (value[0] == '-' && value[1] == '\0')) { + param->value.iov_base = value; + param->value.iov_len = 0; + return; + } + p[-2] = 0; + for (p = strchr(value, ','); p; p = strchr(p + 1, ',')) { + *p = 0; + nval++; + } + } + + /* Set the values according to the parameter type. */ + switch (*(int *)buf & CTLTYPE) { + case CTLTYPE_INT: + case CTLTYPE_UINT: + param->value.iov_len = nval * sizeof(int); + break; + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + param->value.iov_len = nval * sizeof(long); + break; + case CTLTYPE_STRUCT: + if (!strcmp(buf + sizeof(int), "S,in_addr")) + param->value.iov_len = nval * sizeof(struct in_addr); #ifdef INET6 - case AF_INET6: - sai6 = (struct sockaddr_in6 *)(void *)res->ai_addr; - STAILQ_FOREACH(a6p, &addr6, addr6entries) { - if (bcmp(&sai6->sin6_addr, &a6p->ip6, - sizeof(struct in6_addr)) == 0) { - err(1, "Ignoring duplicate IPv6 address."); - break; - } + else if (!strcmp(buf + sizeof(int), "S,in6_addr")) + param->value.iov_len = nval * sizeof(struct in6_addr); +#endif + else + errx(1, "%s: unknown parameter structure (%s)", + name, buf + sizeof(int)); + break; + case CTLTYPE_STRING: + if (!strcmp(name, "path")) { + param->value.iov_base = malloc(MAXPATHLEN); + if (param->value.iov_base == NULL) + err(1, "malloc"); + if (realpath(value, param->value.iov_base) == NULL) + err(1, "%s: realpath(%s)", name, value); + if (chdir(param->value.iov_base) != 0) + err(1, "chdir: %s", + (char *)param->value.iov_base); + } else + param->value.iov_base = value; + param->value.iov_len = strlen(param->value.iov_base) + 1; + return; + default: + errx(1, "%s: unknown parameter type %d (%s)", + name, *(int *)buf, buf + sizeof(int)); + } + param->value.iov_base = malloc(param->value.iov_len); + for (i = 0; i < nval; i++) { + switch (*(int *)buf & CTLTYPE) { + case CTLTYPE_INT: + ((int *)param->value.iov_base)[i] = + strtol(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_UINT: + ((unsigned *)param->value.iov_base)[i] = + strtoul(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_LONG: + ((long *)param->value.iov_base)[i] = + strtol(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_ULONG: + ((unsigned long *)param->value.iov_base)[i] = + strtoul(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_STRUCT: + if (!strcmp(buf + sizeof(int), "S,in_addr")) { + if (inet_pton(AF_INET, value, + &((struct in_addr *) + param->value.iov_base)[i]) != 1) + errx(1, "%s: not an IPv4 address: %s", + name, value); } - a6p = (struct addr6entry *) malloc( - sizeof(struct addr6entry)); - if (a6p == NULL) { - error = 1; - break; +#ifdef INET6 + else if (!strcmp(buf + sizeof(int), "S,in6_addr")) { + if (inet_pton(AF_INET6, value, + &((struct in6_addr *) + param->value.iov_base)[i]) != 1) + errx(1, "%s: not an IPv6 address: %s", + name, value); } - bzero(a6p, sizeof(struct addr6entry)); - bcopy(&sai6->sin6_addr, &a6p->ip6, - sizeof(struct in6_addr)); - if (!STAILQ_EMPTY(&addr6)) - count = STAILQ_FIRST(&addr6)->count; - else - count = 0; - STAILQ_INSERT_TAIL(&addr6, a6p, addr6entries); - STAILQ_FIRST(&addr6)->count = count + 1; - break; #endif - default: - err(1, "Address family %d not supported. Ignoring.\n", - res->ai_family); - break; } + value = strchr(value, '\0') + 1; } - - return (error); } -static struct in_addr * -copy_addr4(void) +static void +set_param_ip_hostname(char *value, int family) { - size_t len; - struct in_addr *ip4s, *p, ia; - struct addr4entry *a4p; + struct addrinfo hints, *ai0, *ai; + char *avalue, *nextav; + socklen_t avlen; + int error; - if (STAILQ_EMPTY(&addr4)) - return NULL; + /* Look up the hostname in the specified address family. */ + memset(&hints, 0, sizeof(hints)); + hints.ai_family = family; + error = getaddrinfo(value, NULL, &hints, &ai0); + if (error != 0) + errx(1, "hostname %s: %s", value, gai_strerror(error)); - len = STAILQ_FIRST(&addr4)->count * sizeof(struct in_addr); - - ip4s = p = (struct in_addr *)malloc(len); - if (ip4s == NULL) - return (NULL); - - bzero(p, len); - - while (!STAILQ_EMPTY(&addr4)) { - a4p = STAILQ_FIRST(&addr4); - STAILQ_REMOVE_HEAD(&addr4, addr4entries); - ia.s_addr = a4p->ip4.s_addr; - bcopy(&ia, p, sizeof(struct in_addr)); - p++; - free(a4p); + /* Convert the addresses to ASCII so set_param can convert them back. */ + avlen = 0; + for (ai = ai0; ai; ai = ai->ai_next) + avlen++; + avlen *= +#ifdef INET6 + family == AF_INET6 ? INET6_ADDRSTRLEN : +#endif + INET_ADDRSTRLEN; + avalue = malloc(avlen); + if (avalue == NULL) + err(1, "malloc"); + avalue[0] = 0; + for (nextav = avalue, ai = ai0; ai; ai = ai->ai_next) { + if (inet_ntop(family, +#ifdef INET6 + family == AF_INET6 ? + (void *)&((struct sockaddr_in6 *)&ai->ai_addr)->sin6_addr : +#endif + (void *)&((struct sockaddr_in *)&ai->ai_addr)->sin_addr, + nextav, avlen - (nextav - avalue)) == NULL) + err(1, "inet_ntop"); + if (ai->ai_next) { + nextav = strchr(nextav, '\0'); + *nextav++ = ','; + } } - - return (ip4s); + set_param( +#ifdef INET6 + family == AF_INET6 ? "ip6.addr" : +#endif + "ip4.addr", avalue); } -#ifdef INET6 -static struct in6_addr * -copy_addr6(void) +static void +usage(void) { - size_t len; - struct in6_addr *ip6s, *p; - struct addr6entry *a6p; - if (STAILQ_EMPTY(&addr6)) - return NULL; - - len = STAILQ_FIRST(&addr6)->count * sizeof(struct in6_addr); - - ip6s = p = (struct in6_addr *)malloc(len); - if (ip6s == NULL) - return (NULL); - - bzero(p, len); - - while (!STAILQ_EMPTY(&addr6)) { - a6p = STAILQ_FIRST(&addr6); - STAILQ_REMOVE_HEAD(&addr6, addr6entries); - bcopy(&a6p->ip6, p, sizeof(struct in6_addr)); - p++; - free(a6p); - } - - return (ip6s); + (void)fprintf(stderr, + "usage: jail [-d] [-i] [-J jid_file] [-s securelevel]\n" + " [-l -u username | -U username]\n" + " [[-c | -o] param=value ... [command=command ...] |\n" + " path hostname ip command ...]\n" + " jail [-r jail]\n"); + exit(1); } -#endif - Index: usr.sbin/jail/jail.8 =================================================================== --- usr.sbin/jail/jail.8 (revision 191694) +++ usr.sbin/jail/jail.8 (working copy) @@ -1,5 +1,6 @@ .\" .\" Copyright (c) 2000, 2003 Robert N. M. Watson +.\" Copyright (c) 2008 James Gritton .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -33,49 +34,37 @@ .\" .\" $FreeBSD$ .\" -.Dd January 24, 2009 +.Dd April 30, 2009 .Dt JAIL 8 .Os .Sh NAME .Nm jail -.Nd "imprison process and its descendants" +.Nd "create or modify a system jail" .Sh SYNOPSIS .Nm -.Op Fl hi -.Op Fl n Ar jailname +.Op Fl di .Op Fl J Ar jid_file .Op Fl s Ar securelevel .Op Fl l u Ar username | Fl U Ar username -.Ar path hostname [ip[,..]] command ... +.Op Fl c | o +.Op Ar parameter=value ... | path hostname ip command ... +.Br +.Nm +.Op Fl r Ar jail .Sh DESCRIPTION The .Nm -utility imprisons a process and all future descendants. +utility creates a new jail or modifies an existing jail, optionally +imprisoning the current process (and future descendants) inside it. .Pp The options are as follows: -.Bl -tag -width ".Fl u Ar username" -.It Fl h -Resolve -.Va hostname -and add all IP addresses returned by the resolver -to the list of -.Va ip-addresses -for this prison. -This may affect default address selection for outgoing IPv4 connections -of prisons. -The address first returned by the resolver for each address family -will be used as primary address. -See -.Va ip-addresses -further down for details. +.Bl -tag -width indent +.It Fl d +Allow making changes to a +.Va +dying jail. .It Fl i Output the jail identifier of the newly created jail. -.It Fl n Ar jailname -Assign and administrative name to the jail that can be used for management -or auditing purposes. -The system will -.Sy not enforce -the name to be unique. .It Fl J Ar jid_file Write a .Ar jid_file @@ -100,7 +89,10 @@ .It Fl s Ar securelevel Sets the .Va kern.securelevel -sysctl variable to the specified value inside the newly created jail. +MIB entry to the specified value inside the newly created jail. +This is equivalent to setting the jail's +.Va securelevel +parameter. .It Fl u Ar username The user name from host environment as whom the .Ar command @@ -109,20 +101,156 @@ The user name from jailed environment as whom the .Ar command should run. -.It Ar path +.It Fl c +Create a new jail, but do not modify an existing one. +Default behavior is to allow modification if a +.Va jid +or +.Va name +parameter refers to an existing jail. +.It Fl o +Only modify an existing jail, but do not create one. +One of the +.Va jid +or +.Va name +parameters must exist and refer to an existing jail. +.It Fl r +Remove the +.Ar jail +specified by jid or name. +All jailed processes are killed. +.El +.Pp +.Ar Parameters +are listed in +.Dq name=value +form, following the options. +Some parameters are boolean, and do not have a value but are set by the +name alone with or without a +.Dq no +prefix, e.g. +.Va persist +or +.Va nopersist . +Any parameters not set will be given default values, generally based on the +current environment. +.Pp +The pseudo-parameter +.Va command +specifies that the current process should enter the new (or modified) jail, +and run the specified command. +It must be the last parameter specified, because it includes not only +the value following the +.Sq = +sign, but also passes the rest of the arguments to the command. +.Pp +Instead of supplying named +.Ar parameters , +four fixed parameters may be supplied in order on the command line: +.Ar path , +.Ar hostname , +.Ar ip , +and +.Ar command . +As the +.Va jid +and +.Va name +parameters aren't in this list, this mode will always create a new jail, and +the +.Fl c +and +.Fl o +options don't apply. +.Pp +Jails have a set a core parameters, and modules can add their own jail +parameters. +The current set of available parameters can be retrieved via +.Dq Nm sysctl Fl d Va security.jail.param . +Some of the notable core parameters include: +.Bl -tag -width indent +.It Va jid +The jail identifier. +This will be assigned automatically to a new jail (or can be explicitly +set), and can be used to identify the jail for later modification, or +for such commands as +.Xr jls 8 +or +.Xr jexec 8 . +.It Va name +The jail name. +This is an arbitrary string that identifies a jail. +Like the +.Va jid , +it can be passed to later +.Nm +commands, or to +.Xr jls 8 +or +.Xr jexec 8 . +If no +.Va name +is supplied, a default is assumed that is the same as the +.Va jid . +.It Va path Directory which is to be the root of the prison. -.It Ar hostname -Hostname of the prison. -.It Ar ip-addresses -None, one or more IPv4 and IPv6 addresses assigned to the prison. -The first address of each address family that was assigned to the jail will -be used as the source address in case source address selection on unbound -sockets cannot find a better match. +The +.Va command +(if any) is run from this directory, as are commands from +.Xr jexec 8 . +.It Va ip4.addr +A comma-separated list of IPv4 addresses assigned to the prison. +If this is set, the jail is restricted to using only these address. +Any attempts to use other addresses fail, and attempts to use wildcard +addresses silently use the jailed address instead. +For IPv4 the first address given will be kept used as the source address +in case source address selection on unbound sockets cannot find a better +match. It is only possible to start multiple jails with the same IP address, if none of the jails has more than this single overlapping IP address -assigned to itself for the address family in question. -.It Ar command -Pathname of the program which is to be executed. +assigned to itself. +.Pp +A list of zero elements (an empty string) will stop the jail from using IPv4 +entirely; setting the boolean parameter +.Ar noip4 +will not restrict the jail at all. +.It Va ip6.addr +A list of IPv6 addresses assigned to the prison, the counterpart to +.Ar ip4.addr +above. +.It Va host.hostname +Hostname of the prison. +If not specified, a jail will use the system hostname. +.It Va ip4_hostname +.It Va ip6_hostname +These psuedo-parameters actually set the jail's +.Va ip4 +and +.Va ip6 +parameters, but will get those addresses by resolving the supplied hostname. +.It Va securelevel +The value of the jail's +.Va kern.securelevel +sysctl. +A jail never has a lower securelevel than the default system, but by +setting this parameter it may have a higher one. +If the system securelevel is changed, any jail securelevels will be at +least as secure. +.It Va persist +Setting this boolean parameter allows a jail to exist without any +processes. +Normally, a jail is destroyed as its last process exits. +.It Va command +The command to run after creating or modifying the jail. +This command is run inside the jail, under the +.Va path +directory. +A new jail must have either the +.Va persist +or +.Va command +parameter set. .El .Pp Jails are typically set up using one of two philosophies: either to @@ -142,10 +270,6 @@ This manual page documents the configuration steps necessary to support either of these steps, although the configuration steps may be refined based on local requirements. -.Pp -Please see the -.Xr jail 2 -man page for further details. .Sh EXAMPLES .Ss "Setting up a Jail Directory Tree" To set up a jail directory tree containing an entire @@ -605,7 +729,7 @@ a jail. This functionality is disabled by default, but can be enabled by setting this MIB entry to 1. -.It Va security.jail.jail_max_af_ips +.It Va security.jail.max_af_ips This MIB entry determines how may address per address family a prison may have. The default is 255. .El @@ -641,7 +765,7 @@ .Xr ps 1 , .Xr quota 1 , .Xr chroot 2 , -.Xr jail 2 , +.Xr jail_set 2 , .Xr jail_attach 2 , .Xr procfs 5 , .Xr rc.conf 5 , @@ -665,6 +789,8 @@ .Nm utility appeared in .Fx 4.0 . +Extensible jail parameters were introduced in +.Fx 8.0 . .Sh AUTHORS .An -nosplit The jail feature was written by @@ -683,6 +809,9 @@ originally done by .An Pawel Jakub Dawidek for IPv4. +.Pp +.An James Gritton +added the extensible jail parameters. .Sh BUGS Jail currently lacks the ability to allow access to specific jail information via Index: sys/sys/jail.h =================================================================== --- sys/sys/jail.h (revision 191694) +++ sys/sys/jail.h (working copy) @@ -84,19 +84,11 @@ struct in6_addr pr_ip6[]; #endif }; -#define XPRISON_VERSION 3 +#define XPRISON_VERSION 3 -static const struct prison_state { - int pr_state; - const char * state_name; -} prison_states[] = { -#define PRISON_STATE_INVALID 0 - { PRISON_STATE_INVALID, "INVALID" }, -#define PRISON_STATE_ALIVE 1 - { PRISON_STATE_ALIVE, "ALIVE" }, -#define PRISON_STATE_DYING 2 - { PRISON_STATE_DYING, "DYING" }, -}; +#define PRISON_STATE_INVALID 0 +#define PRISON_STATE_ALIVE 1 +#define PRISON_STATE_DYING 2 /* * Flags for jail_set and jail_get. --------------080804010107070301060002-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 03:19: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 C9A5E106564A; Mon, 4 May 2009 03:19:41 +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 DB9868FC13; Mon, 4 May 2009 03:19:40 +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 241860680; Mon, 04 May 2009 06:19:39 +0300 Message-ID: <49FE5EC8.3040205@FreeBSD.org> Date: Mon, 04 May 2009 06:19:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Nate Lawson References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> In-Reply-To: <49FE29A4.30507@root.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@FreeBSD.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 03:19:42 -0000 Nate Lawson wrote: > The time may have come to disable p4tcc and throttling by default, as > long as it's easy for a user to enable them again. Perhaps just a change > to boot/default/device.hints? They still could be effective for old P4 series which had no C1E/C2 idle states support yet. But probably their power consumption is not so interesting area now. > The default settings in rc.conf should allow the lowest Cx setting > available to be used. Perhaps that changed? Really, we want C3+ to be > enabled by default without the user doing anything. Present defaults are to use C1. Probably we can allow C2 use more or less safely. Due to default LAPIC timer problems, enabling C3+ by default will make system dead by default. > Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. Without using C3+ it is not so important. I haven't seen any power difference. C1/C2 have practically zero exit latency, while power consumed by interrupt handler itself is miserable. > The real solution for C3 (and C4, etc.) is to implement tickless > scheduling and to fix the current dependence on LAPIC for timer > interrupts. Hopefully someone will do that soon. With that change, this > change isn't needed. System will always have tons of waiting callouts and timeouts to be handled. So timer will be always needed. Working timer. >> 4. HDA modem >> I was surprised, but integrated HDA modem consumed about 1W of power >> even when not used. I have used the most radical solution - removed it >> mechanically from socket. Case surface in that area become much cooler. > > Most modems support the ACPI Dx states, where D3 = device powered off. > I'd think the PCI "power no driver option" would disable the soft modem > since it's unlikely you have a driver for it. Modem share HDA bus/controller with sound. So PCI D3 will kill sound also, that is not an option. snd_hda driver itself puts all non-audio codecs into the HDA D3 state, but in my case it was not effective. >> 6. HDD >> First common recommendation is use tmpfs for temporary files. RAM is >> cheap, fast and anyway with you. >> Also you may try to setup automatic idle drive spin-down, but if it is >> the only system drive you should be careful, as every spin-up reduces >> drive's life time. > > Did you increase the fsflush delay also? I don't, but how long can it delay requests? Several minutes? Hour? Then there is high probability of data loss. Actually I have tried to reduce number of idle disk write activity, but I haven't very succeeded. Even in my quite simple icewm X environment something was persistently writing something every several minutes. I have found and disabled some activity sources, but it was not enough. What would happen in some complicated KDE/Gnome environment I am just afraid to think. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 4 03:45: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 EE595106566B; Mon, 4 May 2009 03:45: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 0B5428FC15; Mon, 4 May 2009 03:45: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 241861314; Mon, 04 May 2009 06:45:12 +0300 Message-ID: <49FE64C5.2020507@FreeBSD.org> Date: Mon, 04 May 2009 06:45:09 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Adam McDougall References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> In-Reply-To: <20090504011421.GI6901@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 03:45:15 -0000 Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Great list! May I suggest screen brightness and DPMS as another tool > to save power, I've measured a 5W difference from the screen draw. > Keeping the brightness as low as tolerable helps considerably, but > also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to > turn off the screen after 2 minutes helps when the laptop isn't being > used every second. May need this in xorg.conf: > Option "dpms" Yes, backlight is also important. But there is not so much things could be done. When I am leaving system for some time, I can just close the lid, if not put system into S3 state, which require very small power (at least I was unable to really measure it without all-day-long testing). Thanks to jkim@ we have more or less working S3 state for amd64 now. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 4 05:22: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 19BAF1065670 for ; Mon, 4 May 2009 05:22:37 +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 B9B478FC13 for ; Mon, 4 May 2009 05:22:36 +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:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:Sender; b=J2GjiZPtnOEfCyJxOSEyTnYxVAjx2sZS3kaTSqxcHJtg2m5rND2K2TsmOgGnPkyTTt98j1QwSFvY9xiNdItH+74QrG/IHEJwgArLZwCarTC986g7iEoPFI/VIJxhGZu1ohYQ8j3H5SL0sZQ+DBA5zqzo0vziIB6yzBbo3sEx6NM=; Received: from amnesiac.at.no.dns (ppp85-141-64-167.pppoe.mtu-net.ru [85.141.64.167]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M0qdO-000G4N-Vf for freebsd-current@freebsd.org; Mon, 04 May 2009 09:22:35 +0400 Date: Mon, 4 May 2009 09:22:32 +0400 From: Eygene Ryabinkin To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: rea-fbsd@codelabs.ru Subject: Patch for "device_attach: estX attach returned 6" on half of the cores 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: Mon, 04 May 2009 05:22:37 -0000 Good day. Recently I had filed a PR, http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 that should heal the situation when estX isn't attached properly on the half of processor cores (the odd ones). I am seeing this only on Asus MBs, but this could show up on other hardware as well. If anyone sees such symptoms, I encourage them to test the patch. The patch itself contained in the PR, but for ease I had put it there, http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff and will sync PR's one and this one in the case of any changes. -- 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 Mon May 4 06:25: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 44699106564A; Mon, 4 May 2009 06:25:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EEA238FC18; Mon, 4 May 2009 06:25:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 96DDA78D0B; Mon, 4 May 2009 06:25:20 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n446PKQI004425; Mon, 4 May 2009 06:25:20 GMT (envelope-from phk@critter.freebsd.dk) To: Jamie Gritton From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 03 May 2009 20:31:35 CST." <49FE5387.3020503@FreeBSD.org> Date: Mon, 04 May 2009 06:25:20 +0000 Message-ID: <4424.1241418320@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: virtualization@FreeBSD.org, jail@FreeBSD.org, current@FreeBSD.org Subject: Re: New jail framework - the userland side X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 06:25:22 -0000 In message <49FE5387.3020503@FreeBSD.org>, Jamie Gritton writes: >Hi all. I recently added some new jail-related system calls to extend >the current jail system with an nmount-inspired name=value interface. I think this is a great move in the right direction, my only concern is that we should try to share as much of the string-munging code between the nmount and jail implementations as possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon May 4 06:28: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 87424106566C for ; Mon, 4 May 2009 06:28:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8868FC12 for ; Mon, 4 May 2009 06:28:32 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n446QP3M057279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 02:26:25 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: rea-fbsd@codelabs.ru In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HOwaKxwwGflrOuQ2jUvM" Organization: FreeBSD Date: Mon, 04 May 2009 01:26:12 -0500 Message-Id: <1241418372.78715.1.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 06:28:35 -0000 --=-HOwaKxwwGflrOuQ2jUvM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 09:22 +0400, Eygene Ryabinkin wrote: > Good day. >=20 > Recently I had filed a PR, > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D134192 > that should heal the situation when estX isn't attached properly > on the half of processor cores (the odd ones). I am seeing this > only on Asus MBs, but this could show up on other hardware as well. >=20 > If anyone sees such symptoms, I encourage them to test the patch. > The patch itself contained in the PR, but for ease I had put it > there, > http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.di= ff > and will sync PR's one and this one in the case of any changes. I'm seeing this on both an ASUS and an Intel board that I have. Both have core2duo E7400's in them. I have applied this patch to the Intel board so far, but unfortunately now both cores fail equally. cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2306004a23 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2306004a23 device_attach: est1 attach returned 6 p4tcc1: on cpu1 robert. --=20 Robert Noland FreeBSD --=-HOwaKxwwGflrOuQ2jUvM 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) iEYEABECAAYFAkn+ioQACgkQM4TrQ4qfRONHhgCeIA/rYGolahtKq9bwEzWK/OBx uOIAnj6gFWYy8UBpSRoc1N7pW6L2TbHC =D9mS -----END PGP SIGNATURE----- --=-HOwaKxwwGflrOuQ2jUvM-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 06:34: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 DBCD51065673; Mon, 4 May 2009 06:34: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 8A75E8FC14; Mon, 4 May 2009 06:34: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=hvX47kS6qiNbvqGCtap0IFb6UKa7VQ1TMtOL0WHgve/4zaexBRTuoNphHKyu4bHW80vZtvuNB7DVvi799ucvcLPeOpoYa6gQ5egTkOohwDlEFYZAGaXGKo2j+RAuPAJWGGkkVC1qh3hJgOy8Qreyw803r8ujRt8De/W+YrW6n0I=; Received: from amnesiac.at.no.dns (ppp85-141-64-167.pppoe.mtu-net.ru [85.141.64.167]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M0rlI-000MzV-9r; Mon, 04 May 2009 10:34:48 +0400 Date: Mon, 4 May 2009 10:34:45 +0400 From: Eygene Ryabinkin To: Robert Noland Message-ID: References: <1241418372.78715.1.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1241418372.78715.1.camel@balrog.2hip.net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores 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: Mon, 04 May 2009 06:34:50 -0000 Robert, good day. Mon, May 04, 2009 at 01:26:12AM -0500, Robert Noland wrote: > On Mon, 2009-05-04 at 09:22 +0400, Eygene Ryabinkin wrote: > > Good day. > > > > Recently I had filed a PR, > > http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 > > that should heal the situation when estX isn't attached properly > > on the half of processor cores (the odd ones). I am seeing this > > only on Asus MBs, but this could show up on other hardware as well. > > > > If anyone sees such symptoms, I encourage them to test the patch. > > The patch itself contained in the PR, but for ease I had put it > > there, > > http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > > and will sync PR's one and this one in the case of any changes. > > I'm seeing this on both an ASUS and an Intel board that I have. Both > have core2duo E7400's in them. I have applied this patch to the Intel > board so far, but unfortunately now both cores fail equally. > > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6164a2306004a23 > device_attach: est0 attach returned 6 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means that most likely you don't have _PSS entries in your DSDT table at all. The patch helps in the case when some processor names are aliased _and_ half of processors are attached properly even without this patch. One could check if the patch will help by examining the output of 'apicdump -d' and looking for the Alias () directives for the Processor objects. Here's what I have for my laptop: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) } Scope (_PR) { Processor (P002, 0x02, 0x00000810, 0x06) {} Alias (P002, CPU2) } ----- So in this case we essentially have 4 Processor objects under _PR, but only two objects are real ones and only they should be attached. For the completeness, could you, please, show the output of 'acpidump -dt 2>&1' for both of your machines? Thanks! -- 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 Mon May 4 07:24: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 EB821106566B; Mon, 4 May 2009 07:24:05 +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 0449E8FC17; Mon, 4 May 2009 07:24:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=z_VEKX-DvsiYp74B3mQA:9 a=JUA1JGd_aKKhrkhcxeqo9KW786QA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 894745855; Mon, 04 May 2009 09:24:03 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 4 May 2009 09:26:37 +0200 User-Agent: KMail/1.9.7 References: <49FE1826.4060000@FreeBSD.org> In-Reply-To: <49FE1826.4060000@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905040926.38337.hselasky@c2i.net> Cc: Alexander Motin , FreeBSD acpi , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 07:24:06 -0000 > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. The new USB stack should turn off USB HC's automatically when not in use. At least the schedules will get disabled. Did you do any research on this? --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 4 07:50: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 91BB91065676; Mon, 4 May 2009 07:50:24 +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 9E7858FC14; Mon, 4 May 2009 07:50:23 +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 241870610; Mon, 04 May 2009 10:50:22 +0300 Message-ID: <49FE9E3B.1050509@FreeBSD.org> Date: Mon, 04 May 2009 10:50:19 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Hans Petter Selasky References: <49FE1826.4060000@FreeBSD.org> <200905040926.38337.hselasky@c2i.net> In-Reply-To: <200905040926.38337.hselasky@c2i.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 07:50:25 -0000 Hans Petter Selasky wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > The new USB stack should turn off USB HC's automatically when not in use. At > least the schedules will get disabled. Did you do any research on this? Sorry, I really was testing it only with previous USB stack. Now I can acknowledge, that new ehci module loading adds only 0.2W for me by default and almost nothing if I power down built-in USB2 web cam connected to it using `usbconfig -u 5 -a 2 power_off`. Great! Thanks! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 4 09:17: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 7D25A1065676; Mon, 4 May 2009 09:17:46 +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 537CC8FC1A; Mon, 4 May 2009 09:17:46 +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 n449HgBN092779; Mon, 4 May 2009 05:17:42 -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 n449Hgsq069958; Mon, 4 May 2009 05:17:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7D1BC7302F; Mon, 4 May 2009 05:17:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090504091741.7D1BC7302F@freebsd-current.sentex.ca> Date: Mon, 4 May 2009 05:17:41 -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: Mon, 04 May 2009 09:17:47 -0000 TB --- 2009-05-04 07:37:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-04 07:37:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-04 07:37:33 - cleaning the object tree TB --- 2009-05-04 07:37:55 - cvsupping the source tree TB --- 2009-05-04 07:37:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-04 07:38:07 - building world TB --- 2009-05-04 07:38:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-04 07:38:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-04 07:38:07 - TARGET=pc98 TB --- 2009-05-04 07:38:07 - TARGET_ARCH=i386 TB --- 2009-05-04 07:38:07 - TZ=UTC TB --- 2009-05-04 07:38:07 - __MAKE_CONF=/dev/null TB --- 2009-05-04 07:38:07 - cd /src TB --- 2009-05-04 07:38:07 - /usr/bin/make -B buildworld >>> World build started on Mon May 4 07:38:09 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 Mon May 4 09:01:09 UTC 2009 TB --- 2009-05-04 09:01:09 - generating LINT kernel config TB --- 2009-05-04 09:01:09 - cd /src/sys/pc98/conf TB --- 2009-05-04 09:01:09 - /usr/bin/make -B LINT TB --- 2009-05-04 09:01:09 - building LINT kernel TB --- 2009-05-04 09:01:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-04 09:01:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-04 09:01:09 - TARGET=pc98 TB --- 2009-05-04 09:01:09 - TARGET_ARCH=i386 TB --- 2009-05-04 09:01:09 - TZ=UTC TB --- 2009-05-04 09:01:09 - __MAKE_CONF=/dev/null TB --- 2009-05-04 09:01:09 - cd /src TB --- 2009-05-04 09:01:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 4 09:01:09 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x109a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** 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-04 09:17:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-04 09:17:41 - ERROR: failed to build lint kernel TB --- 2009-05-04 09:17:41 - 4702.03 user 452.77 system 6008.14 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon May 4 09:28: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 33525106564A for ; Mon, 4 May 2009 09:28:53 +0000 (UTC) (envelope-from onemda@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 B1EF58FC18 for ; Mon, 4 May 2009 09:28:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so3494404bwz.43 for ; Mon, 04 May 2009 02:28:51 -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=1iK7pgvfNWWTSn8Wj8mNtsCLC9tQ+N0EI6k1VHdR5/E=; b=OfPZrsIhQBAA1p95Bh4lq4R6htjXxsbSBW7jEpPiT9Eb1gzZjTte1MOGOqqntADK9+ aFVE/QLe3IePgBP//zUdmw2KDsdLnR4rMezH1oPEK0J/qEoX18vFGp4ZVXons6QRWpJg uwv1XP0C8Xj9RuuDINq0mN+eR7ubNLdDPbARI= 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=hZxOk1KmKiF2Y9LVv6oWelBEZSeA/uhZdvvLfsEQi0Wt7xQgccdIZgANkH6XDmNzx/ JwtsZ3rtF8zTxQ7z/YZEYv8oD/9PitO1YfpjCuzhm52LRkc7VBAWXFF4aLMN89J4jW/W 1efkWhlnUt8bGjisJ6uzy3PGq48AIluehFr84= MIME-Version: 1.0 Received: by 10.239.155.13 with SMTP id g13mr285664hbc.7.1241429331553; Mon, 04 May 2009 02:28:51 -0700 (PDT) In-Reply-To: <20090503224205.GB1414@hades.panopticon> References: <20090503224205.GB1414@hades.panopticon> Date: Mon, 4 May 2009 11:28:51 +0200 Message-ID: <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> From: "Paul B. Mahol" To: Dmitry Marakasov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: geom_part X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 09:28:53 -0000 On 5/4/09, Dmitry Marakasov wrote: > Hi! > > I've upgraded one of my boxes to current recently and ran into some > problems with new geom_part. > > First, it's impossible to edit bsd label online. > > # bsdlabel -e /dev/ad8 > [edit] > bsdlabel: Class not found > re-edit the label? [y]: > bsdlabel, fdisk and others no longer works correctly, use gpart(8) instead. If you really want to still use bsdlabel and fdisk you need custom kernel without geom_part* note that geom_bsd and geom_mbr are going to be removed soon from CURRENT(because they are not used anymore). > Setting sysctl kern.geom.debugflags to 16 helps. > > Next, it's no longer possible to use nested configuration. If I add > bsd label to, say, /dev/ad8f, no subpartitions (ad8fa, ad8fd ...) > will be shown. They pop up after loading geom_bsd. > > Finally, seems like bsd label support is broken: > > # bsdlabel /dev/ad8 > # /dev/ad8: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2097152 0 4.2BSD 2048 16384 28528 > b: 20971520 2097152 swap > c: 390721968 0 unused 0 0 # "raw" part, don't > edit > d: 20971520 23068672 4.2BSD 2048 16384 28528 > e: 2097152 44040192 4.2BSD 2048 16384 28528 > f: 20971520 46137344 4.2BSD 2048 16384 28528 > g: 41943040 67108864 unused 0 0 > h: 281670064 109051904 unused 0 0 > > # ls /dev/ad8* > /dev/ad8 /dev/ad8b /dev/ad8e /dev/ad8g > /dev/ad8a /dev/ad8d /dev/ad8f > > No h partition! > > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D > amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru > _______________________________________________ > 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" > -- Paul From owner-freebsd-current@FreeBSD.ORG Mon May 4 09:40: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 5FEC01065673; Mon, 4 May 2009 09:40:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 615A08FC26; Mon, 4 May 2009 09:40:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fk-out-0910.google.com with SMTP id f33so1839206fkf.11 for ; Mon, 04 May 2009 02:40:35 -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=lkelNI0vwYVPkC3u2T27PnQyiTOKSBwvH2qmXEgihx8=; b=hoAL8tMPe2D79pmmAmzJU2vu8w1o9UXfSWtsbwQIJnPGhvDER7eNxR9+ThYXMgM/yv PFlqbp2hf7AN/rpWjY64GC5d1p9Ij/nSbkN936jczDLe39dt1FqsiAQo+zg0XuXbfz7L YeANJkYozvZDJNvOXq2dAQKNJzJHePwr4xLdY= 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=Lweg7IHS4jYPrURiL+GtHK5erc8z6oX5Qs4bQvZZsetMOYVZ93IgCP91A8Uh7qTXLW 7bkzDzVfjsULAFCfduq9twPLca9VUoFykyKgtR0feZW2I0ACoD27YF3MEvZ5t7ixJtGS zg1SRzU5nhTeL1E0Y21AHG7FRguJpdDzC8zSo= MIME-Version: 1.0 Received: by 10.239.132.134 with SMTP id 6mr291132hbr.157.1241430035330; Mon, 04 May 2009 02:40:35 -0700 (PDT) In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Date: Mon, 4 May 2009 11:40:35 +0200 Message-ID: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> From: "Paul B. Mahol" To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 09:40:43 -0000 On 5/4/09, Alexander Motin wrote: > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. Unloading modules doesnt put them back into into D3 state. You are forced to load some another module again to put wanted device into D3 state. -- Paul From owner-freebsd-current@FreeBSD.ORG Mon May 4 09:51: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 A9C91106567F; Mon, 4 May 2009 09:51:10 +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 B7F5F8FC14; Mon, 4 May 2009 09:51:09 +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 241877347; Mon, 04 May 2009 12:51:08 +0300 Message-ID: <49FEBA89.4040609@FreeBSD.org> Date: Mon, 04 May 2009 12:51:05 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 09:51:11 -0000 Paul B. Mahol wrote: > On 5/4/09, Alexander Motin wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > Unloading modules doesnt put them back into into D3 state. > You are forced to load some another module again to put wanted device > into D3 state. Yes. Resume also does not powers down unowned devices. Would be good to fix that also. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 4 10:00: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 BA14F1065672 for ; Mon, 4 May 2009 10:00:40 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 62FA38FC16 for ; Mon, 4 May 2009 10:00:40 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 619305C06F for ; Mon, 4 May 2009 18:00:39 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0B95855D1694 for ; Mon, 4 May 2009 18:00:39 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id g7-xgriJT3PG for ; Mon, 4 May 2009 17:59:45 +0800 (CST) Received: from qld630 (unknown [219.142.100.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 17FAD55D168E for ; Mon, 4 May 2009 17:59:40 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:content-transfer-encoding:message-id:user-agent; b=g8bdArX6+Bd++/lbOkCLl10B0Ebkdmgt2pDRJPHKaKS5gC5Ur8kjxUgjBW9WtRqS4 8TXc9NcLZvojyu7NxuxNw== Date: Mon, 04 May 2009 17:59:33 +0800 To: freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (Win32) Subject: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 10:00:41 -0000 Hi, all I have a dell optiplex 745 box with a dell usb mouse. I update system from 7.1 to current today, after that the usb mouse could not recongnize. I got some message from dmesg like below: uhci_interrupt: host system error uhci_interrupt: host system error usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! my current is up to date current, [root@currentpark] ~# sysctl kern.osreldate kern.osreldate: 800085 [root@currentpark] ~# uname -a FreeBSD currentpark.intra.umessage.com.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon May 4 17:46:54 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/GENERIC amd64 Is this a usb2.0's bug or I should configure something else? -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Mon May 4 10:35: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 2D9BD1065675 for ; Mon, 4 May 2009 10:35:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id B98188FC1A for ; Mon, 4 May 2009 10:35:56 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=PWmMXO6ZDkO6XY-nw4sA:9 a=BaXrDfA7FkOEX5JkKn0TmXXfmFAA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1239324530; Mon, 04 May 2009 12:35:56 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 4 May 2009 12:38:29 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041238.30304.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 10:35:58 -0000 On Monday 04 May 2009, Chao Shin wrote: > Hi, all > > I have a dell optiplex 745 box with a dell usb mouse. I update system from > 7.1 to current today, > after that the usb mouse could not recongnize. I got some message from > dmesg like below: > > > Is this a usb2.0's bug or I should configure something else? Can you send complete dmesg ? --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 4 11:28: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 DA0EE106564A; Mon, 4 May 2009 11:28:30 +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 416D18FC20; Mon, 4 May 2009 11:28:30 +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=quhd1/QuAZZEWbFBJjx5IHZBlNB03/NoiGdxwmcxsRfVGFQ7+0NZgD9iPc+0c1nh/+ddS7HfW6agvFSwflsUJde8KPco+eSS7wuFIFLCBsG9mG9SVuQ9tavFV4RkTKjseQDr663EEjt6imgmDrmbD/GFSfk48YAANluDqHo/Or0=; Received: from amnesiac.at.no.dns (ppp85-141-64-167.pppoe.mtu-net.ru [85.141.64.167]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M0wLU-000PGL-SV; Mon, 04 May 2009 15:28:29 +0400 Date: Mon, 4 May 2009 15:28:26 +0400 From: Eygene Ryabinkin To: Robert Noland Message-ID: References: <1241418372.78715.1.camel@balrog.2hip.net> <1241419338.78715.8.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <1241419338.78715.8.camel@balrog.2hip.net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores 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: Mon, 04 May 2009 11:28:31 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Robert, Mon, May 04, 2009 at 01:42:18AM -0500, Robert Noland wrote: > Without this patch, cpu0 does attach correctly. On the Intel MB? If yes and you'll be able to to some debugging, please, try the attached patch and send the output of 'dmesg', 'sysctl dev.cpu', 'sysctl dev.cpufreq' and 'sysctl dev.est'. > > One could check if the patch will help by examining the output of > > 'apicdump -d' and looking for the Alias () directives for the Processor > > objects. Here's what I have for my laptop: > > ----- > > Scope (_PR) > > { > > Processor (P001, 0x01, 0x00000810, 0x06) {} > > Alias (P001, CPU1) > > } > > > > Scope (_PR) > > { > > Processor (P002, 0x02, 0x00000810, 0x06) {} > > Alias (P002, CPU2) > > } > > ----- > > So in this case we essentially have 4 Processor objects under _PR, > > but only two objects are real ones and only they should be attached. > > > > For the completeness, could you, please, show the output of 'acpidump > > -dt 2>&1' for both of your machines? > > Attached. The Asus does appear to use aliases as you described. Then you should have est attached to cpu0/cpu2 and rejected on cpu1/cpu3, aren't you? The output of 'sysctl dev.cpu', 'sysctl dev.est' and 'sysctl dev.cpufreq' will be also helpful. Will you be able to try my original patch on the Asus system? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="acpi_perf-provide-debugging-statements.diff" Content-Transfer-Encoding: quoted-printable =46rom 11e32a567a0e92a26d2226c8ca28478ca8f1135b Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Mon, 4 May 2009 15:10:03 +0400 Subject: [PATCH] ACPI perf: provide debugging statements to diagnose attach= ment problems Signed-off-by: Eygene Ryabinkin --- sys/dev/acpica/acpi.c | 1 + sys/dev/acpica/acpi_cpu.c | 2 ++ sys/dev/acpica/acpi_perf.c | 28 ++++++++++++++++++++++++---- 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index d79b413..669de02 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -1742,6 +1742,7 @@ acpi_probe_child(ACPI_HANDLE handle, UINT32 level, vo= id *context, void **status) * At least \_SB and \_TZ are detected as devices (ACPI-CA bug?) */ handle_str =3D acpi_name(handle); + device_printf(bus, "Working with child '%s'\n", handle_str); for (search =3D scopes; *search !=3D NULL; search++) { if (strcmp(handle_str, *search) =3D=3D 0) break; diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c index a65faee..283a8bb 100644 --- a/sys/dev/acpica/acpi_cpu.c +++ b/sys/dev/acpica/acpi_cpu.c @@ -214,6 +214,7 @@ acpi_cpu_probe(device_t dev) return (ENXIO); =20 handle =3D acpi_get_handle(dev); + device_printf(dev, "Going to probe CPU %s\n", acpi_name(handle)); if (cpu_softc =3D=3D NULL) cpu_softc =3D malloc(sizeof(struct acpi_cpu_softc *) * (mp_maxid + 1), M_TEMP /* XXX */, M_WAITOK | M_ZERO); @@ -240,6 +241,7 @@ acpi_cpu_probe(device_t dev) * in their Processor object as the ProcId values in the MADT. */ acpi_id =3D obj->Processor.ProcId; + device_printf(dev, "ACPI ProcId =3D %d\n", acpi_id); AcpiOsFree(obj); if (acpi_pcpu_get_id(device_get_unit(dev), &acpi_id, &cpu_id) !=3D 0) return (ENXIO); diff --git a/sys/dev/acpica/acpi_perf.c b/sys/dev/acpica/acpi_perf.c index e517ad3..87860a8 100644 --- a/sys/dev/acpica/acpi_perf.c +++ b/sys/dev/acpica/acpi_perf.c @@ -139,6 +139,7 @@ MALLOC_DEFINE(M_ACPIPERF, "acpi_perf", "ACPI Performanc= e states"); static void acpi_perf_identify(driver_t *driver, device_t parent) { + ACPI_STATUS status; ACPI_HANDLE handle; device_t dev; =20 @@ -150,8 +151,14 @@ acpi_perf_identify(driver_t *driver, device_t parent) handle =3D acpi_get_handle(parent); if (handle =3D=3D NULL) return; - if (ACPI_FAILURE(AcpiEvaluateObject(handle, "_PSS", NULL, NULL))) + if (ACPI_FAILURE(status =3D + AcpiEvaluateObject(handle, "_PSS", NULL, NULL))) { + device_printf(parent, + "%s: ACPI_FAILURE(evaluate _PSS for %s): %s\n", + __func__, acpi_name(handle), AcpiFormatException(status)); + return; + } =20 /* * Add a child to every CPU that has the right methods. In future @@ -168,6 +175,7 @@ acpi_perf_identify(driver_t *driver, device_t parent) static int acpi_perf_probe(device_t dev) { + ACPI_STATUS status; ACPI_HANDLE handle; ACPI_OBJECT *pkg; struct resource *res; @@ -186,8 +194,12 @@ acpi_perf_probe(device_t dev) handle =3D acpi_get_handle(dev); buf.Pointer =3D NULL; buf.Length =3D ACPI_ALLOCATE_BUFFER; - if (ACPI_FAILURE(AcpiEvaluateObject(handle, "_PCT", NULL, &buf))) + if (ACPI_FAILURE(status =3D + AcpiEvaluateObject(handle, "_PCT", NULL, &buf))) { + device_printf(dev, "%s: failed to evaluate _PCT: %s\n", + __func__, AcpiFormatException(status)); return (error); + } pkg =3D (ACPI_OBJECT *)buf.Pointer; if (ACPI_PKG_VALID(pkg, 2)) { rid =3D 0; @@ -253,8 +265,11 @@ acpi_perf_evaluate(device_t dev) buf.Pointer =3D NULL; buf.Length =3D ACPI_ALLOCATE_BUFFER; status =3D AcpiEvaluateObject(sc->handle, "_PSS", NULL, &buf); - if (ACPI_FAILURE(status)) + if (ACPI_FAILURE(status)) { + device_printf(dev, "%s: failed to evaluate _PSS: %s\n", + __func__, AcpiFormatException(status)); return (ENXIO); + } =20 pkg =3D (ACPI_OBJECT *)buf.Pointer; if (!ACPI_PKG_VALID(pkg, 1)) { @@ -429,14 +444,19 @@ acpi_px_available(struct acpi_perf_softc *sc) =20 /* If the old state is too high, set current state to the new max. */ if (ACPI_SUCCESS(status)) { + device_printf(sc->dev, "Max P-state is %d\n", + sc->px_max_avail); if (sc->px_curr_state !=3D CPUFREQ_VAL_UNKNOWN && sc->px_curr_state > sc->px_max_avail) { acpi_px_to_set(sc->dev, &sc->px_states[sc->px_max_avail], &set); acpi_px_set(sc->dev, &set); } - } else + } else { + device_printf(sc->dev, "Failed to get max P-state (_PPC): %s\n", + AcpiFormatException(status)); sc->px_max_avail =3D 0; + } } =20 static int --=20 1.6.2.4 --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 12:24: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 515741065673; Mon, 4 May 2009 12:24:32 +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 4C2E88FC14; Mon, 4 May 2009 12:24:31 +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 241886311; Mon, 04 May 2009 15:24:30 +0300 Message-ID: <49FEDE7B.30804@FreeBSD.org> Date: Mon, 04 May 2009 15:24:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <49FE1826.4060000@FreeBSD.org> <1241438990.1280.6.camel@RabbitsDen> In-Reply-To: <1241438990.1280.6.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 12:24:33 -0000 Alexandre "Sunny" Kovalenko wrote: > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: >> - C3 state allows CPU completely stop all internal clocks, reduce >> voltage and disconnect from system bus. This state gives additional >> power saving effect, but it is not cheap and require trade-offs. >> As soon as CPU is completely stopped in C3 state, local APIC timers in >> each CPU core, used by FreeBSD as event sources on SMP, are not >> functioning. It stops system time, breaks scheduling that makes system >> close to dead. > Did you try to see whether putting one of the cores in C3 state by doing > something like > > dev.cpu.1.cx_lowest=C3 > > makes any difference? > > # sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% I did. As soon as first CPU core is not in C3 state, second core unable to enter C3 completely and disconnect from the bus, as cores are sharing common resources. Such technique allows to avoid LAPIC timer problems, but I haven't noticed any effect from this on CPU idle power. The only difference I have noticed was in the case, when first core is busy. C3 on second idle core then somehow reduces summary consumption a bit. In other words, C3 state should be active on both cores simultaneously to give real effect. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon May 4 12:32: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 8D7BE1065674 for ; Mon, 4 May 2009 12:32:54 +0000 (UTC) (envelope-from odhiambo@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 075AE8FC43 for ; Mon, 4 May 2009 12:32:53 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz9 with SMTP id 9so3599636bwz.43 for ; Mon, 04 May 2009 05:32:53 -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=YHInqWFs33zkxNTXijwqIUna1RqoJcyxern+jadM7QE=; b=fyNNCIXUfvSd292NOygENNa1vb3hsqC4CoT9ruJX/r5pn/1bLEQWNm5OX+SZO9L482 Ii/HPy0iwFMH7bXZYp7Tic5zTN3e0GorkCxFRkdM/shm1YO748+alxBFIjMjME+y9wiU v2Lhu12nloBHoh/foN6kLWSC2AyB0iaUbQpDQ= 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=HQhZUKfpQS223q4GAOMMQl5aJhtnYBXFNJMqnNxOzL1HVxlVUJpQ9lJ8LFh6FinMBS OaCkGrhHA1sasdDastELyAi0esss8Hc+Dlj0Pfb42c0NGmyGBnaPkSf9/oiPYBBIx8Jz rQjuIM2yNH1mkBx2kixHY6/oQfWPtudokVXGo= MIME-Version: 1.0 Received: by 10.223.116.205 with SMTP id n13mr2102898faq.103.1241439168102; Mon, 04 May 2009 05:12:48 -0700 (PDT) In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Date: Mon, 4 May 2009 15:12:48 +0300 Message-ID: <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 12:32:54 -0000 On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > Please report any concerns to the freebsd-virtualization@ mailing list. > > THEORETICALLY you should not see any changes in behaviour, however we have > the following issues: > > * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you > are not using it yet. > > * An NFS (crash) issue was reported. This MAY have been fixed... > > > Theory tells us that all three kernel options should behave about the same > but if you do try this, and have any benchmarking facilities, > it would be incredibly useful if you could let us know if you see any > performance changes between the three. > > > thanks, > > Julian (currently running a VIMAGE kernel myself) I am ignorant. What is this VIMAGE? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Mon May 4 12:53:49 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 C27921065672 for ; Mon, 4 May 2009 12:53:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA3A8FC1D for ; Mon, 4 May 2009 12:53:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1516820mue.3 for ; Mon, 04 May 2009 05:53: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 :content-transfer-encoding; bh=YXdjp0qYJvLrzH6D5ZVAG12blSLwsAmUje3mdfy2+RI=; b=RjAb3DjRZ2tsFRTKUxIBrfJtyXxxTofP8v3yG+0F3U3em1KV4G7H+BL7s+IvQgdEMb B9Qd3NYaOo1j2KyP4UMBXoHLKJQF5PzVBzlEPcQr8GMaB/2g9ahYBrkGkD+JWi1KdE6S Wf/3f4sBkGO40IB3vRmDlm4bYG0Q+f5wXSTuM= 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=mtYbGqjBP9VOLTHF9G/u3NMO2dP+Sj/Ts0TiHvQUX6sKsW3raxFh3RfXp1np6Glgpj 7HlXaw/Qr/Jf6FOqj+gGh10ZJHYPYfDAgI7VFiUscFCLWzc+XleaSW+QXa10FOwQSgN0 sihCt/iS2axCtCRiOOdGGCBO/BZB1itT8O2Do= MIME-Version: 1.0 Received: by 10.239.168.75 with SMTP id j11mr300173hbe.107.1241441628066; Mon, 04 May 2009 05:53:48 -0700 (PDT) In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Date: Mon, 4 May 2009 14:53:48 +0200 Message-ID: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> From: "Paul B. Mahol" To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 12:53:50 -0000 On 5/2/09, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > Please report any concerns to the freebsd-virtualization@ mailing list. > > THEORETICALLY you should not see any changes in behaviour, however we > have the following issues: > > * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you > are not using it yet. > > * An NFS (crash) issue was reported. This MAY have been fixed... > > > Theory tells us that all three kernel options should behave about the > same but if you do try this, and have any benchmarking facilities, > it would be incredibly useful if you could let us know if you see any > performance changes between the three. I'm experiencing strange 'netstat -r' output, perhaps I need to clean /usr/obj/? (I dont have VIMAGE enabled) -- Paul From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:12: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 CD8221065670; Mon, 4 May 2009 13:12:26 +0000 (UTC) (envelope-from gaijin.k@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 5916C8FC27; Mon, 4 May 2009 13:12:25 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2893389qwe.7 for ; Mon, 04 May 2009 06:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=iypo7b7zlz3AwW7Rii0IuyDmz0y5EAe4AmcmAFjM5yg=; b=IKTbdOeNRmOyTLwZjzkrxA45DSu53hM9yAT9k3MbJEvJ0V+U+Y0AlY14kUGzHSCVsG 3TyNMC97zZdf/2wBETeoAx5XG0Wxc68ctlR1xBVV1aLcNMkk6vHkX95vYjo4hGG4sgvq 8oigwhjRc5DWaZz8yiqgDjzZIa6b4kLYbu4Dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=riT3LkSGTUGTQOffl9OMoXGA8Uhry9jVlN963nhGmG41saIETpuGzlJJHQpsILItY5 ZcPgIviH80RrG9onXJmFD4tmotXu+jPDHPG16lc7dOKyx03r8Jbw8ccOYWcptXr3ORtW Ee3pl/G2xuM2m7wQHNGNSBpDqxDS6mGG7u0K8= Received: by 10.224.80.134 with SMTP id t6mr5686248qak.173.1241439011846; Mon, 04 May 2009 05:10:11 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-23-127.nwrk.east.verizon.net [70.111.23.127]) by mx.google.com with ESMTPS id 7sm9754803qwf.55.2009.05.04.05.10.10 (version=SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 05:10:11 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Alexander Motin In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 May 2009 08:09:50 -0400 Message-Id: <1241438990.1280.6.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 13:12:27 -0000 On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Modern systems, especially laptops, are implementing big number of > power-saving technologies. Some of them are working automatically, other > have significant requirements and need special system tuning or > trade-offs to be effectively used. > > So here is the steps: > > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. Did you try to see whether putting one of the cores in C3 state by doing something like dev.cpu.1.cx_lowest=C3 makes any difference? # sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% -- Alexandre Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:17:58 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 CA40E106566B; Mon, 4 May 2009 13:17:58 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB8C8FC21; Mon, 4 May 2009 13:17:58 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from glorfindel.gritton.org (c-76-27-80-223.hsd1.ut.comcast.net [76.27.80.223]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n44DHu8T003446; Mon, 4 May 2009 07:17:57 -0600 (MDT) Message-ID: <49FEEB03.7060908@FreeBSD.org> Date: Mon, 04 May 2009 07:17:55 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090220) MIME-Version: 1.0 To: Poul-Henning Kamp References: <4424.1241418320@critter.freebsd.dk> In-Reply-To: <4424.1241418320@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9325/Mon May 4 06:17:20 2009 on gritton.org X-Virus-Status: Clean Cc: virtualization@FreeBSD.org, jail@FreeBSD.org, current@FreeBSD.org Subject: Re: New jail framework - the userland side X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 13:17:59 -0000 Poul-Henning Kamp wrote: > In message <49FE5387.3020503@FreeBSD.org>, Jamie Gritton writes: > >> Hi all. I recently added some new jail-related system calls to extend >> the current jail system with an nmount-inspired name=value interface. > > I think this is a great move in the right direction, my only concern is > that we should try to share as much of the string-munging code between > the nmount and jail implementations as possible. Most if it is shared - jail actually calls vfs_getopt and related calls from the family. I might want to spin those functions off into their own subsystem at some point, now that they're officially used outside of VFS. I did have to extend things somewhat for jail_get, as nmount is write- only and only had to deal with one module at a time (the filesystem type). Those extensions are available for use elsewhere, as I suspect filesystems and jails aren't the only place where we could use name- based extensibility. - Jamie From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:31: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 E1B621065672 for ; Mon, 4 May 2009 13:31:04 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id A6C088FC17 for ; Mon, 4 May 2009 13:31:03 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 417C75C06F for ; Mon, 4 May 2009 21:31:02 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id F141555D1694; Mon, 4 May 2009 21:31:01 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id O6ZkwYI27eAp; Mon, 4 May 2009 21:30:07 +0800 (CST) Received: from qld630 (unknown [222.131.117.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1A14E55D1688; Mon, 4 May 2009 21:30:01 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=nzw4jWyJaj1IcJsPSWv3XcJAOgvmxbFD2vGIv+1t0SpL/Hy3TAJNj1+/vHbp/4uRD VeijlSkvzq/Nz/CyOsJTg== Date: Mon, 04 May 2009 21:29:44 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905041238.30304.hselasky@c2i.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200905041238.30304.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 13:31:05 -0000 在 Mon, 04 May 2009 18:38:29 +0800，Hans Petter Selasky 写道: here it is, [root@currentpark] ~# cat /var/run/dmesg.boot 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 #1: Mon May 4 18:14:47 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/UMESSAGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1012514816 (965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3e5ffc00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xecb8-0xecbf mem 0xfea00000-0xfeafffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 ehci0: mem 0xfe9fbc00-0xfe9fbfff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:a0:e1:31:eb bge0: [ITHREAD] uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus3: on uhci2 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus4: on uhci3 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0000 usbus5: on uhci4 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfec0-0xfecf,0xecc0-0xeccf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff,0xcd000-0xcffff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 uhci_interrupt: host controller process error usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 uhci_interrupt: host system error usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152587MB at ata0-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0a is ufsid/49f98454ff52b98f. GEOM_LABEL: Label for provider ad0a is ufs/root. GEOM_LABEL: Label for provider ad0d is ufsid/49f9845b4cbc1341. GEOM_LABEL: Label for provider ad0d is ufs/var. GEOM_LABEL: Label for provider ad0e is ufsid/49f98455b2c7e9e5. GEOM_LABEL: Label for provider ad0e is ufs/tmp. GEOM_LABEL: Label for provider ad0f is ufsid/49f9845405ff03de. GEOM_LABEL: Label for provider ad0f is ufs/home. GEOM_LABEL: Label for provider ad0g is ufsid/49f98456bbb9c493. GEOM_LABEL: Label for provider ad0g is ufs/usr. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered uhci_interrupt: host system error acd0: DVDROM at ata1-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ufs/root uhci_interrupt: host system error GEOM_LABEL: Label ufsid/49f98454ff52b98f removed. GEOM_LABEL: Label ufsid/49f9845405ff03de removed. GEOM_LABEL: Label ufsid/49f98455b2c7e9e5 removed. GEOM_LABEL: Label fs id/49f98456bb c 493 removed. GEOM_LABEL: Label ufsid/49f9845b4cbc1341 removed. usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > On Monday 04 May 2009, Chao Shin wrote: >> Hi, all >> >> I have a dell optiplex 745 box with a dell usb mouse. I update system >> from >> 7.1 to current today, >> after that the usb mouse could not recongnize. I got some message from >> dmesg like below: >> > >> >> Is this a usb2.0's bug or I should configure something else? > > Can you send complete dmesg ? > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:38: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 2BF7D1065674 for ; Mon, 4 May 2009 13:38:52 +0000 (UTC) (envelope-from odhiambo@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 9E2788FC0A for ; Mon, 4 May 2009 13:38:51 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz9 with SMTP id 9so3641945bwz.43 for ; Mon, 04 May 2009 06:38:50 -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=zU1HSng2blS4Ma3VGYtSJZ1i08LpzWHRbq7leWuajBA=; b=gLBax6rrEG8m+tFxqqfh4QeBZpO92OVS3N3nToGZn9tb8nVQ1strHoZDXflN9I1dgJ mJDzro1YLdlpJ5DokcM9G9/fDg2HtqwFspszIDLqqZx/NVT6JppSp9AS3RswDraV3iVP 6BI8YnabFnTTuAcNYsxf/RCmcFQN0X0vPQKEI= 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=uk8KFYUf8MtJQ1qqNRjd2x49A+I7BlwGl088E5cPsRp1qLI5mfJdCuu8dAVIs9EXfs /5vVumMRWAIlUSwJXlj+ry4uPwZDf5U/e+x3gz7+c46xBWnT4P5gvShDGGthl4JWz6VH R5Xb5JRH9Y/vbkhHLKHUXvYcqDItmGCYX+0Ao= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr2233685fap.19.1241444330429; Mon, 04 May 2009 06:38:50 -0700 (PDT) In-Reply-To: <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> Date: Mon, 4 May 2009 16:38:50 +0300 Message-ID: <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 13:38:52 -0000 2009/5/4 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3 > > > On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrot= e: > >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they were >> before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> Please report any concerns to the freebsd-virtualization@ mailing list. >> >> THEORETICALLY you should not see any changes in behaviour, however we ha= ve >> the following issues: >> >> * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you >> are not using it yet. >> >> * An NFS (crash) issue was reported. This MAY have been fixed... >> >> >> Theory tells us that all three kernel options should behave about the sa= me >> but if you do try this, and have any benchmarking facilities, >> it would be incredibly useful if you could let us know if you see any >> performance changes between the three. >> >> >> thanks, >> >> Julian (currently running a VIMAGE kernel myself) > > > I am ignorant. What is this VIMAGE? > Pardon me for the stupid question. Google has given me the whipping I deserve! --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:53: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 7A97D106566C for ; Mon, 4 May 2009 13:53:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 121EF8FC0A for ; Mon, 4 May 2009 13:53:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=QLzzWchZA7pTSEzRoDUA:9 a=1ObIuKMm_JhD8Wo3Px9czXK_PgMA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 845965870; Mon, 04 May 2009 15:53:44 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 4 May 2009 15:56:17 +0200 User-Agent: KMail/1.9.7 References: <200905041238.30304.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041556.18646.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 13:53:46 -0000 On Monday 04 May 2009, Chao Shin wrote: > usbus0: 12Mbps Full Speed USB v1.0 > uhci_interrupt: host controller process error Hi, It appears your USB Host Controller Hardware has crashed. Could you boot having the following line in /boot/loader.conf: hw.usb2.uhci.debug=15 And send new dmesg. Patch you can try in the meanwhile: Edit /sys/dev/usb/controller/usb_controller.c: - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); This will reduce the DMA bits to 30. --HPS From owner-freebsd-current@FreeBSD.ORG Mon May 4 14:03: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 E13C5106564A for ; Mon, 4 May 2009 14:03:48 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6012C8FC16 for ; Mon, 4 May 2009 14:03:48 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id C2F9A5C070 for ; Mon, 4 May 2009 22:03:46 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 80D4555D1692; Mon, 4 May 2009 22:03:46 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id WZeHYEpkcCO7; Mon, 4 May 2009 22:02:56 +0800 (CST) Received: from qld630 (unknown [222.131.117.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 7C5A155D1694; Mon, 4 May 2009 22:02:51 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=pG/9SKqVQMh2MjyPK1+0zOKErQI3HE8kNvQm+MHzK1eGhIuHvQQNJQCPQf5xwdedI qnqDK8Nh3e0YLcz6i766w== Date: Mon, 04 May 2009 22:02:39 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905041238.30304.hselasky@c2i.net> <200905041556.18646.hselasky@c2i.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200905041556.18646.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 14:03:49 -0000 > On Monday 04 May 2009, Chao Shin wrote: >> usbus0: 12Mbps Full Speed USB v1.0 >> uhci_interrupt: host controller process error > > Hi, > > It appears your USB Host Controller Hardware has crashed. > > Could you boot having the following line in /boot/loader.conf: > > hw.usb2.uhci.debug=15 > > And send new dmesg. > Thank you for your reply, I will get it tomorrow and send it to you. > > > Patch you can try in the meanwhile: > > Edit /sys/dev/usb/controller/usb_controller.c: > > - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); > > + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); > > This will reduce the DMA bits to 30. I will try this patch, thank you > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Mon May 4 14:45: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 850CA1065674 for ; Mon, 4 May 2009 14:45:16 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE798FC22 for ; Mon, 4 May 2009 14:45:15 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id AA3AB9B646; Mon, 4 May 2009 16:15:37 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 433649B644; Mon, 4 May 2009 16:15:21 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Mon, 4 May 2009 10:15:15 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> In-Reply-To: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041015.15332.zec@icir.org> Cc: Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 14:45:16 -0000 On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: ... > I'm experiencing strange 'netstat -r' output, perhaps I need to clean > /usr/obj/? (I dont have VIMAGE enabled) You should rebuild your userland regardless whether options VIMAGE in the kernel has been enabled or not, see the UPDATING note for details. Marko From owner-freebsd-current@FreeBSD.ORG Mon May 4 14:57: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 3E806106567C for ; Mon, 4 May 2009 14:57:34 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by mx1.freebsd.org (Postfix) with ESMTP id BC1758FC15 for ; Mon, 4 May 2009 14:57:33 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1556309mue.3 for ; Mon, 04 May 2009 07:57: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=8sTQFv2niNj1gXssobNjN8qq/fHSEG+5Qts2DNk+OMY=; b=UCj5dX6pVXv2mhG2t4gaqctq4P86co+Ai71G8dDYr6YcAsadM4UfPvKtZ2hc6Ni+QC rP5z0myo6nxMF6qc0vHvFR7RKsVHPNAKikjDRn/K62mq3iflPqGsBn93K8cSyo2/7/ie ATZvF/Iwu9mU24S1kk53K+PWgxJExopduWfqE= 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=iJ6u/aXnA+KqKsVD+1Vkr0lcAuK/Tjo69/Sh/KAISigUJyaQgLc9MNHOyM4LcrJkDe ZoCSojQLNWDGnPXkDq8YNaMqmfmjRrrruF/Ua0WEJtodeUDPWriF/xjw0TxPTKqAtj/Y uI7GnS+kNdOSNCrFK7hSKgZcq9MHaIz3PU3v0= MIME-Version: 1.0 Received: by 10.239.154.145 with SMTP id e17mr335631hbc.95.1241449052395; Mon, 04 May 2009 07:57:32 -0700 (PDT) In-Reply-To: <200905041015.15332.zec@icir.org> References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> <200905041015.15332.zec@icir.org> Date: Mon, 4 May 2009 16:57:32 +0200 Message-ID: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> From: "Paul B. Mahol" To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 14:57:34 -0000 On 5/4/09, Marko Zec wrote: > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: > ... >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >> /usr/obj/? (I dont have VIMAGE enabled) > > You should rebuild your userland regardless whether options VIMAGE in the > kernel has been enabled or not, see the UPDATING note for details. I did, but I will ask again do I need to clean /usr/obj/? -- Paul From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:10: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 4F9FE106566C; Mon, 4 May 2009 15:10:01 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5418FC1C; Mon, 4 May 2009 15:10:01 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n44F9xYd027247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 May 2009 08:10:00 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 67BE91CC50; Mon, 4 May 2009 08:09:59 -0700 (PDT) To: Alexander Motin In-reply-to: Your message of "Mon, 04 May 2009 15:24:27 +0300." <49FEDE7B.30804@FreeBSD.org> Date: Mon, 04 May 2009 08:09:59 -0700 From: "Kevin Oberman" Message-Id: <20090504150959.67BE91CC50@ptavv.es.net> Cc: FreeBSD acpi , FreeBSD-Current , "Alexandre \"Sunny\" Kovalenko" , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 15:10:02 -0000 > Date: Mon, 04 May 2009 15:24:27 +0300 > From: Alexander Motin > Sender: owner-freebsd-mobile@freebsd.org > > Alexandre "Sunny" Kovalenko wrote: > > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > >> - C3 state allows CPU completely stop all internal clocks, reduce > >> voltage and disconnect from system bus. This state gives additional > >> power saving effect, but it is not cheap and require trade-offs. > >> As soon as CPU is completely stopped in C3 state, local APIC timers in > >> each CPU core, used by FreeBSD as event sources on SMP, are not > >> functioning. It stops system time, breaks scheduling that makes system > >> close to dead. > > Did you try to see whether putting one of the cores in C3 state by doing > > something like > > > > dev.cpu.1.cx_lowest=C3 > > > > makes any difference? > > > > # sysctl dev.cpu | grep cx_usage > > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% > > I did. As soon as first CPU core is not in C3 state, second core unable > to enter C3 completely and disconnect from the bus, as cores are sharing > common resources. Such technique allows to avoid LAPIC timer problems, > but I haven't noticed any effect from this on CPU idle power. The only > difference I have noticed was in the case, when first core is busy. C3 > on second idle core then somehow reduces summary consumption a bit. > > In other words, C3 state should be active on both cores simultaneously > to give real effect. It is important to be aware that the presence of USB will keep a system from entering C3. Either build a kernel without USB and load it only whan needed or run 8-CURRENT with the USB2 stack which is purported to fix this problem. (I have no systems running CURRENT, so I can't confirm that USB2 fixes the problem.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:11: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 3A2DD1065710 for ; Mon, 4 May 2009 15:11:33 +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 023E98FC27 for ; Mon, 4 May 2009 15:11:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n44FAqnR056664; Mon, 4 May 2009 08:10: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 inq8cshy99pi2rjd9fg3axgkba; Mon, 04 May 2009 08:10:52 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49FF057B.5000602@freebsd.org> Date: Mon, 04 May 2009 08:10: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 B. Mahol" References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> In-Reply-To: <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dmitry Marakasov , freebsd-current@freebsd.org Subject: Re: geom_part X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 15:11:34 -0000 Paul B. Mahol wrote: > On 5/4/09, Dmitry Marakasov wrote: >> >> I've upgraded one of my boxes to current recently and ran into some >> problems with new geom_part. >> >> First, it's impossible to edit bsd label online. >> >> # bsdlabel -e /dev/ad8 >> [edit] >> bsdlabel: Class not found >> re-edit the label? [y]: > > bsdlabel, fdisk and others no longer works correctly, use gpart(8) instead. What are the plans for 8.0? Will bsdlabel and fdisk be fixed? Or removed? Tim From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:26: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 EBAE71065672 for ; Mon, 4 May 2009 15:26:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from skerryvore.cs.uoguelph.ca (skerryvore.cs.uoguelph.ca [131.104.94.204]) by mx1.freebsd.org (Postfix) with ESMTP id 918878FC16 for ; Mon, 4 May 2009 15:26:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by skerryvore.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n44FQe0Y032197 for ; Mon, 4 May 2009 11:26:40 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n44FQhn02051 for ; Mon, 4 May 2009 11:26:43 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 4 May 2009 11:26:43 -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 X-Scanned-By: MIMEDefang 2.63 on 131.104.94.221 Subject: [HEADSUP]: new nfs subdirs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 15:26:42 -0000 I've just committed three subdirs sys/fs/nfs, sys/fs/nfsclient and sys/fs/nfsserver, for a total of about 45,000 lines of C. Since the build glue is not there yet, the only impact you might experience is a slow "svn update". Hopefully the above doesn't cause you grief, rick From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:57: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 3D5B41065744 for ; Mon, 4 May 2009 15:57:38 +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 161458FC15 for ; Mon, 4 May 2009 15:57:37 +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 7ADE1337AF4 for ; Mon, 4 May 2009 11:57:37 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 04 May 2009 11:57:37 -0400 X-Sasl-enc: /HgJfJ6bJXTlTRQTLaspC3sZFBlK6FnGMmJSuWbrR+hU 1241452656 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 CDFA429049 for ; Mon, 4 May 2009 11:57:36 -0400 (EDT) Message-ID: <49FF106D.1060507@incunabulum.net> Date: Mon, 04 May 2009 16:57:33 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: CARP and IPv6 SSM changes -- call for feedback X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 15:57:38 -0000 Hi, Could any CARP users tracking -current let me know if they see any issues with CARP since last week's merge of MLDv2 / SSM in IPv6? Please let me know, I have tried to convert its semantics to the SSM KPI's -- the most intrusive change to carp is to adapt it to how the SSM capable IPv6 stack tracks multicast memberships. This shouldn't impact the functionality of CARP, but if I've missed something, please let me know -- it was a fairly quick refactoring w/o knowing all of the internals of CARP as currently implemented. thanks, BMS From owner-freebsd-current@FreeBSD.ORG Mon May 4 16:21: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 84915106566B for ; Mon, 4 May 2009 16:21:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEF38FC14 for ; Mon, 4 May 2009 16:21:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44GJ33k060708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:19:04 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: rea-fbsd@codelabs.ru In-Reply-To: References: <1241418372.78715.1.camel@balrog.2hip.net> <1241419338.78715.8.camel@balrog.2hip.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-qrTBfmH6pEsSotQ4jCoC" Organization: FreeBSD Date: Mon, 04 May 2009 11:18:50 -0500 Message-Id: <1241453930.1788.10.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 16:21:10 -0000 --=-qrTBfmH6pEsSotQ4jCoC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 15:28 +0400, Eygene Ryabinkin wrote: > Robert, >=20 > Mon, May 04, 2009 at 01:42:18AM -0500, Robert Noland wrote: > > Without this patch, cpu0 does attach correctly. >=20 > On the Intel MB? If yes and you'll be able to to some debugging, > please, try the attached patch and send the output of 'dmesg', > 'sysctl dev.cpu', 'sysctl dev.cpufreq' and 'sysctl dev.est'. Ok, just to publicly state that the Intel board apparently was not attaching to core0. I saw the failure and assumed that it was cpu related and would be the same as the Asus board. Should I still apply this patch? > > > One could check if the patch will help by examining the output of > > > 'apicdump -d' and looking for the Alias () directives for the Process= or > > > objects. Here's what I have for my laptop: > > > ----- > > > Scope (_PR) > > > { > > > Processor (P001, 0x01, 0x00000810, 0x06) {} > > > Alias (P001, CPU1) > > > } > > >=20 > > > Scope (_PR) > > > { > > > Processor (P002, 0x02, 0x00000810, 0x06) {} > > > Alias (P002, CPU2) > > > } > > > ----- > > > So in this case we essentially have 4 Processor objects under _PR, > > > but only two objects are real ones and only they should be attached. > > >=20 > > > For the completeness, could you, please, show the output of 'acpidump > > > -dt 2>&1' for both of your machines? > >=20 > > Attached. The Asus does appear to use aliases as you described. >=20 > Then you should have est attached to cpu0/cpu2 and rejected on > cpu1/cpu3, aren't you? The output of 'sysctl dev.cpu', 'sysctl dev.est' > and 'sysctl dev.cpufreq' will be also helpful. Will you be able to try > my original patch on the Asus system? Ok, the patch is applied on the Asus board and it now appears to be working correctly. I've re-enabled powerd now, so we will see how that goes. When it was only attaching to core0 the board would hang at times with powerd enabled. robert. > Thanks! --=20 Robert Noland FreeBSD --=-qrTBfmH6pEsSotQ4jCoC 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) iEYEABECAAYFAkn/FWoACgkQM4TrQ4qfRONOcwCfaBPVIGBgyY7RqgQ3wKRsNL5Y 5qYAnjJS+Bl/6ZNo7VM7YK7hDxgoyklw =wavN -----END PGP SIGNATURE----- --=-qrTBfmH6pEsSotQ4jCoC-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:32:47 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 3787C106567A for ; Mon, 4 May 2009 17:32:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3CF8FC28 for ; Mon, 4 May 2009 17:32:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1D86922D6; Mon, 4 May 2009 10:32:47 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 55FFF2D63BE; Mon, 4 May 2009 10:32:46 -0700 (PDT) Message-ID: <49FF26C2.8080202@elischer.org> Date: Mon, 04 May 2009 10:32:50 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> In-Reply-To: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 17:32:47 -0000 Paul B. Mahol wrote: > On 5/2/09, Julian Elischer wrote: >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they were >> before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> Please report any concerns to the freebsd-virtualization@ mailing list. >> >> THEORETICALLY you should not see any changes in behaviour, however we >> have the following issues: >> >> * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you >> are not using it yet. >> >> * An NFS (crash) issue was reported. This MAY have been fixed... >> >> >> Theory tells us that all three kernel options should behave about the >> same but if you do try this, and have any benchmarking facilities, >> it would be incredibly useful if you could let us know if you see any >> performance changes between the three. > > I'm experiencing strange 'netstat -r' output, perhaps I need to clean > /usr/obj/? (I dont have VIMAGE enabled) thanks if you do not have VIMAGE enabled then there should be no effect for you. I suggest you make sure that your userland and kernel are completely in sync. > From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:34: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 9184D1065688 for ; Mon, 4 May 2009 17:34:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 778168FC15 for ; Mon, 4 May 2009 17:34:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 5BD8D24D7; Mon, 4 May 2009 10:34:39 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 3D9432D60D4; Mon, 4 May 2009 10:34:38 -0700 (PDT) Message-ID: <49FF2732.5090007@elischer.org> Date: Mon, 04 May 2009 10:34:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?UTF-8?B?T2RoaWFtYm8g44Ov44K344Oz44OI44Oz?= References: <49FC812B.2070305@elischer.org> <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> In-Reply-To: <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 17:34:39 -0000 Odhiambo ワシントン wrote: > 2009/5/4 Odhiambo ワシントン > > > > > I am ignorant. What is this VIMAGE? > > > Pardon me for the stupid question. Google has given me the whipping I > deserve! > yes and a good one too I hope! :-) From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:36: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 1D51A10656DA for ; Mon, 4 May 2009 17:36:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0294B8FC1B for ; Mon, 4 May 2009 17:36:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 06491232E; Mon, 4 May 2009 10:36:05 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 931042D6133; Mon, 4 May 2009 10:36:03 -0700 (PDT) Message-ID: <49FF2787.2060804@elischer.org> Date: Mon, 04 May 2009 10:36:07 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> In-Reply-To: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , freebsd-current@freebsd.org Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 17:36:05 -0000 Paul B. Mahol wrote: > On 5/4/09, Marko Zec wrote: >> On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: >> ... >>> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >>> /usr/obj/? (I dont have VIMAGE enabled) >> You should rebuild your userland regardless whether options VIMAGE in the >> kernel has been enabled or not, see the UPDATING note for details. > > I did, but I will ask again do I need to clean /usr/obj/? THEORETICALLY not, but it can't hurt. From owner-freebsd-current@FreeBSD.ORG Mon May 4 18:02: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 D6CD51065673 for ; Mon, 4 May 2009 18:02:00 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id 390D88FC1A for ; Mon, 4 May 2009 18:02:00 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1620476mue.3 for ; Mon, 04 May 2009 11:01:59 -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=Om6QJcEnSIhJs2rxeD78q9hBubF1eS5vKsKOIUAsbr0=; b=BM5ji3Ai+Q2HA/3BZ4Jk7ccEzyU2bCER+WrqVECy1O/2eZVwmHCipitI7GipBK5e6Y daLmTmiiJq3Br13uyndcu4UHwzSNZgDh+/E9Bs0Qe8ziosZsbYDSYyEg2JyePae6ZQu+ wf8P9xoXloZoxDy138VtpWzw6OuhuH94WryC0= 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=MCcRTJ7TthA5mwhz3BKsaoQDYtzg/k2sPEe4hdkLXF2vpHkgb4vDKVq7Yj8Jh9rx/y gIGF+8YkCbdCYpjtpj50QkD1z9HET+V0vohlMWU3A54LD6rUdBZMhY56eyUwvAsmULt2 rm2c6kuUyM99Vd0q58wy77DkBokN6NNPzvIPE= MIME-Version: 1.0 Received: by 10.103.241.15 with SMTP id t15mr3805247mur.85.1241460119285; Mon, 04 May 2009 11:01:59 -0700 (PDT) In-Reply-To: <49FF057B.5000602@freebsd.org> References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> <49FF057B.5000602@freebsd.org> From: Scott Ullrich Date: Mon, 4 May 2009 14:01:44 -0400 Message-ID: To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dmitry Marakasov , freebsd-current@freebsd.org Subject: Re: geom_part X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 18:02:01 -0000 On Mon, May 4, 2009 at 11:10 AM, Tim Kientzle wrote: > What are the plans for 8.0? =A0Will bsdlabel and fdisk > be fixed? =A0Or removed? fdisk and bsdlabel are working fine as of a few days ago. We use both inside the BSDInstaller which still works OK. Paul, what exactly is broken? Scott From owner-freebsd-current@FreeBSD.ORG Mon May 4 18:08:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 032E8106564A; Mon, 4 May 2009 18:08:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: pluknet Date: Mon, 4 May 2009 14:07:53 -0400 User-Agent: KMail/1.6.2 References: <20090430013428.cb4f804b.nork@FreeBSD.org> <200905011610.42613.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905041407.56204.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org, Jeff Roberson Subject: Re: cannot compile sched_ule without options SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 18:08:09 -0000 On Saturday 02 May 2009 03:50 am, pluknet wrote: > 2009/5/2 Jung-uk Kim : > > On Thursday 30 April 2009 11:04 pm, pluknet wrote: > >> 2009/5/1 pluknet : > >> > 2009/5/1 Jeff Roberson : > >> >> On Thu, 30 Apr 2009, pluknet wrote: > >> >>> 2009/4/30 Jeff Roberson : > >> >>>> On SMP machines you should now see output like this: > >> >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >> >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > >> >>>> > >> >>>> If you detect any irregularities with > >> >>>> kern.sched.topology_spec or this dmesg > >> >>>> line please report them. > >> >>> > >> >>> Hi, Jeff. > >> >>> > >> >>> I have such mismatch. This is an Intel E7200. > >> >>> > >> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads > >> >>> cpu0 (BSP): APIC ID: 0 > >> >>> cpu1 (AP/HT): APIC ID: 1 > >> >>> > >> >>> So it should be instead: 1 package(s) x 2 core(s) > >> >>> cpu0 (BSP): APIC ID: 0 > >> >>> cpu1 (AP): APIC ID: 1 > >> >> > >> >> Can you please repeat the following steps as I have done > >> >> here: > >> > > >> > (kgdb) p/x cpu_high > >> > $1 = 0x2 > >> > (kgdb) p/x cpu_cores > >> > $2 = 0x1 > >> > (kgdb) p/x cpu_logical > >> > $3 = 0x2 > >> > (kgdb) p/x cpu_feature > >> > $4 = 0xbfebfbff > >> > (kgdb) p/x logical_cpus > >> > $5 = 0x2 > >> > (kgdb) p/x hyperthreading_cpus > >> > $6 = 0x2 > >> > >> Follow up myself: > >> > >> What is embarrassing me is HTT feature enabled. May the reason > >> be in a buggy CPUID ? > > > > No, the flag does not mean it supports Hyperthreading. It means > > more than one logical core is supported (multi-threading) > > although the name didn't change for historical reason. ;-) > > I see now. > > > Can you try the attached patch? > > Nice, it works! Committed slightly different version. http://svn.freebsd.org/viewvc/base?view=revision&revision=191788 Thanks! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon May 4 18:40: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 A86FA10656DC for ; Mon, 4 May 2009 18:40:30 +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 267AF8FC21 for ; Mon, 4 May 2009 18:40:29 +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 914A6A06C9; Mon, 4 May 2009 20:40:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 838DEA06C8; Mon, 4 May 2009 20:40:28 +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 6C3C7A06C6; Mon, 4 May 2009 20:40:28 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050420402737-1554 ; Mon, 4 May 2009 20:40:27 +0200 Received: by wep4035 (sSMTP sendmail emulation); Mon, 4 May 2009 20:40:27 +0200 Date: Mon, 4 May 2009 20:40:27 +0200 From: Alexey Shuvaev To: freebsd-current@freebsd.org Message-ID: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 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.2HF443 | November 25, 2008) at 05/04/2009 08:40:27 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/04/2009 08:40:28 PM, Serialize complete at 05/04/2009 08:40:28 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: rnoland@FreeBSD.org Subject: intel graphics loosing msi interrupt on subsequent starts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 18:40:31 -0000 Hello all! Sorry if it is already reported... I have recently upgaded X server from 1.4 to 1.6 (ports from ~23.01.2009 -> 03.05.2009). On the first start everything works ok (including [glx]gears). On the second and subsequent starts everything looks working but jerky, I need to move mouse around to get some windows redrawn, [glx]gears print warning message about not getting vblank interrupts and outputs something about 1-2 frames per 5 seconds. The inspectation with vmstat -i has shown that the card generates interrupts only during the first start of X server. If I set hw.pci.enable_msi="0" everything is working fine (start X server multiple times, switch consoles, [glx]gears, number of irq16-s is increasing, ...). I can't be sure it is only due to X upgrade, I have upgraded the base system also (~2 weeks old CURRENT -> 03.05.2009). Some quick to gather system details: ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun May 3 03:04:41 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 (4 GB of RAM, Core2Duo, if it matters) >From pciconf -lv: vgapci0@pci0:0:2:0: class=0x030000 card=0x82761043 chip=0x29c28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) Integrated Graphics Controller' class = display subclass = VGA >From dmesg with hw.pci.enable_msi="0": vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 >From dmesg with default settings: vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 Thanks, Alexey. From owner-freebsd-current@FreeBSD.ORG Mon May 4 18:40: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 714FF1065708; Mon, 4 May 2009 18:40:41 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 13BAF8FC0C; Mon, 4 May 2009 18:40:40 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yx-out-2324.google.com with SMTP id 8so2476384yxb.13 for ; Mon, 04 May 2009 11:40:40 -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=pVHndkLoel/dDf3T7QhRgr0F+FW0JewyPjQJXOv+qAk=; b=dqFTBCu/S235gSWzohtF25MZuLELY+lmvrcMo3ndRSqXzyd1z/uRSYDA9VZwEgSJ3j Mt7G1wsdONmS8X7Dld/9z/KJBsuuM2YmQDNxxxyVcIZEfWRxuoPVYNfBw6vwZ+a8/QIt ZIKV8O7ZM6XUQlt8Hgj71mdYb6wC/f+1DXICg= 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=i0r/ZX4mJVU/gIIVt0c6+yUN1DnlN+3T+R/MCZ32ESmsZ1tE/oV1nSfcQJ9YRU+Jal 9KbZWDcYvQLIDIH6MSjyAzhNp91np8xgyo3JOegh2gSjPUrXAE3V8hZZIzpaMOrJF4XL efg4CM4b+inmZHJpjBZWnpLOqxtHO6I50o5/k= MIME-Version: 1.0 Received: by 10.150.138.8 with SMTP id l8mr12588155ybd.63.1241461141253; Mon, 04 May 2009 11:19:01 -0700 (PDT) In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Date: Mon, 4 May 2009 20:19:01 +0200 Message-ID: <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> From: Lucius Windschuh To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 18:40:42 -0000 2009/5/4 Alexander Motin : > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. First, thank you for your report about power saving on current laptops. :-) > 1. CPU > [...] > =A0- C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=3D0 I tried this on CURRENT@r191784 (i386) on a Thinkpad T400 (Intel(R) Core(TM)2 Duo CPU T9400) with INVARIANTS, etc. enabled. The result was a panic shortly before /sbin/init is called: panic: lapic1: zero divisor So, the KASSERT in sys/i386/local_apic.c:325 fired: KASSERT(lapic_timer_period !=3D 0, ("lapic%u: zero divisor", lapic_id())); Did I forget something? My /boot/loader.conf: hint.p4tcc.0.disabled=3D1 hint.acpi_throttle.0.disabled=3D1 kern.hz=3D100 hint.atrtc.0.clock=3D0 hint.apic.0.clock=3D0 hint.ata.2.pm_level=3D2 hint.ata.3.pm_level=3D3 vm.pmap.pg_ps_enabled=3D1 dmesg: http://sites.google.com/site/lwfreebsd/Home/files/dmesg-T400-FreeBSD= -CURRENT.txt kernel config: http://sites.google.com/site/lwfreebsd/Home/files/kernel-CUR= RENT.txt Regards Lucius From owner-freebsd-current@FreeBSD.ORG Mon May 4 19:03: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 187FC106567B; Mon, 4 May 2009 19:03:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 60A428FC19; Mon, 4 May 2009 19:03:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1639370mue.3 for ; Mon, 04 May 2009 12:03: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 :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h64Avfk69mBKKEMm3FqSPG5ktckEPvKj+Zd2gb7OtRo=; b=HNLsMWrd5jZSIuDkBab6d3wI+LhV58ZDCkIEcuTfe/YTOZDt0QybFlKWSrhF+52HZu PsKbBAuucInE1oMOIOwwYSyQYlc1yj3nKmUOY1cCHapDcVKOgkykaSQlcp8YtC/nklrX ynU+qX/iR9TUx2acWgUTDu2PUbtMASWiIjHSk= 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=Dc3OfiSMrDYQ8c3ffu8rWBpxcfU0NQi7r7i7B09YlIsR98TI0dzpSC4pU+T8znMOda ybx/Svg28MFoK8zQSOqJ4pg1WM9/qWGvtaTZDF6UY6ZHso5ZI36Ter9r44PAixbezh3k v14RbP7XO6RHV01wktN43yFbkd0cqs3ouuUEA= MIME-Version: 1.0 Received: by 10.103.248.17 with SMTP id a17mr3801442mus.83.1241463804063; Mon, 04 May 2009 12:03:24 -0700 (PDT) In-Reply-To: <200905041407.56204.jkim@FreeBSD.org> References: <20090430013428.cb4f804b.nork@FreeBSD.org> <200905011610.42613.jkim@FreeBSD.org> <200905041407.56204.jkim@FreeBSD.org> Date: Mon, 4 May 2009 23:03:23 +0400 Message-ID: From: pluknet To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jeff Roberson Subject: Re: cannot compile sched_ule without options SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 19:03:26 -0000 2009/5/4 Jung-uk Kim : > On Saturday 02 May 2009 03:50 am, pluknet wrote: >> 2009/5/2 Jung-uk Kim : >> > On Thursday 30 April 2009 11:04 pm, pluknet wrote: >> >> 2009/5/1 pluknet : >> >> > 2009/5/1 Jeff Roberson : >> >> >> On Thu, 30 Apr 2009, pluknet wrote: >> >> >>> 2009/4/30 Jeff Roberson : >> >> >>>> On SMP machines you should now see output like this: >> >> >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> >> >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >> >> >>>> >> >> >>>> If you detect any irregularities with >> >> >>>> kern.sched.topology_spec or this dmesg >> >> >>>> line please report them. >> >> >>> >> >> >>> Hi, Jeff. >> >> >>> >> >> >>> I have such mismatch. This is an Intel E7200. >> >> >>> >> >> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> >> >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >> >> >>> cpu0 (BSP): APIC ID: 0 >> >> >>> cpu1 (AP/HT): APIC ID: 1 >> >> >>> >> >> >>> So it should be instead: 1 package(s) x 2 core(s) >> >> >>> cpu0 (BSP): APIC ID: 0 >> >> >>> cpu1 (AP): APIC ID: 1 >> >> >> >> >> >> Can you please repeat the following steps as I have done >> >> >> here: >> >> > >> >> > (kgdb) p/x cpu_high >> >> > $1 = 0x2 >> >> > (kgdb) p/x cpu_cores >> >> > $2 = 0x1 >> >> > (kgdb) p/x cpu_logical >> >> > $3 = 0x2 >> >> > (kgdb) p/x cpu_feature >> >> > $4 = 0xbfebfbff >> >> > (kgdb) p/x logical_cpus >> >> > $5 = 0x2 >> >> > (kgdb) p/x hyperthreading_cpus >> >> > $6 = 0x2 >> >> >> >> Follow up myself: >> >> >> >> What is embarrassing me is HTT feature enabled. May the reason >> >> be in a buggy CPUID ? >> > >> > No, the flag does not mean it supports Hyperthreading. It means >> > more than one logical core is supported (multi-threading) >> > although the name didn't change for historical reason. ;-) >> >> I see now. >> >> > Can you try the attached patch? >> >> Nice, it works! > > Committed slightly different version. > > http://svn.freebsd.org/viewvc/base?view=revision&revision=191788 > Thank you! Just checked again on fresh current. P.S. For archives: now topology_spec looks slightly different, according to the change: kern.sched.topology_spec: 0, 1 0, 1 -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon May 4 19:06: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 0683210656AD for ; Mon, 4 May 2009 19:06:03 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 04D048FC12 for ; Mon, 4 May 2009 19:06:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44J5sIP061649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:05:55 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alexey Shuvaev In-Reply-To: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> References: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jCo6m8UbreVdcbyNQWVK" Organization: FreeBSD Date: Mon, 04 May 2009 14:05:41 -0500 Message-Id: <1241463941.1788.31.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: intel graphics loosing msi interrupt on subsequent starts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 19:06:04 -0000 --=-jCo6m8UbreVdcbyNQWVK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 20:40 +0200, Alexey Shuvaev wrote: > Hello all! >=20 > Sorry if it is already reported... >=20 > I have recently upgaded X server from 1.4 to 1.6 > (ports from ~23.01.2009 -> 03.05.2009). > On the first start everything works ok (including [glx]gears). > On the second and subsequent starts everything looks working but jerky, > I need to move mouse around to get some windows redrawn, > [glx]gears print warning message about not getting vblank interrupts > and outputs something about 1-2 frames per 5 seconds. >=20 > The inspectation with vmstat -i has shown that the card generates > interrupts only during the first start of X server. >=20 > If I set hw.pci.enable_msi=3D"0" everything is working fine (start X serv= er > multiple times, switch consoles, [glx]gears, number of irq16-s > is increasing, ...). irq16 is likely shared, so this may or may not be true... At least in some cases, I was seeing the interrupt handler processing events when some other device on the shared interrupt fired. Interrupts on Intel have been a real pain. There is a drm specific tuneable for disabling msi hw.drm.msi=3D0. I have a patch which I'm currently using on my g45 that overhauls the way that we handle interrupts. =20 http://people.freebsd.org/~rnoland/drm-intel-050209.patch Reports have been mixed with this, but it is working for me... robert. > I can't be sure it is only due to X upgrade, > I have upgraded the base system also (~2 weeks old CURRENT -> 03.05.2009)= . >=20 > Some quick to gather system details: >=20 > ~> uname -a > FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun May 3 03:04:41 C= EST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64=20 > (4 GB of RAM, Core2Duo, if it matters) I'm running the same. > >From pciconf -lv: > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x82761043 chip=3D0x29c28= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '(Bearlake) Integrated Graphics Controller' > class =3D display > subclass =3D VGA >=20 > >From dmesg with hw.pci.enable_msi=3D"0": > vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9= fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on p= ci0 > agp0: on vgapci0 > agp0: detected 7164k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 >=20 > >From dmesg with default settings: > vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9= fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on p= ci0 > agp0: on vgapci0 > agp0: detected 7164k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 >=20 > Thanks, > Alexey. > _______________________________________________ > 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 Robert Noland FreeBSD --=-jCo6m8UbreVdcbyNQWVK 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) iEYEABECAAYFAkn/PIUACgkQM4TrQ4qfROP7lACfXLxo05FsTz+NBpRIor3a5U2c SbEAoINxH3sYIzAUg9YdbHsnP/kZKMH4 =axQf -----END PGP SIGNATURE----- --=-jCo6m8UbreVdcbyNQWVK-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 19:22: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 152CA10656CD for ; Mon, 4 May 2009 19:22:24 +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 DB1BE8FC18 for ; Mon, 4 May 2009 19:22:23 +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 8FA0D46B8E; Mon, 4 May 2009 15:22:23 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 50EF88A022; Mon, 4 May 2009 15:22:22 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 4 May 2009 10:55:17 -0400 User-Agent: KMail/1.9.7 References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> In-Reply-To: <49F4A031.5010500@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041055.17812.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 04 May 2009 15:22:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Boris Samorodov Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 19:22:24 -0000 On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: > A few days ago I reported about problems when I try to print from > acroread8. For all but one of my systems the problem is solved now, see > below. > > On one system I also totally cleaned up the linux emulator part and > installed everything from the scratch. Now when I try to print I get the > following message: > > --------------------------------------------------------------- > Beim Drucken ist folgender Fehler aufgetreten... > '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version > GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ > Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not > defined' > --------------------------------------------------------------- > > libc.so.6 is from misc/compat6x. I am not able to detect any relevant > differences between my systems. You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that contains this into /compat/linux (probably called something like 'compat-libc'). Probably it would be nice to have a port for this (or include it in the linux base port) for acroread8 to depend on. I think this is a ports@ issue though. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 4 20:06: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 5D20E1065674 for ; Mon, 4 May 2009 20:06:02 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id A80118FC13 for ; Mon, 4 May 2009 20:06:01 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M14QJ-00076X-Kw; Mon, 04 May 2009 22:05:59 +0200 Message-ID: <49FF4A99.30605@gwdg.de> Date: Mon, 04 May 2009 22:05:45 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: John Baldwin References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> In-Reply-To: <200905041055.17812.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Boris Samorodov , freebsd-current@freebsd.org Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 20:06:02 -0000 John, thank you for answering. On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >> A few days ago I reported about problems when I try to print from >> acroread8. For all but one of my systems the problem is solved now, see >> below. >> >> On one system I also totally cleaned up the linux emulator part and >> installed everything from the scratch. Now when I try to print I get the >> following message: >> >> --------------------------------------------------------------- >> Beim Drucken ist folgender Fehler aufgetreten... >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >> defined' >> --------------------------------------------------------------- >> >> libc.so.6 is from misc/compat6x. I am not able to detect any relevant >> differences between my systems. > > You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that > contains this into /compat/linux (probably called something > like 'compat-libc'). Probably it would be nice to have a port for this (or > include it in the linux base port) for acroread8 to depend on. I think this > is a ports@ issue though. > On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> libc-2.7.so'. #pkg_info -W /compat/linux/lib/libc-2.7.so /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 But there is another libc.so.6: #pkg_info -W /usr/local/lib/compat/libc.so.6 /usr/local/lib/compat/libc.so.6 was installed by package compat6x-i386-6.4.604000.200810 I have the CURRENT systems with, as far as I can see, exact the same configuration. On all my other systems printing from acroread8 is ok. Because of that I opened this thread :-( I have no idea where to look next, Rainer From owner-freebsd-current@FreeBSD.ORG Mon May 4 20:12: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 E03F210656F3 for ; Mon, 4 May 2009 20:12:17 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 9A65E8FC28 for ; Mon, 4 May 2009 20:12:17 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1M14WI-000N5D-Bj; Tue, 05 May 2009 00:12:10 +0400 To: Rainer Hurling References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> <49FF4A99.30605@gwdg.de> From: Boris Samorodov Date: Tue, 05 May 2009 00:12:09 +0400 In-Reply-To: <49FF4A99.30605@gwdg.de> (Rainer Hurling's message of "Mon\, 04 May 2009 22\:05\:45 +0200") Message-ID: <37287478@h30.sp.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 20:12:18 -0000 On Mon, 04 May 2009 22:05:45 +0200 Rainer Hurling wrote: > John, thank you for answering. > On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: > >> A few days ago I reported about problems when I try to print from > >> acroread8. For all but one of my systems the problem is solved now, > >> see below. > >> > >> On one system I also totally cleaned up the linux emulator part and > >> installed everything from the scratch. Now when I try to print I > >> get the following message: > >> > >> --------------------------------------------------------------- > >> Beim Drucken ist folgender Fehler aufgetreten... > >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version > >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ > >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not > >> defined' > >> --------------------------------------------------------------- > >> > >> libc.so.6 is from misc/compat6x. I am not able to detect any > >> relevant differences between my systems. > > > > You need a Linux libc.so.6 in /compat/linux. You need to install an > > RPM that contains this into /compat/linux (probably called something > > like 'compat-libc'). Probably it would be nice to have a port for > > this (or include it in the linux base port) for acroread8 to depend > > on. I think this is a ports@ issue though. > > > On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> > libc-2.7.so'. > #pkg_info -W /compat/linux/lib/libc-2.7.so > /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 > But there is another libc.so.6: > #pkg_info -W /usr/local/lib/compat/libc.so.6 > /usr/local/lib/compat/libc.so.6 was installed by package > compat6x-i386-6.4.604000.200810 > I have the CURRENT systems with, as far as I can see, exact the same > configuration. On all my other systems printing from acroread8 is > ok. Because of that I opened this thread :-( > I have no idea where to look next, Did you compare ktrace/linux_kdump at a system w/o problems and a system with this problem? WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Mon May 4 20:15: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 2780B1065676 for ; Mon, 4 May 2009 20:15:45 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id DA9BC8FC22 for ; Mon, 4 May 2009 20:15:44 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M14Zj-00047H-BA; Mon, 04 May 2009 22:15:43 +0200 Message-ID: <49FF4CE5.3090307@gwdg.de> Date: Mon, 04 May 2009 22:15:33 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: John Baldwin References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> In-Reply-To: <200905041055.17812.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Boris Samorodov , freebsd-current@freebsd.org Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 20:15:45 -0000 On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >> A few days ago I reported about problems when I try to print from >> acroread8. For all but one of my systems the problem is solved now, see >> below. >> >> On one system I also totally cleaned up the linux emulator part and >> installed everything from the scratch. Now when I try to print I get the >> following message: >> >> --------------------------------------------------------------- >> Beim Drucken ist folgender Fehler aufgetreten... >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >> defined' >> --------------------------------------------------------------- >> >> libc.so.6 is from misc/compat6x. I am not able to detect any relevant >> differences between my systems. > > You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that > contains this into /compat/linux (probably called something > like 'compat-libc'). Probably it would be nice to have a port for this (or > include it in the linux base port) for acroread8 to depend on. I think this > is a ports@ issue though. > I forgot to mention that Boris asked me to change from current@ to emulation@. So the follow up should be on emulation@ :-) Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Mon May 4 20:20: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 A2606106566B for ; Mon, 4 May 2009 20:20:52 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 340468FC18 for ; Mon, 4 May 2009 20:20:52 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M14eC-0006qw-EI; Mon, 04 May 2009 22:20:20 +0200 Message-ID: <49FF4DFA.7050101@gwdg.de> Date: Mon, 04 May 2009 22:20:10 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Boris Samorodov References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> <49FF4A99.30605@gwdg.de> <37287478@h30.sp.ipt.ru> In-Reply-To: <37287478@h30.sp.ipt.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 20:20:52 -0000 On 04.05.2009 22:12 (UTC+2), Boris Samorodov wrote: > On Mon, 04 May 2009 22:05:45 +0200 Rainer Hurling wrote: > >> John, thank you for answering. > >> On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: >>> On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >>>> A few days ago I reported about problems when I try to print from >>>> acroread8. For all but one of my systems the problem is solved now, >>>> see below. >>>> >>>> On one system I also totally cleaned up the linux emulator part and >>>> installed everything from the scratch. Now when I try to print I >>>> get the following message: >>>> >>>> --------------------------------------------------------------- >>>> Beim Drucken ist folgender Fehler aufgetreten... >>>> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >>>> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >>>> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >>>> defined' >>>> --------------------------------------------------------------- >>>> >>>> libc.so.6 is from misc/compat6x. I am not able to detect any >>>> relevant differences between my systems. >>> You need a Linux libc.so.6 in /compat/linux. You need to install an >>> RPM that contains this into /compat/linux (probably called something >>> like 'compat-libc'). Probably it would be nice to have a port for >>> this (or include it in the linux base port) for acroread8 to depend >>> on. I think this is a ports@ issue though. >>> > >> On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> >> libc-2.7.so'. > >> #pkg_info -W /compat/linux/lib/libc-2.7.so >> /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 > >> But there is another libc.so.6: > >> #pkg_info -W /usr/local/lib/compat/libc.so.6 >> /usr/local/lib/compat/libc.so.6 was installed by package >> compat6x-i386-6.4.604000.200810 > >> I have the CURRENT systems with, as far as I can see, exact the same >> configuration. On all my other systems printing from acroread8 is >> ok. Because of that I opened this thread :-( > >> I have no idea where to look next, > > Did you compare ktrace/linux_kdump at a system w/o problems and > a system with this problem? Yes, I reported about it on emulation@ on May 1st. It was very difficult because the are so many places acroread is looking for or working with 'libc.so.6'. I listed many messages before the error message appears. Please see on emulation@. Rainer Hurling > WBR From owner-freebsd-current@FreeBSD.ORG Mon May 4 21:07: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 D8516106567B for ; Mon, 4 May 2009 21:07:59 +0000 (UTC) (envelope-from onemda@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 332DD8FC25 for ; Mon, 4 May 2009 21:07:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so3986177bwz.43 for ; Mon, 04 May 2009 14:07: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 :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dO0CsB3PcBsouWGp+EdtQGH2RBEox3NpLulQtqThxkA=; b=h5oQtc1mOLeFtg24XirYHHaIipngniim4jXzqXPZe/H2dqPd+tbigqjIFwybpB8GWF YfrXXabu2iqV/5crqgDC9GN1wWNV/A37UDFltnWJJqFfq1vn+24GFjSWFAfIH/3d90vn /+RfBFNBin3xPmsGADB0XrJJzc6KsZyyQG3hs= 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=GQqd0EvBnSr4QG2xDQt25+L2ivPVd8f2h3thekOiyzZxWrCWdFh+0P3W9vbw90GwOt gkmQusI6nAW7xhzmzyDKXmucSAxKRceRXiF1ALBw8OnoXAKiC1tjhVq9j55osZQVJX26 qoOf59w5v/vFiQ85McsTmXgIOTnfScuG7YKDE= MIME-Version: 1.0 Received: by 10.239.180.146 with SMTP id i18mr320776hbg.142.1241471277971; Mon, 04 May 2009 14:07:57 -0700 (PDT) In-Reply-To: References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> <49FF057B.5000602@freebsd.org> Date: Mon, 4 May 2009 23:07:57 +0200 Message-ID: <3a142e750905041407g30a5d31cj64e7e64e1f428d0d@mail.gmail.com> From: "Paul B. Mahol" To: Scott Ullrich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , Dmitry Marakasov , freebsd-current@freebsd.org Subject: Re: geom_part X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 21:08:00 -0000 On 5/4/09, Scott Ullrich wrote: > On Mon, May 4, 2009 at 11:10 AM, Tim Kientzle wrote: >> What are the plans for 8.0? Will bsdlabel and fdisk >> be fixed? Or removed? They are going to be fixed. > fdisk and bsdlabel are working fine as of a few days ago. We use > both inside the BSDInstaller which still works OK. Then both OP and I live in alternate space :-) > Paul, what exactly is broken? -- Paul From owner-freebsd-current@FreeBSD.ORG Mon May 4 22:21: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 D9A55106566C for ; Mon, 4 May 2009 22:21:02 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF5B8FC13 for ; Mon, 4 May 2009 22:20:56 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.40,293,1238968800"; d="scan'208";a="272131731" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 05 May 2009 00:20:54 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id AF1AF1B0765; Tue, 5 May 2009 00:20:54 +0200 (CEST) Date: Tue, 05 May 2009 00:20:48 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200905042220481e86ffa80000275b-a_best01+ Cc: Subject: timeout with pata dvd-drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 22:21:03 -0000 This is a MIME encoded multipart message. --+permail-200905042220481e86ffa80000275b-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi everybody, i'm experiencing this issue for quite some time now. i already filed a PR about it and wrote several mails to various mailinglists without success. :( the problem is that my pata-dvddrive takes forever to access a cdr, because i get a lot of timeouts. booting with a cdr inserted takes > 5 minutes. you can find the PR here: http://www.freebsd.org/cgi/query-pr.cgi?pr=133122 i've attached a verbose dmesg. the problem seems to start in line 1389. right now i'm running r191768M. cheers. alex --+permail-200905042220481e86ffa80000275b-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="messages" TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBzeXNsb2dkOiBrZXJuZWwgYm9vdCBmaWxlIGlzIC9i b290L2tlcm5lbC9rZXJuZWwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1heGxh dD0weDAwICgwIG5zKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaW50cGluPWEs IGlycT01Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGUzMDAsIHNpemUgIDUsIGVuYWJsZWQKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklO VEEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIwOiBzbG90IDI5IElOVEEg aGFyZHdpcmVkIHRvIElSUSAyMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTM1LCByZXZpZD0weDAyCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGlu dHBpbj1iLCBpcnE9MTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsyMF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZTQwMCwgc2l6ZSAgNSwgZW5hYmxlZApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9y IDAuMjkuSU5UQgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjA6IHNsb3Qg MjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE5Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzYsIHJldmlkPTB4MDIKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVu Yz0yCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjbGFzcz0wYy0wMy0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjbWRy ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaW50cGluPWMsIGlycT0zCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBt YXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGU1MDAsIHNpemUgIDUsIGVu YWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIwOiBtYXRjaGVkIGVu dHJ5IGZvciAwLjI5LklOVEMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIw OiBzbG90IDI5IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTNhLCByZXZpZD0weDAy Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBkb21haW49MCwgYnVzPTAsIHNsb3Q9 MjksIGZ1bmM9NwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogY2xhc3M9MGMtMDMt MjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGludHBpbj1hLCBpcnE9NQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJh c2UgMHhmODIwNDAwMCwgc2l6ZSAxMCwgZW5hYmxlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJR IDIzCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDI0NGUsIHJldmlkPTB4OTIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMCwgZnVuYz0wCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBjbGFzcz0wNi0wNC0wMSwgaGRydHlwZT0weDAxLCBtZmRldj0wCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAx MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyOTE2LCByZXZpZD0weDAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAy MTAsIGNhY2hlbG5zej0wIChkd29yZHMpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MjkyMCwgcmV2aWQ9MHgwMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgw MmIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpbnRwaW49YiwgaXJxPTI1 NQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG93ZXJzcGVjIDMgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBb MjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGYwMDAsIHNpemUgIDQsIGVuYWJs ZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsyNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmMwMCwgc2l6ZSAgNCwgZW5hYmxlZApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTMwLCBy ZXZpZD0weDAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBkb21haW49MCwgYnVz PTAsIHNsb3Q9MzEsIGZ1bmM9MwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogY2xh c3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogY21kcmVnPTB4MDAwMywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChk d29yZHMpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGludHBpbj1jLCBpcnE9MwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4Zjgy MDYwMDAsIHNpemUgIDgsIGVuYWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IG1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTAwLCBzaXplICA1LCBl bmFibGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4zMS5JTlRDCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2li MDogc2xvdCAzMSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkyNiwgcmV2aWQ9MHgw MgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTMxLCBmdW5jPTUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNsYXNzPTAxLTAx LTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBpbnRwaW49YiwgaXJxPTExCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ZTcwMCwgc2l6ZSAgMywgZW5hYmxlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlODAwLCBz aXplICAyLCBlbmFibGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMThd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGU5MDAsIHNpemUgIDMsIGVuYWJsZWQK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsxY106IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4ZWEwMCwgc2l6ZSAgMiwgZW5hYmxlZApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2Ug MHhlYjAwLCBzaXplICA0LCBlbmFibGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBtYXBbMjRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGVjMDAsIHNpemUgIDQs IGVuYWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjMxLklOVEIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBj aWIwOiBzbG90IDMxIElOVEIgaGFyZHdpcmVkIHRvIElSUSAxOQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNpYjE6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAx LjAgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjE6ICAgZG9t YWluICAgICAgICAgICAgMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjE6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhjMDAwLTB4Y2ZmZgpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmNDAw MDAwMC0weGY3ZmZmZmZmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMTog ICBwcmVmZXRjaGVkIGRlY29kZSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IHBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0w eDA2MjIsIHJldmlkPTB4YTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGRvbWFp bj0wLCBidXM9MSwgc2xvdD0wLCBmdW5jPTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9OCAoZHdvcmRzKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpbnRwaW49YSwgaXJxPTEwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IE1TSSBzdXBwb3J0cyAxIG1l c3NhZ2UsIDY0IGJpdApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjYwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5 IHJhbmdlIDB4ZjYwMDAwMDAtMHhmNmZmZmZmZjogZ29vZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogbWFwWzE0XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwg YmFzZSAweGUwMDAwMDAwLCBzaXplIDI4LCBlbmFibGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGUwMDAwMDAwLTB4ZWZm ZmZmZmY6IGdvb2QKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsxY106IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY0MDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMTogcmVxdWVzdGVkIG1lbW9yeSBy YW5nZSAweGY0MDAwMDAwLTB4ZjVmZmZmZmY6IGdvb2QKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IG1hcFsyNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YzAwMCwg c2l6ZSAgNywgZW5hYmxlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjE6 IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhjMDAwLTB4YzA3ZjogaW4gcmFuZ2UKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjA6IHNsb3QgMSBJTlRBIGhhcmR3 aXJlZCB0byBJUlEgMTYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIxOiBz bG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiB2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGMwMDAtMHhj MDdmIG1lbSAweGY2MDAwMDAwLTB4ZjZmZmZmZmYsMHhlMDAwMDAwMC0weGVmZmZmZmZmLDB4ZjQw MDAwMDAtMHhmNWZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBudmlkaWEwOiA8R2VGb3JjZSA5NjAwIEdUPiBvbiB2Z2Fw Y2kwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB2Z2FwY2kwOiBjaGlsZCBudmlk aWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2J1c21hc3RlcgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogdmdhcGNpMDogY2hpbGQgbnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9p bwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdmdhcGNpMDogUmVzZXJ2ZWQgMHgx MDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmNjAwMDAwMApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdmdhcGNpMDogUmVzZXJ2ZWQgMHgxMDAwMDAwMCBieXRl cyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4ZTAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHZnYXBjaTA6IFJlc2VydmVkIDB4MjAwMDAwMCBieXRlcyBmb3IgcmlkIDB4 MWMgdHlwZSAzIGF0IDB4ZjQwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHZnYXBjaTA6IGNoaWxkIG52aWRpYTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kg SVJRIDE2KSB0byBsYXBpYyAwIHZlY3RvciA0OQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogbnZpZGlhMDogW0dJQU5ULUxPQ0tFRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IG52aWRpYTA6IFtJVEhSRUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZTIw MC0weGUyMWYgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHVoY2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHhlMjAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpMDog W01QU0FGRV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2kwOiBbSVRIUkVB RF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2kwOiBMZWdTdXAgPSAweDBm NTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVzYnVzMDogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiB1aGNpMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBv cnQgMHhlMDAwLTB4ZTAxZiBpcnEgMjEgYXQgZGV2aWNlIDI2LjEgb24gcGNpMApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWhjaTE6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJp ZCAweDIwIHR5cGUgNCBhdCAweGUwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byBsYXBpYyAwIHZlY3Rv ciA1MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWhjaTE6IFtNUFNBRkVdCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpMTogW0lUSFJFQURdCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpMTogTGVnU3VwID0gMHgwZjUwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1c2J1czE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVT QiBjb250cm9sbGVyPiBvbiB1aGNpMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog dWhjaTI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZTEwMC0w eGUxMWYgaXJxIDE4IGF0IGRldmljZSAyNi4yIG9uIHBjaTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBl IDQgYXQgMHhlMTAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpb2FwaWMwOiBy b3V0aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gbGFwaWMgMCB2ZWN0b3IgNTEKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2kyOiBbTVBTQUZFXQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogdWhjaTI6IFtJVEhSRUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogdWhjaTI6IExlZ1N1cCA9IDB4MGY1MApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogdXNidXMyOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gb24gdWhjaTIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGVoY2kwOiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGY4MjA1MDAwLTB4Zjgy MDUzZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG9uIHBjaTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGVoY2kwOiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlw ZSAzIGF0IDB4ZjgyMDUwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGVoY2kw OiBbTVBTQUZFXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZWhjaTA6IFtJVEhS RUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdXNidXMzOiBFSENJIHZlcnNp b24gMS4wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1c2J1czM6IDxJbnRlbCA4 MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiA8SW50ZWwgODI4MDFJIEhpZ2ggRGVmaW5pdGlvbiBB dWRpbyBDb250cm9sbGVyPiBtZW0gMHhmODIwMDAwMC0weGY4MjAzZmZmIGlycSAyMiBhdCBkZXZp Y2UgMjcuMCBvbiBwY2kwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog SERBIERyaXZlciBSZXZpc2lvbjogMjAwOTA0MDFfMDEzMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6IFJlc2VydmVkIDB4NDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlw ZSAzIGF0IDB4ZjgyMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IHVzaW5nIElSUSAyNTYgZm9yIE1T SQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbXNpOiBBc3NpZ25pbmcgTVNJIElS USAyNTYgdG8gbG9jYWwgQVBJQyAwIHZlY3RvciA1MgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogW0lUSFJFQURdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2li MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMjogICBkb21haW4gICAgICAgICAg ICAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMjogICBzZWNvbmRhcnkg YnVzICAgICAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMjogICBzdWJv cmRpbmF0ZSBidXMgICAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liMjog ICBJL08gZGVjb2RlICAgICAgICAweGIwMDAtMHhiZmZmCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY2liMjogICBubyBwcmVmZXRjaGVkIGRlY29kZQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBpcnEgMTkgYXQgZGV2aWNlIDI4LjMgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNpYjM6ICAgZG9tYWluICAgICAgICAgICAgMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6ICAgSS9PIGRlY29kZSAgICAgICAg MHhkMDAwLTB4ZGZmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6ICAg bWVtb3J5IGRlY29kZSAgICAgMHhmODAwMDAwMC0weGY4MGZmZmZmCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY2liMzogICBubyBwcmVmZXRjaGVkIGRlY29kZQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9MwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgx OTdiLCBkZXY9MHgyMzYzLCByZXZpZD0weDAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBkb21haW49MCwgYnVzPTMsIHNsb3Q9MCwgZnVuYz0wCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBjbGFzcz0wMS0wMS04NSwgaGRydHlwZT0weDAwLCBtZmRldj0wCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAx MCwgY2FjaGVsbnN6PTggKGR3b3JkcykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaW50cGluPWEsIGlycT0xMQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMTBd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQwMDAsIHNpemUgIDMsIGVuYWJsZWQK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJh bmdlIDB4ZDAwMC0weGQwMDc6IGluIHJhbmdlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBtYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQxMDAsIHNpemUg IDIsIGVuYWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIzOiByZXF1 ZXN0ZWQgSS9PIHJhbmdlIDB4ZDEwMC0weGQxMDM6IGluIHJhbmdlCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBtYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eGQyMDAsIHNpemUgIDMsIGVuYWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZDIwMC0weGQyMDc6IGluIHJhbmdlCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweGQzMDAsIHNpemUgIDIsIGVuYWJsZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZDMwMC0weGQzMDM6IGlu IHJhbmdlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ0MDAsIHNpemUgIDQsIGVuYWJsZWQKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZDQw MC0weGQ0MGY6IGluIHJhbmdlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBtYXBb MjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmODAwMDAwMCwgc2l6ZSAxMywgZW5h YmxlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjM6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHhmODAwMDAwMC0weGY4MDAxZmZmOiBnb29kCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY2liMzogbWF0Y2hlZCBlbnRyeSBmb3IgMy4wLklOVEEKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWIzOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQg dG8gSVJRIDE5Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGFwY2kwOiA8Sk1p Y3JvbiBKTUIzNjMgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4ZDAwMC0weGQwMDcsMHhkMTAw LTB4ZDEwMywweGQyMDAtMHhkMjA3LDB4ZDMwMC0weGQzMDMsMHhkNDAwLTB4ZDQwZiBtZW0gMHhm ODAwMDAwMC0weGY4MDAxZmZmIGlycSAxOSBhdCBkZXZpY2UgMC4wIG9uIHBjaTMKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9y IHJpZCAweDIwIHR5cGUgNCBhdCAweGQ0MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQQ0kgSVJRIDE5KSB0byBsYXBpYyAwIHZl Y3RvciA1MwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMDogW01QU0FG RV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTA6IFtJVEhSRUFEXQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMDogUmVzZXJ2ZWQgMHgyMDAw IGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhmODAwMDAwMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMDogQUhDSSBjYWxsZWQgZnJvbSB2ZW5kb3Igc3BlY2lm aWMgZHJpdmVyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGFwY2kwOiBBSENJ IFZlcnNpb24gMDEuMDAgY29udHJvbGxlciB3aXRoIDIgcG9ydHMgUE0gc3VwcG9ydGVkCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRh cGNpMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMjogQUhDSSByZXNldC4u LgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMjogaGFyZHdhcmUgcmVzZXQg Li4uCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEyOiBTQVRBIGNvbm5lY3Qg dGltZW91dCBzdGF0dXM9MDAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGF0YTI6IEFIQ0kgcmVzZXQgZG9uZTogcGh5IHJlc2V0IGZvdW5kIG5vIGRldmljZQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMjogW01QU0FGRV0KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGF0YTI6IFtJVEhSRUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTM6IEFIQ0kgcmVzZXQuLi4KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGF0YTM6IGhhcmR3YXJlIHJlc2V0IC4uLgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMzogU0FUQSBjb25uZWN0IHRpbWVvdXQgc3RhdHVzPTAw MDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEzOiBBSENJIHJlc2V0 IGRvbmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGF0YTM6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBhdGEzOiBbSVRIUkVBRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6 IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFwY2kwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBhdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAw eGQwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTA6IFJlc2VydmVk IDB4NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4ZDEwMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0 MT0wMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDA9MHg1MCBl cnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYXRhNDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAw IGRldmljZXM9MHgyMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDog W01QU0FGRV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IFtJVEhSRUFE XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjQgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNpYjQ6ICAgZG9tYWluICAgICAgICAgICAgMApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgNApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAg ICAgMHhhMDAwLTB4YWZmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjQ6 ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTQKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHVoY2kzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gcG9ydCAweGUzMDAtMHhlMzFmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpMzogUmVzZXJ2ZWQgMHgyMCBieXRlcyBm b3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZTMwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIGxhcGljIDAg dmVjdG9yIDU0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpMzogW01QU0FG RV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2kzOiBbSVRIUkVBRF0KTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2kzOiBMZWdTdXAgPSAweDA1N2EKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVzYnVzNDogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiB1aGNpNDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhl NDAwLTB4ZTQxZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogdWhjaTQ6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweGU0MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVoY2k0 OiBbTVBTQUZFXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWhjaTQ6IFtJVEhS RUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWhjaTQ6IExlZ1N1cCA9IDB4 MDUxMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdXNidXM1OiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHVoY2k1OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4g cG9ydCAweGU1MDAtMHhlNTFmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpNTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3Ig cmlkIDB4MjAgdHlwZSA0IGF0IDB4ZTUwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogdWhjaTU6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNp NTogW0lUSFJFQURdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aGNpNTogTGVn U3VwID0gMHgwNTEwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1c2J1czY6IDxJ bnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpNQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogZWhjaTE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4ZjgyMDQwMDAtMHhmODIwNDNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5 Ljcgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZWhjaTE6IFJlc2Vy dmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmODIwNDAwMApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZWhjaTE6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBlaGNpMTogW0lUSFJFQURdCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiB1c2J1czc6IEVIQ0kgdmVyc2lvbiAxLjAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHVzYnVzNzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250 cm9sbGVyPiBvbiBlaGNpMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjU6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liNTogICBkb21haW4gICAgICAgICAgICAwCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liNTogICBzZWNvbmRhcnkgYnVzICAgICA1 Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liNTogICBzdWJvcmRpbmF0ZSBi dXMgICA1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2liNTogICBJL08gZGVj b2RlICAgICAgICAweGYwMDAtMHhmZmYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHBjaWI1OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjgxMDAwMDAtMHhmODFmZmZmZgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNpYjU6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWI1OiAgIFN1YnRyYWN0aXZlbHkg ZGVjb2RlZCBicmlkZ2UuCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY2k1OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cGNpNTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz01Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDE2OGMsIGRldj0weDAwMTMsIHJldmlkPTB4MDEKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGRvbWFpbj0wLCBidXM9NSwgc2xvdD0xLCBm dW5jPTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNsYXNzPTAyLTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNt ZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdu dD0weDBhICgyNTAwIG5zKSwgbWF4bGF0PTB4MWMgKDcwMDAgbnMpCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBpbnRwaW49YSwgaXJxPTExCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IG1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGY4MTAwMDAwLCBzaXplIDE2LCBlbmFibGVkCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBwY2liNTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY4MTAwMDAwLTB4 ZjgxMGZmZmY6IGdvb2QKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjaWI1OiBt YXRjaGVkIGVudHJ5IGZvciA1LjEuSU5UQQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogcGNpYjU6IHNsb3QgMSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTkKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IDxBdGhlcm9zIDUyMTI+IG1lbSAweGY4MTAwMDAwLTB4 ZjgxMGZmZmYgaXJxIDE5IGF0IGRldmljZSAxLjAgb24gcGNpNQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRoMDogUmVzZXJ2ZWQgMHgxMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSAzIGF0IDB4ZjgxMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0 aDA6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGgwOiBbSVRI UkVBRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IDExYiByYXRlczog MU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGF0aDA6IDExZyByYXRlczogMU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMgNk1icHMgOU1i cHMgMTJNYnBzIDE4TWJwcyAyNE1icHMgMzZNYnBzIDQ4TWJwcyA1NE1icHMKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IHR1cmJvRyByYXRlczogMU1icHMgMk1icHMgNS41 TWJwcyAxMU1icHMgNk1icHMgOU1icHMgMTJNYnBzIDE4TWJwcyAyNE1icHMgMzZNYnBzIDQ4TWJw cyA1NE1icHMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IEFSMjQxMyBt YWMgNy45IFJGMjQxMyBwaHkgNC41Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh dGgwOiBVc2UgaHcgcXVldWUgMSBmb3IgV01FX0FDX0JFIHRyYWZmaWMKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IFVzZSBodyBxdWV1ZSAwIGZvciBXTUVfQUNfQksgdHJh ZmZpYwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVl IDIgZm9yIFdNRV9BQ19WSSB0cmFmZmljCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBhdGgwOiBVc2UgaHcgcXVldWUgMyBmb3IgV01FX0FDX1ZPIHRyYWZmaWMKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0aDA6IFVzZSBodyBxdWV1ZSA4IGZvciBDQUIgdHJhZmZp YwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVlIDkg Zm9yIGJlYWNvbnMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGlzYWIwOiA8UENJ LUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRhcGNpMTogPEludGVsIElDSDkgU0FUQTMwMCBjb250cm9sbGVyPiBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZjAwMC0weGYwMGYsMHhm YzAwLTB4ZmMwZiBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhdGFwY2kxOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBl IDQgYXQgMHhmMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGFwY2kxOiBS ZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDQgYXQgMHhmYzAwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNp MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMTogUmVzZXJ2ZWQgMHg4 IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgxZjAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGF0YXBjaTE6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlw ZSA0IGF0IDB4M2Y2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEwOiByZXNl dCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhdGEwOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEwOiBzdGF0MT0weDAwIGVycj0weDAx IGxzYj0weDAwIG1zYj0weDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEw OiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0 KSB0byBsYXBpYyAwIHZlY3RvciA1NQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog YXRhMDogW01QU0FGRV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTA6IFtJ VEhSRUFEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMTogPEFUQSBjaGFu bmVsIDE+IG9uIGF0YXBjaTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBj aTE6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGFwY2kxOiBSZXNlcnZlZCAweDEgYnl0ZXMg Zm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDM3NgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03ZgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGxhc3QgbWVzc2FnZSByZXBl YXRlZCAyMSB0aW1lcwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMTogc3Rh dDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogYXRhMTogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpb2FwaWMwOiByb3V0aW5nIGludHBp biAxNSAoSVNBIElSUSAxNSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTYKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGF0YTE6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBhdGExOiBbSVRIUkVBRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRh Y2hlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTI6IDxJbnRlbCBJ Q0g5IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGU3MDAtMHhlNzA3LDB4ZTgwMC0weGU4MDMs MHhlOTAwLTB4ZTkwNywweGVhMDAtMHhlYTAzLDB4ZWIwMC0weGViMGYsMHhlYzAwLTB4ZWMwZiBp cnEgMTkgYXQgZGV2aWNlIDMxLjUgb24gcGNpMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhcGNpMjogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0 IDB4ZWIwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMjogW01QU0FG RV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTI6IFtJVEhSRUFEXQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhcGNpMjogUmVzZXJ2ZWQgMHgxMCBi eXRlcyBmb3IgcmlkIDB4MjQgdHlwZSA0IGF0IDB4ZWMwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogYXRhNTogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTIKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSA0IGF0IDB4ZTcwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog YXRhcGNpMjogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhlODAw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE1OiByZXNldCB0cDEgbWFzaz0w MyBvc3RhdDA9N2Ygb3N0YXQxPTdmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh dGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDIxIHRpbWVzCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBhdGE1OiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE1OiByZXNldCB0cDIg c3RhdDA9ZmYgc3RhdDE9ZmYgZGV2aWNlcz0weDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGF0YTU6IFtNUFNBRkVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh dGE1OiBbSVRIUkVBRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTY6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBhdGFwY2kyOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweGU5 MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YXBjaTI6IFJlc2VydmVkIDB4 NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZWEwMApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRhNjogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03 ZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNjogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGxhc3QgbWVz c2FnZSByZXBlYXRlZCAyMSB0aW1lcwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog YXRhNjogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNjogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRl dmljZXM9MHgwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE2OiBbTVBTQUZF XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNjogW0lUSFJFQURdCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdHJ0YzE6IDxBVCByZWFsdGltZSBjbG9jaz4g cG9ydCAweDcwLTB4NzMgb24gYWNwaTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGF0cnRjMTogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0aW9uIDEw MDAwMDB1cykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNwdTA6IDxBQ1BJIENQ VT4gb24gYWNwaTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGNwdTA6IHN3aXRj aGluZyB0byBnZW5lcmljIEN4IG1vZGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGNvcmV0ZW1wMDogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBlc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1 ZW5jeSBDb250cm9sPiBvbiBjcHUwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBl c3Q6IENQVSBzdXBwb3J0cyBFbmhhbmNlZCBTcGVlZHN0ZXAsIGJ1dCBpcyBub3QgcmVjb2duaXpl ZC4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGVzdDogY3B1X3ZlbmRvciBHZW51 aW5lSW50ZWwsIG1zciA5MjUwOTI1MDYwMDA5MjUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGRldmljZV9hdHRhY2g6IGVzdDAgYXR0YWNoIHJldHVybmVkIDYKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IHA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250 cm9sPiBvbiBjcHUwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjcHUxOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjb3JldGVt cDE6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogZXN0OiBDUFUg c3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQuCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBlc3Q6IGNwdV92ZW5kb3IgR2VudWluZUludGVs LCBtc3IgOTI1MDkyNTA2MDAwOTI1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBk ZXZpY2VfYXR0YWNoOiBlc3QxIGF0dGFjaCByZXR1cm5lZCA2Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24g Y3B1MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDIwMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG5w X2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0 IGF0IDJjMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBU cnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM4MwpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDNjMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogUE5QIElkZW50aWZ5 IGNvbXBsZXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpc2FfcHJvYmVfY2hp bGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhOiBhdGEwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHZnYTogdmdh MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFn cyAweDEwMCBvbiBpc2EwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBzYzA6IFZH QSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBzYzA6IGZiMCwgdGVybWluYWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2Vu IHRlcm1pbmFsKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdmdhMDogPEdlbmVy aWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24g aXNhMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYWR2MDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhaGEwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGFpYzA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRr YmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDYwIG9uIGlzYTAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGF0cnRjMDogPEFUIFJlYWwgVGltZSBDbG9jaz4gYXQgcG9ydCAw eDcwIGlycSA4IG9uIGlzYTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0cnRj MDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEludGVycnVwdC4KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0cnRjMTogcmVtb3ZlZCBhcyB0aW1lLW9mLWRheSBj bG9jazogY2xvY2sgYXRydGMgaGFzIGhpZ2hlciByZXNvbHV0aW9uCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBhdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9j ayAocmVzb2x1dGlvbiAxMDAwMDAwdXMpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogY3MwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwIGlycSA2IGRy cSAyIG9uIGlzYTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGZlMDogbm90IHBy b2JlZCAoZGlzYWJsZWQpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpZTA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbGUw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IHBwYzAgZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiB1YXJ0MCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOCBp cnEgNCBvbiBpc2EwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1YXJ0MSBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOCBpcnEgMyBvbiBpc2EwCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiB1YXJ0Mjogbm90IHByb2JlZCAoZGlzYWJsZWQpCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiB1YXJ0Mzogbm90IHByb2JlZCAoZGlzYWJsZWQpCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcg UG5QIGRldmljZXMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IERldmljZSBjb25m aWd1cmF0aW9uIGZpbmlzaGVkLgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogUmVk dWNpbmcga2Vybi5tYXh2bm9kZXMgMTMzNjU0IC0+IDEwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcHJvY2ZzIHJlZ2lzdGVyZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGxpbnByb2NmcyByZWdpc3RlcmVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBsaW5zeXNmcyByZWdpc3RlcmVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBsYXBpYzogRGl2aXNvciAyLCBGcmVxdWVuY3kgMTY2NTAwNTgxIGh6Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjk5NzAx MDM3NyBIeiBxdWFsaXR5IC0xMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IFRp bWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IExpbnV4IEVMRiBleGVjIGhhbmRsZXIgaW5zdGFsbGVkCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBhdGEwOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMDogTmV3IGRldmljZXM6IDAwMDAw MDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1c2J1czA6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1c2J1czE6 IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiB1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiB1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdXNidXM0OiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdXNidXM1OiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdXNi dXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogdXNidXM3OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTAtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVk bWE9VURNQTEzMyBjYWJsZT00MCB3aXJlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiB1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNidXMwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1 Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2Vu Mi4xOiA8SW50ZWw+IGF0IHVzYnVzMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog dWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuMy4x OiA8SW50ZWw+IGF0IHVzYnVzMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWh1 YjM6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMzCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuNC4xOiA8 SW50ZWw+IGF0IHVzYnVzNApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWh1YjQ6 IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXM0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuNS4xOiA8SW50 ZWw+IGF0IHVzYnVzNQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWh1YjU6IDxJ bnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXM1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuNi4xOiA8SW50ZWw+ IGF0IHVzYnVzNgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWh1YjY6IDxJbnRl bCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXM2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBFeHBlbnNpdmUgdGltZW91dCg5 KSBmdW5jdGlvbjogMHhjMDVkZjkyOCgweGM3ZGJkNjkwKSAwLjAwMjAwODA3NiBzCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuNy4xOiA8SW50ZWw+IGF0IHVzYnVzNwpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWh1Yjc6IDxJbnRlbCBFSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM3Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBhZDA6IDIzODQ3NE1CIDxTQU1TVU5HIFNQMjUwNEMgVlQx MDAtNTA+IGF0IGF0YTAtbWFzdGVyIFNBVEEzMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGFkMDogNDg4Mzk1MDU1IHNlY3RvcnMgWzQ4NDUxOEMvMTZILzYzU10gMTYgc2VjdG9y cy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogR0VPTTogbmV3IGRpc2sgYWQwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh dGExOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogYXRhMTogTmV3IGRldmljZXM6IDAwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBhdGEyOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMjogTmV3IGRldmljZXM6IDAwMDAwMDAw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGEzOiBJZGVudGlmeWluZyBkZXZp Y2VzOiAwMDAwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhMzogTmV3 IGRldmljZXM6IDAwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0 OiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAyMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogYXRhNDogTmV3IGRldmljZXM6IDAwMDIwMDAxCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBhdGE0LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEx MDAgY2FibGU9NDAgd2lyZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNC1z bGF2ZTogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEzMyBjYWJsZT04MCB3aXJlCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhZDE6IDE1NzA2Nk1CIDxIaXRhY2hpIEhEUzcy MjUxNlZMQVQ4MCBWMzRPQTYzQT4gYXQgYXRhNC1tYXN0ZXIgVURNQTEwMApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYWQxOiAzMjE2NzI5NjAgc2VjdG9ycyBbMzE5MTIwQy8xNkgv NjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBhY2QwOiA8SEwtRFQtU1QgRFZEUkFNIEdTQS1IMTBOL0pMMTI+IERW RFIgZHJpdmUgYXQgYXRhNCBhcyBzbGF2ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYWNkMDogcmVhZCA4MjY4S0IvcyAoODI2OEtCL3MpIHdyaXRlIDgyNjhLQi9zICg4MjY4S0Iv cyksIDIwNDhLQiBidWZmZXIsIFVETUEzMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYWNkMDogUmVhZHM6IENEUiwgQ0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZE UkFNLCBwYWNrZXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGFjZDA6IFdyaXRl czogQ0RSLCBDRFJXLCBEVkRSLCBEVkRSQU0sIHRlc3Qgd3JpdGUsIGJ1cm5wcm9vZgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYWNkMDogQXVkaW86IHBsYXksIDI1NiB2b2x1bWUg bGV2ZWxzCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhY2QwOiBNZWNoYW5pc206 IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYWNkMDogTWVkaXVtOiBDRC1SIDEyMG1tIGRhdGEgZGlzYwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRhNTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTU6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNjogSWRlbnRpZnlpbmcgZGV2aWNl czogMDAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTY6IE5ldyBk ZXZpY2VzOiAwMDAwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 IFByb2JpbmcgY29kZWMgIzIuLi4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiBIREEgQ29kZWMgIzI6IFJlYWx0ZWsgQUxDODg1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogIEhEQSBDb2RlYyBJRDogMHgxMGVjMDg4NQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICBWZW5kb3I6IDB4MTBlYwpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICBEZXZpY2U6IDB4MDg4NQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgUmV2aXNpb246IDB4 MDEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFN0ZXBwaW5n OiAweDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogUENJIFN1YnZl bmRvcjogMHhhMDAyMTQ1OApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 IAlGb3VuZCBhdWRpbyBGRyBuaWQ9MSBzdGFydG5vZGU9MiBlbmRub2RlPTM5IHRvdGFsPTM3Ck1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogUHJvY2Vzc2luZyBhdWRpbyBGRyBjYWQ9MiBuaWQ9MS4u LgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IEdQSU86IDB4NDAwMDAw MDIgTnVtR1BJTz0yIE51bUdQTz0wIE51bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0xCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogIG5pZCAyMCAweDAxMDE0NDEwIGFz ICAxIHNlcSAgMCAgICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgR3Jl ZW4gbWlzYyA0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogIG5pZCAy MSAweDAxMDExNDEyIGFzICAxIHNlcSAgMiAgICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9j ICAxIGNvbG9yICAgQmxhY2sgbWlzYyA0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogIG5pZCAyMiAweDAxMDE2NDExIGFzICAxIHNlcSAgMSAgICAgIExpbmUtb3V0ICBK YWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICBPcmFuZ2UgbWlzYyA0Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogIG5pZCAyMyAweDAxMDEyNDE0IGFzICAxIHNlcSAgNCAg ICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyA0Ck1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogIG5pZCAyNCAweDAxYTE5YzQw IGFzICA0IHNlcSAgMCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAg IFBpbmsgbWlzYyAxMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBu aWQgMjUgMHgwMmExOWM1MCBhcyAgNSBzZXEgIDAgICAgICAgICAgIE1pYyAgSmFjayBqYWNrICAx IGxvYyAgMiBjb2xvciAgICBQaW5rIG1pc2MgMTIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgbmlkIDI2IDB4MDE4MTM0NGYgYXMgIDQgc2VxIDE1ICAgICAgIExpbmUt aW4gIEphY2sgamFjayAgMSBsb2MgIDEgY29sb3IgICAgQmx1ZSBtaXNjIDQKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgbmlkIDI3IDB4MDIyMTRjMjAgYXMgIDIgc2Vx ICAwICAgIEhlYWRwaG9uZXMgIEphY2sgamFjayAgMSBsb2MgIDIgY29sb3IgICBHcmVlbiBtaXNj IDEyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogIG5pZCAyOCAweDU5 MzMwMWYwIGFzIDE1IHNlcSAgMCAgICAgICAgICAgIENEICBOb25lIGphY2sgIDMgbG9jIDI1IGNv bG9yIFVua25vd24gbWlzYyAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTI5IDB4MDA0MDAwMDAgLT4gMHgwMDcwMDAwMApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBuaWQgMzAgMHgwMTRiNjEz MCBhcyAgMyBzZXEgIDAgICAgIFNQRElGLW91dCAgSmFjayBqYWNrIDExIGxvYyAgMSBjb2xvciAg T3JhbmdlIG1pc2MgMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBu aWQgMzEgMHgwMWNiNzE2MCBhcyAgNiBzZXEgIDAgICAgICBTUERJRi1pbiAgSmFjayBqYWNrIDEx IGxvYyAgMSBjb2xvciAgWWVsbG93IG1pc2MgMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6IFBhdGNoZWQgcGlucyBjb25maWd1cmF0aW9uOgpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBuaWQgMjAgMHgwMTAxNDQxMCBhcyAgMSBzZXEgIDAg ICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgIEdyZWVuIG1pc2MgNApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBuaWQgMjEgMHgwMTAxMTQx MiBhcyAgMSBzZXEgIDIgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAg IEJsYWNrIG1pc2MgNApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBu aWQgMjIgMHgwMTAxNjQxMSBhcyAgMSBzZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAx IGxvYyAgMSBjb2xvciAgT3JhbmdlIG1pc2MgNApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICBuaWQgMjMgMHgwMTAxMjQxNCBhcyAgMSBzZXEgIDQgICAgICBMaW5lLW91 dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgICBHcmV5IG1pc2MgNApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBuaWQgMjQgMHgwMWExOWM0MCBhcyAgNCBzZXEg IDAgICAgICAgICAgIE1pYyAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgICBQaW5rIG1pc2Mg MTIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgbmlkIDI1IDB4MDJh MTljNTAgYXMgIDUgc2VxICAwICAgICAgICAgICBNaWMgIEphY2sgamFjayAgMSBsb2MgIDIgY29s b3IgICAgUGluayBtaXNjIDEyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogIG5pZCAyNiAweDAxODEzNDRmIGFzICA0IHNlcSAxNSAgICAgICBMaW5lLWluICBKYWNrIGph Y2sgIDEgbG9jICAxIGNvbG9yICAgIEJsdWUgbWlzYyA0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogIG5pZCAyNyAweDAyMjE0YzIwIGFzICAyIHNlcSAgMCAgICBIZWFk cGhvbmVzICBKYWNrIGphY2sgIDEgbG9jICAyIGNvbG9yICAgR3JlZW4gbWlzYyAxMgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBuaWQgMjggMHg1OTMzMDFmMCBhcyAx NSBzZXEgIDAgICAgICAgICAgICBDRCAgTm9uZSBqYWNrICAzIGxvYyAyNSBjb2xvciBVbmtub3du IG1pc2MgMSBbRElTQUJMRURdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogIG5pZCAzMCAweDAxNGI2MTMwIGFzICAzIHNlcSAgMCAgICAgU1BESUYtb3V0ICBKYWNrIGph Y2sgMTEgbG9jICAxIGNvbG9yICBPcmFuZ2UgbWlzYyAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogIG5pZCAzMSAweDAxY2I3MTYwIGFzICA2IHNlcSAgMCAgICAgIFNQ RElGLWluICBKYWNrIGphY2sgMTEgbG9jICAxIGNvbG9yICBZZWxsb3cgbWlzYyAxCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogNiBhc3NvY2lhdGlvbnMgZm91bmQ6Ck1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogQXNzb2NpYXRpb24gMCAoMSkg b3V0OgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQaW4gbmlkPTIw IHNlcT0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogIFBpbiBuaWQ9 MjIgc2VxPTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgUGluIG5p ZD0yMSBzZXE9MgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQaW4g bmlkPTIzIHNlcT00Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogQXNz b2NpYXRpb24gMSAoMikgb3V0OgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6ICBQaW4gbmlkPTI3IHNlcT0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogQXNzb2NpYXRpb24gMiAoMykgb3V0OgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICBQaW4gbmlkPTMwIHNlcT0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogQXNzb2NpYXRpb24gMyAoNCkgaW46Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogIFBpbiBuaWQ9MjQgc2VxPTAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgUGluIG5pZD0yNiBzZXE9MTUKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiBBc3NvY2lhdGlvbiA0ICg1KSBpbjoKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgUGluIG5pZD0yNSBzZXE9MApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IEFzc29jaWF0aW9uIDUgKDYpIGluOgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQaW4gbmlkPTMxIHNlcT0w Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogVHJhY2luZyBhc3NvY2lh dGlvbiAwICgxKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQaW4g MjAgdHJhY2VkIHRvIERBQyAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogIFBpbiAyMiB0cmFjZWQgdG8gREFDIDMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgUGluIDIxIHRyYWNlZCB0byBEQUMgNApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICBQaW4gMjMgdHJhY2VkIHRvIERBQyA1Ck1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogQXNzb2NpYXRpb24gMCAoMSkgdHJhY2Ugc3VjY2Vl ZGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogVHJhY2luZyBhc3Nv Y2lhdGlvbiAxICgyKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQ aW4gMjcgdHJhY2VkIHRvIERBQyAzNwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6IEFzc29jaWF0aW9uIDEgKDIpIHRyYWNlIHN1Y2NlZWRlZApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IFRyYWNpbmcgYXNzb2NpYXRpb24gMiAoMykKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgUGluIDMwIHRyYWNlZCB0byBEQUMg NgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IEFzc29jaWF0aW9uIDIg KDMpIHRyYWNlIHN1Y2NlZWRlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6IFRyYWNpbmcgYXNzb2NpYXRpb24gMyAoNCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgUGluIDI0IHRyYWNlZCB0byBBREMgNwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICBQaW4gMjYgdHJhY2VkIHRvIEFEQyA3Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogQXNzb2NpYXRpb24gMyAoNCkgdHJhY2Ugc3Vj Y2VlZGVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogVHJhY2luZyBh c3NvY2lhdGlvbiA0ICg1KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICBQaW4gMjUgdHJhY2VkIHRvIEFEQyA4Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogQXNzb2NpYXRpb24gNCAoNSkgdHJhY2Ugc3VjY2VlZGVkCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiA1ICg2KQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBVbmFibGUgdG8gdHJhY2UgcGlu IDMxIHRvIEFEQyA5LCB1bmRvIHRyYWNlcwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6ICBQaW4gMzEgdHJhY2VkIHRvIEFEQyAxMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6IEFzc29jaWF0aW9uIDUgKDYpIHRyYWNlIHN1Y2NlZWRlZApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IFRyYWNpbmcgaW5wdXQgbW9uaXRv cgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICBUcmFjaW5nIG5pZCAx MSB0byBvdXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgbmlkIDEx IGlzIGlucHV0IG1vbml0b3IKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgVHJhY2luZyBuaWQgMzUgdG8gb3V0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogIFRyYWNpbmcgbmlkIDM2IHRvIG91dApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6IFRyYWNpbmcgYmVlcGVyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogIG5pZCAyOSB0cmFjZWQgdG8gb3V0Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogRkcgY29uZmlnL3F1aXJrczogZm9yY2VzdGVyZW8gaXZyZWY1 MCBpdnJlZjgwIGl2cmVmMTAwIGl2cmVmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogKy0tLS0t LS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog fCBEVU1QSU5HIEhEQSBOT0RFUyB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogKy0tLS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogRGVm YXVsdCBQYXJhbWV0ZXIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAt LS0tLS0tLS0tLS0tLS0tLQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBi aXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgSU4gYW1wOiAweDAwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICBPVVQgYW1wOiAweDAwMDAwMDAwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAw MTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAg ICAgIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBB c3NvY2lhdGlvbjogMCAoMHgwMDAwMDAwMSkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAw eDAwMGUwNTYwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAzCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAwMTEK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAg IFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3Nv Y2lhdGlvbjogMCAoMHgwMDAwMDAwMikKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAw MGUwNTYwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAg ICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICAgbmlkOiA0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAwMTEKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFNU RVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lh dGlvbjogMCAoMHgwMDAwMDAwNCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUw NTYwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAg ICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICAgbmlkOiA1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAwMTEKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJF TwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlv bjogMCAoMHgwMDAwMDAxMCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAg ICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogICAgICAgICAgICAgbmlkOiA2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAyMTEKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIERJR0lUQUwg U1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIEFzc29j aWF0aW9uOiAyICgweDAwMDAwMDAxKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChwY20pCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAx ZTA1ZTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAg ICAgICAgIDE2IDIwIDI0IDMyIGJpdHMsIDQ0IDQ4IDg4IDk2IDE5MiBLSHoKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBuaWQ6IDcKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIGlucHV0Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMTAwMTFi Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAg ICBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgQXNz b2NpYXRpb246IDMgKDB4MDAwMDgwMDEpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIDE2 IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMzJlMTAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTQ2 IHNpemU9MyBvZmZzZXQ9MTYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgY29ubmVjdGlvbnM6IDEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICArIDwtIG5pZD0zNiBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICAgbmlkOiA4Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBpbnB1dApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDExYgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVP Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIEFzc29jaWF0aW9u OiA0ICgweDAwMDAwMDAxKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBi aXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDMyZTEwCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD00NiBzaXplPTMg b2Zmc2V0PTE2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNv bm5lY3Rpb25zOiAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAg ICAgKyA8LSBuaWQ9MzUgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICAgIG5pZDogOSBbRElTQUJMRURdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBpbnB1dApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDExYgpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RF UkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBTdHJlYW0g Y2FwOiAweDAwMDAwMDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICAgICAgICAgICBQQ00KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2 IDE5MiBLSHoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICBJ bnB1dCBhbXA6IDB4ODAwMzJlMTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTQ2IHNpemU9MyBvZmZzZXQ9MTYKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgfApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTM0IFthdWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICAgICAgICAgIG5pZDogMTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIGlucHV0Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMTAwMzkxCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBESUdJ VEFMIFVOU09MIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICBBc3NvY2lhdGlvbjogNSAoMHgwMDAwMDAwMSkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFBDTQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgUENNIGNhcDogMHgwMDFl MDU2MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAg ICAgICAgMTYgMjAgMjQgMzIgYml0cywgNDQgNDggOTYgMTkyIEtIegpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMxIFtwaW46IFNQRElG LWluIChZZWxsb3cgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAg bmlkOiAxMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAg ICAgTmFtZTogYXVkaW8gbWl4ZXIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAxMGIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogLTIgKDB4MDAwMDgwMDEp Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgT1NT OiBtaXggKG1peCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg ICBJbnB1dCBhbXA6IDB4ODAwNTFmMTcKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9MjMK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgY29ubmVjdGlvbnM6 IDEwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgIHwK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBu aWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yNSBbcGluOiBNaWMgKFBpbmsgSmFjayld Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTI2IFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjcgW3Bpbjog SGVhZHBob25lcyAoR3JlZW4gSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjggW3BpbjogQ0QgKE5vbmUp XSBbRElTQUJMRURdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGluOiBM aW5lLW91dCAoR3JlZW4gSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjEgW3BpbjogTGluZS1vdXQgKEJs YWNrIEphY2spXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChPcmFuZ2UgSmFjayld Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFjayldCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAxMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAx MGYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAg ICAgIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBB c3NvY2lhdGlvbjogMCAoMHgwMDAwMDAwMSkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSwgbWl4Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDAwMDM0MDQwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAg c3RlcD02NCBzaXplPTMgb2Zmc2V0PTY0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9 MCBvZmZzZXQ9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBj b25uZWN0aW9uczogMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTIgW2F1ZGlvIG91dHB1dF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTMKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAw MjAwMTBmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAg ICAgICAgICBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDIpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICAgT1NTOiBwY20sIG1peApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDAzNDA0MApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0 ZT0wIHN0ZXA9NjQgc2l6ZT0zIG9mZnNldD02NApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBz aXplPTAgb2Zmc2V0PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgY29ubmVjdGlvbnM6IDIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0KTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBuaWQ6IDE0Ck1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDIwMDEwZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICAgICAgICAgU1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDA0KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4MDAwMzQwNDAK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAg IG11dGU9MCBzdGVwPTY0IHNpemU9MyBvZmZzZXQ9NjQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVw PTAgc2l6ZT0wIG9mZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogICAgIGNvbm5lY3Rpb25zOiAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9NCBbYXVkaW8gb3V0cHV0XQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJd Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAxNQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4 ZXIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAyMDAxMGYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgICAgICAgIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwMDAxMCkKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSwgbWl4Ck1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDAwMDM0 MDQwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAg ICAgICBtdXRlPTAgc3RlcD02NCBzaXplPTMgb2Zmc2V0PTY0Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEg c3RlcD0wIHNpemU9MCBvZmZzZXQ9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6ICAgICAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTUgW2F1ZGlvIG91dHB1dF0KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1p eGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTYgW0RJU0FC TEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAg TmFtZTogdmVuZG9yIHdpZGdldApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICAgIG5pZDogMTcgW0RJU0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAw MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTggW0RJU0FCTEVE XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFt ZTogdmVuZG9yIHdpZGdldApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICAgIG5pZDogMTkgW0RJU0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAwMApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMjAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1v dXQgKEdyZWVuIEphY2spCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDEp Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQaW4gY2Fw OiAweDAwMDAzNzNjCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICAgICAgICBQREMgSFAgT1VUIElOIFZSRUZbIDUwIDgwIDEwMCBHUk9VTkQgSElaIF0K TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFBpbiBjb25maWc6 IDB4MDEwMTQ0MTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg UGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNp emU9MCBvZmZzZXQ9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgIElucHV0IGFtcDogMHgwMDI3MDMwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0w Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5lY3Rpb25z OiA1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgIHwK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBu aWQ9MTIgW2F1ZGlvIG1peGVyXSAoc2VsZWN0ZWQpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1p eGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNSBbYXVk aW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMjEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEJsYWNrIEphY2sp Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2Fw OiAweDAwNDAwMThmCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDQpCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzNjCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQ REMgSFAgT1VUIElOIFZSRUZbIDUwIDgwIDEwMCBHUk9VTkQgSElaIF0KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDEwMTE0MTIKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4 MDAwMDAwNDAgT1VUCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgIElucHV0IGFtcDog MHgwMDI3MDMwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5lY3Rpb25zOiA1Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0x MiBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xNCBbYXVk aW8gbWl4ZXJdIChzZWxlY3RlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICAgIG5pZDogMjIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKE9yYW5nZSBKYWNrKQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAg VU5TT0wgU1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg IEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDAyKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAzYwpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUERDIEhQIE9VVCBJTgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgUGluIGNvbmZpZzog MHgwMTAxNjQxMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBQ aW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6 ZT0wIG9mZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgSW5wdXQgYW1wOiAweDAwMjcwMzAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgY29ubmVjdGlvbnM6 IDUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgfApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXSAoc2VsZWN0 ZWQpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTE1IFthdWRp byBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAg ICAgKyBbRElTQUJMRURdIDwtIG5pZD0zOCBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICAgbmlkOiAyMwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBMaW5lLW91dCAoR3JleSBKYWNrKQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDQwMDE4ZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICAgICAgICAgVU5TT0wgU1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDEwKQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAzYwpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgUERD IEhQIE9VVCBJTgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg UGluIGNvbmZpZzogMHgwMTAxMjQxNApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAwCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9 Mzkgb2Zmc2V0PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg Y29ubmVjdGlvbnM6IDUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0x MyBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xNSBbYXVk aW8gbWl4ZXJdIChzZWxlY3RlZCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zOCBbYXVkaW8gbWl4ZXJdCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAyNApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBNaWMgKFBpbmsg SmFjaykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdl dCBjYXA6IDB4MDA0MDAxOGYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMyAoMHgwMDAwMDAwMSkKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IG1pYyAobWlj KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgUGluIGNh cDogMHgwMDAwMzczYwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICAgICAgICAgUERDIEhQIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAgR1JPVU5EIEhJWiBd Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBQaW4gY29uZmln OiAweDAxYTE5YzQwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg IFBpbiBjb250cm9sOiAweDAwMDAwMDI1IElOIFZSRUZzCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3Rl cD0wIHNpemU9MCBvZmZzZXQ9MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6ICAgICAgIElucHV0IGFtcDogMHgwMDI3MDMwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9m ZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5l Y3Rpb25zOiA1Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0xMyBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zOCBbYXVkaW8gbWl4ZXJd Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgbmlkOiAyNQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBNaWMg KFBpbmsgSmFjaykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg IFdpZGdldCBjYXA6IDB4MDA0MDAxOGYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogNCAoMHgwMDAwMDAwMSkKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IG1v bml0b3IgKG1vbml0b3IpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzNjCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQREMgSFAgT1VUIElOIFZSRUZbIDUwIDgwIDEw MCBHUk9VTkQgSElaIF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgIFBpbiBjb25maWc6IDB4MDJhMTljNTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjUgSU4gVlJFRnMKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAw MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAg ICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3Rl cD0zIHNpemU9Mzkgb2Zmc2V0PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgY29ubmVjdGlvbnM6IDUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gKHNlbGVj dGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNCBbYXVk aW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTUgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM4 IFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBuaWQ6 IDI2Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICBO YW1lOiBwaW46IExpbmUtaW4gKEJsdWUgSmFjaykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGYKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlvbjog MyAoMHgwMDAwODAwMCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgICBPU1M6IGxpbmUgKGxpbmUpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzNjCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQREMgSFAgT1VUIElOIFZS RUZbIDUwIDgwIDEwMCBHUk9VTkQgSElaIF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE4MTM0NGYKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjUgSU4gVlJF RnMKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIE91dHB1dCBh bXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAg ICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDUKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBt aXhlcl0gKHNlbGVjdGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0xNCBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTUgW2F1ZGlvIG1peGVyXQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg ICAgICAgICBuaWQ6IDI3Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICAgICBOYW1lOiBwaW46IEhlYWRwaG9uZXMgKEdyZWVuIEphY2spCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThm Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAg ICBVTlNPTCBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDEpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzNjCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQREMgSFAgT1VUIElO IFZSRUZbIDUwIDgwIDEwMCBHUk9VTkQgSElaIF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDIyMTRjMjAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwYzAgSFAg T1VUCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBPdXRwdXQg YW1wOiAweDgwMDAwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHgwMDI3MDMw MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAg ICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5lY3Rpb25zOiA1Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMiBbYXVkaW8g bWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAg ICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTE0IFth dWRpbyBtaXhlcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg ICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM4IFthdWRpbyBt aXhlcl0gKHNlbGVjdGVkKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5p ZDogMjggW0RJU0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICAgTmFtZTogcGluOiBDRCAoTm9uZSkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAwMDEKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgw MDAwMDAyMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAg ICAgICAgICAgSU4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg IFBpbiBjb25maWc6IDB4NTkzMzAxZjAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgICBuaWQ6IDI5Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICBOYW1lOiBiZWVwIHdpZGdldApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDcwMDAwMApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogLTIgKDB4 MDAwMDAwMDApCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICAgT1NTOiBzcGVha2VyIChzcGVha2VyKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICAgIG5pZDogMzAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICAgICAgIE5hbWU6IHBpbjogU1BESUYtb3V0IChPcmFuZ2UgSmFjaykKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAz MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAg ICAgIERJR0lUQUwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg QXNzb2NpYXRpb246IDIgKDB4MDAwMDAwMDEpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAwMDEwCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBPVVQKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE0YjYxMzAK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgUGluIGNvbnRyb2w6 IDB4MDAwMDAwNDAgT1VUCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDog ICAgIGNvbm5lY3Rpb25zOiAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFj MDogICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICAgICAgKyA8LSBuaWQ9NiBbYXVkaW8gb3V0cHV0XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRh YzA6ICAgICAgICAgICAgIG5pZDogMzEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU1BESUYtaW4gKFllbGxvdyBKYWNrKQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgw MDQwMDIwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAg ICAgICAgICAgRElHSVRBTApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICBBc3NvY2lhdGlvbjogNSAoMHgwMDAwMDAwMSkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICBPU1M6IGRpZzEgKGRpZzEpCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAwMDIw Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAg ICBJTgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgUGluIGNv bmZpZzogMHgwMWNiNzE2MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyMCBJTgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICAgIG5pZDogMzIgW0RJU0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDA0 MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAg ICAgUFJPQwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzMgW0RJ U0FCTEVEXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAg ICAgTmFtZTogdm9sdW1lIHdpZGdldApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDYwMDA4MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM0IFtESVNBQkxFRF0KTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwMjAwMTBiCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgICAgICAgICBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMw OiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNl dD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5lY3Rp b25zOiAxMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAg ICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlk PTI1IFtwaW46IE1pYyAoUGluayBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yNiBbcGluOiBMaW5lLWlu IChCbHVlIEphY2spXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI3IFtwaW46IEhlYWRwaG9uZXMgKEdyZWVuIEph Y2spXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTI4IFtwaW46IENEIChOb25lKV0gW0RJU0FCTEVEXQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0g PC0gbmlkPTI5IFtiZWVwIHdpZGdldF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGluOiBMaW5lLW91dCAo R3JlZW4gSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjEgW3BpbjogTGluZS1vdXQgKEJsYWNrIEphY2sp XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtE SVNBQkxFRF0gPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChPcmFuZ2UgSmFjayldCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8 LSBuaWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTEgW2F1 ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzUK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6 IGF1ZGlvIG1peGVyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICBXaWRnZXQgY2FwOiAweDAwMjAwMTBiCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgQXNzb2NpYXRpb246IDQgKDB4MDAwMDAwMDEpCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgT1NTOiBzcGVha2Vy LCBtaXgsIG1vbml0b3IKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAg ICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0w Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5lY3Rpb25z OiAxMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICB8 Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yNSBbcGluOiBNaWMg KFBpbmsgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjYgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0K TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElT QUJMRURdIDwtIG5pZD0yNyBbcGluOiBIZWFkcGhvbmVzIChHcmVlbiBKYWNrKV0KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0yOCBbcGluOiBDRCAoTm9uZSldIFtESVNBQkxFRF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0XQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTIwIFtwaW46IExpbmUtb3V0IChHcmVlbiBKYWNrKV0KTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD0yMSBbcGluOiBMaW5lLW91dCAoQmxhY2sgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjIgW3Bpbjog TGluZS1vdXQgKE9yYW5nZSBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMyBbcGluOiBMaW5lLW91dCAo R3JleSBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6 ICAgICAgICAgICAgIG5pZDogMzYKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTBiCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgQXNzb2NpYXRpb246IDMg KDB4MDAwMDgwMDEpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAg ICAgICAgICAgT1NTOiBzcGVha2VyLCBsaW5lLCBtaWMsIG1peApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0x IHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDExCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBoZGFjMDogICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXQpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTI1IFtwaW46IE1pYyAoUGluayBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjYgW3BpbjogTGluZS1pbiAo Qmx1ZSBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAg ICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yNyBbcGluOiBIZWFkcGhvbmVzIChHcmVlbiBKYWNr KV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBb RElTQUJMRURdIDwtIG5pZD0yOCBbcGluOiBDRCAoTm9uZSldIFtESVNBQkxFRF0KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2Jl ZXAgd2lkZ2V0XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAg ICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIwIFtwaW46IExpbmUtb3V0IChHcmVlbiBKYWNrKV0K TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElT QUJMRURdIDwtIG5pZD0yMSBbcGluOiBMaW5lLW91dCAoQmxhY2sgSmFjayldCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MjIgW3BpbjogTGluZS1vdXQgKE9yYW5nZSBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMyBbcGlu OiBMaW5lLW91dCAoR3JleSBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzcKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91dHB1dApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDAx MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAg ICAgU1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIEFz c29jaWF0aW9uOiAxICgweDAwMDAwMDAxKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChwY20pCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4 MDAwZTA1NjAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAg ICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM4Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6ICAgICAgICAgICAgICAgICAg U1RFUkVPCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIEFzc29j aWF0aW9uOiAxICgweDAwMDAwMDAxKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog aGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4MDAwMzQwNDAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVw PTY0IHNpemU9MyBvZmZzZXQ9NjQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhk YWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9m ZnNldD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgIGNvbm5l Y3Rpb25zOiAyCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBoZGFjMDogICAgICAg ICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGhkYWMwOiAgICAgICAgICAg KyA8LSBuaWQ9MzcgW2F1ZGlvIG91dHB1dF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaGRhYzA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMDogPEhEQSBSZWFsdGVrIEFMQzg4NSBQQ00gIzAgQW5hbG9nPiBhdCBjYWQg MiBuaWQgMSBvbiBoZGFjMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDog Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMDogfCBEVU1QSU5HIFBDTSBQbGF5YmFjay9SZWNvcmQgQ2hh bm5lbHMgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiBQ bGF5YmFjazoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAw MDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICAgICAgICAg ICAgIFBDTQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgICBQ Q00gY2FwOiAweDAwMGUwNTYwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20w OiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgIERBQzogMiAzIDQg NQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBwY20wOiBSZWNvcmQ6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6 ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogcGNtMDogICAgICAgICAgICAgICAgICBQQ00KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTA6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDU2MApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRz LCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20w OiAgICAgICAgICAgICBBREM6IDcKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBj bTA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20wOiB8IERVTVBJTkcgUGxheWJhY2svUmVjb3JkIFBhdGhzIHwKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20wOiBQbGF5YmFjazoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDog ICAgIG5pZD0yMCBbcGluOiBMaW5lLW91dCAoR3JlZW4gSmFjayldCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwY20wOiAgICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwg bWl4XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgICAgICAg IHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICAr IDwtIG5pZD0yIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJd IFtzcmM6IG1peF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgIG5pZD0yMSBbcGluOiBMaW5l LW91dCAoQmxhY2sgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20w OiAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICAr IDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwgbWl4XQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRw dXRdIFtzcmM6IHBjbV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAg ICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdIFtzcmM6IG1peF0KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMDogICAgIG5pZD0yMiBbcGluOiBMaW5lLW91dCAoT3JhbmdlIEphY2spXQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgfApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgKyA8LSBuaWQ9MTMgW2F1ZGlvIG1p eGVyXSBbc3JjOiBwY20sIG1peF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBj bTA6ICAgICAgICAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20w OiAgICAgICAgICAgICAgKyA8LSBuaWQ9MyBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21dCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9 MTEgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICBu aWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFjayldCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY20wOiAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20wOiAgICAgICArIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwgbWl4XQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgICAgICAgICAgIHwKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICArIDwtIG5p ZD01IFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdIFtzcmM6 IG1peF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogUmVjb3JkOgpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20wOiAgICAgbmlkPTcgW2F1ZGlvIGlucHV0XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogcGNtMDogICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MDogICAgICAgKyA8LSBuaWQ9MzYgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBt aWMsIG1peF0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAg ICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXSBbc3JjOiBtaWNdCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjYg W3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0yOSBbYmVlcCB3aWRn ZXRdIFtzcmM6IHNwZWFrZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20w OiAgICAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTA6IElucHV0IE1peDoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAg IG5pZD0xMSBbYXVkaW8gbWl4ZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20wOiAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAg ICArIDwtIG5pZD0yNCBbcGluOiBNaWMgKFBpbmsgSmFjayldIFtzcmM6IG1pY10KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICAgICsgPC0gbmlkPTI1IFtwaW46IE1p YyAoUGluayBKYWNrKV0gW3NyYzogbW9uaXRvcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IHBjbTA6ICAgICAgICsgPC0gbmlkPTI2IFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayld IFtzcmM6IGxpbmVdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAg ICArIDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRdIFtzcmM6IHNwZWFrZXJdCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IHBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogfCBEVU1QSU5HIFZvbHVtZSBDb250cm9scyB8Ck1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogTWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wpCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICB8Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwgMTQgKG5pZCAgMTIgb3V0KTogICAgLTY0 LzBkQiAoNjUgc3RlcHMpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAg ICArLSBjdGwgMTUgKG5pZCAgMTIgaW4gICAwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDE2IChuaWQgIDEyIGluICAgMSk6IG11dGUKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAxNyAobmlkICAx MyBvdXQpOiAgICAtNjQvMGRCICg2NSBzdGVwcykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IHBjbTA6ICAgICstIGN0bCAxOCAobmlkICAxMyBpbiAgIDApOiBtdXRlCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwgMTkgKG5pZCAgMTMgaW4g ICAxKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0g Y3RsIDIwIChuaWQgIDE0IG91dCk6ICAgIC02NC8wZEIgKDY1IHN0ZXBzKQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDIxIChuaWQgIDE0IGluICAgMCk6 IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAy MiAobmlkICAxNCBpbiAgIDEpOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20wOiAgICArLSBjdGwgMjMgKG5pZCAgMTUgb3V0KTogICAgLTY0LzBkQiAoNjUgc3RlcHMp Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwgMjQgKG5p ZCAgMTUgaW4gICAwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MDogICAgKy0gY3RsIDI1IChuaWQgIDE1IGluICAgMSk6IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAyNiAobmlkICAyMCBpbiApOiAgICBtdXRl Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwgMjggKG5p ZCAgMjEgaW4gKTogICAgbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MDogICAgKy0gY3RsIDMwIChuaWQgIDIyIGluICk6ICAgIG11dGUKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAzMiAobmlkICAyMyBpbiApOiAgICBtdXRl Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IFBDTSBWb2x1bWUgKE9TUzogcGNtKQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDE1IChuaWQgIDEyIGluICAgMCk6IG11dGUKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAxOCAobmlkICAx MyBpbiAgIDApOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAg ICArLSBjdGwgMjEgKG5pZCAgMTQgaW4gICAwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDI0IChuaWQgIDE1IGluICAgMCk6IG11dGUKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogTWljcm9waG9uZSBWb2x1bWUgKE9TUzogbWljKQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgfApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDM1IChuaWQgIDI0IG91dCk6ICAgIDAvMzBk QiAoNCBzdGVwcykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICst IGN0bCA2NCAobmlkICAzNiBpbiAgIDApOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwY20wOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IExp bmUtaW4gVm9sdW1lIChPU1M6IGxpbmUpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20wOiAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICAr LSBjdGwgMzkgKG5pZCAgMjYgb3V0KTogICAgMC8zMGRCICg0IHN0ZXBzKQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDY2IChuaWQgIDM2IGluICAgMik6 IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogU3BlYWtlci9CZWVwIFZvbHVtZSAoT1NTOiBz cGVha2VyKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgfApNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsICA5IChuaWQgIDEx IGluICAgNSk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwgNjkgKG5pZCAgMzYgaW4gICA1KTogbXV0ZQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20wOiBSZWNvcmRpbmcgTGV2ZWwgKE9TUzogcmVjKQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgfApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsICAxIChuaWQgICA3IGluICAgMCk6IC0xNi8z MGRCICg0NyBzdGVwcykgKyBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20wOiAgICArLSBjdGwgNjQgKG5pZCAgMzYgaW4gICAwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDY2IChuaWQgIDM2IGluICAgMik6IG11 dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCA2OSAo bmlkICAzNiBpbiAgIDUpOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20wOiAgICArLSBjdGwgNzQgKG5pZCAgMzYgaW4gIDEwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMDogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20wOiBJbnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cGNtMDogICAgKy0gY3RsICA0IChuaWQgIDExIGluICAgMCk6IC0zNC8xMmRCICgzMiBzdGVwcykg KyBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAgICArLSBjdGwg IDUgKG5pZCAgMTEgaW4gICAxKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAgNiAobmlkICAxMSBpbiAg IDIpOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMDogICAgKy0gY3RsICA5IChuaWQgIDExIGluICAgNSk6IC0zNC8xMmRCICgz MiBzdGVwcykgKyBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAg ICArLSBjdGwgMTYgKG5pZCAgMTIgaW4gICAxKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDE5IChuaWQgIDEzIGluICAgMSk6IG11dGUKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6ICAgICstIGN0bCAyMiAobmlkICAx NCBpbiAgIDEpOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiAg ICArLSBjdGwgMjUgKG5pZCAgMTUgaW4gICAxKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogICAgKy0gY3RsIDc0IChuaWQgIDM2IGluICAxMCk6IG11dGUKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogRW5hYmxpbmcgU29mdCBQQ00gdm9sdW1lCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20wOiBNaXhlciAidm9sIjoKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IHBjbTA6IE1peGVyICJwY20iOgpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogTWl4ZXIgInNwZWFrZXIiOgpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMDogTWl4ZXIgImxpbmUiOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMDogTWl4ZXIgIm1pYyI6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwY20wOiBNaXhlciAibWl4IjoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IHBjbTA6IE1peGVyICJyZWMiOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cGNtMDogU29mdCBQQ00gbWl4ZXIgRU5BQkxFRApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogcGNtMDogY2xvbmUgbWFuYWdlcjogZGVhZGxpbmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAx ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMDogc25kYnVmX3NldG1hcCAy OTEwMDAwLCA0MDAwOyAweGU2MmZmMDAwIC0+IDI5MTAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTA6IHNuZGJ1Zl9zZXRtYXAgMjkyMDAwMCwgNDAwMDsgMHhlNjMwZjAw MCAtPiAyOTIwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiA8SERB IFJlYWx0ZWsgQUxDODg1IFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAyIG5pZCAxIG9uIGhkYWMwCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20xOiB8IERVTVBJTkcgUENNIFBsYXliYWNrL1JlY29yZCBDaGFubmVscyB8Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IFBsYXliYWNrOgpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBwY20xOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgICAgICAgUENNCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgICAgICAg MTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogICAgICAgICAgICAgREFDOiAzNwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogcGNtMTogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20x OiBSZWNvcmQ6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAw MDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgICAgICAgICAg ICAgICBQQ00KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgICAg UENNIGNhcDogMHgwMDBlMDU2MApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MTogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6Ck1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICAgICAgICAgICBBREM6IDgKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMTogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiB8IERVTVBJTkcgUGxheWJhY2sv UmVjb3JkIFBhdGhzIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiBQ bGF5YmFjazoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgIG5pZD0yNyBbcGluOiBIZWFkcGhv bmVzIChHcmVlbiBKYWNrKV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6 ICAgICAgIHwKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgICsg PC0gbmlkPTM4IFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20xOiAgICAgICAgICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMTogICAgICAgICAgICAgICsgPC0gbmlkPTM3IFthdWRpbyBvdXRw dXRdIFtzcmM6IHBjbV0KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAg ICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdIFtzcmM6IG1peF0KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogUmVjb3JkOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog cGNtMTogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICAgbmlkPTgg W2F1ZGlvIGlucHV0XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAg ICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgICAgKyA8LSBu aWQ9MzUgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBtaXgsIG1vbml0b3JdCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICAgICAgICAgICAgfApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgICAgICAgICAgICsgPC0gbmlkPTI1IFtw aW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbW9uaXRvcl0KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgICArIDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRd IFtzcmM6IHNwZWFrZXJdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAg ICAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTE6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogfCBEVU1QSU5HIFZvbHVtZSBDb250cm9scyB8Ck1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogTWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wp Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICB8Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICArLSBjdGwgNDAgKG5pZCAgMjcgaW4gKTog ICAgbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgKy0gY3Rs IDc1IChuaWQgIDM4IG91dCk6ICAgIC02NC8wZEIgKDY1IHN0ZXBzKQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDc2IChuaWQgIDM4IGluICAgMCk6IG11 dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCA3NyAo bmlkICAzOCBpbiAgIDEpOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBw Y20xOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IFBDTSBWb2x1bWUg KE9TUzogcGNtKQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgfApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDc2IChuaWQg IDM4IGluICAgMCk6IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6 IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogTWljcm9waG9uZTIgVm9s dW1lIChPU1M6IG1vbml0b3IpCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20x OiAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICArLSBjdGwg MzcgKG5pZCAgMjUgb3V0KTogICAgMC8zMGRCICg0IHN0ZXBzKQpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDU0IChuaWQgIDM1IGluICAgMSk6IG11dGUK TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMTogU3BlYWtlci9CZWVwIFZvbHVtZSAoT1NTOiBzcGVha2Vy KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgfApNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDU4IChuaWQgIDM1IGluICAg NSk6IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6IApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogUmVjb3JkaW5nIExldmVsIChPU1M6IHJl YykKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgIHwKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCAgMiAobmlkICAgOCBpbiAg IDApOiAtMTYvMzBkQiAoNDcgc3RlcHMpICsgbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDU0IChuaWQgIDM1IGluICAgMSk6IG11dGUKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCA1OCAobmlkICAzNSBp biAgIDUpOiBtdXRlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAgICAr LSBjdGwgNjMgKG5pZCAgMzUgaW4gIDEwKTogbXV0ZQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiBJ bnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogcGNtMTogICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogICAg Ky0gY3RsIDYzIChuaWQgIDM1IGluICAxMCk6IG11dGUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCA3NyAobmlkICAzOCBpbiAgIDEpOiBtdXRlCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTE6IEVuYWJsaW5nIFNvZnQgUENNIHZvbHVtZQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMTogTWl4ZXIgInZvbCI6Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBwY20xOiBNaXhlciAicGNtIjoKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTE6IE1peGVyICJzcGVha2VyIjoKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IHBjbTE6IE1peGVyICJtaXgiOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMTogTWl4ZXIgInJlYyI6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBwY20xOiBNaXhlciAibW9uaXRvciI6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBwY20xOiBTb2Z0IFBDTSBtaXhlciBFTkFCTEVECk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY20xOiBjbG9uZSBtYW5hZ2VyOiBkZWFkbGluZT03NTBtcyBmbGFncz0weDgw MDAwMDFlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20xOiBzbmRidWZfc2V0 bWFwIDI5MzAwMDAsIDQwMDA7IDB4ZTYzMWYwMDAgLT4gMjkzMDAwMApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMTogc25kYnVmX3NldG1hcCAyOTQwMDAwLCA0MDAwOyAweGU2 MzJmMDAwIC0+IDI5NDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6 IDxIREEgUmVhbHRlayBBTEM4ODUgUENNICMyIERpZ2l0YWw+IGF0IGNhZCAyIG5pZCAxIG9uIGhk YWMwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBwY20yOiB8IERVTVBJTkcgUENNIFBsYXliYWNrL1JlY29yZCBDaGFubmVscyB8Ck1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20y OiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6IFBsYXliYWNrOgpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjogCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBwY20yOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDUKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6ICAgICAgICAgICAgICAgICAgQUMzIFBDTQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjogICAgICAgICBQQ00gY2FwOiAw eDAwMWUwNWUwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiAgICAgICAg ICAgICAgICAgIDE2IDIwIDI0IDMyIGJpdHMsIDQ0IDQ4IDg4IDk2IDE5MiBLSHoKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6ICAgICAgICAgICAgIERBQzogNgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjogCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwY20yOiBSZWNvcmQ6Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20yOiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6ICAgICAgU3Ry ZWFtIGNhcDogMHgwMDAwMDAwNQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MjogICAgICAgICAgICAgICAgICBBQzMgUENNCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBwY20yOiAgICAgICAgIFBDTSBjYXA6IDB4MDAxZTA1NjAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTI6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgMzIgYml0cywg NDQgNDggOTYgMTkyIEtIegpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjog ICAgICAgICAgICAgQURDOiAxMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNt MjogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBj bTI6IHwgRFVNUElORyBQbGF5YmFjay9SZWNvcmQgUGF0aHMgfApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogcGNtMjogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiAKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IHBjbTI6IFBsYXliYWNrOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMjogCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiAg ICAgbmlkPTMwIFtwaW46IFNQRElGLW91dCAoT3JhbmdlIEphY2spXQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogcGNtMjogICAgICAgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogcGNtMjogICAgICAgKyA8LSBuaWQ9NiBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21d Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiAKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6IFJlY29yZDoKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTI6IApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjog ICAgIG5pZD0xMCBbYXVkaW8gaW5wdXRdCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBwY20yOiAgICAgICB8Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiAg ICAgICArIDwtIG5pZD0zMSBbcGluOiBTUERJRi1pbiAoWWVsbG93IEphY2spXSBbc3JjOiBkaWcx XQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjogCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBwY20yOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6IHwgRFVNUElORyBWb2x1bWUgQ29u dHJvbHMgfApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogcGNtMjogKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20y OiAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHBjbTI6IGNsb25lIG1hbmFnZXI6 IGRlYWRsaW5lPTc1MG1zIGZsYWdzPTB4ODAwMDAwMWUKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHBjbTI6IHNuZGJ1Zl9zZXRtYXAgMjk1MDAwMCwgNDAwMDsgMHhlNjMzZjAwMCAt PiAyOTUwMDAwCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBwY20yOiBzbmRidWZf c2V0bWFwIDI5NjAwMDAsIDQwMDA7IDB4ZTYzNGYwMDAgLT4gMjk2MDAwMApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBjcHUxIEFQOgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogSUQ6IDB4MDEwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAwMDAwMDAw IERGUjogMHhmZmZmZmZmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogbGludDA6 IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAw MDFmZgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdGltZXI6IDB4MDAwMjAwZWYg dGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTQgKElT QSBJUlEgMTQpIHRvIGxhcGljIDEgdmVjdG9yIDQ4Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBpb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikgdG8gbGFwaWMg MSB2ZWN0b3IgNDkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE5IChQQ0kgSVJRIDE5KSB0byBsYXBpYyAxIHZlY3RvciA1MApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBD SSBJUlEgMjMpIHRvIGxhcGljIDEgdmVjdG9yIDUxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwg a2VybmVsOiBXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBw ZXJmb3JtYW5jZS4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IFdBUk5JTkc6IERJ QUdOT1NUSUMgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogR0VPTTogbmV3IGRpc2sgYWQxCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIg YWQwczFiIGlzIGxhYmVsL3N3YXAuCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBH RU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFkIGlzIGxhYmVsL3Vzci4KTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IEdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRl ciBhZDBzMWQgaXMgdWZzaWQvNDllMjNjZTE4OWM2Y2UzNS4KTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IEdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzMWQgaXMgdWZz L3Vzci4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVodWI2OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVodWIy OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1aHViNTogMiBwb3J0cyB3 aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IGFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBh c2NxPTB4MDAgc2tzPTB4NDAgMHgwMCAweDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiAocHJvYmUwOmF0YTE6MDoxOjApOiBlcnJvciAyMgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogKHByb2JlMDphdGExOjA6MTowKTogVW5yZXRyeWFibGUgRXJyb3IKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IChwcm9iZTA6YXRhMTowOjE6MCk6IERvd24gcmV2 aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/Ck1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBwYXNzMCBhdCBhdGExIGJ1cyAwIHRhcmdldCAxIGx1biAwCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBwYXNzMDogPEhMLURULVNUIERWRFJBTSBHU0EtSDEwTiBK TDEyPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBwYXNzMDogMzMuMDAwTUIvcyB0cmFuc2ZlcnMKTWF5ICA0IDE5OjU4OjAz IG1vc2hucm9sbCBrZXJuZWw6IGNkMCBhdCBhdGExIGJ1cyAwIHRhcmdldCAxIGx1biAwCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjZDA6IDxITC1EVC1TVCBEVkRSQU0gR1NBLUgx ME4gSkwxMj4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogY2QwOiAzMy4wMDBNQi9zIHRyYW5zZmVycwpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogY2QwOiBjZCBwcmVzZW50IFszNDAzNTYgeCAyMDQ4IGJ5dGUg cmVjb3Jkc10KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVodWIzOiA2IHBvcnRz IHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogdWh1Yjc6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1Z2VuMS4yOiA8RGVsbD4gYXQgdXNidXMx Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB1a2JkMDogPERlbGwgRGVsbCBVU0Ig S2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy4wNiwgYWRkciAyPiBvbiB1c2J1czEKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGtiZDAgYXQgdWtiZDAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGtiZDA6IHVrYmQwLCBnZW5lcmljICgwKSwgY29uZmlnOjB4 MCwgZmxhZ3M6MHgxZDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGludGVy cnVwdCBzdG9ybSBkZXRlY3RlZCBvbiAiaXJxMTk6IjsgdGhyb3R0bGluZyBpbnRlcnJ1cHQgc291 cmNlCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpbnRlcnJ1cHQgc3Rvcm0gZGV0 ZWN0ZWQgb24gImlycTE5OiI7IHRocm90dGxpbmcgaW50ZXJydXB0IHNvdXJjZQpNYXkgIDQgMTk6 NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdWdlbjEuMzogPFJhemVyPiBhdCB1c2J1czEKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IHVtczA6IDxSYXplciBSYXplciAxNjAwZHBpIE1v dXNlLCBjbGFzcyAwLzAsIHJldiAyLjAwLzIxLjAwLCBhZGRyIDM+IG9uIHVzYnVzMQpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogdW1zMDogNyBidXR0b25zIGFuZCBbWFlaXSBjb29y ZGluYXRlcyBJRD0wCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBpbnRlcnJ1cHQg c3Rvcm0gZGV0ZWN0ZWQgb24gImlycTE5OiI7IHRocm90dGxpbmcgaW50ZXJydXB0IHNvdXJjZQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGxhc3QgbWVzc2FnZSByZXBlYXRlZCAyNSB0aW1lcwpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVpbml0aW5nIGNoYW5uZWwg Li4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlc2V0IHRwMSBtYXNr PTAzIG9zdGF0MD01MCBvc3RhdDE9NTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGF0YTQ6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKTWF5ICA0IDE5OjU4 OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQg bXNiPTB4ZWIKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlc2V0IHRw MiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MjAwMDEKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IGF0YTQ6IHJlaW5pdCBkb25lIC4uCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhY2QwOiBUSU1FT1VUIC0gUkVBRF9CSUcgcmV0cnlpbmcgKDEgcmV0cnkgbGVm dCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlaW5pdGluZyBjaGFu bmVsIC4uCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNldCB0cDEg bWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTUxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBhdGE0OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0w eDE0IG1zYj0weGViCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNl dCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDIwMDAxCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBhdGE0OiByZWluaXQgZG9uZSAuLgpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYWNkMDogVElNRU9VVCAtIFJFQURfQklHIHJldHJ5aW5nICgwIHJldHJp ZXMgbGVmdCkKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlaW5pdGlu ZyBjaGFubmVsIC4uCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNl dCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTUxCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhdGE0OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiBzdGF0MT0weDAwIGVycj0weDAx IGxzYj0weDE0IG1zYj0weGViCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0 OiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDIwMDAxCk1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZWluaXQgZG9uZSAuLgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYWNkMDogRkFJTFVSRSAtIFJFQURfQklHIHRpbWVkIG91dApN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogR0VPTV9MQUJFTDogTGFiZWwgZm9yIHBy b3ZpZGVyIGFjZDAgaXMgaXNvOTY2MC9EREZfRk9MR0VfODZfQklTXzk3LgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVpbml0aW5nIGNoYW5uZWwgLi4KTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01 MCBvc3RhdDE9NTEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHN0YXQw PTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IGF0YTQ6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlc2V0IHRwMiBzdGF0MD01MCBz dGF0MT0wMCBkZXZpY2VzPTB4MjAwMDEKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGF0YTQ6IHJlaW5pdCBkb25lIC4uCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh Y2QwOiBUSU1FT1VUIC0gUkVBRF9CSUcgcmV0cnlpbmcgKDEgcmV0cnkgbGVmdCkKTWF5ICA0IDE5 OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlaW5pdGluZyBjaGFubmVsIC4uCk1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQxPTUxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiBz dGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBhdGE0OiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGVi Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNldCB0cDIgc3RhdDA9 NTAgc3RhdDE9MDAgZGV2aWNlcz0weDIwMDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2Vy bmVsOiBhdGE0OiByZWluaXQgZG9uZSAuLgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYWNkMDogVElNRU9VVCAtIFJFQURfQklHIHJldHJ5aW5nICgwIHJldHJpZXMgbGVmdCkKTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGF0YTQ6IHJlaW5pdGluZyBjaGFubmVsIC4u Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNldCB0cDEgbWFzaz0w MyBvc3RhdDA9NTAgb3N0YXQxPTUxCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBh dGE0OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCk1heSAgNCAxOTo1ODow MyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1z Yj0weGViCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZXNldCB0cDIg c3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDIwMDAxCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhdGE0OiByZWluaXQgZG9uZSAuLgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xs IGtlcm5lbDogYWNkMDogRkFJTFVSRSAtIFJFQURfQklHIHRpbWVkIG91dApNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogR0VPTTogbmV3IGRpc2sgY2QwCk1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQxczFhIGlz IGxhYmVsL3Jvb3Rmcy4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IEdFT01fTEFC RUw6IExhYmVsIGZvciBwcm92aWRlciBhZDFzMWEgaXMgdWZzaWQvNDlkZjExMTAyNjExNTM5NS4K TWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IEdFT01fTEFCRUw6IExhYmVsIGZvciBw cm92aWRlciBhZDFzMWEgaXMgdWZzL3Jvb3Rmcy4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBr ZXJuZWw6IHNjc2lfY2QuYzo6aW9jdGwgY21kPTQ0MDA2NDhiIGVycm9yPTI1Ck1heSAgNCAxOTo1 ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZWluaXRpbmcgY2hhbm5lbCAuLgpNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQw PTUwIG9zdGF0MT01MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3Rh dDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5y b2xsIGtlcm5lbDogYXRhNDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAyIHN0YXQwPTUw IHN0YXQxPTAwIGRldmljZXM9MHgyMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5l bDogYXRhNDogcmVpbml0IGRvbmUgLi4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IGFjZDA6IEZBSUxVUkUgLSBSRUFEX0JJRyB0aW1lZCBvdXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hu cm9sbCBrZXJuZWw6IChjZDA6YXRhMTowOjE6MCk6IENvbW1hbmQgdGltZWQgb3V0Ck1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiAoY2QwOmF0YTE6MDoxOjApOiBSZXRyeWluZyBDb21t YW5kCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZWluaXRpbmcgY2hh bm5lbCAuLgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAx IG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT01MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhNDogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMApNYXkgIDQg MTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9 MHgxNCBtc2I9MHhlYgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVz ZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgyMDAwMQpNYXkgIDQgMTk6NTg6MDMg bW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVpbml0IGRvbmUgLi4KTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IGFjZDA6IEZBSUxVUkUgLSBSRUFEX0JJRyB0aW1lZCBvdXQKTWF5ICA0 IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IChjZDA6YXRhMTowOjE6MCk6IENvbW1hbmQgdGlt ZWQgb3V0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiAoY2QwOmF0YTE6MDoxOjAp OiBSZXRyeWluZyBDb21tYW5kCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0 OiByZWluaXRpbmcgY2hhbm5lbCAuLgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog YXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT01MQpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBt c2I9MHgwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDE9MHgw MCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhNDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgyMDAwMQpN YXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVpbml0IGRvbmUgLi4KTWF5 ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGFjZDA6IEZBSUxVUkUgLSBSRUFEX0JJRyB0 aW1lZCBvdXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IChjZDA6YXRhMTowOjE6 MCk6IENvbW1hbmQgdGltZWQgb3V0Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiAo Y2QwOmF0YTE6MDoxOjApOiBSZXRyeWluZyBDb21tYW5kCk1heSAgNCAxOTo1ODowMyBtb3NobnJv bGwga2VybmVsOiBhdGE0OiByZWluaXRpbmcgY2hhbm5lbCAuLgpNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT01 MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDA9MHg1MCBlcnI9 MHgwMSBsc2I9MHgwMCBtc2I9MHgwMApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDog YXRhNDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgpNYXkgIDQgMTk6NTg6 MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRl dmljZXM9MHgyMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVp bml0IGRvbmUgLi4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6IGFjZDA6IEZBSUxV UkUgLSBSRUFEX0JJRyB0aW1lZCBvdXQKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJuZWw6 IChjZDA6YXRhMTowOjE6MCk6IENvbW1hbmQgdGltZWQgb3V0Ck1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiAoY2QwOmF0YTE6MDoxOjApOiBSZXRyeWluZyBDb21tYW5kCk1heSAgNCAx OTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBhdGE0OiByZWluaXRpbmcgY2hhbm5lbCAuLgpNYXkg IDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0 YXQwPTUwIG9zdGF0MT01MQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDog c3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMApNYXkgIDQgMTk6NTg6MDMgbW9z aG5yb2xsIGtlcm5lbDogYXRhNDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhl YgpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogYXRhNDogcmVzZXQgdHAyIHN0YXQw PTUwIHN0YXQxPTAwIGRldmljZXM9MHgyMDAwMQpNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtl cm5lbDogYXRhNDogcmVpbml0IGRvbmUgLi4KTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IGFjZDA6IEZBSUxVUkUgLSBSRUFEX0JJRyB0aW1lZCBvdXQKTWF5ICA0IDE5OjU4OjAzIG1v c2hucm9sbCBrZXJuZWw6IChjZDA6YXRhMTowOjE6MCk6IENvbW1hbmQgdGltZWQgb3V0Ck1heSAg NCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiAoY2QwOmF0YTE6MDoxOjApOiBlcnJvciA1Ck1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiAoY2QwOmF0YTE6MDoxOjApOiBSZXRyaWVz IEV4aGF1c3RlZApNYXkgIDQgMTk6NTg6MDMgbW9zaG5yb2xsIGtlcm5lbDogKGNkMDphdGExOjA6 MTowKTogY2Rkb25lOiBnb3QgZXJyb3IgMHg1IGJhY2sKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IFRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvbGFiZWwvcm9vdGZz Ck1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBjdF90b190cyhbMjAwOS0wNS0wNCAx Nzo1Nzo1OV0pID0gMTI0MTQ1OTg3OS4wMDAwMDAwMDAKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9s bCBrZXJuZWw6IHN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0Ck1heSAgNCAxOTo1ODowMyBt b3NobnJvbGwga2VybmVsOiBHRU9NX0xBQkVMOiBMYWJlbCB1ZnMvcm9vdGZzIHJlbW92ZWQuCk1h eSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiBHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80 OWRmMTExMDI2MTE1Mzk1IHJlbW92ZWQuCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVs OiBHRU9NX0xBQkVMOiBMYWJlbCB1ZnMvdXNyIHJlbW92ZWQuCk1heSAgNCAxOTo1ODowMyBtb3No bnJvbGwga2VybmVsOiBHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80OWUyM2NlMTg5YzZjZTM1IHJl bW92ZWQuCk1heSAgNCAxOTo1ODowMyBtb3NobnJvbGwga2VybmVsOiB3bGFuMDogRXRoZXJuZXQg YWRkcmVzczogMDA6MGY6YjU6ODI6MDc6YzgKTWF5ICA0IDE5OjU4OjAzIG1vc2hucm9sbCBrZXJu ZWw6IEV4cGVuc2l2ZSB0aW1lb3V0KDkpIGZ1bmN0aW9uOiAweGMwNTBiYTFlKDB4YzA5ZWZhNjAp IDAuMDAyNDU4OTcxIHMKTWF5ICA0IDE5OjU4OjMwIG1vc2hucm9sbCBrZXJuZWw6IHRzX3RvX2N0 KDEyNDE0NTk5MTAuOTUyMzUyMTE3KSA9IFsyMDA5LTA1LTA0IDE3OjU4OjMwXQpNYXkgIDQgMTk6 NTg6MzQgbW9zaG5yb2xsIGtlcm5lbDogV0FSTklORzogYXR0ZW1wdCB0byBuZXRfYWRkX2RvbWFp bihibHVldG9vdGgpIGFmdGVyIGRvbWFpbmZpbmFsaXplKCkKTWF5ICA0IDE5OjU4OjQ4IG1vc2hu cm9sbCBrZXJuZWw6IGxvY2sgb3JkZXIgcmV2ZXJzYWw6Ck1heSAgNCAxOTo1ODo0OCBtb3NobnJv bGwga2VybmVsOiAxc3QgMHhkOTkzOWExMCBidWZ3YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19iaW8uYzoyNTU1Ck1heSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiAy bmQgMHhjN2U4MjIwMCBkaXJoYXNoIChkaXJoYXNoKSBAIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vm c19kaXJoYXNoLmM6Mjc1Ck1heSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiBLREI6IHN0 YWNrIGJhY2t0cmFjZToKTWF5ICA0IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IGRiX3RyYWNl X3NlbGZfd3JhcHBlcihjMDdhYjUxZCxlODVlYjc5YyxjMDVlOGI4ZixjMDVkYjM3YixjMDdhZTQw OSwuLi4pIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDI2Ck1heSAgNCAxOTo1ODo0OCBtb3No bnJvbGwga2VybmVsOiBrZGJfYmFja3RyYWNlKGMwNWRiMzdiLGMwN2FlNDA5LGM3OGU4OWYwLGM3 OGViZDIwLGU4NWViN2Y4LC4uLikgYXQga2RiX2JhY2t0cmFjZSsweDI5Ck1heSAgNCAxOTo1ODo0 OCBtb3NobnJvbGwga2VybmVsOiBfd2l0bmVzc19kZWJ1Z2dlcihjMDdhZTQwOSxjN2U4MjIwMCxj MDdjMjdlNixjNzhlYmQyMCxjMDdjMjQ3ZiwuLi4pIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MWUK TWF5ICA0IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IHdpdG5lc3NfY2hlY2tvcmRlcihjN2U4 MjIwMCw5LGMwN2MyNDdmLDExMywwLC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODE4Ck1h eSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiBfc3hfeGxvY2soYzdlODIyMDAsMCxjMDdj MjQ3ZiwxMTMsYzg1ZTgyYjgsLi4uKSBhdCBfc3hfeGxvY2srMHg3ZgpNYXkgIDQgMTk6NTg6NDgg bW9zaG5yb2xsIGtlcm5lbDogdWZzZGlyaGFzaF9hY3F1aXJlKGQ5OTM5OWIwLGU4NWViOGY0LDM0 LGRhODExMGNjLGU4NWViOGM4LC4uLikgYXQgdWZzZGlyaGFzaF9hY3F1aXJlKzB4NDQKTWF5ICA0 IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IHVmc2Rpcmhhc2hfYWRkKGM4NWU4MmI4LGU4NWVi OGY0LGNjLGU4NWViOGI0LGU4NWViOGI4LC4uLikgYXQgdWZzZGlyaGFzaF9hZGQrMHgxMwpNYXkg IDQgMTk6NTg6NDggbW9zaG5yb2xsIGtlcm5lbDogdWZzX2RpcmVudGVyKGM4NWVkZDcwLGM4NjQ2 MTU4LGU4NWViOGY0LGU4NWViYmQ4LDAsLi4uKSBhdCB1ZnNfZGlyZW50ZXIrMHg3MGUKTWF5ICA0 IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IHVmc19tYWtlaW5vZGUoZTg1ZWJiZDgpIGF0IHVm c19tYWtlaW5vZGUrMHgyODkKTWF5ICA0IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IHVmc19j cmVhdGUoZTg1ZWJhZDAsYzA3ZDFiM2IsMCwwLGU4NWViYmFjLC4uLikgYXQgdWZzX2NyZWF0ZSsw eDJjCk1heSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiBWT1BfQ1JFQVRFX0FQVihjMDgw YzZlMCxlODVlYmFkMCwyLGMwN2EwZTgyLDMsLi4uKSBhdCBWT1BfQ1JFQVRFX0FQVisweGM0Ck1h eSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiB2bl9vcGVuX2NyZWQoZTg1ZWJiYWMsZTg1 ZWJjNjAsMTgwLGM4NjI5OTAwLGM3ZWY4YWI4LC4uLikgYXQgdm5fb3Blbl9jcmVkKzB4MThlCk1h eSAgNCAxOTo1ODo0OCBtb3NobnJvbGwga2VybmVsOiB2bl9vcGVuKGU4NWViYmFjLGU4NWViYzYw LDE4MCxjN2VmOGFiOCxjMDdhOTVhNSwuLi4pIGF0IHZuX29wZW4rMHgzMwpNYXkgIDQgMTk6NTg6 NDggbW9zaG5yb2xsIGtlcm5lbDoga2Vybl9vcGVuYXQoYzgxN2Q4YzAsZmZmZmZmOWMsYmZiZmU2 M2IsMCxhMDIsLi4uKSBhdCBrZXJuX29wZW5hdCsweGUwCk1heSAgNCAxOTo1ODo0OCBtb3NobnJv bGwga2VybmVsOiBrZXJuX29wZW4oYzgxN2Q4YzAsYmZiZmU2M2IsMCxhMDEsMTgwLC4uLikgYXQg a2Vybl9vcGVuKzB4MzUKTWF5ICA0IDE5OjU4OjQ4IG1vc2hucm9sbCBrZXJuZWw6IG9wZW4oYzgx N2Q4YzAsZTg1ZWJjZjgsYyxjMDdhZWNhMCxjMDdmM2UzOCwuLi4pIGF0IG9wZW4rMHgzMApNYXkg IDQgMTk6NTg6NDggbW9zaG5yb2xsIGtlcm5lbDogc3lzY2FsbChlODVlYmQzOCkgYXQgc3lzY2Fs bCsweDI3YwpNYXkgIDQgMTk6NTg6NDggbW9zaG5yb2xsIGtlcm5lbDogWGludDB4ODBfc3lzY2Fs bCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMApNYXkgIDQgMTk6NTg6NDggbW9zaG5yb2xsIGtl cm5lbDogLS0tIHN5c2NhbGwgKDUsIEZyZWVCU0QgRUxGMzIsIG9wZW4pLCBlaXAgPSAweDI4Mjc3 Zjg3LCBlc3AgPSAweGJmYmZlMjBjLCBlYnAgPSAweGJmYmZlYWE4IC0tLQpNYXkgIDQgMjA6MDA6 MDEgbW9zaG5yb2xsIG5ld3N5c2xvZ1sxMTM2XTogbG9nZmlsZSB0dXJuZWQgb3ZlciBkdWUgdG8g c2l6ZT4xMDBLCg== --+permail-200905042220481e86ffa80000275b-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 22:28: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 A3128106567D; Mon, 4 May 2009 22:28:52 +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 DF52A8FC1F; Mon, 4 May 2009 22:28:51 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.120.34] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 241908524; Tue, 05 May 2009 01:28:45 +0300 Message-ID: <49FF6C11.5030607@FreeBSD.org> Date: Tue, 05 May 2009 01:28:33 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Lucius Windschuh References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> In-Reply-To: <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------080307030500090208040209" Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 22:28:53 -0000 This is a multi-part message in MIME format. --------------080307030500090208040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lucius Windschuh wrote: > I tried this on CURRENT@r191784 (i386) on a Thinkpad T400 (Intel(R) > Core(TM)2 Duo CPU T9400) with INVARIANTS, etc. enabled. > The result was a panic shortly before /sbin/init is called: > > panic: lapic1: zero divisor > > So, the KASSERT in sys/i386/local_apic.c:325 fired: > KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", > lapic_id())); > > Did I forget something? > > My /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > kern.hz=100 > hint.atrtc.0.clock=0 > hint.apic.0.clock=0 > hint.ata.2.pm_level=2 > hint.ata.3.pm_level=3 > vm.pmap.pg_ps_enabled=1 > > dmesg: http://sites.google.com/site/lwfreebsd/Home/files/dmesg-T400-FreeBSD-CURRENT.txt > kernel config: http://sites.google.com/site/lwfreebsd/Home/files/kernel-CURRENT.txt Sorry, my fault. Try attached patch. -- Alexander Motin --------------080307030500090208040209 Content-Type: text/plain; name="local_apic.nohz.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="local_apic.nohz.patch" --- local_apic.c.prev 2009-05-01 23:53:37.000000000 +0300 +++ local_apic.c 2009-05-05 01:10:04.000000000 +0300 @@ -319,7 +319,7 @@ lapic_setup(int boot) } /* We don't setup the timer during boot on the BSP until later. */ - if (!(boot && PCPU_GET(cpuid) == 0)) { + if (!(boot && PCPU_GET(cpuid) == 0) && lapic_timer_hz != 0) { KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", lapic_id())); lapic_timer_set_divisor(lapic_timer_divisor); --------------080307030500090208040209-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 22:32: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 3CBC2106564A; Mon, 4 May 2009 22:32:04 +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 B5DB48FC1B; Mon, 4 May 2009 22:32:03 +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 874161990E3; Tue, 5 May 2009 00:31:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7B91B1990D4; Tue, 5 May 2009 00:31:49 +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 66FB61990D2; Tue, 5 May 2009 00:31:49 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050500314851-2141 ; Tue, 5 May 2009 00:31:48 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 5 May 2009 00:31:48 +0200 Date: Tue, 5 May 2009 00:31:48 +0200 From: Alexey Shuvaev To: Robert Noland Message-ID: <20090504223148.GA1659@wep4035.physik.uni-wuerzburg.de> References: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> <1241463941.1788.31.camel@balrog.2hip.net> MIME-Version: 1.0 In-Reply-To: <1241463941.1788.31.camel@balrog.2hip.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.2HF443 | November 25, 2008) at 05/05/2009 12:31:48 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/05/2009 12:31:49 AM, Serialize complete at 05/05/2009 12:31:49 AM 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: Re: intel graphics loosing msi interrupt on subsequent starts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 22:32:04 -0000 On Mon, May 04, 2009 at 02:05:41PM -0500, Robert Noland wrote: > On Mon, 2009-05-04 at 20:40 +0200, Alexey Shuvaev wrote: > > Hello all! > > > > Sorry if it is already reported... > > > > I have recently upgaded X server from 1.4 to 1.6 > > (ports from ~23.01.2009 -> 03.05.2009). > > On the first start everything works ok (including [glx]gears). > > On the second and subsequent starts everything looks working but jerky, > > I need to move mouse around to get some windows redrawn, > > [glx]gears print warning message about not getting vblank interrupts > > and outputs something about 1-2 frames per 5 seconds. > > > > The inspectation with vmstat -i has shown that the card generates > > interrupts only during the first start of X server. > > > > If I set hw.pci.enable_msi="0" everything is working fine (start X server > > multiple times, switch consoles, [glx]gears, number of irq16-s > > is increasing, ...). > > irq16 is likely shared, so this may or may not be true... At least in > some cases, I was seeing the interrupt handler processing events when > some other device on the shared interrupt fired. Interrupts on Intel > have been a real pain. There is a drm specific tuneable for disabling > msi hw.drm.msi=0. I have a patch which I'm currently using on my g45 > that overhauls the way that we handle interrupts. > > http://people.freebsd.org/~rnoland/drm-intel-050209.patch > > Reports have been mixed with this, but it is working for me... > So far works for me too... irq256: vgapci0 7759 21 Thanks! :) Alexey. From owner-freebsd-current@FreeBSD.ORG Mon May 4 22:34: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 75F6110656F3 for ; Mon, 4 May 2009 22:34:57 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 51A548FC2A for ; Mon, 4 May 2009 22:34:57 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id k40so3453527rvb.43 for ; Mon, 04 May 2009 15:34:57 -0700 (PDT) Received: by 10.141.49.15 with SMTP id b15mr1740077rvk.25.1241475292167; Mon, 04 May 2009 15:14:52 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id c20sm16231458rvf.50.2009.05.04.15.14.49 (version=SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 15:14:50 -0700 (PDT) Date: Mon, 4 May 2009 12:17:22 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ben Kelly 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: current@freebsd.org Subject: Re: [patch] zfs kmem fragmentation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 22:34:58 -0000 On Sat, 2 May 2009, Ben Kelly wrote: > Hello all, > > Lately I've been looking into the "kmem too small" panics that often occur > with zfs if you don't restrict the arc. What I found in my test environment > was that everything works well until the kmem usage hits the 75% limit set in > arc.c. At this point the arc is shrunk and slabs are reclaimed from uma. > Unfortunately, every time this reclamation process runs the kmem space > becomes more fragmented. The vast majority of the time my machine hits the > "kmem too small" panic it has over 200MB of kmem space available, but the > largest fragment is less than 128KB. What consumers make requests of kmem for 128kb and over? What ultimately trips the panic? > > Ideally things would be arranged to free memory without fragmentation. I > have tried a few things along those lines, but none of them have been > successful so far. I'm going to continue that work, but in the meantime I've > put together a patch that tries to avoid fragmentation by slowing kmem growth > before the aggressive reclamation process is required: > > http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff > > It uses the following heuristics to do this: > > - Start arc_c at arc_c_min instead of arc_c_max. This causes the system to > warm up more slowly. > - Half the rate arc_c grows when kmem exceeds kmem_slow_growth_thresh > - Stop arc_c growth when kmem exceeds kmem_target > - Evict arc data when the kmem exceeds kmem_target > - If kmem usage exceeds kmem_target then ask the pagedaemon to reclaim pages > - If the largest kmem fragment is less than kmem_fragment_target then ask > the pagedaemon to reclaim pages > - If the largest kmem fragment is less than a kmem_fragment_thresh then > force the aggressve kmem/arc reclamation process > > The defaults for the various targets and thresholds are: > > kmem_reclaim_threshold = 7/8 kmem > kmem_target = 3/4 kmem > kmem_slow_growth_threshold = 5/8 kmem > kmem_fragment_target = 1/8 kmem > kmem_fragment_thresh = 1/16 kmem > > With this patch I've been able to run my load tests with the default arc size > with kmem values of 512MB to 700MB. I tried one loaded run with a 300MB > kmem, but it panic'ed due to legitimate, non-fragmented kmem exhaustion. > May I suggest an alternate approach; Have you considered placing zfs in its own kernel submap? If all of its allocations are of a like size, fragmentation won't be an issue and it can be constrained to a fixed size without placing pressure on other kmem_map consumers. This is the approach taken for the buffer cache. It makes a good deal of sense. If arc can be taught to handle allocation failures we could eliminate the panic entirely by simply causing arc to run out of space and flush more buffers. Do you believe this would also address the problem? Thanks, Jeff > Please note that you may still encounter some fragmentation. Its possible > for the system to get stuck in a degraded state where its constantly trying > to free pages and memory in attempt to fix the fragmentation. If the system > is in this state the kstat.zfs.misc.arcstats.fragmented_kmem_count sysctl > will be increasing at a fairly rapid rate. > > Anyway, I just thought I would put this out there in case anyone wanted to > try to test with it. I've mainly been loading it using rsync between two > pools on a non-SMP, i386, with 2GB memory. > > Also, if anyone is interested in helping with the fragmentation problem > please let me know. At this point I think the best odds are to modify UMA to > allow some zones to use a custom slab size of 128KB (max zfs buffer size) so > that most of the allocations from kmem are the same size. It also occurred > to me that much of this mess would be simpler if kmem information were passed > up through the vnode so that the top layer entities like pagedaemon could > make better choices for the overall memory usage of the system. Right now we > have a sub-system two or three layers down making decisions for everyone. > Anyway, suggestions and insights are more than welcome. > > Thanks! > > - Ben > _______________________________________________ > 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 4 23:22: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 73C261065670; Mon, 4 May 2009 23:22:14 +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 021FF8FC0A; Mon, 4 May 2009 23:22:13 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so2565429ywe.13 for ; Mon, 04 May 2009 16:22:13 -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=/+7aw/hSDt4QIlNIrJ+kZflW/Puzna+vtSKkbc1k8Jo=; b=TU+0DRkQAbftx1t01/C8xbFf/jlKPVPhIRo5DJXS4tD3/rRFnhqiuj7GXghghKC+VK c4GYdWMxBXhM+pKc/NZWJepIYxT/KQPootSMH8taOEUO503rayEVv2LX1i0SsuM4hZcN oB3xTFj4DYfK6DNtx8hfTNJevqg0NiBuOEQx8= 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=WyVkCZUvcWWnr8nk98F1u1fCVuUfzH0NpZsLcMDIC0DUA71+i3cUL+0HzoZ2EBVogM ymt5pbOiRELLFo/mEQgiYZAcoS6jTFnZqTl2bRHRMyAI30H3/pWgk3ZDcBw769+weQFN hOEe5Oqx9VR2jGTMjdqu8C681aitf5KhUreZE= MIME-Version: 1.0 Received: by 10.151.101.20 with SMTP id d20mr13084900ybm.14.1241479333020; Mon, 04 May 2009 16:22:13 -0700 (PDT) In-Reply-To: <49FF6C11.5030607@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> Date: Tue, 5 May 2009 01:22:12 +0200 Message-ID: <90a5caac0905041622oaddd7cek52f28a9b018b3ea7@mail.gmail.com> From: Lucius Windschuh To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 May 2009 23:22:14 -0000 2009/5/5 Alexander Motin : > Lucius Windschuh wrote: >> [...] >> panic: lapic1: zero divisor > [...] > --- local_apic.c.prev =A0 2009-05-01 23:53:37.000000000 +0300 > +++ local_apic.c =A0 =A0 =A0 =A02009-05-05 01:10:04.000000000 +0300 > @@ -319,7 +319,7 @@ lapic_setup(int boot) > =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0/* We don't setup the timer during boot on the BSP until l= ater. */ > - =A0 =A0 =A0 if (!(boot && PCPU_GET(cpuid) =3D=3D 0)) { > + =A0 =A0 =A0 if (!(boot && PCPU_GET(cpuid) =3D=3D 0) && lapic_timer_hz != =3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KASSERT(lapic_timer_period !=3D 0, ("lapic= %u: zero divisor", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lapic_id())); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lapic_timer_set_divisor(lapic_timer_diviso= r); This patch solves the panic. C3 instead of C2 saves between 0.5 and 1.5 Watt here with some quick measurements. Thanks. Lucius From owner-freebsd-current@FreeBSD.ORG Tue May 5 01:17: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 03C77106566B; Tue, 5 May 2009 01:17:52 +0000 (UTC) (envelope-from matheusber@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 6B6B28FC17; Tue, 5 May 2009 01:17:51 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so2528079ana.13 for ; Mon, 04 May 2009 18:17:50 -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:cc :user-agent:mime-version:content-type:x-priority:importance; bh=NZbexX+o3lNmphnp/4eQvMw8OwvQzop6GKg+9zQ64cc=; b=al0YKphSFyY/mq0DRltde9bFP2zxLP9xpYhbQdFUinWmkeEB76kCeYMY6SmqTsWPHN ta1qyz0We/XEZLn/Ll0fY/RrqJuUe4VuE8hCwXhBChw7uzcjx13JGm9be/E6rZgr75OW 8N9kIVKDBsh9BV52QwIieGfwwdOFjQm9Ws1tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to:cc :user-agent:mime-version:content-type:x-priority:importance; b=DOV70iDXAGV8WzsNDBUM7rSU1NV+Uz7geY/eMqzjuyonVkec4cWxvMw3JPlnv926HY XCembpvahZQmNJEOLPsQOupWQGSj75I5vK4up67UNvk/5Dh+76hQhvCn0IGRBQ+oIltH XZV3Pbf04eg1FmXRp3hRJKEJC6v8dQCm0w3uM= Received: by 10.100.248.16 with SMTP id v16mr14491254anh.60.1241486270727; Mon, 04 May 2009 18:17:50 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.40.240]) by mx.google.com with ESMTPS id c29sm910700anc.30.2009.05.04.18.17.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 18:17:49 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id AF0AFB8074; Mon, 4 May 2009 22:17:40 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Mon, 4 May 2009 22:17:40 -0300 (BRT) Message-ID: <9b2ddf7fa0e24199c4d20aae92edbf67.squirrel@10.1.1.10> In-Reply-To: <1239874051.12971.1.camel@buffy.york.ac.uk> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> <1239874051.12971.1.camel@buffy.york.ac.uk> Date: Mon, 4 May 2009 22:17:40 -0300 (BRT) From: "Nenhum_de_Nos" To: "Gavin Atkinson" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20090504221740_41124" X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: ata and seagate microdrive problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 01:17:52 -0000 ------=_20090504221740_41124 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On Thu, April 16, 2009 06:27, Gavin Atkinson wrote: > On Thu, 2009-04-09 at 19:03 -0300, Nenhum_de_Nos wrote: >> hail, >> >> I'm trying to install current on via itx using ide 44pin to cf adapter >> and >> a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter I >> got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and >> both fail to find it. the same thing in 7.1R. > > Can you boot in verbose mode, and post the dmesg somewhere please? they're attached :) just remember the seagate is there, but I'm using and old samsung 6.4GB to boot, using SATA<>IDE adapter and SIL3112 sata controller. > Also, can you confirm which ATA channel the drive should show up on? I'd say first one, as it is in the onboard ide controller. I don't know much more to say, but that OpenBSD sees it as wd0. if any more info needed, just say so. almost forgot: FreeBSD xxx 8.0-HEAD-20090501-JPSNAP FreeBSD 8.0-HEAD-20090501-JPSNAP #0: Fri May 1 04:22:31 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC i386 thanks, matheus > Thanks, > > Gavin > >> I found this http://forums.freebsd.org/archive/index.php/t-2733.html, >> but >> hw.ata.ata_dma_check_80pin=0 is no good :( >> >> and found this pr >> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html >> as >> the only pr that mentions microdrive (I may be wrong). > > -- We will call you cygnus, The God of balance you shall be ------=_20090504221740_41124 Content-Type: application/octet-stream; name="pciconv" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pciconv" aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMjk1MTI3OSBjaGlwPTB4 MDM5NTEyNzkgcmV2PTB4MDQgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVHJhbnNtZXRhIENv cnAuJwogICAgZGV2aWNlICAgICA9ICdMb25nUnVuIE5vcnRoYnJpZGdlJwogICAgY2xhc3MgICAg ICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCm5vbmUwQHBjaTA6MDowOjE6CWNs YXNzPTB4MDUwMDAwIGNhcmQ9MHgwMjk1MTI3OSBjaGlwPTB4MDM5NjEyNzkgcmV2PTB4MDAgaGRy PTB4MDAKICAgIHZlbmRvciAgICAgPSAnVHJhbnNtZXRhIENvcnAuJwogICAgZGV2aWNlICAgICA9 ICdTRFJBTSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IG1lbW9yeQogICAgc3ViY2xhc3Mg ICA9IFJBTQpub25lMUBwY2kwOjA6MDoyOgljbGFzcz0weDA1MDAwMCBjYXJkPTB4MDI5NTEyNzkg Y2hpcD0weDAzOTcxMjc5IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1RyYW5z bWV0YSBDb3JwLicKICAgIGRldmljZSAgICAgPSAnQklPUyBzY3JhdGNocGFkJwogICAgY2xhc3Mg ICAgICA9IG1lbW9yeQogICAgc3ViY2xhc3MgICA9IFJBTQpub25lMkBwY2kwOjA6MDozOgljbGFz cz0weDA1MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDAzOTkxMjc5IHJldj0weDAwIGhkcj0w eDAwCiAgICB2ZW5kb3IgICAgID0gJ1RyYW5zbWV0YSBDb3JwLicKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0KdWhjaTBAcGNpMDowOjk6MDoJY2xhc3M9MHgwYzAz MDAgY2FyZD0weDMwMzgxMTA2IGNoaXA9MHgzMDM4MTEwNiByZXY9MHg2MSBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVzIEluYycKICAgIGRldmljZSAgICAgPSAnVlQ4 M0M1NzIsIFZUNjIwMiBWSUEgUmV2IDUgb3IgbGF0ZXIgVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRy b2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFVTQgp1 aGNpMUBwY2kwOjA6OToxOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4MzAzODExMDYgY2hpcD0weDMw MzgxMTA2IHJldj0weDYxIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dp ZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDgzQzU3MiwgVlQ2MjAyIFZJQSBSZXYgNSBvciBs YXRlciBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmVoY2kwQHBjaTA6MDo5OjI6CWNsYXNzPTB4MGMw MzIwIGNhcmQ9MHgzMTA0MTEwNiBjaGlwPTB4MzEwNDExMDYgcmV2PTB4NjMgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1ZU NjIwMi8xMiBVU0IgMi4wIEVuaGFuY2VkIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAg PSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmF0YXBjaTBAcGNpMDowOjExOjA6CWNs YXNzPTB4MDEwNDAwIGNhcmQ9MHg2MTE0MTA5NSBjaGlwPTB4MzExNDEwOTUgcmV2PTB4MDIgaGRy PTB4MDAKICAgIHZlbmRvciAgICAgPSAnU2lsaWNvbiBJbWFnZSBJbmMgKFdhczogQ01EIFRlY2hu b2xvZ3kgSW5jKScKICAgIGRldmljZSAgICAgPSAnU2lsIDMxMTQgU0FUQUxpbmsvU0FUQVJhaWQg Q29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzICAg PSBSQUlECnZnYXBjaTBAcGNpMDowOjEzOjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHg1MTU5MTAw MiBjaGlwPTB4NTE1OTEwMDIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQVRJ IFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1JWMTAwIFJhZGVvbiA3MDAwIC8g UmFkZW9uIFZFJwogICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EK aXNhYjBAcGNpMDowOjE3OjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHgwMDAwMTEwNiBjaGlwPTB4 ODIzMTExMDYgcmV2PTB4MTAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xv Z2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1ZUODIzMSBQQ0kgdG8gSVNBIEJyaWRnZScKICAg IGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmF0YXBjaTFAcGNp MDowOjE3OjE6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHgwNTcxMTEwNiBjaGlwPTB4MDU3MTExMDYg cmV2PTB4MDYgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcyBJbmMn CiAgICBkZXZpY2UgICAgID0gJ1ZUODJDNTg2QS9CL1ZUODJDNjg2L0EvQi9WVDgyM3gvQS9DIEJ1 cyBNYXN0ZXIgSURFIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAg ICBzdWJjbGFzcyAgID0gQVRBCm5vbmUzQHBjaTA6MDoxNzo0OgljbGFzcz0weDA2ODAwMCBjYXJk PTB4ODIzNTExMDYgY2hpcD0weDgyMzUxMTA2IHJldj0weDEwIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDg3NTEgUG93 ZXIgTWFuYWdlbWVudCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQp2cjBAcGNp MDowOjE4OjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgwMTAyMTEwNiBjaGlwPTB4MzA2NTExMDYg cmV2PTB4NTEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcyBJbmMn CiAgICBkZXZpY2UgICAgID0gJ1ZUNjEwMiBSaGluZSBJSSBQQ0kgRmFzdCBFdGhlcm5ldCBDb250 cm9sbGVyfHxVc2VkIGJ5IEdFUklDT00gaW4gbGFwdG9wIFdlYmVuZ2luZSBBZHZhbmNlZCcKICAg IGNsYXNzICAgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQK ------=_20090504221740_41124 Content-Type: application/octet-stream; name="dmesg.verbose" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.verbose" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtSEVBRC0yMDA5MDUwMS1KUFNOQVAgIzA6IEZy aSBNYXkgIDEgMDQ6MjI6MzEgVVRDIDIwMDkKICAgIHJvb3RAYnVpbGQtaTM4Ni1mYnNkLTIuYWxs YnNkLm9yZzovdXNyL29iai9pMzg2L3Vzci9zcmMvc3lzL0dFTkVSSUMKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClByZWxvYWRlZCBl bGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGMxMGI3MDAwLgpUaW1lY291bnRl ciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDYWxpYnJhdGluZyBUU0Mg Y2xvY2sgLi4uIFRTQyBjbG9jazogNzk4MTMwNjE2IEh6CkNQVTogVHJhbnNtZXRhKHRtKSBDcnVz b2UodG0pIFByb2Nlc3NvciBUTTU3MDAgKDc5OC4xMy1NSHogNTg2LWNsYXNzIENQVSkKICBPcmln aW4gPSAiR2VudWluZVRNeDg2IiAgSWQgPSAweDU0MyAgU3RlcHBpbmcgPSAzCiAgRmVhdHVyZXM9 MHg4NDg5M2Y8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixDWDgsU0VQLENNT1YsUE4sTU1YPgogIFBy b2Nlc3NvciByZXZpc2lvbiAxLjUuMC4yCiAgQ29kZSBNb3JwaGluZyBTb2Z0d2FyZSByZXZpc2lv biA0LjUuMi0xMi0xMQogIDIwMDQwNjE0IDE1OjAwIG9mZmljaWFsIHJlbGVhc2UgNC41LjIjMQpy ZWFsIG1lbW9yeSAgPSAxMzYzMTQ4ODAgKDEzMCBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMp OgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOTlmZmYsIDYyNjY4OCBieXRlcyAo MTUzIHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3 MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAxNDI1MDAwIC0gMHgwMDAwMDAwMDA2ZGQx ZmZmLCA5NDAzMTg3MiBieXRlcyAoMjI5NTcgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDk1ODEzNjMy ICg5MSBNQikKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVyIGF0 IDB4YzAwZjlkZTAKYmlvczMyOiBFbnRyeSA9IDB4ZmEyNjAgKGMwMGZhMjYwKSAgUmV2ID0gMCAg TGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4YTI5MApwbnBiaW9z OiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmFjZjAKcG5wYmlvczogRW50cnkgPSBmMDAw MDphZDIwICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgpVTEU6IHNldHVw IGNwdSAwCndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJv IGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xv Y2s6IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MApp bzogPEkvTz4KbWVtOiA8bWVtb3J5PgpocHRycjogUm9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBj b250cm9sbGVyIGRyaXZlciB2MS4yIChNYXkgIDEgMjAwOSAwNDoyMToxOCkKbnB4MDogSU5UIDE2 IGludGVyZmFjZQpwY2lfb3BlbigxKToJbW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgw MDAwMDU4CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNp X2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRyPTgwXSBpcyB0aGVyZSAoaWQ9 MDM5NTEyNzkpCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEwCnBjaWIwOiA8SG9zdCB0byBQQ0kg YnJpZGdlPiBwY2lidXMgMCBvbiBtb3RoZXJib2FyZApwaXIwOiA8UENJIEludGVycnVwdCBSb3V0 aW5nIFRhYmxlOiA1IEVudHJpZXM+IG9uIG1vdGhlcmJvYXJkCiRQSVI6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkxpbmsgIElSUSAgUnRkICBSZWYgIElSUXMKIDB4MiAgMjU1ICAgTiAgICAg MyAgMyA0IDUgNyA5IDEwIDExIDE0IDE1CiAweDMgIDI1NSAgIE4gICAgIDQgIDMgNCA1IDcgOSAx MCAxMSAxNCAxNQogMHg1ICAyNTUgICBOICAgICA0ICAzIDQgNSA3IDkgMTAgMTEgMTQgMTUKIDB4 MSAgMjU1ICAgTiAgICAgNCAgMyA0IDUgNyA5IDEwIDExIDE0IDE1CiRQSVI6IEZvdW5kIG1hdGNo aW5nIHBpbiBmb3IgMC4xMS5JTlRBIGF0IGZ1bmMgMDogMTUKJFBJUjogRm91bmQgbWF0Y2hpbmcg cGluIGZvciAwLjEzLklOVEEgYXQgZnVuYyAwOiAxMAokUElSOiBGb3VuZCBtYXRjaGluZyBwaW4g Zm9yIDAuOS5JTlRBIGF0IGZ1bmMgMDogMTEKJFBJUjogRm91bmQgbWF0Y2hpbmcgcGluIGZvciAw LjkuSU5UQiBhdCBmdW5jIDE6IDE1CiRQSVI6IEZvdW5kIG1hdGNoaW5nIHBpbiBmb3IgMC45LklO VEMgYXQgZnVuYyAyOiA1CiRQSVI6IEZvdW5kIG1hdGNoaW5nIHBpbiBmb3IgMC4xOC5JTlRBIGF0 IGZ1bmMgMDogMTEKJFBJUjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBJUlEgZGlzY292ZXJ5OgpMaW5r ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAweDIgICAxNSAgIFkgICAgIDMgIDMgNCA1IDcgOSAxMCAx MSAxNCAxNQogMHgzICAgIDUgICBZICAgICA0ICAzIDQgNSA3IDkgMTAgMTEgMTQgMTUKIDB4NSAg IDEwICAgWSAgICAgNCAgMyA0IDUgNyA5IDEwIDExIDE0IDE1CiAweDEgICAxMSAgIFkgICAgIDQg IDMgNCA1IDcgOSAxMCAxMSAxNCAxNQokUElSOiBJUlFzIHVzZWQgYnkgQklPUzogNSAxMCAxMSAx NQokUElSOiBJbnRlcnJ1cHQgV2VpZ2h0czoKWyAgICAwICAgMSAgIDIgICAzICAgNCAgIDUgICA2 ICAgNyAgIDggICA5ICAxMCAgMTEgIDEyICAxMyAgMTQgIDE1IF0KWyAgICAwICAgMCAgIDAgICAw ICAgMCAgIDQgICAwICAgMCAgIDAgICAwICAgNCAgIDQgICAwICAgMCAgIDAgICAzIF0KcGNpMDog PFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MApmb3VuZC0+ CXZlbmRvcj0weDEyNzksIGRldj0weDAzOTUsIHJldmlkPTB4MDQKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgyMjAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGU4MDAwMDAwLCBzaXplIDIw LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTI3OSwgZGV2PTB4MDM5NiwgcmV2aWQ9MHgwMAoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MQoJY2xhc3M9MDUtMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMjc5LCBkZXY9MHgwMzk3LCByZXZpZD0w eDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0yCgljbGFzcz0wNS0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEyNzksIGRldj0weDAzOTksIHJl dmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTMKCWNsYXNzPTA1LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MzAz OCwgcmV2aWQ9MHg2MQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTksIGZ1bmM9MAoJY2xhc3M9MGMt MDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAy MTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGUwMDAsIHNpemUgIDUsIGVuYWJsZWQKJFBJUjogMDo5 IElOVEEgcm91dGVkIHRvIGlycSAxMQpmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMwMzgs IHJldmlkPTB4NjEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD05LCBmdW5jPTEKCWNsYXNzPTBjLTAz LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxNDcsIHN0YXRyZWc9MHgwMjEw LCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTUKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzIwXTogdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlMTAwLCBzaXplICA1LCBlbmFibGVkCiRQSVI6IDA6OSBJ TlRCIHJvdXRlZCB0byBpcnEgMTUKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMTA0LCBy ZXZpZD0weDYzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9OSwgZnVuYz0yCgljbGFzcz0wYy0wMy0y MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTUKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZTgxOTIwMDAsIHNpemUgIDgsIGVuYWJsZWQKJFBJUjogMDo5IElO VEMgcm91dGVkIHRvIGlycSA1CmZvdW5kLT4JdmVuZG9yPTB4MTA5NSwgZGV2PTB4MzExNCwgcmV2 aWQ9MHgwMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTExLCBmdW5jPTAKCWNsYXNzPTAxLTA0LTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxNDcsIHN0YXRyZWc9MHgwMmIwLCBj YWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTUKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhlMjAwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMTRdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGUzMDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsx OF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZTQwMCwgc2l6ZSAgMywgZW5hYmxl ZAoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlNTAwLCBzaXplICAy LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGU2MDAs IHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGU4MTkwMDAwLCBzaXplIDEwLCBlbmFibGVkCiRQSVI6IDA6MTEgSU5UQSByb3V0ZWQgdG8gaXJx IDE1CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NTE1OSwgcmV2aWQ9MHgwMAoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTEzLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAxODcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdv cmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5 LCByYW5nZSAzMiwgYmFzZSAweGUwMDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCgltYXBbMTRdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGU3MDAsIHNpemUgIDgsIGVuYWJsZWQKCW1h cFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGU4MTgwMDAwLCBzaXplIDE2LCBl bmFibGVkCiRQSVI6IDA6MTMgSU5UQSByb3V0ZWQgdG8gaXJxIDEwCmZvdW5kLT4JdmVuZG9yPTB4 MTEwNiwgZGV2PTB4ODIzMSwgcmV2aWQ9MHgxMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE3LCBm dW5jPTAKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw ODcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9 MHgwNTcxLCByZXZpZD0weDA2Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9MQoJY2xh c3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJl Zz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweGU4MDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9 MHg4MjM1LCByZXZpZD0weDEwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9NAoJY2xh c3M9MDYtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMCwgc3RhdHJl Zz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMwNjUsIHJl dmlkPTB4NTEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOCwgZnVuYz0wCgljbGFzcz0wMi0wMC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAz ICg3NTAgbnMpLCBtYXhsYXQ9MHgwOCAoMjAwMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlYjAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlODE5MTAwMCwgc2l6ZSAgOCwgZW5hYmxl ZAokUElSOiAwOjE4IElOVEEgcm91dGVkIHRvIGlycSAxMQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0 IGRldmljZSAwLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBk ZXZpY2UgMC4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2 aWNlIDAuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp1aGNpMDogPFZJQSA4M0M1NzIgVVNCIGNvbnRy b2xsZXI+IHBvcnQgMHhlMDAwLTB4ZTAxZiBpcnEgMTEgYXQgZGV2aWNlIDkuMCBvbiBwY2kwCnVo Y2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhlMDAwCnVo Y2kwOiBbTVBTQUZFXQp1aGNpMDogW0lUSFJFQURdCnVoY2kwOiBMZWdTdXAgPSAweDIwMWEKdXNi dXMwOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdWhjaTE6IDxWSUEgODND NTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZTEwMC0weGUxMWYgaXJxIDE1IGF0IGRldmljZSA5 LjEgb24gcGNpMAp1aGNpMTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4ZTEwMAp1aGNpMTogW01QU0FGRV0KdWhjaTE6IFtJVEhSRUFEXQp1aGNpMTogTGVnU3Vw ID0gMHgyMDEwCnVzYnVzMTogPFZJQSA4M0M1NzIgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCmVo Y2kwOiA8VklBIFZUNjIwMiBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGU4MTkyMDAwLTB4ZTgx OTIwZmYgaXJxIDUgYXQgZGV2aWNlIDkuMiBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDEwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTgxOTIwMDAKZWhjaTA6IFtNUFNBRkVdCmVo Y2kwOiBbSVRIUkVBRF0KdXNidXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPFZJQSBWVDYy MDIgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAphdGFwY2kwOiA8U2lJIDMxMTQgU0FUQTE1 MCBjb250cm9sbGVyPiBwb3J0IDB4ZTIwMC0weGUyMDcsMHhlMzAwLTB4ZTMwMywweGU0MDAtMHhl NDA3LDB4ZTUwMC0weGU1MDMsMHhlNjAwLTB4ZTYwZiBtZW0gMHhlODE5MDAwMC0weGU4MTkwM2Zm IGlycSAxNSBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0 ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGU2MDAKYXRhcGNpMDogW01QU0FGRV0KYXRhcGNp MDogW0lUSFJFQURdCmF0YXBjaTA6IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgyNCB0 eXBlIDMgYXQgMHhlODE5MDAwMAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEy OiBTQVRBIGNvbm5lY3QgdGltZT0wbXMgc3RhdHVzPTAwMDAwMTEzCmF0YTI6IHJlc2V0IHRwMSBt YXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMjogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9 MHgwMCBtc2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0w eDEKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBv biBhdGFwY2kwCmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGEz OiBbTVBTQUZFXQphdGEzOiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9uIGF0YXBj aTAKYXRhNDogU0FUQSBjb25uZWN0IHRpbWVvdXQgc3RhdHVzPTAwMDAwMDAwCmF0YTQ6IFtNUFNB RkVdCmF0YTQ6IFtJVEhSRUFEXQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNpMAphdGE1 OiBTQVRBIGNvbm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYXRhNTogW01QU0FGRV0KYXRh NTogW0lUSFJFQURdCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZTcw MC0weGU3ZmYgbWVtIDB4ZTAwMDAwMDAtMHhlN2ZmZmZmZiwweGU4MTgwMDAwLTB4ZTgxOGZmZmYg aXJxIDEwIGF0IGRldmljZSAxMy4wIG9uIHBjaTAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQg ZGV2aWNlIDE3LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMTogPFZJ QSA4MjMxIFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0w eDE3NywweDM3NiwweGU4MDAtMHhlODBmIGF0IGRldmljZSAxNy4xIG9uIHBjaTAKYXRhcGNpMTog UmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZTgwMAphdGEwOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kxOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9y IHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9 NTggb3N0YXQxPTAwCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAK YXRhMDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNldCB0 cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEKYXRhMDogW01QU0FGRV0KYXRhMDogW0lU SFJFQURdCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0YXBjaTE6IFJlc2VydmVk IDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTE6IFJlc2VydmVk IDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0IHRwMSBt YXNrPTAwIG9zdGF0MD1mZiBvc3RhdDE9ZmYKYXRhMTogW01QU0FGRV0KYXRhMTogW0lUSFJFQURd CnBjaTA6IDxicmlkZ2U+IGF0IGRldmljZSAxNy40IChubyBkcml2ZXIgYXR0YWNoZWQpCnZyMDog PFZJQSBWVDYxMDIgUmhpbmUgSUkgMTAvMTAwQmFzZVRYPiBwb3J0IDB4ZWIwMC0weGViZmYgbWVt IDB4ZTgxOTEwMDAtMHhlODE5MTBmZiBpcnEgMTEgYXQgZGV2aWNlIDE4LjAgb24gcGNpMAp2cjA6 IFF1aXJrczogMHgwCnZyMDogUmV2aXNpb246IDB4NTEKdnIwOiBSZXNlcnZlZCAweDEwMCBieXRl cyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZWIwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gdnIw CnVrcGh5MDogPEdlbmVyaWMgSUVFRSA4MDIuM3UgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBt aWlidXMwCnVrcGh5MDogT1VJIDB4MDA0MDYzLCBtb2RlbCAweDAwMzIsIHJldi4gMTAKdWtwaHkw OiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwp2 cjA6IGJwZiBhdHRhY2hlZAp2cjA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEzOjIxOmVlOjI2OjAw CnZyMDogW01QU0FGRV0KdnIwOiBbSVRIUkVBRF0KY3B1MCBvbiBtb3RoZXJib2FyZAp1bmtub3du OiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWls ZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMg cmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5r bm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgphaGNfaXNhX3Byb2JlIDE0OiBpb3BvcnQg MHhlYzAwIGFsbG9jIGZhaWxlZApwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBs ZXRlCmV4X2lzYV9pZGVudGlmeSgpCnBucGJpb3M6IDExIGRldmljZXMsIGxhcmdlc3QgNzggYnl0 ZXMKUE5QMDIwMDogYWRkaW5nIGRtYSBtYXNrIDB4MTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdl IDAtMHhmLCBzaXplPTB4MTAsIGFsaWduPTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4ODEt MHg4Mywgc2l6ZT0weDMsIGFsaWduPTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4ODctMHg4 Nywgc2l6ZT0weDEsIGFsaWduPTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4ODktMHg4Yiwg c2l6ZT0weDMsIGFsaWduPTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4OGYtMHg5MSwgc2l6 ZT0weDMsIGFsaWduPTAKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4YzAtMHhkZiwgc2l6ZT0w eDIwLCBhbGlnbj0wCnBucGJpb3M6IGhhbmRsZSAxIGRldmljZSBJRCBQTlAwMjAwICgwMDAyZDA0 MSkKUE5QMDEwMDogYWRkaW5nIGlycSBtYXNrIDB4MQpQTlAwMTAwOiBhZGRpbmcgaW8gcmFuZ2Ug MHg0MC0weDQzLCBzaXplPTB4NCwgYWxpZ249MApwbnBiaW9zOiBoYW5kbGUgMiBkZXZpY2UgSUQg UE5QMDEwMCAoMDAwMWQwNDEpClBOUDBiMDA6IGFkZGluZyBpcnEgbWFzayAweDEwMApQTlAwYjAw OiBhZGRpbmcgaW8gcmFuZ2UgMHg3MC0weDcxLCBzaXplPTB4MiwgYWxpZ249MApwbnBiaW9zOiBo YW5kbGUgMyBkZXZpY2UgSUQgUE5QMGIwMCAoMDAwYmQwNDEpClBOUDAzMDM6IGFkZGluZyBpcnEg bWFzayAweDIKUE5QMDMwMzogYWRkaW5nIGlvIHJhbmdlIDB4NjAtMHg2MCwgc2l6ZT0weDEsIGFs aWduPTAKUE5QMDMwMzogYWRkaW5nIGlvIHJhbmdlIDB4NjQtMHg2NCwgc2l6ZT0weDEsIGFsaWdu PTAKcG5wYmlvczogaGFuZGxlIDQgZGV2aWNlIElEIFBOUDAzMDMgKDAzMDNkMDQxKQpQTlAwODAw OiBhZGRpbmcgaW8gcmFuZ2UgMHg2MS0weDYxLCBzaXplPTB4MSwgYWxpZ249MApwbnBiaW9zOiBo YW5kbGUgNSBkZXZpY2UgSUQgUE5QMDgwMCAoMDAwOGQwNDEpClBOUDBjMDQ6IGFkZGluZyBpcnEg bWFzayAweDIwMDAKUE5QMGMwNDogYWRkaW5nIGlvIHJhbmdlIDB4ZjAtMHhmZiwgc2l6ZT0weDEw LCBhbGlnbj0wCnBucGJpb3M6IGhhbmRsZSA2IGRldmljZSBJRCBQTlAwYzA0ICgwNDBjZDA0MSkK UE5QMGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDAtMHg5ZmZmZiwgc2l6ZT0weGEw MDAwClBOUDBjMDE6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGZmZmUwMDAwLTB4ZmZm ZmZmZmYsIHNpemU9MHgyMDAwMApQTlAwYzAxOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2Ug MHhmZmY4MDAwMC0weGZmZmRmZmZmLCBzaXplPTB4NjAwMDAKUE5QMGMwMTogYWRkaW5nIGZpeGVk IG1lbW9yeTMyIHJhbmdlIDB4ZmVlMDAwMDAtMHhmZWUwZmZmZiwgc2l6ZT0weDEwMDAwClBOUDBj MDE6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweDEwMDAwMC0weGZmZmZmZiwgc2l6ZT0w eGYwMDAwMApwbnBiaW9zOiBoYW5kbGUgNyBkZXZpY2UgSUQgUE5QMGMwMSAoMDEwY2QwNDEpClBO UDBjMDI6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGYwMDAwLTB4ZjNmZmYsIHNpemU9 MHg0MDAwClBOUDBjMDI6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGY0MDAwLTB4Zjdm ZmYsIHNpemU9MHg0MDAwClBOUDBjMDI6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGY4 MDAwLTB4ZmZmZmYsIHNpemU9MHg4MDAwClBOUDBjMDI6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiBy YW5nZSAweGRhMDAwLTB4ZGJmZmYsIHNpemU9MHgyMDAwCnBucGJpb3M6IGhhbmRsZSA4IGRldmlj ZSBJRCBQTlAwYzAyICgwMjBjZDA0MSkKUE5QMGEwMzogYWRkaW5nIGlvIHJhbmdlIDB4NGQwLTB4 NGQxLCBzaXplPTB4MiwgYWxpZ249MApQTlAwYTAzOiBhZGRpbmcgaW8gcmFuZ2UgMHhjZjgtMHhj ZmYsIHNpemU9MHg4LCBhbGlnbj0wClBOUDBhMDM6IGFkZGluZyBpbyByYW5nZSAweDQwMDAtMHg0 MDdmLCBzaXplPTB4ODAsIGFsaWduPTAKUE5QMGEwMzogYWRkaW5nIGlvIHJhbmdlIDB4NDA4MC0w eDQwZmYsIHNpemU9MHg4MCwgYWxpZ249MApQTlAwYTAzOiBhZGRpbmcgaW8gcmFuZ2UgMHg1MDAw LTB4NTAxZiwgc2l6ZT0weDIwLCBhbGlnbj0wClBOUDBhMDM6IGFkZGluZyBpbyByYW5nZSAweDYw MDAtMHg2MDdmLCBzaXplPTB4ODAsIGFsaWduPTAKcG5wYmlvczogaGFuZGxlIDkgZGV2aWNlIElE IFBOUDBhMDMgKDAzMGFkMDQxKQpQTlAwNzAwOiBhZGRpbmcgZG1hIG1hc2sgMHg0ClBOUDA3MDA6 IGFkZGluZyBpbyByYW5nZSAweDNmMi0weDNmNSwgc2l6ZT0weDQsIGFsaWduPTAKUE5QMDcwMDog YWRkaW5nIGlvIHJhbmdlIDB4M2Y3LTB4M2Y3LCBzaXplPTB4MSwgYWxpZ249MApQTlAwNzAwOiBh ZGRpbmcgaXJxIG1hc2sgMHg0MApwbnBiaW9zOiBoYW5kbGUgMTMgZGV2aWNlIElEIFBOUDA3MDAg KDAwMDdkMDQxKQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwpwbXRp bWVyMCBvbiBpc2EwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBhdCBwb3J0IDB4NzAtMHg3 MSBpcnEgOCBwbnBpZCBQTlAwYjAwIG9uIGlzYTAKYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGlt ZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAwMDAwMHVzKQphdGtiZGMwOiA8S2V5Ym9hcmQg Y29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBpcnEgMSBwbnBpZCBQTlAwMzAz IG9uIGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHRo ZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY3CmF0a2JkOiBrZXlib2Fy ZCBJRCAweGZmZmZmZmZmICgxKQphdGtiZDogZmFpbGVkIHRvIHJlc2V0IHRoZSBrZXlib2FyZC4K a2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCA4NCAoMSksIGNvbmZpZzoweDAsIGZsYWdz OjB4M2QwMDAwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHNtMDog dW5hYmxlIHRvIGFsbG9jYXRlIElSUQp1bmtub3duOiA8QVQgUmVhbCBUaW1lIENsb2NrPiBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDYxIHBucGlkIFBOUDA4MDAgb24gaXNhMAp1bmtub3duOiA8 UE5QMGMwMT4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAobWVtb3J5KQp1bmtub3duOiA8UE5QMGMw MT4gYXQgaW9tZW0gMC0weDlmZmZmIHBucGlkIFBOUDBjMDEgb24gaXNhMAp1bmtub3duOiA8QVQg UmVhbCBUaW1lIENsb2NrPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMi0weDNmNSwweDNm NyBpcnEgNiBkcnEgMiBwbnBpZCBQTlAwNzAwIG9uIGlzYTAKYXRhOiBhdGEwIGFscmVhZHkgZXhp c3RzOyBza2lwcGluZyBpdAphdGE6IGF0YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0 a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRydGM6IGF0cnRjMCBh bHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBp bmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hp bGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjOGZmZiwweGNjMDAwLTB4Y2ZmZmYsMHhkMDAwMC0weGQ5ZmZmIHBu cGlkIE9STTAwMDAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAg b24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDog ZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWluYWwpCnZn YTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0w eGJmZmZmIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYnQwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKY3MwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZWQwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBp cnEgNiBkcnEgMiBvbiBpc2EwCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmllMDogbm90IHBy b2JlZCAoZGlzYWJsZWQpCmxlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnBwYzA6IHBhcmFsbGVs IHBvcnQgbm90IGZvdW5kLgpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0 IGlycSA3IG9uIGlzYTAKc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdWFydDA6IDxuczgyNTA+ IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IG9uIGlzYTAKdWFydDE6 IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlz YTAKdWFydDI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1YXJ0Mzogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwp1bmtub3duOiA8UE5Q MGMwMT4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAobWVtb3J5KQp1bmtub3duOiA8UE5QMGMwMT4g YXQgaW9tZW0gMC0weDlmZmZmIHBucGlkIFBOUDBjMDEgb24gaXNhMApEZXZpY2UgY29uZmlndXJh dGlvbiBmaW5pc2hlZC4KcHJvY2ZzIHJlZ2lzdGVyZWQKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVl bmN5IDc5ODEzMDYxNiBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAw MCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgph dGEwOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQphdGEwOiBOZXcgZGV2aWNlczogMDAw MDAwMDEKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBG dWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVn ZW4wLjE6IDxWSUE+IGF0IHVzYnVzMAp1aHViMDogPFZJQSBVSENJIHJvb3QgSFVCLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxWSUE+IGF0IHVz YnVzMQp1aHViMTogPFZJQSBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxWSUE+IGF0IHVzYnVzMgp1aHViMjogPFZJQSBF SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMy CnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBw b3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYXRhMDogcmVpbml0aW5nIGNoYW5u ZWwgLi4KYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTU4IG9zdGF0MT0wMAphdGEwOiBz dGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHN0YXQxPTB4MDAgZXJy PTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAw IGRldmljZXM9MHgxCmF0YTA6IHJlaW5pdCBkb25lIC4uCnVua25vd246IEZBSUxVUkUgLSBBVEFf SURFTlRJRlkgdGltZWQgb3V0IExCQT0wCnVodWIyOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAphdGEwOiByZWluaXRpbmcgY2hhbm5lbCAuLgphdGEwOiByZXNldCB0cDEg bWFzaz0wMyBvc3RhdDA9NTggb3N0YXQxPTAwCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNi PTB4MDAgbXNiPTB4MDAKYXRhMDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgw MAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEKYXRhMDogcmVp bml0IGRvbmUgLi4KdW5rbm93bjogRkFJTFVSRSAtIEFUQV9JREVOVElGWSB0aW1lZCBvdXQgTEJB PTAKYXRhMTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKYXRhMTogTmV3IGRldmljZXM6 IDAwMDAwMDAwCmF0YTI6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAxCmF0YTI6IE5ldyBk ZXZpY2VzOiAwMDAwMDAwMQphdGEyLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVE TUEzMyBjYWJsZT00MCB3aXJlCmFkNDogNjE0OU1CIDxTQU1TVU5HIFNWMDY0M0QgS1QxMDA+IGF0 IGF0YTItbWFzdGVyIFNBVEExNTAKYWQ0OiAxMjU5NDk2MCBzZWN0b3JzIFsxMzMyOEMvMTVILzYz U10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDQK YWQ0OiBTaWxpY29uIEltYWdlIGNoZWNrMSBmYWlsZWQKYWQ0OiBBZGFwdGVjIGNoZWNrMSBmYWls ZWQKYWQ0OiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2MikgY2hlY2sxIGZhaWxl ZAphZDQ6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphdGEzOiBJZGVudGlmeWluZyBkZXZpY2VzOiAw MDAwMDAwMAphdGEzOiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhNDogSWRlbnRpZnlpbmcgZGV2 aWNlczogMDAwMDAwMDAKYXRhNDogTmV3IGRldmljZXM6IDAwMDAwMDAwCmF0YTU6IElkZW50aWZ5 aW5nIGRldmljZXM6IDAwMDAwMDAwCmF0YTU6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMApBVEEgUHNl dWRvUkFJRCBsb2FkZWQKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJl ZHVjZWQgcGVyZm9ybWFuY2UuCkdFT006IGFkNHMxOiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBs YWJlbCAoMjU1aCw2M3MgIT0gMTVoLDYzcykuCkdFT006IGFkNHMyOiBnZW9tZXRyeSBkb2VzIG5v dCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTVoLDYzcykuCkdFT01fTEFCRUw6IExhYmVsIGZv ciBwcm92aWRlciBhZDRzMWEgaXMgdWZzaWQvNDhhNDk4MzkzYjZkOGJlYS4KVHJ5aW5nIHRvIG1v dW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDRzMWEKY3RfdG9fdHMoWzIwMDktMDUtMDQgMjI6MTA6 MTddKSA9IDEyNDE0NzUwMTcuMDAwMDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0 CnVnZW4xLjI6IDxHTS1URUs+IGF0IHVzYnVzMQp1a2JkMDogPEhJRCBLZXlib2FyZD4gb24gdXNi dXMxCmtiZDIgYXQgdWtiZDAKa2JkMjogdWtiZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBm bGFnczoweDNkMDAwMAp1bXMwOiA8SElEIE1vdXNlPiBvbiB1c2J1czEKdW1zMDogMyBidXR0b25z IGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ4YTQ5 ODM5M2I2ZDhiZWEgcmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkNHMx YSBpcyB1ZnNpZC80OGE0OTgzOTNiNmQ4YmVhLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80OGE0 OTgzOTNiNmQ4YmVhIHJlbW92ZWQuCnNwbGFzaDogaW1hZ2UgZGVjb2RlciBmb3VuZDogZ3JlZW5f c2F2ZXIK ------=_20090504221740_41124-- From owner-freebsd-current@FreeBSD.ORG Tue May 5 06:31: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 3D2771065670 for ; Tue, 5 May 2009 06:31:24 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 351268FC13 for ; Tue, 5 May 2009 06:31:23 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 15A635C070 for ; Tue, 5 May 2009 14:31:22 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id CCAF855D16AD; Tue, 5 May 2009 14:31:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 6INgrL9yeNtE; Tue, 5 May 2009 14:30:22 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 5B39A55D16A3; Tue, 5 May 2009 14:30:12 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=lawNyuPWZTkC9GRshN3MzorUG+UluNhT0wS20DtdN9NwphNPMcGYsfbxn3LWrOlN4 XImLosnJ33NMxarFUstAQ== Date: Tue, 05 May 2009 14:30:06 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905041238.30304.hselasky@c2i.net> <200905041556.18646.hselasky@c2i.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200905041556.18646.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 06:31:24 -0000 Hi Hans, There is new dmesg with debug=15, but I can't catch difference... [root@currentpark] ~# dmesg 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 #4: Tue May 5 00:25:41 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/UMESSAGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1012195328 (965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3e5ffc00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xecb8-0xecbf mem 0xfea00000-0xfeafffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 ehci0: mem 0xfe9fbc00-0xfe9fbfff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:a0:e1:31:eb bge0: [ITHREAD] uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus3: on uhci2 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus4: on uhci3 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0000 usbus5: on uhci4 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfec0-0xfecf,0xecc0-0xeccf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff,0xcd000-0xcffff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] 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 usbus3: 12Mbps Full Speed USB v1.0 uhci_interrupt: host system error usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152587MB at ata0-master SATA300 uhci_interrupt: host system error ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0a is ufsid/49f98454ff52b98f. GEOM_LABEL: Label for provider ad0a is ufs/root. GEOM_LABEL: Label for provider ad0d is ufsid/49f9845b4cbc1341. GEOM_LABEL: Label for provider ad0d is ufs/var. GEOM_LABEL: Label for provider ad0e is ufsid/49f98455b2c7e9e5. GEOM_LABEL: Label for provider ad0e is ufs/tmp. GEOM_LABEL: Label for provider ad0f is ufsid/49f9845405ff03de. GEOM_LABEL: Label for provider ad0f is ufs/home. GEOM_LABEL: Label for provider ad0g is ufsid/49f98456bbb9c493. GEOM_LABEL: Label for provider ad0g is ufs/usr. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered uhci_interrupt: host system error acd0: DVDROM at ata1-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ufs/root uhci_interrupt: host system error GEOM_LABEL: Label ufsid/49f98454ff52b98f removed. GEOM_LABEL: Label ufsid/49f9845405ff03de removed. GEOM_LABEL: Label ufsid/49f98455b2c7e9e5 removed. GEOM_LABEL: Label ufsid/49f984 bb b9c493 removed. GEOM_LABEL: Label ufsid/49f9845b4cbc1341 removed. usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) bge0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! [root@currentpark] ~# cat /boot/loader.conf hw.usb2.uhci.debug=15 after I patched your patch, the mouse still couldn't recognize, there is nothing different than before usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) bge0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! any idea? > On Monday 04 May 2009, Chao Shin wrote: >> usbus0: 12Mbps Full Speed USB v1.0 >> uhci_interrupt: host controller process error > > Hi, > > It appears your USB Host Controller Hardware has crashed. > > Could you boot having the following line in /boot/loader.conf: > > hw.usb2.uhci.debug=15 > > And send new dmesg. > > > > Patch you can try in the meanwhile: > > Edit /sys/dev/usb/controller/usb_controller.c: > > - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); > > + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); > > This will reduce the DMA bits to 30. > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:17: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 1D620106566B for ; Tue, 5 May 2009 07:17:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id A98548FC1C for ; Tue, 5 May 2009 07:17:19 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=EJv1_veVTJqDrCpoJmcA:9 a=17yQsT8QNLrDRbMNEnsV0wx7Dq8A: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 492944039; Tue, 05 May 2009 09:17:17 +0200 From: Hans Petter Selasky To: "Chao Shin" Date: Tue, 5 May 2009 09:19:51 +0200 User-Agent: KMail/1.9.7 References: <200905041556.18646.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905050919.51551.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:17:20 -0000 On Tuesday 05 May 2009, Chao Shin wrote: > Hi Hans, > There is new dmesg with debug=15, but I can't catch difference... > If you type: ll /boot/kernel Do all the modules have the same date? There is a fuse4bsd module there which I suspect is out of date. --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:26: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 9784F106566B for ; Tue, 5 May 2009 07:26:20 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id CD2FF8FC0C for ; Tue, 5 May 2009 07:26:17 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 930325C06F for ; Tue, 5 May 2009 15:25:28 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3321555D16AE; Tue, 5 May 2009 15:25:28 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id Jp+J6LfTYy-C; Tue, 5 May 2009 15:24:30 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id E0CE555D16AD; Tue, 5 May 2009 15:24:24 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:cc:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=hlX7ZULALFs5AxhKwo4A8kVIn7HDm6MIiCJL7Ut+SsM9/Yn4FX8vvs1rwZ/xNBHov 3DJsVzL9BjaukUHUnd03A== Date: Tue, 05 May 2009 15:24:14 +0800 To: "Hans Petter Selasky" From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905041556.18646.hselasky@c2i.net> <200905050919.51551.hselasky@c2i.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200905050919.51551.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: freebsd-current@freebsd.org Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:26:20 -0000 Hi Hans, There is my modules' list as your guess, the fuse.ko is out of date, but is it can cause mouse defunction? I'll try to unload it. [root@currentpark] /usr/local/etc/rc.d# ll /usr/local/modules/fuse.ko -r-xr-xr-x 1 root wheel 83208 May 1 04:19 /usr/local/modules/fuse.ko* [root@currentpark] /usr/local/etc/rc.d# ll /boot/kernel/ total 159208 drwxr-xr-x 2 root wheel 27136 May 5 14:24 ./ drwxr-xr-x 9 root wheel 1024 May 5 14:24 ../ -r-xr-xr-x 1 root wheel 174856 May 5 14:24 aac.ko* -r-xr-xr-x 1 root wheel 134424 May 5 14:24 aac.ko.symbols* -r-xr-xr-x 1 root wheel 8744 May 5 14:24 accf_data.ko* -r-xr-xr-x 1 root wheel 8480 May 5 14:24 accf_data.ko.symbols* -r-xr-xr-x 1 root wheel 9976 May 5 14:24 accf_dns.ko* -r-xr-xr-x 1 root wheel 9552 May 5 14:24 accf_dns.ko.symbols* -r-xr-xr-x 1 root wheel 13712 May 5 14:24 accf_http.ko* -r-xr-xr-x 1 root wheel 11808 May 5 14:24 accf_http.ko.symbols* -r-xr-xr-x 1 root wheel 18520 May 5 14:24 acpi_aiboost.ko* -r-xr-xr-x 1 root wheel 15328 May 5 14:24 acpi_aiboost.ko.symbols* -r-xr-xr-x 1 root wheel 44912 May 5 14:24 acpi_asus.ko* -r-xr-xr-x 1 root wheel 30408 May 5 14:24 acpi_asus.ko.symbols* -r-xr-xr-x 1 root wheel 24144 May 5 14:24 acpi_dock.ko* -r-xr-xr-x 1 root wheel 19784 May 5 14:24 acpi_dock.ko.symbols* -r-xr-xr-x 1 root wheel 24080 May 5 14:24 acpi_fujitsu.ko* -r-xr-xr-x 1 root wheel 19408 May 5 14:24 acpi_fujitsu.ko.symbols* -r-xr-xr-x 1 root wheel 30904 May 5 14:24 acpi_ibm.ko* -r-xr-xr-x 1 root wheel 23456 May 5 14:24 acpi_ibm.ko.symbols* -r-xr-xr-x 1 root wheel 21928 May 5 14:24 acpi_panasonic.ko* -r-xr-xr-x 1 root wheel 18536 May 5 14:24 acpi_panasonic.ko.symbols* -r-xr-xr-x 1 root wheel 13216 May 5 14:24 acpi_sony.ko* -r-xr-xr-x 1 root wheel 11576 May 5 14:24 acpi_sony.ko.symbols* -r-xr-xr-x 1 root wheel 24472 May 5 14:24 acpi_toshiba.ko* -r-xr-xr-x 1 root wheel 20216 May 5 14:24 acpi_toshiba.ko.symbols* -r-xr-xr-x 1 root wheel 32984 May 5 14:24 acpi_video.ko* -r-xr-xr-x 1 root wheel 25152 May 5 14:24 acpi_video.ko.symbols* -r-xr-xr-x 1 root wheel 116544 May 5 14:24 agp.ko* -r-xr-xr-x 1 root wheel 86104 May 5 14:24 agp.ko.symbols* -r-xr-xr-x 1 root wheel 63080 May 5 14:24 aha.ko* -r-xr-xr-x 1 root wheel 46264 May 5 14:24 aha.ko.symbols* -r-xr-xr-x 1 root wheel 288808 May 5 14:24 ahc.ko* -r-xr-xr-x 1 root wheel 174232 May 5 14:24 ahc.ko.symbols* -r-xr-xr-x 1 root wheel 32136 May 5 14:24 ahc_eisa.ko* -r-xr-xr-x 1 root wheel 30328 May 5 14:24 ahc_eisa.ko.symbols* -r-xr-xr-x 1 root wheel 33408 May 5 14:24 ahc_isa.ko* -r-xr-xr-x 1 root wheel 31160 May 5 14:24 ahc_isa.ko.symbols* -r-xr-xr-x 1 root wheel 94216 May 5 14:24 ahc_pci.ko* -r-xr-xr-x 1 root wheel 68952 May 5 14:24 ahc_pci.ko.symbols* -r-xr-xr-x 1 root wheel 427168 May 5 14:24 ahd.ko* -r-xr-xr-x 1 root wheel 240920 May 5 14:24 ahd.ko.symbols* -r-xr-xr-x 1 root wheel 134064 May 5 14:24 aio.ko* -r-xr-xr-x 1 root wheel 104616 May 5 14:24 aio.ko.symbols* -r-xr-xr-x 1 root wheel 12168 May 5 14:24 alias_cuseeme.ko* -r-xr-xr-x 1 root wheel 11360 May 5 14:24 alias_cuseeme.ko.symbols* -r-xr-xr-x 1 root wheel 11152 May 5 14:24 alias_dummy.ko* -r-xr-xr-x 1 root wheel 10704 May 5 14:24 alias_dummy.ko.symbols* -r-xr-xr-x 1 root wheel 17048 May 5 14:24 alias_ftp.ko* -r-xr-xr-x 1 root wheel 13776 May 5 14:24 alias_ftp.ko.symbols* -r-xr-xr-x 1 root wheel 14264 May 5 14:24 alias_irc.ko* -r-xr-xr-x 1 root wheel 12112 May 5 14:24 alias_irc.ko.symbols* -r-xr-xr-x 1 root wheel 16064 May 5 14:24 alias_nbt.ko* -r-xr-xr-x 1 root wheel 13320 May 5 14:24 alias_nbt.ko.symbols* -r-xr-xr-x 1 root wheel 15040 May 5 14:24 alias_pptp.ko* -r-xr-xr-x 1 root wheel 13192 May 5 14:24 alias_pptp.ko.symbols* -r-xr-xr-x 1 root wheel 12792 May 5 14:24 alias_skinny.ko* -r-xr-xr-x 1 root wheel 11800 May 5 14:24 alias_skinny.ko.symbols* -r-xr-xr-x 1 root wheel 16120 May 5 14:24 alias_smedia.ko* -r-xr-xr-x 1 root wheel 13088 May 5 14:24 alias_smedia.ko.symbols* -r-xr-xr-x 1 root wheel 22472 May 5 14:24 alpm.ko* -r-xr-xr-x 1 root wheel 16760 May 5 14:24 alpm.ko.symbols* -r-xr-xr-x 1 root wheel 22400 May 5 14:24 amdpm.ko* -r-xr-xr-x 1 root wheel 16520 May 5 14:24 amdpm.ko.symbols* -r-xr-xr-x 1 root wheel 20960 May 5 14:24 amdsmb.ko* -r-xr-xr-x 1 root wheel 16128 May 5 14:24 amdsmb.ko.symbols* -r-xr-xr-x 1 root wheel 16856 May 5 14:24 amdtemp.ko* -r-xr-xr-x 1 root wheel 14040 May 5 14:24 amdtemp.ko.symbols* -r-xr-xr-x 1 root wheel 104712 May 5 14:24 amr.ko* -r-xr-xr-x 1 root wheel 82120 May 5 14:24 amr.ko.symbols* -r-xr-xr-x 1 root wheel 32744 May 5 14:24 amr_cam.ko* -r-xr-xr-x 1 root wheel 29672 May 5 14:24 amr_cam.ko.symbols* -r-xr-xr-x 1 root wheel 19408 May 5 14:24 amr_linux.ko* -r-xr-xr-x 1 root wheel 19008 May 5 14:24 amr_linux.ko.symbols* -r-xr-xr-x 1 root wheel 70832 May 5 14:24 arcmsr.ko* -r-xr-xr-x 1 root wheel 49904 May 5 14:24 arcmsr.ko.symbols* -r-xr-xr-x 1 root wheel 47952 May 5 14:24 asmc.ko* -r-xr-xr-x 1 root wheel 28192 May 5 14:24 asmc.ko.symbols* -r-xr-xr-x 1 root wheel 121264 May 5 14:24 ata.ko* -r-xr-xr-x 1 root wheel 86400 May 5 14:24 ata.ko.symbols* -r-xr-xr-x 1 root wheel 25296 May 5 14:24 ataacard.ko* -r-xr-xr-x 1 root wheel 21520 May 5 14:24 ataacard.ko.symbols* -r-xr-xr-x 1 root wheel 27712 May 5 14:24 ataacerlabs.ko* -r-xr-xr-x 1 root wheel 22848 May 5 14:24 ataacerlabs.ko.symbols* -r-xr-xr-x 1 root wheel 13544 May 5 14:24 ataadaptec.ko* -r-xr-xr-x 1 root wheel 12552 May 5 14:24 ataadaptec.ko.symbols* -r-xr-xr-x 1 root wheel 33808 May 5 14:24 ataahci.ko* -r-xr-xr-x 1 root wheel 24272 May 5 14:24 ataahci.ko.symbols* -r-xr-xr-x 1 root wheel 21976 May 5 14:24 ataamd.ko* -r-xr-xr-x 1 root wheel 19512 May 5 14:24 ataamd.ko.symbols* -r-xr-xr-x 1 root wheel 29408 May 5 14:24 ataati.ko* -r-xr-xr-x 1 root wheel 24824 May 5 14:24 ataati.ko.symbols* -r-xr-xr-x 1 root wheel 14896 May 5 14:24 atacard.ko* -r-xr-xr-x 1 root wheel 13184 May 5 14:24 atacard.ko.symbols* -r-xr-xr-x 1 root wheel 16024 May 5 14:24 atacenatek.ko* -r-xr-xr-x 1 root wheel 14928 May 5 14:24 atacenatek.ko.symbols* -r-xr-xr-x 1 root wheel 19904 May 5 14:24 atacypress.ko* -r-xr-xr-x 1 root wheel 18400 May 5 14:24 atacypress.ko.symbols* -r-xr-xr-x 1 root wheel 19416 May 5 14:24 atacyrix.ko* -r-xr-xr-x 1 root wheel 17912 May 5 14:24 atacyrix.ko.symbols* -r-xr-xr-x 1 root wheel 29280 May 5 14:24 atadisk.ko* -r-xr-xr-x 1 root wheel 24192 May 5 14:24 atadisk.ko.symbols* -r-xr-xr-x 1 root wheel 26768 May 5 14:24 atahighpoint.ko* -r-xr-xr-x 1 root wheel 22384 May 5 14:24 atahighpoint.ko.symbols* -r-xr-xr-x 1 root wheel 33536 May 5 14:24 ataintel.ko* -r-xr-xr-x 1 root wheel 25024 May 5 14:24 ataintel.ko.symbols* -r-xr-xr-x 1 root wheel 14464 May 5 14:24 ataisa.ko* -r-xr-xr-x 1 root wheel 12776 May 5 14:24 ataisa.ko.symbols* -r-xr-xr-x 1 root wheel 26792 May 5 14:24 ataite.ko* -r-xr-xr-x 1 root wheel 22080 May 5 14:24 ataite.ko.symbols* -r-xr-xr-x 1 root wheel 24248 May 5 14:24 atajmicron.ko* -r-xr-xr-x 1 root wheel 21176 May 5 14:24 atajmicron.ko.symbols* -r-xr-xr-x 1 root wheel 27056 May 5 14:24 atamarvell.ko* -r-xr-xr-x 1 root wheel 20880 May 5 14:24 atamarvell.ko.symbols* -r-xr-xr-x 1 root wheel 16216 May 5 14:24 atamicron.ko* -r-xr-xr-x 1 root wheel 15024 May 5 14:24 atamicron.ko.symbols* -r-xr-xr-x 1 root wheel 20520 May 5 14:24 atanational.ko* -r-xr-xr-x 1 root wheel 18696 May 5 14:24 atanational.ko.symbols* -r-xr-xr-x 1 root wheel 19168 May 5 14:24 atanetcell.ko* -r-xr-xr-x 1 root wheel 17984 May 5 14:24 atanetcell.ko.symbols* -r-xr-xr-x 1 root wheel 26632 May 5 14:24 atanvidia.ko* -r-xr-xr-x 1 root wheel 21536 May 5 14:24 atanvidia.ko.symbols* -r-xr-xr-x 1 root wheel 66968 May 5 14:24 atapci.ko* -r-xr-xr-x 1 root wheel 51200 May 5 14:24 atapci.ko.symbols* -r-xr-xr-x 1 root wheel 42056 May 5 14:24 atapicam.ko* -r-xr-xr-x 1 root wheel 35304 May 5 14:24 atapicam.ko.symbols* -r-xr-xr-x 1 root wheel 68392 May 5 14:24 atapicd.ko* -r-xr-xr-x 1 root wheel 49992 May 5 14:24 atapicd.ko.symbols* -r-xr-xr-x 1 root wheel 27176 May 5 14:24 atapifd.ko* -r-xr-xr-x 1 root wheel 23408 May 5 14:24 atapifd.ko.symbols* -r-xr-xr-x 1 root wheel 36856 May 5 14:24 atapist.ko* -r-xr-xr-x 1 root wheel 29752 May 5 14:24 atapist.ko.symbols* -r-xr-xr-x 1 root wheel 44208 May 5 14:24 atapromise.ko* -r-xr-xr-x 1 root wheel 28456 May 5 14:24 atapromise.ko.symbols* -r-xr-xr-x 1 root wheel 134960 May 5 14:24 ataraid.ko* -r-xr-xr-x 1 root wheel 76784 May 5 14:24 ataraid.ko.symbols* -r-xr-xr-x 1 root wheel 28152 May 5 14:24 ataserverworks.ko* -r-xr-xr-x 1 root wheel 22288 May 5 14:24 ataserverworks.ko.symbols* -r-xr-xr-x 1 root wheel 39752 May 5 14:24 atasiliconimage.ko* -r-xr-xr-x 1 root wheel 28360 May 5 14:24 atasiliconimage.ko.symbols* -r-xr-xr-x 1 root wheel 28960 May 5 14:24 atasis.ko* -r-xr-xr-x 1 root wheel 23344 May 5 14:24 atasis.ko.symbols* -r-xr-xr-x 1 root wheel 30552 May 5 14:24 atavia.ko* -r-xr-xr-x 1 root wheel 24272 May 5 14:24 atavia.ko.symbols* -r-xr-xr-x 1 root wheel 11368 May 5 14:24 blank_saver.ko* -r-xr-xr-x 1 root wheel 10976 May 5 14:24 blank_saver.ko.symbols* -r-xr-xr-x 1 root wheel 50568 May 5 14:24 bridgestp.ko* -r-xr-xr-x 1 root wheel 37248 May 5 14:24 bridgestp.ko.symbols* -r-xr-xr-x 1 root wheel 803448 May 5 14:24 cam.ko* -r-xr-xr-x 1 root wheel 583904 May 5 14:24 cam.ko.symbols* -r-xr-xr-x 1 root wheel 47816 May 5 14:24 cardbus.ko* -r-xr-xr-x 1 root wheel 37528 May 5 14:24 cardbus.ko.symbols* -r-xr-xr-x 1 root wheel 120632 May 5 14:24 cbb.ko* -r-xr-xr-x 1 root wheel 90928 May 5 14:24 cbb.ko.symbols* -r-xr-xr-x 1 root wheel 221688 May 5 14:24 cd9660.ko* -r-xr-xr-x 1 root wheel 198984 May 5 14:24 cd9660.ko.symbols* -r-xr-xr-x 1 root wheel 7632 May 5 14:24 cd9660_iconv.ko* -r-xr-xr-x 1 root wheel 7240 May 5 14:24 cd9660_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 92088 May 5 14:24 ciss.ko* -r-xr-xr-x 1 root wheel 60456 May 5 14:24 ciss.ko.symbols* -r-xr-xr-x 1 root wheel 27048 May 5 14:24 cmx.ko* -r-xr-xr-x 1 root wheel 19896 May 5 14:24 cmx.ko.symbols* -r-xr-xr-x 1 root wheel 233768 May 5 14:24 coda.ko* -r-xr-xr-x 1 root wheel 199448 May 5 14:24 coda.ko.symbols* -r-xr-xr-x 1 root wheel 240040 May 5 14:24 coda5.ko* -r-xr-xr-x 1 root wheel 203328 May 5 14:24 coda5.ko.symbols* -r-xr-xr-x 1 root wheel 22488 May 5 14:24 coretemp.ko* -r-xr-xr-x 1 root wheel 20880 May 5 14:24 coretemp.ko.symbols* -r-xr-xr-x 1 root wheel 26136 May 5 14:24 cpuctl.ko* -r-xr-xr-x 1 root wheel 23248 May 5 14:24 cpuctl.ko.symbols* -r-xr-xr-x 1 root wheel 100872 May 5 14:24 cpufreq.ko* -r-xr-xr-x 1 root wheel 73360 May 5 14:24 cpufreq.ko.symbols* -r-xr-xr-x 1 root wheel 220744 May 5 14:24 crypto.ko* -r-xr-xr-x 1 root wheel 113552 May 5 14:24 crypto.ko.symbols* -r-xr-xr-x 1 root wheel 27744 May 5 14:24 cryptodev.ko* -r-xr-xr-x 1 root wheel 22128 May 5 14:24 cryptodev.ko.symbols* -r-xr-xr-x 1 root wheel 54584 May 5 14:24 cxgb_t3fw.ko* -r-xr-xr-x 1 root wheel 13248 May 5 14:24 cxgb_t3fw.ko.symbols* -r-xr-xr-x 1 root wheel 37520 May 5 14:24 cyclic.ko* -r-xr-xr-x 1 root wheel 30512 May 5 14:24 cyclic.ko.symbols* -r-xr-xr-x 1 root wheel 24728 May 5 14:24 daemon_saver.ko* -r-xr-xr-x 1 root wheel 20696 May 5 14:24 daemon_saver.ko.symbols* -r-xr-xr-x 1 root wheel 35000 May 5 14:24 dcons.ko* -r-xr-xr-x 1 root wheel 31440 May 5 14:24 dcons.ko.symbols* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 dcons_crom.ko* -r-xr-xr-x 1 root wheel 23904 May 5 14:24 dcons_crom.ko.symbols* -r-xr-xr-x 1 root wheel 15672 May 5 14:24 dragon_saver.ko* -r-xr-xr-x 1 root wheel 13960 May 5 14:24 dragon_saver.ko.symbols* -r-xr-xr-x 1 root wheel 513384 May 5 14:24 drm.ko* -r-xr-xr-x 1 root wheel 454000 May 5 14:24 drm.ko.symbols* -r-xr-xr-x 1 root wheel 41552 May 5 14:24 dtmalloc.ko* -r-xr-xr-x 1 root wheel 40144 May 5 14:24 dtmalloc.ko.symbols* -r-xr-xr-x 1 root wheel 49808 May 5 14:24 dtnfsclient.ko* -r-xr-xr-x 1 root wheel 46176 May 5 14:24 dtnfsclient.ko.symbols* -r-xr-xr-x 1 root wheel 306704 May 5 14:24 dtrace.ko* -r-xr-xr-x 1 root wheel 689808 May 5 14:24 dtrace.ko.symbols* -r-xr-xr-x 1 root wheel 21896 May 5 14:24 dtrace_test.ko* -r-xr-xr-x 1 root wheel 21592 May 5 14:24 dtrace_test.ko.symbols* -r-xr-xr-x 1 root wheel 9840 May 5 14:24 dtraceall.ko* -r-xr-xr-x 1 root wheel 9104 May 5 14:24 dtraceall.ko.symbols* -r-xr-xr-x 1 root wheel 72824 May 5 14:24 dummynet.ko* -r-xr-xr-x 1 root wheel 53024 May 5 14:24 dummynet.ko.symbols* -r-xr-xr-x 1 root wheel 102232 May 5 14:24 ehci.ko* -r-xr-xr-x 1 root wheel 65816 May 5 14:24 ehci.ko.symbols* -r-xr-xr-x 1 root wheel 19192 May 5 14:24 exca.ko* -r-xr-xr-x 1 root wheel 13480 May 5 14:24 exca.ko.symbols* -r-xr-xr-x 1 root wheel 393200 May 5 14:24 ext2fs.ko* -r-xr-xr-x 1 root wheel 347320 May 5 14:24 ext2fs.ko.symbols* -r-xr-xr-x 1 root wheel 12192 May 5 14:24 fade_saver.ko* -r-xr-xr-x 1 root wheel 11464 May 5 14:24 fade_saver.ko.symbols* -r-xr-xr-x 1 root wheel 57672 May 5 14:24 fbt.ko* -r-xr-xr-x 1 root wheel 50600 May 5 14:24 fbt.ko.symbols* -r-xr-xr-x 1 root wheel 107536 May 5 14:24 fdc.ko* -r-xr-xr-x 1 root wheel 85864 May 5 14:24 fdc.ko.symbols* -r-xr-xr-x 1 root wheel 74440 May 5 14:24 fdescfs.ko* -r-xr-xr-x 1 root wheel 68752 May 5 14:24 fdescfs.ko.symbols* -r-xr-xr-x 1 root wheel 15056 May 5 14:24 fire_saver.ko* -r-xr-xr-x 1 root wheel 13440 May 5 14:24 fire_saver.ko.symbols* -r-xr-xr-x 1 root wheel 214520 May 5 14:24 firewire.ko* -r-xr-xr-x 1 root wheel 145664 May 5 14:24 firewire.ko.symbols* -r-xr-xr-x 1 root wheel 40608 May 5 14:24 firmware.ko* -r-xr-xr-x 1 root wheel 37096 May 5 14:24 firmware.ko.symbols* -r-xr-xr-x 1 root wheel 99608 May 5 14:24 geom_bde.ko* -r-xr-xr-x 1 root wheel 64312 May 5 14:24 geom_bde.ko.symbols* -r-xr-xr-x 1 root wheel 28024 May 5 14:24 geom_bsd.ko* -r-xr-xr-x 1 root wheel 20072 May 5 14:24 geom_bsd.ko.symbols* -r-xr-xr-x 1 root wheel 43088 May 5 14:24 geom_cache.ko* -r-xr-xr-x 1 root wheel 30720 May 5 14:24 geom_cache.ko.symbols* -r-xr-xr-x 1 root wheel 20216 May 5 14:24 geom_ccd.ko* -r-xr-xr-x 1 root wheel 14680 May 5 14:24 geom_ccd.ko.symbols* -r-xr-xr-x 1 root wheel 37080 May 5 14:24 geom_concat.ko* -r-xr-xr-x 1 root wheel 26952 May 5 14:24 geom_concat.ko.symbols* -r-xr-xr-x 1 root wheel 209448 May 5 14:24 geom_eli.ko* -r-xr-xr-x 1 root wheel 168864 May 5 14:24 geom_eli.ko.symbols* -r-xr-xr-x 1 root wheel 20328 May 5 14:24 geom_fox.ko* -r-xr-xr-x 1 root wheel 16328 May 5 14:24 geom_fox.ko.symbols* -r-xr-xr-x 1 root wheel 44976 May 5 14:24 geom_gate.ko* -r-xr-xr-x 1 root wheel 37064 May 5 14:24 geom_gate.ko.symbols* -r-xr-xr-x 1 root wheel 188544 May 5 14:24 geom_journal.ko* -r-xr-xr-x 1 root wheel 144672 May 5 14:24 geom_journal.ko.symbols* -r-xr-xr-x 1 root wheel 65328 May 5 14:24 geom_label.ko* -r-xr-xr-x 1 root wheel 54864 May 5 14:24 geom_label.ko.symbols* -r-xr-xr-x 1 root wheel 49104 May 5 14:24 geom_linux_lvm.ko* -r-xr-xr-x 1 root wheel 32896 May 5 14:24 geom_linux_lvm.ko.symbols* -r-xr-xr-x 1 root wheel 22080 May 5 14:24 geom_mbr.ko* -r-xr-xr-x 1 root wheel 17232 May 5 14:24 geom_mbr.ko.symbols* -r-xr-xr-x 1 root wheel 65320 May 5 14:24 geom_md.ko* -r-xr-xr-x 1 root wheel 54432 May 5 14:24 geom_md.ko.symbols* -r-xr-xr-x 1 root wheel 165944 May 5 14:24 geom_mirror.ko* -r-xr-xr-x 1 root wheel 114168 May 5 14:24 geom_mirror.ko.symbols* -r-xr-xr-x 1 root wheel 27336 May 5 14:24 geom_multipath.ko* -r-xr-xr-x 1 root wheel 20608 May 5 14:24 geom_multipath.ko.symbols* -r-xr-xr-x 1 root wheel 26672 May 5 14:24 geom_nop.ko* -r-xr-xr-x 1 root wheel 20104 May 5 14:24 geom_nop.ko.symbols* -r-xr-xr-x 1 root wheel 20712 May 5 14:24 geom_part_apm.ko* -r-xr-xr-x 1 root wheel 16440 May 5 14:24 geom_part_apm.ko.symbols* -r-xr-xr-x 1 root wheel 19160 May 5 14:24 geom_part_bsd.ko* -r-xr-xr-x 1 root wheel 15264 May 5 14:24 geom_part_bsd.ko.symbols* -r-xr-xr-x 1 root wheel 20392 May 5 14:24 geom_part_ebr.ko* -r-xr-xr-x 1 root wheel 16152 May 5 14:24 geom_part_ebr.ko.symbols* -r-xr-xr-x 1 root wheel 29592 May 5 14:24 geom_part_gpt.ko* -r-xr-xr-x 1 root wheel 20240 May 5 14:24 geom_part_gpt.ko.symbols* -r-xr-xr-x 1 root wheel 18848 May 5 14:24 geom_part_mbr.ko* -r-xr-xr-x 1 root wheel 15456 May 5 14:24 geom_part_mbr.ko.symbols* -r-xr-xr-x 1 root wheel 19008 May 5 14:24 geom_part_pc98.ko* -r-xr-xr-x 1 root wheel 15488 May 5 14:24 geom_part_pc98.ko.symbols* -r-xr-xr-x 1 root wheel 19368 May 5 14:24 geom_part_vtoc8.ko* -r-xr-xr-x 1 root wheel 15560 May 5 14:24 geom_part_vtoc8.ko.symbols* -r-xr-xr-x 1 root wheel 19232 May 5 14:24 geom_pc98.ko* -r-xr-xr-x 1 root wheel 15400 May 5 14:24 geom_pc98.ko.symbols* -r-xr-xr-x 1 root wheel 173392 May 5 14:24 geom_raid3.ko* -r-xr-xr-x 1 root wheel 118440 May 5 14:24 geom_raid3.ko.symbols* -r-xr-xr-x 1 root wheel 36128 May 5 14:24 geom_shsec.ko* -r-xr-xr-x 1 root wheel 26664 May 5 14:24 geom_shsec.ko.symbols* -r-xr-xr-x 1 root wheel 43848 May 5 14:24 geom_stripe.ko* -r-xr-xr-x 1 root wheel 30560 May 5 14:24 geom_stripe.ko.symbols* -r-xr-xr-x 1 root wheel 20808 May 5 14:24 geom_sunlabel.ko* -r-xr-xr-x 1 root wheel 17176 May 5 14:24 geom_sunlabel.ko.symbols* -r-xr-xr-x 1 root wheel 19936 May 5 14:24 geom_uzip.ko* -r-xr-xr-x 1 root wheel 16088 May 5 14:24 geom_uzip.ko.symbols* -r-xr-xr-x 1 root wheel 271344 May 5 14:24 geom_vinum.ko* -r-xr-xr-x 1 root wheel 196168 May 5 14:24 geom_vinum.ko.symbols* -r-xr-xr-x 1 root wheel 78408 May 5 14:24 geom_virstor.ko* -r-xr-xr-x 1 root wheel 55624 May 5 14:24 geom_virstor.ko.symbols* -r-xr-xr-x 1 root wheel 14320 May 5 14:24 geom_vol_ffs.ko* -r-xr-xr-x 1 root wheel 13304 May 5 14:24 geom_vol_ffs.ko.symbols* -r-xr-xr-x 1 root wheel 13088 May 5 14:24 geom_zero.ko* -r-xr-xr-x 1 root wheel 12056 May 5 14:24 geom_zero.ko.symbols* -r-xr-xr-x 1 root wheel 11368 May 5 14:24 green_saver.ko* -r-xr-xr-x 1 root wheel 10976 May 5 14:24 green_saver.ko.symbols* -r-xr-xr-x 1 root wheel 68168 May 5 14:24 hifn.ko* -r-xr-xr-x 1 root wheel 45160 May 5 14:24 hifn.ko.symbols* -r-xr-xr-x 1 root wheel 61664 May 5 14:24 hptiop.ko* -r-xr-xr-x 1 root wheel 43560 May 5 14:24 hptiop.ko.symbols* -r-xr-xr-x 1 root wheel 313456 May 5 14:24 hptmv.ko* -r-xr-xr-x 1 root wheel 194432 May 5 14:24 hptmv.ko.symbols* -r-xr-xr-x 1 root wheel 697512 May 5 14:24 hptrr.ko* -r-xr-xr-x 1 root wheel 267160 May 5 14:24 hptrr.ko.symbols* -r-xr-xr-x 1 root wheel 515608 May 5 14:24 hwpmc.ko* -r-xr-xr-x 1 root wheel 466096 May 5 14:24 hwpmc.ko.symbols* -r-xr-xr-x 1 root wheel 184688 May 5 14:24 i915.ko* -r-xr-xr-x 1 root wheel 158144 May 5 14:24 i915.ko.symbols* -r-xr-xr-x 1 root wheel 31552 May 5 14:24 ichsmb.ko* -r-xr-xr-x 1 root wheel 23728 May 5 14:24 ichsmb.ko.symbols* -r-xr-xr-x 1 root wheel 19920 May 5 14:24 ichwd.ko* -r-xr-xr-x 1 root wheel 14104 May 5 14:24 ichwd.ko.symbols* -r-xr-xr-x 1 root wheel 54544 May 5 14:24 ida.ko* -r-xr-xr-x 1 root wheel 45784 May 5 14:24 ida.ko.symbols* -r-xr-xr-x 1 root wheel 57016 May 5 14:24 if_ae.ko* -r-xr-xr-x 1 root wheel 37880 May 5 14:24 if_ae.ko.symbols* -r-xr-xr-x 1 root wheel 77392 May 5 14:24 if_age.ko* -r-xr-xr-x 1 root wheel 47168 May 5 14:24 if_age.ko.symbols* -r-xr-xr-x 1 root wheel 79928 May 5 14:24 if_ale.ko* -r-xr-xr-x 1 root wheel 49376 May 5 14:24 if_ale.ko.symbols* -r-xr-xr-x 1 root wheel 187184 May 5 14:24 if_an.ko* -r-xr-xr-x 1 root wheel 149752 May 5 14:24 if_an.ko.symbols* -r-xr-xr-x 1 root wheel 1671072 May 5 14:24 if_ath.ko* -r-xr-xr-x 1 root wheel 1343776 May 5 14:24 if_ath.ko.symbols* -r-xr-xr-x 1 root wheel 41448 May 5 14:24 if_aue.ko* -r-xr-xr-x 1 root wheel 32944 May 5 14:24 if_aue.ko.symbols* -r-xr-xr-x 1 root wheel 41240 May 5 14:24 if_axe.ko* -r-xr-xr-x 1 root wheel 33368 May 5 14:24 if_axe.ko.symbols* -r-xr-xr-x 1 root wheel 333408 May 5 14:24 if_bce.ko* -r-xr-xr-x 1 root wheel 78872 May 5 14:24 if_bce.ko.symbols* -r-xr-xr-x 1 root wheel 56072 May 5 14:24 if_bfe.ko* -r-xr-xr-x 1 root wheel 36816 May 5 14:24 if_bfe.ko.symbols* -r-xr-xr-x 1 root wheel 104248 May 5 14:24 if_bge.ko* -r-xr-xr-x 1 root wheel 58800 May 5 14:24 if_bge.ko.symbols* -r-xr-xr-x 1 root wheel 103672 May 5 14:24 if_bridge.ko* -r-xr-xr-x 1 root wheel 82344 May 5 14:24 if_bridge.ko.symbols* -r-xr-xr-x 1 root wheel 38496 May 5 14:24 if_cdce.ko* -r-xr-xr-x 1 root wheel 33080 May 5 14:24 if_cdce.ko.symbols* -r-xr-xr-x 1 root wheel 32600 May 5 14:24 if_cue.ko* -r-xr-xr-x 1 root wheel 28168 May 5 14:24 if_cue.ko.symbols* -r-xr-xr-x 1 root wheel 576568 May 5 14:24 if_cxgb.ko* -r-xr-xr-x 1 root wheel 431104 May 5 14:24 if_cxgb.ko.symbols* -r-xr-xr-x 1 root wheel 108624 May 5 14:24 if_dc.ko* -r-xr-xr-x 1 root wheel 72552 May 5 14:24 if_dc.ko.symbols* -r-xr-xr-x 1 root wheel 90864 May 5 14:24 if_de.ko* -r-xr-xr-x 1 root wheel 48816 May 5 14:24 if_de.ko.symbols* -r-xr-xr-x 1 root wheel 18784 May 5 14:24 if_disc.ko* -r-xr-xr-x 1 root wheel 17672 May 5 14:24 if_disc.ko.symbols* -r-xr-xr-x 1 root wheel 167592 May 5 14:24 if_ed.ko* -r-xr-xr-x 1 root wheel 126592 May 5 14:24 if_ed.ko.symbols* -r-xr-xr-x 1 root wheel 18456 May 5 14:24 if_edsc.ko* -r-xr-xr-x 1 root wheel 17248 May 5 14:24 if_edsc.ko.symbols* -r-xr-xr-x 1 root wheel 22016 May 5 14:24 if_ef.ko* -r-xr-xr-x 1 root wheel 19576 May 5 14:24 if_ef.ko.symbols* -r-xr-xr-x 1 root wheel 430576 May 5 14:24 if_em.ko* -r-xr-xr-x 1 root wheel 262416 May 5 14:24 if_em.ko.symbols* -r-xr-xr-x 1 root wheel 90968 May 5 14:24 if_en.ko* -r-xr-xr-x 1 root wheel 58024 May 5 14:24 if_en.ko.symbols* -r-xr-xr-x 1 root wheel 66120 May 5 14:24 if_et.ko* -r-xr-xr-x 1 root wheel 47112 May 5 14:24 if_et.ko.symbols* -r-xr-xr-x 1 root wheel 31048 May 5 14:24 if_faith.ko* -r-xr-xr-x 1 root wheel 29120 May 5 14:24 if_faith.ko.symbols* -r-xr-xr-x 1 root wheel 104648 May 5 14:24 if_fatm.ko* -r-xr-xr-x 1 root wheel 41800 May 5 14:24 if_fatm.ko.symbols* -r-xr-xr-x 1 root wheel 35712 May 5 14:24 if_fwe.ko* -r-xr-xr-x 1 root wheel 30168 May 5 14:24 if_fwe.ko.symbols* -r-xr-xr-x 1 root wheel 63072 May 5 14:24 if_fwip.ko* -r-xr-xr-x 1 root wheel 51424 May 5 14:24 if_fwip.ko.symbols* -r-xr-xr-x 1 root wheel 70432 May 5 14:24 if_fxp.ko* -r-xr-xr-x 1 root wheel 43320 May 5 14:24 if_fxp.ko.symbols* -r-xr-xr-x 1 root wheel 71968 May 5 14:24 if_gem.ko* -r-xr-xr-x 1 root wheel 49160 May 5 14:24 if_gem.ko.symbols* -r-xr-xr-x 1 root wheel 102016 May 5 14:24 if_gif.ko* -r-xr-xr-x 1 root wheel 91768 May 5 14:24 if_gif.ko.symbols* -r-xr-xr-x 1 root wheel 65792 May 5 14:24 if_gre.ko* -r-xr-xr-x 1 root wheel 59312 May 5 14:24 if_gre.ko.symbols* -r-xr-xr-x 1 root wheel 158472 May 5 14:24 if_hatm.ko* -r-xr-xr-x 1 root wheel 112528 May 5 14:24 if_hatm.ko.symbols* -r-xr-xr-x 1 root wheel 64880 May 5 14:24 if_hme.ko* -r-xr-xr-x 1 root wheel 48280 May 5 14:24 if_hme.ko.symbols* -r-xr-xr-x 1 root wheel 23432 May 5 14:24 if_ic.ko* -r-xr-xr-x 1 root wheel 20616 May 5 14:24 if_ic.ko.symbols* -r-xr-xr-x 1 root wheel 430408 May 5 14:24 if_igb.ko* -r-xr-xr-x 1 root wheel 263664 May 5 14:24 if_igb.ko.symbols* -r-xr-xr-x 1 root wheel 93408 May 5 14:24 if_ipw.ko* -r-xr-xr-x 1 root wheel 64784 May 5 14:24 if_ipw.ko.symbols* -r-xr-xr-x 1 root wheel 144368 May 5 14:24 if_iwn.ko* -r-xr-xr-x 1 root wheel 95680 May 5 14:24 if_iwn.ko.symbols* -r-xr-xr-x 1 root wheel 81792 May 5 14:24 if_ixgb.ko* -r-xr-xr-x 1 root wheel 54712 May 5 14:24 if_ixgb.ko.symbols* -r-xr-xr-x 1 root wheel 81968 May 5 14:24 if_jme.ko* -r-xr-xr-x 1 root wheel 53592 May 5 14:24 if_jme.ko.symbols* -r-xr-xr-x 1 root wheel 39576 May 5 14:24 if_kue.ko* -r-xr-xr-x 1 root wheel 29664 May 5 14:24 if_kue.ko.symbols* -r-xr-xr-x 1 root wheel 80512 May 5 14:24 if_lagg.ko* -r-xr-xr-x 1 root wheel 61904 May 5 14:24 if_lagg.ko.symbols* -r-xr-xr-x 1 root wheel 77960 May 5 14:24 if_le.ko* -r-xr-xr-x 1 root wheel 63088 May 5 14:24 if_le.ko.symbols* -r-xr-xr-x 1 root wheel 41024 May 5 14:24 if_lge.ko* -r-xr-xr-x 1 root wheel 29928 May 5 14:24 if_lge.ko.symbols* -r-xr-xr-x 1 root wheel 91480 May 5 14:24 if_lmc.ko* -r-xr-xr-x 1 root wheel 48872 May 5 14:24 if_lmc.ko.symbols* -r-xr-xr-x 1 root wheel 169992 May 5 14:24 if_malo.ko* -r-xr-xr-x 1 root wheel 141600 May 5 14:24 if_malo.ko.symbols* -r-xr-xr-x 1 root wheel 107664 May 5 14:24 if_msk.ko* -r-xr-xr-x 1 root wheel 56400 May 5 14:24 if_msk.ko.symbols* -r-xr-xr-x 1 root wheel 119920 May 5 14:24 if_mxge.ko* -r-xr-xr-x 1 root wheel 78112 May 5 14:24 if_mxge.ko.symbols* -r-xr-xr-x 1 root wheel 44544 May 5 14:24 if_my.ko* -r-xr-xr-x 1 root wheel 29752 May 5 14:24 if_my.ko.symbols* -r-xr-xr-x 1 root wheel 282792 May 5 14:24 if_ndis.ko* -r-xr-xr-x 1 root wheel 250648 May 5 14:24 if_ndis.ko.symbols* -r-xr-xr-x 1 root wheel 77840 May 5 14:24 if_nfe.ko* -r-xr-xr-x 1 root wheel 45816 May 5 14:24 if_nfe.ko.symbols* -r-xr-xr-x 1 root wheel 45128 May 5 14:24 if_nge.ko* -r-xr-xr-x 1 root wheel 29904 May 5 14:24 if_nge.ko.symbols* -r-xr-xr-x 1 root wheel 102088 May 5 14:24 if_nve.ko* -r-xr-xr-x 1 root wheel 56512 May 5 14:24 if_nve.ko.symbols* -r-xr-xr-x 1 root wheel 574792 May 5 14:24 if_nxge.ko* -r-xr-xr-x 1 root wheel 431496 May 5 14:24 if_nxge.ko.symbols* -r-xr-xr-x 1 root wheel 190544 May 5 14:24 if_patm.ko* -r-xr-xr-x 1 root wheel 119912 May 5 14:24 if_patm.ko.symbols* -r-xr-xr-x 1 root wheel 39568 May 5 14:24 if_pcn.ko* -r-xr-xr-x 1 root wheel 29936 May 5 14:24 if_pcn.ko.symbols* -r-xr-xr-x 1 root wheel 202192 May 5 14:24 if_ral.ko* -r-xr-xr-x 1 root wheel 147016 May 5 14:24 if_ral.ko.symbols* -r-xr-xr-x 1 root wheel 61304 May 5 14:24 if_re.ko* -r-xr-xr-x 1 root wheel 39096 May 5 14:24 if_re.ko.symbols* -r-xr-xr-x 1 root wheel 51888 May 5 14:24 if_rl.ko* -r-xr-xr-x 1 root wheel 36336 May 5 14:24 if_rl.ko.symbols* -r-xr-xr-x 1 root wheel 39168 May 5 14:24 if_rue.ko* -r-xr-xr-x 1 root wheel 32856 May 5 14:24 if_rue.ko.symbols* -r-xr-xr-x 1 root wheel 85040 May 5 14:24 if_rum.ko* -r-xr-xr-x 1 root wheel 62120 May 5 14:24 if_rum.ko.symbols* -r-xr-xr-x 1 root wheel 62480 May 5 14:24 if_sf.ko* -r-xr-xr-x 1 root wheel 39640 May 5 14:24 if_sf.ko.symbols* -r-xr-xr-x 1 root wheel 52496 May 5 14:24 if_sis.ko* -r-xr-xr-x 1 root wheel 33240 May 5 14:24 if_sis.ko.symbols* -r-xr-xr-x 1 root wheel 74456 May 5 14:24 if_sk.ko* -r-xr-xr-x 1 root wheel 44016 May 5 14:24 if_sk.ko.symbols* -r-xr-xr-x 1 root wheel 63896 May 5 14:24 if_sn.ko* -r-xr-xr-x 1 root wheel 50152 May 5 14:24 if_sn.ko.symbols* -r-xr-xr-x 1 root wheel 46032 May 5 14:24 if_ste.ko* -r-xr-xr-x 1 root wheel 32208 May 5 14:24 if_ste.ko.symbols* -r-xr-xr-x 1 root wheel 54136 May 5 14:24 if_stf.ko* -r-xr-xr-x 1 root wheel 49664 May 5 14:24 if_stf.ko.symbols* -r-xr-xr-x 1 root wheel 57704 May 5 14:24 if_stge.ko* -r-xr-xr-x 1 root wheel 36824 May 5 14:24 if_stge.ko.symbols* -r-xr-xr-x 1 root wheel 52232 May 5 14:24 if_tap.ko* -r-xr-xr-x 1 root wheel 43104 May 5 14:24 if_tap.ko.symbols* -r-xr-xr-x 1 root wheel 230056 May 5 14:24 if_ti.ko* -r-xr-xr-x 1 root wheel 45496 May 5 14:24 if_ti.ko.symbols* -r-xr-xr-x 1 root wheel 46920 May 5 14:24 if_tl.ko* -r-xr-xr-x 1 root wheel 32168 May 5 14:24 if_tl.ko.symbols* -r-xr-xr-x 1 root wheel 52912 May 5 14:24 if_tun.ko* -r-xr-xr-x 1 root wheel 43208 May 5 14:24 if_tun.ko.symbols* -r-xr-xr-x 1 root wheel 46296 May 5 14:24 if_tx.ko* -r-xr-xr-x 1 root wheel 32400 May 5 14:24 if_tx.ko.symbols* -r-xr-xr-x 1 root wheel 121320 May 5 14:24 if_txp.ko* -r-xr-xr-x 1 root wheel 43200 May 5 14:24 if_txp.ko.symbols* -r-xr-xr-x 1 root wheel 83336 May 5 14:24 if_uath.ko* -r-xr-xr-x 1 root wheel 62912 May 5 14:24 if_uath.ko.symbols* -r-xr-xr-x 1 root wheel 38432 May 5 14:24 if_udav.ko* -r-xr-xr-x 1 root wheel 32344 May 5 14:24 if_udav.ko.symbols* -r-xr-xr-x 1 root wheel 83600 May 5 14:24 if_ural.ko* -r-xr-xr-x 1 root wheel 63656 May 5 14:24 if_ural.ko.symbols* -r-xr-xr-x 1 root wheel 47424 May 5 14:24 if_vge.ko* -r-xr-xr-x 1 root wheel 31688 May 5 14:24 if_vge.ko.symbols* -r-xr-xr-x 1 root wheel 39720 May 5 14:24 if_vlan.ko* -r-xr-xr-x 1 root wheel 31032 May 5 14:24 if_vlan.ko.symbols* -r-xr-xr-x 1 root wheel 61664 May 5 14:24 if_vr.ko* -r-xr-xr-x 1 root wheel 38648 May 5 14:24 if_vr.ko.symbols* -r-xr-xr-x 1 root wheel 45152 May 5 14:24 if_vx.ko* -r-xr-xr-x 1 root wheel 34504 May 5 14:24 if_vx.ko.symbols* -r-xr-xr-x 1 root wheel 43976 May 5 14:24 if_wb.ko* -r-xr-xr-x 1 root wheel 30704 May 5 14:24 if_wb.ko.symbols* -r-xr-xr-x 1 root wheel 167272 May 5 14:24 if_wi.ko* -r-xr-xr-x 1 root wheel 137888 May 5 14:24 if_wi.ko.symbols* -r-xr-xr-x 1 root wheel 112944 May 5 14:24 if_wpi.ko* -r-xr-xr-x 1 root wheel 77504 May 5 14:24 if_wpi.ko.symbols* -r-xr-xr-x 1 root wheel 66688 May 5 14:24 if_xl.ko* -r-xr-xr-x 1 root wheel 38736 May 5 14:24 if_xl.ko.symbols* -r-xr-xr-x 1 root wheel 110504 May 5 14:24 if_zyd.ko* -r-xr-xr-x 1 root wheel 68872 May 5 14:24 if_zyd.ko.symbols* -r-xr-xr-x 1 root wheel 20040 May 5 14:24 iic.ko* -r-xr-xr-x 1 root wheel 16664 May 5 14:24 iic.ko.symbols* -r-xr-xr-x 1 root wheel 19640 May 5 14:24 iicbb.ko* -r-xr-xr-x 1 root wheel 15296 May 5 14:24 iicbb.ko.symbols* -r-xr-xr-x 1 root wheel 24280 May 5 14:24 iicbus.ko* -r-xr-xr-x 1 root wheel 20040 May 5 14:24 iicbus.ko.symbols* -r-xr-xr-x 1 root wheel 19744 May 5 14:24 iicsmb.ko* -r-xr-xr-x 1 root wheel 15792 May 5 14:24 iicsmb.ko.symbols* -r-xr-xr-x 1 root wheel 75336 May 5 14:24 iir.ko* -r-xr-xr-x 1 root wheel 57280 May 5 14:24 iir.ko.symbols* -r-xr-xr-x 1 root wheel 24176 May 5 14:24 intpm.ko* -r-xr-xr-x 1 root wheel 17400 May 5 14:24 intpm.ko.symbols* -r-xr-xr-x 1 root wheel 33544 May 5 14:24 io.ko* -r-xr-xr-x 1 root wheel 33000 May 5 14:24 io.ko.symbols* -r-xr-xr-x 1 root wheel 80984 May 5 14:24 ip_mroute.ko* -r-xr-xr-x 1 root wheel 63400 May 5 14:24 ip_mroute.ko.symbols* -r-xr-xr-x 1 root wheel 56280 May 5 14:24 ipdivert.ko* -r-xr-xr-x 1 root wheel 51240 May 5 14:24 ipdivert.ko.symbols* -r-xr-xr-x 1 root wheel 166040 May 5 14:24 ipfw.ko* -r-xr-xr-x 1 root wheel 127144 May 5 14:24 ipfw.ko.symbols* -r-xr-xr-x 1 root wheel 42504 May 5 14:24 ipfw_nat.ko* -r-xr-xr-x 1 root wheel 37800 May 5 14:24 ipfw_nat.ko.symbols* -r-xr-xr-x 1 root wheel 616112 May 5 14:24 ipl.ko* -r-xr-xr-x 1 root wheel 452752 May 5 14:24 ipl.ko.symbols* -r-xr-xr-x 1 root wheel 123160 May 5 14:24 ipmi.ko* -r-xr-xr-x 1 root wheel 96752 May 5 14:24 ipmi.ko.symbols* -r-xr-xr-x 1 root wheel 19472 May 5 14:24 ipmi_linux.ko* -r-xr-xr-x 1 root wheel 19040 May 5 14:24 ipmi_linux.ko.symbols* -r-xr-xr-x 1 root wheel 96640 May 5 14:24 ips.ko* -r-xr-xr-x 1 root wheel 76808 May 5 14:24 ips.ko.symbols* -r-xr-xr-x 1 root wheel 216696 May 5 14:24 ipw_bss.ko* -r-xr-xr-x 1 root wheel 6912 May 5 14:24 ipw_bss.ko.symbols* -r-xr-xr-x 1 root wheel 208688 May 5 14:24 ipw_ibss.ko* -r-xr-xr-x 1 root wheel 6928 May 5 14:24 ipw_ibss.ko.symbols* -r-xr-xr-x 1 root wheel 204048 May 5 14:24 ipw_monitor.ko* -r-xr-xr-x 1 root wheel 6984 May 5 14:24 ipw_monitor.ko.symbols* -r-xr-xr-x 1 root wheel 258648 May 5 14:24 iscsi_initiator.ko* -r-xr-xr-x 1 root wheel 217968 May 5 14:24 iscsi_initiator.ko.symbols* -r-xr-xr-x 1 root wheel 339928 May 5 14:24 isp.ko* -r-xr-xr-x 1 root wheel 216848 May 5 14:24 isp.ko.symbols* -r-xr-xr-x 1 root wheel 29864 May 5 14:24 isp_1040.ko* -r-xr-xr-x 1 root wheel 6408 May 5 14:24 isp_1040.ko.symbols* -r-xr-xr-x 1 root wheel 39896 May 5 14:24 isp_1040_it.ko* -r-xr-xr-x 1 root wheel 6440 May 5 14:24 isp_1040_it.ko.symbols* -r-xr-xr-x 1 root wheel 38264 May 5 14:24 isp_1080.ko* -r-xr-xr-x 1 root wheel 6408 May 5 14:24 isp_1080.ko.symbols* -r-xr-xr-x 1 root wheel 47592 May 5 14:24 isp_1080_it.ko* -r-xr-xr-x 1 root wheel 6440 May 5 14:24 isp_1080_it.ko.symbols* -r-xr-xr-x 1 root wheel 34984 May 5 14:24 isp_12160.ko* -r-xr-xr-x 1 root wheel 6424 May 5 14:24 isp_12160.ko.symbols* -r-xr-xr-x 1 root wheel 47584 May 5 14:24 isp_12160_it.ko* -r-xr-xr-x 1 root wheel 6448 May 5 14:24 isp_12160_it.ko.symbols* -r-xr-xr-x 1 root wheel 83696 May 5 14:24 isp_2100.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2100.ko.symbols* -r-xr-xr-x 1 root wheel 84144 May 5 14:24 isp_2200.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2200.ko.symbols* -r-xr-xr-x 1 root wheel 112000 May 5 14:24 isp_2300.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2300.ko.symbols* -r-xr-xr-x 1 root wheel 128704 May 5 14:24 isp_2322.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2322.ko.symbols* -r-xr-xr-x 1 root wheel 201904 May 5 14:24 isp_2400.ko* -r-xr-xr-x 1 root wheel 6352 May 5 14:24 isp_2400.ko.symbols* -r-xr-xr-x 1 root wheel 789128 May 5 14:24 ispfw.ko* -r-xr-xr-x 1 root wheel 13672 May 5 14:24 ispfw.ko.symbols* -r-xr-xr-x 1 root wheel 557360 May 5 14:24 iw_cxgb.ko* -r-xr-xr-x 1 root wheel 505384 May 5 14:24 iw_cxgb.ko.symbols* -r-xr-xr-x 1 root wheel 198136 May 5 14:24 iwnfw.ko* -r-xr-xr-x 1 root wheel 6496 May 5 14:24 iwnfw.ko.symbols* -r-xr-xr-x 1 root wheel 23000 May 5 14:24 joy.ko* -r-xr-xr-x 1 root wheel 20016 May 5 14:24 joy.ko.symbols* -r-xr-xr-x 1 root wheel 43984 May 5 14:24 kbdmux.ko* -r-xr-xr-x 1 root wheel 31200 May 5 14:24 kbdmux.ko.symbols* -r-xr-xr-x 1 root wheel 11502375 May 5 14:06 kernel* -r-xr-xr-x 1 root wheel 45085952 May 5 14:06 kernel.symbols* -r-xr-xr-x 1 root wheel 335232 May 5 14:24 krpc.ko* -r-xr-xr-x 1 root wheel 276928 May 5 14:24 krpc.ko.symbols* -r-xr-xr-x 1 root wheel 78704 May 5 14:24 krping.ko* -r-xr-xr-x 1 root wheel 59256 May 5 14:24 krping.ko.symbols* -r-xr-xr-x 1 root wheel 132296 May 5 14:24 libalias.ko* -r-xr-xr-x 1 root wheel 90280 May 5 14:24 libalias.ko.symbols* -r-xr-xr-x 1 root wheel 41624 May 5 14:24 libiconv.ko* -r-xr-xr-x 1 root wheel 34760 May 5 14:24 libiconv.ko.symbols* -r-xr-xr-x 1 root wheel 10808 May 5 14:24 libmbpool.ko* -r-xr-xr-x 1 root wheel 9152 May 5 14:24 libmbpool.ko.symbols* -r-xr-xr-x 1 root wheel 10720 May 5 14:24 libmchain.ko* -r-xr-xr-x 1 root wheel 7672 May 5 14:24 libmchain.ko.symbols* -rw-r--r-- 1 root wheel 44188 May 5 14:24 linker.hints -r-xr-xr-x 1 root wheel 93440 May 5 14:24 linprocfs.ko* -r-xr-xr-x 1 root wheel 78832 May 5 14:24 linprocfs.ko.symbols* -r-xr-xr-x 1 root wheel 48192 May 5 14:24 linsysfs.ko* -r-xr-xr-x 1 root wheel 45872 May 5 14:24 linsysfs.ko.symbols* -r-xr-xr-x 1 root wheel 671888 May 5 14:24 linux.ko* -r-xr-xr-x 1 root wheel 569296 May 5 14:24 linux.ko.symbols* -r-xr-xr-x 1 root wheel 23544 May 5 14:24 logo_saver.ko* -r-xr-xr-x 1 root wheel 13560 May 5 14:24 logo_saver.ko.symbols* -r-xr-xr-x 1 root wheel 16920 May 5 14:24 lpbb.ko* -r-xr-xr-x 1 root wheel 14104 May 5 14:24 lpbb.ko.symbols* -r-xr-xr-x 1 root wheel 26080 May 5 14:24 lpt.ko* -r-xr-xr-x 1 root wheel 19704 May 5 14:24 lpt.ko.symbols* -r-xr-xr-x 1 root wheel 127928 May 5 14:24 mac_biba.ko* -r-xr-xr-x 1 root wheel 105000 May 5 14:24 mac_biba.ko.symbols* -r-xr-xr-x 1 root wheel 107336 May 5 14:24 mac_bsdextended.ko* -r-xr-xr-x 1 root wheel 99944 May 5 14:24 mac_bsdextended.ko.symbols* -r-xr-xr-x 1 root wheel 44272 May 5 14:24 mac_ifoff.ko* -r-xr-xr-x 1 root wheel 40648 May 5 14:24 mac_ifoff.ko.symbols* -r-xr-xr-x 1 root wheel 120104 May 5 14:24 mac_lomac.ko* -r-xr-xr-x 1 root wheel 99304 May 5 14:24 mac_lomac.ko.symbols* -r-xr-xr-x 1 root wheel 122216 May 5 14:24 mac_mls.ko* -r-xr-xr-x 1 root wheel 101432 May 5 14:24 mac_mls.ko.symbols* -r-xr-xr-x 1 root wheel 25912 May 5 14:24 mac_none.ko* -r-xr-xr-x 1 root wheel 25576 May 5 14:24 mac_none.ko.symbols* -r-xr-xr-x 1 root wheel 49088 May 5 14:24 mac_partition.ko* -r-xr-xr-x 1 root wheel 45392 May 5 14:24 mac_partition.ko.symbols* -r-xr-xr-x 1 root wheel 56936 May 5 14:24 mac_portacl.ko* -r-xr-xr-x 1 root wheel 51496 May 5 14:24 mac_portacl.ko.symbols* -r-xr-xr-x 1 root wheel 48608 May 5 14:24 mac_seeotheruids.ko* -r-xr-xr-x 1 root wheel 45008 May 5 14:24 mac_seeotheruids.ko.symbols* -r-xr-xr-x 1 root wheel 90504 May 5 14:24 mac_stub.ko* -r-xr-xr-x 1 root wheel 84960 May 5 14:24 mac_stub.ko.symbols* -r-xr-xr-x 1 root wheel 235208 May 5 14:24 mac_test.ko* -r-xr-xr-x 1 root wheel 193336 May 5 14:24 mac_test.ko.symbols* -r-xr-xr-x 1 root wheel 179232 May 5 14:24 mach64.ko* -r-xr-xr-x 1 root wheel 135528 May 5 14:24 mach64.ko.symbols* -r-xr-xr-x 1 root wheel 43192 May 5 14:24 mcd.ko* -r-xr-xr-x 1 root wheel 29880 May 5 14:24 mcd.ko.symbols* -r-xr-xr-x 1 root wheel 51776 May 5 14:24 mem.ko* -r-xr-xr-x 1 root wheel 46384 May 5 14:24 mem.ko.symbols* -r-xr-xr-x 1 root wheel 119552 May 5 14:24 mfi.ko* -r-xr-xr-x 1 root wheel 93608 May 5 14:24 mfi.ko.symbols* -r-xr-xr-x 1 root wheel 22144 May 5 14:24 mfi_linux.ko* -r-xr-xr-x 1 root wheel 21496 May 5 14:24 mfi_linux.ko.symbols* -r-xr-xr-x 1 root wheel 41816 May 5 14:24 mfip.ko* -r-xr-xr-x 1 root wheel 39304 May 5 14:24 mfip.ko.symbols* -r-xr-xr-x 1 root wheel 213224 May 5 14:24 mga.ko* -r-xr-xr-x 1 root wheel 156320 May 5 14:24 mga.ko.symbols* -r-xr-xr-x 1 root wheel 657296 May 5 14:24 miibus.ko* -r-xr-xr-x 1 root wheel 559880 May 5 14:24 miibus.ko.symbols* -r-xr-xr-x 1 root wheel 84536 May 5 14:24 mlx.ko* -r-xr-xr-x 1 root wheel 59936 May 5 14:24 mlx.ko.symbols* -r-xr-xr-x 1 root wheel 79736 May 5 14:24 mly.ko* -r-xr-xr-x 1 root wheel 54864 May 5 14:24 mly.ko.symbols* -r-xr-xr-x 1 root wheel 51856 May 5 14:24 mmc.ko* -r-xr-xr-x 1 root wheel 32000 May 5 14:24 mmc.ko.symbols* -r-xr-xr-x 1 root wheel 25456 May 5 14:24 mmcsd.ko* -r-xr-xr-x 1 root wheel 19800 May 5 14:24 mmcsd.ko.symbols* -r-xr-xr-x 1 root wheel 418792 May 5 14:24 mpt.ko* -r-xr-xr-x 1 root wheel 319216 May 5 14:24 mpt.ko.symbols* -r-xr-xr-x 1 root wheel 83744 May 5 14:24 mqueuefs.ko* -r-xr-xr-x 1 root wheel 65208 May 5 14:24 mqueuefs.ko.symbols* -r-xr-xr-x 1 root wheel 255872 May 5 14:24 msdosfs.ko* -r-xr-xr-x 1 root wheel 208816 May 5 14:24 msdosfs.ko.symbols* -r-xr-xr-x 1 root wheel 7656 May 5 14:24 msdosfs_iconv.ko* -r-xr-xr-x 1 root wheel 7264 May 5 14:24 msdosfs_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 47480 May 5 14:24 musb.ko* -r-xr-xr-x 1 root wheel 29456 May 5 14:24 musb.ko.symbols* -r-xr-xr-x 1 root wheel 117960 May 5 14:24 mxge_eth_z8e.ko* -r-xr-xr-x 1 root wheel 6568 May 5 14:24 mxge_eth_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 118816 May 5 14:24 mxge_ethp_z8e.ko* -r-xr-xr-x 1 root wheel 6584 May 5 14:24 mxge_ethp_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 155640 May 5 14:24 mxge_rss_eth_z8e.ko* -r-xr-xr-x 1 root wheel 6640 May 5 14:24 mxge_rss_eth_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 156960 May 5 14:24 mxge_rss_ethp_z8e.ko* -r-xr-xr-x 1 root wheel 6656 May 5 14:24 mxge_rss_ethp_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 400104 May 5 14:24 ndis.ko* -r-xr-xr-x 1 root wheel 326192 May 5 14:24 ndis.ko.symbols* -r-xr-xr-x 1 root wheel 104584 May 5 14:24 netgraph.ko* -r-xr-xr-x 1 root wheel 70840 May 5 14:24 netgraph.ko.symbols* -r-xr-xr-x 1 root wheel 980488 May 5 14:24 nfsclient.ko* -r-xr-xr-x 1 root wheel 822768 May 5 14:24 nfsclient.ko.symbols* -r-xr-xr-x 1 root wheel 210344 May 5 14:24 nfslockd.ko* -r-xr-xr-x 1 root wheel 170800 May 5 14:24 nfslockd.ko.symbols* -r-xr-xr-x 1 root wheel 24440 May 5 14:24 nfsmb.ko* -r-xr-xr-x 1 root wheel 18304 May 5 14:24 nfsmb.ko.symbols* -r-xr-xr-x 1 root wheel 327552 May 5 14:24 nfsserver.ko* -r-xr-xr-x 1 root wheel 261216 May 5 14:24 nfsserver.ko.symbols* -r-xr-xr-x 1 root wheel 20792 May 5 14:24 nfssvc.ko* -r-xr-xr-x 1 root wheel 20160 May 5 14:24 nfssvc.ko.symbols* -r-xr-xr-x 1 root wheel 13360 May 5 14:24 ng_UI.ko* -r-xr-xr-x 1 root wheel 12120 May 5 14:24 ng_UI.ko.symbols* -r-xr-xr-x 1 root wheel 21880 May 5 14:24 ng_async.ko* -r-xr-xr-x 1 root wheel 17136 May 5 14:24 ng_async.ko.symbols* -r-xr-xr-x 1 root wheel 48352 May 5 14:24 ng_atm.ko* -r-xr-xr-x 1 root wheel 36704 May 5 14:24 ng_atm.ko.symbols* -r-xr-xr-x 1 root wheel 19616 May 5 14:24 ng_atmllc.ko* -r-xr-xr-x 1 root wheel 17864 May 5 14:24 ng_atmllc.ko.symbols* -r-xr-xr-x 1 root wheel 15048 May 5 14:24 ng_bluetooth.ko* -r-xr-xr-x 1 root wheel 12576 May 5 14:24 ng_bluetooth.ko.symbols* -r-xr-xr-x 1 root wheel 30320 May 5 14:24 ng_bpf.ko* -r-xr-xr-x 1 root wheel 23536 May 5 14:24 ng_bpf.ko.symbols* -r-xr-xr-x 1 root wheel 33136 May 5 14:24 ng_bridge.ko* -r-xr-xr-x 1 root wheel 26440 May 5 14:24 ng_bridge.ko.symbols* -r-xr-xr-x 1 root wheel 43048 May 5 14:24 ng_bt3c.ko* -r-xr-xr-x 1 root wheel 31216 May 5 14:24 ng_bt3c.ko.symbols* -r-xr-xr-x 1 root wheel 305520 May 5 14:24 ng_btsocket.ko* -r-xr-xr-x 1 root wheel 215336 May 5 14:24 ng_btsocket.ko.symbols* -r-xr-xr-x 1 root wheel 22352 May 5 14:24 ng_car.ko* -r-xr-xr-x 1 root wheel 17432 May 5 14:24 ng_car.ko.symbols* -r-xr-xr-x 1 root wheel 253864 May 5 14:24 ng_ccatm.ko* -r-xr-xr-x 1 root wheel 193424 May 5 14:24 ng_ccatm.ko.symbols* -r-xr-xr-x 1 root wheel 25528 May 5 14:24 ng_cisco.ko* -r-xr-xr-x 1 root wheel 21600 May 5 14:24 ng_cisco.ko.symbols* -r-xr-xr-x 1 root wheel 22728 May 5 14:24 ng_deflate.ko* -r-xr-xr-x 1 root wheel 18208 May 5 14:24 ng_deflate.ko.symbols* -r-xr-xr-x 1 root wheel 26168 May 5 14:24 ng_device.ko* -r-xr-xr-x 1 root wheel 23400 May 5 14:24 ng_device.ko.symbols* -r-xr-xr-x 1 root wheel 11472 May 5 14:24 ng_echo.ko* -r-xr-xr-x 1 root wheel 10912 May 5 14:24 ng_echo.ko.symbols* -r-xr-xr-x 1 root wheel 25848 May 5 14:24 ng_eiface.ko* -r-xr-xr-x 1 root wheel 22840 May 5 14:24 ng_eiface.ko.symbols* -r-xr-xr-x 1 root wheel 17664 May 5 14:24 ng_etf.ko* -r-xr-xr-x 1 root wheel 15096 May 5 14:24 ng_etf.ko.symbols* -r-xr-xr-x 1 root wheel 32008 May 5 14:24 ng_ether.ko* -r-xr-xr-x 1 root wheel 27136 May 5 14:24 ng_ether.ko.symbols* -r-xr-xr-x 1 root wheel 12040 May 5 14:24 ng_ether_echo.ko* -r-xr-xr-x 1 root wheel 11312 May 5 14:24 ng_ether_echo.ko.symbols* -r-xr-xr-x 1 root wheel 33536 May 5 14:24 ng_fec.ko* -r-xr-xr-x 1 root wheel 27080 May 5 14:24 ng_fec.ko.symbols* -r-xr-xr-x 1 root wheel 15088 May 5 14:24 ng_frame_relay.ko* -r-xr-xr-x 1 root wheel 12728 May 5 14:24 ng_frame_relay.ko.symbols* -r-xr-xr-x 1 root wheel 26880 May 5 14:24 ng_gif.ko* -r-xr-xr-x 1 root wheel 24128 May 5 14:24 ng_gif.ko.symbols* -r-xr-xr-x 1 root wheel 15664 May 5 14:24 ng_gif_demux.ko* -r-xr-xr-x 1 root wheel 14056 May 5 14:24 ng_gif_demux.ko.symbols* -r-xr-xr-x 1 root wheel 118360 May 5 14:24 ng_hci.ko* -r-xr-xr-x 1 root wheel 83240 May 5 14:24 ng_hci.ko.symbols* -r-xr-xr-x 1 root wheel 14248 May 5 14:24 ng_hole.ko* -r-xr-xr-x 1 root wheel 13032 May 5 14:24 ng_hole.ko.symbols* -r-xr-xr-x 1 root wheel 11616 May 5 14:24 ng_hub.ko* -r-xr-xr-x 1 root wheel 10952 May 5 14:24 ng_hub.ko.symbols* -r-xr-xr-x 1 root wheel 30760 May 5 14:24 ng_iface.ko* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 ng_iface.ko.symbols* -r-xr-xr-x 1 root wheel 16600 May 5 14:24 ng_ip_input.ko* -r-xr-xr-x 1 root wheel 16160 May 5 14:24 ng_ip_input.ko.symbols* -r-xr-xr-x 1 root wheel 24248 May 5 14:24 ng_ipfw.ko* -r-xr-xr-x 1 root wheel 22568 May 5 14:24 ng_ipfw.ko.symbols* -r-xr-xr-x 1 root wheel 44256 May 5 14:24 ng_ksocket.ko* -r-xr-xr-x 1 root wheel 36104 May 5 14:24 ng_ksocket.ko.symbols* -r-xr-xr-x 1 root wheel 136800 May 5 14:24 ng_l2cap.ko* -r-xr-xr-x 1 root wheel 91184 May 5 14:24 ng_l2cap.ko.symbols* -r-xr-xr-x 1 root wheel 34368 May 5 14:24 ng_l2tp.ko* -r-xr-xr-x 1 root wheel 23864 May 5 14:24 ng_l2tp.ko.symbols* -r-xr-xr-x 1 root wheel 25208 May 5 14:24 ng_lmi.ko* -r-xr-xr-x 1 root wheel 17432 May 5 14:24 ng_lmi.ko.symbols* -r-xr-xr-x 1 root wheel 23112 May 5 14:24 ng_mppc.ko* -r-xr-xr-x 1 root wheel 17224 May 5 14:24 ng_mppc.ko.symbols* -r-xr-xr-x 1 root wheel 26768 May 5 14:24 ng_nat.ko* -r-xr-xr-x 1 root wheel 20888 May 5 14:24 ng_nat.ko.symbols* -r-xr-xr-x 1 root wheel 55320 May 5 14:24 ng_netflow.ko* -r-xr-xr-x 1 root wheel 45728 May 5 14:24 ng_netflow.ko.symbols* -r-xr-xr-x 1 root wheel 19360 May 5 14:24 ng_one2many.ko* -r-xr-xr-x 1 root wheel 15912 May 5 14:24 ng_one2many.ko.symbols* -r-xr-xr-x 1 root wheel 44832 May 5 14:24 ng_ppp.ko* -r-xr-xr-x 1 root wheel 27128 May 5 14:24 ng_ppp.ko.symbols* -r-xr-xr-x 1 root wheel 37368 May 5 14:24 ng_pppoe.ko* -r-xr-xr-x 1 root wheel 24688 May 5 14:24 ng_pppoe.ko.symbols* -r-xr-xr-x 1 root wheel 26440 May 5 14:24 ng_pptpgre.ko* -r-xr-xr-x 1 root wheel 19792 May 5 14:24 ng_pptpgre.ko.symbols* -r-xr-xr-x 1 root wheel 21080 May 5 14:24 ng_pred1.ko* -r-xr-xr-x 1 root wheel 16504 May 5 14:24 ng_pred1.ko.symbols* -r-xr-xr-x 1 root wheel 22752 May 5 14:24 ng_rfc1490.ko* -r-xr-xr-x 1 root wheel 19496 May 5 14:24 ng_rfc1490.ko.symbols* -r-xr-xr-x 1 root wheel 34880 May 5 14:24 ng_socket.ko* -r-xr-xr-x 1 root wheel 28520 May 5 14:24 ng_socket.ko.symbols* -r-xr-xr-x 1 root wheel 30576 May 5 14:24 ng_source.ko* -r-xr-xr-x 1 root wheel 24584 May 5 14:24 ng_source.ko.symbols* -r-xr-xr-x 1 root wheel 12680 May 5 14:24 ng_split.ko* -r-xr-xr-x 1 root wheel 11800 May 5 14:24 ng_split.ko.symbols* -r-xr-xr-x 1 root wheel 25128 May 5 14:24 ng_sppp.ko* -r-xr-xr-x 1 root wheel 22976 May 5 14:24 ng_sppp.ko.symbols* -r-xr-xr-x 1 root wheel 34072 May 5 14:24 ng_sscfu.ko* -r-xr-xr-x 1 root wheel 26936 May 5 14:24 ng_sscfu.ko.symbols* -r-xr-xr-x 1 root wheel 131272 May 5 14:24 ng_sscop.ko* -r-xr-xr-x 1 root wheel 74696 May 5 14:24 ng_sscop.ko.symbols* -r-xr-xr-x 1 root wheel 20312 May 5 14:24 ng_tag.ko* -r-xr-xr-x 1 root wheel 16848 May 5 14:24 ng_tag.ko.symbols* -r-xr-xr-x 1 root wheel 16896 May 5 14:24 ng_tcpmss.ko* -r-xr-xr-x 1 root wheel 14472 May 5 14:24 ng_tcpmss.ko.symbols* -r-xr-xr-x 1 root wheel 17040 May 5 14:24 ng_tee.ko* -r-xr-xr-x 1 root wheel 14488 May 5 14:24 ng_tee.ko.symbols* -r-xr-xr-x 1 root wheel 37368 May 5 14:24 ng_tty.ko* -r-xr-xr-x 1 root wheel 33888 May 5 14:24 ng_tty.ko.symbols* -r-xr-xr-x 1 root wheel 45624 May 5 14:24 ng_ubt.ko* -r-xr-xr-x 1 root wheel 32896 May 5 14:24 ng_ubt.ko.symbols* -r-xr-xr-x 1 root wheel 438096 May 5 14:24 ng_uni.ko* -r-xr-xr-x 1 root wheel 322024 May 5 14:24 ng_uni.ko.symbols* -r-xr-xr-x 1 root wheel 29520 May 5 14:24 ng_vjc.ko* -r-xr-xr-x 1 root wheel 21816 May 5 14:24 ng_vjc.ko.symbols* -r-xr-xr-x 1 root wheel 23968 May 5 14:24 ng_vlan.ko* -r-xr-xr-x 1 root wheel 20672 May 5 14:24 ng_vlan.ko.symbols* -r-xr-xr-x 1 root wheel 319384 May 5 14:24 ngatmbase.ko* -r-xr-xr-x 1 root wheel 168896 May 5 14:24 ngatmbase.ko.symbols* -r-xr-xr-x 1 root wheel 27080 May 5 14:24 nmdm.ko* -r-xr-xr-x 1 root wheel 25096 May 5 14:24 nmdm.ko.symbols* -r-xr-xr-x 1 root wheel 203152 May 5 14:24 ntfs.ko* -r-xr-xr-x 1 root wheel 176360 May 5 14:24 ntfs.ko.symbols* -r-xr-xr-x 1 root wheel 7584 May 5 14:24 ntfs_iconv.ko* -r-xr-xr-x 1 root wheel 7184 May 5 14:24 ntfs_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 98256 May 5 14:24 nullfs.ko* -r-xr-xr-x 1 root wheel 91192 May 5 14:24 nullfs.ko.symbols* -r-xr-xr-x 1 root wheel 21104 May 5 14:24 nvram.ko* -r-xr-xr-x 1 root wheel 20056 May 5 14:24 nvram.ko.symbols* -r-xr-xr-x 1 root wheel 83568 May 5 14:24 ohci.ko* -r-xr-xr-x 1 root wheel 56560 May 5 14:24 ohci.ko.symbols* -r-xr-xr-x 1 root wheel 21624 May 5 14:24 opensolaris.ko* -r-xr-xr-x 1 root wheel 20400 May 5 14:24 opensolaris.ko.symbols* -r-xr-xr-x 1 root wheel 30704 May 5 14:24 padlock.ko* -r-xr-xr-x 1 root wheel 24232 May 5 14:24 padlock.ko.symbols* -r-xr-xr-x 1 root wheel 95616 May 5 14:24 pccard.ko* -r-xr-xr-x 1 root wheel 57624 May 5 14:24 pccard.ko.symbols* -r-xr-xr-x 1 root wheel 15176 May 5 14:24 pcf.ko* -r-xr-xr-x 1 root wheel 11592 May 5 14:24 pcf.ko.symbols* -r-xr-xr-x 1 root wheel 495664 May 5 14:24 pf.ko* -r-xr-xr-x 1 root wheel 325264 May 5 14:24 pf.ko.symbols* -r-xr-xr-x 1 root wheel 37440 May 5 14:24 pflog.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 pflog.ko.symbols* -r-xr-xr-x 1 root wheel 46104 May 5 14:24 plip.ko* -r-xr-xr-x 1 root wheel 34080 May 5 14:24 plip.ko.symbols* -r-xr-xr-x 1 root wheel 76280 May 5 14:24 portalfs.ko* -r-xr-xr-x 1 root wheel 71752 May 5 14:24 portalfs.ko.symbols* -r-xr-xr-x 1 root wheel 51384 May 5 14:24 ppbus.ko* -r-xr-xr-x 1 root wheel 37624 May 5 14:24 ppbus.ko.symbols* -r-xr-xr-x 1 root wheel 54872 May 5 14:24 ppc.ko* -r-xr-xr-x 1 root wheel 40856 May 5 14:24 ppc.ko.symbols* -r-xr-xr-x 1 root wheel 33256 May 5 14:24 ppi.ko* -r-xr-xr-x 1 root wheel 24544 May 5 14:24 ppi.ko.symbols* -r-xr-xr-x 1 root wheel 22496 May 5 14:24 pps.ko* -r-xr-xr-x 1 root wheel 18064 May 5 14:24 pps.ko.symbols* -r-xr-xr-x 1 root wheel 218944 May 5 14:24 procfs.ko* -r-xr-xr-x 1 root wheel 207472 May 5 14:24 procfs.ko.symbols* -r-xr-xr-x 1 root wheel 46512 May 5 14:24 profile.ko* -r-xr-xr-x 1 root wheel 43504 May 5 14:24 profile.ko.symbols* -r-xr-xr-x 1 root wheel 39232 May 5 14:24 prototype.ko* -r-xr-xr-x 1 root wheel 38320 May 5 14:24 prototype.ko.symbols* -r-xr-xr-x 1 root wheel 131000 May 5 14:24 pseudofs.ko* -r-xr-xr-x 1 root wheel 118256 May 5 14:24 pseudofs.ko.symbols* -r-xr-xr-x 1 root wheel 65816 May 5 14:24 puc.ko* -r-xr-xr-x 1 root wheel 46888 May 5 14:24 puc.ko.symbols* -r-xr-xr-x 1 root wheel 167912 May 5 14:24 r128.ko* -r-xr-xr-x 1 root wheel 130368 May 5 14:24 r128.ko.symbols* -r-xr-xr-x 1 root wheel 632624 May 5 14:24 radeon.ko* -r-xr-xr-x 1 root wheel 284832 May 5 14:24 radeon.ko.symbols* -r-xr-xr-x 1 root wheel 14624 May 5 14:24 rain_saver.ko* -r-xr-xr-x 1 root wheel 13064 May 5 14:24 rain_saver.ko.symbols* -r-xr-xr-x 1 root wheel 100080 May 5 14:24 random.ko* -r-xr-xr-x 1 root wheel 69480 May 5 14:24 random.ko.symbols* -r-xr-xr-x 1 root wheel 6200 May 5 14:24 rc4.ko* -r-xr-xr-x 1 root wheel 5752 May 5 14:24 rc4.ko.symbols* -r-xr-xr-x 1 root wheel 33920 May 5 14:24 rdma_addr.ko* -r-xr-xr-x 1 root wheel 30632 May 5 14:24 rdma_addr.ko.symbols* -r-xr-xr-x 1 root wheel 88608 May 5 14:24 rdma_cma.ko* -r-xr-xr-x 1 root wheel 75984 May 5 14:24 rdma_cma.ko.symbols* -r-xr-xr-x 1 root wheel 77704 May 5 14:24 rdma_core.ko* -r-xr-xr-x 1 root wheel 62256 May 5 14:24 rdma_core.ko.symbols* -r-xr-xr-x 1 root wheel 49512 May 5 14:24 rdma_iwcm.ko* -r-xr-xr-x 1 root wheel 42464 May 5 14:24 rdma_iwcm.ko.symbols* -r-xr-xr-x 1 root wheel 315384 May 5 14:24 reiserfs.ko* -r-xr-xr-x 1 root wheel 291752 May 5 14:24 reiserfs.ko.symbols* -r-xr-xr-x 1 root wheel 15008 May 5 14:24 rt2561fw.ko* -r-xr-xr-x 1 root wheel 6504 May 5 14:24 rt2561fw.ko.symbols* -r-xr-xr-x 1 root wheel 15032 May 5 14:24 rt2561sfw.ko* -r-xr-xr-x 1 root wheel 6528 May 5 14:24 rt2561sfw.ko.symbols* -r-xr-xr-x 1 root wheel 15008 May 5 14:24 rt2661fw.ko* -r-xr-xr-x 1 root wheel 6504 May 5 14:24 rt2661fw.ko.symbols* -r-xr-xr-x 1 root wheel 53912 May 5 14:24 safe.ko* -r-xr-xr-x 1 root wheel 39200 May 5 14:24 safe.ko.symbols* -r-xr-xr-x 1 root wheel 126400 May 5 14:24 savage.ko* -r-xr-xr-x 1 root wheel 96056 May 5 14:24 savage.ko.symbols* -r-xr-xr-x 1 root wheel 88992 May 5 14:24 sbp.ko* -r-xr-xr-x 1 root wheel 61168 May 5 14:24 sbp.ko.symbols* -r-xr-xr-x 1 root wheel 66864 May 5 14:24 sbp_targ.ko* -r-xr-xr-x 1 root wheel 51280 May 5 14:24 sbp_targ.ko.symbols* -r-xr-xr-x 1 root wheel 35456 May 5 14:24 scc.ko* -r-xr-xr-x 1 root wheel 27888 May 5 14:24 scc.ko.symbols* -r-xr-xr-x 1 root wheel 38120 May 5 14:24 scd.ko* -r-xr-xr-x 1 root wheel 28144 May 5 14:24 scd.ko.symbols* -r-xr-xr-x 1 root wheel 112080 May 5 14:24 scsi_low.ko* -r-xr-xr-x 1 root wheel 86232 May 5 14:24 scsi_low.ko.symbols* -r-xr-xr-x 1 root wheel 41656 May 5 14:24 sdhci.ko* -r-xr-xr-x 1 root wheel 25664 May 5 14:24 sdhci.ko.symbols* -r-xr-xr-x 1 root wheel 41264 May 5 14:24 sdt.ko* -r-xr-xr-x 1 root wheel 39896 May 5 14:24 sdt.ko.symbols* -r-xr-xr-x 1 root wheel 56464 May 5 14:24 sem.ko* -r-xr-xr-x 1 root wheel 49776 May 5 14:24 sem.ko.symbols* -r-xr-xr-x 1 root wheel 65800 May 5 14:24 sis.ko* -r-xr-xr-x 1 root wheel 60288 May 5 14:24 sis.ko.symbols* -r-xr-xr-x 1 root wheel 18688 May 5 14:24 smb.ko* -r-xr-xr-x 1 root wheel 15664 May 5 14:24 smb.ko.symbols* -r-xr-xr-x 1 root wheel 557240 May 5 14:24 smbfs.ko* -r-xr-xr-x 1 root wheel 472168 May 5 14:24 smbfs.ko.symbols* -r-xr-xr-x 1 root wheel 13656 May 5 14:24 smbus.ko* -r-xr-xr-x 1 root wheel 11928 May 5 14:24 smbus.ko.symbols* -r-xr-xr-x 1 root wheel 17808 May 5 14:24 snake_saver.ko* -r-xr-xr-x 1 root wheel 16512 May 5 14:24 snake_saver.ko.symbols* -r-xr-xr-x 1 root wheel 41736 May 5 14:24 snd_ad1816.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 snd_ad1816.ko.symbols* -r-xr-xr-x 1 root wheel 44296 May 5 14:24 snd_als4000.ko* -r-xr-xr-x 1 root wheel 36624 May 5 14:24 snd_als4000.ko.symbols* -r-xr-xr-x 1 root wheel 52376 May 5 14:24 snd_atiixp.ko* -r-xr-xr-x 1 root wheel 40816 May 5 14:24 snd_atiixp.ko.symbols* -r-xr-xr-x 1 root wheel 44256 May 5 14:24 snd_cmi.ko* -r-xr-xr-x 1 root wheel 36192 May 5 14:24 snd_cmi.ko.symbols* -r-xr-xr-x 1 root wheel 43872 May 5 14:24 snd_cs4281.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 snd_cs4281.ko.symbols* -r-xr-xr-x 1 root wheel 67648 May 5 14:24 snd_csa.ko* -r-xr-xr-x 1 root wheel 50712 May 5 14:24 snd_csa.ko.symbols* -r-xr-xr-x 1 root wheel 17536 May 5 14:24 snd_driver.ko* -r-xr-xr-x 1 root wheel 15472 May 5 14:24 snd_driver.ko.symbols* -r-xr-xr-x 1 root wheel 74752 May 5 14:24 snd_ds1.ko* -r-xr-xr-x 1 root wheel 39248 May 5 14:24 snd_ds1.ko.symbols* -r-xr-xr-x 1 root wheel 58712 May 5 14:24 snd_emu10k1.ko* -r-xr-xr-x 1 root wheel 41272 May 5 14:24 snd_emu10k1.ko.symbols* -r-xr-xr-x 1 root wheel 155216 May 5 14:24 snd_emu10kx.ko* -r-xr-xr-x 1 root wheel 101496 May 5 14:24 snd_emu10kx.ko.symbols* -r-xr-xr-x 1 root wheel 64896 May 5 14:24 snd_envy24.ko* -r-xr-xr-x 1 root wheel 46432 May 5 14:24 snd_envy24.ko.symbols* -r-xr-xr-x 1 root wheel 61960 May 5 14:24 snd_envy24ht.ko* -r-xr-xr-x 1 root wheel 44816 May 5 14:24 snd_envy24ht.ko.symbols* -r-xr-xr-x 1 root wheel 65408 May 5 14:24 snd_es137x.ko* -r-xr-xr-x 1 root wheel 45904 May 5 14:24 snd_es137x.ko.symbols* -r-xr-xr-x 1 root wheel 45864 May 5 14:24 snd_ess.ko* -r-xr-xr-x 1 root wheel 37456 May 5 14:24 snd_ess.ko.symbols* -r-xr-xr-x 1 root wheel 39872 May 5 14:24 snd_fm801.ko* -r-xr-xr-x 1 root wheel 34168 May 5 14:24 snd_fm801.ko.symbols* -r-xr-xr-x 1 root wheel 168376 May 5 14:24 snd_hda.ko* -r-xr-xr-x 1 root wheel 88904 May 5 14:24 snd_hda.ko.symbols* -r-xr-xr-x 1 root wheel 51656 May 5 14:24 snd_ich.ko* -r-xr-xr-x 1 root wheel 40280 May 5 14:24 snd_ich.ko.symbols* -r-xr-xr-x 1 root wheel 63264 May 5 14:24 snd_maestro.ko* -r-xr-xr-x 1 root wheel 44936 May 5 14:24 snd_maestro.ko.symbols* -r-xr-xr-x 1 root wheel 70264 May 5 14:24 snd_maestro3.ko* -r-xr-xr-x 1 root wheel 42184 May 5 14:24 snd_maestro3.ko.symbols* -r-xr-xr-x 1 root wheel 92776 May 5 14:24 snd_mss.ko* -r-xr-xr-x 1 root wheel 65120 May 5 14:24 snd_mss.ko.symbols* -r-xr-xr-x 1 root wheel 92928 May 5 14:24 snd_neomagic.ko* -r-xr-xr-x 1 root wheel 34880 May 5 14:24 snd_neomagic.ko.symbols* -r-xr-xr-x 1 root wheel 41840 May 5 14:24 snd_sb16.ko* -r-xr-xr-x 1 root wheel 34640 May 5 14:24 snd_sb16.ko.symbols* -r-xr-xr-x 1 root wheel 40168 May 5 14:24 snd_sb8.ko* -r-xr-xr-x 1 root wheel 34272 May 5 14:24 snd_sb8.ko.symbols* -r-xr-xr-x 1 root wheel 25976 May 5 14:24 snd_sbc.ko* -r-xr-xr-x 1 root wheel 19728 May 5 14:24 snd_sbc.ko.symbols* -r-xr-xr-x 1 root wheel 46488 May 5 14:24 snd_solo.ko* -r-xr-xr-x 1 root wheel 36936 May 5 14:24 snd_solo.ko.symbols* -r-xr-xr-x 1 root wheel 12064 May 5 14:24 snd_spicds.ko* -r-xr-xr-x 1 root wheel 9408 May 5 14:24 snd_spicds.ko.symbols* -r-xr-xr-x 1 root wheel 44296 May 5 14:24 snd_t4dwave.ko* -r-xr-xr-x 1 root wheel 35680 May 5 14:24 snd_t4dwave.ko.symbols* -r-xr-xr-x 1 root wheel 136320 May 5 14:24 snd_uaudio.ko* -r-xr-xr-x 1 root wheel 102736 May 5 14:24 snd_uaudio.ko.symbols* -r-xr-xr-x 1 root wheel 57920 May 5 14:24 snd_via8233.ko* -r-xr-xr-x 1 root wheel 43712 May 5 14:24 snd_via8233.ko.symbols* -r-xr-xr-x 1 root wheel 41448 May 5 14:24 snd_via82c686.ko* -r-xr-xr-x 1 root wheel 35368 May 5 14:24 snd_via82c686.ko.symbols* -r-xr-xr-x 1 root wheel 45208 May 5 14:24 snd_vibes.ko* -r-xr-xr-x 1 root wheel 36568 May 5 14:24 snd_vibes.ko.symbols* -r-xr-xr-x 1 root wheel 28456 May 5 14:24 snp.ko* -r-xr-xr-x 1 root wheel 26224 May 5 14:24 snp.ko.symbols* -r-xr-xr-x 1 root wheel 750088 May 5 14:24 sound.ko* -r-xr-xr-x 1 root wheel 567280 May 5 14:24 sound.ko.symbols* -r-xr-xr-x 1 root wheel 18888 May 5 14:24 speaker.ko* -r-xr-xr-x 1 root wheel 14968 May 5 14:24 speaker.ko.symbols* -r-xr-xr-x 1 root wheel 132184 May 5 14:24 sppp.ko* -r-xr-xr-x 1 root wheel 82744 May 5 14:24 sppp.ko.symbols* -r-xr-xr-x 1 root wheel 16496 May 5 14:24 star_saver.ko* -r-xr-xr-x 1 root wheel 15616 May 5 14:24 star_saver.ko.symbols* -r-xr-xr-x 1 root wheel 108440 May 5 14:24 sym.ko* -r-xr-xr-x 1 root wheel 52632 May 5 14:24 sym.ko.symbols* -r-xr-xr-x 1 root wheel 160904 May 5 14:24 systrace.ko* -r-xr-xr-x 1 root wheel 124432 May 5 14:24 systrace.ko.symbols* -r-xr-xr-x 1 root wheel 46768 May 5 14:24 sysvmsg.ko* -r-xr-xr-x 1 root wheel 37504 May 5 14:24 sysvmsg.ko.symbols* -r-xr-xr-x 1 root wheel 51592 May 5 14:24 sysvsem.ko* -r-xr-xr-x 1 root wheel 40056 May 5 14:24 sysvsem.ko.symbols* -r-xr-xr-x 1 root wheel 47424 May 5 14:24 sysvshm.ko* -r-xr-xr-x 1 root wheel 39472 May 5 14:24 sysvshm.ko.symbols* -r-xr-xr-x 1 root wheel 30528 May 5 14:24 tdfx.ko* -r-xr-xr-x 1 root wheel 29520 May 5 14:24 tdfx.ko.symbols* -r-xr-xr-x 1 root wheel 156216 May 5 14:24 tmpfs.ko* -r-xr-xr-x 1 root wheel 137792 May 5 14:24 tmpfs.ko.symbols* -r-xr-xr-x 1 root wheel 29792 May 5 14:24 toecore.ko* -r-xr-xr-x 1 root wheel 27816 May 5 14:24 toecore.ko.symbols* -r-xr-xr-x 1 root wheel 56496 May 5 14:24 trm.ko* -r-xr-xr-x 1 root wheel 35672 May 5 14:24 trm.ko.symbols* -r-xr-xr-x 1 root wheel 151816 May 5 14:24 twa.ko* -r-xr-xr-x 1 root wheel 107408 May 5 14:24 twa.ko.symbols* -r-xr-xr-x 1 root wheel 73104 May 5 14:24 twe.ko* -r-xr-xr-x 1 root wheel 49680 May 5 14:24 twe.ko.symbols* -r-xr-xr-x 1 root wheel 32968 May 5 14:24 u3g.ko* -r-xr-xr-x 1 root wheel 27704 May 5 14:24 u3g.ko.symbols* -r-xr-xr-x 1 root wheel 23640 May 5 14:24 uark.ko* -r-xr-xr-x 1 root wheel 21304 May 5 14:24 uark.ko.symbols* -r-xr-xr-x 1 root wheel 179040 May 5 14:24 uart.ko* -r-xr-xr-x 1 root wheel 135552 May 5 14:24 uart.ko.symbols* -r-xr-xr-x 1 root wheel 29400 May 5 14:24 ubsa.ko* -r-xr-xr-x 1 root wheel 25136 May 5 14:24 ubsa.ko.symbols* -r-xr-xr-x 1 root wheel 69600 May 5 14:24 ubsec.ko* -r-xr-xr-x 1 root wheel 46936 May 5 14:24 ubsec.ko.symbols* -r-xr-xr-x 1 root wheel 29704 May 5 14:24 ubser.ko* -r-xr-xr-x 1 root wheel 26656 May 5 14:24 ubser.ko.symbols* -r-xr-xr-x 1 root wheel 42480 May 5 14:24 ubtbcmfw.ko* -r-xr-xr-x 1 root wheel 40656 May 5 14:24 ubtbcmfw.ko.symbols* -r-xr-xr-x 1 root wheel 31672 May 5 14:24 uchcom.ko* -r-xr-xr-x 1 root wheel 26512 May 5 14:24 uchcom.ko.symbols* -r-xr-xr-x 1 root wheel 27168 May 5 14:24 ucom.ko* -r-xr-xr-x 1 root wheel 19888 May 5 14:24 ucom.ko.symbols* -r-xr-xr-x 1 root wheel 26760 May 5 14:24 ucycom.ko* -r-xr-xr-x 1 root wheel 23368 May 5 14:24 ucycom.ko.symbols* -r-xr-xr-x 1 root wheel 31792 May 5 14:24 udbp.ko* -r-xr-xr-x 1 root wheel 26032 May 5 14:24 udbp.ko.symbols* -r-xr-xr-x 1 root wheel 108616 May 5 14:24 udf.ko* -r-xr-xr-x 1 root wheel 91576 May 5 14:24 udf.ko.symbols* -r-xr-xr-x 1 root wheel 7560 May 5 14:24 udf_iconv.ko* -r-xr-xr-x 1 root wheel 7160 May 5 14:24 udf_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 29960 May 5 14:24 uether.ko* -r-xr-xr-x 1 root wheel 25808 May 5 14:24 uether.ko.symbols* -r-xr-xr-x 1 root wheel 40528 May 5 14:24 ufm.ko* -r-xr-xr-x 1 root wheel 38872 May 5 14:24 ufm.ko.symbols* -r-xr-xr-x 1 root wheel 38192 May 5 14:24 ufoma.ko* -r-xr-xr-x 1 root wheel 30608 May 5 14:24 ufoma.ko.symbols* -r-xr-xr-x 1 root wheel 30432 May 5 14:24 uftdi.ko* -r-xr-xr-x 1 root wheel 25080 May 5 14:24 uftdi.ko.symbols* -r-xr-xr-x 1 root wheel 25840 May 5 14:24 ugensa.ko* -r-xr-xr-x 1 root wheel 23696 May 5 14:24 ugensa.ko.symbols* -r-xr-xr-x 1 root wheel 86192 May 5 14:24 uhci.ko* -r-xr-xr-x 1 root wheel 57632 May 5 14:24 uhci.ko.symbols* -r-xr-xr-x 1 root wheel 51776 May 5 14:24 uhid.ko* -r-xr-xr-x 1 root wheel 46424 May 5 14:24 uhid.ko.symbols* -r-xr-xr-x 1 root wheel 34904 May 5 14:24 uipaq.ko* -r-xr-xr-x 1 root wheel 21848 May 5 14:24 uipaq.ko.symbols* -r-xr-xr-x 1 root wheel 41104 May 5 14:24 ukbd.ko* -r-xr-xr-x 1 root wheel 26872 May 5 14:24 ukbd.ko.symbols* -r-xr-xr-x 1 root wheel 50424 May 5 14:24 ulpt.ko* -r-xr-xr-x 1 root wheel 45784 May 5 14:24 ulpt.ko.symbols* -r-xr-xr-x 1 root wheel 84792 May 5 14:24 umass.ko* -r-xr-xr-x 1 root wheel 59088 May 5 14:24 umass.ko.symbols* -r-xr-xr-x 1 root wheel 28112 May 5 14:24 umct.ko* -r-xr-xr-x 1 root wheel 25168 May 5 14:24 umct.ko.symbols* -r-xr-xr-x 1 root wheel 36312 May 5 14:24 umodem.ko* -r-xr-xr-x 1 root wheel 30640 May 5 14:24 umodem.ko.symbols* -r-xr-xr-x 1 root wheel 29072 May 5 14:24 umoscom.ko* -r-xr-xr-x 1 root wheel 25224 May 5 14:24 umoscom.ko.symbols* -r-xr-xr-x 1 root wheel 57016 May 5 14:24 ums.ko* -r-xr-xr-x 1 root wheel 49784 May 5 14:24 ums.ko.symbols* -r-xr-xr-x 1 root wheel 155136 May 5 14:24 unionfs.ko* -r-xr-xr-x 1 root wheel 124600 May 5 14:24 unionfs.ko.symbols* -r-xr-xr-x 1 root wheel 33840 May 5 14:24 uplcom.ko* -r-xr-xr-x 1 root wheel 27816 May 5 14:24 uplcom.ko.symbols* -r-xr-xr-x 1 root wheel 46032 May 5 14:24 urio.ko* -r-xr-xr-x 1 root wheel 43152 May 5 14:24 urio.ko.symbols* -r-xr-xr-x 1 root wheel 678384 May 5 14:24 usb.ko* -r-xr-xr-x 1 root wheel 487936 May 5 14:24 usb.ko.symbols* -r-xr-xr-x 1 root wheel 17360 May 5 14:24 usb_quirk.ko* -r-xr-xr-x 1 root wheel 11920 May 5 14:24 usb_quirk.ko.symbols* -r-xr-xr-x 1 root wheel 44016 May 5 14:24 usb_template.ko* -r-xr-xr-x 1 root wheel 36336 May 5 14:24 usb_template.ko.symbols* -r-xr-xr-x 1 root wheel 38448 May 5 14:24 usfs.ko* -r-xr-xr-x 1 root wheel 28248 May 5 14:24 usfs.ko.symbols* -r-xr-xr-x 1 root wheel 30120 May 5 14:24 uslcom.ko* -r-xr-xr-x 1 root wheel 25704 May 5 14:24 uslcom.ko.symbols* -r-xr-xr-x 1 root wheel 43328 May 5 14:24 uss820dci.ko* -r-xr-xr-x 1 root wheel 28560 May 5 14:24 uss820dci.ko.symbols* -r-xr-xr-x 1 root wheel 84496 May 5 14:24 utopia.ko* -r-xr-xr-x 1 root wheel 73688 May 5 14:24 utopia.ko.symbols* -r-xr-xr-x 1 root wheel 29920 May 5 14:24 uvisor.ko* -r-xr-xr-x 1 root wheel 25344 May 5 14:24 uvisor.ko.symbols* -r-xr-xr-x 1 root wheel 30312 May 5 14:24 uvscom.ko* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 uvscom.ko.symbols* -r-xr-xr-x 1 root wheel 36792 May 5 14:24 viapm.ko* -r-xr-xr-x 1 root wheel 26672 May 5 14:24 viapm.ko.symbols* -r-xr-xr-x 1 root wheel 45696 May 5 14:24 vkbd.ko* -r-xr-xr-x 1 root wheel 32176 May 5 14:24 vkbd.ko.symbols* -r-xr-xr-x 1 root wheel 48392 May 5 14:24 vpo.ko* -r-xr-xr-x 1 root wheel 33400 May 5 14:24 vpo.ko.symbols* -r-xr-xr-x 1 root wheel 14648 May 5 14:24 warp_saver.ko* -r-xr-xr-x 1 root wheel 12576 May 5 14:24 warp_saver.ko.symbols* -r-xr-xr-x 1 root wheel 1150544 May 5 14:24 wlan.ko* -r-xr-xr-x 1 root wheel 932616 May 5 14:24 wlan.ko.symbols* -r-xr-xr-x 1 root wheel 42320 May 5 14:24 wlan_acl.ko* -r-xr-xr-x 1 root wheel 39544 May 5 14:24 wlan_acl.ko.symbols* -r-xr-xr-x 1 root wheel 37888 May 5 14:24 wlan_amrr.ko* -r-xr-xr-x 1 root wheel 36264 May 5 14:24 wlan_amrr.ko.symbols* -r-xr-xr-x 1 root wheel 61912 May 5 14:24 wlan_ccmp.ko* -r-xr-xr-x 1 root wheel 43080 May 5 14:24 wlan_ccmp.ko.symbols* -r-xr-xr-x 1 root wheel 38552 May 5 14:24 wlan_rssadapt.ko* -r-xr-xr-x 1 root wheel 36616 May 5 14:24 wlan_rssadapt.ko.symbols* -r-xr-xr-x 1 root wheel 46480 May 5 14:24 wlan_tkip.ko* -r-xr-xr-x 1 root wheel 38416 May 5 14:24 wlan_tkip.ko.symbols* -r-xr-xr-x 1 root wheel 40408 May 5 14:24 wlan_wep.ko* -r-xr-xr-x 1 root wheel 36648 May 5 14:24 wlan_wep.ko.symbols* -r-xr-xr-x 1 root wheel 36184 May 5 14:24 wlan_xauth.ko* -r-xr-xr-x 1 root wheel 35744 May 5 14:24 wlan_xauth.ko.symbols* -r-xr-xr-x 1 root wheel 156456 May 5 14:24 wpifw.ko* -r-xr-xr-x 1 root wheel 6496 May 5 14:24 wpifw.ko.symbols* -r-xr-xr-x 1 root wheel 3549952 May 5 14:24 xfs.ko* -r-xr-xr-x 1 root wheel 3173032 May 5 14:24 xfs.ko.symbols* -r-xr-xr-x 1 root wheel 5075776 May 5 14:24 zfs.ko* -r-xr-xr-x 1 root wheel 4138392 May 5 14:24 zfs.ko.symbols* -r-xr-xr-x 1 root wheel 52080 May 5 14:24 zlib.ko* -r-xr-xr-x 1 root wheel 20920 May 5 14:24 zlib.ko.symbols* > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> There is new dmesg with debug=15, but I can't catch difference... >> > > If you type: > > ll /boot/kernel > > Do all the modules have the same date? > > There is a fuse4bsd module there which I suspect is out of date. > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:28: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 8F7EB1065677 for ; Tue, 5 May 2009 07:28:01 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33DF38FC2C for ; Tue, 5 May 2009 07:28:01 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5290F5C06F for ; Tue, 5 May 2009 15:28:00 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 255DA55D16B2; Tue, 5 May 2009 15:28:00 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 0QXuLx0iYQuV; Tue, 5 May 2009 15:27:01 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 52F9B55D16A3; Tue, 5 May 2009 15:26:56 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:cc:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=KX7UXKyNNE6MxV1/HNNdTi0QqZGtiwUJM02+qwmqlt7YekY7xmh0UCVxCPU13F1RX 22CsSnCqxNQd2j8AQjIgw== Date: Tue, 05 May 2009 15:26:43 +0800 To: "Hans Petter Selasky" From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905041556.18646.hselasky@c2i.net> <200905050919.51551.hselasky@c2i.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200905050919.51551.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: freebsd-current@freebsd.org Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:28:02 -0000 Hi Hans, I disabled fuse.ko and reboot box, nothing changed [root@currentpark] ~# kldstat Id Refs Address Size Name 1 1 0xffffffff80100000 c1b1e8 kernel > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> There is new dmesg with debug=15, but I can't catch difference... >> > > If you type: > > ll /boot/kernel > > Do all the modules have the same date? > > There is a fuse4bsd module there which I suspect is out of date. > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:35: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 DB4C71065672 for ; Tue, 5 May 2009 07:35:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 719388FC0C for ; Tue, 5 May 2009 07:35:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=QUtVGy250EaBWz6u7sEA:9 a=qmQvog2p1DtvgAx4Psh4A-EM9l0A:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1066786006; Tue, 05 May 2009 09:35:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 5 May 2009 09:38:20 +0200 User-Agent: KMail/1.9.7 References: <200905050919.51551.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905050938.20963.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:35:48 -0000 On Tuesday 05 May 2009, Chao Shin wrote: > Hi Hans, > > I disabled fuse.ko and reboot box, nothing changed > > [root@currentpark] ~# kldstat > Id Refs Address Size Name > 1 1 0xffffffff80100000 c1b1e8 kernel > Then you need to build a kernel with debugging and get a backtrace: options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. When you get to the debugger prompt at boot, type "bt" for backtrace. --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:49: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 945D6106566B for ; Tue, 5 May 2009 07:49:21 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 535478FC16 for ; Tue, 5 May 2009 07:49:20 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C4A7019E044; Tue, 5 May 2009 09:49:18 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3B5C019E043; Tue, 5 May 2009 09:49:16 +0200 (CEST) Message-ID: <49FFEF7C.6030005@quip.cz> Date: Tue, 05 May 2009 09:49:16 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49E4CED7.2040206@jrv.org> <49E69F7C.9020402@jrv.org> <20090416104803.O88758@rust.salford.ac.uk> In-Reply-To: <20090416104803.O88758@rust.salford.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Powell Subject: Re: ata FLUSHCACHE timeout errors? [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: Tue, 05 May 2009 07:49:21 -0000 Mark Powell wrote: > On Wed, 15 Apr 2009, James R. Van Artsdalen wrote: > >> James R. Van Artsdalen wrote: >> >>> I am getting many FLUSHCACHE timeout errors during "zfs recv" >>> operations. >> >> >> This patch fixes this. PR to be filed. >> In addition this causes any ata request that times out to print the >> timeout, since it's going to be the timeout itself that's likely wrong. > > > This is well known and had been repeated ad. inf.. Problem is, it never > got addressed: > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > Attached is an 8-CURRENT patch which makes the ata timeout a tuneable. > Shamelessy ripped off the FreeNAS patch on the above url. > Cheers. Is there any possibility to have it committed in to the tree? It seems useful, I have timeout problems [READ_DMA timed out] on few machines and this (tunable / longer timeout) should definitely fix it. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:50: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 C3A6A1065679 for ; Tue, 5 May 2009 07:50:44 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 693E98FC1B for ; Tue, 5 May 2009 07:50:44 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 64AE75C073 for ; Tue, 5 May 2009 15:50:43 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 362F655D16AF; Tue, 5 May 2009 15:50:43 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 2gheBWGM091e; Tue, 5 May 2009 15:49:54 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8C47D55D16AE; Tue, 5 May 2009 15:49:44 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=wwhMAwZSZ9iivE8S5C1wWUpHX7C2TpoX2H80Tz61sMNatYSqUI4nRS170kQHamCBy fDSDHCriHU0PcEYzp/N3Q== Date: Tue, 05 May 2009 15:49:28 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905050919.51551.hselasky@c2i.net> <200905050938.20963.hselasky@c2i.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200905050938.20963.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:50:45 -0000 在 Tue, 05 May 2009 15:38:20 +0800，Hans Petter Selasky 写道: > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> >> I disabled fuse.ko and reboot box, nothing changed >> >> [root@currentpark] ~# kldstat >> Id Refs Address Size Name >> 1 1 0xffffffff80100000 c1b1e8 kernel >> > Because my box have no ps/2 mouse and keyborad interface, so after I entered kdb, the keyboard can not work any more... any idea? > Then you need to build a kernel with debugging and get a backtrace: > > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > > When you get to the debugger prompt at boot, type "bt" for backtrace. > > --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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 07:54: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 1B9E110656DD for ; Tue, 5 May 2009 07:54:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id A60B58FC0A for ; Tue, 5 May 2009 07:54:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=R9-VYX1gZw5sxdxOw7AA:9 a=6BycFQhpxapd1gbxxnQA:7 a=c_OTAnqDqWNRQ5BBB8v1IICqxeoA:4 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 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 492964423; Tue, 05 May 2009 09:54:26 +0200 From: Hans Petter Selasky To: "Chao Shin" Date: Tue, 5 May 2009 09:57:00 +0200 User-Agent: KMail/1.9.7 References: <200905050938.20963.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905050957.01216.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 07:54:29 -0000 On Tuesday 05 May 2009, Chao Shin wrote: > =E5=9C=A8 Tue, 05 May 2009 15:38:20 +0800=EF=BC=8CHans Petter Selasky > > =E5=86=99=E9=81=93: > > On Tuesday 05 May 2009, Chao Shin wrote: > >> Hi Hans, > >> > >> I disabled fuse.ko and reboot box, nothing changed > >> > >> [root@currentpark] ~# kldstat > >> Id Refs Address Size Name > >> 1 1 0xffffffff80100000 c1b1e8 kernel > > Because my box have no ps/2 mouse and keyborad interface, so after I > entered kdb, the keyboard can not work any more... > any idea? Hi Chao, What is printed on the screen? You can also try adding these options: options KDB_UNATTENDED # reboot by default options PANIC_REBOOT_WAIT_TIME=3D10 #seconds =2D-HPS > > > Then you need to build a kernel with debugging and get a backtrace: > > > > options KDB # Enable kernel debugger suppor= t. > > options DDB # Support DDB. > > options GDB # Support remote GDB. > > > > When you get to the debugger prompt at boot, type "bt" for backtrace. > > > > --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 Tue May 5 08:06: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 5A0AA1065675 for ; Tue, 5 May 2009 08:06:26 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id ED9C08FC12 for ; Tue, 5 May 2009 08:06:25 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 0DA325C070 for ; Tue, 5 May 2009 16:06:25 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id AF61255D16AD; Tue, 5 May 2009 16:06:24 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 9pr2+UAmLekH; Tue, 5 May 2009 16:05:26 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 0C41D55D16A3; Tue, 5 May 2009 16:05:16 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:cc:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=ZLrkOsLzJVwR/g9HZ4C9h0OP2bQjhQvxLpbI+2fI2WoyD1QTpJveEXmoupXo3vw8X qqMxKTxjudgeMiOprc+3A== Date: Tue, 05 May 2009 16:05:05 +0800 To: "Hans Petter Selasky" From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905050938.20963.hselasky@c2i.net> <200905050957.01216.hselasky@c2i.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200905050957.01216.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: freebsd-current@freebsd.org Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 08:06:26 -0000 >> > On Tuesday 05 May 2009, Chao Shin wrote: >> >> Hi Hans, >> >> >> >> I disabled fuse.ko and reboot box, nothing changed >> >> >> >> [root@currentpark] ~# kldstat >> >> Id Refs Address Size Name >> >> 1 1 0xffffffff80100000 c1b1e8 kernel >> >> Because my box have no ps/2 mouse and keyborad interface, so after I >> entered kdb, the keyboard can not work any more... >> any idea? > > Hi Chao, > > What is printed on the screen? > > You can also try adding these options: > > options KDB_UNATTENDED # reboot by default > options PANIC_REBOOT_WAIT_TIME=10 #seconds > > --HPS But my box didn't panic after booting, only usb mouse couldn't recognized. I don't understand what you want to see. > > >> >> > Then you need to build a kernel with debugging and get a backtrace: >> > >> > options KDB # Enable kernel debugger >> support. >> > options DDB # Support DDB. >> > options GDB # Support remote GDB. >> > >> > When you get to the debugger prompt at boot, type "bt" for backtrace. >> > >> > --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" > > > _______________________________________________ > 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" -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 08:38: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 53045106564A for ; Tue, 5 May 2009 08:38:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id DF86D8FC1A for ; Tue, 5 May 2009 08:38:19 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=T-RdjjgWDNJRC0zp7lUA:9 a=5QlnIh6ntBOrdQ6bFxCUaWsSKlMA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1239873087; Tue, 05 May 2009 10:38:18 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 5 May 2009 10:40:53 +0200 User-Agent: KMail/1.9.7 References: <200905050957.01216.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905051040.53708.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 08:38:20 -0000 On Tuesday 05 May 2009, Chao Shin wrote: > >> > On Tuesday 05 May 2009, Chao Shin wrote: > >> >> Hi Hans, > >> >> > >> >> I disabled fuse.ko and reboot box, nothing changed > >> >> > >> >> [root@currentpark] ~# kldstat > >> >> Id Refs Address Size Name > >> >> 1 1 0xffffffff80100000 c1b1e8 kernel > >> > >> Because my box have no ps/2 mouse and keyborad interface, so after I > >> entered kdb, the keyboard can not work any more... > >> any idea? > > > > Hi Chao, > > > > What is printed on the screen? > > > > You can also try adding these options: > > > > options KDB_UNATTENDED # reboot by default > > options PANIC_REBOOT_WAIT_TIME=10 #seconds > > > > --HPS > > But my box didn't panic after booting, only usb mouse couldn't recognized. > I don't understand what you want to see. Sorry, I'm mixing with another error report. Try this: 1) Boot without the USB mouse plugged in. 2) Run: sysctl hw.usb2.uhci.debug=15 3) Plug your USB mouse. 4) Unplug your USB mouse. Send dmesg. --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 5 09:05: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 EDF991065672 for ; Tue, 5 May 2009 09:05:54 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id C92E68FC19 for ; Tue, 5 May 2009 09:05:51 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id A87945C070 for ; Tue, 5 May 2009 17:05:50 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id D27B455D16AD; Tue, 5 May 2009 17:05:49 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 3puo7f339PMA; Tue, 5 May 2009 17:04:42 +0800 (CST) Received: from qld630 (unknown [219.142.100.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 9B4EC55D16A3; Tue, 5 May 2009 17:04:32 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:message-id:in-reply-to:user-agent; b=a+RiQ5+EZXAkeHia/XrgNDnVTju/yfUL+nPH2G48se4EVpAsRLVDIOO58GXwhwbKi lLpB+imhufWwt1XgHzLFw== Date: Tue, 05 May 2009 17:04:21 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: multipart/mixed; boundary=----------MzLPzOZYrxSwTrFHiE6WCq MIME-Version: 1.0 References: <200905050957.01216.hselasky@c2i.net> <200905051040.53708.hselasky@c2i.net> Message-ID: In-Reply-To: <200905051040.53708.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 09:05:55 -0000 ------------MzLPzOZYrxSwTrFHiE6WCq Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit 在 Tue, 05 May 2009 16:40:53 +0800，Hans Petter Selasky 写道: > sysctl hw.usb2.uhci.debug=15 This is my dmesg in attchement. -- The Power to Serve ------------MzLPzOZYrxSwTrFHiE6WCq Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; name=dmesg.txt Content-Transfer-Encoding: Base64 77u/Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4 OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG cmVlQlNEIEZvdW5kYXRpb24uDQpGcmVlQlNEIDguMC1DVVJSRU5UICM1OiBUdWUg TWF5ICA1IDE0OjA1OjI0IENTVCAyMDA5DQogICAgcm9vdEBjdXJyZW50cGFyay5p bnRyYS51bWVzc2FnZS5jb20uY246L3Vzci9vYmovdXNyL3NyYy9zeXMvVU1FU1NB R0UNClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwDQpDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgRHVhbCAgQ1BVICBFMjE2 MCAgQCAxLjgwR0h6ICgxNzk1LjUxLU1IeiBLOC1jbGFzcyBDUFUpDQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmZkICBTdGVwcGluZyA9IDEzDQog IEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUs TUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xG TFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPg0K ICBGZWF0dXJlczI9MHhlMzlkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsRVNULFRN MixTU1NFMyxDWDE2LHhUUFIsUERDTT4NCiAgQU1EIEZlYXR1cmVzPTB4MjAxMDA4 MDA8U1lTQ0FMTCxOWCxMTT4NCiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4NCiAg VFNDOiBQLXN0YXRlIGludmFyaWFudA0KcmVhbCBtZW1vcnkgID0gMTA3Mzc0MTgy NCAoMTAyNCBNQikNCmF2YWlsIG1lbW9yeSA9IDEwMTIxOTUzMjggKDk2NSBNQikN CkFDUEkgQVBJQyBUYWJsZTogPERFTEwgICBCOEsgICAgPg0KRnJlZUJTRC9TTVA6 IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzDQpGcmVlQlNE L1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpDQogY3B1MCAoQlNQKTogQVBJ QyBJRDogIDANCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxDQppb2FwaWMwOiBDaGFu Z2luZyBBUElDIElEIHRvIDgNCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAt MjMgb24gbW90aGVyYm9hcmQNCmxhcGljMDogRm9yY2luZyBMSU5UMSB0byBlZGdl IHRyaWdnZXINCmtiZDEgYXQga2JkbXV4MA0KYWNwaTA6IDxERUxMIEI4SyAgICA+ IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogUG93ZXIg QnV0dG9uIChmaXhlZCkNCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAo MykgZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBmMDAwMDAg KDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMDAsIDNlNWZm YzAwICgzKSBmYWlsZWQNClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5j eSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQg dGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAN CmFjcGlfaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0g MHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwDQpUaW1lY291bnRlciAiSFBF VCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAwDQphY3BpX2J1dHRv bjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwDQpwY2liMDogPEFDUEkgSG9zdC1Q Q0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMA0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+ IHBvcnQgMHhlY2I4LTB4ZWNiZiBtZW0gMHhmZWEwMDAwMC0weGZlYWZmZmZmLDB4 ZDAwMDAwMDAtMHhkZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kw DQphZ3AwOiA8SW50ZWwgUTk2NSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAN CmFncDA6IGRldGVjdGVkIDc2NzZrIHN0b2xlbiBtZW1vcnkNCmFncDA6IGFwZXJ0 dXJlIHNpemUgaXMgMjU2TQ0KdmdhcGNpMTogPFZHQS1jb21wYXRpYmxlIGRpc3Bs YXk+IG1lbSAweGZlYjAwMDAwLTB4ZmViZmZmZmYgYXQgZGV2aWNlIDIuMSBvbiBw Y2kwDQp1aGNpMDogPEludGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIg VVNCLUQ+IHBvcnQgMHhmZjIwLTB4ZmYzZiBpcnEgMTYgYXQgZGV2aWNlIDI2LjAg b24gcGNpMA0KdWhjaTA6IFtJVEhSRUFEXQ0KdWhjaTA6IExlZ1N1cCA9IDB4MGYx MA0KdXNidXMwOiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBV U0ItRD4gb24gdWhjaTANCnVoY2kxOiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0Ig Y29udHJvbGxlciBVU0ItRT4gcG9ydCAweGZmMDAtMHhmZjFmIGlycSAxNyBhdCBk ZXZpY2UgMjYuMSBvbiBwY2kwDQp1aGNpMTogW0lUSFJFQURdDQp1aGNpMTogTGVn U3VwID0gMHgwZjEwDQp1c2J1czE6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBj b250cm9sbGVyIFVTQi1FPiBvbiB1aGNpMQ0KZWhjaTA6IDxJbnRlbCA4MjgwMUgg KElDSDgpIFVTQiAyLjAgY29udHJvbGxlciBVU0IyLUI+IG1lbSAweGZlOWZiYzAw LTB4ZmU5ZmJmZmYgaXJxIDIyIGF0IGRldmljZSAyNi43IG9uIHBjaTANCmVoY2kw OiBbSVRIUkVBRF0NCnVzYnVzMjogd2FpdGluZyBmb3IgQklPUyB0byBnaXZlIHVw IGNvbnRyb2wNCnVzYnVzMjogRUhDSSB2ZXJzaW9uIDEuMA0KdXNidXMyOiA8SW50 ZWwgODI4MDFIIChJQ0g4KSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCMi1CPiBvbiBl aGNpMA0KcGNpMDogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNlIDI3LjAgKG5v IGRyaXZlciBhdHRhY2hlZCkNCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTANCnBjaTI6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIyDQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAx NiBhdCBkZXZpY2UgMjguNCBvbiBwY2kwDQpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMw0KYmdlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBHaWdhYml0IEV0aGVy bmV0IENvbnRyb2xsZXIsIEFTSUMgcmV2LiAweGIwMDI+IG1lbSAweGZlNmYwMDAw LTB4ZmU2ZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMw0KbWlpYnVz MDogPE1JSSBidXM+IG9uIGJnZTANCmJyZ3BoeTA6IDxCQ001Nzg3IDEwLzEwMC8x MDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMA0KYnJncGh5MDogIDEwYmFz ZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBi YXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bw0KYmdlMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MWE6YTA6ZTE6MzE6ZWINCmJnZTA6IFtJVEhSRUFEXQ0KdWhjaTI6IDxJ bnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4 ZmY4MC0weGZmOWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTANCnVoY2ky OiBbSVRIUkVBRF0NCnVoY2kyOiBMZWdTdXAgPSAweDAwMDANCnVzYnVzMzogPElu dGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2ky DQp1aGNpMzogPEludGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNC LUI+IHBvcnQgMHhmZjYwLTB4ZmY3ZiBpcnEgMTcgYXQgZGV2aWNlIDI5LjEgb24g cGNpMA0KdWhjaTM6IFtJVEhSRUFEXQ0KdWhjaTM6IExlZ1N1cCA9IDB4MDAwMA0K dXNidXM0OiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBVU0It Qj4gb24gdWhjaTMNCnVoY2k0OiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29u dHJvbGxlciBVU0ItQz4gcG9ydCAweGZmNDAtMHhmZjVmIGlycSAxOCBhdCBkZXZp Y2UgMjkuMiBvbiBwY2kwDQp1aGNpNDogW0lUSFJFQURdDQp1aGNpNDogTGVnU3Vw ID0gMHgwMDAwDQp1c2J1czU6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250 cm9sbGVyIFVTQi1DPiBvbiB1aGNpNA0KZWhjaTE6IDxJbnRlbCA4MjgwMUggKElD SDgpIFVTQiAyLjAgY29udHJvbGxlciBVU0IyLUE+IG1lbSAweGZmOTgwODAwLTB4 ZmY5ODBiZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTANCmVoY2kxOiBb SVRIUkVBRF0NCnVzYnVzNjogRUhDSSB2ZXJzaW9uIDEuMA0KdXNidXM2OiA8SW50 ZWwgODI4MDFIIChJQ0g4KSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCMi1BPiBvbiBl aGNpMQ0KcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAu MCBvbiBwY2kwDQpwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNA0KaXNhYjA6 IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMA0KaXNhMDog PElTQSBidXM+IG9uIGlzYWIwDQphdGFwY2kwOiA8SW50ZWwgSUNIOCBTQVRBMzAw IGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcs MHgzNzYsMHhmZWMwLTB4ZmVjZiwweGVjYzAtMHhlY2NmIGF0IGRldmljZSAzMS4y IG9uIHBjaTANCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGEw OiBbSVRIUkVBRF0NCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwDQph dGExOiBbSVRIUkVBRF0NCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2 aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmF0YXBjaTE6IDxJbnRlbCBJ Q0g4IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGZlNDAtMHhmZTQ3LDB4ZmU1 MC0weGZlNTMsMHhmZTYwLTB4ZmU2NywweGZlNzAtMHhmZTczLDB4ZmVkMC0weGZl ZGYsMHhlY2QwLTB4ZWNkZiBpcnEgMjAgYXQgZGV2aWNlIDMxLjUgb24gcGNpMA0K YXRhcGNpMTogW0lUSFJFQURdDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRh cGNpMQ0KYXRhMjogW0lUSFJFQURdDQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24g YXRhcGNpMQ0KYXRhMzogW0lUSFJFQURdDQphdHJ0YzA6IDxBVCByZWFsdGltZSBj bG9jaz4gcG9ydCAweDcwLTB4N2YgaXJxIDggb24gYWNwaTANCnBwYzA6IDxQYXJh bGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4NzdmIGlycSA3IG9u IGFjcGkwDQpwcGMwOiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJC TEUpIGluIENPTVBBVElCTEUgbW9kZQ0KcHBjMDogRklGTyB3aXRoIDE2LzE2Lzgg Ynl0ZXMgdGhyZXNob2xkDQpwcGMwOiBbSVRIUkVBRF0NCnBwYnVzMDogPFBhcmFs bGVsIHBvcnQgYnVzPiBvbiBwcGMwDQpwbGlwMDogPFBMSVAgbmV0d29yayBpbnRl cmZhY2U+IG9uIHBwYnVzMA0KcGxpcDA6IFtJVEhSRUFEXQ0KbHB0MDogPFByaW50 ZXI+IG9uIHBwYnVzMA0KbHB0MDogW0lUSFJFQURdDQpscHQwOiBJbnRlcnJ1cHQt ZHJpdmVuIHBvcnQNCnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMA0KdWFy dDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gYWNwaTANCnVhcnQwOiBbRklMVEVSXQ0KY3B1MDogPEFD UEkgQ1BVPiBvbiBhY3BpMA0KZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVx dWVuY3kgQ29udHJvbD4gb24gY3B1MA0KZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5j ZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQuDQplc3Q6IGNwdV92 ZW5kb3IgR2VudWluZUludGVsLCBtc3IgOTI4MDkyODA2MDAwOTI4DQpkZXZpY2Vf YXR0YWNoOiBlc3QwIGF0dGFjaCByZXR1cm5lZCA2DQpwNHRjYzA6IDxDUFUgRnJl cXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MA0KY3B1MTogPEFDUEkgQ1BV PiBvbiBhY3BpMA0KZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MQ0KZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5jZWQgU3Bl ZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQuDQplc3Q6IGNwdV92ZW5kb3Ig R2VudWluZUludGVsLCBtc3IgOTI4MDkyODA2MDAwOTI4DQpkZXZpY2VfYXR0YWNo OiBlc3QxIGF0dGFjaCByZXR1cm5lZCA2DQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5 IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQ0Kb3JtMDogPElTQSBPcHRpb24gUk9N cz4gYXQgaW9tZW0gMHhjMDAwMC0weGNhZmZmLDB4Y2IwMDAtMHhjY2ZmZiwweGNk MDAwLTB4Y2ZmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZs YWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVz LCBmbGFncz0weDMwMD4NCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQg MHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCmF0a2Jk YzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCww eDY0IG9uIGlzYTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGti ZGMwDQprYmQwIGF0IGF0a2JkMA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0KYXRr YmQwOiBbSVRIUkVBRF0NClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1z ZWMNCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMTog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMjogNDgwTWJwcyBIaWdo IFNwZWVkIFVTQiB2Mi4wDQp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2 MS4wDQp1aGNpX2ludGVycnVwdDogaG9zdCBzeXN0ZW0gZXJyb3INCnVzYnVzNDog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzNTogMTJNYnBzIEZ1bGwg U3BlZWQgVVNCIHYxLjANCnVzYnVzNjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wDQphZDA6IDE1MjU4N01CIDxTZWFnYXRlIFNUMzE2MDgxNUFTIDQuQURBPiBh dCBhdGEwLW1hc3RlciBTQVRBMzAwDQp1aGNpX2ludGVycnVwdDogaG9zdCBzeXN0 ZW0gZXJyb3INCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwDQp1aHViMDogPElu dGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czANCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxDQp1aHVi MTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2J1czENCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMy DQp1aHViMjogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czINCnVnZW4zLjE6IDxJbnRlbD4gYXQg dXNidXMzDQp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMNCnVnZW40LjE6IDxJbnRl bD4gYXQgdXNidXM0DQp1aHViNDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQNCnVnZW41LjE6 IDxJbnRlbD4gYXQgdXNidXM1DQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUNCnVn ZW42LjE6IDxJbnRlbD4gYXQgdXNidXM2DQp1aHViNjogPEludGVsIEVIQ0kgcm9v dCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czYNCkdFT006IGFkMDogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1 NWgsNjNzICE9IDE2aCw2M3MpLg0KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3Zp ZGVyIGFkMGEgaXMgdWZzaWQvNDlmOTg0NTRmZjUyYjk4Zi4NCkdFT01fTEFCRUw6 IExhYmVsIGZvciBwcm92aWRlciBhZDBhIGlzIHVmcy9yb290Lg0KR0VPTV9MQUJF TDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMGQgaXMgdWZzaWQvNDlmOTg0NWI0Y2Jj MTM0MS4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBkIGlzIHVm cy92YXIuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwZSBpcyB1 ZnNpZC80OWY5ODQ1NWIyYzdlOWU1Lg0KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHBy b3ZpZGVyIGFkMGUgaXMgdWZzL3RtcC4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBw cm92aWRlciBhZDBmIGlzIHVmc2lkLzQ5Zjk4NDU0MDVmZjAzZGUuDQpHRU9NX0xB QkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwZiBpcyB1ZnMvaG9tZS4NCkdFT01f TEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBnIGlzIHVmc2lkLzQ5Zjk4NDU2 YmJiOWM0OTMuDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwZyBp cyB1ZnMvdXNyLg0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQNCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZA0KdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkDQp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCnVodWIyOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZA0KdWh1YjY6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkDQphY2QwOiBEVkRST00gPFRTU1Rjb3JwRFZELVJPTSBUUy1IMzUzQi9EMjAw PiBhdCBhdGExLW1hc3RlciBTQVRBMTUwDQpsYXBpYzE6IEZvcmNpbmcgTElOVDEg dG8gZWRnZSB0cmlnZ2VyDQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCENClJvb3Qg bW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNg0KVHJ5aW5nIHRvIG1vdW50IHJvb3Qg ZnJvbSB1ZnM6L2Rldi91ZnMvcm9vdA0KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQv NDlmOTg0NTRmZjUyYjk4ZiByZW1vdmVkLg0KR0VPTV9MQUJFTDogTGFiZWwgdWZz aWQvNDlmOTg0NTQwNWZmMDNkZSByZW1vdmVkLg0KR0VPTV9MQUJFTDogTGFiZWwg dWZzaWQvNDlmOTg0NTViMmM3ZTllNSByZW1vdmVkLg0KR0VPTV9MQUJFTDogTA0K PDExYTg+L2Rldi91ZnMvaG9tZTogRklMRSBTWVNURU0gQ0xFYkFOOyBTS0lQUElO RyBDSEVDS1MNCmVsDQogdWZzaWQvNDlmOTg0NTZiYmI5YzQ5MyByZW1vdmVkLg0K R0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDlmOTg0NWI0Yw0KMTMNCjQxIHJlbW92 ZWQuDQoNCnVnZW40LjI6IDxEZWxsPiBhdCB1c2J1czQNCnVrYmQwOiA8RGVsbCBw cm9kdWN0IDB4MjEwNSwgY2xhc3MgMC8wLCByZXYgMS4xMC8zLjUyLCBhZGRyIDI+ IG9uIHVzYnVzNA0Ka2JkMiBhdCB1a2JkMA0KYmdlMDogbGluayBzdGF0ZSBjaGFu Z2VkIHRvIFVQDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3 X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMC4NCnVoY2lfcm9vdGh1Yl9leGVj OjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVl PTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0 eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAg d0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3Nl dF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDEuDQp1aGNpX3Jvb3RodWJf ZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdW YWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUx NDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgw MDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhj aV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAzLg0KdWhjaV9yb290 aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAw NCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVj OjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVl PTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiAN CnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDA6IFNvbWUgVVNCIHRyYW5zZmVyIGlzIGFj dGl2ZSBvbiA0Lg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJl cXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAw MDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4 MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNp X3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBv d2VyIHNhdmUgb24gNS4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhh MyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9 MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVz dD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0K dWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0 OiBQb3dlciBzYXZlIG9uIDAuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBl PTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0lu ZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJl cXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAw MDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6 MzIwNDogUG93ZXIgc2F2ZSBvbiAxLg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDog dHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAw IHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhh MyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9 MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bv d2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMy4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1 MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4 MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBl PTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0lu ZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9o d19wb3dlcjozMjAwOiBTb21lIFVTQiB0cmFuc2ZlciBpcyBhY3RpdmUgb24gNC4N CnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAg d0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jv b3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgw MDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93 ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9u IDUuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0w eDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhj aV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVu PTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3 X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2 ZSBvbiAwLg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVl c3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDEN CnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAg d0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3Nl dF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2Vy IHNhdmUgb24gMS4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyBy ZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgw MDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0w eDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhj aV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQ b3dlciBzYXZlIG9uIDMuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4 YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4 PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVl c3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDIN CnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIw MDogU29tZSBVU0IgdHJhbnNmZXIgaXMgYWN0aXZlIG9uIDQuDQp1aGNpX3Jvb3Ro dWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0 IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6 MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9 MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0K dWhjaV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiA1Lg0KdWhjaV9y b290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4 MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9l eGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1Zh bHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgy OiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMS4NCnVo Y2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xl bj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3Ro dWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0 IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9yb290aHViX2V4ZWM6 MjUxNDogdHlwZT0weDIzIHJlcXVlc3Q9MHgwMSB3TGVuPTB4MDAwMCB3VmFsdWU9 MHgwMDEwIHdJbmRleD0weDAwMDINCnVoY2lfcm9vdGh1Yl9leGVjOjI2MjQ6IFVS X0NMRUFSX1BPUlRfRkVBVFVSRSBwb3J0PTIgZmVhdHVyZT0xNg0KdWhjaV9yb290 aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAw NCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfcm9vdGh1Yl9leGVj OjI1MTQ6IHR5cGU9MHgyMyByZXF1ZXN0PTB4MDMgd0xlbj0weDAwMDAgd1ZhbHVl PTB4MDAwNCB3SW5kZXg9MHgwMDAyDQp1aGNpX3BvcnRyZXNldDoyMzk2OiBBY3Rp dmF0aW5nIFNPRnMhDQp1aGNpX2ludGVycnVwdDogaG9zdCBzeXN0ZW0gZXJyb3IN CnVoY2lfaW50ZXJydXB0OjE0NjE6IHVoY2lfaW50ZXJydXB0OiBob3N0IGNvbnRy b2xsZXIgaGFsdGVkDQp1aGNpX2R1bXByZWdzOjY5NjogdXNidXMxIHJlZ3M6IGNt ZD0wMDgwLCBzdHM9MDAyOCwgaW50cj0wMDBmLCBmcm51bT0wMDEwLCBmbGJhc2U9 MDAwMDAwNDAsIHNvZj0wMDQwLCBwb3J0c2MxPTAwODAsIHBvcnRzYzI9MDE4MQ0K dWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmODAwKSBhdCAweDAx M2RmODAyOiBoX25leHQ9MHgwMTNkZjc4MiBlX25leHQ9MHgwMDAwMDAwMQ0KdWhj aV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNzgwKSBhdCAweDAxM2Rm NzgyOiBoX25leHQ9MHgwMTNkZjcwMiBlX25leHQ9MHgwMDAwMDAwMQ0KdWhjaV9k dW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNzAwKSBhdCAweDAxM2RmNzAy OiBoX25leHQ9MHgwMTNkZjY4MiBlX25leHQ9MHgwMDAwMDAwMQ0KdWhjaV9kdW1w X3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNjgwKSBhdCAweDAxM2RmNjgyOiBo X25leHQ9MHgwMDAwMDAwMSBlX25leHQ9MHgwMTNkZjYwMA0KdWhjaV9wb3J0cmVz ZXQ6MjQxMTogdWhjaSBwb3J0IDIgcmVzZXQsIHN0YXR1czAgPSAweDAyODANCnVo Y2lfcG9ydHJlc2V0OjI0Mjg6IHVoY2kgcG9ydCAyIHJlc2V0LCBzdGF0dXMxID0g MHgwMTgzDQp1aGNpX3BvcnRyZXNldDoyNDQxOiB1aGNpIHBvcnQgMiBpdGVyYXRp b24gMCwgc3RhdHVzID0gMHgwMTg3DQp1aGNpX3BvcnRyZXNldDoyNDQxOiB1aGNp IHBvcnQgMiBpdGVyYXRpb24gMSwgc3RhdHVzID0gMHgwMTg1DQp1aGNpX3BvcnRy ZXNldDoyNDc5OiB1aGNpIHBvcnQgMiByZXNldCwgc3RhdHVzMiA9IDB4MDE4NQ0K dWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3 TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfcm9v dGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHgyMyByZXF1ZXN0PTB4MDEgd0xlbj0weDAw MDAgd1ZhbHVlPTB4MDAxNCB3SW5kZXg9MHgwMDAyDQp1aGNpX3Jvb3RodWJfZXhl YzoyNjI0OiBVUl9DTEVBUl9QT1JUX0ZFQVRVUkUgcG9ydD0yIGZlYXR1cmU9MjAN CnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAg d0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3Bp cGVfaW5pdDozMDQzOiBwaXBlPTB4ZmZmZmZmMDAwMWEyMDhkOCwgYWRkcj0wLCBl bmRwdD0wLCBtb2RlPTAgKDEpDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVo Y2lfc2V0X2h3X3Bvd2VyOjMyMDA6IFNvbWUgVVNCIHRyYW5zZmVyIGlzIGFjdGl2 ZSBvbiAxLg0KdWhjaV9zZXR1cF9zdGFuZGFyZF9jaGFpbjoxNjY2OiBhZGRyPTAg ZW5kcHQ9MCBzdW1sZW49OCBzcGVlZD0xDQp1aGNpX3NldHVwX3N0YW5kYXJkX2No YWluOjE4Mjc6IG5leHR0b2c9MDsgZGF0YSBiZWZvcmUgdHJhbnNmZXI6DQpURCgw eGZmZmZmZjAwMDE2OGFkMDApIGF0IDB4MDE2OGFkMDQgPSBsaW5rPTB4MDAwMDAw MDEgc3RhdHVzPTB4MWQ4MDAzZmYgdG9rZW49MHgwMGUwMDAyZCBidWZmZXI9MHgy ODZmNjI2MA0KVEQoMHhmZmZmZmYwMDAxNjhhZDAwKSB0ZF9uZXh0PS1UIHRkX3N0 YXR1cz0tQUNUSVZFLUlPQy1MUywgZXJyY250PTMsIGFjdGxlbj0wIHBpZD0yZCxh ZGRyPTAsZW5kcHQ9MCxEPTAsbWF4bGVuPTgNCl91aGNpX2FwcGVuZF9xaDo5MjM6 IDB4ZmZmZmZmMDAwMWIzYWIwMCB0byAweGZmZmZmZjAwMDEzZGY4MDANCnVoY2lf Y2hlY2tfdHJhbnNmZXI6MTM5MTogeGZlcj0weGZmZmZmZmZlNDA2ZjYxNDggaXMg c3RpbGwgYWN0aXZlDQp1aGNpX2ludGVycnVwdDogaG9zdCBzeXN0ZW0gZXJyb3IN CnVoY2lfaW50ZXJydXB0OjE0NjE6IHVoY2lfaW50ZXJydXB0OiBob3N0IGNvbnRy b2xsZXIgaGFsdGVkDQp1aGNpX2R1bXByZWdzOjY5NjogdXNidXMxIHJlZ3M6IGNt ZD0wMDgwLCBzdHM9MDAyOCwgaW50cj0wMDBmLCBmcm51bT0wMDEwLCBmbGJhc2U9 MDAwMDAwNDAsIHNvZj0wMDQwLCBwb3J0c2MxPTAwODAsIHBvcnRzYzI9MDE4NQ0K dWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxYjNhYjAwKSBhdCAweDAx YjNhYjAyOiBoX25leHQ9MHgwMTNkZjc4MiBlX25leHQ9MHgwMTY4YWQwNA0KdWhj aV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNzgwKSBhdCAweDAxM2Rm NzgyOiBoX25leHQ9MHgwMTNkZjcwMiBlX25leHQ9MHgwMDAwMDAwMQ0KdWhjaV9k dW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNzAwKSBhdCAweDAxM2RmNzAy OiBoX25leHQ9MHgwMTNkZjY4MiBlX25leHQ9MHgwMDAwMDAwMQ0KdWhjaV9kdW1w X3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNjgwKSBhdCAweDAxM2RmNjgyOiBo X25leHQ9MHgwMDAwMDAwMSBlX25leHQ9MHgwMTNkZjYwMA0KdWhjaV9jaGVja190 cmFuc2ZlcjoxMzkxOiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCBpcyBzdGlsbCBh Y3RpdmUNCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93 ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAwLg0KdWhjaV9yb290aHViX2V4ZWM6MjUx NDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgw MDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9 MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5k ZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3 X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMy4NCnVoY2lfcm9vdGh1Yl9leGVj OjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVl PTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0 eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAg d0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3Nl dF9od19wb3dlcjozMjAwOiBTb21lIFVTQiB0cmFuc2ZlciBpcyBhY3RpdmUgb24g NC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4 MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNp X3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49 MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdf cG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZl IG9uIDUuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVz dD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0K dWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3 TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfdGlt ZW91dDoxNDk4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OA0KdWhjaV9kZXZpY2Vf ZG9uZToxODQ4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCwgcGlwZT0weGZmZmZm ZjAwMDFhMjA4ZDgsIGVycm9yPTIwDQpfdWhjaV9yZW1vdmVfcWg6OTc5OiAweGZm ZmZmZjAwMDFiM2FiMDAgZnJvbSAweGZmZmZmZjAwMDFiM2FiMDANCnVoY2lfZGV2 aWNlX2RvbmU6MTg0ODogeGZlcj0weGZmZmZmZmZlNDA2ZjYxNDgsIHBpcGU9MHhm ZmZmZmYwMDAxYTIwOGQ4LCBlcnJvcj01DQpfdWhjaV9yZW1vdmVfcWg6OTc5OiAw eGZmZmZmZjAwMDFiM2FiMDAgZnJvbSAweGZmZmZmZjAwMDEzZGY4MDANCnVzYjJf YWxsb2NfZGV2aWNlOjE1NzQ6IHNldCBhZGRyZXNzIDIgZmFpbGVkIChVU0JfRVJS X1RJTUVPVVQsIGlnbm9yZWQpDQp1aGNpX3NldHVwX3N0YW5kYXJkX2NoYWluOjE2 NjY6IGFkZHI9MiBlbmRwdD0wIHN1bWxlbj0xNiBzcGVlZD0xDQp1aGNpX3NldHVw X3N0YW5kYXJkX2NoYWluOjE4Mjc6IG5leHR0b2c9MDsgZGF0YSBiZWZvcmUgdHJh bnNmZXI6DQpURCgweGZmZmZmZjAwMDE2OGFkMDApIGF0IDB4MDE2OGFkMDQgPSBs aW5rPTB4MDE2OGFjYzQgc3RhdHVzPTB4MWM4MDAzZmYgdG9rZW49MHgwMGUwMDIy ZCBidWZmZXI9MHgyODZmNjI2MA0KVEQoMHhmZmZmZmYwMDAxNjhhZDAwKSB0ZF9u ZXh0PS1WRiB0ZF9zdGF0dXM9LUFDVElWRS1MUywgZXJyY250PTMsIGFjdGxlbj0w IHBpZD0yZCxhZGRyPTIsZW5kcHQ9MCxEPTAsbWF4bGVuPTgNClREKDB4ZmZmZmZm MDAwMTY4YWNjMCkgYXQgMHgwMTY4YWNjNCA9IGxpbms9MHgwMTY4YWM4NCBzdGF0 dXM9MHgzYzgwMDNmZiB0b2tlbj0weDAwZTgwMjY5IGJ1ZmZlcj0weDI4NmY2MjY4 DQpURCgweGZmZmZmZjAwMDE2OGFjYzApIHRkX25leHQ9LVZGIHRkX3N0YXR1cz0t QUNUSVZFLUxTLVNQRCwgZXJyY250PTMsIGFjdGxlbj0wIHBpZD02OSxhZGRyPTIs ZW5kcHQ9MCxEPTEsbWF4bGVuPTgNClREKDB4ZmZmZmZmMDAwMTY4YWM4MCkgYXQg MHgwMTY4YWM4NCA9IGxpbms9MHgwMDAwMDAwMSBzdGF0dXM9MHgxZDgwMDNmZiB0 b2tlbj0weGZmZTgwMmUxIGJ1ZmZlcj0weDAwMDAwMDAwDQpURCgweGZmZmZmZjAw MDE2OGFjODApIHRkX25leHQ9LVQgdGRfc3RhdHVzPS1BQ1RJVkUtSU9DLUxTLCBl cnJjbnQ9MywgYWN0bGVuPTAgcGlkPWUxLGFkZHI9MixlbmRwdD0wLEQ9MSxtYXhs ZW49MA0KX3VoY2lfYXBwZW5kX3FoOjkyMzogMHhmZmZmZmYwMDAxZDQwNDgwIHRv IDB4ZmZmZmZmMDAwMTNkZjgwMA0KdWhjaV9jaGVja190cmFuc2ZlcjoxMzkxOiB4 ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCBpcyBzdGlsbCBhY3RpdmUNCnVoY2lfdGlt ZW91dDoxNDk4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OA0KdWhjaV9kZXZpY2Vf ZG9uZToxODQ4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCwgcGlwZT0weGZmZmZm ZjAwMDFhMjA4ZDgsIGVycm9yPTIwDQpfdWhjaV9yZW1vdmVfcWg6OTc5OiAweGZm ZmZmZjAwMDFkNDA0ODAgZnJvbSAweGZmZmZmZjAwMDFkNDA0ODANCnVoY2lfZGV2 aWNlX2RvbmU6MTg0ODogeGZlcj0weGZmZmZmZmZlNDA2ZjYxNDgsIHBpcGU9MHhm ZmZmZmYwMDAxYTIwOGQ4LCBlcnJvcj01DQpfdWhjaV9yZW1vdmVfcWg6OTc5OiAw eGZmZmZmZjAwMDFkNDA0ODAgZnJvbSAweGZmZmZmZjAwMDEzZGY4MDANCnVzYjJf YWxsb2NfZGV2aWNlOjE2MTI6IGdldHRpbmcgZGV2aWNlIGRlc2NyaXB0b3IgYXQg YWRkciAyIGZhaWxlZCwgVVNCX0VSUl9USU1FT1VUIQ0KdWhjaV9yb290aHViX2V4 ZWM6MjUxNDogdHlwZT0weDIzIHJlcXVlc3Q9MHgwMyB3TGVuPTB4MDAwMCB3VmFs dWU9MHgwMDA0IHdJbmRleD0weDAwMDINCnVoY2lfcG9ydHJlc2V0OjIzOTY6IEFj dGl2YXRpbmcgU09GcyENCnVoY2lfaW50ZXJydXB0OiBob3N0IHN5c3RlbSBlcnJv cg0KdWhjaV9pbnRlcnJ1cHQ6MTQ2MTogdWhjaV9pbnRlcnJ1cHQ6IGhvc3QgY29u dHJvbGxlciBoYWx0ZWQNCnVoY2lfZHVtcHJlZ3M6Njk2OiB1c2J1czEgcmVnczog Y21kPTAwODAsIHN0cz0wMDI4LCBpbnRyPTAwMGYsIGZybnVtPTAwMTAsIGZsYmFz ZT0wMDAwMDA0MCwgc29mPTAwNDAsIHBvcnRzYzE9MDA4MCwgcG9ydHNjMj0wMTg1 DQp1aGNpX2R1bXBfcWg6NzY5OiBRSCgweGZmZmZmZjAwMDEzZGY4MDApIGF0IDB4 MDEzZGY4MDI6IGhfbmV4dD0weDAxM2RmNzgyIGVfbmV4dD0weDAwMDAwMDAxDQp1 aGNpX2R1bXBfcWg6NzY5OiBRSCgweGZmZmZmZjAwMDEzZGY3ODApIGF0IDB4MDEz ZGY3ODI6IGhfbmV4dD0weDAxM2RmNzAyIGVfbmV4dD0weDAwMDAwMDAxDQp1aGNp X2R1bXBfcWg6NzY5OiBRSCgweGZmZmZmZjAwMDEzZGY3MDApIGF0IDB4MDEzZGY3 MDI6IGhfbmV4dD0weDAxM2RmNjgyIGVfbmV4dD0weDAwMDAwMDAxDQp1aGNpX2R1 bXBfcWg6NzY5OiBRSCgweGZmZmZmZjAwMDEzZGY2ODApIGF0IDB4MDEzZGY2ODI6 IGhfbmV4dD0weDAwMDAwMDAxIGVfbmV4dD0weDAxM2RmNjAwDQp1aGNpX3BvcnRy ZXNldDoyNDExOiB1aGNpIHBvcnQgMiByZXNldCwgc3RhdHVzMCA9IDB4MDI4OA0K dWhjaV9wb3J0cmVzZXQ6MjQyODogdWhjaSBwb3J0IDIgcmVzZXQsIHN0YXR1czEg PSAweDAxOGINCnVoY2lfcG9ydHJlc2V0OjI0NDE6IHVoY2kgcG9ydCAyIGl0ZXJh dGlvbiAwLCBzdGF0dXMgPSAweDAxOGYNCnVoY2lfcG9ydHJlc2V0OjI0NDE6IHVo Y2kgcG9ydCAyIGl0ZXJhdGlvbiAxLCBzdGF0dXMgPSAweDAxODUNCnVoY2lfcG9y dHJlc2V0OjI0Nzk6IHVoY2kgcG9ydCAyIHJlc2V0LCBzdGF0dXMyID0gMHgwMTg1 DQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAw IHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9y b290aHViX2V4ZWM6MjUxNDogdHlwZT0weDIzIHJlcXVlc3Q9MHgwMSB3TGVuPTB4 MDAwMCB3VmFsdWU9MHgwMDE0IHdJbmRleD0weDAwMDINCnVoY2lfcm9vdGh1Yl9l eGVjOjI2MjQ6IFVSX0NMRUFSX1BPUlRfRkVBVFVSRSBwb3J0PTIgZmVhdHVyZT0y MA0KdWhjaV9zZXR1cF9zdGFuZGFyZF9jaGFpbjoxNjY2OiBhZGRyPTAgZW5kcHQ9 MCBzdW1sZW49OCBzcGVlZD0xDQp1aGNpX3NldHVwX3N0YW5kYXJkX2NoYWluOjE4 Mjc6IG5leHR0b2c9MDsgZGF0YSBiZWZvcmUgdHJhbnNmZXI6DQpURCgweGZmZmZm ZjAwMDE3MTcxMDApIGF0IDB4MDE3MTcxMDQgPSBsaW5rPTB4MDAwMDAwMDEgc3Rh dHVzPTB4MWQ4MDAzZmYgdG9rZW49MHgwMGUwMDAyZCBidWZmZXI9MHgyODZmNjI2 MA0KVEQoMHhmZmZmZmYwMDAxNzE3MTAwKSB0ZF9uZXh0PS1UIHRkX3N0YXR1cz0t QUNUSVZFLUlPQy1MUywgZXJyY250PTMsIGFjdGxlbj0wIHBpZD0yZCxhZGRyPTAs ZW5kcHQ9MCxEPTAsbWF4bGVuPTgNCl91aGNpX2FwcGVuZF9xaDo5MjM6IDB4ZmZm ZmZmMDAwMWQ0MTM4MCB0byAweGZmZmZmZjAwMDEzZGY4MDANCnVoY2lfY2hlY2tf dHJhbnNmZXI6MTM5MTogeGZlcj0weGZmZmZmZmZlNDA2ZjYxNDggaXMgc3RpbGwg YWN0aXZlDQp1aGNpX3RpbWVvdXQ6MTQ5ODogeGZlcj0weGZmZmZmZmZlNDA2ZjYx NDgNCnVoY2lfZGV2aWNlX2RvbmU6MTg0ODogeGZlcj0weGZmZmZmZmZlNDA2ZjYx NDgsIHBpcGU9MHhmZmZmZmYwMDAxYTIwOGQ4LCBlcnJvcj0yMA0KX3VoY2lfcmVt b3ZlX3FoOjk3OTogMHhmZmZmZmYwMDAxZDQxMzgwIGZyb20gMHhmZmZmZmYwMDAx ZDQxMzgwDQp1aGNpX2RldmljZV9kb25lOjE4NDg6IHhmZXI9MHhmZmZmZmZmZTQw NmY2MTQ4LCBwaXBlPTB4ZmZmZmZmMDAwMWEyMDhkOCwgZXJyb3I9NQ0KX3VoY2lf cmVtb3ZlX3FoOjk3OTogMHhmZmZmZmYwMDAxZDQxMzgwIGZyb20gMHhmZmZmZmYw MDAxM2RmODAwDQp1c2IyX3JlcV9yZV9lbnVtZXJhdGU6MTUxOTogYWRkcj0yLCBz ZXQgYWRkcmVzcyBmYWlsZWQhIChVU0JfRVJSX1RJTUVPVVQsIGlnbm9yZWQpDQp1 aGNpX3NldHVwX3N0YW5kYXJkX2NoYWluOjE2NjY6IGFkZHI9MiBlbmRwdD0wIHN1 bWxlbj0xNiBzcGVlZD0xDQp1aGNpX3NldHVwX3N0YW5kYXJkX2NoYWluOjE4Mjc6 IG5leHR0b2c9MDsgZGF0YSBiZWZvcmUgdHJhbnNmZXI6DQpURCgweGZmZmZmZjAw MDEzZWU5MDApIGF0IDB4MDEzZWU5MDQgPSBsaW5rPTB4MDEzZWU4YzQgc3RhdHVz PTB4MWM4MDAzZmYgdG9rZW49MHgwMGUwMDIyZCBidWZmZXI9MHgyODZmNjI2MA0K VEQoMHhmZmZmZmYwMDAxM2VlOTAwKSB0ZF9uZXh0PS1WRiB0ZF9zdGF0dXM9LUFD VElWRS1MUywgZXJyY250PTMsIGFjdGxlbj0wIHBpZD0yZCxhZGRyPTIsZW5kcHQ9 MCxEPTAsbWF4bGVuPTgNClREKDB4ZmZmZmZmMDAwMTNlZThjMCkgYXQgMHgwMTNl ZThjNCA9IGxpbms9MHgwMTNlZTg4NCBzdGF0dXM9MHgzYzgwMDNmZiB0b2tlbj0w eDAwZTgwMjY5IGJ1ZmZlcj0weDI4NmY2MjY4DQpURCgweGZmZmZmZjAwMDEzZWU4 YzApIHRkX25leHQ9LVZGIHRkX3N0YXR1cz0tQUNUSVZFLUxTLVNQRCwgZXJyY250 PTMsIGFjdGxlbj0wIHBpZD02OSxhZGRyPTIsZW5kcHQ9MCxEPTEsbWF4bGVuPTgN ClREKDB4ZmZmZmZmMDAwMTNlZTg4MCkgYXQgMHgwMTNlZTg4NCA9IGxpbms9MHgw MDAwMDAwMSBzdGF0dXM9MHgxZDgwMDNmZiB0b2tlbj0weGZmZTgwMmUxIGJ1ZmZl cj0weDAwMDAwMDAwDQpURCgweGZmZmZmZjAwMDEzZWU4ODApIHRkX25leHQ9LVQg dGRfc3RhdHVzPS1BQ1RJVkUtSU9DLUxTLCBlcnJjbnQ9MywgYWN0bGVuPTAgcGlk PWUxLGFkZHI9MixlbmRwdD0wLEQ9MSxtYXhsZW49MA0KX3VoY2lfYXBwZW5kX3Fo OjkyMzogMHhmZmZmZmYwMDAxZDQxMjgwIHRvIDB4ZmZmZmZmMDAwMTNkZjgwMA0K dWhjaV9jaGVja190cmFuc2ZlcjoxMzkxOiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0 OCBpcyBzdGlsbCBhY3RpdmUNCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhj aV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAwLg0KdWhjaV9yb290 aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAw NCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVj OjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVl PTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiAN CnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMy4NCnVoY2lf cm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0w eDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJf ZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdW YWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4 MjogDQp1aGNpX3NldF9od19wb3dlcjozMjAwOiBTb21lIFVTQiB0cmFuc2ZlciBp cyBhY3RpdmUgb24gNC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhh MyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9 MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVz dD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0K dWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0 OiBQb3dlciBzYXZlIG9uIDUuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBl PTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0lu ZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJl cXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAw MDINCnVoY2lfdGltZW91dDoxNDk4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OA0K dWhjaV9kZXZpY2VfZG9uZToxODQ4OiB4ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCwg cGlwZT0weGZmZmZmZjAwMDFhMjA4ZDgsIGVycm9yPTIwDQpfdWhjaV9yZW1vdmVf cWg6OTc5OiAweGZmZmZmZjAwMDFkNDEyODAgZnJvbSAweGZmZmZmZjAwMDFkNDEy ODANCnVoY2lfZGV2aWNlX2RvbmU6MTg0ODogeGZlcj0weGZmZmZmZmZlNDA2ZjYx NDgsIHBpcGU9MHhmZmZmZmYwMDAxYTIwOGQ4LCBlcnJvcj01DQpfdWhjaV9yZW1v dmVfcWg6OTc5OiAweGZmZmZmZjAwMDFkNDEyODAgZnJvbSAweGZmZmZmZjAwMDEz ZGY4MDANCnVzYjJfcmVxX3JlX2VudW1lcmF0ZToxNTMzOiBnZXR0aW5nIGRldmlj ZSBkZXNjcmlwdG9yIGF0IGFkZHIgMiBmYWlsZWQsIFVTQl9FUlJfVElNRU9VVCEN CnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHgyMyByZXF1ZXN0PTB4MDMg d0xlbj0weDAwMDAgd1ZhbHVlPTB4MDAwNCB3SW5kZXg9MHgwMDAyDQp1aGNpX3Bv cnRyZXNldDoyMzk2OiBBY3RpdmF0aW5nIFNPRnMhDQp1aGNpX2ludGVycnVwdDog aG9zdCBzeXN0ZW0gZXJyb3INCnVoY2lfaW50ZXJydXB0OjE0NjE6IHVoY2lfaW50 ZXJydXB0OiBob3N0IGNvbnRyb2xsZXIgaGFsdGVkDQp1aGNpX2R1bXByZWdzOjY5 NjogdXNidXMxIHJlZ3M6IGNtZD0wMDgwLCBzdHM9MDAyOCwgaW50cj0wMDBmLCBm cm51bT0wMDEwLCBmbGJhc2U9MDAwMDAwNDAsIHNvZj0wMDQwLCBwb3J0c2MxPTAw ODAsIHBvcnRzYzI9MDE4NQ0KdWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYw MDAxM2RmODAwKSBhdCAweDAxM2RmODAyOiBoX25leHQ9MHgwMTNkZjc4MiBlX25l eHQ9MHgwMDAwMDAwMQ0KdWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAx M2RmNzgwKSBhdCAweDAxM2RmNzgyOiBoX25leHQ9MHgwMTNkZjcwMiBlX25leHQ9 MHgwMDAwMDAwMQ0KdWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2Rm NzAwKSBhdCAweDAxM2RmNzAyOiBoX25leHQ9MHgwMTNkZjY4MiBlX25leHQ9MHgw MDAwMDAwMQ0KdWhjaV9kdW1wX3FoOjc2OTogUUgoMHhmZmZmZmYwMDAxM2RmNjgw KSBhdCAweDAxM2RmNjgyOiBoX25leHQ9MHgwMDAwMDAwMSBlX25leHQ9MHgwMTNk ZjYwMA0KdWhjaV9wb3J0cmVzZXQ6MjQxMTogdWhjaSBwb3J0IDIgcmVzZXQsIHN0 YXR1czAgPSAweDAyODgNCnVoY2lfcG9ydHJlc2V0OjI0Mjg6IHVoY2kgcG9ydCAy IHJlc2V0LCBzdGF0dXMxID0gMHgwMThiDQp1aGNpX3BvcnRyZXNldDoyNDQxOiB1 aGNpIHBvcnQgMiBpdGVyYXRpb24gMCwgc3RhdHVzID0gMHgwMThmDQp1aGNpX3Bv cnRyZXNldDoyNDQxOiB1aGNpIHBvcnQgMiBpdGVyYXRpb24gMSwgc3RhdHVzID0g MHgwMTg1DQp1aGNpX3BvcnRyZXNldDoyNDc5OiB1aGNpIHBvcnQgMiByZXNldCwg c3RhdHVzMiA9IDB4MDE4NQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0w eGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRl eD0weDAwMDINCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHgyMyByZXF1 ZXN0PTB4MDEgd0xlbj0weDAwMDAgd1ZhbHVlPTB4MDAxNCB3SW5kZXg9MHgwMDAy DQp1aGNpX3Jvb3RodWJfZXhlYzoyNjI0OiBVUl9DTEVBUl9QT1JUX0ZFQVRVUkUg cG9ydD0yIGZlYXR1cmU9MjANCnVoY2lfc2V0dXBfc3RhbmRhcmRfY2hhaW46MTY2 NjogYWRkcj0wIGVuZHB0PTAgc3VtbGVuPTggc3BlZWQ9MQ0KdWhjaV9zZXR1cF9z dGFuZGFyZF9jaGFpbjoxODI3OiBuZXh0dG9nPTA7IGRhdGEgYmVmb3JlIHRyYW5z ZmVyOg0KVEQoMHhmZmZmZmYwMDAxM2YwNTAwKSBhdCAweDAxM2YwNTA0ID0gbGlu az0weDAwMDAwMDAxIHN0YXR1cz0weDFkODAwM2ZmIHRva2VuPTB4MDBlMDAwMmQg YnVmZmVyPTB4Mjg2ZjYyNjANClREKDB4ZmZmZmZmMDAwMTNmMDUwMCkgdGRfbmV4 dD0tVCB0ZF9zdGF0dXM9LUFDVElWRS1JT0MtTFMsIGVycmNudD0zLCBhY3RsZW49 MCBwaWQ9MmQsYWRkcj0wLGVuZHB0PTAsRD0wLG1heGxlbj04DQpfdWhjaV9hcHBl bmRfcWg6OTIzOiAweGZmZmZmZjAwMDFkNDAyMDAgdG8gMHhmZmZmZmYwMDAxM2Rm ODAwDQp1aGNpX2NoZWNrX3RyYW5zZmVyOjEzOTE6IHhmZXI9MHhmZmZmZmZmZTQw NmY2MTQ4IGlzIHN0aWxsIGFjdGl2ZQ0KdWhjaV90aW1lb3V0OjE0OTg6IHhmZXI9 MHhmZmZmZmZmZTQwNmY2MTQ4DQp1aGNpX2RldmljZV9kb25lOjE4NDg6IHhmZXI9 MHhmZmZmZmZmZTQwNmY2MTQ4LCBwaXBlPTB4ZmZmZmZmMDAwMWEyMDhkOCwgZXJy b3I9MjANCl91aGNpX3JlbW92ZV9xaDo5Nzk6IDB4ZmZmZmZmMDAwMWQ0MDIwMCBm cm9tIDB4ZmZmZmZmMDAwMWQ0MDIwMA0KdWhjaV9kZXZpY2VfZG9uZToxODQ4OiB4 ZmVyPTB4ZmZmZmZmZmU0MDZmNjE0OCwgcGlwZT0weGZmZmZmZjAwMDFhMjA4ZDgs IGVycm9yPTUNCl91aGNpX3JlbW92ZV9xaDo5Nzk6IDB4ZmZmZmZmMDAwMWQ0MDIw MCBmcm9tIDB4ZmZmZmZmMDAwMTNkZjgwMA0KdXNiMl9yZXFfcmVfZW51bWVyYXRl OjE1MTk6IGFkZHI9Miwgc2V0IGFkZHJlc3MgZmFpbGVkISAoVVNCX0VSUl9USU1F T1VULCBpZ25vcmVkKQ0KdWhjaV9zZXR1cF9zdGFuZGFyZF9jaGFpbjoxNjY2OiBh ZGRyPTIgZW5kcHQ9MCBzdW1sZW49MTYgc3BlZWQ9MQ0KdWhjaV9zZXR1cF9zdGFu ZGFyZF9jaGFpbjoxODI3OiBuZXh0dG9nPTA7IGRhdGEgYmVmb3JlIHRyYW5zZmVy Og0KVEQoMHhmZmZmZmYwMDAxNDQwMTAwKSBhdCAweDAxNDQwMTA0ID0gbGluaz0w eDAxNDQwMGM0IHN0YXR1cz0weDFjODAwM2ZmIHRva2VuPTB4MDBlMDAyMmQgYnVm ZmVyPTB4Mjg2ZjYyNjANClREKDB4ZmZmZmZmMDAwMTQ0MDEwMCkgdGRfbmV4dD0t VkYgdGRfc3RhdHVzPS1BQ1RJVkUtTFMsIGVycmNudD0zLCBhY3RsZW49MCBwaWQ9 MmQsYWRkcj0yLGVuZHB0PTAsRD0wLG1heGxlbj04DQpURCgweGZmZmZmZjAwMDE0 NDAwYzApIGF0IDB4MDE0NDAwYzQgPSBsaW5rPTB4MDE0NDAwODQgc3RhdHVzPTB4 M2M4MDAzZmYgdG9rZW49MHgwMGU4MDI2OSBidWZmZXI9MHgyODZmNjI2OA0KVEQo MHhmZmZmZmYwMDAxNDQwMGMwKSB0ZF9uZXh0PS1WRiB0ZF9zdGF0dXM9LUFDVElW RS1MUy1TUEQsIGVycmNudD0zLCBhY3RsZW49MCBwaWQ9NjksYWRkcj0yLGVuZHB0 PTAsRD0xLG1heGxlbj04DQpURCgweGZmZmZmZjAwMDE0NDAwODApIGF0IDB4MDE0 NDAwODQgPSBsaW5rPTB4MDAwMDAwMDEgc3RhdHVzPTB4MWQ4MDAzZmYgdG9rZW49 MHhmZmU4MDJlMSBidWZmZXI9MHgwMDAwMDAwMA0KVEQoMHhmZmZmZmYwMDAxNDQw MDgwKSB0ZF9uZXh0PS1UIHRkX3N0YXR1cz0tQUNUSVZFLUlPQy1MUywgZXJyY250 PTMsIGFjdGxlbj0wIHBpZD1lMSxhZGRyPTIsZW5kcHQ9MCxEPTEsbWF4bGVuPTAN Cl91aGNpX2FwcGVuZF9xaDo5MjM6IDB4ZmZmZmZmMDAwMWIzYWM4MCB0byAweGZm ZmZmZjAwMDEzZGY4MDANCnVoY2lfY2hlY2tfdHJhbnNmZXI6MTM5MTogeGZlcj0w eGZmZmZmZmZlNDA2ZjYxNDggaXMgc3RpbGwgYWN0aXZlDQp1aGNpX3NldF9od19w b3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUg b24gMC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0 PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1 aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdM ZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRf aHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBz YXZlIG9uIDMuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVx dWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAw MQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgw MCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lf c2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwMDogU29t ZSBVU0IgdHJhbnNmZXIgaXMgYWN0aXZlIG9uIDQuDQp1aGNpX3Jvb3RodWJfZXhl YzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1 ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDog dHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAw IHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9z ZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiA1Lg0KdWhjaV9yb290aHVi X2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3 VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1 MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4 MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3RpbWVvdXQ6MTQ5ODogeGZlcj0weGZm ZmZmZmZlNDA2ZjYxNDgNCnVoY2lfZGV2aWNlX2RvbmU6MTg0ODogeGZlcj0weGZm ZmZmZmZlNDA2ZjYxNDgsIHBpcGU9MHhmZmZmZmYwMDAxYTIwOGQ4LCBlcnJvcj0y MA0KX3VoY2lfcmVtb3ZlX3FoOjk3OTogMHhmZmZmZmYwMDAxYjNhYzgwIGZyb20g MHhmZmZmZmYwMDAxYjNhYzgwDQp1aGNpX2RldmljZV9kb25lOjE4NDg6IHhmZXI9 MHhmZmZmZmZmZTQwNmY2MTQ4LCBwaXBlPTB4ZmZmZmZmMDAwMWEyMDhkOCwgZXJy b3I9NQ0KX3VoY2lfcmVtb3ZlX3FoOjk3OTogMHhmZmZmZmYwMDAxYjNhYzgwIGZy b20gMHhmZmZmZmYwMDAxM2RmODAwDQp1c2IyX3JlcV9yZV9lbnVtZXJhdGU6MTUz MzogZ2V0dGluZyBkZXZpY2UgZGVzY3JpcHRvciBhdCBhZGRyIDIgZmFpbGVkLCBV U0JfRVJSX1RJTUVPVVQhDQp1Z2VuMS4yOiA8PiBhdCB1c2J1czEgKGRpc2Nvbm5l Y3RlZCkNCnVodWJfcmVhdHRhY2hfcG9ydDo0MTc6IGNvdWxkIG5vdCBhbGxvY2F0 ZSBuZXcgZGV2aWNlIQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weDIz IHJlcXVlc3Q9MHgwMSB3TGVuPTB4MDAwMCB3VmFsdWU9MHgwMDAxIHdJbmRleD0w eDAwMDINCnVoY2lfcm9vdGh1Yl9leGVjOjI2MjQ6IFVSX0NMRUFSX1BPUlRfRkVB VFVSRSBwb3J0PTIgZmVhdHVyZT0xDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiAN CnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMS4NCnVoY2lf cm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0w eDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJf ZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdW YWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4 MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDAuDQp1 aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdM ZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290 aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAw NCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2Vy OjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAx Lg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgw MCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lf cm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0w eDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19w b3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUg b24gMy4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0 PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1 aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdM ZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRf aHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjAwOiBTb21lIFVT QiB0cmFuc2ZlciBpcyBhY3RpdmUgb24gNC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1 MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4 MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBl PTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0lu ZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9o d19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDUuDQp1aGNpX3Jvb3RodWJfZXhl YzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1 ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDog dHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAw IHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9z ZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAwLg0KdWhjaV9yb290aHVi X2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3 VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1 MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4 MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVo Y2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMS4NCnVoY2lfcm9v dGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAw MDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhl YzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1 ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4Mjog DQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDMuDQp1aGNp X3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49 MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHVi X2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3 VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMx ODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwMDogU29tZSBVU0IgdHJhbnNmZXIg aXMgYWN0aXZlIG9uIDQuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4 YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4 PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVl c3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDIN CnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIw NDogUG93ZXIgc2F2ZSBvbiA1Lg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlw ZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJ bmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyBy ZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgw MDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2Vy OjMyMDQ6IFBvd2VyIHNhdmUgb24gMC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6 IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAw MCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4 YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4 PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19w b3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDEuDQp1aGNpX3Jvb3RodWJfZXhlYzoy NTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0w eDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlw ZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJ bmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRf aHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAzLg0KdWhjaV9yb290aHViX2V4 ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFs dWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6 IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAw MCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lf c2V0X2h3X3Bvd2VyOjMyMDA6IFNvbWUgVVNCIHRyYW5zZmVyIGlzIGFjdGl2ZSBv biA0Lg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9 MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVo Y2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xl bj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9o d19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNh dmUgb24gNS4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1 ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAx DQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAw IHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9z ZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dl ciBzYXZlIG9uIDEuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMg cmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4 MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9 MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVo Y2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHgyMyByZXF1ZXN0PTB4MDEgd0xl bj0weDAwMDAgd1ZhbHVlPTB4MDAxMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3Jvb3Ro dWJfZXhlYzoyNjI0OiBVUl9DTEVBUl9QT1JUX0ZFQVRVUkUgcG9ydD0yIGZlYXR1 cmU9MTYNCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0 PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1 aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6 IFBvd2VyIHNhdmUgb24gMC4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9 MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5k ZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVx dWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAw Mg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjoz MjA0OiBQb3dlciBzYXZlIG9uIDEuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0 eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAg d0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEz IHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0w eDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93 ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAzLg0KdWhjaV9yb290aHViX2V4ZWM6MjUx NDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgw MDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9 MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5k ZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3 X3Bvd2VyOjMyMDA6IFNvbWUgVVNCIHRyYW5zZmVyIGlzIGFjdGl2ZSBvbiA0Lg0K dWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3 TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9v dGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAw MDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dl cjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24g NS4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4 MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNp X3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49 MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdf cG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZl IG9uIDAuDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVz dD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0K dWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3 TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0 X2h3X3Bvd2VyOjMxODI6IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIg c2F2ZSBvbiAxLg0KdWhjaV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJl cXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAw MDENCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4 MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNp X3NldF9od19wb3dlcjozMTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBv d2VyIHNhdmUgb24gMy4NCnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhh MyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9 MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVz dD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMg0K dWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1aGNpX3NldF9od19wb3dlcjozMjAw OiBTb21lIFVTQiB0cmFuc2ZlciBpcyBhY3RpdmUgb24gNC4NCnVoY2lfcm9vdGh1 Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQg d1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jvb3RodWJfZXhlYzoy NTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgwMDA0IHdWYWx1ZT0w eDAwMDAgd0luZGV4PTB4MDAwMg0KdWhjaV9zZXRfaHdfcG93ZXI6MzE4MjogDQp1 aGNpX3NldF9od19wb3dlcjozMjA0OiBQb3dlciBzYXZlIG9uIDUuDQp1aGNpX3Jv b3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgw MDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMQ0KdWhjaV9yb290aHViX2V4 ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVuPTB4MDAwNCB3VmFs dWU9MHgwMDAwIHdJbmRleD0weDAwMDINCnVoY2lfc2V0X2h3X3Bvd2VyOjMxODI6 IA0KdWhjaV9zZXRfaHdfcG93ZXI6MzIwNDogUG93ZXIgc2F2ZSBvbiAwLg0KdWhj aV9yb290aHViX2V4ZWM6MjUxNDogdHlwZT0weGEzIHJlcXVlc3Q9MHgwMCB3TGVu PTB4MDAwNCB3VmFsdWU9MHgwMDAwIHdJbmRleD0weDAwMDENCnVoY2lfcm9vdGh1 Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAgd0xlbj0weDAwMDQg d1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAyDQp1aGNpX3NldF9od19wb3dlcjoz MTgyOiANCnVoY2lfc2V0X2h3X3Bvd2VyOjMyMDQ6IFBvd2VyIHNhdmUgb24gMS4N CnVoY2lfcm9vdGh1Yl9leGVjOjI1MTQ6IHR5cGU9MHhhMyByZXF1ZXN0PTB4MDAg d0xlbj0weDAwMDQgd1ZhbHVlPTB4MDAwMCB3SW5kZXg9MHgwMDAxDQp1aGNpX3Jv b3RodWJfZXhlYzoyNTE0OiB0eXBlPTB4YTMgcmVxdWVzdD0weDAwIHdMZW49MHgw MDA0IHdWYWx1ZT0weDAwMDAgd0luZGV4PTB4MDAwMgA= ------------MzLPzOZYrxSwTrFHiE6WCq-- From owner-freebsd-current@FreeBSD.ORG Tue May 5 09:19: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 6A8CC106564A; Tue, 5 May 2009 09:19:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id EFC3C8FC17; Tue, 5 May 2009 09:19:18 +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 mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n459JFEW001664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 19:19:16 +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 n459JF5F094733; Tue, 5 May 2009 19:19:15 +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 n459JFr9094732; Tue, 5 May 2009 19:19:15 +1000 (EST) (envelope-from peter) Date: Tue, 5 May 2009 19:19:14 +1000 From: Peter Jeremy To: Alexander Motin Message-ID: <20090505091914.GA94521@server.vk2pj.dyndns.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <49FE5EC8.3040205@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 09:19:19 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-04 06:19:36 +0300, Alexander Motin wrote: >System will always have tons of waiting callouts and timeouts to be=20 >handled. So timer will be always needed. Working timer. Yes, but a tickless kernel will let the CPU stay asleep for longer since it doesn't need to wake up just to discover there's nothing to do. >number of idle disk write activity, but I haven't very succeeded. Even=20 >in my quite simple icewm X environment something was persistently=20 >writing something every several minutes. I have found and disabled some=20 >activity sources, but it was not enough. I've recently (in the last few days) worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes I made were: 1) Mount the SSD filesystems as noatime 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). 3) Change maillog rotation to size instead of daily 4) Run save-entropy once per hour instead of every 11 minutes. 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp By default, ntpd updates ntp.drift every hour. I might do some monitoring and see if the drift changes significantly over time. If it doesn't, hard-wiring the ntp.drift file will save some writes. (The other option would be to tweak the relevant timecounter until the actual drift is 0 and then stop ntpd and just run something like ntpdate regularly to compensate for the remaining drift). Experimentation shows that firefox3 generates a fairly heavy write load - continuously updating several internal databases whilst it is in use. Turning off the "Block reported attack sites" and "Block reported web forgeries" options under 'Security' stops it updating urlclassifier3.sqlite. Note that when you update a file, you implicitly update the associated inode and the filesystem superbock. > What would happen in some=20 >complicated KDE/Gnome environment I am just afraid to think. I'd recommend avoiding a heavyweight window manager and using something like fwvm or vtwm. --=20 Peter Jeremy --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoABJIACgkQ/opHv/APuIfq8wCdH8DXPq3Vv0V1hzLBO1KOmnG8 67AAnjuB8SS3/vaNaSu5WP+7b7xHQ6Xj =ZLjp -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Tue May 5 10:19: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 60BDB1065677 for ; Tue, 5 May 2009 10:19:28 +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 B90C88FC25 for ; Tue, 5 May 2009 10:19:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=8kQB0OdkAAAA:8 a=fVrbk2N5DAe2BhTDaGoA:9 a=pY4xUFcQFCOFI9jgRGw6tErPjmUA:4 a=9aOQ2cSd83gA:10 a=HoH03RvBXNaYstPRyVwA:9 a=mQeylW-3_SvhdQ7mjzwA:7 a=0A__baNcM3s3_R0xENXHwbeSBloA: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 1237046659; Tue, 05 May 2009 12:19:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 5 May 2009 12:22:00 +0200 User-Agent: KMail/1.9.7 References: <200905051040.53708.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_INBAKBeYLWaJ1GH" Message-Id: <200905051222.00887.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 10:19:28 -0000 --Boundary-00=_INBAKBeYLWaJ1GH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 05 May 2009, Chao Shin wrote: > =E5=9C=A8 Tue, 05 May 2009 16:40:53 +0800=EF=BC=8CHans Petter Selasky > > =E5=86=99=E9=81=93: > > sysctl hw.usb2.uhci.debug=3D15 > > This is my dmesg in attchement. Try the attached patch to uhci.c. =2D-HPS --Boundary-00=_INBAKBeYLWaJ1GH Content-Type: text/x-diff; charset="utf-8"; name="uhci.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uhci.c.diff" --- /usr/8-current/src/sys/dev/usb/controller/uhci.c Tue May 5 12:15:08 2009 +++ src/sys/dev/usb/controller/uhci.c Tue May 5 12:20:53 2009 @@ -132,6 +132,7 @@ extern struct usb2_pipe_methods uhci_device_intr_methods; extern struct usb2_pipe_methods uhci_device_isoc_methods; +static uint8_t uhci_restart(uhci_softc_t *sc); static void uhci_do_poll(struct usb2_bus *); static void uhci_device_done(struct usb2_xfer *, usb2_error_t); static void uhci_transfer_intr_enqueue(struct usb2_xfer *); @@ -246,10 +247,51 @@ ml->buf_offset += td->len; } +/* + * Return values: + * 0: Success + * Else: Failure + */ +static uint8_t +uhci_restart(uhci_softc_t *sc) +{ + struct usb2_page_search buf_res; + + USB_BUS_LOCK_ASSERT(&sc->sc_bus, MA_OWNED); + + if (UREAD2(sc, UHCI_CMD) & UHCI_CMD_RS) { + DPRINTFN(2, "Already started\n"); + return (0); + } + + DPRINTFN(2, "Restarting\n"); + + usb2_get_page(&sc->sc_hw.pframes_pc, 0, &buf_res); + + /* Reload fresh base address */ + UWRITE4(sc, UHCI_FLBASEADDR, buf_res.physaddr); + + /* + * Assume 64 byte packets at frame end and start HC controller: + */ + UHCICMD(sc, (UHCI_CMD_MAXP | UHCI_CMD_RS)); + + /* wait 10 milliseconds */ + + usb2_pause_mtx(&sc->sc_bus.bus_mtx, hz / 100); + + /* check that controller has started */ + + if (!(UREAD2(sc, UHCI_STS) & UHCI_STS_HCH)) { + DPRINTFN(2, "Failed\n"); + return (1); + } + return (0); +} + void uhci_reset(uhci_softc_t *sc) { - struct usb2_page_search buf_res; uint16_t n; USB_BUS_LOCK_ASSERT(&sc->sc_bus, MA_OWNED); @@ -309,8 +351,6 @@ done_2: /* reload the configuration */ - usb2_get_page(&sc->sc_hw.pframes_pc, 0, &buf_res); - UWRITE4(sc, UHCI_FLBASEADDR, buf_res.physaddr); UWRITE2(sc, UHCI_FRNUM, sc->sc_saved_frnum); UWRITE1(sc, UHCI_SOF, sc->sc_saved_sof); @@ -337,30 +377,11 @@ UHCI_INTR_IOCE | UHCI_INTR_SPIE)); - /* - * assume 64 byte packets at frame end and start HC controller - */ - - UHCICMD(sc, (UHCI_CMD_MAXP | UHCI_CMD_RS)); - - uint8_t n = 10; - - while (n--) { - /* wait one millisecond */ - - usb2_pause_mtx(&sc->sc_bus.bus_mtx, hz / 1000); - - /* check that controller has started */ - - if (!(UREAD2(sc, UHCI_STS) & UHCI_STS_HCH)) { - goto done; - } + if (uhci_restart(sc)) { + device_printf(sc->sc_bus.bdev, + "cannot start HC controller\n"); } - device_printf(sc->sc_bus.bdev, - "cannot start HC controller\n"); - -done: /* start root interrupt */ uhci_root_intr(sc); } @@ -2072,10 +2093,8 @@ qh->qh_e_next = td->td_self; if (xfer->xroot->udev->state != USB_STATE_SUSPENDED) { - /* enter QHs into the controller data structures */ UHCI_APPEND_QH(qh, sc->sc_intr_p_last[xfer->qh_pos]); - } else { usb2_pc_cpu_flush(qh->page_cache); } @@ -2391,15 +2410,7 @@ * Before we do anything, turn on SOF messages on the USB * BUS. Some USB devices do not cope without them! */ - if (!(UREAD2(sc, UHCI_CMD) & UHCI_CMD_RS)) { - - DPRINTF("Activating SOFs!\n"); - - UHCICMD(sc, (UHCI_CMD_MAXP | UHCI_CMD_RS)); - - /* wait a little bit */ - usb2_pause_mtx(&sc->sc_bus.bus_mtx, hz / 100); - } + uhci_restart(sc); x = URWMASK(UREAD2(sc, port)); UWRITE2(sc, port, x | UHCI_PORTSC_PR); @@ -3196,11 +3207,11 @@ USB_HW_POWER_INTERRUPT | USB_HW_POWER_ISOC)) { DPRINTF("Some USB transfer is " - "active on %u.\n", + "active on unit %u.\n", device_get_unit(sc->sc_bus.bdev)); - UHCICMD(sc, (UHCI_CMD_MAXP | UHCI_CMD_RS)); + uhci_restart(sc); } else { - DPRINTF("Power save on %u.\n", + DPRINTF("Power save on unit %u.\n", device_get_unit(sc->sc_bus.bdev)); UHCICMD(sc, UHCI_CMD_MAXP); } --Boundary-00=_INBAKBeYLWaJ1GH-- From owner-freebsd-current@FreeBSD.ORG Tue May 5 06:39: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 97F49106564A for ; Tue, 5 May 2009 06:39:56 +0000 (UTC) (envelope-from jimmiejaz@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 1756F8FC08 for ; Tue, 5 May 2009 06:39:55 +0000 (UTC) (envelope-from jimmiejaz@gmail.com) Received: by qyk3 with SMTP id 3so8483558qyk.3 for ; Mon, 04 May 2009 23:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:content-type :content-transfer-encoding; bh=nphZF+Nzx3RcQ1hiAARD2sD4yRmVUlk5T3Og4T+YI5s=; b=FZohWU1qead//xb2A+tMjnCyBXhWPaPeJBoIUgtFgITEz6S1BjsDd9+vU7JJCXbkaK 7vas9wMmEat3lfrM4XmRV9pQJTj0zWEj+SH9uIDQ0Qp0norL9wQfMDU+9ZS4bX2PdeHn PYRCjT2/VSoOOt/EkxU4rdLIPUJvPbLvbIBMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:content-type:content-transfer-encoding; b=dOW04FjAnVnu/yUoZDrPDSj+dgmh9bvOzMm+ihx6IMaD9WauQzk/PYU132WfL8apub oYaJVizMDErA2oLXTSTmQB6QOFyHMRFQ3Uzt6hEI+UEAYdZab4wsP72Ahc24daczgdbe Hub2StH25n/L0xk1mM441UlAUc1wCP8apr8rU= Received: by 10.224.54.83 with SMTP id p19mr178756qag.191.1241503779197; Mon, 04 May 2009 23:09:39 -0700 (PDT) Received: from jimmiejaz.org (bas1-toronto44-1279263445.dsl.bell.ca [76.64.2.213]) by mx.google.com with ESMTPS id 34sm1986499yxm.21.2009.05.04.23.09.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 23:09:38 -0700 (PDT) Message-ID: <49FFD81A.5040501@gmail.com> Date: Tue, 05 May 2009 02:09:30 -0400 From: Jimmie James User-Agent: Thunderbird 2.0.0.7pre (X11/20090406) MIME-Version: 1.0 To: freebsd-current@freebsd.org, john@baldwin.cx References: 200903041011.24606.jhb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 May 2009 11:18:06 +0000 Cc: Subject: pci regression: "panic: resource_list_alloc: resource entry is busy" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jimmiejaz@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, 05 May 2009 06:39:56 -0000 Why is this affecting 7.2-STABLE? Does anyone test anything before a release anymore? This doesn't apply to 7.2: atching file vga_pci.c using Plan A... Hunk #1 failed at 42. Hunk #2 succeeded at 118 (offset -20 lines). Hunk #3 succeeded at 146 (offset -20 lines). 1 out of 3 hunks failed--saving rejects to vga_pci.c.rej Hmm... Ignoring the trailing garbage. done > John Baldwin wrote: > Probably at some point the agp and drm drivers for Intel will be merged which > would fix this, but this patch should help for now. We used to be leaking > a small portion of KVA due to this problem before. > > --- //depot/vendor/freebsd/src/sys/dev/pci/vga_pci.c 2008/09/19 19:15:30 > +++ //depot/user/jhb/acpipci/dev/pci/vga_pci.c 2009/03/04 15:32:08 > @@ -42,12 +42,20 @@ > #include > #include > #include > +#include > +#include > > #include > #include > > +struct vga_resource { > + struct resource *vr_res; > + int vr_refs; > +}; > + > struct vga_pci_softc { > device_t vga_msi_child; /* Child driver using MSI. */ > + struct vga_resource vga_res[PCIR_MAX_BAR_0 + 1]; > }; > > static int > @@ -130,7 +138,27 @@ > vga_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > + struct vga_pci_softc *sc; > + int bar; > > + switch (type) { > + case SYS_RES_MEMORY: > + case SYS_RES_IOPORT: > + /* > + * For BARs, we cache the resource so that we only allocate it > + * from the PCI bus once. > + */ > + bar = PCI_RID2BAR(*rid); > + if (bar < 0 || bar > PCIR_MAX_BAR_0) > + return (NULL); > + sc = device_get_softc(dev); > + if (sc->vga_res[bar].vr_res == NULL) > + sc->vga_res[bar].vr_res = bus_alloc_resource(dev, type, > + rid, start, end, count, flags); > + if (sc->vga_res[bar].vr_res != NULL) > + sc->vga_res[bar].vr_refs++; > + return (sc->vga_res[bar].vr_res); > + } > return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); > } > > @@ -138,6 +166,37 @@ > vga_pci_release_resource(device_t dev, device_t child, int type, int rid, > struct resource *r) > { > + struct vga_pci_softc *sc; > + int bar, error; > + > + switch (type) { > + case SYS_RES_MEMORY: > + case SYS_RES_IOPORT: > + /* > + * For BARs, we release the resource from the PCI bus > + * when the last child reference goes away. > + */ > + bar = PCI_RID2BAR(rid); > + if (bar < 0 || bar > PCIR_MAX_BAR_0) > + return (EINVAL); > + sc = device_get_softc(dev); > + if (sc->vga_res[bar].vr_res == NULL) > + return (EINVAL); > + KASSERT(sc->vga_res[bar].vr_res == r, > + ("vga_pci resource mismatch")); > + if (sc->vga_res[bar].vr_refs > 1) { > + sc->vga_res[bar].vr_refs--; > + return (0); > + } > + KASSERT(sc->vga_res[bar].vr_refs > 0, > + ("vga_pci resource reference count underflow")); > + error = bus_release_resource(dev, type, rid, r); > + if (error == 0) { > + sc->vga_res[bar].vr_res = NULL; > + sc->vga_res[bar].vr_refs = 0; > + } > + return (error); > + } > > return (bus_release_resource(dev, type, rid, r)); > } > -- Over the years I've come to regard you as people I've met. From owner-freebsd-current@FreeBSD.ORG Tue May 5 12:30: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 5C7451065673 for ; Tue, 5 May 2009 12:30:06 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id DA38A8FC13 for ; Tue, 5 May 2009 12:30:05 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id AC73B5C06F for ; Tue, 5 May 2009 20:30:04 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 8AEC655D16B5; Tue, 5 May 2009 20:30:04 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id teaH8rbOAGjg; Tue, 5 May 2009 20:29:10 +0800 (CST) Received: from qld630 (unknown [114.243.10.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D052555D16B3; Tue, 5 May 2009 20:29:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=tYouPBw5MLbDhkKRizWrL28blaPdQb7qKKhF9kMEebPI+/a3oq9PArC+Dit1FM8Fo UQL3uSfTOJ28bGTWxmmCg== Date: Tue, 05 May 2009 20:28:49 +0800 To: "Hans Petter Selasky" , freebsd-current@freebsd.org From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200905051040.53708.hselasky@c2i.net> <200905051222.00887.hselasky@c2i.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200905051222.00887.hselasky@c2i.net> User-Agent: Opera Mail/9.64 (Win32) Cc: Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 12:30:06 -0000 Great! after patched my mouse can work now, there is new dmesg segment below: bge0: link state changed to UP ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 Thank you very much! Would you commit this patch to current? BTW: usb2.0 is great work, I have test umass device on current, it is 6 times faster than 1.0. Do you have any plan make usb2.0 to support kdb or mountroot> ? > On Tuesday 05 May 2009, Chao Shin wrote: >> 在 Tue, 05 May 2009 16:40:53 +0800，Hans Petter Selasky >> >> >> 写道: >> > sysctl hw.usb2.uhci.debug=15 >> >> This is my dmesg in attchement. > > Try the attached patch to uhci.c. > > --HPS -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Tue May 5 12:51: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 3D28C106564A for ; Tue, 5 May 2009 12:51: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 C70D98FC16 for ; Tue, 5 May 2009 12:51:38 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R2bh8Ytw37wA:10 a=6I5d2MoRAAAA:8 a=8kQB0OdkAAAA:8 a=9dGKX7PjvK8rp-SGRKsA:9 a=rnZSGXFHlsPQi95PoXmH2si7qnUA:4 a=9aOQ2cSd83gA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1063917600; Tue, 05 May 2009 14:51:37 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 5 May 2009 14:54:10 +0200 User-Agent: KMail/1.9.7 References: <200905051222.00887.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905051454.11249.hselasky@c2i.net> Cc: Chao Shin Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 12:51:39 -0000 Hi Chao, On Tuesday 05 May 2009, Chao Shin wrote: > Great! after patched my mouse can work now, there is new dmesg segment > below: > > bge0: link state changed to UP > ugen1.2: at usbus1 > ums0: on usbu= s1 > ums0: 3 buttons and [XYZ] coordinates ID=3D0 > > Thank you very much! > Would you commit this patch to current? Yes, it is going into -current soon. =46inal patch: http://perforce.freebsd.org/chv.cgi?CH=3D161615 > > BTW: > usb2.0 is great work, I have test umass device on current, it is 6 times > faster > than 1.0. Thanks. > > Do you have any plan make usb2.0 to support kdb or mountroot> ? Not yet. The problem is USB is multi threaded, while kdb requires single=20 threaded operation. It is a little difficult. Also UKBD was Giant locked last time I checked due to some non-MPSAFE=20 dependencies. This is another issue blocking USB keyboard in KDB. =2D-HPS > > > On Tuesday 05 May 2009, Chao Shin wrote: > >> =E5=9C=A8 Tue, 05 May 2009 16:40:53 +0800=EF=BC=8CHans Petter Selasky > >> > >> > >> =E5=86=99=E9=81=93: > >> > sysctl hw.usb2.uhci.debug=3D15 > >> > >> This is my dmesg in attchement. > > > > Try the attached patch to uhci.c. > > > > --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 5 13:30: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 952661065672 for ; Tue, 5 May 2009 13:30:55 +0000 (UTC) (envelope-from paul@paulstewart.org) Received: from smtp.nexicom.net (smtp.nexicom.net [216.168.96.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5087A8FC23 for ; Tue, 5 May 2009 13:30:55 +0000 (UTC) (envelope-from paul@paulstewart.org) Received: from smtp.nexicom.net (smtp.nexicom.net [216.168.96.13]) by smtp.nexicom.net (8.13.6/8.13.4) with ESMTP id n45DUfJ4016590 for ; Tue, 5 May 2009 09:30:54 -0400 Received: from pstewart ([216.168.115.179] helo=pstewart) with IPv4:25 by smtp.nexicom.net; 5 May 2009 09:30:41 -0400 Received: from pstewart by pstewart (PGP Universal service); Tue, 05 May 2009 09:30:54 -0500 X-PGP-Universal: processed; by pstewart on Tue, 05 May 2009 09:30:54 -0500 From: "Paul Stewart" To: Date: Tue, 5 May 2009 09:30:41 -0400 Message-ID: <000001c9cd85$afe53b70$0fafb250$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNha8m7WDhzi5xSLW9LCH8BHmThQ== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 7.1 to 7.2 upgrade question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 13:30:56 -0000 Hi there. As I'm slowly getting used to FreeBSD (again), I recently upgraded three boxes to 7.2-RELEASE. Two of them were running 7.1-RELEASE and one was running 7.2-RC2 .. Anyways, I used freebsd-update to upgrade - in my previous experiences I would have to do a "make world" etc. etc. Which method is most preferred - source or binary upgrading? I don't mind source upgrading but is it really necessary anymore if using freebsd-update on a regular basis? Thanks, Paul From owner-freebsd-current@FreeBSD.ORG Tue May 5 13:44: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 2250E1065694; Tue, 5 May 2009 13:44:42 +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 EBC5C8FC13; Tue, 5 May 2009 13:44:41 +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 n45DidZQ044916; Tue, 5 May 2009 09:44:39 -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 n45DidC6002929; Tue, 5 May 2009 09:44:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4DB657302F; Tue, 5 May 2009 09:44:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090505134439.4DB657302F@freebsd-current.sentex.ca> Date: Tue, 5 May 2009 09:44:39 -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/i386 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: Tue, 05 May 2009 13:44:42 -0000 TB --- 2009-05-05 12:07:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 12:07:35 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-05 12:07:35 - cleaning the object tree TB --- 2009-05-05 12:08:13 - cvsupping the source tree TB --- 2009-05-05 12:08:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-05 12:08:23 - building world TB --- 2009-05-05 12:08:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 12:08:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 12:08:23 - TARGET=i386 TB --- 2009-05-05 12:08:23 - TARGET_ARCH=i386 TB --- 2009-05-05 12:08:23 - TZ=UTC TB --- 2009-05-05 12:08:23 - __MAKE_CONF=/dev/null TB --- 2009-05-05 12:08:23 - cd /src TB --- 2009-05-05 12:08:23 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 12:08:25 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 Tue May 5 13:30:01 UTC 2009 TB --- 2009-05-05 13:30:01 - generating LINT kernel config TB --- 2009-05-05 13:30:01 - cd /src/sys/i386/conf TB --- 2009-05-05 13:30:01 - /usr/bin/make -B LINT TB --- 2009-05-05 13:30:01 - building LINT kernel TB --- 2009-05-05 13:30:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:30:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:30:01 - TARGET=i386 TB --- 2009-05-05 13:30:01 - TARGET_ARCH=i386 TB --- 2009-05-05 13:30:01 - TZ=UTC TB --- 2009-05-05 13:30:01 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:30:01 - cd /src TB --- 2009-05-05 13:30:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 13:30:02 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 13:44:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 13:44:38 - ERROR: failed to build lint kernel TB --- 2009-05-05 13:44:38 - 4621.52 user 440.46 system 5822.88 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue May 5 13:48:49 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 786E61065678 for ; Tue, 5 May 2009 13:48:49 +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 295368FC19 for ; Tue, 5 May 2009 13:48:48 +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 n45DmiL1033881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 May 2009 13:48:45 GMT (envelope-from ben@wanderview.com) Message-Id: <8FB38AF4-3464-45AA-A6B2-96308EC49407@wanderview.com> From: Ben Kelly To: Jeff Roberson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 09:48:44 -0400 References: X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: current@freebsd.org Subject: Re: [patch] zfs kmem fragmentation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 13:48:50 -0000 On May 4, 2009, at 6:17 PM, Jeff Roberson wrote: > On Sat, 2 May 2009, Ben Kelly wrote: >> Hello all, >> >> Lately I've been looking into the "kmem too small" panics that >> often occur with zfs if you don't restrict the arc. What I found >> in my test environment was that everything works well until the >> kmem usage hits the 75% limit set in arc.c. At this point the arc >> is shrunk and slabs are reclaimed from uma. Unfortunately, every >> time this reclamation process runs the kmem space becomes more >> fragmented. The vast majority of the time my machine hits the >> "kmem too small" panic it has over 200MB of kmem space available, >> but the largest fragment is less than 128KB. > > What consumers make requests of kmem for 128kb and over? What > ultimately trips the panic? ZFS buffers range from 512 bytes to 128KB. I don't know of any allocations above 128KB at the moment. In my workload the panic is usually caused by zfs attempting to allocate a 128KB buffer, although sometimes its only doing a 64KB buffer. At one point I hacked in some instrumentation to print the kmem_map vm_map_entry when I touched a sysctl mib. Here's a capture I made during my load test as the fragmentation was occurring: http://www.wanderview.com/svn/public/misc/zfs/fragmentation.txt I also added some debug later to show the consumers of the allocations. The vast majority of them were from the opensolaris subsystem. Unfortunately I don't have a capture of that output handy. >> Ideally things would be arranged to free memory without >> fragmentation. I have tried a few things along those lines, but >> none of them have been successful so far. I'm going to continue >> that work, but in the meantime I've put together a patch that tries >> to avoid fragmentation by slowing kmem growth before the aggressive >> reclamation process is required: >> >> http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff >> >> It uses the following heuristics to do this: >> >> - Start arc_c at arc_c_min instead of arc_c_max. This causes the >> system to warm up more slowly. >> - Half the rate arc_c grows when kmem exceeds kmem_slow_growth_thresh >> - Stop arc_c growth when kmem exceeds kmem_target >> - Evict arc data when the kmem exceeds kmem_target >> - If kmem usage exceeds kmem_target then ask the pagedaemon to >> reclaim pages >> - If the largest kmem fragment is less than kmem_fragment_target >> then ask the pagedaemon to reclaim pages >> - If the largest kmem fragment is less than a kmem_fragment_thresh >> then force the aggressve kmem/arc reclamation process >> >> The defaults for the various targets and thresholds are: >> >> kmem_reclaim_threshold = 7/8 kmem >> kmem_target = 3/4 kmem >> kmem_slow_growth_threshold = 5/8 kmem >> kmem_fragment_target = 1/8 kmem >> kmem_fragment_thresh = 1/16 kmem >> >> With this patch I've been able to run my load tests with the >> default arc size with kmem values of 512MB to 700MB. I tried one >> loaded run with a 300MB kmem, but it panic'ed due to legitimate, >> non-fragmented kmem exhaustion. >> > > May I suggest an alternate approach; Have you considered placing > zfs in its own kernel submap? If all of its allocations are of a > like size, fragmentation won't be an issue and it can be constrained > to a fixed size without placing pressure on other kmem_map > consumers. This is the approach taken for the buffer cache. It > makes a good deal of sense. If arc can be taught to handle > allocation failures we could eliminate the panic entirely by simply > causing arc to run out of space and flush more buffers. > > Do you believe this would also address the problem? Using a separate submap might help. It seems that the fragmentation is occurring due to the interaction of the smaller and larger buffers within zfs. I believe in opensolaris data buffers and meta-data buffers are allocated from separate arenas. We don't do this currently and it may be the cause of some of the fragmentation. It also occurred to me that it might be nice if the arc could somehow share the buffer cache directly. Unfortunately I am moving this Friday and probably will be unable to really look at this for the next couple weeks. Thanks. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 5 14:18:33 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 5BA1A106566C for ; Tue, 5 May 2009 14:18:33 +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 E591D8FC0C for ; Tue, 5 May 2009 14:18:32 +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 n45EIUmE034239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 May 2009 14:18:30 GMT (envelope-from ben@wanderview.com) Message-Id: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> From: Ben Kelly To: 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 v930.3) Date: Tue, 5 May 2009 10:18:30 -0400 X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Subject: [patch] corrupt memstat_kvm_malloc(3) output and dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 14:18:33 -0000 Hi all, While debugging a problem recently with Alexander Leidinger we noticed that crashinfo(8) was producing corrupt vmstat -m output. After doing some digging it appears that memstat_kvm_malloc(3) might have been broken by this commit: http://svn.freebsd.org/viewvc/base?view=revision&revision=179222 The problem is that memstat_kvm_malloc(3) assumes that malloc_type_internal starts with an array of malloc_types_stats structures. This assumption is no longer true, though, as mti_probes was inserted at the start of the structure. It appears that this (untested) patch might fix the problem: http://www.wanderview.com/svn/public/misc/zfs/vmstat_kvm_malloc.diff I'm not very familiar with dtrace, though. Does anyone know if this would cause problems? Thanks. - Ben From owner-freebsd-current@FreeBSD.ORG Tue May 5 14:41: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 E5FDD1065670 for ; Tue, 5 May 2009 14:41:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id A17358FC25 for ; Tue, 5 May 2009 14:41:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1M1LqH-00074v-Ft>; Tue, 05 May 2009 16:41:57 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1M1LqH-0007F3-Ed>; Tue, 05 May 2009 16:41:57 +0200 Message-ID: <4A004FE3.2070702@zedat.fu-berlin.de> Date: Tue, 05 May 2009 14:40:35 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090417) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: Weird slowlyness of subversion-freebsd with 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: Tue, 05 May 2009 14:41:59 -0000 Hello, since the last portupgrade when dev/subversion-freebsd got updates, I realize a drastic slowdown since then on FreeBSD 8.0-CURRENT/amd64 boxes. Is there any known issue and if, how to circumvent ... Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue May 5 15:19: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 242B5106564A; Tue, 5 May 2009 15:19:20 +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 ECBA78FC17; Tue, 5 May 2009 15:19:19 +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 n45FJGH3041762; Tue, 5 May 2009 11:19:16 -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 n45FJFCF084701; Tue, 5 May 2009 11:19:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 955DA7302F; Tue, 5 May 2009 11:19:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090505151915.955DA7302F@freebsd-current.sentex.ca> Date: Tue, 5 May 2009 11:19:15 -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 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: Tue, 05 May 2009 15:19:20 -0000 TB --- 2009-05-05 13:44:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 13:44:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-05 13:44:39 - cleaning the object tree TB --- 2009-05-05 13:45:17 - cvsupping the source tree TB --- 2009-05-05 13:45:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-05 13:45:28 - building world TB --- 2009-05-05 13:45:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:45:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:45:28 - TARGET=pc98 TB --- 2009-05-05 13:45:28 - TARGET_ARCH=i386 TB --- 2009-05-05 13:45:28 - TZ=UTC TB --- 2009-05-05 13:45:28 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:45:28 - cd /src TB --- 2009-05-05 13:45:28 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 13:45:30 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 Tue May 5 15:06:56 UTC 2009 TB --- 2009-05-05 15:06:56 - generating LINT kernel config TB --- 2009-05-05 15:06:56 - cd /src/sys/pc98/conf TB --- 2009-05-05 15:06:56 - /usr/bin/make -B LINT TB --- 2009-05-05 15:06:56 - building LINT kernel TB --- 2009-05-05 15:06:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 15:06:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 15:06:56 - TARGET=pc98 TB --- 2009-05-05 15:06:56 - TARGET_ARCH=i386 TB --- 2009-05-05 15:06:56 - TZ=UTC TB --- 2009-05-05 15:06:56 - __MAKE_CONF=/dev/null TB --- 2009-05-05 15:06:56 - cd /src TB --- 2009-05-05 15:06:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 15:06:56 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** 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-05 15:19:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 15:19:15 - ERROR: failed to build lint kernel TB --- 2009-05-05 15:19:15 - 4480.66 user 442.88 system 5675.99 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue May 5 15: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 0768D106564A for ; Tue, 5 May 2009 15:42: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 BF5628FC0A for ; Tue, 5 May 2009 15:42: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 BB6C8FF30; Wed, 6 May 2009 03:42:44 +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 lvvuZknQrhRp; Wed, 6 May 2009 03:42:40 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 6 May 2009 03:42:40 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id D0DA711432; Wed, 6 May 2009 03:42:39 +1200 (NZST) Date: Tue, 5 May 2009 08:42:39 -0700 From: Andrew Thompson To: Chao Shin Message-ID: <20090505154239.GE40769@citylink.fud.org.nz> References: <200905051040.53708.hselasky@c2i.net> <200905051222.00887.hselasky@c2i.net> 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: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: current couldn't attach usb mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 15:42:46 -0000 This has been committed, thanks for reporting and Hans for fixing. On Tue, May 05, 2009 at 08:28:49PM +0800, Chao Shin wrote: > Great! after patched my mouse can work now, there is new dmesg segment > below: > > bge0: link state changed to UP > ugen1.2: at usbus1 > ums0: on usbus1 > ums0: 3 buttons and [XYZ] coordinates ID=0 > > Thank you very much! > Would you commit this patch to current? > > BTW: > usb2.0 is great work, I have test umass device on current, it is 6 times > faster > than 1.0. > > Do you have any plan make usb2.0 to support kdb or mountroot> ? > > >> On Tuesday 05 May 2009, Chao Shin wrote: >>> ??? Tue, 05 May 2009 16:40:53 +0800???Hans Petter Selasky >>> >>> >>> ??????: >>> > sysctl hw.usb2.uhci.debug=15 >>> >>> This is my dmesg in attchement. >> >> Try the attached patch to uhci.c. >> >> --HPS > > > > -- > The Power to Serve > _______________________________________________ > 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 5 15:59: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 B168A106566C; Tue, 5 May 2009 15:59:22 +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 8777E8FC0A; Tue, 5 May 2009 15:59:22 +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 n45FxKYp049392; Tue, 5 May 2009 11:59:20 -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 n45FxKI8083740; Tue, 5 May 2009 11:59:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EF3677302F; Tue, 5 May 2009 11:59:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090505155919.EF3677302F@freebsd-current.sentex.ca> Date: Tue, 5 May 2009 11:59:19 -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 ia64/ia64 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: Tue, 05 May 2009 15:59:23 -0000 TB --- 2009-05-05 13:54:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 13:54:24 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-05 13:54:24 - cleaning the object tree TB --- 2009-05-05 13:54:55 - cvsupping the source tree TB --- 2009-05-05 13:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-05 13:55:05 - building world TB --- 2009-05-05 13:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:55:05 - TARGET=ia64 TB --- 2009-05-05 13:55:05 - TARGET_ARCH=ia64 TB --- 2009-05-05 13:55:05 - TZ=UTC TB --- 2009-05-05 13:55:05 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:55:05 - cd /src TB --- 2009-05-05 13:55:05 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 13:55:06 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 Tue May 5 15:42:36 UTC 2009 TB --- 2009-05-05 15:42:36 - generating LINT kernel config TB --- 2009-05-05 15:42:36 - cd /src/sys/ia64/conf TB --- 2009-05-05 15:42:36 - /usr/bin/make -B LINT TB --- 2009-05-05 15:42:36 - building LINT kernel TB --- 2009-05-05 15:42:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 15:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 15:42:36 - TARGET=ia64 TB --- 2009-05-05 15:42:36 - TARGET_ARCH=ia64 TB --- 2009-05-05 15:42:36 - TZ=UTC TB --- 2009-05-05 15:42:36 - __MAKE_CONF=/dev/null TB --- 2009-05-05 15:42:36 - cd /src TB --- 2009-05-05 15:42:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 15:42:36 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 [...] /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:143: error: initializer element is not computable at load time /src/sys/netgraph/ng_base.c:143: error: (near initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 15:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 15:59:19 - ERROR: failed to build lint kernel TB --- 2009-05-05 15:59:19 - 6189.92 user 448.20 system 7495.84 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue May 5 16:17: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 3B2D71065672 for ; Tue, 5 May 2009 16:17:32 +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 E5F4F8FC1D for ; Tue, 5 May 2009 16:17:31 +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 n45GHUFn046605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 09:17:31 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A00669A.10105@freebsd.org> Date: Tue, 05 May 2009 09:17:30 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Peter Jeremy References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> <20090505091914.GA94521@server.vk2pj.dyndns.org> In-Reply-To: <20090505091914.GA94521@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD-Current Subject: Re: Fighting for the power. [syslogd] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 16:17:32 -0000 Peter Jeremy wrote: > On 2009-May-04 06:19:36 +0300, Alexander Motin wrote: > ...snip... >> number of idle disk write activity, but I haven't very succeeded. Even >> in my quite simple icewm X environment something was persistently >> writing something every several minutes. I have found and disabled some >> activity sources, but it was not enough. >> > > I've recently (in the last few days) worked through minimising the > write activity on the SSD in my laptop (I wrote a tool that monitors > write transfers via devstat(3) and it would be possible to track down > the actual modified files via kqueue(2) if necessary). I'm now down > to about two chunks of about 13 transfers each per hour (due to entopy > saving and ntp.drift updating). The changes I made were: > 1) Mount the SSD filesystems as noatime > 2) Turn off all local syslogging (syslog is directed to another > system when my laptop is at home, lost otherwise). > Regarding syslogd, I've considered adding support to batch/buffer writes to workaround a problem that I consider rather important: syslogd is not started early enough in the boot so it's not available to log msgs from other applications. In particular I hit this because wpa_supplicant logs via syslog but when it's started at boot syslogd isn't available and since wpa_supplicant operates in a chroot'd environment it cannot defer connecting until syslogd has started up so nothing is ever logged. I think we want syslogd to start very early and deal with the case where the local filesystem is not present. My plan was to buffer msgs and then flush them at a later time. But this might also be used to buffer log activity so local disk activity is staged (e.g. for the laptop or embedded use). Maybe someone else has a better idea but I think we need to do something soon. Sam From owner-freebsd-current@FreeBSD.ORG Tue May 5 16:51: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 ACDF010656E8 for ; Tue, 5 May 2009 16:51:56 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3C84E8FC18 for ; Tue, 5 May 2009 16:51:56 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id B209D9B756; Tue, 5 May 2009 18:31:09 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id BE6329B6C6 for ; Tue, 5 May 2009 18:27:55 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Tue, 5 May 2009 12:27:51 -0400 User-Agent: KMail/1.9.10 References: <20090505155919.EF3677302F@freebsd-current.sentex.ca> In-Reply-To: <20090505155919.EF3677302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905051227.51590.zec@freebsd.org> Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 16:51:58 -0000 Mea culpa, should be fixed by r191827 now. Marko On Tuesday 05 May 2009 11:59:19 FreeBSD Tinderbox wrote: > TB --- 2009-05-05 13:54:24 - tinderbox 2.6 running on > freebsd-current.sentex.ca TB --- 2009-05-05 13:54:24 - starting HEAD > tinderbox run for ia64/ia64 TB --- 2009-05-05 13:54:24 - cleaning the > object tree > TB --- 2009-05-05 13:54:55 - cvsupping the source tree > TB --- 2009-05-05 13:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s > /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-05 13:55:05 - building > world > TB --- 2009-05-05 13:55:05 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-05 13:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-05 13:55:05 - TARGET=ia64 > TB --- 2009-05-05 13:55:05 - TARGET_ARCH=ia64 > TB --- 2009-05-05 13:55:05 - TZ=UTC > TB --- 2009-05-05 13:55:05 - __MAKE_CONF=/dev/null > TB --- 2009-05-05 13:55:05 - cd /src > TB --- 2009-05-05 13:55:05 - /usr/bin/make -B buildworld > > >>> World build started on Tue May 5 13:55:06 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 Tue May 5 15:42:36 UTC 2009 > > TB --- 2009-05-05 15:42:36 - generating LINT kernel config > TB --- 2009-05-05 15:42:36 - cd /src/sys/ia64/conf > TB --- 2009-05-05 15:42:36 - /usr/bin/make -B LINT > TB --- 2009-05-05 15:42:36 - building LINT kernel > TB --- 2009-05-05 15:42:36 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-05 15:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-05 15:42:36 - TARGET=ia64 > TB --- 2009-05-05 15:42:36 - TARGET_ARCH=ia64 > TB --- 2009-05-05 15:42:36 - TZ=UTC > TB --- 2009-05-05 15:42:36 - __MAKE_CONF=/dev/null > TB --- 2009-05-05 15:42:36 - cd /src > TB --- 2009-05-05 15:42:36 - /usr/bin/make -B buildkernel KERNCONF=LINT > > >>> Kernel build for LINT started on Tue May 5 15:42:36 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 > > [...] > /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from > integer without a cast /src/sys/netgraph/ng_base.c:143: warning: > initialization makes integer from pointer without a cast > /src/sys/netgraph/ng_base.c:143: error: initializer element is not > computable at load time /src/sys/netgraph/ng_base.c:143: error: (near > initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: > warning: initialization makes pointer from integer without a cast > /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer > /src/sys/netgraph/ng_base.c:145: warning: (near initialization for > 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: > initialization makes integer from pointer without a cast *** Error code 1 > > Stop in /obj/ia64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-05-05 15:59:19 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-05-05 15:59:19 - ERROR: failed to build lint kernel > TB --- 2009-05-05 15:59:19 - 6189.92 user 448.20 system 7495.84 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full > _______________________________________________ > 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 5 17:36: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 A075A1065678; Tue, 5 May 2009 17:36:06 +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 76E768FC17; Tue, 5 May 2009 17:36:06 +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 n45Ha4OC064029; Tue, 5 May 2009 13:36:04 -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 n45Ha4l8005864; Tue, 5 May 2009 13:36:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D96C67302F; Tue, 5 May 2009 13:36:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090505173603.D96C67302F@freebsd-current.sentex.ca> Date: Tue, 5 May 2009 13:36:03 -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 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: Tue, 05 May 2009 17:36:07 -0000 TB --- 2009-05-05 15:59:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 15:59:20 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-05 15:59:20 - cleaning the object tree TB --- 2009-05-05 15:59:52 - cvsupping the source tree TB --- 2009-05-05 15:59:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-05 16:00:04 - building world TB --- 2009-05-05 16:00:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 16:00:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 16:00:04 - TARGET=powerpc TB --- 2009-05-05 16:00:04 - TARGET_ARCH=powerpc TB --- 2009-05-05 16:00:04 - TZ=UTC TB --- 2009-05-05 16:00:04 - __MAKE_CONF=/dev/null TB --- 2009-05-05 16:00:04 - cd /src TB --- 2009-05-05 16:00:04 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 16:00:06 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 Tue May 5 17:24:24 UTC 2009 TB --- 2009-05-05 17:24:24 - generating LINT kernel config TB --- 2009-05-05 17:24:24 - cd /src/sys/powerpc/conf TB --- 2009-05-05 17:24:24 - /usr/bin/make -B LINT TB --- 2009-05-05 17:24:24 - building LINT kernel TB --- 2009-05-05 17:24:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 17:24:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 17:24:24 - TARGET=powerpc TB --- 2009-05-05 17:24:24 - TARGET_ARCH=powerpc TB --- 2009-05-05 17:24:24 - TZ=UTC TB --- 2009-05-05 17:24:24 - __MAKE_CONF=/dev/null TB --- 2009-05-05 17:24:24 - cd /src TB --- 2009-05-05 17:24:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 17:24:24 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/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** 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-05 17:36:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 17:36:03 - ERROR: failed to build lint kernel TB --- 2009-05-05 17:36:03 - 4650.95 user 428.40 system 5803.43 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue May 5 17:48: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 E84BB106566C for ; Tue, 5 May 2009 17:48:35 +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 63F808FC08 for ; Tue, 5 May 2009 17:48:35 +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 E9540A0754; Tue, 5 May 2009 19:48:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DC9FDA0752; Tue, 5 May 2009 19:48:31 +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 C7247A0743; Tue, 5 May 2009 19:48:31 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050519483116-5802 ; Tue, 5 May 2009 19:48:31 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 5 May 2009 19:48:31 +0200 Date: Tue, 5 May 2009 19:48:31 +0200 From: Alexey Shuvaev To: openoffice@FreeBSD.org Message-ID: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 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.2HF443 | November 25, 2008) at 05/05/2009 07:48:31 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/05/2009 07:48:31 PM, Serialize complete at 05/05/2009 07:48:31 PM Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: gunzip | tar reports broken pipe during OOO build on 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: Tue, 05 May 2009 17:48:36 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello all! I was trying to upgrade editors/openoffice.org-2 recently and build failed for me at: -------------------------------------------------------------- packimages -- version: 1.16 packimages: packing ../unxfbsdx.pro/bin/images_industrial.zip finished. cd ../unxfbsdx.pro/misc && gunzip -c /usr/ports/editors/openoffice.org-2/work/OOH680_m18/external_images/ooo_crystal_images-1.tar.gz | ( tar -xf - ) && touch crystal.flag ---* tg_merge.mk *--- Running processes: 0 1 module(s): instsetoo_native need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /usr/ports/editors/openoffice.org-2/work/OOH680_m18/instsetoo_native/packimages Attention: if you build and deliver the above module(s) you may prolongue your the build issuing command "build --from instsetoo_native" *** Error code 1 Stop in /usr/ports/editors/openoffice.org-2. -------------------------------------------------------------- The reason appeared to be the first part of the command "gunzip -c ... | ( tar -xf - ) && touch ..." which exited with non-zero exit status (141) and "touch ..." was not called. Running the command manually has showed that gunzip was complaining about broken pipe (however the archive was extracted successfully). The attached patch has fixed the problem however I don't feel it is the proper solution. The problem seems to be in that specific archive but I'm not sure... ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue May 5 00:16:39 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 My 0.02$, Alexey. --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-OOO --- instsetoo_native/packimages/makefile.mk.orig 2007-06-06 16:20:38.000000000 +0200 +++ instsetoo_native/packimages/makefile.mk 2009-05-05 17:01:57.000000000 +0200 @@ -79,7 +79,7 @@ # unpack the Crystal icon set $(MISC)$/crystal.flag : $(CRYSTAL_TARBALL) - cd $(MISC) && gunzip -c $(CRYSTAL_TARBALL) | ( tar -xf - ) && $(TOUCH) $(@:f) + cd $(MISC) && tar -xf $(CRYSTAL_TARBALL) && $(TOUCH) $(@:f) .IF "$(GUI)"=="UNX" chmod -R g+w $(MISC)$/crystal .ENDIF --45Z9DzgjV8m4Oswq-- From owner-freebsd-current@FreeBSD.ORG Tue May 5 17:53: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 9DC381065676 for ; Tue, 5 May 2009 17:53: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 4ACA98FC18 for ; Tue, 5 May 2009 17:53:20 +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 64A5CEB568B; Tue, 5 May 2009 20:53:19 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 51917450C6; Tue, 5 May 2009 20:53:19 +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 1i9CBNJUhb52; Tue, 5 May 2009 20:53:19 +0300 (EEST) Received: from kobe.laptop (adsl119-239.kln.forthnet.gr [77.49.238.239]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 1614145088; Tue, 5 May 2009 20:53:19 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n45HrIit058915; Tue, 5 May 2009 20:53:18 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n45HrGIS058914; Tue, 5 May 2009 20:53:16 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Paul Stewart" References: <000001c9cd85$afe53b70$0fafb250$@org> Date: Tue, 05 May 2009 20:53:16 +0300 In-Reply-To: <000001c9cd85$afe53b70$0fafb250$@org> (Paul Stewart's message of "Tue, 5 May 2009 09:30:41 -0400") Message-ID: <87ljpbwi5v.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: 7.1 to 7.2 upgrade question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 17:53:21 -0000 On Tue, 5 May 2009 09:30:41 -0400, "Paul Stewart" wrote: > Hi there. > > As I'm slowly getting used to FreeBSD (again), I recently upgraded > three boxes to 7.2-RELEASE. Two of them were running 7.1-RELEASE and > one was running 7.2-RC2 .. > > Anyways, I used freebsd-update to upgrade - in my previous experiences > I would have to do a "make world" etc. etc. > > Which method is most preferred - source or binary upgrading? I don't > mind source upgrading but is it really necessary anymore if using > freebsd-update on a regular basis? If you don't need local patches or a custom kernel, and you can use the GENERIC kernel configured to match your hardware setup, then it probably makes a lot of sense to use freebsd-update. It will usually be much faster than compiling everything from source. From owner-freebsd-current@FreeBSD.ORG Tue May 5 17:58: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 8A09F106566B; Tue, 5 May 2009 17:58:53 +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 605B58FC16; Tue, 5 May 2009 17:58:52 +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 n45Hwpds067153; Tue, 5 May 2009 13:58:51 -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 n45HwpaT055846; Tue, 5 May 2009 13:58:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0EE1B7302F; Tue, 5 May 2009 13:58:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090505175851.0EE1B7302F@freebsd-current.sentex.ca> Date: Tue, 5 May 2009 13:58:51 -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/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: Tue, 05 May 2009 17:58:54 -0000 TB --- 2009-05-05 16:25:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 16:25:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-05 16:25:10 - cleaning the object tree TB --- 2009-05-05 16:25:42 - cvsupping the source tree TB --- 2009-05-05 16:25:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-05 16:25:52 - building world TB --- 2009-05-05 16:25:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 16:25:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 16:25:52 - TARGET=sparc64 TB --- 2009-05-05 16:25:52 - TARGET_ARCH=sparc64 TB --- 2009-05-05 16:25:52 - TZ=UTC TB --- 2009-05-05 16:25:52 - __MAKE_CONF=/dev/null TB --- 2009-05-05 16:25:52 - cd /src TB --- 2009-05-05 16:25:52 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 16:25:53 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 Tue May 5 17:46:14 UTC 2009 TB --- 2009-05-05 17:46:14 - generating LINT kernel config TB --- 2009-05-05 17:46:14 - cd /src/sys/sparc64/conf TB --- 2009-05-05 17:46:14 - /usr/bin/make -B LINT TB --- 2009-05-05 17:46:14 - building LINT kernel TB --- 2009-05-05 17:46:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 17:46:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 17:46:14 - TARGET=sparc64 TB --- 2009-05-05 17:46:14 - TARGET_ARCH=sparc64 TB --- 2009-05-05 17:46:14 - TZ=UTC TB --- 2009-05-05 17:46:14 - __MAKE_CONF=/dev/null TB --- 2009-05-05 17:46:14 - cd /src TB --- 2009-05-05 17:46:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 17:46:14 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 [...] /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:143: error: initializer element is not computable at load time /src/sys/netgraph/ng_base.c:143: error: (near initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** 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-05 17:58:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 17:58:51 - ERROR: failed to build lint kernel TB --- 2009-05-05 17:58:51 - 4436.18 user 419.07 system 5621.04 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue May 5 18:59: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 D02CF106564A for ; Tue, 5 May 2009 18:59:05 +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 81DDE8FC1A for ; Tue, 5 May 2009 18:59: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=oryz4u5YiWEDe6yGQQ4cFaLEY68bQvT7dwggKQHWnF4arBQg57Zzn5FrpkPRvkvVfw/oc4lngPTkzAyaZaQl5YNc3KNjHKxhnz5AkSL6GsaIm3ycrn16w1h6YH+lYAPGpr4C1selfoqDvCC7ALGJ8HCqVyVwAndhzjD1TUFDLc4=; Received: from amnesiac.at.no.dns ([91.78.118.163]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M1Pr5-0000Tu-Lt; Tue, 05 May 2009 22:59:04 +0400 Date: Tue, 5 May 2009 22:59:01 +0400 From: Eygene Ryabinkin To: Alexey Shuvaev Message-ID: <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, openoffice@FreeBSD.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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: Tue, 05 May 2009 18:59:06 -0000 Alexey, good day. Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > The reason appeared to be the first part of the command > "gunzip -c ... | ( tar -xf - ) && touch ..." > which exited with non-zero exit status (141) and "touch ..." was not called. > Running the command manually has showed that gunzip was complaining about > broken pipe (however the archive was extracted successfully). Yes, 141 means that SIGPIPE was delivered. This in turn means that 'tar -xf -' exited before gunzip had finished its job and gunzip had tried to write more data to the pipe. Could I ask to do some debugging: 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the results. 3. do 'md5 ooo_crystal_images-1.tar.gz' For the last point, I have ----- MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 ----- but this tar.gz was taken from OOO 3.x. If yours have some other checksum, could you place it somewhere where I can download it? My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of May. Thanks! -- 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 Tue May 5 19:55: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 60267106566C for ; Tue, 5 May 2009 19:55:32 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by mx1.freebsd.org (Postfix) with ESMTP id E63F58FC1F for ; Tue, 5 May 2009 19:55:31 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so274161gve.39 for ; Tue, 05 May 2009 12:55:31 -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=oo0N/YN0RNmgiooQy42pHKjOqgwEvhkfJcXioU7qqlk=; b=nGdzcRwRbWspTfjqTF3z5I9LZKJGF1X++SvXYawZtdx8PvbJvY8nYWCmHth5ls/Y83 yhH9f1s5J1WIY0IMfPXcSxm1UYB+RgoJkP1UxLlCe5rFWiv4/mB2clXvVQjPitkp3+JG 1IHJrkfSj++MUhfoIvpUNBxLWuB2z3/n6JeYA= 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=aklZqwGLDNtfCWJJmqNjmKxrLxvXedY4BpHwO45dG+HY4x2ax2dUiBvQaZqo+xzQKi wK6CEwLEyC5korIbzQS3sfD0s87XmFt5vjjlzgAvqO1nDhHg7Pha8aLPrOSwUu31OLKC 3jU6wqrmiWxoNoNtELMyHqVYxi45GLsfoQVA8= MIME-Version: 1.0 Received: by 10.220.75.199 with SMTP id z7mr722256vcj.112.1241553330166; Tue, 05 May 2009 12:55:30 -0700 (PDT) In-Reply-To: <87ljpbwi5v.fsf@kobe.laptop> References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> From: Renato Botelho Date: Tue, 5 May 2009 16:55:15 -0300 Message-ID: <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> To: Giorgos Keramidas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Paul Stewart Subject: Re: 7.1 to 7.2 upgrade question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 19:55:32 -0000 On Tue, May 5, 2009 at 2:53 PM, Giorgos Keramidas wrote: > On Tue, 5 May 2009 09:30:41 -0400, "Paul Stewart" = wrote: >> Hi there. >> >> As I'm slowly getting used to FreeBSD (again), I recently upgraded >> three boxes to 7.2-RELEASE. =A0Two of them were running 7.1-RELEASE and >> one was running 7.2-RC2 .. >> >> Anyways, I used freebsd-update to upgrade - in my previous experiences >> I would have to do a "make world" etc. etc. >> >> Which method is most preferred - source or binary upgrading? =A0I don't >> mind source upgrading but is it really necessary anymore if using >> freebsd-update on a regular basis? > > If you don't need local patches or a custom kernel, and you can use the > GENERIC kernel configured to match your hardware setup, then it probably > makes a lot of sense to use freebsd-update. =A0It will usually be much > faster than compiling everything from source. I don't know if it's officially supported, but I did an hybrid upgrade using freebsd-update for the base and building the custom kernel from sources, it worked fine and is still much faster than build everything. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Tue May 5 20:26: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 C7EEC1065693 for ; Tue, 5 May 2009 20:26:21 +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 9AF8A8FC1E for ; Tue, 5 May 2009 20:26:21 +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 52F5146B09; Tue, 5 May 2009 16:26:21 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [127.0.0.1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E1A9A8A022; Tue, 5 May 2009 16:26:19 -0400 (EDT) Message-ID: <4A00A0ED.7000003@FreeBSD.org> Date: Tue, 05 May 2009 16:26:21 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: jimmiejaz@gmail.com References: 200903041011.24606.jhb@freebsd.org <49FFD81A.5040501@gmail.com> In-Reply-To: <49FFD81A.5040501@gmail.com> 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 (bigwig.baldwin.cx); Tue, 05 May 2009 16:26:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: pci regression: "panic: resource_list_alloc: resource entry is busy" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 20:26:22 -0000 Jimmie James wrote: > Why is this affecting 7.2-STABLE? Does anyone test anything before a > release anymore? > This doesn't apply to 7.2: > > atching file vga_pci.c using Plan A... > Hunk #1 failed at 42. > Hunk #2 succeeded at 118 (offset -20 lines). > Hunk #3 succeeded at 146 (offset -20 lines). > 1 out of 3 hunks failed--saving rejects to vga_pci.c.rej > Hmm... Ignoring the trailing garbage. > done It affects -stable because I merged some changes to the PCI bus code after the release (thus, 7.2-release is not affected as you seem to imply). Note that the machine I tested the merge on is a server box that doesn't use DRM (and drm(4) isn't in GENERIC) so I didn't run into this during testing. If you update your tree it should be fixed now. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 5 21:07: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 08D511065673 for ; Tue, 5 May 2009 21:07:29 +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 AC00A8FC0A for ; Tue, 5 May 2009 21:07:28 +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:Content-Transfer-Encoding:In-Reply-To:Sender; b=KVWoVFpN2XoAa5/JIBwf7T1Qf/LgeubkQq6zXC1NZ5mu1ZB8HMYDwBn51YwmSAMXsKbIVgTXUpXxMKK4OvrfO8sV9qVBkLSOXgCj8rfHaR80lURB3bLgcjj6LFHgO5sEB61vlyaBNq2WpZTjralsGGGlEThLtXF79tU5pP1bbbE=; Received: from amnesiac.at.no.dns ([91.78.118.163]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M1RrJ-000D5Q-9W; Wed, 06 May 2009 01:07:25 +0400 Date: Wed, 6 May 2009 01:07:23 +0400 From: Eygene Ryabinkin To: Renato Botelho Message-ID: References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: Giorgos Keramidas , freebsd-current@freebsd.org, Paul Stewart Subject: Re: 7.1 to 7.2 upgrade question 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: Tue, 05 May 2009 21:07:29 -0000 Renato, Tue, May 05, 2009 at 04:55:15PM -0300, Renato Botelho wrote: > On Tue, May 5, 2009 at 2:53 PM, Giorgos Keramidas > wrote: > > If you don't need local patches or a custom kernel, and you can use the > > GENERIC kernel configured to match your hardware setup, then it probably > > makes a lot of sense to use freebsd-update. šIt will usually be much > > faster than compiling everything from source. > > I don't know if it's officially supported, but I did an hybrid upgrade > using freebsd-update for the base and building the custom kernel > from sources, it worked fine and is still much faster than build > everything. In principle, you can run into some errors, like KVM size mismatches (and other ABI changes) if your kernel (that you build from sources) and updated base will differ. But you'll immediately notice it ;)) And for most cases such way should work fine. My two cents. -- 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 Tue May 5 21:55: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 356991065689; Tue, 5 May 2009 21:55:56 +0000 (UTC) (envelope-from eitanadlerlist@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 45C168FC16; Tue, 5 May 2009 21:55:53 +0000 (UTC) (envelope-from eitanadlerlist@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so3651095qwe.7 for ; Tue, 05 May 2009 14:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=yx4brSKUDTB09SWwDxfsK92rS6enO9dX9V+R0m4vPbE=; b=mulAXzgx9iNdfP+/pDOJPwzP+t8pKWKvGpwlODTw2xEGJPBNUYNzjPsriXrgu+Wzol cKD1lXuBuVZkceodPf8w6KZ1LvkLgM7HLUyB3Ae4KGIn4SPntTikEEu/9UaVwfvG0qyl IrmChSUkjMRfI6KD42K0zaoktmVtToj7O3Z4E= 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:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=t2K1RwcYwUcWXGOd9xNhXuUyDAydBj8jbShBo7K/o/i4RV86qR6fB4K1i1sGgGFycS 1QN9YNOAydqGLsLuU4RAgJGt5yeHmBhRlJSSzaG2FTZagoOETQUWvPlcrS33urtNcXOF gQCpE+GoJG6+cA4TOHapREW+VONtCanh1aL6U= Received: by 10.224.2.202 with SMTP id 10mr723225qak.336.1241558952496; Tue, 05 May 2009 14:29:12 -0700 (PDT) Received: from aargh.lan (ool-182fcc8b.dyn.optonline.net [24.47.204.139]) by mx.google.com with ESMTPS id 5sm3549213ywl.22.2009.05.05.14.29.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 14:29:12 -0700 (PDT) Message-ID: <4A00AFEB.7010001@gmail.com> Date: Tue, 05 May 2009 17:30:19 -0400 From: Eitan Adler User-Agent: Mozilla (X11; U; FreeBSD i386; en-US; ) Gecko Thunderbird Mnenhy/0.7.6.666 MIME-Version: 1.0 To: mcdouga9@egr.msu.edu References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> In-Reply-To: <20090504011421.GI6901@egr.msu.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=E9C2CCD1; url=pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 21:55:56 -0000 Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > Could some of these tips get added to 11.15 Power and Resource Management? I'm sure many people who don't regularly read the mailing lists would like to use these tips. -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From owner-freebsd-current@FreeBSD.ORG Tue May 5 22:31: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 A09D7106566B for ; Tue, 5 May 2009 22:31:54 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 023428FC12 for ; Tue, 5 May 2009 22:31:52 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n45MQbtU011162; Wed, 6 May 2009 07:56:37 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.1) with ESMTP id ; Wed, 6 May 2009 08:01:51 +0930 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 08:01:51 +0930 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 06:31:50 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n45MTwkv016560; Wed, 6 May 2009 06:29:58 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n45MTwH4016559; Wed, 6 May 2009 06:29:58 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 6 May 2009 06:29:58 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Message-ID: <20090505222958.GK12123@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-acpi@freebsd.org References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> <4A00AFEB.7010001@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4A00AFEB.7010001@gmail.com> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 05 May 2009 22:31:50.0690 (UTC) FILETIME=[489D5820:01C9CDD1] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.600.1016-16624.002 X-TM-AS-Result: No--0.480900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 May 2009 22:31:54 -0000 0n Tue, May 05, 2009 at 05:30:19PM -0400, Eitan Adler wrote: >Adam McDougall wrote: >> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: >> >> I would like to summarize some of my knowledge on reducing FreeBSD power >> consumption and describe some new things I have recently implemented in >> 8-CURRENT. The main character of this story is my 12" Acer TravelMate >> 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under >> amd64 8-CURRENT. >> >Could some of these tips get added to 11.15 Power and Resource >Management? I'm sure many people who don't regularly read the mailing >lists would like to use these tips. I agree. This was an extremely useful and informative thread of discussion to read. (Now how to remember it all ?) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed May 6 00:48: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 5B913106566B for ; Wed, 6 May 2009 00:48:06 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from mx-2.btshosting.co.uk (mx-2.btshosting.co.uk [87.117.208.79]) by mx1.freebsd.org (Postfix) with ESMTP id DC21D8FC19 for ; Wed, 6 May 2009 00:48:05 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.1.65] (host86-139-98-149.range86-139.btcentralplus.com [86.139.98.149]) (Authenticated sender: bazerka@beardz.net) by mx-2.btshosting.co.uk (Postfix) with ESMTPA id E59476E54DA for ; Wed, 6 May 2009 01:33:18 +0100 (BST) Message-ID: <4A00DACA.1010500@beardz.net> Date: Wed, 06 May 2009 01:33:14 +0100 From: Jase Thew User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------020406020706010106050908" X-Virus-Scanned: clamav-milter 0.95.1 at mx-2.btshosting.co.uk X-Virus-Status: Clean Subject: Another USB mouse failing to attach with current, post-USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 00:48:06 -0000 This is a multi-part message in MIME format. --------------020406020706010106050908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I installed 8.0-CURRENT a few months ago to test it with the hardware in my machine. Everything worked fine until USB2 replaced USB in the tree, and upon a rebuild, my Razer Copperhead USB mouse stopped attaching to ums. I've updated my sources and rebuilt everything around 3 hours ago to ensure that I'm up-to-date with HEAD. Please find attached the relevant lines from my verbose dmesg.boot and also usbconfig outputs for the device. The mouse itself doesn't conform to the HID spec somewhat ( see usb/118670 [1] for some history ) so it has to rely on the hid_is_collection test rather than reading the descriptor direct in the ums probe routine. However, the hid_is_collection test now fails since USB2 replaced USB. I've tested with my kludge patch from usb/118670 and the mouse works perfectly with it, so USB2 supports the mouse fine apart from the hid_is_collection test no longer recognising it. If any additional info is required, I'll be happy to supply it. Thanks in advance, Jase. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 --------------020406020706010106050908 Content-Type: text/plain; name="verbose_dmesg_snippet.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="verbose_dmesg_snippet.txt" uhci0: port 0xd000-0xd01f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xd100-0xd11f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd100 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 uhci2: port 0xd500-0xd51f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd500 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x0f10 usbus2: on uhci2 ehci0: mem 0xea205000-0xea2053ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xea205000 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 uhci3: port 0xd200-0xd21f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd200 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x003a usbus4: on uhci3 uhci4: port 0xd300-0xd31f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd300 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x0010 usbus5: on uhci4 uhci5: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x0010 usbus6: on uhci5 ehci1: mem 0xea204000-0xea2043ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xea204000 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen0.2: at usbus0 uhub8: on usbus0 ugen1.2: at usbus1 uhid0: on usbus1 uhub8: 3 ports with 0 removable, bus powered ugen2.2: at usbus2 uhid1: on usbus2 ukbd0: on usbus2 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ukbd_set_leds_callback:554: error=USB_ERR_STALLED ugen0.3: at usbus0 ukbd1: on usbus0 kbd3 at ukbd1 kbd3: ukbd1, generic (0), config:0x0, flags:0x3d0000 ugen0.4: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=2 ugen2.3: at usbus2 uhub9: on usbus2 ugen0.5: at usbus0 uhub9: 4 ports with 2 removable, bus powered ugen2.4: at usbus2 ukbd2: on usbus2 kbd: new array size 8 kbd4 at ukbd2 kbd4: ukbd2, generic (0), config:0x0, flags:0x3d0000 uhid2: on usbus2 --------------020406020706010106050908 Content-Type: text/plain; name="usbconfig-request.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usbconfig-request.txt" sheesh8# usbconfig -u 2 -a 2 do_request 0x81 0x06 0x2200 0 0x100 REQUEST = <0x05 0x01 0x09 0x02 0xa1 0x01 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x07 0x15 0x00 0x25 0x01 0x95 0x08 0x75 0x01 0x81 0x02 0x06 0x00 0xff 0x09 0x40 0x95 0x02 0x75 0x08 0x15 0x81 0x25 0x7f 0x81 0x02 0x05 0x01 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01 0x81 0x06 0x09 0x30 0x09 0x31 0x16 0x00 0x80 0x26 0xff 0x7f 0x75 0x10 0x95 0x02 0x81 0x06 0xc0 0xc0><)%u@u%8%u01&u> --------------020406020706010106050908 Content-Type: text/plain; name="usbconfig-desc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usbconfig-desc.txt" ugen2.2: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x1532 idProduct = 0x0101 bcdDevice = 0x2100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x003b bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0002 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x09, 0x21, 0x01, 0x10, 0x00, 0x01, 0x22, 0x49, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0001 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x09, 0x21, 0x01, 0x10, 0x00, 0x01, 0x22, 0x2f, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0008 bRefresh = 0x0000 bSynchAddress = 0x0000 --------------020406020706010106050908-- From owner-freebsd-current@FreeBSD.ORG Wed May 6 01:54: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 A1DC41065672 for ; Wed, 6 May 2009 01:54:53 +0000 (UTC) (envelope-from robillard.etienne@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 597C18FC1E for ; Wed, 6 May 2009 01:54:52 +0000 (UTC) (envelope-from robillard.etienne@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so2951650ana.13 for ; Tue, 05 May 2009 18:54:52 -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:subject :message-id:organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=+Ap67PkL/ykewF0G9I1zZQcAFIdcDsBtdoKttEh//Ik=; b=aTWcxDFknK7Bpl68qels4x2lD0oSBIy3J3XY6+BJRdbSz5ojPKYJPN0CergouZwk3e 4Y2Nw5WLFQ/3b7zMe+2xR+dmai9zfX1lMK24hEAWMESA+eFqct6uTr8BRE/6kyAWV80z Q3BBC8/Ynw5H7vgMOtq0kqJNWentivrEKl29Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:organization:x-mailer:mime-version :content-type:content-transfer-encoding; b=mVIRSK0sPXF5zETL1hV0EnsAO9Kxaxfc9oeJeXdb5G12h2WRrODsPW58df7WS/9ILX 9nZOKmEpVQCcLXdlLNEN36f+XY4ZQImrgnp2lc7QgolDO1HF+elL5Zjp1GjJDE/ed+Yq gk0dr+v8dD/OvCk/aIjqmEUlllI7m35t9/xQc= Received: by 10.100.92.17 with SMTP id p17mr1347111anb.138.1241573322924; Tue, 05 May 2009 18:28:42 -0700 (PDT) Received: from marina (modemcable236.244-82-70.mc.videotron.ca [70.82.244.236]) by mx.google.com with ESMTPS id c9sm1440049ana.14.2009.05.05.18.28.41 (version=SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 18:28:42 -0700 (PDT) Date: Tue, 5 May 2009 21:27:04 -0400 From: Etienne Robillard To: freebsd-current@freebsd.org Message-ID: <20090505212704.411fac32@marina> Organization: Green Tea Hackers Club X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Upgrading to gnome 2.26 problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 01:54:54 -0000 Hi, I have some problems running gnome-session 2.26 on freebsd8. It appears that dbus is missing a required library and so makes gnome-session unusable. I also have some difficulties building hal, and thought it might be related. Plus, it was running fine on 2.24. Problems started when upgrading with portupgrade gnome to 2.26. So I was thinking that perhaps i need to make another buildworld since it might depends on recent libusb changes, but I'm just guessing. Would there be an alternative or quick fix for avoiding the buildworld/installworld step or is there something in -CURRENT that is required for upgrading fully to gnome 2.26 ? Thanks in advance for your help, erob N.B: I have the following packages installed: libusb-0.1.12_4 xorg-server-1.5.3_6,1 gnome-session-2.26.1 dbus-1.2.4.4 dbus-glib-0.80 X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT i386 Current Operating System: FreeBSD marina 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Feb 25 22:26:21 EST 2009 root@marina:/usr/src/sys/i386/compile/GENERIC i386 Build Date: 07 March 2009 04:15:25PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat May 2 00:31:50 2009 (==) Using config file: "/etc/X11/xorg.conf" encoder: 0x4 encoder: 0x2 encoder: 0x5 XRANDR name: VGA-0 Connector: VGA CRT1: INTERNAL_DAC1 DDC reg: 0x64 XRANDR name: DVI-0 Connector: DVI-I CRT2: INTERNAL_DAC2 DFP1: INTERNAL_TMDS1 DDC reg: 0x68 finished output detect: 0 Dac detection success Unhandled monitor type 0 finished output detect: 1 finished all detect before xf86InitialConfiguration Dac detection success Unhandled monitor type 0 after xf86InitialConfiguration Entering TV Save Save TV timing tables saveTimingTables: reading timing tables TV Save done disable primary dac disable primary dac disable primary dac init memmap init common init crtc1 init pll1 freq: 135000000 best_freq: 135000000 best_feedback_div: 20 best_ref_div: 2 best_post_div: 2 restore memmap restore common restore crtc1 restore pll1 finished PLL1 set RMX set primary dac enable primary dac The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". gnome-session[15174]: WARNING: Could not connect to ConsoleKit: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory gnome-session[15174]: CRITICAL: dbus_g_connection_get_connection: assertion `gconnection' failed process 15174: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 3298. This is normally a bug in some application using the D-Bus library. D-Bus not compiled with backtrace support so unable to print a backtrace gnome-session[15174]: ******************* START ******************************** gnome-session[15174]: Frame 0: 0x805f7d3 <_init+70079> at gnome-session gnome-session[15174]: Frame 1: 0xbfbfffb4 gnome-session[15174]: Frame 2: 0x2903440a at /lib/libc.so.7 gnome-session[15174]: Frame 3: 0x286a8f85 <_dbus_abort+53> at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 4: 0x286a4b56 <_dbus_warn_check_failed+134> at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 5: 0x2868d528 at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 6: 0x8057a2b <_init+37911> at gnome-session gnome-session[15174]: Frame 7: 0x8057b0a <_init+38134> at gnome-session gnome-session[15174]: Frame 8: 0x8060a5c <_init+74824> at gnome-session gnome-session[15174]: Frame 9: 0x8060fd4 <_init+76224> at gnome-session gnome-session[15174]: Frame 10: 0x80503c9 <_init+7605> at gnome-session gnome-session[15174]: ******************* END ********************************** waiting for X server to shut down disable primary dac finished PLL2 finished PLL1 Entering Restore TV Restore TV PLL Restore TVHV Restore TV Restarts Restore Timing Tables Restore TV standard Leaving Restore TV From owner-freebsd-current@FreeBSD.ORG Wed May 6 03:28: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 351C2106567B; Wed, 6 May 2009 03:28:40 +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 B0D898FC14; Wed, 6 May 2009 03:28:39 +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 8A62819906F; Wed, 6 May 2009 05:28:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7D5EF19906E; Wed, 6 May 2009 05:28:33 +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 6855619906A; Wed, 6 May 2009 05:28:33 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050605283190-208 ; Wed, 6 May 2009 05:28:31 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 6 May 2009 05:28:32 +0200 Date: Wed, 6 May 2009 05:28:32 +0200 From: Alexey Shuvaev To: Eygene Ryabinkin Message-ID: <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> MIME-Version: 1.0 In-Reply-To: <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> 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.2HF443 | November 25, 2008) at 05/06/2009 05:28:31 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/06/2009 05:28:32 AM, Serialize complete at 05/06/2009 05:28:32 AM 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, openoffice@FreeBSD.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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: Wed, 06 May 2009 03:28:40 -0000 On Tue, May 05, 2009 at 10:59:01PM +0400, Eygene Ryabinkin wrote: > Alexey, good day. > > Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > > The reason appeared to be the first part of the command > > "gunzip -c ... | ( tar -xf - ) && touch ..." > > which exited with non-zero exit status (141) and "touch ..." was not called. > > Running the command manually has showed that gunzip was complaining about > > broken pipe (however the archive was extracted successfully). > > Yes, 141 means that SIGPIPE was delivered. This in turn means that > 'tar -xf -' exited before gunzip had finished its job and gunzip had > tried to write more data to the pipe. > > Could I ask to do some debugging: > > 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' > Ok so far. > 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the results. > Ok: ~/tmp> cat crystal.tar | ( tar -xf - ) && echo OK OK > 3. do 'md5 ooo_crystal_images-1.tar.gz' > ~/tmp> md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > For the last point, I have > ----- > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > ----- > but this tar.gz was taken from OOO 3.x. If yours have some other > checksum, could you place it somewhere where I can download it? > Mmmm... not so easy... German universities are not so internet friendly... fsck... But it was taken from official openoffice.org2/OOo_OOH680_m18_source.tar.bz2 tarball... Ping me if it is download error. > My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of May. > > Thanks! > I'm running amd64 Core2Duo processor with SMP kernel. Can it be that 2 processes (gunzip and tar) are running on different cpu-s and this is some race condition? Not triggered before? > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > _______________________________________________ > 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 6 05:00: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 58BEB106566B for ; Wed, 6 May 2009 05:00:21 +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 03D698FC0C for ; Wed, 6 May 2009 05:00:20 +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 n464xsxr002387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 6 May 2009 04:59:54 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: current@freebsd.org In-Reply-To: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 6 May 2009 01:00:09 -0400 References: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Subject: Re: [patch] corrupt memstat_kvm_malloc(3) output and dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 05:00:21 -0000 On May 5, 2009, at 10:18 AM, Ben Kelly wrote: > While debugging a problem recently with Alexander Leidinger we > noticed that crashinfo(8) was producing corrupt vmstat -m output. > After doing some digging it appears that memstat_kvm_malloc(3) might > have been broken by this commit: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=179222 > > The problem is that memstat_kvm_malloc(3) assumes that > malloc_type_internal starts with an array of malloc_types_stats > structures. This assumption is no longer true, though, as > mti_probes was inserted at the start of the structure. > > It appears that this (untested) patch might fix the problem: > > http://www.wanderview.com/svn/public/misc/zfs/vmstat_kvm_malloc.diff > > I'm not very familiar with dtrace, though. Does anyone know if this > would cause problems? Just FYI, I was able to recompile and test this patch tonight. It seems to have fixed vmstat -M $core -m output on my machine. - Ben From owner-freebsd-current@FreeBSD.ORG Wed May 6 08:22: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 49398106567B for ; Wed, 6 May 2009 08:22:41 +0000 (UTC) (envelope-from Achim_Leubner@adaptec.com) Received: from mail-gw3.adaptec.com (ts.adaptec.com [162.62.93.58]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA5D8FC19 for ; Wed, 6 May 2009 08:22:38 +0000 (UTC) (envelope-from Achim_Leubner@adaptec.com) Received: from ADPE2K702.adaptec.com (adpe2k702.adaptec.com [10.25.8.26]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 5990A2C3E5F; Wed, 6 May 2009 01:04:37 -0700 (PDT) Received: from ADPE2K703.adaptec.com ([10.25.8.22]) by ADPE2K702.adaptec.com ([10.25.8.26]) with mapi; Wed, 6 May 2009 01:04:37 -0700 From: "Leubner, Achim" To: Ed Maste , Scott Long Date: Wed, 6 May 2009 01:04:34 -0700 Thread-Topic: softdep_move_dependencies panic Thread-Index: AcnOIUrnZ74iDoM2TJSMQhruAukIdg== Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "current@freebsd.org" , "Sridaran, Gana" Subject: softdep_move_dependencies panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 08:22:41 -0000 Hi Ed, Hi Scott, We run into a problem if a RAID array goes into an "error" state and is mar= ked "offline". The new aac driver removes the device in this case with devi= ce_delete_child() and all commands to that device will be answered using bi= odone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_mo= ve_dependencies: need merge code" panic in the filesystem. Is there any pos= sibility to avoid this panic? We see it under FreeBSD 7.1 too. Any help is greatly appreciated. Thanks & Regards, Achim =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 Achim Leubner Software Engineer / RAID drivers ICP vortex GmbH / Adaptec Inc. Phone: +49-351-8718291 From owner-freebsd-current@FreeBSD.ORG Wed May 6 09: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 87385106566C for ; Wed, 6 May 2009 09:19:32 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 454748FC13 for ; Wed, 6 May 2009 09:19:32 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 626669B64A; Wed, 6 May 2009 11:19:31 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 55FC99B644; Wed, 6 May 2009 11:19:15 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Wed, 6 May 2009 05:19:09 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> In-Reply-To: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905060519.10151.zec@icir.org> Cc: Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 09:19:32 -0000 On Monday 04 May 2009 10:57:32 Paul B. Mahol wrote: > On 5/4/09, Marko Zec wrote: > > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: > > ... > > > >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean > >> /usr/obj/? (I dont have VIMAGE enabled) > > > > You should rebuild your userland regardless whether options VIMAGE in the > > kernel has been enabled or not, see the UPDATING note for details. > > I did, but I will ask again do I need to clean /usr/obj/? No you don't. Could you post the output from 'netstat -r' with pre- and post-r191816 kernel + world builds? Marko From owner-freebsd-current@FreeBSD.ORG Wed May 6 09:50: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 E01EB10656DB for ; Wed, 6 May 2009 09:50:13 +0000 (UTC) (envelope-from onemda@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 6AB188FC08 for ; Wed, 6 May 2009 09:50:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so5136824bwz.43 for ; Wed, 06 May 2009 02:50:12 -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=P2+MenyDzC25+yMUXWNMh1vE+CQcTFhFP52LaHl81zY=; b=YoN2E8aJsyP0VTXUJfXrtVBmzYmNlcejrGXdYmV2r9yvka0tnlrygmltoHcTbNnhvj 3kBlH0VYOFRE0jmo31MIQWuZOQJKeUBKaniQDJGkMMfYj3RJ3kDg/SzIIhRzh44nS48q BOsFM/XruHRVKx8QoubHY3iK5lMjpSPz9khdw= 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=KmoLV5vR/bZKsEImHSNaboaFGJSDdpsiwytx+nQ6bpcCsqMVLKSBNIXQjjdp8/dd3c 3R0oFqQ9FQmUnfb94jm82mhYobquTAQKn9E79Wpdh96ffxP8X1qLYQjJJf2BGQefldsZ NevP/YYG5HJU7koIlaOr9hjaVdPoZjhmtU+u0= MIME-Version: 1.0 Received: by 10.239.172.12 with SMTP id y12mr66817hbe.35.1241603412443; Wed, 06 May 2009 02:50:12 -0700 (PDT) In-Reply-To: <200905060519.10151.zec@icir.org> References: <49FC812B.2070305@elischer.org> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> <200905060519.10151.zec@icir.org> Date: Wed, 6 May 2009 11:50:12 +0200 Message-ID: <3a142e750905060250t394ada5bl2798c79b18855746@mail.gmail.com> From: "Paul B. Mahol" To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 09:50:14 -0000 On 5/6/09, Marko Zec wrote: > On Monday 04 May 2009 10:57:32 Paul B. Mahol wrote: >> On 5/4/09, Marko Zec wrote: >> > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: >> > ... >> > >> >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >> >> /usr/obj/? (I dont have VIMAGE enabled) >> > >> > You should rebuild your userland regardless whether options VIMAGE in >> > the >> > kernel has been enabled or not, see the UPDATING note for details. >> >> I did, but I will ask again do I need to clean /usr/obj/? > > No you don't. > > Could you post the output from 'netstat -r' with pre- and post-r191816 > kernel > + world builds? It was caused by NO_CLEAN=1 option in make.conf(I guess) or I broke it with some other "make install" command under /usr/src .... Clearing /usr/obj/ fixed it. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed May 6 10:06:10 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 614E31065690 for ; Wed, 6 May 2009 10:06:10 +0000 (UTC) (envelope-from odhiambo@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 D5B768FC28 for ; Wed, 6 May 2009 10:06:09 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz9 with SMTP id 9so5145480bwz.43 for ; Wed, 06 May 2009 03:06: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; bh=pEa0C3aFWY7v2Ck9JVhdplRmUa5sasjdqGAdRHpaze0=; b=M+8qqoSbUmcWdy3UqrVfZDwsOCTgh8fRdwjThrFJlTSWW0dgUnlO/0RAOmcDxWkPYc g7qoBAoKMyvyfm32BUzuZyK5j5ZncQujdlIaX8fjX0LugvQyJZuTrw5TlvxFVs9vk5Z4 +oULjotL4Ve2zMubPTCGOi0CU3lK1YvN2U3UA= 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=Hz86LruWwEnhH50HrBCwdobVHtyOXmmxFrHalELORhjcfik0u83HcQFjfVC1wZAt0W 6xxYH0axw6CozNn0VPSm2dwOPQUekL/a15FIurh2RkcBgQD+QlNCQFIOmgnV/ee8MnJX uQMDtEp5+yBrO22eRzBd3L6Pp5caWxAq1alZQ= MIME-Version: 1.0 Received: by 10.223.124.147 with SMTP id u19mr330577far.28.1241604368464; Wed, 06 May 2009 03:06:08 -0700 (PDT) In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Date: Wed, 6 May 2009 13:06:08 +0300 Message-ID: <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 10:06:11 -0000 On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 10:13: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 9AD95106564A for ; Wed, 6 May 2009 10:13:07 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 308728FC1C for ; Wed, 6 May 2009 10:13:06 +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 mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n46AD22T012334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 20:13:03 +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 n46AD26l019020 for ; Wed, 6 May 2009 20:13:02 +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 n46AD2eD019019 for freebsd-current@freebsd.org; Wed, 6 May 2009 20:13:02 +1000 (EST) (envelope-from peter) Date: Wed, 6 May 2009 20:13:02 +1000 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20090506101301.GA17874@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Subject: hardclock() sources X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 10:13:07 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Currently, FreeBSD uses the LAPIC timer to derive both hardclock() and statclock()/profclock() if it exists, otherwise it uses the 8254 and RTC. This presents a problem for using C3 - which stops the LAPIC clock. Some time ago, ariff@ produced a patch to work around a similar problem with C1E on some AMD Turion CPUs: http://people.freebsd.org/~ariff/misc/idlecpu_apic_5.diff A better solution would seem to be to use a HPET periodic timer. Is there a particular reason why code to (at least optionally) support HPET as the timer interrupt hasn't been written? Looking back through the archives, pkh@ has made disparaging remarks about the actual usefulness of HPET (as against the Intel documentation) but I can't find anything that actually talks about using it. Note that supporting HPET as a timer source would provide at least some of the infrastructure that will be needed for a future tickless kernel. --=20 Peter Jeremy --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoBYq0ACgkQ/opHv/APuIfLngCfbgRt+478eQO1CaAtCPltykir W2gAoI8Tga5coWvjU5X8wR7wDoRhy9x6 =rfRx -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-current@FreeBSD.ORG Wed May 6 10:16: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 2EDB2106566C for ; Wed, 6 May 2009 10:16:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E80B18FC2A for ; Wed, 6 May 2009 10:16:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BEEEB78CE0; Wed, 6 May 2009 10:16:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n46AGQxQ006173; Wed, 6 May 2009 10:16:26 GMT (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 06 May 2009 20:13:02 +1000." <20090506101301.GA17874@server.vk2pj.dyndns.org> Date: Wed, 06 May 2009 10:16:26 +0000 Message-ID: <6172.1241604986@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: hardclock() sources X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 10:16:29 -0000 In message <20090506101301.GA17874@server.vk2pj.dyndns.org>, Peter Jeremy write s: >A better solution would seem to be to use a HPET periodic timer. Part of the problem is discovering the timers location early enough. We have long (10 years) talked about doing (at least) two scans of the busses: First scan to allocate missing resources Second scan to get "important" hardware (console, timers) Third scan to find the rest. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed May 6 10:47: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 42F7A106564A for ; Wed, 6 May 2009 10:47:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2768FC0A for ; Wed, 6 May 2009 10:47:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6AF62CEA2E; Wed, 6 May 2009 03:47:59 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (unknown [24.114.252.238]) by idiom.com (Postfix) with ESMTP id 737E52D625A; Wed, 6 May 2009 03:47:58 -0700 (PDT) Message-ID: <4A016ADD.3060004@elischer.org> Date: Wed, 06 May 2009 03:47:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?UTF-8?B?T2RoaWFtYm8g44Ov44K344Oz44OI44Oz?= References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> In-Reply-To: <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Marko Zec , FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 10:47:59 -0000 Odhiambo ワシントン wrote: > > > On Sat, May 2, 2009 at 8:21 PM, Julian Elischer > wrote: > > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they > were before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) VImage code is in -current (hence the -current mailing list) so it is not in 7.2. HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow you to substitute in a 7.2 VIMAGE kernel and play with it.. I'll let Marko give you the details. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > "Clothes make the man. Naked people have little or no influence on > society." > -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 10: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 69F0F1065673 for ; Wed, 6 May 2009 10:50:53 +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 29C8A8FC22 for ; Wed, 6 May 2009 10:50:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from rebelion.Sisis.de (cazador.sisis.de [193.31.11.193]) by dd12710.kasserver.com (Postfix) with ESMTP id 8FBDD185145D6 for ; Wed, 6 May 2009 12:19:35 +0200 (CEST) Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n46AJWxH007609 for freebsd-current@freebsd.org; Wed, 6 May 2009 12:19:32 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Wed, 6 May 2009 12:19:32 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090506101932.GA7414@rebelion.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 7.0-STABLE (i386) Subject: problems with BTX loader booting -CURRENT from USB key 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: Wed, 06 May 2009 10:50:53 -0000 Hello, I've just got a new laptop Dell Precision M4400 and will install -CURRENT on it from a prepared USB key. While booting from the USB the BTX loader (1.00, BTX version 1.02) brings up as usual the menu with the numbers 1-6 for the boot form and counts down the time; until here total normal; but: - when you let it count to zero it tries to start the kernel and only one char of the rotating -/|\ is printed, nothing more happens; - when you just press any of the numbers it gives the same result; - when you press SPACE to stop the countdown and then any number it boots fine; any idea what is wrong of what could I check for more information? Thanks 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 Wed May 6 11:37: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 822AF106566C for ; Wed, 6 May 2009 11:37:26 +0000 (UTC) (envelope-from odhiambo@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 0F9F48FC22 for ; Wed, 6 May 2009 11:37:25 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by fxm12 with SMTP id 12so38841fxm.43 for ; Wed, 06 May 2009 04:37:25 -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=w51ieHv1cBZK30o7BbgQhXUP7hx3QVdr7TYwrVSZ9ss=; b=JQjeITeNnp1iLkd3U1ECh9L5oSGfECAh+4gq5na6oKbpCAuGb6mBm8GKYPvAwLmihQ 8pcIlh0NiL9TbzZw3LoPK7w6sKipDz1O9+VsXhNFFKn/CdLpBqYppPcDVbTbd+v/Lqj3 JiPUVIppws6/3zwUZWPn63xfik25Lr+hVLNlA= 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=mOw8KjX8+5oF08mi18BNEXNkm6KZwQSkTJP+e5S3ovQN8oC1c1bLyQ7pQsDI7Z9ZTy HqwHY8Ocnsx+pIjJSLsNK3UHGhtanIk0dRaSTV66Iczo3ewohzOukoH1wrcm+ImiYhwh F+TDsmqntX43VnlPPa9yJMAvZc/qx5laBFi9s= MIME-Version: 1.0 Received: by 10.223.108.210 with SMTP id g18mr877253fap.38.1241609845016; Wed, 06 May 2009 04:37:25 -0700 (PDT) In-Reply-To: <4A016ADD.3060004@elischer.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> Date: Wed, 6 May 2009 14:37:24 +0300 Message-ID: <991123400905060437n56cacd9fk12ad1fc0b851b47c@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marko Zec , FreeBSD Current Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 11:37:26 -0000 2009/5/6 Julian Elischer > Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3 wrote: > >> >> >> On Sat, May 2, 2009 at 8:21 PM, Julian Elischer > julian@elischer.org>> wrote: >> >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they >> were before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> >> How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz := ) >> > > > VImage code is in -current (hence the -current mailing list) > so it is not in 7.2. > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow you > to substitute in a 7.2 VIMAGE kernel and play with it.. > I'll let Marko give you the details. > Looking forward to that. Thanks in advance. --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 11:43: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 2FBCD1065674 for ; Wed, 6 May 2009 11:43:59 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id E13648FC0C for ; Wed, 6 May 2009 11:43:58 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 33F579B644; Wed, 6 May 2009 13:43:57 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 287569B648; Wed, 6 May 2009 13:43:39 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Wed, 6 May 2009 07:43:32 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> In-Reply-To: <4A016ADD.3060004@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905060743.33045.zec@freebsd.org> Cc: Odhiambo =?utf-8?q?=E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3?= , Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 11:43:59 -0000 On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3 wrote: =2E.. > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz = :) > > VImage code is in -current (hence the -current mailing list) > so it is not in 7.2. > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > you to substitute in a 7.2 VIMAGE kernel and play with it.. > I'll let Marko give you the details. Hi, you should throw a look at this page for more details: http://imunes.tel.fer.hr/virtnet More specifically, you should download this tarball: http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz and then do the following: tpx32% cd src/sys/i386/conf/ tpx32% config VIMAGE tpx32% cd ../compile/VIMAGE/ tpx32% make depend; make tpx32% sudo make install tpx32% cd ~/tmp/src/usr.sbin/vimage/ tpx32% make clean; make tpx32% sudo make install Good luck, Marko From owner-freebsd-current@FreeBSD.ORG Wed May 6 12: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 D13E010656AD for ; Wed, 6 May 2009 12:06:08 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4988FC13 for ; Wed, 6 May 2009 12:06:08 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 9F4B69B644; Wed, 6 May 2009 14:06:07 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id A21BC9B645; Wed, 6 May 2009 14:05:49 +0200 (CEST) From: Marko Zec To: Odhiambo =?utf-8?q?=E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3?= Date: Wed, 6 May 2009 08:05:43 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <200905060743.33045.zec@freebsd.org> <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> In-Reply-To: <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905060805.43835.zec@freebsd.org> Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 12:06:11 -0000 On Wednesday 06 May 2009 08:01:24 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3= =83=88=E3=83=B3 wrote: > 2009/5/6 Marko Zec =2E.. > > Hi Marko, > > Thank you. I am gonna play with this. I had seen this page - > http://imunes.tel.fer.hr/virtnet/ but there is a static link there that > points only to vimage_7_20090401.tgz, so perhaps you can change that to > point the others to a location with the latest sources? I've updated the link already when I uploaded the new tarball, so perhaps=20 you've been looking at a cached page? Anyhow, both vimage_7_20090401.tgz a= nd=20 vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 userland. Marko From owner-freebsd-current@FreeBSD.ORG Wed May 6 12: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 ED29A1065670; Wed, 6 May 2009 12:19:44 +0000 (UTC) (envelope-from odhiambo@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 46DA18FC1D; Wed, 6 May 2009 12:19:43 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by fxm12 with SMTP id 12so62442fxm.43 for ; Wed, 06 May 2009 05:19: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=1mMd7Z9c19Drsov40f/9IT692hFZkXtjVXexWfSEiYY=; b=UIOgs8F5fNEiElaYI5tw6IwT/c8XzK1Xp/KcFfmJlhgf5BFIHnRU6RPG+6CPrjW8tv EiBdQqj2C0DhHIY5OzRLCy0xAVbNHutenwp2JeFQSZObT2kJYzpxfiO0Hx7K0hklB83O w8LyNH5sv23VKQB6DAAW5B4QgU5MgJYgRMnrA= 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=vk53N4+4IVHsKu2De+R4nU9wUKzRtpihI5y1AxPys4Dm8Z+CRY8y5TLKZqkboKK3OQ 3i5gtVxhGncl6ihVJC/p55j8gfquHEVN6bctPTF6hdSjYsctl8I02zZVAAo07Mm0gkTd nuaeBW1Iml3lu6r+Mgg5yY6uGmzO2CQ5I8vdE= MIME-Version: 1.0 Received: by 10.223.108.210 with SMTP id g18mr901810fap.38.1241612383092; Wed, 06 May 2009 05:19:43 -0700 (PDT) In-Reply-To: <200905060743.33045.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> <200905060743.33045.zec@freebsd.org> Date: Wed, 6 May 2009 15:19:43 +0300 Message-ID: <991123400905060519y635de314qe56e82972a9ee05a@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 12:19:45 -0000 2009/5/6 Marko Zec > On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > > Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3 wrote: > ... > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boy= z > :) > > > > VImage code is in -current (hence the -current mailing list) > > so it is not in 7.2. > > > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > > you to substitute in a 7.2 VIMAGE kernel and play with it.. > > I'll let Marko give you the details. > > Hi, > > you should throw a look at this page for more details: > > http://imunes.tel.fer.hr/virtnet > > More specifically, you should download this tarball: > > http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz > > and then do the following: > > tpx32% cd src/sys/i386/conf/ > tpx32% config VIMAGE > tpx32% cd ../compile/VIMAGE/ > tpx32% make depend; make > tpx32% sudo make install > tpx32% cd ~/tmp/src/usr.sbin/vimage/ > tpx32% make clean; make > tpx32% sudo make install > > Good luck, > > Marko > Okay. I found something that looks like a problem but that could be me as well. I have a custom kernel config file named BEASTIE-7.x (I hope there is nothing wrong with that naming as I have used it ever since FreeBSD 3.x). Now after diff-ing the GENERIC with BEASTIE-7x, I decided to edit VIMAGE to "include BEASTIE-7.x" instead of GENERIC. Here is what happens: FreeBSD-7# pwd /usr/home/wash/VIMAGE/src/sys/i386/conf FreeBSD-7# config VIMAGE config: VIMAGE:8: syntax error Alright, I wonder what is happening but line 8 has: include BEASTIE-7.x So I decided to cp BEASTIE-7.x BEASTIE Then I edited line 8 to remove the "-7.x" and... FreeBSD-7# config VIMAGE Kernel build directory is ../compile/VIMAGE Don't forget to do ``make cleandepend && make depend'' Now, again I looked further and I find that the problem actually is the ".x= " in the file name, because "include BEASTIE-7" does not give any error. Maybe it's not a problem at all. It's not a big problem for me, but maybe it's something known/unknown that can be fixed? Sorry to bug you this early:) --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 12:21: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 86805106568F for ; Wed, 6 May 2009 12:21:51 +0000 (UTC) (envelope-from odhiambo@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 015D88FC33 for ; Wed, 6 May 2009 12:21:50 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz9 with SMTP id 9so62025bwz.43 for ; Wed, 06 May 2009 05:21:49 -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=X8zVqEWlvjKru2vTGQzN4yUvqMuyYyULvv+4AYiLE9o=; b=x8o8pA0zJB+bRtYmHDSZyUsu61kPemv+5+uyeezoVVD1FDds7T5Jah0i7qoHJlrB// 0dAJQCKZQnyBNDQ7E+pMfBYmA0i2gSiWrQ5HcYxh8JhgjLC5tt8k0lV1mq7Cz5kDeVmA qpKI01pVRGBYBU2TP5X6lN1J5Hi4sdghBapmQ= 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=ly/3QpDhUiSBkBe7yWPyoHZrU/vWZ+mfTjII/K4zpNSnYep0rhBwEj2pRrKNcAQSsh UfP4URQbe4U+ZTuGSEKpIMe4xMvqbvzhijemp0XC2Mw92Z8g1U3PLyIjN1ZJS8fBT1TA NyUtGz9WBGDlCvS1fVxQDV3NLseZpBi+VI1yU= MIME-Version: 1.0 Received: by 10.223.122.15 with SMTP id j15mr924480far.10.1241611284200; Wed, 06 May 2009 05:01:24 -0700 (PDT) In-Reply-To: <200905060743.33045.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> <200905060743.33045.zec@freebsd.org> Date: Wed, 6 May 2009 15:01:24 +0300 Message-ID: <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 12:21:52 -0000 2009/5/6 Marko Zec > On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > > Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3 wrote: > ... > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boy= z > :) > > > > VImage code is in -current (hence the -current mailing list) > > so it is not in 7.2. > > > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > > you to substitute in a 7.2 VIMAGE kernel and play with it.. > > I'll let Marko give you the details. > > Hi, > > you should throw a look at this page for more details: > > http://imunes.tel.fer.hr/virtnet > > More specifically, you should download this tarball: > > http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz > > and then do the following: > > tpx32% cd src/sys/i386/conf/ > tpx32% config VIMAGE > tpx32% cd ../compile/VIMAGE/ > tpx32% make depend; make > tpx32% sudo make install > tpx32% cd ~/tmp/src/usr.sbin/vimage/ > tpx32% make clean; make > tpx32% sudo make install Hi Marko, Thank you. I am gonna play with this. I had seen this page - http://imunes.tel.fer.hr/virtnet/ but there is a static link there that points only to vimage_7_20090401.tgz, so perhaps you can change that to point the others to a location with the latest sources? Thank you. --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 12:55: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 CF40A1065687; Wed, 6 May 2009 12:55:04 +0000 (UTC) (envelope-from odhiambo@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 E0C818FC13; Wed, 6 May 2009 12:55:03 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz9 with SMTP id 9so80886bwz.43 for ; Wed, 06 May 2009 05:55:02 -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=DlfVqlfQGULHrctS0/beAop4yrNoKCd6xyvv3HxOCSc=; b=D8ZT1eoc+8XtYROQGh22Ik8cDMA5cGgmMUn2wsLJ4+j/TagIymZvE4z6X46sbYXVPo EuRYEZx7TOZYYlo/bD77jsg6L3AZ/m/vW+uBLz+gjsNMqNlqprGX7AbtyPiyotB+zxMI ebsBtLeeXFX5dSbjuO/cx8U/0okM66XLCVtQg= 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=cFjgTqC+vjAZQ5juEuashqa+LeXTwKgP4/KUkUeSRgVEpFmRbQmZyFIDFLtUX6Hhvt MECxbRLpoW47/WEmPODYuhpAlngXW1xUPrJHBBbqDkoT31Abspg3U5llNs6OA2l7pwu6 XTS4ZN0dZngXUK2gnrT3kb/wGcTYqaFen0Yg0= MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr898634fap.62.1241614502675; Wed, 06 May 2009 05:55:02 -0700 (PDT) In-Reply-To: <200905060805.43835.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <200905060743.33045.zec@freebsd.org> <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> <200905060805.43835.zec@freebsd.org> Date: Wed, 6 May 2009 15:55:02 +0300 Message-ID: <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 12:55:06 -0000 2009/5/6 Marko Zec > On Wednesday 06 May 2009 08:01:24 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3= =E3=83=88=E3=83=B3 wrote: > > 2009/5/6 Marko Zec > ... > > > > Hi Marko, > > > > Thank you. I am gonna play with this. I had seen this page - > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there that > > points only to vimage_7_20090401.tgz, so perhaps you can change that to > > point the others to a location with the latest sources? > > I've updated the link already when I uploaded the new tarball, so perhaps > you've been looking at a cached page? Anyhow, both vimage_7_20090401.tgz > and > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 userland= . I reloaded the link today and it's fine. Now, if only you can help me further, with the failure: =3D=3D=3D> zyd (depend) cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror ../../../netinet/in_proto.c -I../../../contrib/pf In file included from ../../../netinet/in_proto.c:88: ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types in declaration specifiers *** Error code 1 Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. My kernel file is here: http://gw.kictanet.or.ke/~wash/BEASTIE-7.txt --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 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 2CD78106564A for ; Wed, 6 May 2009 13:08:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id DE0158FC17 for ; Wed, 6 May 2009 13:08:07 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CF65619E043; Wed, 6 May 2009 15:08:05 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6390D19E044; Wed, 6 May 2009 15:08:03 +0200 (CEST) Message-ID: <4A018BB3.80302@quip.cz> Date: Wed, 06 May 2009 15:08:03 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Paul Stewart Subject: Re: 7.1 to 7.2 upgrade question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 13:08:08 -0000 Eygene Ryabinkin wrote: > Renato, [...] >>I don't know if it's officially supported, but I did an hybrid upgrade >>using freebsd-update for the base and building the custom kernel >>from sources, it worked fine and is still much faster than build >>everything. > > > In principle, you can run into some errors, like KVM size mismatches > (and other ABI changes) if your kernel (that you build from sources) and > updated base will differ. But you'll immediately notice it ;)) And for > most cases such way should work fine. Just a question: How can kernel be different, if it is build from the same sources (7.2-RELEASE)? freebsd-update updates the sources too (if old sources are installed in /usr/src), or am I wrong? Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed May 6 13:13: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 C55C8106567B for ; Wed, 6 May 2009 13:13:59 +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 757418FC14 for ; Wed, 6 May 2009 13:13:59 +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=fqdmNMxiDOoq3d/4ABgtvE4VBDOKQq6XSLRtCbHbc7vhI8Xtc4UBOU6Pt3C5yS+/nVs2anJwy9lEAi83rkXIrffLatbxqtcQ/M9LsAe/e0Zsuptn7/q+gHWZ2R0mKKc8GT9xreIVs6QoG7NBddT2VFGEfxyTvvzmNOqMQw5k9fE=; Received: from amnesiac.at.no.dns ([91.78.118.163]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M1gwf-0002Ch-E9; Wed, 06 May 2009 17:13:57 +0400 Date: Wed, 6 May 2009 17:13:55 +0400 From: Eygene Ryabinkin To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> <4A018BB3.80302@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A018BB3.80302@quip.cz> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, Paul Stewart Subject: Re: 7.1 to 7.2 upgrade question 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, 06 May 2009 13:14:00 -0000 Wed, May 06, 2009 at 03:08:03PM +0200, Miroslav Lachman wrote: > Eygene Ryabinkin wrote: > > In principle, you can run into some errors, like KVM size mismatches > > (and other ABI changes) if your kernel (that you build from sources) and > > updated base will differ. But you'll immediately notice it ;)) And for > > most cases such way should work fine. > > Just a question: How can kernel be different, if it is build from the > same sources (7.2-RELEASE)? freebsd-update updates the sources too (if > old sources are installed in /usr/src), or am I wrong? If you are really checking out 7.2-RELEASE, then no, they can't be different. But you could checkout 7-STABLE and thus kernel might diverge from the world. -- 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 6 13:28: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 95C57106564A for ; Wed, 6 May 2009 13:28:08 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 25CA48FC14 for ; Wed, 6 May 2009 13:28:07 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id DC4C49B649; Wed, 6 May 2009 15:28:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 792359B644; Wed, 6 May 2009 15:27:48 +0200 (CEST) From: Marko Zec To: Odhiambo =?utf-8?q?=E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3?= Date: Wed, 6 May 2009 09:27:42 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <200905060805.43835.zec@freebsd.org> <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> In-Reply-To: <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905060927.42540.zec@freebsd.org> Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 13:28:08 -0000 On Wednesday 06 May 2009 08:55:02 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3= =83=88=E3=83=B3 wrote: > 2009/5/6 Marko Zec > > > On Wednesday 06 May 2009 08:01:24 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3= =E3=83=88=E3=83=B3 wrote: > > > 2009/5/6 Marko Zec > > > > ... > > > > > Hi Marko, > > > > > > Thank you. I am gonna play with this. I had seen this page - > > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there th= at > > > points only to vimage_7_20090401.tgz, so perhaps you can change that = to > > > point the others to a location with the latest sources? > > > > I've updated the link already when I uploaded the new tarball, so perha= ps > > you've been looking at a cached page? Anyhow, both vimage_7_20090401.t= gz > > and > > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 > > userland. > > I reloaded the link today and it's fine. > Now, if only you can help me further, with the failure: > > =3D=3D=3D> zyd (depend) > cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 > -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dn= ow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > ../../../netinet/in_proto.c -I../../../contrib/pf > In file included from ../../../netinet/in_proto.c:88: > ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types in > declaration specifiers > *** Error code 1 > > Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. > > My kernel file is here: > http://gw.kictanet.or.ke/~wash/BEASTIE-7.txtsh/BEASTIE-7.txt> IPFILTER, ALTQ and most of the things that you have in your config file, bu= t=20 are not normally in GENERIC, are not yet supported with options VIMAGE. Marko From owner-freebsd-current@FreeBSD.ORG Wed May 6 13:59: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 CE950106564A; Wed, 6 May 2009 13:59:55 +0000 (UTC) (envelope-from odhiambo@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 286EA8FC0A; Wed, 6 May 2009 13:59:54 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by fxm12 with SMTP id 12so125381fxm.43 for ; Wed, 06 May 2009 06:59:54 -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=GPA6TxjZbhnLRwx9wIpLYLwmqZeHXyABQd8YltLSHWQ=; b=mCXuVnX+t+Cbckjd/uRbr4ExXEz+JrflkIWF8qjNVjDl8WxJNceHLRJRRoRnzKcmG7 VwISA5fSlsCgf2gnLZO3M6dUesvowAkOGAjQUbztV8DptCJ4dsHneKcPH+alh4vMPl3E XD72Lwcs2+c5EiOooVVQFBxTyHWf1JwZVttu4= 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=S6JzfsriG2QKpXBbR9hKsXq6CNEivqXuFZNRehSFoO6/+Yn7YfEiakEn8DopphDtPG dsA/PloMp3A8jMrRdhGifBfC8Vl9NJA9evTe2cvXNwMfqtnjWbZMEJ7b8lEkpHkn6hx8 qerh0RMBJNqeiopIMeVGckTBi97wsPyiXnQuI= MIME-Version: 1.0 Received: by 10.223.126.66 with SMTP id b2mr965215fas.67.1241618394054; Wed, 06 May 2009 06:59:54 -0700 (PDT) In-Reply-To: <200905060927.42540.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <200905060805.43835.zec@freebsd.org> <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> <200905060927.42540.zec@freebsd.org> Date: Wed, 6 May 2009 16:59:54 +0300 Message-ID: <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 13:59:56 -0000 2009/5/6 Marko Zec > On Wednesday 06 May 2009 08:55:02 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3= =E3=83=88=E3=83=B3 wrote: > > 2009/5/6 Marko Zec > > > > > On Wednesday 06 May 2009 08:01:24 Odhiambo =E3=83=AF=E3=82=B7=E3=83= =B3=E3=83=88=E3=83=B3 wrote: > > > > 2009/5/6 Marko Zec > > > > > > ... > > > > > > > Hi Marko, > > > > > > > > Thank you. I am gonna play with this. I had seen this page - > > > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there > that > > > > points only to vimage_7_20090401.tgz, so perhaps you can change tha= t > to > > > > point the others to a location with the latest sources? > > > > > > I've updated the link already when I uploaded the new tarball, so > perhaps > > > you've been looking at a cached page? Anyhow, both > vimage_7_20090401.tgz > > > and > > > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 > > > userland. > > > > I reloaded the link today and it's fine. > > Now, if only you can help me further, with the failure: > > > > =3D=3D=3D> zyd (depend) > > cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -= I. > > -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADE= RS > > -include opt_global.h -fno-common -finline-limit=3D8000 --param > > inline-unit-growth=3D100 --param large-function-growth=3D1000 > > -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3= dnow > > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > > ../../../netinet/in_proto.c -I../../../contrib/pf > > In file included from ../../../netinet/in_proto.c:88: > > ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types i= n > > declaration specifiers > > *** Error code 1 > > > > Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. > > > > My kernel file is here: > > http://gw.kictanet.or.ke/~wash/BEASTIE-7.txt > >sh/BEASTIE-7.txt> > > IPFILTER, ALTQ and most of the things that you have in your config file, > but > are not normally in GENERIC, are not yet supported with options VIMAGE. > So no firewall at all when using VIMAGE, right? --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Wed May 6 14:03: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 67364106564A for ; Wed, 6 May 2009 14:03:21 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 231898FC12 for ; Wed, 6 May 2009 14:03:20 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 36D7B9B645; Wed, 6 May 2009 16:03:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 254A69B648; Wed, 6 May 2009 16:02:54 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Wed, 6 May 2009 10:02:48 -0400 User-Agent: KMail/1.9.10 References: <49FC812B.2070305@elischer.org> <200905060927.42540.zec@freebsd.org> <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> In-Reply-To: <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905061002.49019.zec@freebsd.org> Cc: Odhiambo =?utf-8?q?=E3=83=AF=E3=82=B7=E3=83=B3=E3=83=88=E3=83=B3?= , Julian Elischer Subject: Re: VIMAGE status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 14:03:21 -0000 On Wednesday 06 May 2009 09:59:54 Odhiambo =E3=83=AF=E3=82=B7=E3=83=B3=E3= =83=88=E3=83=B3 wrote: =2E.. > > IPFILTER, ALTQ and most of the things that you have in your config file, > > but > > are not normally in GENERIC, are not yet supported with options VIMAGE. > > So no firewall at all when using VIMAGE, right? ipfw should work, at least to some extent. Marko From owner-freebsd-current@FreeBSD.ORG Wed May 6 15:21: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 364EB106566B; Wed, 6 May 2009 15:21:02 +0000 (UTC) (envelope-from mister.olli@googlemail.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 888378FC0C; Wed, 6 May 2009 15:21:01 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by ewy3 with SMTP id 3so227626ewy.43 for ; Wed, 06 May 2009 08:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=gXhWIWVt9Q7HU+LqJgIiydU6bx5wzagqcNGaIZL+fYo=; b=k8n8bccvypwAf1uVYC9+dPdB/Aykx/ICKDmyonPZR+zpArvKfYfWAo1cmRpw8udNGs AwwodEG5DXUPMToRF46SkBYj/VLplbtgy+wlnGp3mUDOFiJ8YKe/XR4ndHbh3O7Z6n9C NfFeRsc+sE6U8SMTD2mqIQU5dO+sLd5C/iCnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=KeCLGOQOj+nxD2QIC9YRCQ/r+Vn8SzRBjWOEHFdske/Vk5mi1gC7tscpjjNUcaTbbf DZ4kK8uwoQGgUzuvp41hP+IkZmKy5Fu0VO9cJNpz8a997ze0OlKsuxoIM8NPffBsYev5 Y1UJjWDtDN7J0p0kNZj+aWLGTFfdwE9b2Gyqs= Received: by 10.210.130.13 with SMTP id c13mr1680162ebd.94.1241623259400; Wed, 06 May 2009 08:20:59 -0700 (PDT) Received: from ?172.16.16.200? (dsl212102251063.4dsl.de [212.102.251.63]) by mx.google.com with ESMTPS id 7sm1842568eyg.7.2009.05.06.08.20.58 (version=SSLv3 cipher=RC4-MD5); Wed, 06 May 2009 08:20:58 -0700 (PDT) From: Mister Olli To: "freebsd-questions@freebsd.org" Content-Type: text/plain Date: Wed, 06 May 2009 17:20:54 +0200 Message-Id: <1241623255.12407.6.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Assign IP address and hostname via kernel parameter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.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, 06 May 2009 15:21:02 -0000 Hi, is there a way to configure IP address and hostname on freebsd systems via kernel command line parameters? I have some freebsd systems in as xen domU's and it would be really great to be able to set the ip address & hostname within the configuration file for the domU. I'm aware that I could configure a static mac address and use DHCP, but with several layer2 segments on different XEN hosts setting up DHCP correctly would be a real pain ;-) --- Regards Mr. Olli From owner-freebsd-current@FreeBSD.ORG Wed May 6 15:47: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 A4F2A1065701; Wed, 6 May 2009 15:47:42 +0000 (UTC) (envelope-from jt@0xabadba.be) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 139F98FC1B; Wed, 6 May 2009 15:47:41 +0000 (UTC) (envelope-from jt@0xabadba.be) Received: by ewy3 with SMTP id 3so255427ewy.43 for ; Wed, 06 May 2009 08:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.209 with SMTP id 59mr783418wep.213.1241623627220; Wed, 06 May 2009 08:27:07 -0700 (PDT) X-Originating-IP: [192.52.218.40] In-Reply-To: <1241623255.12407.6.camel@phoenix.blechhirn.net> References: <1241623255.12407.6.camel@phoenix.blechhirn.net> From: jt@0xabadba.be Date: Wed, 6 May 2009 11:26:47 -0400 Message-ID: To: mister.olli@googlemail.com 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, "freebsd-questions@freebsd.org" Subject: Re: Assign IP address and hostname via kernel parameter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 15:47:43 -0000 Hi, I would take a look at sysctl this system takes care of kernel parameters. There are a few man pages that delineate what is read only. I'm sure you are aware of setting the hostname at boot time. It seemed like you were more curious about on the fly. I'm not familiar with xen domU's hope this helps, =jt On Wed, May 6, 2009 at 11:20 AM, Mister Olli wrote: > Hi, > > is there a way to configure IP address and hostname on freebsd systems > via kernel command line parameters? > > I have some freebsd systems in as xen domU's and it would be really > great to be able to set the ip address & hostname within the > configuration file for the domU. > > I'm aware that I could configure a static mac address and use DHCP, but > with several layer2 segments on different XEN hosts setting up DHCP > correctly would be a real pain ;-) > > --- > Regards > Mr. Olli > > _______________________________________________ > 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 6 16:55: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 57F0C106564A for ; Wed, 6 May 2009 16:55:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6E08FC12 for ; Wed, 6 May 2009 16:55:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n46GthIr076814; Wed, 6 May 2009 10:55:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A01C10F.4060805@samsco.org> Date: Wed, 06 May 2009 10:55:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "Leubner, Achim" References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> In-Reply-To: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Ed Maste , "current@freebsd.org" , "Sridaran, Gana" Subject: Re: softdep_move_dependencies panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 16:55:54 -0000 No, there is no fix for this. FreeBSD doesn't handle this case very well. What I would suggest doing is keeping the logical representation of the device around, but indicate that it has failed. Then complete all i/o with good status. This is something that is being worked on, but I have no information on when it might be fixed. Scott Leubner, Achim wrote: > Hi Ed, Hi Scott, > > > > We run into a problem if a RAID array goes into an “error” state and is > marked “offline”. The new aac driver removes the device in this case > with device_delete_child() and all commands to that device will be > answered using biodone() with flag BIO_ERROR and error EINVAL. But this > causes a “softdep_move_dependencies: need merge code” panic in the > filesystem. Is there any possibility to avoid this panic? We see it > under FreeBSD 7.1 too. > > Any help is greatly appreciated. > > > > Thanks & Regards, > > Achim > > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > > From owner-freebsd-current@FreeBSD.ORG Wed May 6 17:04: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 D9CD01065674 for ; Wed, 6 May 2009 17:04:58 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id A7B428FC1B for ; Wed, 6 May 2009 17:04:58 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1M1kYD-0002lw-Qf for freebsd-current@freebsd.org; Wed, 06 May 2009 10:04:57 -0700 Message-ID: <23411239.post@talk.nabble.com> Date: Wed, 6 May 2009 10:04:57 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <49FF6C11.5030607@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 17:04:59 -0000 Hello. Is this patch commited yet? -best regards, Jakub Lach Alexander Motin-3 wrote: > > > Sorry, my fault. Try attached patch. > > -- > Alexander Motin > > --- local_apic.c.prev 2009-05-01 23:53:37.000000000 +0300 > +++ local_apic.c 2009-05-05 01:10:04.000000000 +0300 > @@ -319,7 +319,7 @@ lapic_setup(int boot) > } > > /* We don't setup the timer during boot on the BSP until later. */ > - if (!(boot && PCPU_GET(cpuid) == 0)) { > + if (!(boot && PCPU_GET(cpuid) == 0) && lapic_timer_hz != 0) { > KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", > lapic_id())); > lapic_timer_set_divisor(lapic_timer_divisor); > > _______________________________________________ > 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" > -- View this message in context: http://www.nabble.com/Fighting-for-the-power.-tp23360518p23411239.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed May 6 17:08: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 891051065678; Wed, 6 May 2009 17:08:41 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id E020D8FC16; Wed, 6 May 2009 17:08:40 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n46Gr0bq026326; Wed, 6 May 2009 17:53:00 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.28] ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n46GqrWL062404; Wed, 6 May 2009 17:52:53 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> From: Bob Bishop To: mister.olli@googlemail.com In-Reply-To: <1241623255.12407.6.camel@phoenix.blechhirn.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 6 May 2009 17:52:53 +0100 References: <1241623255.12407.6.camel@phoenix.blechhirn.net> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org, "freebsd-questions@freebsd.org" Subject: Re: Assign IP address and hostname via kernel parameter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 17:08:41 -0000 Hi, On 6 May 2009, at 16:20, Mister Olli wrote: > is there a way to configure IP address and hostname on freebsd systems > via kernel command line parameters? [etc] When running diskless, the loader sets kernel variables like: boot.netif.gateway="192.168.198.1" boot.netif.hwaddr="00:15:17:47:14:fc" boot.netif.ip="192.168.198.8" boot.netif.netmask="255.255.255.0" to values obtained from BOOTP or DHCP, and the right things happen. I guess you could just set these in loader.conf or at the loader prompt. -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Wed May 6 18:46: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 C045C1065673 for ; Wed, 6 May 2009 18:46:14 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.152]) by mx1.freebsd.org (Postfix) with ESMTP id 560CE8FC0A for ; Wed, 6 May 2009 18:46:14 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from 6nq.u-strasbg.fr (mojito.u-strasbg.fr [IPv6:2001:660:4701:1002::2]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n46IiwKV074508 for ; Wed, 6 May 2009 20:44:58 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id E350BD094; Wed, 6 May 2009 20:41:30 +0200 (CEST) Date: Wed, 6 May 2009 20:41:30 +0200 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20090506184130.GA1878@unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline 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::152]); Wed, 06 May 2009 20:44:58 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9333/Wed May 6 05:55:26 2009 on mr2.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 mr2.u-strasbg.fr Subject: amd64 suspend/resume broken on 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: Wed, 06 May 2009 18:46:15 -0000 Hello, Suspend/resume (S3) was working like a charm and it is now broken with FreeBSD 8.0-CURRENT #1: Wed May 6 18:27:21 CEST 2009 GENERIC amd64. I can suspend the laptop, but when resuming it I'm in a console which gets a lot of "fwohci0: device physically ejected?" messages and the system is dead. -- bug From owner-freebsd-current@FreeBSD.ORG Wed May 6 19:07: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 70AEB10656C7 for ; Wed, 6 May 2009 19:07:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id DF4FC8FC0A for ; Wed, 6 May 2009 19:07:49 +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 mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n46J7k3M002145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 05:07:47 +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 n46J7k1L081264; Thu, 7 May 2009 05:07:46 +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 n46J7jfk081263; Thu, 7 May 2009 05:07:46 +1000 (EST) (envelope-from peter) Date: Thu, 7 May 2009 05:07:45 +1000 From: Peter Jeremy To: Jakub Lach Message-ID: <20090506190745.GA91670@server.vk2pj.dyndns.org> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> <23411239.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <23411239.post@talk.nabble.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 19:07:51 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-06 10:04:57 -0700, Jakub Lach wrote: >Is this patch commited yet? Yes as r191803. --=20 Peter Jeremy --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoB4AEACgkQ/opHv/APuIfhGgCgtS890vRoQpsHmJGbhw1msilp sUoAoL5HDyBZE9HoJjJSwMR0LFhEwrom =AADh -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Wed May 6 19:26: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 0311A1065675; Wed, 6 May 2009 19:26:06 +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 74FCB8FC15; Wed, 6 May 2009 19:26:05 +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 6551AA07FB; Wed, 6 May 2009 21:26:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 582D7A07EE; Wed, 6 May 2009 21:26:04 +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 310E4A080B; Wed, 6 May 2009 21:26:04 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050621260260-4252 ; Wed, 6 May 2009 21:26:02 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 6 May 2009 21:26:03 +0200 Date: Wed, 6 May 2009 21:26:03 +0200 From: Alexey Shuvaev To: Tim Kientzle Message-ID: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> 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.2HF443 | November 25, 2008) at 05/06/2009 09:26:02 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/06/2009 09:26:03 PM, Serialize complete at 05/06/2009 09:26:03 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, openoffice@FreeBSD.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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: Wed, 06 May 2009 19:26:06 -0000 On Wed, May 06, 2009 at 05:01:23AM -0700, Tim Kientzle wrote: > No, this is simply tar not being very friendly to gunzip. bsdtar is a > little quick to shutdown when it sees the end of the archive, even though > gunzip is still decompressing some end-of-archive padding. I'll look at > this; tar should notice when it's reading from a pipe and read the final > padding in this case, which would allow gunzip to shut down cleanly. > Thanks for looking at it! > Your workaround looks like a good change, though. The separate gunzip is > unnecessary. > On freebsd yes, but this patch is against makefile (deep) in the OOO sources. I don't think OOO people will accept the patch, then it should live in ports, which is not very desirable. (I'm not the maintainer of OOO, though.) > > On Tue, May 5, 2009 at 8:28 PM, Alexey Shuvaev < > shuvaev@physik.uni-wuerzburg.de> wrote: > > > On Tue, May 05, 2009 at 10:59:01PM +0400, Eygene Ryabinkin wrote: > > > Alexey, good day. > > > > > > Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > > > > The reason appeared to be the first part of the command > > > > "gunzip -c ... | ( tar -xf - ) && touch ..." > > > > which exited with non-zero exit status (141) and "touch ..." was not > > called. > > > > Running the command manually has showed that gunzip was complaining > > about > > > > broken pipe (however the archive was extracted successfully). > > > > > > Yes, 141 means that SIGPIPE was delivered. This in turn means that > > > 'tar -xf -' exited before gunzip had finished its job and gunzip had > > > tried to write more data to the pipe. > > > > > > Could I ask to do some debugging: > > > > > > 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' > > > > > Ok so far. > > > > > 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the > > results. > > > > > Ok: > > ~/tmp> cat crystal.tar | ( tar -xf - ) && echo OK > > OK > > > > > 3. do 'md5 ooo_crystal_images-1.tar.gz' > > > > > ~/tmp> md5 crystal.tar > > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > > > > > For the last point, I have > > > ----- > > > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > > ----- > > > but this tar.gz was taken from OOO 3.x. If yours have some other > > > checksum, could you place it somewhere where I can download it? > > > > > Mmmm... not so easy... German universities are not so internet friendly... > > fsck... > > But it was taken from official > > openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > tarball... > > Ping me if it is download error. > > > > > My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of > > May. > > > > > > Thanks! > > > > > I'm running amd64 Core2Duo processor with SMP kernel. Can it be that > > 2 processes (gunzip and tar) are running on different cpu-s and this is > > some race condition? Not triggered before? > > > -- > > > Eygene > > > _ ___ _.--. # > > > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > > > / ' ` , __.--' # to read the on-line manual > > > )/' _/ \ `-_, / # while single-stepping the kernel. > > > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > > > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > > > {_.-``-' {_/ # > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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 6 20:06: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 08AD6106564A for ; Wed, 6 May 2009 20:06:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 95A448FC0C for ; Wed, 6 May 2009 20:06:35 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XEd02-WV6wAA:10 a=AfyaOJejoSkA:10 a=lyEUAijRBdbizgvxMw8A:9 a=9IdtweBPWMZ2JnhHKVgf7b4GHvQA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1236255095; Wed, 06 May 2009 22:06:33 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 6 May 2009 22:09:07 +0200 User-Agent: KMail/1.9.7 References: <4A00DACA.1010500@beardz.net> In-Reply-To: <4A00DACA.1010500@beardz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905062209.08113.hselasky@c2i.net> Cc: Jase Thew Subject: Re: Another USB mouse failing to attach with current, post-USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 20:06:36 -0000 On Wednesday 06 May 2009, Jase Thew wrote: > Hi, > I'm working on a fix for this issue. --HPS From owner-freebsd-current@FreeBSD.ORG Wed May 6 20: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 0214910656E8 for ; Wed, 6 May 2009 20:48:51 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.freebsd.org (Postfix) with ESMTP id 43CA98FC12 for ; Wed, 6 May 2009 20:48:51 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by wf-out-1314.google.com with SMTP id 24so361107wfg.7 for ; Wed, 06 May 2009 13:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.152.17 with SMTP id z17mr1558569wad.73.1241641134681; Wed, 06 May 2009 13:18:54 -0700 (PDT) Date: Wed, 6 May 2009 22:18:54 +0200 Message-ID: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> From: Olivier SMEDTS To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: can't build kernel without atkbd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 20:48:53 -0000 Hello list, I'm trying to build a -CURRENT amd64 kernel but it fails if I don't have "device atkbd" in my kernel config file : # make buildkernel [...] linking kernel kbd.o(.text+0x14c): In function `kbd_configure': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x152): In function `kbd_configure': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x177): In function `kbd_configure': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x11f9): In function `kbd_get_switch': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x11ff): In function `kbd_get_switch': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1217): In function `kbd_get_switch': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1495): In function `kbd_register': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x149b): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x14ad): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Here's the kernel config : cpu HAMMER ident QUAD options SCHED_ULE options PREEMPTION options IPI_PREEMPTION options INET options INET6 options FFS options SOFTUPDATES options UFS_DIRHASH options COMPAT_IA32 options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options STOP_NMI options AUDIT options VIMAGE options PRINTF_BUFR_SIZE=3D128 options SMP device acpi device pci device vga device sc device loop device ether device pty device bpf If I add "makeoptions DEBUG=3D-g" like I have usually, here is the error : [...] MAKE=3Dmake sh /work/src/sys/conf/newvers.sh QUAD cc -c -O2 -pipe -march=3Dnative -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/work/src/sys -I/work/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse-mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug kbd.o(.text+0x14c): In function `kbd_configure': /work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x152):/work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x177):/work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x11f9): In function `kbd_get_switch': /work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x11ff):/work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1217):/work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1495): In function `kbd_register': /work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x149b):/work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x14ad):/work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__stop_set_kbddriver_set' *** Error code 1 I don't think that's expected because, citing ukbd(4) : If you want to use a USB keyboard as your default and not use an AT ke= y- board at all, you will have to remove the device atkbd line from the k= er- nel configuration file. NOTE=A0:=A0I'm using USB2. Any hints ? Thanks, Olivier --=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 Wed May 6 22:05:16 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 27396106566C for ; Wed, 6 May 2009 22:05:16 +0000 (UTC) (envelope-from Cristi.Magherusan@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id D0A188FC23 for ; Wed, 6 May 2009 22:05:15 +0000 (UTC) (envelope-from Cristi.Magherusan@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 50388B241A; Thu, 7 May 2009 00:34:18 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUgKWT5poqlV; Thu, 7 May 2009 00:34:04 +0300 (EEST) Received: from [192.168.1.10] (unknown [89.41.20.67]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcristi) by bavaria.utcluj.ro (Postfix) with ESMTP id 6F398B2435; Thu, 7 May 2009 00:34:04 +0300 (EEST) From: Cristi Magherusan To: current@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-IvZDALXkh4ADOxt7pgkg" Date: Thu, 07 May 2009 00:34:03 +0300 Message-Id: <1241645643.23197.7.camel@hyperion> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Cc: davidch@broadcom.com Subject: trivial patch commit request/reminder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 May 2009 22:05:16 -0000 --=-IvZDALXkh4ADOxt7pgkg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please anyone in charge (David Christensen?) review and commit to the tree the trivial patch that fixes the issue discussed in this thread: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D118238 It's a shame that it didn't make it in 7.2, but hopefully it will in 8.0. Regards, Cristi --=20 Ing. Cristi M=C4=83gheru=C8=99an, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 --=-IvZDALXkh4ADOxt7pgkg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkoCAkUACgkQfwrBISYVZFWQVgCffDoM66F6O2gCfmf254rQhEnL VwUAn1SFPiNR8wAMPnKmLYt7M2Wwb7cs =jHk8 -----END PGP SIGNATURE----- --=-IvZDALXkh4ADOxt7pgkg-- From owner-freebsd-current@FreeBSD.ORG Wed May 6 23:37: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 AB009106566B; Wed, 6 May 2009 23:37:18 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id EF8F88FC12; Wed, 6 May 2009 23:37:17 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [137.122.72.187] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242134781; Thu, 07 May 2009 01:37:16 +0300 Message-ID: <4A021118.2030106@mavhome.dp.ua> Date: Thu, 07 May 2009 01:37:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Guy Brand , current References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 May 2009 23:41:59 +0000 Cc: sbruno@FreeBSD.org Subject: Re: amd64 suspend/resume broken on 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: Wed, 06 May 2009 23:37:18 -0000 Guy Brand wrote: > Suspend/resume (S3) was working like a charm and it is now broken with > FreeBSD 8.0-CURRENT #1: Wed May 6 18:27:21 CEST 2009 GENERIC amd64. > > I can suspend the laptop, but when resuming it I'm in a console which > gets a lot of "fwohci0: device physically ejected?" messages and the > system is dead. Looking onto the message, problem may be FireWire related. We have tested FireWire with Sean Bruno on my laptop, and even as system resumed successfully, FireWire was not working after resume, until we reloaded the driver. So there are definitely some problems exist. We can try to check it more, but could you try to unload FireWire drivers and try again? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed May 6 23:46: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 3579C1065674 for ; Wed, 6 May 2009 23:46:32 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id BB96E8FC14 for ; Wed, 6 May 2009 23:46:31 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 231A5CD8; Wed, 6 May 2009 19:46:31 -0400 (EDT) Received: from localhost ([127.0.0.1]:50726 helo=ichotolot.servalan.com) by servalan.servalan.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1q01-0001KO-QZ for freebsd-current@freebsd.org; Wed, 06 May 2009 17:54:01 -0500 To: freebsd-current@freebsd.org Date: Wed, 06 May 2009 17:54:01 -0500 From: Richard Todd Message-Id: <20090506234631.231A5CD8@mx1.synetsystems.com> Subject: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's 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: Wed, 06 May 2009 23:46:32 -0000 Hi. I updated my main -current box to the current sources as of yesterday, and I've managed to twice get the "wrong vnode panic" out of the cache_enter code. As you can see from the backtrace down at cache_enter at frame 11, the code is apparently expecting vp to point to a VDIR vnode, but instead it's pointing to a VLNK. (I've got another, similar, dump where vp is pointing to a VREG node.) In both cases, I was running tinderbox to build packages, with resulting heavy use of both zfs (the underlying filesystem) and nullfs, if that's relevant. Script started on Wed May 6 17:41:35 2009 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: wrong vnode type 0xffffff011885b4e0 cpuid = 0 KDB: enter: panic exclusive rw Name Cache (Name Cache) r = 0 (0xffffffff80db98e0) locked @ /usr/src/sys/kern/vfs_cache.c:674 shared lockmgr zfs (zfs) r = 0 (0xffffff010c019098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1201 exclusive lockmgr zfs (zfs) r = 0 (0xffffff011885b578) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1199 exclusive rw Name Cache (Name Cache) r = 0 (0xffffffff80db98e0) locked @ /usr/src/sys/kern/vfs_cache.c:674 shared lockmgr zfs (zfs) r = 0 (0xffffff010c019098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1201 exclusive lockmgr zfs (zfs) r = 0 (0xffffff011885b578) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1199 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff010c479b10) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff006a338378) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive lockmgr bufwait (bufwait) r = 0 (0xffffffff003abe48) locked @ /usr/src/sys/vm/vm_pager.c:310 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff006a338b10) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff00ad503600) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 0xffffff010c019000: tag zfs, type VDIR usecount 5, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xffffff00bd665708 ref 0 pages 0 lock type zfs: SHARED (count 1) #0 0xffffffff8054a4fa at __lockmgr_args+0x51a #1 0xffffffff805dbad9 at vop_stdlock+0x39 #2 0xffffffff8088a47b at VOP_LOCK1_APV+0x9b #3 0xffffffff805f7cb7 at _vn_lock+0x57 #4 0xffffffff81049b53 at zfs_lookup+0x303 #5 0xffffffff81049f51 at zfs_freebsd_lookup+0x81 #6 0xffffffff80888fef at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805d9880 at vfs_cache_lookup+0xf0 #8 0xffffffff8088b347 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805e0324 at lookup+0x4d4 #10 0xffffffff805e1285 at namei+0x545 #11 0xffffffff805f78e2 at vn_open_cred+0x1b2 #12 0xffffffff805dc184 at vop_stdvptocnp+0x174 #13 0xffffffff80889139 at VOP_VPTOCNP_APV+0xb9 #14 0xffffffff805d86fb at vn_vptocnp+0xdb #15 0xffffffff805d8a54 at vn_fullpath1+0x244 #16 0xffffffff805d8eb4 at kern___getcwd+0xd4 #17 0xffffffff808419d7 at syscall+0x1e7 0xffffff011885b4e0: tag zfs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type zfs: EXCL by thread 0xffffff0051e05000 (pid 55596) #0 0xffffffff8054a738 at __lockmgr_args+0x758 #1 0xffffffff805dbad9 at vop_stdlock+0x39 #2 0xffffffff8088a47b at VOP_LOCK1_APV+0x9b #3 0xffffffff805f7cb7 at _vn_lock+0x57 #4 0xffffffff81049b28 at zfs_lookup+0x2d8 #5 0xffffffff81049f51 at zfs_freebsd_lookup+0x81 #6 0xffffffff80888fef at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805d9880 at vfs_cache_lookup+0xf0 #8 0xffffffff8088b347 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805e0324 at lookup+0x4d4 #10 0xffffffff805e1285 at namei+0x545 #11 0xffffffff805f78e2 at vn_open_cred+0x1b2 #12 0xffffffff805dc184 at vop_stdvptocnp+0x174 #13 0xffffffff80889139 at VOP_VPTOCNP_APV+0xb9 #14 0xffffffff805d86fb at vn_vptocnp+0xdb #15 0xffffffff805d8a54 at vn_fullpath1+0x244 #16 0xffffffff805d8eb4 at kern___getcwd+0xd4 #17 0xffffffff808419d7 at syscall+0x1e7 Physical memory: 4012 MB Dumping 2299 MB: 2284 2268 2252 2236 2220 2204 2188 2172 2156 2140 2124 2108 2092 2076 2060 2044 2028 2012 1996 1980 1964 1948 1932 1916 1900 1884 1868 1852 1836 1820 1804 1788 1772 1756 1740 1724 1708 1692 1676 1660 1644 1628 1612 1596 1580 1564 1548 1532 1516 1500 1484 1468 1452 1436 1420 1404 1388 1372 1356 1340 1324 1308 1292 1276 1260 1244 1228 1212 1196 1180 1164 1148 1132 1116 1100 1084 1068 1052 1036 1020 1004 988 972 956 940 924 908 892 876 860 844 828 812 796 780 764 748 732 716 700 684 668 652 636 620 604 588 572 556 540 524 508 492 476 460 444 428 412 396 380 364 348 332 316 300 284 268 252 236 220 204 188 172 156 140 124 108 92 76 60 44 28 12 Reading symbols from /boot/kernel/zfs.ko...done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/snd_hda.ko...done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/coretemp.ko...done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/atapicam.ko...done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/tmpfs.ko...done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko Reading symbols from /boot/kernel/radeon.ko...done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/nullfs.ko...done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/linprocfs.ko...done. Loaded symbols for /boot/kernel/linprocfs.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 0xffffffff801cc59c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801cc84d in db_command (last_cmdp=0xffffffff80bc36a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801d1043 in db_script_exec ( scriptname=0xffffffff2d7d9d50 "kdb.enter.panic", warnifnotfound=0) at /usr/src/sys/ddb/db_script.c:302 #4 0xffffffff801d1112 in db_script_kdbenter (eventname=Variable "eventname" is not available. ) at /usr/src/sys/ddb/db_script.c:324 #5 0xffffffff801ceac4 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #6 0xffffffff8058f5d5 in kdb_trap (type=3, code=0, tf=0xffffffff2d7d9f70) at /usr/src/sys/kern/subr_kdb.c:534 #7 0xffffffff80842125 in trap (frame=0xffffffff2d7d9f70) at /usr/src/sys/amd64/amd64/trap.c:606 #8 0xffffffff8081cef3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #9 0xffffffff8058f7ad in kdb_enter (why=0xffffffff80946c99 "panic", msg=0xa
) at cpufunc.h:63 #10 0xffffffff8055fe5b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:559 #11 0xffffffff805d8542 in cache_enter (dvp=0xffffff010c019000, vp=0xffffff011885b4e0, cnp=0xffffffff2d7da908) at /usr/src/sys/kern/vfs_cache.c:702 #12 0xffffffff81049b95 in zfs_lookup (dvp=0xffffff010c019000, nm=0xffffffff2d7da230 "..", vpp=0xffffffff2d7da8e0, cnp=0xffffffff2d7da908, nameiop=0, cr=0xffffff0032a08a00, td=0xffffff0051e05000, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1221 #13 0xffffffff81049f51 in zfs_freebsd_lookup (ap=0xffffffff2d7da390) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:3988 #14 0xffffffff80888fef in VOP_CACHEDLOOKUP_APV (vop=0xffffffff810b22e0, a=0xffffffff2d7da390) at vnode_if.c:187 #15 0xffffffff805d9880 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #16 0xffffffff8088b347 in VOP_LOOKUP_APV (vop=0xffffffff810b22e0, a=0xffffffff2d7da460) at vnode_if.c:123 #17 0xffffffff805e0324 in lookup (ndp=0xffffffff2d7da8b0) at vnode_if.h:54 #18 0xffffffff805e1285 in namei (ndp=0xffffffff2d7da8b0) at /usr/src/sys/kern/vfs_lookup.c:256 #19 0xffffffff805f78e2 in vn_open_cred (ndp=0xffffffff2d7da8b0, flagp=0xffffffff2d7da9b8, cmode=0, cred=0xffffff0032a08a00, fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:189 #20 0xffffffff805dc184 in vop_stdvptocnp (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:707 #21 0xffffffff80889139 in VOP_VPTOCNP_APV (vop=0xffffffff80b7f560, a=0xffffffff2d7daa30) at vnode_if.c:3353 #22 0xffffffff805d86fb in vn_vptocnp (vp=0xffffffff2d7daab0, ---Type to continue, or q to quit--- bp=0xffffffff2d7daac0, buf=0xffffff00059ed800 'p' ..., buflen=0xffffffff2d7daaac) at vnode_if.h:1512 #23 0xffffffff805d8a54 in vn_fullpath1 (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_cache.c:1168 #24 0xffffffff805d8eb4 in kern___getcwd (td=0xffffff0051e05000, buf=0x7fffffffe390
, bufseg=UIO_USERSPACE, buflen=1024) at /usr/src/sys/kern/vfs_cache.c:936 #25 0xffffffff808419d7 in syscall (frame=0xffffffff2d7dac90) at /usr/src/sys/amd64/amd64/trap.c:977 #26 0xffffffff8081d180 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #27 0x000000001892dcec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xffffffff805d8542 in cache_enter (dvp=0xffffff010c019000, vp=0xffffff011885b4e0, cnp=0xffffffff2d7da908) at /usr/src/sys/kern/vfs_cache.c:702 702 KASSERT(vp == NULL || vp->v_type == VDIR, (kgdb) p *vp $1 = {v_type = VLNK, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff006cfe9178, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60c58}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xffffff00a6675770, tqh_last = 0xffffff00a6675790}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 18446742975571578880, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615800, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147048, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff011885b578, v_holdcnt = 1, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60dd0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6b0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6d0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff011885b4e0, __bo_vnode = 0xffffff011885b4e0}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) l 697 if (dvp->v_cache_dd != NULL) { 698 CACHE_WUNLOCK(); 699 cache_free(ncp); 700 return; 701 } 702 KASSERT(vp == NULL || vp->v_type == VDIR, 703 ("wrong vnode type %p", vp)); 704 dvp->v_cache_dd = ncp; 705 } 706 (kgdb) fr 12 #12 0xffffffff81049b95 in zfs_lookup (dvp=0xffffff010c019000, nm=0xffffffff2d7da230 "..", vpp=0xffffffff2d7da8e0, cnp=0xffffffff2d7da908, nameiop=0, cr=0xffffff0032a08a00, td=0xffffff0051e05000, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1221 1221 cache_enter(dvp, *vpp, cnp); (kgdb) l 1216 * Insert name into cache if appropriate. 1217 */ 1218 if (error == 0 && (cnp->cn_flags & MAKEENTRY)) { 1219 if (!(cnp->cn_flags & ISLASTCN) || 1220 (nameiop != DELETE && nameiop != RENAME)) { 1221 cache_enter(dvp, *vpp, cnp); 1222 } 1223 } 1224 #endif 1225 (kgdb) p *dvp $2 = {v_type = VDIR, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff00b7a99bc0, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff001fee1270, tqe_prev = 0xffffff00c1c9c508}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xffffff010c019060}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 9, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615226, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147091, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff010c019098, v_holdcnt = 6, v_usecount = 5, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xffffff010c0701a0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff010c0191d0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff010c0191f0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0xffffff00bd665708, bo_synclist = { le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff010c019000, __bo_vnode = 0xffffff010c019000}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) p **vpp $3 = {v_type = VLNK, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff006cfe9178, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60c58}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xffffff00a6675770, tqh_last = 0xffffff00a6675790}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 18446742975571578880, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615800, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147048, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff011885b578, v_holdcnt = 1, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60dd0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6b0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6d0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff011885b4e0, __bo_vnode = 0xffffff011885b4e0}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) q Script done on Wed May 6 17:42:37 2009 From owner-freebsd-current@FreeBSD.ORG Thu May 7 00:54:37 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 74D59106566B for ; Thu, 7 May 2009 00:54:37 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63905.mail.re1.yahoo.com (web63905.mail.re1.yahoo.com [69.147.97.120]) by mx1.freebsd.org (Postfix) with SMTP id 0945C8FC0C for ; Thu, 7 May 2009 00:54:35 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 78596 invoked by uid 60001); 7 May 2009 00:54:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241657675; bh=+AOITqkJl9NP9Ch1hBtUwjRwPN064QCxc3IudOy482M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=U+tS8D86mRGNizsDTvUL5WVu6hBl9Cy9eu9kD/UPCrQhBPlLNf9DqLD8tkRTJw9mJyYVwX13i7f50jyk9jQ3ujxz9U5r9sVed12zsRUoG+7oavA5EulDJqAf87pIQ3xw2NaX/qGX49aIqHTY+jqmunzMEO2j4s1UM3hQm8tDnJw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=oGKr62lMc7r1Q1cVJ9G7uOn9wl/99ApjYYzs5cA1w2UVu/2pXwFTc4yXEre1258VrO4/jYOIiiT+6GydSerZpgsbn7hLpy0zSOvFGkBTSE8FwVLoNSDZzCa+VNMIFK4kzVNi//XYTt10Nz3wuvUVW7zxUCn0oIAkypwdFGEXsoQ=; Message-ID: <270637.78561.qm@web63905.mail.re1.yahoo.com> X-YMail-OSG: m6sASdwVM1mNMedyenLIXQTIonG_AGlmF.QIwylOgWD0vg5vPuyvAyFAqj6IqWwIq.k3HPbpSHgOaclGL9.i07sGTimxO18qlUjts8ciOqJvQZWVWrZREGeTpXfiD9cE6rPl1gEmURFG6ti8epd9GEdzA1l97bQzBSqDiokvRRwg.iKEdl3WhWlpeKfs62VLCWLGXhNHn_SpUe60598fF53XRRkOHA5usCRhQoWr9rncEGnb2RqTe8la2szcHj62jhjGKe2Y_xgUmNp7ZM23Imo8MD1qZrqlG.tCC5NCPQ-- Received: from [68.180.216.147] by web63905.mail.re1.yahoo.com via HTTP; Wed, 06 May 2009 17:54:35 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 6 May 2009 17:54:35 -0700 (PDT) From: Barney Cordoba To: "Current@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 07 May 2009 01:39:30 +0000 Cc: Subject: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 00:54:37 -0000 I just got a shiny new nehalem box and it comes up with 16 processors with dual quads installed. Is there any benefit or should hyperthreading be disabled? From owner-freebsd-current@FreeBSD.ORG Thu May 7 02:55:19 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 840D5106564A for ; Thu, 7 May 2009 02:55:19 +0000 (UTC) (envelope-from pluknet@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 106A98FC16 for ; Thu, 7 May 2009 02:55:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz9 with SMTP id 9so509549bwz.43 for ; Wed, 06 May 2009 19:55:18 -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=f6eVq0KFP9OjBdAXdRjfhOaSZEcquk+LIhthYcIXPvg=; b=Ca1K6zoHRj0622UY0ZZ0j+lxk501/gldOF/t5GJTHFBGOa97hUkwl5iHgqlNHtbfWF yud0e3gR/hJ5CRI1ft7L2Lkx7aRCsebW1HOeBXtBuOJsWtokFFCStRhIY1eZ5hV8OCUI u1fxHdu2u5Tumqsje1gReF0PH/NNDAzgAQU3c= 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=reli2OMSrUsNWW1pDfACUcHFGuZrQIoX5Z2IAk5Nfdl7R6lgHF0/EyAr28uMPgheJ/ iVOLT3MyRYxeamxchCKssTB6Bwpzn2S07f0EeOdg1kqrKIjZjPAtEjFJd3ssrz4X3JHX sC3NPL0EO1uJdiiUvKVgauegm6704+Yar6GF8= MIME-Version: 1.0 Received: by 10.103.220.18 with SMTP id x18mr1283618muq.135.1241664918002; Wed, 06 May 2009 19:55:18 -0700 (PDT) In-Reply-To: <270637.78561.qm@web63905.mail.re1.yahoo.com> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> Date: Thu, 7 May 2009 06:55:17 +0400 Message-ID: From: pluknet To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 02:55:19 -0000 2009/5/7 Barney Cordoba : > > I just got a shiny new nehalem box and it comes up with 16 processors with dual quads installed. Is there any benefit or should hyperthreading be disabled? > Hi. There is a measurable win if hyperthreading is enabled [1]. You can switch it off via machdep.hyperthreading_enabled loader tunable. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu May 7 04:39: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 8BBD61065670 for ; Thu, 7 May 2009 04:39:11 +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 5A1FD8FC19 for ; Thu, 7 May 2009 04:39:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n474dA2q096021; Wed, 6 May 2009 21:39:10 -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 pwzgw7r8jc4fu4w45wrj7d2ac2; Wed, 06 May 2009 21:39:10 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A0265ED.4070407@freebsd.org> Date: Wed, 06 May 2009 21:39:09 -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: Alexey Shuvaev References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, openoffice@freebsd.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 04:39:11 -0000 Alexey Shuvaev wrote: > On Wed, May 06, 2009 at 05:01:23AM -0700, Tim Kientzle wrote: >> No, this is simply tar not being very friendly to gunzip. bsdtar is a >> little quick to shutdown when it sees the end of the archive, even though >> gunzip is still decompressing some end-of-archive padding. I'll look at >> this; tar should notice when it's reading from a pipe and read the final >> padding in this case, which would allow gunzip to shut down cleanly. >> > Thanks for looking at it! I did look; bsdtar does do the right thing. (I think I was remembering a bug that got fixed years ago.) I tried but could not reproduce your bug using a recent -CURRENT. I downloaded this file: http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 and extracted ooo_crystal_images-1.tar.gz and got the same MD5 that Eygene reported. $ md5 ooo_crystal_images-1.tar.gz MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 Where did you download your file from? Tim From owner-freebsd-current@FreeBSD.ORG Thu May 7 06:05: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 01004106566B; Thu, 7 May 2009 06:05: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 9D3E28FC12; Thu, 7 May 2009 06:05:44 +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=Og0Xc/rAEiaOx+syPbD3BC6Vc8VMS9/MbPJ9nigOPZQmSmbLcPxthPV26xNKVzosnQj6VjYrX/bEQ1xKdkN2Ao+MgJeD0BnnHM4bQj6SEkQcQr7vJZaMPe+bIVv46Ilz/PhU+5TBqlHgcagm18aTMmDVjxs0uuezADbyEwmhqiQ=; Received: from amnesiac.at.no.dns (ppp91-78-118-57.pppoe.mtu-net.ru [91.78.118.57]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M1wjn-000MHr-Gq; Thu, 07 May 2009 10:05:43 +0400 Date: Thu, 7 May 2009 10:05:40 +0400 From: Eygene Ryabinkin To: Tim Kientzle Message-ID: References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A0265ED.4070407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0265ED.4070407@freebsd.org> Sender: rea-fbsd@codelabs.ru Cc: Alexey Shuvaev , freebsd-current@freebsd.org, openoffice@freebsd.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 06:05:45 -0000 Wed, May 06, 2009 at 09:39:09PM -0700, Tim Kientzle wrote: > I tried but could not reproduce your bug using > a recent -CURRENT. I downloaded this file: > > http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > and extracted ooo_crystal_images-1.tar.gz > and got the same MD5 that Eygene reported. > > $ md5 ooo_crystal_images-1.tar.gz > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > Where did you download your file from? Alexey's .tar.gz file should be also fine: he reported the checksum from the .tar file, not .tar.gz one: ----- ~/tmp> md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a ----- I have the same MD5 for the .tar file: ----- $ md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a ----- I am not able to reproduce the bug too, so perhaps the output from ktrace, ----- ktrace -f gunzip.trace gunzip -c ooo_crystal_images-1.tar.gz | (ktrace -f tar.trace tar -xf -) ----- will be useful for diagnostics. The files of interest will be gunzip.trace and tar.trace. -- 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 7 06:14: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 09333106566B; Thu, 7 May 2009 06:14:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BDDD58FC1F; Thu, 7 May 2009 06:14:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n476Ax9N066591; Thu, 7 May 2009 00:11:00 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 07 May 2009 00:10:59 -0600 (MDT) Message-Id: <20090507.001059.-1558772981.imp@bsdimp.com> To: onemda@gmail.com From: "M. Warner Losh" In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 06:14:20 -0000 In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> "Paul B. Mahol" writes: : On 5/4/09, Alexander Motin wrote: : > 2. PCI devices : > PCI bus provides method to control device power. For example, I have : > completely no use for my FireWire controller and most of time - EHCI USB : > controller. Disabling them allows me to save about 3W of power. To : > disable all unneeded PCI devices you should build kernel without their : > drivers and add to loader.conf: : > hw.pci.do_power_nodriver=3 : > To enable devices back all you need to do is just load their drivers as : > modules. : : Unloading modules doesnt put them back into into D3 state. : You are forced to load some another module again to put wanted device : into D3 state. It should. If it isn't, that's a bug. Warner From owner-freebsd-current@FreeBSD.ORG Thu May 7 08:39: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 4AD95106566B for ; Thu, 7 May 2009 08:39:38 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 2FE488FC17 for ; Thu, 7 May 2009 08:39:37 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n478HKVD044293; Thu, 7 May 2009 09:17:20 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.28] ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n478HEZ1069208; Thu, 7 May 2009 09:17:15 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> From: Bob Bishop To: pluknet In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 09:17:15 +0100 References: <270637.78561.qm@web63905.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: Barney Cordoba , "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 08:39:38 -0000 Hi, On 7 May 2009, at 03:55, pluknet wrote: > 2009/5/7 Barney Cordoba : >> >> I just got a shiny new nehalem box and it comes up with 16 >> processors with dual quads installed. Is there any benefit or >> should hyperthreading be disabled? >> > > Hi. There is a measurable win if hyperthreading is enabled [1]. AFAICS the reference doesn't support that conclusion at all. > You can switch it off via machdep.hyperthreading_enabled loader > tunable. > > [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Thu May 7 09:26: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 BADF61065673 for ; Thu, 7 May 2009 09:26:50 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id 5D1078FC15 for ; Thu, 7 May 2009 09:26:50 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 2400 invoked by uid 60001); 7 May 2009 09:26:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241688409; bh=wQuGxgnvYVXkV1a40AOY/gqjiJ5vvKX4M7nzx7cMRCo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nf6ww8tCMRerBYSAGA9OexKPw+FJ4cKdhq7pYuS4iDMNCh8YDCOt/EWfb0Fx9pQE2iXPzqW++7qL4YHaZiSEr0TcyhWb6fNZ69WUCgWxLg6u3DXcPdxtyL0ldfmrrsjzF5aSypplZ8qCtD2GZuyNrDO1MHMqByC+77NBzdjArQU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QSDLr4BPeBTiMpHkQLmnul+DUE39hk784Cj4PQIHNQ4alL4b1VzN5/WJaAJjP5C/hk3noDatXRFst+745IFgJLbfogsjOhCb1PhsLURkcHQXOFpvAPDvaW4bATbJVBBnKgPawr1rwgvDRe5rgPU9saq2SUlo9ywsSNVawWusV5s=; Message-ID: <758865.1091.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: pgkfytwVM1kfx2H6XVCa1wPSegL_P5a4hL9Hwb8XT_EgN8lQ.K8Ig6cLzvEoKLPZo.rso.HLNeLETvpv7.4M6.W.E9txYjWVOBfqjBr44vZmwTnPN42mnd2_CntWjG8fpmbEUKto.sF1Z45STkWcSgaDGQBJ9n_AGRtessHAanh58ohFtEvZGtlo_IadHOcrvH6KCJAegYx90zVwkWm4kexGtNKgethJpxBc8kbR6j2ydq1XShowzqufiPs5aVP9SlxdlRt.AMBErcssJBdlTrD2xS4- Received: from [98.242.223.106] by web63907.mail.re1.yahoo.com via HTTP; Thu, 07 May 2009 02:26:49 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Thu, 7 May 2009 02:26:49 -0700 (PDT) From: Barney Cordoba To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.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, 07 May 2009 09:26:51 -0000 --- On Wed, 5/6/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Barney Cordoba" > Cc: "Current@freebsd.org" > Date: Wednesday, May 6, 2009, 10:55 PM > 2009/5/7 Barney Cordoba : > > > > I just got a shiny new nehalem box and it comes up > with 16 processors with dual quads installed. Is there any > benefit or should hyperthreading be disabled? > > > > Hi. There is a measurable win if hyperthreading is enabled > [1]. > You can switch it off via machdep.hyperthreading_enabled > loader tunable. > > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html > I wouldn't call varying the number of jobs a very good test of hyperthreading. I'd want to see the exact same test with hyperthreading enabled and disabled. Its pretty naive to assume that running 16 jobs causes them to all be run on a different cpu. Barney From owner-freebsd-current@FreeBSD.ORG Thu May 7 09:31:12 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 A3C83106566B for ; Thu, 7 May 2009 09:31:12 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1FA8FC12 for ; Thu, 7 May 2009 09:31:12 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by yx-out-2324.google.com with SMTP id 8so388885yxb.13 for ; Thu, 07 May 2009 02:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr406971agb.33.1241688671645; Thu, 07 May 2009 02:31:11 -0700 (PDT) In-Reply-To: <758865.1091.qm@web63907.mail.re1.yahoo.com> References: <758865.1091.qm@web63907.mail.re1.yahoo.com> Date: Thu, 7 May 2009 11:31:11 +0200 Message-ID: <367b2c980905070231r37a94eack399f5afed742247f@mail.gmail.com> From: Olivier SMEDTS To: barney_cordoba@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pluknet , "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 09:31:12 -0000 2009/5/7 Barney Cordoba : > > > > > --- On Wed, 5/6/09, pluknet wrote: > >> From: pluknet >> Subject: Re: Hypertherading >> To: "Barney Cordoba" >> Cc: "Current@freebsd.org" >> Date: Wednesday, May 6, 2009, 10:55 PM >> 2009/5/7 Barney Cordoba : >> > >> > I just got a shiny new nehalem box and it comes up >> with 16 processors with dual quads installed. Is there any >> benefit or should hyperthreading be disabled? There can be some benefit if the scheduler is aware of the topoly of CPUs and Hyperthreading (shared cache). I don't know how SCHED_ULE handles this on -CURRENT. If it doesn't see any difference between CPU cores and "HT" cores, you should disable HT in BIOS. >> > >> >> Hi. There is a measurable win if hyperthreading is enabled >> [1]. >> You can switch it off via machdep.hyperthreading_enabled >> loader tunable. >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >> > > I wouldn't call varying the number of jobs a very good test > of hyperthreading. I'd want to see the exact same test with > hyperthreading enabled and disabled. Its pretty naive > to assume that running 16 jobs causes them to all be run on > a different cpu. > > Barney > > > > _______________________________________________ > 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" > -- 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 Thu May 7 10:04: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 912571065670 for ; Thu, 7 May 2009 10:04:48 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1F40A8FC1B for ; Thu, 7 May 2009 10:04:47 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by fk-out-0910.google.com with SMTP id f33so349264fkf.11 for ; Thu, 07 May 2009 03:04:47 -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=tOQlZKJm6xUt9ZnELW597VJypUAtIhL92HAvnbrINBw=; b=RNMNqG4IrTzAf1Y2pRmtNQvnM6itwadn606iDyqGL1t+2FFtfcf/9IsgvJgvetMVEV GMkmBzDfVEZKgXUCbU7fA0PqM7qvOsO/q/XlxnuISBPvPoqQ3qawT2y5HrDGqMdr+B+m xFUqlaBMWcwq5fJ3bKfgsVId9mKM6ddYi8mDM= 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=F6Oi3GBKkVhiHIRG90+AcOC1VkEUABV0J9KKCP64u+k+1cKGWgPTu+lwju/K19jaLr +yACqYTzUl23OBLxluyPtf4/yUubQe84Q64aKA+Ad9RltT6dZtOtaXEbft+VpVz2bZJn 28YXcc/WBW7JyfU88b2HyCwXNtornOG0DBuzQ= MIME-Version: 1.0 Received: by 10.223.103.133 with SMTP id k5mr1480866fao.23.1241688970263; Thu, 07 May 2009 02:36:10 -0700 (PDT) In-Reply-To: <758865.1091.qm@web63907.mail.re1.yahoo.com> References: <758865.1091.qm@web63907.mail.re1.yahoo.com> Date: Thu, 7 May 2009 04:36:10 -0500 Message-ID: <2fd864e0905070236m4ff62796y3839a1d21c1ed610@mail.gmail.com> From: Astrodog To: barney_cordoba@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pluknet , "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 10:04:48 -0000 The big thing I've seen in all of the tests of HT is that it's incredibly dependent on the type of load one's trying to run. Loads which consist largely of mathematical calculations and very latency-sensitive loads seem to be hurt by it, and desktop loads seem to see either nothing, or a mild improvement. The scheduler is better at handling this kind of decision than the CPU is, in most cases. (To say nothing of the annoyance HT causes for the scheduler, imo) JeffR can probably explain what actually happens with HT enabled (as far as scheduling decisions go) better than I can. --- Harrison From owner-freebsd-current@FreeBSD.ORG Thu May 7 11:17: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 2B7C81065694 for ; Thu, 7 May 2009 11:17:46 +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 B58C48FC12 for ; Thu, 7 May 2009 11:17:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XEd02-WV6wAA:10 a=AfyaOJejoSkA:10 a=6I5d2MoRAAAA:8 a=DgkoNTbEmsxql3vuVgQA:9 a=4iSideRrVZoRnAPMXdGrXG5kao8A:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 490872277; Thu, 07 May 2009 13:17:43 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org User-Agent: KMail/1.9.7 References: <4A00DACA.1010500@beardz.net> In-Reply-To: <4A00DACA.1010500@beardz.net> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 7 May 2009 13:20:16 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905071320.17310.hselasky@c2i.net> Cc: Jase Thew Subject: Re: Another USB mouse failing to attach with current, post-USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 11:17:46 -0000 On Wednesday 06 May 2009, Jase Thew wrote: > Hi, > Hi, Can you try the following patch: http://perforce.freebsd.org/chv.cgi?CH=161718 BTW: Thanks for reporting! --HPS From owner-freebsd-current@FreeBSD.ORG Thu May 7 11:57: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 3BE4E1065670 for ; Thu, 7 May 2009 11:57:22 +0000 (UTC) (envelope-from igor@kharin.org) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 1F8B08FC0C for ; Thu, 7 May 2009 11:57:21 +0000 (UTC) (envelope-from igor@kharin.org) Received: by rv-out-0506.google.com with SMTP id k40so615325rvb.43 for ; Thu, 07 May 2009 04:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.157.9 with SMTP id f9mr967156wfe.59.1241696166542; Thu, 07 May 2009 04:36:06 -0700 (PDT) In-Reply-To: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> References: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> Date: Thu, 7 May 2009 18:36:06 +0700 Message-ID: From: Igor Kharin To: Olivier SMEDTS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: can't build kernel without atkbd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 11:57:22 -0000 2009/5/7 Olivier SMEDTS : > Here's the kernel config : > > cpu HAMMER > ident QUAD > options SCHED_ULE > options PREEMPTION > options IPI_PREEMPTION > options INET > options INET6 > options FFS > options SOFTUPDATES > options UFS_DIRHASH > options COMPAT_IA32 > options SYSVSHM > options SYSVMSG > options SYSVSEM > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV > options STOP_NMI > options AUDIT > options VIMAGE > options PRINTF_BUFR_SIZE=128 > options SMP > device acpi > device pci > device vga > device sc > device loop > device ether > device pty > device bpf It's OK, just atkbd is required by syscons (man 4 sc): > The syscons driver is implemented on top of the keyboard driver > (atkbd(4)) and the video card driver (vga(4)) and so requires both of > them to be configured in the system. From owner-freebsd-current@FreeBSD.ORG Thu May 7 12:59: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 1DDC5106564A for ; Thu, 7 May 2009 12:59:49 +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 A3CAF8FC18 for ; Thu, 7 May 2009 12:59:48 +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 n47CxkZ6008888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 May 2009 12:59:46 GMT (envelope-from ben@wanderview.com) Message-Id: <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> From: Ben Kelly To: Richard Todd In-Reply-To: <20090506234631.231A5CD8@mx1.synetsystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 08:59:45 -0400 References: <20090506234631.231A5CD8@mx1.synetsystems.com> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's 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, 07 May 2009 12:59:49 -0000 On May 6, 2009, at 6:54 PM, Richard Todd wrote: > Hi. I updated my main -current box to the current sources as of > yesterday, > and I've managed to twice get the "wrong vnode panic" out of the > cache_enter > code. As you can see from the backtrace down at cache_enter at > frame 11, > the code is apparently expecting vp to point to a VDIR vnode, but > instead > it's pointing to a VLNK. (I've got another, similar, dump where vp > is > pointing to a VREG node.) In both cases, I was running tinderbox to > build > packages, with resulting heavy use of both zfs (the underlying > filesystem) > and nullfs, if that's relevant. > (kgdb) l > 697 if (dvp->v_cache_dd != NULL) { > 698 CACHE_WUNLOCK(); > 699 cache_free(ncp); > 700 return; > 701 } > 702 KASSERT(vp == NULL || vp->v_type == VDIR, > 703 ("wrong vnode type %p", vp)); > 704 dvp->v_cache_dd = ncp; > 705 } > 706 It looks like this KASSERT was added relatively recently as part of the dotdot changes to the namecache: http://svn.freebsd.org/viewvc/base?view=revision&revision=190945 Perhaps there is further fallout from the changes that only occur with ZFS? - Ben From owner-freebsd-current@FreeBSD.ORG Thu May 7 13:11: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 DB3F6106566C for ; Thu, 7 May 2009 13:11:47 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAE08FC12 for ; Thu, 7 May 2009 13:11:47 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1M23O6-000J2U-Eg for freebsd-current@FreeBSD.org; Thu, 07 May 2009 17:11:46 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Thu, 07 May 2009 17:11:46 +0400 Message-ID: <47975645@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: make -jN stalls X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 13:11:48 -0000 Hello List, I should have done something stupid, but any command "make -jN", (where N > 1) stalls the process after some time, even with blank /etc/make.conf. I use i386-CURRENT as of yesterday. Hereis a truss log from "make -C /usr/ports -j5 index" (it is really small): ftp://ftp.ipt.ru/pub/tmp/make.jN.log The directory /usr/ports is a link to /m/ports. Other than that is pretty default. What should be done, how to diagnose, etc... Thanks. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu May 7 13:13:12 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 587DA106564A for ; Thu, 7 May 2009 13:13:12 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3370E8FC08 for ; Thu, 7 May 2009 13:13:12 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id m38so427676waf.27 for ; Thu, 07 May 2009 06:13:11 -0700 (PDT) Received: by 10.114.53.1 with SMTP id b1mr2220637waa.173.1241701991359; Thu, 07 May 2009 06:13:11 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id q20sm209214pog.20.2009.05.07.06.13.08 (version=SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 06:13:10 -0700 (PDT) Date: Thu, 7 May 2009 03:15:56 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Olivier SMEDTS In-Reply-To: <367b2c980905070231r37a94eack399f5afed742247f@mail.gmail.com> Message-ID: References: <758865.1091.qm@web63907.mail.re1.yahoo.com> <367b2c980905070231r37a94eack399f5afed742247f@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 Cc: barney_cordoba@yahoo.com, pluknet , "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 13:13:12 -0000 On Thu, 7 May 2009, Olivier SMEDTS wrote: > 2009/5/7 Barney Cordoba : >> >> >> >> >> --- On Wed, 5/6/09, pluknet wrote: >> >>> From: pluknet >>> Subject: Re: Hypertherading >>> To: "Barney Cordoba" >>> Cc: "Current@freebsd.org" >>> Date: Wednesday, May 6, 2009, 10:55 PM >>> 2009/5/7 Barney Cordoba : >>>> >>>> I just got a shiny new nehalem box and it comes up >>> with 16 processors with dual quads installed. Is there any >>> benefit or should hyperthreading be disabled? > > There can be some benefit if the scheduler is aware of the topoly of > CPUs and Hyperthreading (shared cache). I don't know how SCHED_ULE > handles this on -CURRENT. If it doesn't see any difference between CPU > cores and "HT" cores, you should disable HT in BIOS. ULE is topology aware and most machines are probed properly. ULE will prefer not to use hyperthreaded cores if there is available time on an unloaded core. ULE will also freely share threads among hyperthreaded neighbors. I have found the hyperthreaded cores on nehalem to be significantly improved over the older version. On one packet forwarding test a 50% improvement was seen by enabling htt cores. I believe this is because the amount of memory bandwidth and is sufficient to support these cores where it was not before. Depending on how populated your memories are you may have less memory bandwidth and see less good results. You can always safely disable these cores by using cpuset to modify the default group, group 1, and experiment at run-time. Thanks, Jeff > >>>> >>> >>> Hi. There is a measurable win if hyperthreading is enabled >>> [1]. >>> You can switch it off via machdep.hyperthreading_enabled >>> loader tunable. >>> >>> [1] >>> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >>> >> >> I wouldn't call varying the number of jobs a very good test >> of hyperthreading. I'd want to see the exact same test with >> hyperthreading enabled and disabled. Its pretty naive >> to assume that running 16 jobs causes them to all be run on >> a different cpu. >> >> Barney >> >> >> >> _______________________________________________ >> 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" >> > > > > -- > 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." > _______________________________________________ > 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 7 13:17:04 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 4721E10656FD for ; Thu, 7 May 2009 13:17:04 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 2245D8FC08 for ; Thu, 7 May 2009 13:17:04 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id k40so642310rvb.43 for ; Thu, 07 May 2009 06:17:03 -0700 (PDT) Received: by 10.114.183.1 with SMTP id g1mr2269988waf.140.1241702223727; Thu, 07 May 2009 06:17:03 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id y11sm270155pod.18.2009.05.07.06.17.00 (version=SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 06:17:02 -0700 (PDT) Date: Thu, 7 May 2009 03:19:48 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "Leubner, Achim" In-Reply-To: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Message-ID: References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Maste , "current@freebsd.org" , "Sridaran, Gana" Subject: Re: softdep_move_dependencies panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 13:17:04 -0000 On Wed, 6 May 2009, Leubner, Achim wrote: > Hi Ed, Hi Scott, > > We run into a problem if a RAID array goes into an "error" state and is marked "offline". The new aac driver removes the device in this case with device_delete_child() and all commands to that device will be answered using biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_move_dependencies: need merge code" panic in the filesystem. Is there any possibility to avoid this panic? We see it under FreeBSD 7.1 too. > Any help is greatly appreciated. Hi Achim, Can you post the entire stack trace from the panic? Thanks, Jeff > > Thanks & Regards, > Achim > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > _______________________________________________ > 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 7 13:27: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 735A51065670 for ; Thu, 7 May 2009 13:27:50 +0000 (UTC) (envelope-from Achim_Leubner@adaptec.com) Received: from mail-gw3.adaptec.com (ts.adaptec.com [162.62.93.58]) by mx1.freebsd.org (Postfix) with ESMTP id 586598FC1E for ; Thu, 7 May 2009 13:27:50 +0000 (UTC) (envelope-from Achim_Leubner@adaptec.com) Received: from ADPE2K702.adaptec.com (adaptecpop.adaptec.com [10.25.8.26]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 7BDF42AF8F5; Thu, 7 May 2009 06:27:46 -0700 (PDT) Received: from ADPE2K703.adaptec.com ([10.25.8.22]) by ADPE2K702.adaptec.com ([10.25.8.26]) with mapi; Thu, 7 May 2009 06:27:46 -0700 From: "Leubner, Achim" To: Jeff Roberson Date: Thu, 7 May 2009 06:27:44 -0700 Thread-Topic: softdep_move_dependencies panic Thread-Index: AcnPFh4iMWCZR1hYQ9WMHaWY1cfimgAASW3w Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B6D33F1@ADPE2K703.adaptec.com> References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ed Maste , "current@freebsd.org" , "Sridaran, Gana" Subject: RE: softdep_move_dependencies panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 13:27:50 -0000 Hi Jeff, I'm currently on business trip. I'll send the stack trace next Monday. Thanks, Achim -----Original Message----- From: Jeff Roberson [mailto:jroberson@jroberson.net]=20 Sent: Thursday, May 07, 2009 3:20 PM To: Leubner, Achim Cc: Ed Maste; Scott Long; current@freebsd.org; Sridaran, Gana Subject: Re: softdep_move_dependencies panic On Wed, 6 May 2009, Leubner, Achim wrote: > Hi Ed, Hi Scott, > > We run into a problem if a RAID array goes into an "error" state and is m= arked "offline". The new aac driver removes the device in this case with de= vice_delete_child() and all commands to that device will be answered using = biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_= move_dependencies: need merge code" panic in the filesystem. Is there any p= ossibility to avoid this panic? We see it under FreeBSD 7.1 too. > Any help is greatly appreciated. Hi Achim, Can you post the entire stack trace from the panic? Thanks, Jeff > > Thanks & Regards, > Achim > > > =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 > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > _______________________________________________ > 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 7 13:57: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 32FBB106564A for ; Thu, 7 May 2009 13:57:45 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id D307A8FC15 for ; Thu, 7 May 2009 13:57:44 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 47162 invoked by uid 60001); 7 May 2009 13:57:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241704664; bh=HuFlHR2sU335qZjV96HNAOvW70+Y+43k8U+kkVLxUfA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=w3P1sSFr4Qm/MO0ajA8PBzMs61yaIosPINhIJ00qiVh1uiYmaTVW06p/PSeuLFSXhHB41964SoVGommXuFJ9gYmrRFz8m5T3whgNOjkHGx9ox6oD90zIrIln8vHt7tXp/FaxBy/ryTFwCbC4zwAX3wjGAFol4GeYpJPs5xrRVTM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=isI5BFjDuQsv98Z5rGnl0SL0Us23RO7+IO9F+LXJ5zF0QmE70aHszdGUFIo5u5lG8Je1b6c5ND1vQriCMEViwQt0/kuilKNAvZPztrUryFn0kxMSRKkl+7Bp+NbLJWqHTvVglDz/lQB9NZekzm2PWi6qBqW3AjXQEOD3G+zAQcE=; Message-ID: <418018.46727.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: V1MCDmEVM1mOgq8NaJR4BliYaI8uTTKieq.4ehkGeAhPXh6ZVjnNa2C9tLk8dmfJLY9kkM57w3PUtfsXGUQnN6DSuNFuaWm6HWLVdfHlL8254aog1_egM3XvynXAzZSNXqyaPVV8PUch7yp88BvxWBdXEmSLPPvPGQ59Pd.VmeQY38Cnt6tAefYxwor6o_AuPKP7JpArewbItj9Nr.6C_hC9msV9XnGKV5gw._v0obZb3Cv7l0VrCH0azYNiucR4dt.GnhtuIcUb6lUgQ_1DU8vcJPCYgl08sZhYh6SFQGKvKi88YH5Rmjs- Received: from [98.242.223.106] by web63901.mail.re1.yahoo.com via HTTP; Thu, 07 May 2009 06:57:44 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Thu, 7 May 2009 06:57:44 -0700 (PDT) From: Barney Cordoba To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.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, 07 May 2009 13:57:45 -0000 --- On Wed, 5/6/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Barney Cordoba" > Cc: "Current@freebsd.org" > Date: Wednesday, May 6, 2009, 10:55 PM > 2009/5/7 Barney Cordoba : > > > > I just got a shiny new nehalem box and it comes up > with 16 processors with dual quads installed. Is there any > benefit or should hyperthreading be disabled? > > > > Hi. There is a measurable win if hyperthreading is enabled > [1]. > You can switch it off via machdep.hyperthreading_enabled > loader tunable. > > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html > > > -- > wbr, > pluknet I assume you mean hyperthreading-allowed? I set sysctl -a | grep hyper machdep.hyperthreading_allowed: 0 but it still launches 16 cpus. Is that expected? It doesn't seem correct. Barney From owner-freebsd-current@FreeBSD.ORG Thu May 7 14:31: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 28D1F106566C for ; Thu, 7 May 2009 14:31:54 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from mx-2.btshosting.co.uk (mx-2.btshosting.co.uk [87.117.208.79]) by mx1.freebsd.org (Postfix) with ESMTP id E41318FC19 for ; Thu, 7 May 2009 14:31:53 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.1.65] (host86-139-98-149.range86-139.btcentralplus.com [86.139.98.149]) (Authenticated sender: bazerka@beardz.net) by mx-2.btshosting.co.uk (Postfix) with ESMTPA id 1D1136E54DA; Thu, 7 May 2009 15:31:52 +0100 (BST) Message-ID: <4A02F0D0.50205@beardz.net> Date: Thu, 07 May 2009 15:31:44 +0100 From: Jase Thew User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hans Petter Selasky References: <4A00DACA.1010500@beardz.net> <200905071320.17310.hselasky@c2i.net> In-Reply-To: <200905071320.17310.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mx-2.btshosting.co.uk X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Another USB mouse failing to attach with current, post-USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 14:31:54 -0000 Hans Petter Selasky wrote: > On Wednesday 06 May 2009, Jase Thew wrote: >> Hi, >> > > Hi, > > Can you try the following patch: > > http://perforce.freebsd.org/chv.cgi?CH=161718 > > BTW: Thanks for reporting! > > --HPS Hi Hans, The patch works perfectly - the mouse is now attaching successfully : ugen2.2: at usbus2 ums0: on usbus2 ums0: 7 buttons and [XYZ] coordinates ID=0 Thanks very much for fixing this issue. Regards, Jase. From owner-freebsd-current@FreeBSD.ORG Thu May 7 14:42: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 BA2AC1065687; Thu, 7 May 2009 14:42:45 +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 227E28FC0A; Thu, 7 May 2009 14:42:45 +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 A4567A0846; Thu, 7 May 2009 16:42:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 95B30A0845; Thu, 7 May 2009 16:42:41 +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 71C1BA0839; Thu, 7 May 2009 16:42:41 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050716424011-8183 ; Thu, 7 May 2009 16:42:40 +0200 Received: by wep4035 (sSMTP sendmail emulation); Thu, 7 May 2009 16:42:40 +0200 Date: Thu, 7 May 2009 16:42:40 +0200 From: Alexey Shuvaev To: Eygene Ryabinkin Message-ID: <20090507144240.GA68128@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A0265ED.4070407@freebsd.org> MIME-Version: 1.0 In-Reply-To: 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.2HF443 | November 25, 2008) at 05/07/2009 04:42:40 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/07/2009 04:42:40 PM, Serialize complete at 05/07/2009 04:42:40 PM Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Tim Kientzle , openoffice@freebsd.org, freebsd-current@freebsd.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 14:42:46 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 07, 2009 at 10:05:40AM +0400, Eygene Ryabinkin wrote: > Wed, May 06, 2009 at 09:39:09PM -0700, Tim Kientzle wrote: > > I tried but could not reproduce your bug using > > a recent -CURRENT. I downloaded this file: > > > > http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > > > and extracted ooo_crystal_images-1.tar.gz > > and got the same MD5 that Eygene reported. > > > > $ md5 ooo_crystal_images-1.tar.gz > > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > > > Where did you download your file from? > > Alexey's .tar.gz file should be also fine: he reported the checksum from > the .tar file, not .tar.gz one: > ----- > ~/tmp> md5 crystal.tar > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > ----- > I have the same MD5 for the .tar file: > ----- > $ md5 crystal.tar > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > ----- > > I am not able to reproduce the bug too, so perhaps the output from > ktrace, > ----- > ktrace -f gunzip.trace gunzip -c ooo_crystal_images-1.tar.gz | (ktrace -f tar.trace tar -xf -) > ----- > will be useful for diagnostics. The files of interest will be > gunzip.trace and tar.trace. > Ok, ktraces/kdumps on my system show that tar is exiting before the last gunzip's write :( gunzip.dump.human shows the last successful write on gunzip side and tar.dump.human shows the read sequence on tar side. gunzip has written 65536 bytes whereas tar has read 6 x 10240 = 61440 bytes and has exited thereafter. gunzip has got successful write operation (65536 bytes). At last gunzip tries to write 4932 zeros and fails... The command is exactly as above. FWIW: ~> echo $SHELL /bin/tcsh Alexey. --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gunzip.dump.human" [snip] 0x0fd0 0603 87f9 1773 ae4b 2b37 a19e ce15 52bc |.....s.K+7....R.| 0x0fe0 62b6 b026 c61f acf8 6fbe 1afc 89fe b3fd |b..&....o.......| 0x0ff0 7cfd ff8f fc9f 9999 83f5 0fff f74b ff7f ||............K..| 64841 gunzip 1241690009.435989 RET read 30608/0x7790 64841 gunzip 1241690009.436242 CALL write(0x1,0x800b02000,0x10000) 64841 gunzip 1241690009.444528 GIO fd 1 wrote 4096 bytes 0x0000 e15b a552 0104 0010 6b0f 00e5 dddd dd14 |.[.R....k.......| 0x0010 1403 a328 4011 deca 181e 0a24 4088 1840 |...(@......$@..@| 0x0020 310a 58bc 668e 018d 8e8e 1aa4 d702 2546 |1.X.f.........%F| [snip] 0x0fd0 3036 3534 3637 3600 3031 3435 3335 0020 |0654676.014535. | 0x0fe0 3000 0000 0000 0000 0000 0000 0000 0000 |0...............| 0x0ff0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 64841 gunzip 1241690009.444537 RET write 65536/0x10000 64841 gunzip 1241690009.444627 CALL write(0x1,0x800b02000,0x1344) 64841 gunzip 1241690009.444638 RET write -1 errno 32 Broken pipe 64841 gunzip 1241690009.444722 PSIG SIGPIPE SIG_DFL --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tar.dump.human" [snip] 0x0290 1f47 1090 009a 9a9a 62df 1e00 0280 2814 |.G......b.....(.| 0x02a0 0acc a0c5 00e7 1840 2983 bc13 253c 4319 |.......@)...%....]:| [snip] 0x0fd0 77f7 98cd 4624 3140 28fe 8432 0c6f 8665 |w...F$1@(..2.o.e| 0x0fe0 0d4c 8a97 4624 8f30 c886 bb6f dffe b1b0 |.L..F$.0...o....| 0x0ff0 b0f0 411c 632c 1249 7df2 c557 f527 8f52 |..A.c,.I}..W.'.R| 64842 bsdtar 1241690009.439197 RET read 10240/0x2800 [snip] /* 4-th read. */ 64842 bsdtar 1241690009.439945 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.439955 GIO fd 0 read 4096 bytes 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0010 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 |................| [snip] 0x0fd0 c5e9 d4df e60b 2f9e e1e6 6894 0251 b486 |....../...h..Q..| 0x0fe0 cd50 d522 b4d6 62a5 1a60 664c e59b 5fd2 |.P."..b..`fL.._.| 0x0ff0 7979 56a1 6d5a d84e 4356 d713 ff0d bdbe |yyV.mZ.NCV......| 64842 bsdtar 1241690009.439962 RET read 10240/0x2800 [snip] /* 5-th read. */ 64842 bsdtar 1241690009.441049 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.441059 GIO fd 0 read 4096 bytes 0x0000 71f1 e5b8 e9e9 993b 667c 56c1 47b8 b6c5 |q......;f|V.G...| 0x0010 361b fc38 687d affb 4c9d 0a8f 8951 1b05 |6..8h}..L....Q..| 0x0020 52f1 95b8 0d7c 1930 1ee2 993e 243e ade0 |R....|.0...>$>..| [snip] 0x0fd0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0fe0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0ff0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 64842 bsdtar 1241690009.441065 RET read 10240/0x2800 [snip] /* 6-th read. */ 64842 bsdtar 1241690009.442445 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.442455 GIO fd 0 read 4096 bytes 0x0000 d357 8185 7ed3 ae16 c5d2 c425 b41c af2f |.W..~......%.../| 0x0010 31b8 471e aacc 5053 53eb 7e4d 6dc3 e8d9 |1.G...PSS.~Mm...| 0x0020 53f5 6f3f 3e8a 94b1 9000 e6af 03cf af11 |S.o?>...........| [snip] 0x0fd0 71b9 94bc 06e8 3b15 82e2 13a4 3ced c2af |q.....;.....<...| 0x0fe0 f258 57a0 c20b 4081 8069 f18e 7938 334e |.XW...@..i..y83N| 0x0ff0 72a0 abca 9f59 10ee 3e12 8a01 b3f7 c13d |r....Y..>......=| 64842 bsdtar 1241690009.442462 RET read 10240/0x2800 [snip] 64842 bsdtar 1241690009.443046 CALL futimes(0x3,0x7fffffffe3b0) 64842 bsdtar 1241690009.443056 RET futimes 0 64842 bsdtar 1241690009.443062 CALL close(0x3) 64842 bsdtar 1241690009.443069 RET close 0 64842 bsdtar 1241690009.443097 CALL lutimes(0x80101b320,0x7fffffffe3c0) 64842 bsdtar 1241690009.443104 NAMI "crystal/vcl/source/src/" 64842 bsdtar 1241690009.443121 RET lutimes 0 64842 bsdtar 1241690009.443128 CALL lutimes(0x80101b300,0x7fffffffe3c0) 64842 bsdtar 1241690009.443135 NAMI "crystal/vcl/source/" 64842 bsdtar 1241690009.443150 RET lutimes 0 64842 bsdtar 1241690009.443156 CALL lutimes(0x80108e0d0,0x7fffffffe3c0) 64842 bsdtar 1241690009.443162 NAMI "crystal/vcl/" 64842 bsdtar 1241690009.443176 RET lutimes 0 [snip] 64842 bsdtar 1241690009.444351 CALL lutimes(0x80108e060,0x7fffffffe3c0) 64842 bsdtar 1241690009.444357 NAMI "crystal/" 64842 bsdtar 1241690009.444369 RET lutimes 0 64842 bsdtar 1241690009.444398 CALL sigaction(SIG29,0x7fffffffe520,0x7fffffffe500) 64842 bsdtar 1241690009.444407 RET sigaction 0 64842 bsdtar 1241690009.444413 CALL sigaction(SIGUSR1,0x7fffffffe520,0x7fffffffe500) 64842 bsdtar 1241690009.444419 RET sigaction 0 64842 bsdtar 1241690009.444440 CALL sigprocmask(SIG_BLOCK,0x8006417e0,0x7fffffffe690) 64842 bsdtar 1241690009.444448 RET sigprocmask 0 64842 bsdtar 1241690009.444455 CALL sigprocmask(SIG_SETMASK,0x8006417f0,0) 64842 bsdtar 1241690009.444461 RET sigprocmask 0 64842 bsdtar 1241690009.444476 CALL sigprocmask(SIG_BLOCK,0x8006417e0,0x7fffffffe660) 64842 bsdtar 1241690009.444482 RET sigprocmask 0 64842 bsdtar 1241690009.444488 CALL sigprocmask(SIG_SETMASK,0x8006417f0,0) 64842 bsdtar 1241690009.444494 RET sigprocmask 0 64842 bsdtar 1241690009.444510 CALL exit(0) --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Thu May 7 16:22: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 133D01065670 for ; Thu, 7 May 2009 16:22:57 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3C88FC1C for ; Thu, 7 May 2009 16:22:56 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 5F0A83B811; Thu, 7 May 2009 18:22:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to4PaABNzTOY; Thu, 7 May 2009 18:22:55 +0200 (CEST) Received: from rron.local (unknown [137.122.68.155]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 64DA83AAF0; Thu, 7 May 2009 18:22:54 +0200 (CEST) Message-ID: <4A030ADB.9050802@keltia.freenix.fr> Date: Thu, 07 May 2009 18:22:51 +0200 From: Ollivier Robert User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090506 Shredder/3.0b3pre MIME-Version: 1.0 To: Bob Bishop References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> In-Reply-To: <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 16:22:57 -0000 On 7/05/2009 10:17, Bob Bishop wrote: > AFAICS the reference doesn't support that conclusion at all. Nehalem CPUs'HT feature is significantly different from the one present in previous P4 CPUs. Apparently, Nehalem's HT works. Memory bandwidth being much higher helps too. -- Ollivier Robert -=- roberto@keltia.freenix.fr From owner-freebsd-current@FreeBSD.ORG Thu May 7 16:26: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 A2450106566C for ; Thu, 7 May 2009 16:26:12 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 582818FC17 for ; Thu, 7 May 2009 16:26:12 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n47GQ9U2084134; Thu, 7 May 2009 10:26:09 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A030BA1.8070709@samsco.org> Date: Thu, 07 May 2009 10:26:09 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Ollivier Robert References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> <4A030ADB.9050802@keltia.freenix.fr> In-Reply-To: <4A030ADB.9050802@keltia.freenix.fr> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 16:26:12 -0000 Ollivier Robert wrote: > On 7/05/2009 10:17, Bob Bishop wrote: >> AFAICS the reference doesn't support that conclusion at all. > Nehalem CPUs'HT feature is significantly different from the one present > in previous P4 CPUs. Apparently, Nehalem's HT works. Memory bandwidth > being much higher helps too. > I keep here the anecdote that "it's better". Is there a good reference somewhere that describes exactly how it works? Scott From owner-freebsd-current@FreeBSD.ORG Thu May 7 16:38:13 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 1C525106564A for ; Thu, 7 May 2009 16:38:13 +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 AD7698FC16 for ; Thu, 7 May 2009 16:38:12 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 88822 invoked from network); 7 May 2009 16:11:32 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 7 May 2009 16:11:32 -0000 Message-ID: <4A0307F7.6000403@acm.poly.edu> Date: Thu, 07 May 2009 12:10:31 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: barney_cordoba@yahoo.com References: <418018.46727.qm@web63901.mail.re1.yahoo.com> In-Reply-To: <418018.46727.qm@web63901.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pluknet , "Current@freebsd.org" Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 16:38:13 -0000 Barney Cordoba wrote: > > > --- On Wed, 5/6/09, pluknet wrote: > > >> From: pluknet >> Subject: Re: Hypertherading >> To: "Barney Cordoba" >> Cc: "Current@freebsd.org" >> Date: Wednesday, May 6, 2009, 10:55 PM >> 2009/5/7 Barney Cordoba : >> >>> I just got a shiny new nehalem box and it comes up >>> >> with 16 processors with dual quads installed. Is there any >> benefit or should hyperthreading be disabled? >> >> Hi. There is a measurable win if hyperthreading is enabled >> [1]. >> You can switch it off via machdep.hyperthreading_enabled >> loader tunable. >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >> >> >> -- >> wbr, >> pluknet >> > > I assume you mean hyperthreading-allowed? > > I set > > sysctl -a | grep hyper > > machdep.hyperthreading_allowed: 0 > > > but it still launches 16 cpus. Is that expected? It doesn't seem correct. > > Barney > > > > _______________________________________________ > 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" > If I recall correctly, that sysctl only prevents processes from being scheduled on the "virtual" hyper-threaded CPUs, and does not affect their discovery by the kernel. -Boris From owner-freebsd-current@FreeBSD.ORG Thu May 7 17:51: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 C213F106566C; Thu, 7 May 2009 17:51:51 +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 8FF948FC16; Thu, 7 May 2009 17:51:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n47HpoKM004203; Thu, 7 May 2009 10:51:51 -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 b4eti8a3ediv8nkn7mgdhtz3en; Thu, 07 May 2009 10:51:50 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A031FB6.2050907@freebsd.org> Date: Thu, 07 May 2009 10:51:50 -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: Alexey Shuvaev References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, openoffice@freebsd.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 17:51:52 -0000 >>>> Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: >>>>> The reason appeared to be the first part of the command >>>>> "gunzip -c ... | ( tar -xf - ) && touch ..." >>>>> which exited with non-zero exit status (141) and "touch ..." was not >>> called. >>>>> Running the command manually has showed that gunzip was complaining >>> about >>>>> broken pipe (however the archive was extracted successfully). >>>> Yes, 141 means that SIGPIPE was delivered. This in turn means that >>>> 'tar -xf -' exited before gunzip had finished its job and gunzip had >>>> tried to write more data to the pipe. I finally reproduced this; it seems to only happen with /bin/csh. It does not happen with /bin/sh or bash. Also, in /bin/csh, this works: (gunzip -c ooo_crystal_images-1.tar.gz | tar xf -) && echo OK and this fails: gunzip -c ooo_crystal_images-1.tar.gz | (tar xf -) && echo OK Tim From owner-freebsd-current@FreeBSD.ORG Thu May 7 19:06: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 8C52B106564A for ; Thu, 7 May 2009 19:06:23 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 479A28FC16 for ; Thu, 7 May 2009 19:06:23 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id 0092A1018B8BC for ; Thu, 7 May 2009 21:05:19 +0200 (CEST) Received: from [217.236.38.100] (helo=zelda.local) by smtp05.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1M28uE-0000SX-00 for freebsd-current@FreeBSD.org; Thu, 07 May 2009 21:05:18 +0200 Date: Thu, 7 May 2009 21:05:16 +0200 From: Martin To: freebsd-current@FreeBSD.org Message-ID: <20090507210516.06331fb2@zelda.local> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+35uLtVunP+iNQYRQkUKBidG66Fpbj/9bpH10G Nf9GhAgiRL5k0e3VoIEPJAx9lziyVkKvt3e3ghlQxDy/ULdJ3t zpanfLKKk= Cc: Subject: ZFS panic space_map.c line 110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 19:06:23 -0000 Hi, I have a file server running ZFS on -CURRENT. Someone has tried to transfer a file with several gigabytes onto the system. The kernel crashed with a panic and freezed up during spewing the panic. I've only written down the most important messages: solaris assert ss==NULL zfs/space_map.c line 110 process: 160 spa_zio I've heard that I can try to move the zpool cache away and import the zpool with force once again. Will this help? I am asking because I don't know if the panic is caused by a corrupt cache or corrupt file system metadata. Maybe someone can explain it. (I had to switch the server off very ungently and the underlying RAID is rebuilding, so I can try it out later.) Is this issue with inconsistent zpools well known? I've seen some posts from 2007 and January 2009 that reported similar problems. Apparently some people have lost their entire zpools multiple times already, as far as I understood it. One more piece of information I can give is that every hour the ZFS file systems create snapshots. Maybe it triggered some inconsistency between the writes to a file system and the snapshot, I cannot tell, because I don't understand the condition. -- Martin From owner-freebsd-current@FreeBSD.ORG Thu May 7 19:42: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 339EB106566B for ; Thu, 7 May 2009 19:42:45 +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 5B0898FC0A for ; Thu, 7 May 2009 19:42:44 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [192.168.42.48] (unknown [192.168.42.48]) by itchy.rabson.org (Postfix) with ESMTP id D20DD5C62; Thu, 7 May 2009 20:42:34 +0100 (BST) Message-Id: <05FB85E2-1BB9-4EA7-9ED2-C92CB1014783@rabson.org> From: Doug Rabson To: Tom McLaughlin In-Reply-To: <49FCB96E.1010604@sdf.lonestar.org> Content-Type: multipart/mixed; boundary=Apple-Mail-9--722357766 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 15:42:10 -0400 References: <49D851FC.4090103@sdf.lonestar.org> <49FCB96E.1010604@sdf.lonestar.org> X-Mailer: Apple Mail (2.930.3) Cc: current@freebsd.org Subject: Re: NFS lockd/statd lock up network connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 May 2009 19:42:45 -0000 --Apple-Mail-9--722357766 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2 May 2009, at 17:21, Tom McLaughlin wrote: > Doug Rabson wrote, On 04/08/2009 03:20 PM: >> On 5 Apr 2009, at 07:38, Tom McLaughlin wrote: >>> Hey, I have a recent -CURRENT box which has a mount exported from an >>> OpenBSD NFS server. Recently I enabled lockd and statd on the >>> machine >>> but this has started to cause the network connection on the >>> machine to lockup. I find the following in dmesg: >>> >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> NLM: failed to contact remote rpcbind, stat = 5, port = 28416 >>> >>> Additionally I see this when trying to restart netif: >>> >>> em0: Could not setup receive structures >>> >>> I've tried building with NFS_LEGACYRPC but that has not changed >>> anything. Additionally I've tested this on 7-STABLE and while >>> lockd still does not work (so, looks like I'll still have to work >>> around my need for NFS locking) the network connection at least >>> does not lock up. Is what I'm seeing evidence of some further >>> problem? >> It looks as if lockd is not running on the server. The NFS locking >> protocol needs it enabled at both ends. Also, NFS_LEGACYRPC won't >> affect this - the record locking code always uses the new RPC code. > > Hi Doug, lockd is runing on both ends. The problem appears to be > with the system running out of mbuf clusters when using lockd. [1] > For now I'm mounting the particular mount with nolockd as an option > to get around this. I've gotten errors with my -STABLE box using > this mount with lockd enabled but at least the system didn't run out > of mbuf clusters and lose all network connectivity. Could you please try the attached (unfortunately untested - I'm at BSDCan) patch and see if it affects your problem. This patch attempts to fix PR 130628 which appears similar to your issue. --Apple-Mail-9--722357766 Content-Disposition: attachment; filename=rpc-deadlock.diff Content-Type: application/octet-stream; x-unix-mode=0664; name="rpc-deadlock.diff" Content-Transfer-Encoding: 7bit Index: rpc/svc_dg.c =================================================================== --- rpc/svc_dg.c (revision 191886) +++ rpc/svc_dg.c (working copy) @@ -53,6 +53,7 @@ #include #include #include +#include #include #include @@ -118,7 +119,7 @@ xprt = mem_alloc(sizeof (SVCXPRT)); memset(xprt, 0, sizeof (SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -161,6 +162,9 @@ svc_dg_stat(SVCXPRT *xprt) { + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -173,22 +177,17 @@ int error, rcvflag; /* + * Serialise access to the socket. + */ + sx_xlock(&xprt->xp_lock); + + /* * The socket upcall calls xprt_active() which will eventually * cause the server to call us here. We attempt to read a * packet from the socket and process it. If the read fails, * we have drained all pending requests so we call * xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; mreq = NULL; @@ -196,8 +195,19 @@ error = soreceive(xprt->xp_socket, &raddr, &uio, &mreq, NULL, &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after taking the + * lock to protect us in the case where a new packet + * arrives on the socket after our call to soreceive + * fails with EWOULDBLOCK. The pool lock protects us + * from racing the upcall after our soreadable() call + * returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -208,11 +218,11 @@ xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); KASSERT(raddr->sa_len < xprt->xp_rtaddr.maxlen, ("Unexpected remote address length")); @@ -301,7 +311,7 @@ xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -328,7 +338,5 @@ { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } Index: rpc/svc_vc.c =================================================================== --- rpc/svc_vc.c (revision 191886) +++ rpc/svc_vc.c (working copy) @@ -54,6 +54,7 @@ #include #include #include +#include #include #include #include @@ -142,7 +143,7 @@ } xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -219,7 +220,7 @@ cd->strm_stat = XPRT_IDLE; xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = cd; @@ -255,9 +256,9 @@ * Throw the transport into the active list in case it already * has some data buffered. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (xprt); cleanup_svc_vc_create: @@ -347,22 +348,27 @@ * connection from the socket and turn it into a new * transport. If the accept fails, we have drained all pending * connections so we call xprt_inactive(). - * - * The lock protects us in the case where a new connection arrives - * on the socket after our call to accept fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); error = svc_vc_accept(xprt->xp_socket, &so); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for new connections after taking + * the lock to protect us in the case where a new + * connection arrives after our call to accept fails + * with EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our TAILQ_EMPTY() call + * returns false. + */ + ACCEPT_LOCK(); + mtx_lock(&xprt->xp_pool->sp_lock); + if (TAILQ_EMPTY(&xprt->xp_socket->so_comp)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + ACCEPT_UNLOCK(); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -373,11 +379,11 @@ xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); sa = 0; error = soaccept(so, &sa); @@ -422,7 +428,7 @@ xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -483,21 +489,29 @@ /* * Return XPRT_MOREREQS if we have buffered data and we are - * mid-record or if we have enough data for a record marker. + * mid-record or if we have enough data for a record + * marker. Since this is only a hint, we read mpending and + * resid outside the lock. We do need to take the lock if we + * have to traverse the mbuf chain. */ if (cd->mpending) { if (cd->resid) return (XPRT_MOREREQS); n = 0; + sx_xlock(&xprt->xp_lock); m = cd->mpending; while (m && n < sizeof(uint32_t)) { n += m->m_len; m = m->m_next; } + sx_xunlock(&xprt->xp_lock); if (n >= sizeof(uint32_t)) return (XPRT_MOREREQS); } + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -509,6 +523,12 @@ struct mbuf *m; int error, rcvflag; + /* + * Serialise access to the socket and our own record parsing + * state. + */ + sx_xlock(&xprt->xp_lock); + for (;;) { /* * If we have an mbuf chain in cd->mpending, try to parse a @@ -584,6 +604,7 @@ */ xdrmbuf_create(&xprt->xp_xdrreq, cd->mreq, XDR_DECODE); cd->mreq = NULL; + sx_xunlock(&xprt->xp_lock); if (! xdr_callmsg(&xprt->xp_xdrreq, msg)) { XDR_DESTROY(&xprt->xp_xdrreq); return (FALSE); @@ -602,17 +623,7 @@ * the result in cd->mpending. If the read fails, * we have drained both cd->mpending and the socket so * we can call xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; m = NULL; @@ -621,8 +632,20 @@ &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after + * taking the lock to protect us in the case + * where a new packet arrives on the socket + * after our call to soreceive fails with + * EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our soreadable() + * call returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -634,7 +657,7 @@ SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -642,8 +665,9 @@ /* * EOF - the other end has closed the socket. */ + xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -651,8 +675,6 @@ m_last(cd->mpending)->m_next = m; else cd->mpending = m; - - mtx_unlock(&xprt->xp_lock); } } @@ -739,9 +761,7 @@ { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } #if 0 Index: rpc/svc.c =================================================================== --- rpc/svc.c (revision 191886) +++ rpc/svc.c (working copy) @@ -178,18 +178,23 @@ } void -xprt_inactive(SVCXPRT *xprt) +xprt_inactive_locked(SVCXPRT *xprt) { SVCPOOL *pool = xprt->xp_pool; - mtx_lock(&pool->sp_lock); - if (xprt->xp_active) { TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); xprt->xp_active = FALSE; } - wakeup(&pool->sp_active); +} +void +xprt_inactive(SVCXPRT *xprt) +{ + SVCPOOL *pool = xprt->xp_pool; + + mtx_lock(&pool->sp_lock); + xprt_inactive_locked(xprt); mtx_unlock(&pool->sp_lock); } Index: rpc/svc.h =================================================================== --- rpc/svc.h (revision 191886) +++ rpc/svc.h (working copy) @@ -47,6 +47,7 @@ #include #include #include +#include #endif /* @@ -128,7 +129,7 @@ */ typedef struct __rpc_svcxprt { #ifdef _KERNEL - struct mtx xp_lock; + struct sx xp_lock; struct __rpc_svcpool *xp_pool; /* owning pool (see below) */ TAILQ_ENTRY(__rpc_svcxprt) xp_link; TAILQ_ENTRY(__rpc_svcxprt) xp_alink; @@ -332,6 +333,7 @@ __BEGIN_DECLS extern void xprt_active(SVCXPRT *); extern void xprt_inactive(SVCXPRT *); +extern void xprt_inactive_locked(SVCXPRT *); __END_DECLS #endif --Apple-Mail-9--722357766 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-9--722357766-- From owner-freebsd-current@FreeBSD.ORG Thu May 7 20:33: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 53940106566B; Thu, 7 May 2009 20:33:25 +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 1CED38FC0C; Thu, 7 May 2009 20:33:25 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n47KXOWl006267; Thu, 7 May 2009 13:33:24 -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 m5q48e9drdfqcryyxkruzuh8gi; Thu, 07 May 2009 13:33:24 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A034594.4010405@freebsd.org> Date: Thu, 07 May 2009 13:33:24 -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: Alexey Shuvaev , "'freebsd-current@freebsd.org'" , openoffice@freebsd.org References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A031FB6.2050907@freebsd.org> <20090507184121.GA70931@wep4035.physik.uni-wuerzburg.de> <20090507193213.GC70931@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090507193213.GC70931@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 20:33:25 -0000 Alexey Shuvaev wrote: > On Thu, May 07, 2009 at 08:41:21PM +0200, Alexey Shuvaev wrote: >> On Thu, May 07, 2009 at 10:51:50AM -0700, Tim Kientzle wrote: >>> I finally reproduced this; it seems to only happen with >>> /bin/csh. It does not happen with /bin/sh or bash. >>> >>> Also, in /bin/csh, this works: >>> >>> (gunzip -c ooo_crystal_images-1.tar.gz | tar xf -) && echo OK >>> >>> and this fails: >>> >>> gunzip -c ooo_crystal_images-1.tar.gz | (tar xf -) && echo OK >>> >> Do you mean it is a bug in [t]csh? No, this is definitely a bug in tar. I finally found the place where tar was not always reading beyond end-of-archive on a pipe. This doesn't show up under /bin/sh or bash because for those shells, the return status of "gunzip|tar" is the exit status of the last command ("tar"). For csh, the return status of the pipeline is the return status of the first command. So for other shells, the SIGPIPE exit from gunzip doesn't cause the whole sequence to fail (because "tar" exits with success). I'm testing a fix now; it will be committed later today. Tim From owner-freebsd-current@FreeBSD.ORG Thu May 7 22:03: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 E6A601065675; Thu, 7 May 2009 22:03:38 +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 A5D218FC20; Thu, 7 May 2009 22:03:38 +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 n47M3aOF043812; Thu, 7 May 2009 18:03:36 -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 n47M3a37083053; Thu, 7 May 2009 18:03:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 10EBA7302F; Thu, 7 May 2009 18:03:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090507220336.10EBA7302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 18:03:36 -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, 07 May 2009 22:03:39 -0000 TB --- 2009-05-07 21:18:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 21:18:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-05-07 21:18:13 - cleaning the object tree TB --- 2009-05-07 21:18:46 - cvsupping the source tree TB --- 2009-05-07 21:18:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-07 21:19:00 - building world TB --- 2009-05-07 21:19:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 21:19:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 21:19:00 - TARGET=sun4v TB --- 2009-05-07 21:19:00 - TARGET_ARCH=sparc64 TB --- 2009-05-07 21:19:00 - TZ=UTC TB --- 2009-05-07 21:19:00 - __MAKE_CONF=/dev/null TB --- 2009-05-07 21:19:00 - cd /src TB --- 2009-05-07 21:19:00 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 21:19:06 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 [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/sun4v/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 22:03:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 22:03:35 - ERROR: failed to build world TB --- 2009-05-07 22:03:35 - 2232.81 user 262.47 system 2722.11 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu May 7 23:03: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 75C7C106571F; Thu, 7 May 2009 23:03:34 +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 4C62E8FC1B; Thu, 7 May 2009 23:03:34 +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 n47N3V6Q077935; Thu, 7 May 2009 19:03:31 -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 n47N3VIe046119; Thu, 7 May 2009 19:03:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1C16E7302F; Thu, 7 May 2009 19:03:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090507230331.1C16E7302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 19:03:31 -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 arm/arm 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, 07 May 2009 23:03:36 -0000 TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-07 22:20:00 - cleaning the object tree TB --- 2009-05-07 22:20:48 - cvsupping the source tree TB --- 2009-05-07 22:20:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-07 22:20:58 - building world TB --- 2009-05-07 22:20:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 22:20:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 22:20:58 - TARGET=arm TB --- 2009-05-07 22:20:58 - TARGET_ARCH=arm TB --- 2009-05-07 22:20:58 - TZ=UTC TB --- 2009-05-07 22:20:58 - __MAKE_CONF=/dev/null TB --- 2009-05-07 22:20:58 - cd /src TB --- 2009-05-07 22:20:58 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 22:21:00 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 [...] cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/arm/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:03:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:03:30 - ERROR: failed to build world TB --- 2009-05-07 23:03:30 - 1926.59 user 271.18 system 2610.58 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu May 7 23:09: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 23A96106566C; Thu, 7 May 2009 23:09:38 +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 CA3888FC0A; Thu, 7 May 2009 23:09:37 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n47N9X2V007876; Thu, 7 May 2009 16:09:33 -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 ka7wnkncppkxrk8cs93xki9pra; Thu, 07 May 2009 16:09:32 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A036A2C.1070606@freebsd.org> Date: Thu, 07 May 2009 16:09:32 -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: Alexey Shuvaev References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, openoffice@freebsd.org Subject: Re: gunzip | tar reports broken pipe during OOO build on 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, 07 May 2009 23:09:38 -0000 Alexey Shuvaev wrote: > Hello all! > > I was trying to upgrade editors/openoffice.org-2 recently and > build failed for me at: ... > The reason appeared to be the first part of the command > "gunzip -c ... | ( tar -xf - ) && touch ..." > which exited with non-zero exit status (141) and "touch ..." was not called. > Running the command manually has showed that gunzip was complaining about > broken pipe (however the archive was extracted successfully). I just committed r191904, which should fix the tar problem (actually, a libarchive problem) that caused this. This problem was introduced in r191171 on 2009-04-16 when I went a little too far trying to eliminate some duplicated code. As a result, tar was no longer flushing the pipe after it hit end-of-archive, which caused gunzip to receive SIGPIPE for the final writes. This only causes problems with /bin/csh, which reports the exit status of the first command in a pipeline (unlike /bin/sh, which reports the exit status of the last command). Tim From owner-freebsd-current@FreeBSD.ORG Thu May 7 23:14:12 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 D4AA510656A8; Thu, 7 May 2009 23:14:12 +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 96A368FC1B; Thu, 7 May 2009 23:14:12 +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 n47NE9pS048358; Thu, 7 May 2009 19:14:09 -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 n47NE8LS039740; Thu, 7 May 2009 19:14:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D1B3A7302F; Thu, 7 May 2009 19:14:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 19:14:08 -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 amd64/amd64 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, 07 May 2009 23:14:13 -0000 TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-05-07 22:20:00 - cleaning the object tree TB --- 2009-05-07 22:21:25 - cvsupping the source tree TB --- 2009-05-07 22:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-05-07 22:21:33 - building world TB --- 2009-05-07 22:21:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 22:21:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 22:21:33 - TARGET=amd64 TB --- 2009-05-07 22:21:33 - TARGET_ARCH=amd64 TB --- 2009-05-07 22:21:33 - TZ=UTC TB --- 2009-05-07 22:21:33 - __MAKE_CONF=/dev/null TB --- 2009-05-07 22:21:33 - cd /src TB --- 2009-05-07 22:21:33 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 22:21:34 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 [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/amd64/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:14:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:14:08 - ERROR: failed to build world TB --- 2009-05-07 23:14:08 - 2356.94 user 283.40 system 3248.40 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu May 7 23:42: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 AA55F106566B for ; Thu, 7 May 2009 23:42:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 62E8B8FC17 for ; Thu, 7 May 2009 23:42:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so647390ana.13 for ; Thu, 07 May 2009 16:42: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=yj2fuPbua/S2RGdW4Y1A3z3glqqmO0OJVF6VaEeEmPo=; b=na2sJ2VQGqXRrOEITuduihMI2d0njqC+uqRAerz8PbfhKfAGHYFEkTCW1HtcMFmqE3 PT9ch5Whpntq+uYPqD8CMTWpWCWiny89HH1urBpD04VZIelIGYMxOfQwlGh7CTJhz10K 1141yWYLmdVVadCUgq1/9XrEQd+6+E1n0jMO8= 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=UjF3udhp8kYBMgywgYeOvItwiqKSna9ZjeHxrS6yuhtS5CDV5UBIYiehm3UXASvOkk 5aeMk1DxCnWP0RruX0LBdwoCslth1KXunUwq3ofTjn3vZP1hY0GRXRGv/1nQZ0Jjq3FC GNobhbKUBTBfmWVmhHl7s7KAAgzEfz29U2AhM= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.101.69.6 with SMTP id w6mr6969022ank.6.1241739773589; Thu, 07 May 2009 16:42:53 -0700 (PDT) In-Reply-To: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> References: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 16:42:53 -0700 X-Google-Sender-Auth: cd9259cb6903a42d Message-ID: <3c1674c90905071642g5aa13b69t8ba74ca53007bfc@mail.gmail.com> From: Kip Macy To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/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, 07 May 2009 23:42:54 -0000 Fixed, sorry. I didn't realize the user version of ZFS was being compiled. -Kip On Thu, May 7, 2009 at 4:14 PM, FreeBSD Tinderbox w= rote: > TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2009-05-07 22:20:00 - cleaning the object tree > TB --- 2009-05-07 22:21:25 - cvsupping the source tree > TB --- 2009-05-07 22:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -= s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-05-07 22:21:33 - building world > TB --- 2009-05-07 22:21:33 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-05-07 22:21:33 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-07 22:21:33 - TARGET=3Damd64 > TB --- 2009-05-07 22:21:33 - TARGET_ARCH=3Damd64 > TB --- 2009-05-07 22:21:33 - TZ=3DUTC > TB --- 2009-05-07 22:21:33 - __MAKE_CONF=3D/dev/null > TB --- 2009-05-07 22:21:33 - cd /src > TB --- 2009-05-07 22:21:33 - /usr/bin/make -B buildworld >>>> World build started on Thu May =A07 22:21:34 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 > [...] > cc -O2 -pipe =A0-DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../.= ./sys/cddl/compat/opensolaris =A0-I/src/cddl/usr.bin/sgsmsg/../../../cddl/c= ompat/opensolaris/include =A0-I/src/cddl/usr.bin/sgsmsg/../../../cddl/contr= ib/opensolaris/cmd/sgs/include =A0-I/src/cddl/usr.bin/sgsmsg/../../../sys/c= ddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -fst= ack-protector -Wno-unknown-pragmas =A0-o sgsmsg avl.o sgsmsg.o string_table= .o findprime.o > =3D=3D=3D> cddl/usr.bin/zinject (all) > cc -O2 -pipe =A0-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/open= solaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src= /cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.= bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin= /zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/= zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject= /../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bi= n/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/= usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cdd= l/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinjec= t/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -fstack-protector -= Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/= cmd/zinject/zinject.c > cc -O2 -pipe =A0-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/open= solaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src= /cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.= bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin= /zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/= zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject= /../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bi= n/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/= usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cdd= l/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinjec= t/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -fstack-protector -= Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/= cmd/zinject/translate.c > /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate= .c: In function 'translate_record': > /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate= .c:373: warning: passing argument 4 of 'calculate_range' discards qualifier= s from pointer target type > cc -O2 -pipe =A0-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/open= solaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src= /cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.= bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin= /zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/= zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject= /../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bi= n/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/= usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cdd= l/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinjec= t/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -fstack-protector -= Wno-unknown-pragmas =A0-o zinject zinject.o translate.o -lavl -lgeom -lm -l= nvpair -lumem -luutil -lzfs -lzpool > /obj/amd64/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_a= sync_fini' > *** Error code 1 > > Stop in /src/cddl/usr.bin/zinject. > *** Error code 1 > > Stop in /src/cddl/usr.bin. > *** Error code 1 > > Stop in /src/cddl. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-05-07 23:14:08 - WARNING: /usr/bin/make returned exit code = =A01 > TB --- 2009-05-07 23:14:08 - ERROR: failed to build world > TB --- 2009-05-07 23:14:08 - 2356.94 user 283.40 system 3248.40 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full > _______________________________________________ > 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 All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Thu May 7 23:54: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 31E93106564A; Thu, 7 May 2009 23:54:23 +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 E7DC18FC17; Thu, 7 May 2009 23:54:22 +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 n47NsKCP050789; Thu, 7 May 2009 19:54:20 -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 n47NsKFQ078127; Thu, 7 May 2009 19:54:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6CB2A7302F; Thu, 7 May 2009 19:54:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090507235420.6CB2A7302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 19:54:20 -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 i386/i386 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, 07 May 2009 23:54:23 -0000 TB --- 2009-05-07 23:03:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 23:03:31 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-07 23:03:31 - cleaning the object tree TB --- 2009-05-07 23:04:11 - cvsupping the source tree TB --- 2009-05-07 23:04:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-07 23:04:18 - building world TB --- 2009-05-07 23:04:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 23:04:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 23:04:18 - TARGET=i386 TB --- 2009-05-07 23:04:18 - TARGET_ARCH=i386 TB --- 2009-05-07 23:04:18 - TZ=UTC TB --- 2009-05-07 23:04:18 - __MAKE_CONF=/dev/null TB --- 2009-05-07 23:04:18 - cd /src TB --- 2009-05-07 23:04:18 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 23:04:20 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 [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:54:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:54:20 - ERROR: failed to build world TB --- 2009-05-07 23:54:20 - 2296.38 user 268.37 system 3049.07 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri May 8 00:05: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 DD9F81065672; Fri, 8 May 2009 00:05:38 +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 9DC598FC08; Fri, 8 May 2009 00:05:38 +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 n4805axW051369; Thu, 7 May 2009 20:05:36 -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 n4805ZTg050489; Thu, 7 May 2009 20:05:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C52817302F; Thu, 7 May 2009 20:05:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090508000535.C52817302F@freebsd-current.sentex.ca> Date: Thu, 7 May 2009 20:05:35 -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 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: Fri, 08 May 2009 00:05:39 -0000 TB --- 2009-05-07 23:14:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 23:14:09 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-07 23:14:09 - cleaning the object tree TB --- 2009-05-07 23:14:41 - cvsupping the source tree TB --- 2009-05-07 23:14:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-07 23:14:50 - building world TB --- 2009-05-07 23:14:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 23:14:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 23:14:50 - TARGET=pc98 TB --- 2009-05-07 23:14:50 - TARGET_ARCH=i386 TB --- 2009-05-07 23:14:50 - TZ=UTC TB --- 2009-05-07 23:14:50 - __MAKE_CONF=/dev/null TB --- 2009-05-07 23:14:50 - cd /src TB --- 2009-05-07 23:14:50 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 23:14:52 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 [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/pc98/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-08 00:05:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-08 00:05:35 - ERROR: failed to build world TB --- 2009-05-08 00:05:35 - 2292.02 user 280.10 system 3086.78 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri May 8 02:19: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 F4187106564A for ; Fri, 8 May 2009 02:19:41 +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 AE25D8FC0C for ; Fri, 8 May 2009 02:19:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so686426ywe.13 for ; Thu, 07 May 2009 19:19: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=cIapMll6SKrFtZQNF2yOHn6XWH76olK52KQjycsXFRs=; b=WNnJjsB8KxHCmAAAKjPdyuIsowunkJNfFhPtKgXtocj04C0LdQMPqnZn7f5UnhklxJ cfC9XibBMFNtGMTsSwoRdynTb44DKP7CXQFpMJEMO9Yd1kNMaBO5CrS9Elj8pDkZeOey TcJmoyZIXegT+tGvoKnSj63Fin5xkU9EKUu7A= 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=Xy1f+WZ2xuizYU5/CMhdPT0DOoZ8wtJDBhiro75Sw3d/tCABAMW1Cp+uNhFRgORcHW skfsQQJNM2ZRsOHdhrGckgZsjk/yrPw0/aKprqyDySOzw7VjDlvYUAkL4SKZRZSF1vs5 0kb9fdWyRxP4cFcAZN3t0MgjAq2ZFQ7S3+q7A= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.248.4 with SMTP id v4mr7231547anh.57.1241749180920; Thu, 07 May 2009 19:19:40 -0700 (PDT) In-Reply-To: <20090507210516.06331fb2@zelda.local> References: <20090507210516.06331fb2@zelda.local> Date: Thu, 7 May 2009 19:19:40 -0700 X-Google-Sender-Auth: 8fd51aed131761ec Message-ID: <3c1674c90905071919k55e1bf86yc64b54a10b142c8d@mail.gmail.com> From: Kip Macy To: Martin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS panic space_map.c line 110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 02:19:42 -0000 This panic indicates that the caller expected there to be free space between start and (start + size), but none was found. This could be a locking bug or a space map corruption (depressing). There really isn't enough context here for me to go on. If you can't get a core, please at least provide us with a backtrace from ddb. Thanks, Kip On Thu, May 7, 2009 at 12:05 PM, Martin wrote: > > Hi, > > I have a file server running ZFS on -CURRENT. Someone has tried to > transfer a file with several gigabytes onto the system. The kernel > crashed with a panic and freezed up during spewing the panic. I've only > written down the most important messages: > > solaris assert ss==NULL > zfs/space_map.c line 110 > > process: 160 spa_zio > > I've heard that I can try to move the zpool cache away and import the > zpool with force once again. Will this help? I am asking because I > don't know if the panic is caused by a corrupt cache or corrupt > file system metadata. Maybe someone can explain it. (I had to switch the > server off very ungently and the underlying RAID is rebuilding, so I > can try it out later.) > > Is this issue with inconsistent zpools well known? I've seen some posts > from 2007 and January 2009 that reported similar problems. Apparently > some people have lost their entire zpools multiple times already, as > far as I understood it. > > One more piece of information I can give is that every hour the ZFS file > systems create snapshots. Maybe it triggered some inconsistency between > the writes to a file system and the snapshot, I cannot tell, because I > don't understand the condition. > > -- > Martin > _______________________________________________ > 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" > -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Fri May 8 03:46: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 70F2B1065677 for ; Fri, 8 May 2009 03:46:10 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9EA8FC22 for ; Fri, 8 May 2009 03:46:09 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 63403CD4; Thu, 7 May 2009 23:46:09 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2GPl-0004YR-EM; Thu, 07 May 2009 22:06:21 -0500 To: freebsd-current@freebsd.org, Martin References: <20090507210516.06331fb2@zelda.local> From: Richard Todd Date: Thu, 07 May 2009 22:06:21 -0500 In-Reply-To: (Martin's message of "Thu, 7 May 2009 21:05:16 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: ZFS panic space_map.c line 110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 03:46:11 -0000 Martin writes: > Hi, > > I have a file server running ZFS on -CURRENT. Someone has tried to > transfer a file with several gigabytes onto the system. The kernel > crashed with a panic and freezed up during spewing the panic. I've only > written down the most important messages: > > solaris assert ss==NULL > zfs/space_map.c line 110 > > process: 160 spa_zio > > I've heard that I can try to move the zpool cache away and import the > zpool with force once again. Will this help? I kinda doubt it. > zpool with force once again. Will this help? I am asking because I > don't know if the panic is caused by a corrupt cache or corrupt > file system metadata. Maybe someone can explain it. (I had to switch the This panic wouldn't have anything to do with zpool.cache (that's just a file to help the system find which devices it should expect to find zpools on during boot). This is a problem with the free space map, which is part of the filesystem metadata. If you're lucky, it's just the in-core copy of the free space map that was bogus and there's a valid map on disk. If you're unlucky, the map on disk is trashed, and there's no really easy way to recover that pool. > Is this issue with inconsistent zpools well known? I've seen some posts > from 2007 and January 2009 that reported similar problems. Apparently > some people have lost their entire zpools multiple times already, as > far as I understood it. Mine was probably one of those messages; I managed to get an error like that once, through Seriously Provoking the system (repeatedly unmounting and mounting the main filesystem on one pool) while attempting to debug a different, unrelated problem. It's not something I've ever seen in any sort of "normal" usage, and just copying a few gig to the FS shouldn't cause this sort of problem. I managed to recover the data without having to resort to backups, by hacking the kernel to disable some of the asserts in space_map.c, iterating until I reached a point where I got a kernel that could import the pool without panicing. Once I did that I managed to mount the fs readonly and copy everything off to a different device. Like I said, not an *easy* way to recover that data. > One more piece of information I can give is that every hour the ZFS file > systems create snapshots. Maybe it triggered some inconsistency between > the writes to a file system and the snapshot, I cannot tell, because I > don't understand the condition. I doubt this had anything to do with the problem. From owner-freebsd-current@FreeBSD.ORG Fri May 8 03:50: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 CCAEF10656DB for ; Fri, 8 May 2009 03:50:57 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from mail.clearchain.com (leo.clearchain.com [199.73.29.74]) by mx1.freebsd.org (Postfix) with ESMTP id 711C98FC0A for ; Fri, 8 May 2009 03:50:57 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from [192.168.0.91] (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.14.3/8.14.3) with ESMTP id n483FLcl076239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 May 2009 12:45:24 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <4A03A3C9.3060503@clearchain.com> Date: Fri, 08 May 2009 12:45:21 +0930 From: Benjamin Close User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090505 Shredder/3.0b3pre MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.clearchain.com [199.73.29.74]); Fri, 08 May 2009 12:45:25 +0930 (CST) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: zfsboot, MBR/partition table based setup, zfs loader 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: Fri, 08 May 2009 03:50:58 -0000 Hi Folks, I've been trying to setup zfs on root without a ufs partition. Not using gpt but using a standard mbr/partition table. After digging through the code I found having it on a bsd slice (aka a,b,d,e,f etc) is impossible. Though having it on a partition should be possible. I've got most of the way but now have hit a point where there's something not quite working and I don't know how to debug it further. The setup is: amd64 ad4s1 - winxp ad4s2 - zpool:data I'm using the -current snapshot fixit cdrom from 200902 I've successfully installed boot1/2 using: # dd if=/mnt2/boot/zfsboot of=/dev/da0s1 count=1 # dd if=/mnt2/boot/zfsboot of=/dev/da0s1 skip=1 seek=1024 and created a pool using: # cd /mnt2/boot/kernel # kldload ./opensolaris.ko # kldload ./zfs.ko # zpool create data /dev/ad4s2 # cp -a /dist/boot /data/boot Most the setup is working. Boot2 is starting the loader but the loader is unable to see any zfs pools (even though it's built with LOADER_WITH_ZFS on another box). I've been trying to narrow down the issue with the loader. Turns out the loader gets the correct guid for the pool from boot2 but when loader reprobes the bios disks via: zfsimpl.c:837:zio_read_phy: rc=vdev->v_read(vdev,vdev->vread_priv, offset, buf,psize) zfsimpl.c:644:vdev_probe : zio_read_phys(&vtmp,&bp,vdev_label,off) zfs.c :438:zfs_dev_init: vdev_probe(vdev_read, (void *)(uintptr_t)fd, 0)) main.c :167:main : devsw[i]->dv_init() the resultant read succeeds but the following call to zio_checksum_error confirms the checksum is wrong. I've destroyed the pool and recreated it just incase the sum was wrong. However, I suspect the ldr is reading the wrong data from the disk. vdev->v_read is the function: vdev_read( vdev_t *vdev, void *priv, off_t offset, void *buf, size_t size), being called with: vdev_read( tempstruct built in vdev_probe, fd = 0 opened in vdev_probe for ad4s2, offset = 0x4000 from offsetof(vdev_label_t, vl_vdevphys) in vdev_probe, a buffer - vdev_label (which = zscratch), 113800 - sizeof(vdev_phys_t), via get/set BP_PSIZE in vdev_probe) The read is successful. What I question is the following: o Why do all devices return fd=0 on an open call, is this because it's loader code and there's no unique numbering? If so do offsets have to be applied for slices? Ie is it 0x4000 + some slice offset? o Does the read (based on asm in zfsldr.S) actually have valid data at offset 0x4000 - The comment in the file seems to indicate data is only valid above 0x8000 or am I mixing up memory/vs disk addressing? /* * Ok, we have a slice and drive in %dx now, so use that to locate and * load boot2. %si references the start of the slice we are looking * for, so go ahead and load up the 64 sectors starting at sector 1024 * (i.e. after the two vdev labels). We don't have do anything fancy * here to allow for an extra copy of boot1 and a partition table * (compare to this section of the UFS bootstrap) so we just load it * all at 0x8000. The first part of boot2 is BTX, which wants to run * at 0x9000. The boot2.bin binary starts right after the end of BTX, * so we have to figure out where the start of it is and then move the * binary to 0xc000. After we have moved the client, we relocate BTX * itself to 0x9000 - doing it in this order means that none of the * memcpy regions overlap which would corrupt the copy. Normally, BTX * clients start at MEM_USR, or 0xa000, but when we use btxld to * create boot2, we use an entry point of 0x2000. That entry point is * relative to MEM_USR; thus boot2.bin starts at 0xc000. Any help would be appreciated in getting this working as having FBSD boot off zfs natively is a huge win. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Fri May 8 03:59: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 0C9B11065691 for ; Fri, 8 May 2009 03:59:46 +0000 (UTC) (envelope-from kabaev@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 8AE9D8FC26 for ; Fri, 8 May 2009 03:59:45 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by fxm12 with SMTP id 12so1162242fxm.43 for ; Thu, 07 May 2009 20:59:44 -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=sQjB/ATkbIlsXrU8rl2JOR40eKdI7OB8omXN3Zh8K3g=; b=grUesg43sg1KZGpXF4Jgaj+F4fyz9dSHSTI2ZKF5glT78Le+qigfiWLMi3S5An8EjT zA+yRH68AJ1rQDfU6S5RFkMhx+H4mP1yEcDWxw3aWN6KDsTv+P2WvXr6s07Lkr7YCXu7 COsqMuP7zk22lSerg2nlU9fu1vaswJ5BP5NPk= 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=D3e73VK0enFvqa8EyM7rTNNGQuQ91F0bdqMRGdU6G6c0fRkqluoOnbysvtrugPW5DY 1Sn00xPlVALIVnmwOIqn4jaSGL2+zArhtAEB/B2/congcl0Fu9MS+svr2rWfYuERha38 QqT77wVTEfdJ+7OKNGeEj50Ja3765k9cBnQyQ= MIME-Version: 1.0 Received: by 10.86.90.2 with SMTP id n2mr3224138fgb.39.1241755184612; Thu, 07 May 2009 20:59:44 -0700 (PDT) In-Reply-To: <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> References: <20090506234631.231A5CD8@mx1.synetsystems.com> <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> Date: Thu, 7 May 2009 23:59:44 -0400 Message-ID: <8e5ef5f70905072059u51dcdbe8nd5b66f6fb5c124e4@mail.gmail.com> From: Alexander Kabaev To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Richard Todd , freebsd-current@freebsd.org Subject: Re: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's 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: Fri, 08 May 2009 03:59:47 -0000 > On May 6, 2009, at 6:54 PM, Richard Todd wrote: > It looks like this KASSERT was added relatively recently as part of the > dotdot changes to the namecache: > > =A0http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D190945 > > Perhaps there is further fallout from the changes that only occur with ZF= S? > > - Ben Up to recently dotdot caching in VFS was quite broken and did pay any attention to vnode types FSes did feed to it. >From backtrace and analysis provided by original poster it is evident that ZFS is trying to cache_enter(VDIR, "..", VLNK), which cannot possibly make any sense. kib@ has recently committed fixes to FFS to avoid races with vnodes being reused from under ffs_lookup, and I would not be surprised if ZFS was broken is similar fashion. --=20 Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Fri May 8 07:20: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 AD2971065676 for ; Fri, 8 May 2009 07:20:41 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 32FDC8FC0C for ; Fri, 8 May 2009 07:20:36 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate03.web.de (Postfix) with ESMTP id A25CCFC01913; Fri, 8 May 2009 09:20:34 +0200 (CEST) Received: from [217.236.36.151] (helo=zelda.local) by smtp07.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1M2KNm-0000No-00; Fri, 08 May 2009 09:20:34 +0200 Date: Fri, 8 May 2009 09:20:33 +0200 From: Martin To: Richard Todd Message-ID: <20090508092033.299daab6@zelda.local> In-Reply-To: References: <20090507210516.06331fb2@zelda.local> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+6hKKIFgFLtQ+uGU6ycE0ipPSjcA5LWaSDoqEm YQzkVpkhVyuKRV6gpUuacZTZ7mcGW4E7Qj2CrA8z3sfai2fEJ3 /lwZAkniA= Cc: freebsd-current@freebsd.org, Kip Macy Subject: Re: ZFS panic space_map.c line 110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 07:20:42 -0000 Hi Richard and Kip, @Richard: > This panic wouldn't have anything to do with zpool.cache (that's just > a file to help the system find which devices it should expect to find > zpools on during boot). This is a problem with the free space map, > which is part of the filesystem metadata. If you're lucky, it's just > the in-core copy of the free space map that was bogus and there's a > valid map on disk. If you're unlucky, the map on disk is trashed, > and there's no really easy way to recover that pool. I really cannot tell. I thought it would be nice to have ZFS for jail managements, so I can create one file system for one jail that's why I installed -CURRENT with version 13 of ZFS on a server in production. > > One more piece of information I can give is that every hour the ZFS > > file systems create snapshots. Maybe it triggered some > > inconsistency between the writes to a file system and the snapshot, > > I cannot tell, because I don't understand the condition. > > I doubt this had anything to do with the problem. Well, you said you provoked the panic by mounting and unmounting very often. The zfs-snapshot-mgmt port that I used shows similar behavior in certain situations. @Kip: > This could be a locking bug or a space map corruption (depressing). > There really isn't enough context here for me to go on. If you can't > get a core, please at least provide us with a backtrace from ddb. It does not look like a locking bug to me. I tried several times to get the pool running, also with an older kernel. It paniced in the same way. I could get past the panic the first time, when I removed zfs_enable="YES" from rc.conf. ZFS really made we worried and I removed the pools now, created UFS partition and restored all data from backup. Sorry, I did not investigate the problem deeper because I wanted to get the file server running and thought that the exact panic line number and mentioning the situation (during importing the pool) would be enough to make the problem clear. Nothing was lost, this ZFS data corruption just ended my ZFS experiment for now. I will use the good old UFS2 for now and check it at a later time again. Thanks to you both for your advice. -- Martin From owner-freebsd-current@FreeBSD.ORG Fri May 8 10:34: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 85CC0106566B; Fri, 8 May 2009 10:34:54 +0000 (UTC) (envelope-from onemda@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 7F48B8FC0C; Fri, 8 May 2009 10:34:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so1285555bwz.43 for ; Fri, 08 May 2009 03:34: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 :content-transfer-encoding; bh=p2cItQSo7NSeVItexvTC4atsaRofqEwF9mh9nWatND8=; b=KdBo0A80m64jlcGk70IH/13IzI12ys138mpqzwvvVsHxCGsxnOq8hMgUjD6Cr+KjZ3 kywEIm9Lt9dngtOh8ga5yxQXLl8Wl6P259L/dofE7ORFuhnvLqA/oMt0bv/PrdF802lc Wi8nuT7QT+UrSaTBTx2nJ5Y6I/xNsKgmJ6E8A= 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=Cn3iRY7MelgofEeezLYWo+6ckjLqPH15X0Us402zeC3yqlhRhi+SslGMTARtb8ARhC uRm9pxToIoqYOvVVXTlrNyzsJZvBH9yWc6mOcKfy6WaNDtWLb/Q9N8HfHSpKgHGW1tl4 +AUGmvNTr8eT6PQEtOGgu8Htz2FPB3jnIYiuA= MIME-Version: 1.0 Received: by 10.239.154.83 with SMTP id d19mr206468hbc.33.1241778892413; Fri, 08 May 2009 03:34:52 -0700 (PDT) In-Reply-To: <20090507.001059.-1558772981.imp@bsdimp.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> Date: Fri, 8 May 2009 10:34:52 +0000 Message-ID: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> From: "Paul B. Mahol" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 10:34:55 -0000 On 5/7/09, M. Warner Losh wrote: > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> > "Paul B. Mahol" writes: > : On 5/4/09, Alexander Motin wrote: > : > 2. PCI devices > : > PCI bus provides method to control device power. For example, I have > : > completely no use for my FireWire controller and most of time - EHCI USB > : > controller. Disabling them allows me to save about 3W of power. To > : > disable all unneeded PCI devices you should build kernel without their > : > drivers and add to loader.conf: > : > hw.pci.do_power_nodriver=3 > : > To enable devices back all you need to do is just load their drivers as > : > modules. > : > : Unloading modules doesnt put them back into into D3 state. > : You are forced to load some another module again to put wanted device > : into D3 state. > > It should. If it isn't, that's a bug. It's a bug. On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for all devices(including not attached ones). Unloading module/detaching device doesn't call pci_cfg_save. Should device_detach routine be used or new one like pci_driver_removed() implemented? -- Paul From owner-freebsd-current@FreeBSD.ORG Fri May 8 11:13: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 6A8BD1065673 for ; Fri, 8 May 2009 11:13:52 +0000 (UTC) (envelope-from pluknet@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 ECD188FC19 for ; Fri, 8 May 2009 11:13:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm12 with SMTP id 12so1332481fxm.43 for ; Fri, 08 May 2009 04:13:51 -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=hA6NsIZWjWw/p5IHPeB/vSVjo6OLtyAOWG/qTVexFOM=; b=h/uYOrHAcQbAIGq1p1U0c++7UF6286gt0PWCrowhbyLcpL+9ZIQTMAmN7nj0VRmvUW gvcnBVAvqxH+1X5xwuvciNd35uikQ4RUQ+mFlS90B0x8kI3/N4X/0Pw0ofYpEivo9ipr RgIg9GsJuiqm53r0auWnOsd1uSm3xBCQEeYy4= 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=F19jHcXF5Iy9h6mC/WvDjkiinQZ68kcLOQJnhFQG6dxitLGH8Y4BHPFp0J6F0Xm21R PsBl7pFRZJBrkYr8ww+GKRiVsMU2gHvFWQhKRmHRZRDraJbFF+dp3V+eRyS/egxECUP0 qWUU05Ft0xqGm3sMAAE1FGC93LOcjdVj+LBCM= MIME-Version: 1.0 Received: by 10.103.11.7 with SMTP id o7mr2252351mui.95.1241781231063; Fri, 08 May 2009 04:13:51 -0700 (PDT) In-Reply-To: <4A030BA1.8070709@samsco.org> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> <4A030ADB.9050802@keltia.freenix.fr> <4A030BA1.8070709@samsco.org> Date: Fri, 8 May 2009 04:13:51 -0700 Message-ID: From: pluknet To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 11:13:52 -0000 2009/5/7 Scott Long : > Ollivier Robert wrote: >> >> On 7/05/2009 10:17, Bob Bishop wrote: >>> >>> AFAICS the reference doesn't support that conclusion at all. >> >> Nehalem CPUs'HT feature is significantly different from the one present = in >> previous P4 CPUs. =A0Apparently, Nehalem's HT works. =A0Memory bandwidth= being >> much higher helps too. >> > > I keep here the anecdote that "it's better". =A0Is there a good reference > somewhere that describes exactly how it works? > > Scott Hi. There is a number of synthetic, low-level, and h/level application nehalem tests flowing around in Russian. Also, not far ago (31.12.2008 18:09) Intel has published the Intel Optimization Reference Manual for x32/64. (see ch. 8). It might be useful. http://download.intel.com/design/processor/manuals/248966.pdf. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri May 8 12:22: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 48D0F1065678 for ; Fri, 8 May 2009 12:22:20 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id E4ED58FC26 for ; Fri, 8 May 2009 12:22:19 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 42696 invoked by uid 60001); 8 May 2009 12:22:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241785339; bh=I+xIUPErpm3qKbTrFBBTe15XteUO1GP5yU+I9t5X4I8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kBWRjbNSSEEUtmm1mV0z2x0KwW/Le6qdp3lUZdhJHuWOK+RTdSNaoUztKhEhPzVKPz/yZlCbcBUrpScI6scBcYLewxeEdwLY7C29y+JHKeIsoDwuVKAlB+qaxDB8WsdRlTrdY5MLI2swD/ZTo63Ukb2qrPnwOId2e9B/O/OU/84= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L2qq40lNi6G+UuK7c57qfef90lW9LdLdomSzOEdfwzjovyL5Z7/bRIobCtpYGpvR++Flxg7PzRBWX2SB1/+8XykuuHeUX3uWn8+I+iafHKFkkDknqpJTWYuQN73+VyTn589CwTydM9BZzrA5p9h0Gnz5NK/mdu0ia6Wg1HG1PUM=; Message-ID: <484220.40675.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: RoKCaWMVM1lrEBkZANXzNMyxw5C4otY1KIPTderWySlZ0IAvISY5wBjYu5cH.b4gRINWWIpCh6f7V0kziPK7a8Y8lMctEL.8SCpyqTIJfNAlKccYijD_weeBsQdK2KO3IaCt9ScL9WPusTqFMRyGh6_hzTLw_Ve0lpoXuqijLdZu4YvRiKK6w1hhD3qNISc1FTHbMEyhUJT8TtILFjUwuddlEpK74FnyWpjxEoig4Dyp49gk5w1KlyvwP2im_nT5ZIu8E6tlzvkAG7A.nEYPNwToGy1ls0zIRBrxpWSkKULKqiUGGO3ZSGeRz0E- Received: from [98.242.223.106] by web63907.mail.re1.yahoo.com via HTTP; Fri, 08 May 2009 05:22:19 PDT X-Mailer: YahooMailWebService/0.7.289.10 Date: Fri, 8 May 2009 05:22:19 -0700 (PDT) From: Barney Cordoba To: Scott Long , pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: Hypertherading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 12:22:20 -0000 --- On Fri, 5/8/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Scott Long" > Cc: "Ollivier Robert" , freebsd-current@freebs= d.org > Date: Friday, May 8, 2009, 7:13 AM > 2009/5/7 Scott Long : > > Ollivier Robert wrote: > >> > >> On 7/05/2009 10:17, Bob Bishop wrote: > >>> > >>> AFAICS the reference doesn't support that > conclusion at all. > >> > >> Nehalem CPUs'HT feature is significantly > different from the one present in > >> previous P4 CPUs. =A0Apparently, Nehalem's HT > works. =A0Memory bandwidth being > >> much higher helps too. > >> > > > > I keep here the anecdote that "it's > better". =A0Is there a good reference > > somewhere that describes exactly how it works? > > > > Scott >=20 > Hi. >=20 > There is a number of synthetic, low-level, and h/level > application > nehalem tests flowing around in Russian. > Also, not far ago (31.12.2008 18:09) Intel has published > the Intel > Optimization Reference Manual for x32/64. > (see ch. 8). It might be useful. > http://download.intel.com/design/processor/manuals/248966.pdf. >=20 Ah, Intel says that its higher priced processors are better than their lower priced processors. There's evidence you can take to the bank. Barney=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Fri May 8 13:10: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 0A3D01065673; Fri, 8 May 2009 13:10:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BBFEA8FC12; Fri, 8 May 2009 13:10:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n48D70nR089707; Fri, 8 May 2009 07:07:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 08 May 2009 07:06:59 -0600 (MDT) Message-Id: <20090508.070659.1622573996.imp@bsdimp.com> To: onemda@gmail.com From: "M. Warner Losh" In-Reply-To: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> References: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 13:10:39 -0000 In message: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> "Paul B. Mahol" writes: : On 5/7/09, M. Warner Losh wrote: : > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> : > "Paul B. Mahol" writes: : > : On 5/4/09, Alexander Motin wrote: : > : > 2. PCI devices : > : > PCI bus provides method to control device power. For example, I have : > : > completely no use for my FireWire controller and most of time - EHCI USB : > : > controller. Disabling them allows me to save about 3W of power. To : > : > disable all unneeded PCI devices you should build kernel without their : > : > drivers and add to loader.conf: : > : > hw.pci.do_power_nodriver=3 : > : > To enable devices back all you need to do is just load their drivers as : > : > modules. : > : : > : Unloading modules doesnt put them back into into D3 state. : > : You are forced to load some another module again to put wanted device : > : into D3 state. : > : > It should. If it isn't, that's a bug. : : It's a bug. : : On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for : all devices(including not attached ones). : Unloading module/detaching device doesn't call pci_cfg_save. : : Should device_detach routine be used or new one like : pci_driver_removed() implemented? No. device_detach shouldn't be used for this. This should happen all in the PCI bus code when do_power_nodriver is > 0. Warner From owner-freebsd-current@FreeBSD.ORG Fri May 8 13:49: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 A560A106564A for ; Fri, 8 May 2009 13:49:43 +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 CF3BB8FC14 for ; Fri, 8 May 2009 13:49:42 +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 QAA20514; Fri, 08 May 2009 16:49:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A04386B.5050201@icyb.net.ua> Date: Fri, 08 May 2009 16:49:31 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Benjamin Close References: <4A03A3C9.3060503@clearchain.com> In-Reply-To: <4A03A3C9.3060503@clearchain.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: zfsboot, MBR/partition table based setup, zfs loader 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: Fri, 08 May 2009 13:49:43 -0000 on 08/05/2009 06:15 Benjamin Close said the following: > Hi Folks, > I've been trying to setup zfs on root without a ufs partition. Not > using gpt but using a standard mbr/partition table. > After digging through the code I found having it on a bsd slice (aka > a,b,d,e,f etc) is impossible. Though having it on a partition should be > possible. No real help here, but I think you mixed the terms. ad0s1 is a slice, as0s1a is a partition. This is in (Free)BSD conventional terms. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 8 14:17: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 BCDB7106564A for ; Fri, 8 May 2009 14:17:58 +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 6A15D8FC08 for ; Fri, 8 May 2009 14:17:58 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from rebelion.Sisis.de (cazador.sisis.de [193.31.11.193]) by dd12710.kasserver.com (Postfix) with ESMTP id CCCB018516EC9; Fri, 8 May 2009 16:17:59 +0200 (CEST) Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n48EHt6u013667; Fri, 8 May 2009 16:17:55 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 8 May 2009 16:17:55 +0200 From: Matthias Apitz To: freebsd-mobile@freebsd.org Message-ID: <20090508141755.GB13584@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090428083627.GA3621@rebelion.Sisis.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) Cc: freebsd-current@freebsd.org Subject: Re: laptop Dell M4400 with -CURRENT? 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, 08 May 2009 14:17:59 -0000 El día Tuesday, April 28, 2009 a las 10:36:27AM +0200, Matthias Apitz escribió: > > Hello, > > I'm planning to order a new laptop and got an offer for a Dell M4400 > with the following main details: > > Precision M4400 : Intel Core 2 Extreme X9100 (3.06GHz,1066MHz,6MB) > Base Option : 512MB Discrete nVidia FX770M Graphics Card (with 512MB dedicated memory) > Palmrest : UPEK Swipe Fingerprint Reader Biometric > Display : 15.4in Widescreen WUXGA (1920X1200) with Dual CCFL > Camera : Integrated 0.3 Mega Pixel Camera with Microphone for 2CCFL LCD Panel > LCD Back Cover : 2CCFL > Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel > disk : 250GB Serial ATA (7200 1/min) Festplatte (Free-Fall-Sensor) > Optical Drive : Roxio Creator 9.0 Software and Media Included > Optisches Laufwerk : 8x DVD+/-RW Laufwerk ohne Software > Battery : Primary 9-cell 85 W/HR LI-ION 451-10589 > Battery : Additional 6-Cell 56 W/HR LI-ION 451-10590 > Wireless : EMEA Dell Wireless 1510 (802.11a/b/g/n 2X3) MiniCard for Core 2 Extreme ONLY > Wireless : EMEA Dell Wireless 370 Bluetooth 2.1 MiniCard > Keyboard : Internal German Qwertz Keyboard I have now installed CURRENT in that Precision M4400; shrinked the Vista partition to 50 GByte and installed in the remaining 170 GByte FreeBSD CURRENT from a prepared USB key. It seems that the Quadro FX 770M Graphics Card is not supported by the NVIDIA driver in Xorg 1.6. -- any idea how to solve 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 8 15: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 44C21106568E for ; Fri, 8 May 2009 15:28:39 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 026C88FC1A for ; Fri, 8 May 2009 15:28:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-154-182-184.bna.bellsouth.net [68.154.182.184]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n48FSXLi091668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 11:28:33 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matthias Apitz In-Reply-To: <20090508141755.GB13584@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> <20090508141755.GB13584@rebelion.Sisis.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-/MGbhDqCNVtlOmgASu1X" Organization: FreeBSD Date: Fri, 08 May 2009 10:28:09 -0500 Message-Id: <1241796489.1733.25.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: laptop Dell M4400 with -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: Fri, 08 May 2009 15:28:39 -0000 --=-/MGbhDqCNVtlOmgASu1X Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Fri, 2009-05-08 at 16:17 +0200, Matthias Apitz wrote: > El d=EDa Tuesday, April 28, 2009 a las 10:36:27AM +0200, Matthias Apitz e= scribi=F3: >=20 > >=20 > > Hello, > >=20 > > I'm planning to order a new laptop and got an offer for a Dell M4400 > > with the following main details: > >=20 > > Precision M4400 : Intel Core 2 Extreme X9100 (3.06GHz,1066MHz,6MB) > > Base Option : 512MB Discrete nVidia FX770M Graphics Card (with 512MB= dedicated memory) > > Palmrest : UPEK Swipe Fingerprint Reader Biometric > > Display : 15.4in Widescreen WUXGA (1920X1200) with Dual CCFL > > Camera : Integrated 0.3 Mega Pixel Camera with Microphone for 2CCFL = LCD Panel > > LCD Back Cover : 2CCFL > > Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel > > disk : 250GB Serial ATA (7200 1/min) Festplatte (Free-Fall-Sensor) > > Optical Drive : Roxio Creator 9.0 Software and Media Included > > Optisches Laufwerk : 8x DVD+/-RW Laufwerk ohne Software > > Battery : Primary 9-cell 85 W/HR LI-ION 451-10589 > > Battery : Additional 6-Cell 56 W/HR LI-ION 451-10590 > > Wireless : EMEA Dell Wireless 1510 (802.11a/b/g/n 2X3) MiniCard for = Core 2 Extreme ONLY > > Wireless : EMEA Dell Wireless 370 Bluetooth 2.1 MiniCard=20 > > Keyboard : Internal German Qwertz Keyboard >=20 > I have now installed CURRENT in that Precision M4400; shrinked the Vista > partition to 50 GByte and installed in the remaining 170 GByte FreeBSD > CURRENT from a prepared USB key. >=20 > It seems that the Quadro FX 770M Graphics Card is not supported by the > NVIDIA driver in Xorg 1.6. -- any idea how to solve this? I have ported the nouveau drm driver. http://people.freebsd.org/~rnoland/drm-nouveau-043009.patch It is working on NV50 cards, NV40 was working, but with WITNESS enabled I seem to be getting a panic on NV40. My NV40 card seems to be having memory issues so I haven't been able to get and/or see the backtrace. I think it is just a locking issue which should be pretty easily solved if I can get a clear backtrace. You will need current libdrm and xf86-video-nouveau from ports. This won't get you 3d right now, but should get you EXA + Xv. robert. > Thx in advance >=20 > matthias --=20 Robert Noland FreeBSD --=-/MGbhDqCNVtlOmgASu1X 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) iEYEABECAAYFAkoET4kACgkQM4TrQ4qfROPexACcC3rFSNW0pw/X5whWgraMrvDA wXwAoIoR20hoaepPUyUzFUfwEUDZ82PJ =tHbM -----END PGP SIGNATURE----- --=-/MGbhDqCNVtlOmgASu1X-- From owner-freebsd-current@FreeBSD.ORG Fri May 8 22:04: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 1B270106566C for ; Fri, 8 May 2009 22:04:29 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id C42528FC0A for ; Fri, 8 May 2009 22:04:28 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so992979ywe.13 for ; Fri, 08 May 2009 15:04:28 -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; bh=gMQadjz5B9tUiSGOOqfpU9Pvuxx90WT+QbA3/yyAPQc=; b=Lr1CR2yZRJc7xQYzkypbocbNjcuEjfdfubKKEDvK/ShJAyv+1WZhXzeUxK+Q7tuuND RBXLock8IBB3MvOSiv+dmCCSp4mRvWPuqMt9QC2AnOpLXI1yqxgt0gam4+1WBKWxkRTI 2KdANcJOymqNl3FRvHxrYiq7IqsK6QYKjpWws= 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; b=M6Zf8lI8PsLqX3sxTKYVN6W3vZQIhet5mYEUxTf8uBOpHQ5aPGQienCyp3n1tXY1hP /D7GLCdkfONGGVUfOn+jzlxXyCJAhptJaX2tXjAX60JxoiL4yHSkRi5GB747yQW9OLx9 g76vLZQBLMFbCfkwf+xImam0+Y4LQ/IG0XUzY= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.100.126.19 with SMTP id y19mr9189250anc.100.1241820266954; Fri, 08 May 2009 15:04:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 May 2009 15:04:26 -0700 X-Google-Sender-Auth: ac9d7f2a58aeebd1 Message-ID: From: Artem Belevich To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=0016e644d02ce38b2404696dcf46 Subject: [patch] zfs.ko loading failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 22:04:29 -0000 --0016e644d02ce38b2404696dcf46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, After recent changes (r191915) opensolaris.ko refers to utsname variable that's actually compiled into zfs.ko zfs.ko itself requires symbols from opensolaris.ko and this circular dependency leads to failure to load zfs.ko. Attached patch moves opensolaris_misc.c to modules/opensolaris and fixes the issue --Artem --0016e644d02ce38b2404696dcf46 Content-Type: application/octet-stream; name="zfs-utsname.diff" Content-Disposition: attachment; filename="zfs-utsname.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fuhfp3gt0 ZGlmZiAtciBmYWU5NDg5NWNjNjcgc3lzL21vZHVsZXMvb3BlbnNvbGFyaXMvTWFrZWZpbGUKLS0t IGEvc3lzL21vZHVsZXMvb3BlbnNvbGFyaXMvTWFrZWZpbGUJRnJpIE1heSAwOCAxMjoyMjoxMCAy MDA5IC0wNzAwCisrKyBiL3N5cy9tb2R1bGVzL29wZW5zb2xhcmlzL01ha2VmaWxlCUZyaSBNYXkg MDggMTU6MDM6MzcgMjAwOSAtMDcwMApAQCAtMSwxNSArMSwxNiBAQAogIyAkRnJlZUJTRDogaGVh ZC9zeXMvbW9kdWxlcy9vcGVuc29sYXJpcy9NYWtlZmlsZSAxOTAzNzQgMjAwOS0wMy0yNCAxNTo0 ODozNVogbWFyaXVzICQKIAogLlBBVEg6ICR7LkNVUkRJUn0vLi4vLi4vY2RkbC9jb21wYXQvb3Bl bnNvbGFyaXMva2VybgogCiBLTU9EPQkJb3BlbnNvbGFyaXMKIFNSQ1M9CQlvcGVuc29sYXJpcy5j CQlcCiAJCW9wZW5zb2xhcmlzX2Ntbl9lcnIuYwlcCisgICAgICAgICAJb3BlbnNvbGFyaXNfbWlz Yy5jICAgICAgXAogCQlvcGVuc29sYXJpc19rbWVtLmMKIAogLmlmICR7TUFDSElORV9BUkNIfSA9 PSAiaTM4NiIgfHwgJHtNQUNISU5FX0FSQ0h9ID09ICJhbWQ2NCIgfHwgJHtNQUNISU5FX0FSQ0h9 ID09ICJpYTY0IiB8fCAke01BQ0hJTkVfQVJDSH0gPT0gInNwYXJjNjQiCiAuUEFUSDoJJHsuQ1VS RElSfS8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2F0b21pYy8ke01BQ0hJ TkVfQVJDSH0KIFNSQ1MrPQkJYXRvbWljLlMKIC5lbHNlCiBTUkNTKz0JCW9wZW5zb2xhcmlzX2F0 b21pYy5jCiAuZW5kaWYKZGlmZiAtciBmYWU5NDg5NWNjNjcgc3lzL21vZHVsZXMvemZzL01ha2Vm aWxlCi0tLSBhL3N5cy9tb2R1bGVzL3pmcy9NYWtlZmlsZQlGcmkgTWF5IDA4IDEyOjIyOjEwIDIw MDkgLTA3MDAKKysrIGIvc3lzL21vZHVsZXMvemZzL01ha2VmaWxlCUZyaSBNYXkgMDggMTU6MDM6 MzcgMjAwOSAtMDcwMApAQCAtMTUsMTcgKzE1LDE2IEBAIFNSQ1MrPQludnBhaXIuYwogLlBBVEg6 CSR7LkNVUkRJUn0vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NvbW1vbi91bmljb2Rl CiBTUkNTKz0JdThfdGV4dHByZXAuYwogCiAuUEFUSDoJJHsuQ1VSRElSfS8uLi8uLi9jZGRsL2Nv bXBhdC9vcGVuc29sYXJpcy9rZXJuCiBTUkNTKz0Jb3BlbnNvbGFyaXNfa21lbS5jCiBTUkNTKz0J b3BlbnNvbGFyaXNfa29iai5jCiBTUkNTKz0Jb3BlbnNvbGFyaXNfa3N0YXQuYwogU1JDUys9CW9w ZW5zb2xhcmlzX2xvb2t1cC5jCi1TUkNTKz0Jb3BlbnNvbGFyaXNfbWlzYy5jCiBTUkNTKz0Jb3Bl bnNvbGFyaXNfcG9saWN5LmMKIFNSQ1MrPQlvcGVuc29sYXJpc19zdHJpbmcuYwogU1JDUys9CW9w ZW5zb2xhcmlzX3Zmcy5jCiBTUkNTKz0Jb3BlbnNvbGFyaXNfem9uZS5jCiAKIC5pZiAke01BQ0hJ TkVfQVJDSH0gPT0gImkzODYiIHx8ICR7TUFDSElORV9BUkNIfSA9PSAiYW1kNjQiIHx8ICR7TUFD SElORV9BUkNIfSA9PSAiaWE2NCIgfHwgJHtNQUNISU5FX0FSQ0h9ID09ICJzcGFyYzY0IgogLlBB VEg6CSR7U1VOV30vY29tbW9uL2F0b21pYy8ke01BQ0hJTkVfQVJDSH0KIFNSQ1MrPQlhdG9taWMu Uwo= --0016e644d02ce38b2404696dcf46-- From owner-freebsd-current@FreeBSD.ORG Fri May 8 22:01: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 C0929106566B for ; Fri, 8 May 2009 22:01:16 +0000 (UTC) (envelope-from artemb@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 7DDA78FC1B for ; Fri, 8 May 2009 22:01:16 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so992041ywe.13 for ; Fri, 08 May 2009 15:01:16 -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=FTknzAL2wk3CpKSXu7qu0sWY7cxfRTz4fZ3f06Y6j7s=; b=gdbmHuyCAkGwb1Abmav4oCO63+uvPP20nSpHBQRIxkL0QkJZvcPnmLe1MNqrDfqaKp m0cUu0k3DRWF8WPgi9WZ5NkDB/eQSiQYS8WvfC9a++85iCK7uU3JRnNyRlqQYGuSHxtR IrafVOZ2Ds36cdl9ajyDSeW/b6op7fc2qqu2Q= 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=BAZInhAGwkJjquqtgravu22d4kTUcptqSc94mB72YTRwA2ZcqlWiw/Br95D0GgPEP4 hSKwD7CdgsY0FOQEKae+s+euW6uqZhewdDuS7uMOygEzodbT3dEz4fwyw/tUbZ8YlMP4 q0MzGzxc2GsQoyM040kNSKn9hHq7KcIChBHo8= MIME-Version: 1.0 Received: by 10.100.215.13 with SMTP id n13mr1754910ang.88.1241820075876; Fri, 08 May 2009 15:01:15 -0700 (PDT) Date: Fri, 8 May 2009 15:01:15 -0700 Message-ID: From: Artem Belevich To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 May 2009 22:04:36 +0000 Subject: [patch] zfs.ko loading failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 May 2009 22:01:17 -0000 Hi, After recent changes (r191915) opensolaris.ko refers to utsname variable that's actually compiled into zfs.ko In turn zfs.ko requires symbols from opensolaris.ko and this circular dependency leads to failure to load zfs.ko. Following patch moves opensolaris_misc.c to modules/opensolaris and fixes the issue --Artem diff -r fae94895cc67 sys/modules/opensolaris/Makefile --- a/sys/modules/opensolaris/Makefile Fri May 08 12:22:10 2009 -0700 +++ b/sys/modules/opensolaris/Makefile Fri May 08 14:59:51 2009 -0700 @@ -1,15 +1,16 @@ # $FreeBSD: head/sys/modules/opensolaris/Makefile 190374 2009-03-24 15:48:35Z marius $ .PATH: ${.CURDIR}/../../cddl/compat/opensolaris/kern KMOD= opensolaris SRCS= opensolaris.c \ opensolaris_cmn_err.c \ + opensolaris_misc.c \ opensolaris_kmem.c .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" .PATH: ${.CURDIR}/../../cddl/contrib/opensolaris/common/atomic/${MACHINE_ARCH} SRCS+= atomic.S .else SRCS+= opensolaris_atomic.c .endif diff -r fae94895cc67 sys/modules/zfs/Makefile --- a/sys/modules/zfs/Makefile Fri May 08 12:22:10 2009 -0700 +++ b/sys/modules/zfs/Makefile Fri May 08 14:59:51 2009 -0700 @@ -15,17 +15,16 @@ SRCS+= nvpair.c .PATH: ${.CURDIR}/../../cddl/contrib/opensolaris/common/unicode SRCS+= u8_textprep.c .PATH: ${.CURDIR}/../../cddl/compat/opensolaris/kern SRCS+= opensolaris_kmem.c SRCS+= opensolaris_kobj.c SRCS+= opensolaris_kstat.c SRCS+= opensolaris_lookup.c -SRCS+= opensolaris_misc.c SRCS+= opensolaris_policy.c SRCS+= opensolaris_string.c SRCS+= opensolaris_vfs.c SRCS+= opensolaris_zone.c .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" .PATH: ${SUNW}/common/atomic/${MACHINE_ARCH} SRCS+= atomic.S From owner-freebsd-current@FreeBSD.ORG Sat May 9 01:03: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 028F2106566C for ; Sat, 9 May 2009 01:03:35 +0000 (UTC) (envelope-from m.e.sanliturk@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 7275C8FC08 for ; Sat, 9 May 2009 01:03:34 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by fxm12 with SMTP id 12so1681523fxm.43 for ; Fri, 08 May 2009 18:03:33 -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; bh=YR97n+EgU/9aNiCjgR8MCUkLHkf2qzPyPeeurNzizlE=; b=jE0kooe812/kF6xWYGxjFK519MVUYk6wTgzDYys+FXBbmE/G6kMjzXRSxxzN4khmHh 3oIWjXGXGds6yBLaNC+hJqterep/qTf+OrmQiLcUpuSOnkrs5ulQUulAU7TcRceeEJqa qkrYcO+unn43k7WvO961QCKqw/oun/F2DFnNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=npXOY9/Bcln2IjnFfX6owQvBGkeWB5sbSZ4VvJ0ztWIdpYjvORj+l6VErfWXs9UH/m jySYNaZcxrCjwWZ5svMdCslDKIzCaoLd0nSpXnrcVSKZagBMiWng1paG+mWR/4+gFVQW c+Te4zv34MGIn6ko5iqEAbE3fYRnugzWLar9w= MIME-Version: 1.0 Received: by 10.204.120.3 with SMTP id b3mr4156804bkr.58.1241831012642; Fri, 08 May 2009 18:03:32 -0700 (PDT) Date: Fri, 8 May 2009 21:03:32 -0400 Message-ID: From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 May 2009 01:03:35 -0000 Dear All , A few days ago I have downloaded and installed 8.-Current-2009-05-amd64-dvd on an Intel DG965WHMKR main board with 2 GB RAM and 250 GB SATA II hard disk , PS/2 mouse and key board . Installation has been completed successfully and the PC booted well . (1) I tried to use X but X was completely missing . (2) Trying to add X with pkg_add did not worked because it could not find it in FreeBSD repositories . (3) I did not understand what can I do with that release sufficiently well , because I could not find a ReadMe about What to Do with this snapshot ( Perhaps there is one within installed OS but there is no any reminder about it with respect to my knowledge ( I could not check it now because I have installed another OS on its hard disk . ) . My ideas are following : (i) A ReadMe file set like supplied by releases would be very useful . Assume that these will be drafts of the release 8.0 . People will be able to work and make comments on them . A ReadMe about how to use and test the snapshot and supply feedback about its usage ( I think general bug reports are not very suitable for current development activities ) . (ii) Up to now I did not see any test program which can be applied by the installers and then send results back to FreeBSD release and current developers . Such a program would test an overall structure of the installed components and would sent a report to FreeBSD current developers . (iii) Some Linux distributions are collecting computer profile data for successful installations , for example , Fedora is collecting profile information and summaries are published in www.smolts.org . FreeBSD installations may include a similarly profile collection step . I do not know the relationship between www.bsdstats.org and www.freebsd.org, but a detailed hardware profile list such as the following sample pages would be very useful : http://hcl.mandriva.com/ http://en.opensuse.org/Hardware http://wiki.freespire.org/index.php/Hardware_Compatibility_List http://www.ubuntuhcl.org/ http://www.turbolinux.com/products/compatibility/index.html https://hardware.redhat.com/ http://www.smolts.org/ http://www.armorlogic.com/openbsd_information_server_compatibility_list.html http://www.sun.com/bigadmin/hcl/ How to Certify hardware : http://www.sun.com/bigadmin/hcl/hcts/ Submit Hardware to the Solaris HCL : http://www.sun.com/bigadmin/hcl/submittal/submit.jsp http://www.microsoft.com/whdc/hcl/default.mspx Some others : http://www.networkupstools.org/compat/stable.html ( UPS ) http://hcl.xensource.com/ ( Xen Server ) http://wiki.xensource.com/xenwiki/HardwareCompatibilityList (iv) A structured form in a page in FreeBSD web site to collect information about failed installations and their hardware profiles ( because failed installation can not send any profile mail ) . (v) Handbook is only showing last active releases , the others are replaced by latest release related handbook . For users it is no more possible to access removed handbooks . It is possible to use a structure like following : ... Handbook 6.4 ... Handbook 7.0 Handbook 7.1 Handbook 7.2 ... Handbook 8.0 During current development phase it is possible also to get proposals about current Handbook and it may be possible to synchronize it with current OS . In that way , it becomes possible to ( NOT to revise release Handbook for the active releases ) . Each Handbook develops in its own course . Previous Handbooks will not be lost due to new releases . Current Handbook will be initialized by copying a previous Handbook and then will be modified with respect to developed current . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sat May 9 02:28: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 E99111065673 for ; Sat, 9 May 2009 02:28:23 +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 BD69B8FC12 for ; Sat, 9 May 2009 02:28:23 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n492SMfq025543; Fri, 8 May 2009 19:28:22 -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 vj3jxn68dbzmscx8g7mc8cmjes; Fri, 08 May 2009 19:28:22 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A04EA46.20106@freebsd.org> Date: Fri, 08 May 2009 19:28:22 -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: Mehmet Erol Sanliturk References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Installation of FreeBSD 8.0-Current-2009-amd64-dvd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 May 2009 02:28:24 -0000 Mehmet Erol Sanliturk wrote: > > A few days ago I have downloaded and installed 8.-Current-2009-05-amd64-dvd > on ... > > (1) I tried to use X but X was completely missing . > (2) Trying to add X with pkg_add did not worked... > (3) I did not understand what can I do with that release... FreeBSD-CURRENT is for people who are helping to develop FreeBSD itself. In order to use -CURRENT, you need to be able to build software without using packages. Because -CURRENT is in development, pre-built packages are not available (they would break very quickly as the system changes). Remember that X is just another set of packages. You can build and install X from ports: $ cd /usr/ports/x11-servers/xorg-server $ make $ make install Is there a particular reason you wanted to run FreeBSD-CURRENT? It sounds like you might be happier using the latest -STABLE release, which is FreeBSD 7.2. Cheers, Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Sat May 9 03:36:08 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 F3C35106566C; Sat, 9 May 2009 03:36:07 +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 B08778FC14; Sat, 9 May 2009 03:36:07 +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 n493a52F005258; Fri, 8 May 2009 23:36:05 -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 n493a5eb051369; Fri, 8 May 2009 23:36:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 23A347302F; Fri, 8 May 2009 23:36:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090509033605.23A347302F@freebsd-current.sentex.ca> Date: Fri, 8 May 2009 23:36:05 -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 i386/i386 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: Sat, 09 May 2009 03:36:08 -0000 TB --- 2009-05-09 03:07:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 03:07:29 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-09 03:07:29 - cleaning the object tree TB --- 2009-05-09 03:08:05 - cvsupping the source tree TB --- 2009-05-09 03:08:05 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-09 03:08:19 - building world TB --- 2009-05-09 03:08:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 03:08:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 03:08:19 - TARGET=i386 TB --- 2009-05-09 03:08:19 - TARGET_ARCH=i386 TB --- 2009-05-09 03:08:19 - TZ=UTC TB --- 2009-05-09 03:08:19 - __MAKE_CONF=/dev/null TB --- 2009-05-09 03:08:19 - cd /src TB --- 2009-05-09 03:08:19 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 03:08:21 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 [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 03:36:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 03:36:04 - ERROR: failed to build world TB --- 2009-05-09 03:36:04 - 1316.71 user 145.48 system 1715.12 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat May 9 03:39: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 E4358106564A for ; Sat, 9 May 2009 03:39:58 +0000 (UTC) (envelope-from m.e.sanliturk@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 401AE8FC0C for ; Sat, 9 May 2009 03:39:57 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by fxm12 with SMTP id 12so1708205fxm.43 for ; Fri, 08 May 2009 20:39:57 -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=R6tqJDhzOCxMnauRDD36x+kXxsjncuxEjnzHJxaM8xg=; b=tmgeAg/M3ak6lgb3ZqtGSQ2VWZNhlG40H09U8fK8deZVKOfSA61EUAKzxiKDWxlBf9 Tlm5Xpj1spONWTtbTrZ3R7rer7leNt36RSSo/BhGvQ2YJ32qWSVVY1cTo833ii0Xo4I7 fML7Zz61cDyaSVlxyF56sZeZmIH5TiCciJDr8= 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=md9tt2fePuwEn0ClhywzbgUAIrs3WYPrndreM4mUeAL4Zs+zVSrv+GveGlB3HdTZTb Hf9BD+n+Lc8o40EL5/uaUvU1WaeGhAQdj73/NaA6FiJbzx+FRd7pvhtCKCWLHptTzqaV ZN782Q3Der3Hf5PMjcqBlCBSUdWxsrZ8APN24= MIME-Version: 1.0 Received: by 10.204.72.15 with SMTP id k15mr4293277bkj.14.1241840397154; Fri, 08 May 2009 20:39:57 -0700 (PDT) In-Reply-To: <4A04EA46.20106@freebsd.org> References: <4A04EA46.20106@freebsd.org> Date: Fri, 8 May 2009 23:39:57 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: Installation of FreeBSD 8.0-Current-2009-amd64-dvd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 May 2009 03:39:59 -0000 On Fri, May 8, 2009 at 10:28 PM, Tim Kientzle wrote: > Mehmet Erol Sanliturk wrote: > >> >> A few days ago I have downloaded and installed >> 8.-Current-2009-05-amd64-dvd >> on ... >> >> (1) I tried to use X but X was completely missing . >> (2) Trying to add X with pkg_add did not worked... >> (3) I did not understand what can I do with that release... >> > > FreeBSD-CURRENT is for people who are helping to develop > FreeBSD itself. In order to use -CURRENT, you > need to be able to build software without using > packages. Because -CURRENT is in development, > pre-built packages are not available (they would break > very quickly as the system changes). Remember > that X is just another set of packages. > > You can build and install X from ports: > $ cd /usr/ports/x11-servers/xorg-server > $ make > $ make install > > Is there a particular reason you wanted to run > FreeBSD-CURRENT? It sounds like you might be > happier using the latest -STABLE release, which > is FreeBSD 7.2. > > Cheers, > > Tim Kientzle > > Dear Tim , I know that current snapshots should not be used in any production purposes . My intention was only to install it , run some programs , and if I get a feeling that supplying an information to current developers may be useful to send an e-mail about my experiences . I think such installation and test results would be useful to current developers if I am not wrongly assumed that . Thank you very much . Mehmet eErol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sat May 9 04:04:49 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 7B860106566B; Sat, 9 May 2009 04:04:49 +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 3CB078FC0A; Sat, 9 May 2009 04:04:49 +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 n4944ker006284; Sat, 9 May 2009 00:04:46 -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 n4944kYK099965; Sat, 9 May 2009 00:04:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3E86F7302F; Sat, 9 May 2009 00:04:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090509040446.3E86F7302F@freebsd-current.sentex.ca> Date: Sat, 9 May 2009 00:04:46 -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: Sat, 09 May 2009 04:04:50 -0000 TB --- 2009-05-09 03:36:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 03:36:05 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-09 03:36:05 - cleaning the object tree TB --- 2009-05-09 03:36:35 - cvsupping the source tree TB --- 2009-05-09 03:36:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-09 03:36:44 - building world TB --- 2009-05-09 03:36:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 03:36:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 03:36:44 - TARGET=pc98 TB --- 2009-05-09 03:36:44 - TARGET_ARCH=i386 TB --- 2009-05-09 03:36:44 - TZ=UTC TB --- 2009-05-09 03:36:44 - __MAKE_CONF=/dev/null TB --- 2009-05-09 03:36:44 - cd /src TB --- 2009-05-09 03:36:44 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 03:36:46 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 [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/pc98/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 04:04:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 04:04:46 - ERROR: failed to build world TB --- 2009-05-09 04:04:46 - 1315.56 user 150.86 system 1720.84 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat May 9 04:36: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 EB5D2106564A; Sat, 9 May 2009 04:36:51 +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 A86788FC15; Sat, 9 May 2009 04:36:51 +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 n494anHA007852; Sat, 9 May 2009 00:36:49 -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 n494an1D076006; Sat, 9 May 2009 00:36:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 37BE07302F; Sat, 9 May 2009 00:36:49 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090509043649.37BE07302F@freebsd-current.sentex.ca> Date: Sat, 9 May 2009 00:36:49 -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 ia64/ia64 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: Sat, 09 May 2009 04:36:52 -0000 TB --- 2009-05-09 04:04:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 04:04:46 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-09 04:04:46 - cleaning the object tree TB --- 2009-05-09 04:05:23 - cvsupping the source tree TB --- 2009-05-09 04:05:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-09 04:05:33 - building world TB --- 2009-05-09 04:05:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 04:05:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 04:05:33 - TARGET=ia64 TB --- 2009-05-09 04:05:33 - TARGET_ARCH=ia64 TB --- 2009-05-09 04:05:33 - TZ=UTC TB --- 2009-05-09 04:05:33 - __MAKE_CONF=/dev/null TB --- 2009-05-09 04:05:33 - cd /src TB --- 2009-05-09 04:05:33 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 04:05:36 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 [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 04:36:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 04:36:49 - ERROR: failed to build world TB --- 2009-05-09 04:36:49 - 1513.34 user 147.44 system 1922.70 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat May 9 07:09:44 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 6C2F7106566B; Sat, 9 May 2009 07:09:44 +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 2EBF38FC19; Sat, 9 May 2009 07:09:44 +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 n4979fOX017053; Sat, 9 May 2009 03:09:41 -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 n4979fAU010730; Sat, 9 May 2009 03:09:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 13C967302F; Sat, 9 May 2009 03:09:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090509070941.13C967302F@freebsd-current.sentex.ca> Date: Sat, 9 May 2009 03:09: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 205.211.164.50 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: Sat, 09 May 2009 07:09:45 -0000 TB --- 2009-05-09 05:43:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 05:43:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-09 05:43:12 - cleaning the object tree TB --- 2009-05-09 05:43:49 - cvsupping the source tree TB --- 2009-05-09 05:43:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-09 05:43:59 - building world TB --- 2009-05-09 05:43:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 05:43:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 05:43:59 - TARGET=sparc64 TB --- 2009-05-09 05:43:59 - TARGET_ARCH=sparc64 TB --- 2009-05-09 05:43:59 - TZ=UTC TB --- 2009-05-09 05:43:59 - __MAKE_CONF=/dev/null TB --- 2009-05-09 05:43:59 - cd /src TB --- 2009-05-09 05:43:59 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 05:44:03 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 Sat May 9 07:05:13 UTC 2009 TB --- 2009-05-09 07:05:13 - generating LINT kernel config TB --- 2009-05-09 07:05:13 - cd /src/sys/sparc64/conf TB --- 2009-05-09 07:05:13 - /usr/bin/make -B LINT TB --- 2009-05-09 07:05:13 - building LINT kernel TB --- 2009-05-09 07:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 07:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 07:05:13 - TARGET=sparc64 TB --- 2009-05-09 07:05:13 - TARGET_ARCH=sparc64 TB --- 2009-05-09 07:05:13 - TZ=UTC TB --- 2009-05-09 07:05:13 - __MAKE_CONF=/dev/null TB --- 2009-05-09 07:05:13 - cd /src TB --- 2009-05-09 07:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 9 07:05:14 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 [...] awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sparc64/src/sys/LINT /src/sys/modules/nullfs/../../fs/nullfs/null_subr.c /src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c /src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c ===> opensolaris (depend) @ -> /src/sys machine -> /src/sys/sparc64/include make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/sys/modules. *** 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-09 07:09:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 07:09:40 - ERROR: failed to build lint kernel TB --- 2009-05-09 07:09:40 - 3921.31 user 392.82 system 5188.72 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat May 9 14:55:49 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 347AE1065670 for ; Sat, 9 May 2009 14:55:49 +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 ABBEB8FC0A for ; Sat, 9 May 2009 14:55:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [137.122.79.188] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242352922; Sat, 09 May 2009 16:55:46 +0300 Message-ID: <4A058B5C.3010707@FreeBSD.org> Date: Sat, 09 May 2009 16:55:40 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Jung-uk Kim Subject: [Fwd: Re: amd64 suspend/resume broken on 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: Sat, 09 May 2009 14:55:49 -0000 -------- Original Message -------- Subject: Re: amd64 suspend/resume broken on current Date: Fri, 8 May 2009 21:52:45 +0200 From: Guy Brand Organization: Direction Informatique, Université de Strasbourg, France To: Alexander Motin References: <4A021118.2030106@mavhome.dp.ua> <20090508111024.GK4922@unistra.fr> <4A041DC2.90106@mavhome.dp.ua> <20090508144551.GA1599@unistra.fr> <4A047925.6060301@mavhome.dp.ua> Guy Brand wrote: > Alexander Motin wrote: > > Done. No firewire issue of course, but a kernel panic on resume. Bad > > karma since yesterday :-) > > Where is this panic happens now? Just after resuming: Fatal trap 12: page fault while in kernel mode ... current process = 1415 (acpiconf) The backtrace says: intr_execute_handlers() at intr_execute_handlers+0x21 lapic_handle_intr() at lapic_handle_intr+0x37 Xapic_isr1() at Xapic_isr1+0xa4 acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe acpi_AckSleepState() at acpi_AckSleepState+0x163 devfs_ioctl() at devfs_ioctl_f+0x77 kern_ioctl() at kern_ioctl+0xb0 ioctl() at ioctl+0xfd syscall() at syscal+0x246 Xfast_syscall() at Xfast_syscall+0xd0 -- bug -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat May 9 15:33: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 C4B7F1065675 for ; Sat, 9 May 2009 15:33: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 A27738FC17 for ; Sat, 9 May 2009 15:33:53 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:46383 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2oOr-0000SS-H2 for freebsd-current@freebsd.org; Sat, 09 May 2009 10:23:43 -0500 Date: Sat, 9 May 2009 10:23:25 -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: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: -2.4 (--) X-LERCTR-Spam-Score: -2.4 (--) X-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_CP=0.077 X-LERCTR-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_CP=0.077 DomainKey-Status: no signature Subject: sysctl -a crash on todays 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: Sat, 09 May 2009 15:33:54 -0000 I hit the following page-fault panic on todays -CURRENT, when running sysctl -a: I have the core and kernel. Script started on Sat May 9 10:20:26 2009 # kgdb /boot/kernel/kernel.symbols vmcore.4 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: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803b9996 stack pointer = 0x28:0xfffffffeb9f228d0 frame pointer = 0x28:0xfffffffeb9f228e0 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 = 1712 (sysctl) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap_pfault() at trap_pfault+0x294 trap() at trap+0x29a calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff803b9996, rsp = 0xfffffffeb9f228d0, rbp = 0xfffffffeb9f228e0 --- strlcpy() at strlcpy+0x16 sysctl_kern_malloc_stats() at sysctl_kern_malloc_stats+0x20e sysctl_root() at sysctl_root+0xfd userland_sysctl() at userland_sysctl+0x14f __sysctl() at __sysctl+0xaa syscall() at syscall+0x246 Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073024c, rsp = 0x7fffffffd878, rbp = 0x2 --- Uptime: 1h7m20s Physical memory: 4084 MB Dumping 535 MB: 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.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/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8031f599 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8031f9ec in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff8057c4cd in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:845 #4 0xffffffff8057c8b4 in trap_pfault (frame=0xfffffffeb9f22820, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:761 #5 0xffffffff8057d1ca in trap (frame=0xfffffffeb9f22820) at /usr/src/sys/amd64/amd64/trap.c:487 #6 0xffffffff80557e13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #7 0xffffffff803b9996 in strlcpy (dst=0xfffffffeb9f22930 "", src=0x0, siz=Variable "siz" is not available. ) at /usr/src/sys/libkern/strlcpy.c:54 #8 0xffffffff8030e1ee in sysctl_kern_malloc_stats (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_malloc.c:808 #9 0xffffffff80328c4d in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1514 #10 0xffffffff80328e9f in userland_sysctl (td=0x0, name=0xfffffffeb9f22ab0, namelen=2, old=0x0, oldlenp=0x7fffffffd920, inkernel=0, new=0x0, newlen=0, retval=0xfffffffeb9f22b18, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1613 #11 0xffffffff8032906a in __sysctl (td=0xffffff004861cab0, uap=0xfffffffeb9f22c00) at /usr/src/sys/kern/kern_sysctl.c:1544 #12 0xffffffff8057cb26 in syscall (frame=0xfffffffeb9f22c90) at /usr/src/sys/amd64/amd64/trap.c:977 #13 0xffffffff805580a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #14 0x000000080073024c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) # ^D Script done on Sat May 9 10:21:03 2009 -- 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 Sat May 9 17:12: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 8ADED106566B for ; Sat, 9 May 2009 17:12:20 +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 5D5E08FC12 for ; Sat, 9 May 2009 17:12:20 +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 687BB7E837; Sat, 9 May 2009 09:12:19 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sat, 9 May 2009 19:12:17 +0200 User-Agent: KMail/1.11.2 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) 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: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Larry Rosenman Subject: Re: sysctl -a crash on todays 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: Sat, 09 May 2009 17:12:20 -0000 On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: > I hit the following page-fault panic on todays -CURRENT, when running > sysctl -a: I have the core and kernel. > Reading symbols from /boot/modules/cpu.ko...done. > Loaded symbols for /boot/modules/cpu.ko Recompile that module and search archive for the why. -- Mel From owner-freebsd-current@FreeBSD.ORG Sat May 9 17:21: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 C8A461065670 for ; Sat, 9 May 2009 17:21:15 +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 A07FB8FC17 for ; Sat, 9 May 2009 17:21:15 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:14499 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2qEb-0001Kp-Qb; Sat, 09 May 2009 12:21:15 -0500 Date: Sat, 9 May 2009 12:21:00 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Mel Flynn In-Reply-To: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: References: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> 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.4 (--) X-LERCTR-Spam-Score: -2.4 (--) X-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_VC=0.077 X-LERCTR-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_VC=0.077 DomainKey-Status: no signature Cc: stas@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: sysctl -a crash on todays 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: Sat, 09 May 2009 17:21:16 -0000 On Sat, 9 May 2009, Mel Flynn wrote: > On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: >> I hit the following page-fault panic on todays -CURRENT, when running >> sysctl -a: I have the core and kernel. > > > >> Reading symbols from /boot/modules/cpu.ko...done. >> Loaded symbols for /boot/modules/cpu.ko > > Recompile that module and search archive for the why. Thanks. It actually doesn't compile at the moment due to kernel tree changes. (Maintainer CC'd). I've removed that KLD from the system and we're fine. # cd /usr/ports/sysutils/devcpu # make ===> Found saved configuration for devcpu-0.8.1 ===> Extracting for devcpu-0.8.3 => MD5 Checksum OK for devcpu-0.8.3.tar.bz2. => SHA256 Checksum OK for devcpu-0.8.3.tar.bz2. ===> Patching for devcpu-0.8.3 /usr/bin/sed -i.bak -e "s,%%PREFIX%%,/usr/local,g" /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu_microcode_tool/cpu_microcode_tool.8 ===> Configuring for devcpu-0.8.3 ===> Building for devcpu-0.8.3 ===> cpu (all) Warning: Object directory not changed from original /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -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 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cpu.c cpu.c: In function 'cpu_ioctl': cpu.c:158: error: invalid operands to binary & cpu.c: In function 'cpu_open': cpu.c:427: error: invalid operands to binary & *** Error code 1 Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu. *** Error code 1 Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3. *** Error code 1 Stop in /usr/ports/sysutils/devcpu. *** Error code 1 Stop in /usr/ports/sysutils/devcpu. # > -- 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 Sat May 9 19:04: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 D202110656CF for ; Sat, 9 May 2009 19:04:01 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 7E56B8FC20 for ; Sat, 9 May 2009 19:04:01 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 714158FC18 for ; Sat, 9 May 2009 23:03:53 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 9C8C78FC4E; Sat, 9 May 2009 23:03:03 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 9084B3982F; Sat, 9 May 2009 23:03:25 +0400 (MSD) Date: Sat, 9 May 2009 23:03:25 +0400 From: Stanislav Sedov To: Larry Rosenman Message-Id: <20090509230325.278241e0.stas@FreeBSD.org> In-Reply-To: References: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat May 9 23:03:53 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4a05d398994291470650666 Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: sysctl -a crash on todays 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: Sat, 09 May 2009 19:04:03 -0000 On Sat, 9 May 2009 12:21:00 -0500 (CDT) Larry Rosenman mentioned: > On Sat, 9 May 2009, Mel Flynn wrote: > > > On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: > >> I hit the following page-fault panic on todays -CURRENT, when running > >> sysctl -a: I have the core and kernel. > > > > > > > >> Reading symbols from /boot/modules/cpu.ko...done. > >> Loaded symbols for /boot/modules/cpu.ko > > > > Recompile that module and search archive for the why. > Thanks. It actually doesn't compile at the moment due to kernel tree changes. > (Maintainer CC'd). > > I've removed that KLD from the system and we're fine. > > # cd /usr/ports/sysutils/devcpu > # make > ===> Found saved configuration for devcpu-0.8.1 > ===> Extracting for devcpu-0.8.3 > => MD5 Checksum OK for devcpu-0.8.3.tar.bz2. > => SHA256 Checksum OK for devcpu-0.8.3.tar.bz2. > ===> Patching for devcpu-0.8.3 > /usr/bin/sed -i.bak -e "s,%%PREFIX%%,/usr/local,g" /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu_microcode_tool/cpu_microcode_tool.8 > ===> Configuring for devcpu-0.8.3 > ===> Building for devcpu-0.8.3 > ===> cpu (all) > Warning: Object directory not changed from original /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu > @ -> /usr/src/sys > machine -> /usr/src/sys/amd64/include > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -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 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cpu.c > cpu.c: In function 'cpu_ioctl': > cpu.c:158: error: invalid operands to binary & > cpu.c: In function 'cpu_open': > cpu.c:427: error: invalid operands to binary & > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu. > # > You should not use devcpu port on CURRENT. This code is already included both into STABLE and HEAD branches (sys/modules/cpuctl). -- Stanislav Sedov ST4096-RIPE !DSPAM:4a05d398994291470650666! From owner-freebsd-current@FreeBSD.ORG Sat May 9 19:13: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 C4BC41065716; Sat, 9 May 2009 19:13:24 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0258FC24; Sat, 9 May 2009 19:13:24 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 070CA8FE62; Sat, 9 May 2009 13:12:54 -0600 (MDT) Date: Sat, 9 May 2009 13:12:53 -0600 From: Brad Davis To: freebsd-hackers@FreeBSD.org Message-ID: <20090509191253.GD40521@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Status Reports January - March, 2009 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 May 2009 19:13:25 -0000 FreeBSD Quarterly Status Report Introduction Since the last Status Reports there has been interesting progress in FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some of the highlights include: Support for superpages in the FreeBSD Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has been increased to 6GB on amd64. An updated jail(8) subsystem that supports multi-IPv4/IPv6/noIP and much more. Lots of FreeBSD Developers are in Ottawa, Canada attending the FreeBSD Developer Summit that is before BSDCan. BSDCan officially starts tomorrow and should cover lots of interesting topics, see the BSDCan Website for more information. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Projects * Clang replacing GCC in the base system * Device mmap() Extensions * OpenBSM * Release Engineering * Sysinfo - a set of scripts which document your system * TrustedBSD MAC Framework in GENERIC * VFS/NFS DTrace Probes * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD BugBusting Team Architectures * FreeBSD/powerpc G5 Support * FreeBSD/sparc64 UltraSPARC III support Documentation * Dutch Documentation Project * German Documentation Project * Hungarian Documentation Project Google Summer of Code * BSD-licensed text-processing tools __________________________________________________________________ BSD-licensed text-processing tools URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ soc2008/gabor_textproc Contact: Gábor Kövesdán Currently, grep is finished and is only waiting for a portbuild test. It is known to be more or less feature complete, while it is much smaller than the GNU version. As for sort, there has been some progress with the complete rewrite and it is lacking few options. Performance is to be measured, as well. Open tasks: 1. Test grep on pointyhat. 2. Complete sort with the missing features. 3. Do performance measurements for sort and look for possible optimization opportunities. 4. Test sort on pointyhat. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang URL: http://git.hoeg.nl/?p=llvm-bmake URL: http://clang.llvm.org/ Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The last 3-4 months we've been working together with the LLVM developers to discuss any bugs and issues we are experiencing with their Clang compiler frontend. The FreeBSD project is looking at the possibility to replace GCC with Clang as a system compiler. It can compile 99% of the FreeBSD world and can compile booting kernel on i386/amd64 but it still contains bugs and its C++ support is still immature. Ed is maintaining a patchset for the FreeBSD sources to replace cc(1) by a Clang binary and bootstrap almost all sources with the Clang compiler. The LLVM developers are very helpful fixing most of the bugs we've reported (over 100). Unfortunately we are currently blocked on some bug reports that prevent us from building libc, libm, libcrypto and various CDDL libraries with Clang but the FreeBSD kernel itself compiles and boots. Open tasks: 1. Testing Clang with compilation of various applications and reporting bugs. 2. Testing the llvm-bmake branch to find more bugs. 3. Arranging an experimental ports build. __________________________________________________________________ Device mmap() Extensions URL: http://www.FreeBSD.org/~jhb/pat/ Contact: John Baldwin GPU device drivers are increasingly requiring more sophisticated support for mapping objects into both userland and the kernel. For example, memory used for textures often needs to be mapped Write-Combining rather than Write-Back. I have recently created three patches to provide several extensions. The first patch allows device drivers to use a different VM object to back specific mmap() calls instead of always using the device pager. The second patch introduces a new VM object type that can map an arbitrary set of physical address ranges. This can be used to let userland mmap PCI BARs, etc. The third patch allows memory mappings to use different caching modes (e.g. Write-Combining or Uncacheable). Together I believe these patches provide the remaining pieces needed for an Nvidia amd64 driver. They will also be useful for future Xorg DRM support as well. The current set of patches can be safely merged back to 7.x as well. Currently I am waiting for review and feedback from several folks. I am hopeful that these patches will be in HEAD soon, prior to the 8.0 freeze. __________________________________________________________________ Dutch Documentation Project URL: http://wiki.freebsd.org/DutchDocumentationProject URL: http://www.freebsd.org/doc/nl/ URL: http://p4web.freebsd.org/@md=d&cd=//&c=pFl@//depot/projects/docproj_nl/ ?ac=83 Contact: Remko Lodder Contact: René Ladan The FreeBSD Dutch Documentation Project is an ongoing project to translate FreeBSD Documentation into the Dutch language. The translation of the Handbook was completed last January. It is kept up-to-date with the English version. Furthermore five articles and the flyer have been translated. Some initial work has been done to translate the website, but most likely more translators are needed to fully realize it. Open tasks: 1. Recruit more translators. 2. Keep the translations up-to-date with the English versions. 3. Finish the translation of the FAQ. 4. Translate more articles and maybe some books. __________________________________________________________________ FreeBSD BugBusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.freebsd.org/~linimon/studies/prs/recommended_prs.html Contact: Mark Linimon Contact: Remko Lodder We continue to classify PRs as they arrive, with 'tags' corresponding to the kernel subsystem, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage Mark Linimon (linimon@) has created special reports for the Release Engineering Team to help focus on regressions and other areas of interest relating to the release of FreeBSD 7.2 in the coming weeks. This is a refinement of the 'customized reports for developers' announced in the last status report. A full list of all the automatically generated reports is also available. Any recommendations for reports which do not currently exist but which would be beneficial are welcomed. Mark Linimon also continues attempting to define the general problem and investigating possible new work flow models, and will be presenting on the subject at BSDCan. The list of PRs recommended for committer evaluation by the BugBusting team continues to receive new additions. This list contains PRs, mostly with patches, that the BugBusting team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. Since the last status report, the number of open bugs continued to hover around the 5600 mark, although has began to rise with the 7.2 ports freeze. As always, more help is appreciated, and committers and non-committers alike are invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Think of some way for committers to only view PRs that have been in some way 'vetted' or 'confirmed'. 3. Generate more publicity for what we've already got in place, and for what we intend to do next. 4. Define new categories, classifications, and states for PRs, that will better match our work flow (in progress). __________________________________________________________________ FreeBSD/powerpc G5 Support Contact: Nathan Whitehorn FreeBSD 8.0-CURRENT now has support for PowerPC CPUs operating in the 64-bit bridge mode. This includes the PowerPC 970 (G5) as well as the POWER3 and POWER4. Currently only Apple systems are known to work. Open tasks: 1. IBM systems currently are not supported due to missing northbridge support. 2. Software fan control on SMU-based Apple G5 systems (G5 iMac, later Powermac G5) is not available. __________________________________________________________________ FreeBSD/sparc64 UltraSPARC III support Contact: Marius Strobl Like announced in the previous status report, support for sun4u-machines based on UltraSPARC III and beyond has been MFC'ed to stable/7 (the last missing piece was r190297) and thus will be present in the upcoming 7.2-RELEASE and can be already tested with 7.2-RC1. Additionally, as of r191076 machfb(4) has been fixed to work with UltraSPARC III and beyond, that fix unfortunately did not make it into 7.2-RC1 but will be in the final version. The X.Org 7.4 and Firefox ports as well as some other gecko-based ones like Seamonkey once again have been fixed to also work and package on sparc64, including on UltraSPARC III and UltraSPARC IIIi based machines equipped with cards driven by creator(4) or machfb(4). The driver for the Sun Cassini/Cassini+ as well as National Semiconductor DP83065 Saturn Gigabit NICs found on-board for example in Fire V440 and as add-on cards is coming along nicely, the last thing which needs to be implemented before it can hit CURRENT is support for jumbo frames. __________________________________________________________________ German Documentation Project URL: https://doc.bsdgroup.de Contact: Johann Kois Contact: Martin Wilke In February 2009 the German version of the FreeBSD Developer's handbook went online. Additionally we managed to update large areas of the FAQ thanks to the contributions of Benedict Reuschling. The website (at least the areas we see as relevant for a translation) is translated and updated constantly. More volunteers are always welcome of course, as there is still plenty of work to be done. Open tasks: 1. Update the existing documentation set (especially the handbook). 2. Read the translations. Check for problems/mistakes. Send feedback. __________________________________________________________________ Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli We are proud to announce that the FreeBSD Hungarian web pages have been extended by the following items: * Project news entries, staring from 2009 (HTML, RSS, RDF) * Press releases, starting from 2008 (HTML, RSS) * Events, starting from 2009 (HTML, RSS) * Security advisories (HTML, RSS) We are still hoping that having the FDP Primer translated will encourage others to help our work. Feel free to contribute, every submitted line of translation or feedback is appreciated and is highly welcome. For more information on how to contribute, please read the project's introduction (in Hungarian). Open tasks: 1. Translate news entries, press releases. 2. Translate Release Notes for -CURRENT and 8.X. 3. Translate articles. 4. Translate web pages. 5. Read the translations, send feedback. __________________________________________________________________ OpenBSM URL: http://www.openbsm.org/ Contact: Robert Watson Contact: TrustedBSD audit mailing list The TrustedBSD Project has now released OpenBSM 1.1, the second production release of the OpenBSM code base. OpenBSM 1.1 has been merged to FreeBSD 8-CURRENT, and will be merged to 7-STABLE before FreeBSD 7.3. Major changes since OpenBSM 1.0 include: * Trail files now include the host where the trail is generated. Crash recovery has been improved. Trail expiration based on size and date is now supported; by default trail files will be expired after 10MB of trails. The default individual trail limit is now 2MB. * Mac OS X Snow Leopard is now a fully supported platform; launchd(8) can now be used to launchd auditd(8). Command line tools and libraries are now supported on Mac OS X Leopard. * Extended header tokens are now supported, allowing audit trails to be tagged with a host identifier. IPv6 addresses are now supported in subject tokens. BSM token and record types have been further synchronized to OpenSolaris; support for many new system calls has been added. Local errors and socket types are mapped to and from BSM values. Since the last test release, OpenBSM 1.1 beta 1, 32/64-bit compatibility has been fixed for the auditon(2) system call. A default "expire-after" of 10MB is now set in audit_control(5). Local fcntl(2) arguments are now mapped to wire BSM versions using new APIs. The audit_submit(3) man page has been fixed. A new audit event class has been added for post-login authentication and access control events. Open tasks: 1. Migrate to sbufs in token-encoding. 2. Support for auditing NFS RPCs. __________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team (with lots of help from lots of other people) released FreeBSD 7.2 on May 4th, 2009. During this period we have also begun reminding developers of the upcoming FreeBSD 8.0 release cycle which is scheduled to begin in early June 2009 with release targeted at early September 2009. __________________________________________________________________ Sysinfo - a set of scripts which document your system URL: http://danger.rulez.sk/index.php/2009/04/14/sysinfo-a-set-of-scripts-wh ich-document-your-freebsd-system/ URL: https://forums.freebsd.org/showthread.php?p=19321 Contact: Daniel Gerzo Sysinfo a shell script which purpose is to automatically gather system information and document hardware and software configuration of the given host system. The goal is to provide a system operator with descriptive information about an unknown FreeBSD installation. It consists of several modules (also shell scripts), thus is easily extensible and provides an easy way to inspect overall system configuration. It has been written as part of my Bachelor thesis and its development is a work in progress. Therefore, I would appreciate if you could provide me with some feedback as I will defend my thesis soon. Your feedback is welcome at the forums , or alternatively you can send me a private email. The tool itself can now be installed using the Ports tree from the sysutils/sysinfo port. Open tasks: 1. Receive additional feedback. 2. Perform more testing. 3. Extend and improve the tool. __________________________________________________________________ TrustedBSD MAC Framework in GENERIC URL: http://www.trustedBSD.org/mac.html Contact: Robert Watson Contact: TrustedBSD discussion mailing list There is on-going work to allow "options MAC" to be included in the GENERIC kernel for 8.0. This primarily consists of performance work to reduce overhead when policies are used, and eliminate when none are configured. Work to date includes: * The MAC Framework now detects which object types are labeled by policies, and MAC label storage is not allocated when it won't be used. * Add MAC Framework DTrace probes so allow more easy analysis of MAC Framework and policy interactions. * Eliminate mutex-protected reference count used to prevent module unload during entry point invocation, and replace with an sx lock and an rwlock, respectively for long-sleepable and short-sleepable entry points, significantly lowering the overhead of entering the MAC Framework. If no dynamic policies are loaded, no locking overhead is taken. Open tasks: 1. Move to rmlocks for non-sleepable entry points to reduce cache line thrashing under load. 2. Macroize invocation of MAC Framework entry points from the kernel, and perform caller-side determination of whether MAC is enabled in order to avoid additional function call overhead in the caller path if MAC is disabled. __________________________________________________________________ VFS/NFS DTrace Probes Contact: Robert Watson A new DTrace provider, dtnfsclient, has been added to the FreeBSD 8.x kernel, and will be merged to 7.x before 7.3. The following probes are available: * nfsclient:{nfs2,nfs3}:{procname}:start - NFSv2 and NFSv3 RPC start probes * nfsclient:{nfs2,nfs3}:{procname}:done - NFSv2 and NFSv3 RPC done probes * nfsclient:accesscache:: - NFS access cache flush/hit/miss/load probes * nfsclient:attrcache:: - NFS attribute cache flush/hit/miss/done In addition, a number of VFS probes have been added: * vfs:vop:{vopname}:entry - VOP entry probe * vfs:vop:{vopname}:return - VOP return probe * vfs:namei:lookup:entry - VFS name lookup entry probe * vfs:namei:lookup:return - VFS name lookup return probe * vfs:namecache:*:* - VFS namecache enter/enter_negative/fullpath_enter/fullpath_hit/fullpath_miss/full path_return/lookup_hit/lookup_hit_negative/lookup_miss/purge/purge_ negative/purgevfs/zap/zap_negative probes These probes make it much easier to trace NFS and VFS events. Open tasks: 1. Add VFSOP tracing. 2. Add RPC-layer tracing, such as RPC retransmits. 3. Provide decoded NFS RPCs in order to expose transaction IDs and file handles. __________________________________________________________________ VirtualBox on FreeBSD URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd/ URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd-first-screenshots/ URL: http://vbox.innotek.de/pipermail/vbox-dev/2009-May/001369.html Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Martin Wilke After the first mail from Alexander Eichner on the vbox-dev mailinglist, we started the work on a VirtualBox port. 6 Days was needed to get VirtualBox to start with over 20 patches. We'd like to say thanks to Alexander Eichner, all the VirtualBox Developers, Gustau Perez and Ulf Lilleengen. If you like to play with the current port you can checkout the port here. Please do not ping us about any problems, we know about a lot and are still working to get them all solved before we do an official call for testing. Open tasks: 1. Fix kernel crashes on 7.2-RELEASE. 2. Code cleanup. 3. Fix errors on AMD64. 4. Fix user/permission problems. From owner-freebsd-current@FreeBSD.ORG Sat May 9 22:00: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 08E3A106566B for ; Sat, 9 May 2009 22:00:31 +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 7925C8FC08 for ; Sat, 9 May 2009 22:00:30 +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 51EA3EB53A8 for ; Sun, 10 May 2009 01:00:29 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 4167645088 for ; Sun, 10 May 2009 01:00:29 +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 ny-nLWXVrZgu for ; Sun, 10 May 2009 01:00:29 +0300 (EEST) Received: from kobe.laptop (static062038151242.dsl.hol.gr [62.38.151.242]) by mail.ceid.upatras.gr (Postfix) with ESMTP id A5D2C4503F for ; Sun, 10 May 2009 01:00:28 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n49M0OGD002226 for ; Sun, 10 May 2009 01:00:24 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n49M0Mw4002225; Sun, 10 May 2009 01:00:22 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: freebsd-current@freebsd.org Date: Sat, 09 May 2009 20:59:30 +0300 Message-ID: <87bpq288e5.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: bug in perl 5.10 on 8.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 May 2009 22:00:31 -0000 I've recently enabled kern.sugid_coredump=1 to debug a problem in a problem of my own and noticed this too: $ ls -ld /*core -rw------- 1 root wheel - 11612160 May 9 12:13 /perl5.10.0.core # gdb /usr/local/bin/perl5 /perl*core ... (gdb) bt #0 0x283136a7 in kill () at kill.S:2 #1 0x282243f7 in _raise (sig=6) at /usr/src/lib/libthr/thread/thr_sig.c:185 #2 0x2831222a in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #3 0x282f8756 in __assert (func=0xbfbfeb24 "\006", file=0x3
, line=0, failedexpr=0x2831bcb0 "(run->regs_mask[elm] & (1U << bit)) == 0") at /usr/src/lib/libc/gen/assert.c:54 #4 0x28299c4a in arena_dalloc_small (arena=0x8049c40, chunk=0x28400000, ptr=Variable "ptr" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:2543 #5 0x2829a020 in idalloc (ptr=0x284d7ec0) at /usr/src/lib/libc/stdlib/malloc.c:3871 #6 0x2829a757 in free (ptr=0x284d7ec0) at /usr/src/lib/libc/stdlib/malloc.c:5454 #7 0x2830cefb in __clean_env (freeVars=true) at /usr/src/lib/libc/stdlib/getenv.c:236 #8 0x2824dde0 in ?? () from /lib/libc.so.7 #9 0x28325800 in ?? () from /lib/libc.so.7 #10 0x280782d8 in ?? () from /libexec/ld-elf.so.1 #11 0xbfbfecf8 in ?? () #12 0x28316dcc in _fini () from /lib/libc.so.7 #13 0x28088380 in ?? () #14 0x280782d8 in ?? () from /libexec/ld-elf.so.1 #15 0xbfbfecf8 in ?? () #16 0x2804ec6f in objlist_call_fini (list=Variable "list" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:1620 Previous frame inner to this frame (corrupt stack?) (gdb) x/100b 0x284d7ec0 0x284d7ec0: 0x44 0x42 0x55 0x53 0x5f 0x53 0x54 0x41 0x284d7ec8: 0x52 0x54 0x45 0x52 0x5f 0x42 0x55 0x53 0x284d7ed0: 0x5f 0x54 0x59 0x50 0x45 0x3d 0x73 0x79 0x284d7ed8: 0x73 0x74 0x65 0x6d 0x00 0x70 0x72 0x69 0x284d7ee0: 0xc0 0x7e 0x4d 0x28 0x80 0x70 0xe6 0x28 0x284d7ee8: 0x00 0x00 0x00 0x00 0x75 0x73 0x65 0x72 0x284d7ef0: 0x5b 0x31 0x5d 0x5c 0x6e 0x22 0x3b 0x0a 0x284d7ef8: 0x20 0x20 0x20 0x20 0x20 0x20 0x70 0x72 0x284d7f00: 0x00 0x00 0x00 0x00 0xc0 0x58 0x1d 0x28 0x284d7f08: 0x00 0x00 0x63 0x00 0x0c 0x00 0x00 0x00 0x284d7f10: 0x00 0x00 0x00 0x00 0x70 0xee 0xe6 0x28 0x284d7f18: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x284d7f20: 0x0c 0x00 0x00 0x00 Current language: auto; currently asm (gdb) x/s 0x284d7ec0 0x284d7ec0: "DBUS_STARTER_BUS_TYPE=system" Has anyone else seen something similar? Is this an already known bug in Perl or an artifact of the way __clean_env() works in 8.0-CURRENT?