From owner-freebsd-acpi@FreeBSD.ORG Sun May 3 23:18:25 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8117106566B for ; Sun, 3 May 2009 23: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 F0E388FC20 for ; Sun, 3 May 2009 23:18:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 23:18:26 -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-acpi@FreeBSD.ORG Sun May 3 23:28:45 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBEC1065672 for ; Sun, 3 May 2009 23:28:45 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi025.prodigy.net (nlpi025.sbcis.sbc.com [207.115.36.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F72D8FC0A for ; Sun, 3 May 2009 23:28:45 +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 nlpi025.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n43NA94a015099; Sun, 3 May 2009 18:10:10 -0500 Message-ID: <49FE2452.4000401@root.org> Date: Sun, 03 May 2009 16:10:10 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Moore, Robert" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: [Fwd: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 23:28:46 -0000 Wonder what you thought of this patch to avoid Aliases in AcpiWalkNamespace()? -------- Original Message -------- Subject: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes Resent-Date: Sun, 3 May 2009 19:50:01 GMT Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-CC: jkim@freebsd.org, njl@freebsd.org Date: Sun, 3 May 2009 23:41:28 +0400 (MSD) From: Eygene Ryabinkin Reply-To: Eygene Ryabinkin To: FreeBSD-gnats-submit@freebsd.org >Number: 134192 >Category: kern >Synopsis: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 03 19:50:00 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Eygene Ryabinkin >Release: FreeBSD 7.1-STABLE amd64 >Organization: Code Labs >Environment: System: FreeBSD 7.1-STABLE amd64 >Description: Some vendors (in my case, Asus) like to create aliases for node names in the DSDT table: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) Processor (P002, 0x02, 0x00000000, 0x00) {} Alias (P002, CPU2) Processor (P003, 0x03, 0x00000000, 0x00) {} Alias (P003, CPU3) Processor (P004, 0x04, 0x00000000, 0x00) {} Alias (P004, CPU4) } ----- Another example (from Asus system too) is presented in the patch below. Since AcpiWalkNamespace treats CPUX as the real Processor objects, the probe order for acpi(4) bus children will be P001, CPU1, P002, CPU2, P003, CPU3, P004, CPU4. This is very bad, because half of processors are attached twice and half -- aren't attached at all. Moreover, est (Enhanced SpeedStep cpufreq driver) isn't able to get _PSS for CPUX, so P-states will be missing for half of processors. >How-To-Repeat: Insert Alias() instruction to your custom DSDT and try to use it, enabling debug that will show what ACPI nodes are attached to cpuX device nodes. >Fix: The following patch adds ACPI namespace walking procedure that skips nodes that are results of the Alias() operator invocation. This new method is used for probing of acpi(4) bus members. The patch works on two machines of mine that have these annoying Alias() calls in the _PR namespace. I had tried this patch both on 7.x and 8-CURRENT. --- ACPI-attach-children-without-aliases.diff begins here --- >From f70d0d754f381735a67a42be91fa7253b19a5c8c Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin Date: Sun, 3 May 2009 22:00:20 +0400 ...and use this function to probe acpi(4) children. The rationale is very simple: some BIOS vendors, in my case it was Asus, like to create aliased nodes in the namespaces that will be walked by the acpi bus method that attaches children to the bus. In my particular case, the problem lied in the Processor objects: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) } Scope (_PR) { Processor (P002, 0x02, 0x00000810, 0x06) {} Alias (P002, CPU2) } ----- The thing is that the simple walk routine treated CPU1 and CPU2 as real processors and order of attachment was P001, CPU1, P002, CPU2. Thus, the second CPU was never attached, first was attached twice and est (Enhanced SpeedStep cpufreq(4) driver) was failing to get _PSS (processor P-states) from the CPU1. I greatly doubt that some real devices will be ever created as aliases, since they should be real objects and not modified copies of other device instances. And since ASL Alias() semantics is to provide pseudonym, this modification should be "The Good Thing (tm)". Signed-off-by: Eygene Ryabinkin --- sys/contrib/dev/acpica/aclocal.h | 1 + sys/contrib/dev/acpica/acnamesp.h | 1 + sys/contrib/dev/acpica/acpixf.h | 9 +++++ sys/contrib/dev/acpica/excreate.c | 3 ++ sys/contrib/dev/acpica/nswalk.c | 10 ++++- sys/contrib/dev/acpica/nsxfeval.c | 69 ++++++++++++++++++++++++++++++++++--- sys/dev/acpica/acpi.c | 18 +++++---- 7 files changed, 96 insertions(+), 15 deletions(-) diff --git a/sys/contrib/dev/acpica/aclocal.h b/sys/contrib/dev/acpica/aclocal.h index ba1145e..73e1568 100644 --- a/sys/contrib/dev/acpica/aclocal.h +++ b/sys/contrib/dev/acpica/aclocal.h @@ -301,6 +301,7 @@ typedef struct acpi_namespace_node #define ANOBJ_METHOD_ARG 0x04 /* Node is a method argument */ #define ANOBJ_METHOD_LOCAL 0x08 /* Node is a method local */ #define ANOBJ_SUBTREE_HAS_INI 0x10 /* Used to optimize device initialization */ +#define ANOBJ_IS_ALIAS 0x20 /* Node is an alias to another one */ #define ANOBJ_IS_EXTERNAL 0x08 /* iASL only: This object created via External() */ #define ANOBJ_METHOD_NO_RETVAL 0x10 /* iASL only: Method has no return value */ diff --git a/sys/contrib/dev/acpica/acnamesp.h b/sys/contrib/dev/acpica/acnamesp.h index 8d07fb3..52a50bb 100644 --- a/sys/contrib/dev/acpica/acnamesp.h +++ b/sys/contrib/dev/acpica/acnamesp.h @@ -146,6 +146,7 @@ #define ACPI_NS_WALK_NO_UNLOCK 0 #define ACPI_NS_WALK_UNLOCK 0x01 #define ACPI_NS_WALK_TEMP_NODES 0x02 +#define ACPI_NS_WALK_SKIP_ALIASES 0x04 /* diff --git a/sys/contrib/dev/acpica/acpixf.h b/sys/contrib/dev/acpica/acpixf.h index f85fd67..3757ad0 100644 --- a/sys/contrib/dev/acpica/acpixf.h +++ b/sys/contrib/dev/acpica/acpixf.h @@ -238,6 +238,15 @@ AcpiWalkNamespace ( void **ReturnValue); ACPI_STATUS +AcpiWalkNamespaceNoAliases ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue); + +ACPI_STATUS AcpiGetDevices ( char *HID, ACPI_WALK_CALLBACK UserFunction, diff --git a/sys/contrib/dev/acpica/excreate.c b/sys/contrib/dev/acpica/excreate.c index d237dab..dba8312 100644 --- a/sys/contrib/dev/acpica/excreate.c +++ b/sys/contrib/dev/acpica/excreate.c @@ -221,6 +221,9 @@ AcpiExCreateAlias ( break; } + /* Mark object as alias, so alias creation could be detected */ + AliasNode->Flags |= ANOBJ_IS_ALIAS; + /* Since both operands are Nodes, we don't need to delete them */ return_ACPI_STATUS (Status); diff --git a/sys/contrib/dev/acpica/nswalk.c b/sys/contrib/dev/acpica/nswalk.c index a3ac86c..9cbc56d 100644 --- a/sys/contrib/dev/acpica/nswalk.c +++ b/sys/contrib/dev/acpica/nswalk.c @@ -208,8 +208,7 @@ AcpiNsGetNextNode ( * PARAMETERS: Type - ACPI_OBJECT_TYPE to search for * StartNode - Handle in namespace where search begins * MaxDepth - Depth to which search is to reach - * Flags - Whether to unlock the NS before invoking - * the callback routine + * Flags - Flags that modify walk parameters * UserFunction - Called when an object of "Type" is found * Context - Passed to user function * ReturnValue - from the UserFunction if terminated early. @@ -300,6 +299,13 @@ AcpiNsWalkNamespace ( Status = AE_CTRL_DEPTH; } + /* Skip nodes created by Alias() routines if it was requested */ + else if ((ChildNode->Flags & ANOBJ_IS_ALIAS) && + (Flags & ACPI_NS_WALK_SKIP_ALIASES)) + { + Status = AE_CTRL_DEPTH; + } + /* Type must match requested type */ else if (ChildType == Type) diff --git a/sys/contrib/dev/acpica/nsxfeval.c b/sys/contrib/dev/acpica/nsxfeval.c index 617002c..662a9df 100644 --- a/sys/contrib/dev/acpica/nsxfeval.c +++ b/sys/contrib/dev/acpica/nsxfeval.c @@ -122,6 +122,16 @@ #include #include +static ACPI_STATUS +_AcpiWalkNamespace ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue, + UINT32 AddFlags); + #define _COMPONENT ACPI_NAMESPACE ACPI_MODULE_NAME ("nsxfeval") @@ -491,11 +501,62 @@ AcpiWalkNamespace ( void *Context, void **ReturnValue) { - ACPI_STATUS Status; + ACPI_FUNCTION_TRACE (AcpiWalkNamespace); + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, + UserFunction, Context, ReturnValue, 0); +} - ACPI_FUNCTION_TRACE (AcpiWalkNamespace); +ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) +/******************************************************************************* + * + * FUNCTION: AcpiWalkNamespaceNoAliases + * + * DESCRIPTION: The same as AcpiWalkNamespace, but skips nodes that were + * created as the result of an Alias function. + * + * NOTE: for parameters/semantics see AcpiWalkNamespace. + * + ******************************************************************************/ + +ACPI_STATUS +AcpiWalkNamespaceNoAliases ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue) +{ + ACPI_FUNCTION_TRACE (AcpiWalkNamespaceNoAliases); + + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, + UserFunction, Context, ReturnValue, ACPI_NS_WALK_SKIP_ALIASES); +} + +ACPI_EXPORT_SYMBOL (AcpiWalkNamespaceNoAliases) + +/******************************************************************************* + * + * FUNCTION: _AcpiWalkNamespace + * + * DESCRIPTION: Internal helper for AcpiWalkNamespace and + * AcpiWalkNamespaceNoAliases. + * + ******************************************************************************/ + +static ACPI_STATUS +_AcpiWalkNamespace ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue, + UINT32 AddFlags) +{ + ACPI_STATUS Status; /* Parameter validation */ @@ -519,15 +580,13 @@ AcpiWalkNamespace ( } Status = AcpiNsWalkNamespace (Type, StartObject, MaxDepth, - ACPI_NS_WALK_UNLOCK, + AddFlags | ACPI_NS_WALK_UNLOCK, UserFunction, Context, ReturnValue); (void) AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE); return_ACPI_STATUS (Status); } -ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) - /******************************************************************************* * diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index d79b413..18a9800 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -1528,7 +1528,7 @@ acpi_device_scan_children(device_t bus, device_t dev, int max_depth, ctx.user_fn = user_fn; ctx.arg = arg; ctx.parent = h; - return (AcpiWalkNamespace(ACPI_TYPE_ANY, h, max_depth, + return (AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, h, max_depth, acpi_device_scan_cb, &ctx, NULL)); } @@ -1648,14 +1648,16 @@ acpi_probe_children(device_t bus) * Scan the namespace and insert placeholders for all the devices that * we find. We also probe/attach any early devices. * - * Note that we use AcpiWalkNamespace rather than AcpiGetDevices because - * we want to create nodes for all devices, not just those that are - * currently present. (This assumes that we don't want to create/remove - * devices as they appear, which might be smarter.) + * Note that we use AcpiWalkNamespaceNoAliases rather than + * AcpiGetDevices because we want to create nodes for all devices, + * not just those that are currently present. (This assumes that we + * don't want to create/remove devices as they appear, which might + * be smarter.) We avoid counting aliased nodes, because we generally + * want to attach only to a "genuine" devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "namespace scan\n")); - AcpiWalkNamespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, acpi_probe_child, - bus, NULL); + AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, + acpi_probe_child, bus, NULL); /* Pre-allocate resources for our rman from any sysresource devices. */ acpi_sysres_alloc(bus); @@ -2794,7 +2796,7 @@ acpi_wake_prep_walk(int sstate) ACPI_HANDLE sb_handle; if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, "\\_SB_", &sb_handle))) - AcpiWalkNamespace(ACPI_TYPE_DEVICE, sb_handle, 100, + AcpiWalkNamespaceNoAliases(ACPI_TYPE_DEVICE, sb_handle, 100, acpi_wake_prep, &sstate, NULL); return (0); } -- 1.6.2.4 --- ACPI-attach-children-without-aliases.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun May 3 23:32:53 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3DD0106566C; Sun, 3 May 2009 23:32:53 +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 842CD8FC16; Sun, 3 May 2009 23:32:53 +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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 23:32:54 -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-acpi@FreeBSD.ORG Mon May 4 01:30:56 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F6D106566B; Mon, 4 May 2009 01:30:56 +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 179228FC14; Mon, 4 May 2009 01:30:55 +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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 01:30:56 -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-acpi@FreeBSD.ORG Mon May 4 03:19:41 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 03:45:14 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 07:50:24 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 08:24:07 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33C6C106566C; Mon, 4 May 2009 08:24:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.tele2.se [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 937118FC0A; Mon, 4 May 2009 08:24:06 +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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 08:24:07 -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-acpi@FreeBSD.ORG Mon May 4 09:51:10 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 10:04:52 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D74B1106566C for ; Mon, 4 May 2009 10:04:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACCF8FC08 for ; Mon, 4 May 2009 10:04:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm6 with SMTP id 6so3577799fxm.43 for ; Mon, 04 May 2009 03:04: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=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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:04:53 -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-acpi@FreeBSD.ORG Mon May 4 11:07:38 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A12B106564A for ; Mon, 4 May 2009 11:07:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F16DF8FC0A for ; Mon, 4 May 2009 11:07:37 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n44B7bV8098329 for ; Mon, 4 May 2009 11:07:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n44B7aVG098315 for freebsd-acpi@FreeBSD.org; Mon, 4 May 2009 11:07:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 May 2009 11:07:36 GMT Message-Id: <200905041107.n44B7aVG098315@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 11:07:38 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 46 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 4 12:24:32 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 13:12:26 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 13:21:03 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745421065697 for ; Mon, 4 May 2009 13:21:03 +0000 (UTC) (envelope-from patttern@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 DFA928FC1C for ; Mon, 4 May 2009 13:21:02 +0000 (UTC) (envelope-from patttern@gmail.com) Received: by bwz9 with SMTP id 9so3630101bwz.43 for ; Mon, 04 May 2009 06:21:01 -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=SaCSj4m1McNn6ofP5bLeVDwMIm2hJhUw+yb66Gd/yIk=; b=mWAA3T5757tqpNMLYhKn7onFtNN0ESf9UG/IXXawT8cvwBV8toqcSjfFz//nofTq6q H9mdSuOIOoIsgEu4ENPYoz3JprHNJv99r2w5aMSTCo5Ba3w2iYH6bh4BTDToMrR12msr En/GxZmTalZufxv+5UXVBgmYn1fVzdj+Zu6GQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=On5zKfzFiLtIoMjfPLiwquhnqpo1kHc3tfER/ynF4/CYi3+H3cSUqQo1wP28sFEefl uqzM86sQzF2SUXiQXOTd+ycTlxRZpie0hHaCRG9KCjcVGCcynUQRNJydgUi2PuG7REUl oMV65zrnQBqVhIifHdymMV68xmWjoGB9dqdMg= MIME-Version: 1.0 Received: by 10.204.57.13 with SMTP id a13mr5640477bkh.205.1241443260562; Mon, 04 May 2009 06:21:00 -0700 (PDT) Date: Mon, 4 May 2009 17:21:00 +0400 Message-ID: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> From: Pattern To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ACPI on Toshiba A210 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:21:04 -0000 Hi! I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. At loading FreeBSD by default, the system does not detect hard disks. Through acpidump i have received a dsl-file. (dsdt_SB600.dsl) After considerable editing of a file, i have received a file without errors. (dsdt_SB600.diff) Result of operation iasl: [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20070320 [Mar 31 2009] Copyright (C) 2000 - 2007 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes 873 named objects 2398 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 Optimizations I have placed the aml-file received as a result of operation in /boot and have registered it in loader.conf. [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf acpi_dsdt_load="YES" acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" After system reboot, hard disks as have not found out. In the console following errors are output. acpi0: om motherboard ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc69cde80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST ... unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (irq) That the system has successfully booted it is required to apply the following file. (dsdt_SB600_addon.diff) (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date Why it occurs and how it to fix? http://pma.8855.ru/files/dsdt_SB600.dsl http://pma.8855.ru/files/dsdt_SB600.diff http://pma.8855.ru/files/dsdt_SB600_addon.diff From owner-freebsd-acpi@FreeBSD.ORG Mon May 4 15:10:01 2009 Return-Path: Delivered-To: freebsd-acpi@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 , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Mon May 4 19:33:05 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7019C1065673; Mon, 4 May 2009 19:33:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Mon, 4 May 2009 15:32:50 -0400 User-Agent: KMail/1.6.2 References: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> In-Reply-To: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_jL0/Jil2dSzr+vi" Message-Id: <200905041532.52001.jkim@FreeBSD.org> Cc: Pattern Subject: Re: ACPI on Toshiba A210 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:33:05 -0000 --Boundary-00=_jL0/Jil2dSzr+vi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 04 May 2009 09:21 am, Pattern wrote: > Hi! > I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. > At loading FreeBSD by default, the system does not detect hard > disks. Through acpidump i have received a dsl-file. > (dsdt_SB600.dsl) After considerable editing of a file, i have > received a file without errors. (dsdt_SB600.diff) > Result of operation iasl: > > [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20070320 [Mar 31 2009] > Copyright (C) 2000 - 2007 Intel Corporation > Supports ACPI Specification Revision 3.0a > ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 > keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes > 873 named objects 2398 executable opcodes > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 > Optimizations > > I have placed the aml-file received as a result of operation in > /boot and have registered it in loader.conf. > > [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf > acpi_dsdt_load="YES" > acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" > > After system reboot, hard disks as have not found out. In the > console following errors are output. > > acpi0: om motherboard > ACPI Error (evregion-0427): No handler for Region [ERAM] > (0xc69cde80) [EmbeddedControl] [20070320] > ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler > [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST > ACPI Error (psparse-0626): Method parse/execution failed > [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > ... > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (irq) > unknown: can't assign resources (port) > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (irq) > > That the system has successfully booted it is required to apply the > following file. (dsdt_SB600_addon.diff) > (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl > dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> > dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date > Why it occurs and how it to fix? > > http://pma.8855.ru/files/dsdt_SB600.dsl > http://pma.8855.ru/files/dsdt_SB600.diff > http://pma.8855.ru/files/dsdt_SB600_addon.diff I think you commented out too much. ;-) Please try the attached patch for DSDT instead. Jung-uk Kim --Boundary-00=_jL0/Jil2dSzr+vi Content-Type: text/plain; charset="iso-8859-1"; name="dsdt_SB600.dsl.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dsdt_SB600.dsl.diff" --- dsdt_SB600.dsl.orig 2009-05-04 15:04:08.000000000 -0400 +++ dsdt_SB600.dsl 2009-05-04 15:10:56.000000000 -0400 @@ -278,6 +278,11 @@ Notify (\_SB.PCI0, 0x00) \_SB.HSWK (Arg0) + Return (Package (0x02) + { + Zero, + Zero + }) } Scope (\_SB) @@ -1773,6 +1778,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AF07, 0, NotSerialized) @@ -1806,6 +1812,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AFN1, 1, Serialized) @@ -5810,7 +5817,7 @@ } OperationRegion (ECRM, EmbeddedControl, 0x00, 0xFF) - Field (ECRM, AnyAcc, Lock, Preserve) + Field (ECRM, ByteAcc, Lock, Preserve) { Offset (0x94), ERIB, 16, @@ -6906,6 +6913,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AF07, 0, NotSerialized) @@ -6939,6 +6947,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AFN1, 1, Serialized) --Boundary-00=_jL0/Jil2dSzr+vi-- From owner-freebsd-acpi@FreeBSD.ORG Mon May 4 19:51:32 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D6EFD106566B; Mon, 4 May 2009 19:51:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Mon, 4 May 2009 15:51:16 -0400 User-Agent: KMail/1.6.2 References: <49FE2452.4000401@root.org> In-Reply-To: <49FE2452.4000401@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905041551.19904.jkim@FreeBSD.org> Cc: "Moore, Robert" Subject: Re: [Fwd: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:51:33 -0000 On Sunday 03 May 2009 07:10 pm, Nate Lawson wrote: > Wonder what you thought of this patch to avoid Aliases in > AcpiWalkNamespace()? I believe it was fixed in the vendor source differently since ACPI-CA 20071019 if I am not mistaken: http://git.moblin.org/cgit.cgi/acpica/commit/?id=1e8f03866122dc06146879c9d4d4ad8bb408b60e Jung-uk Kim > -------- Original Message -------- > Subject: kern/134192: [patch] [acpi] don't probe acpi(4) children > that are aliases of other nodes > Resent-Date: Sun, 3 May 2009 19:50:01 GMT > Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) > Resent-To: freebsd-bugs@FreeBSD.org > Resent-CC: jkim@freebsd.org, njl@freebsd.org > Date: Sun, 3 May 2009 23:41:28 +0400 (MSD) > From: Eygene Ryabinkin > Reply-To: Eygene Ryabinkin > To: FreeBSD-gnats-submit@freebsd.org > > >Number: 134192 > >Category: kern > >Synopsis: [patch] [acpi] don't probe acpi(4) children that > > are aliases of other nodes Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun May 03 19:50:00 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Eygene Ryabinkin > >Release: FreeBSD 7.1-STABLE amd64 > >Organization: > > Code Labs > > >Environment: > > System: FreeBSD 7.1-STABLE amd64 > > >Description: > > Some vendors (in my case, Asus) like to create aliases for node > names in the DSDT table: > ----- > Scope (_PR) > { > Processor (P001, 0x01, 0x00000810, 0x06) {} > Alias (P001, CPU1) > Processor (P002, 0x02, 0x00000000, 0x00) {} > Alias (P002, CPU2) > Processor (P003, 0x03, 0x00000000, 0x00) {} > Alias (P003, CPU3) > Processor (P004, 0x04, 0x00000000, 0x00) {} > Alias (P004, CPU4) > } > ----- > Another example (from Asus system too) is presented in the patch > below. > > Since AcpiWalkNamespace treats CPUX as the real Processor objects, > the probe order for acpi(4) bus children will be P001, CPU1, P002, > CPU2, P003, CPU3, P004, CPU4. This is very bad, because half of > processors are attached twice and half -- aren't attached at all. > Moreover, est (Enhanced SpeedStep cpufreq driver) isn't able to get > _PSS for CPUX, so P-states will be missing for half of processors. > > >How-To-Repeat: > > Insert Alias() instruction to your custom DSDT and try to use it, > enabling debug that will show what ACPI nodes are attached to cpuX > device nodes. > > >Fix: > > The following patch adds ACPI namespace walking procedure that > skips nodes that are results of the Alias() operator invocation. > This new method is used for probing of acpi(4) bus members. > > The patch works on two machines of mine that have these annoying > Alias() calls in the _PR namespace. > > I had tried this patch both on 7.x and 8-CURRENT. > > --- ACPI-attach-children-without-aliases.diff begins here --- > > >From f70d0d754f381735a67a42be91fa7253b19a5c8c Mon Sep 17 00:00:00 > > 2001 > > From: Eygene Ryabinkin > Date: Sun, 3 May 2009 22:00:20 +0400 > > ...and use this function to probe acpi(4) children. > > The rationale is very simple: some BIOS vendors, in my case it was > Asus, like to create aliased nodes in the namespaces that will be > walked by the acpi bus method that attaches children to the bus. > > In my particular case, the problem lied in the Processor objects: > ----- > Scope (_PR) > { > Processor (P001, 0x01, 0x00000810, 0x06) {} > Alias (P001, CPU1) > } > > Scope (_PR) > { > Processor (P002, 0x02, 0x00000810, 0x06) {} > Alias (P002, CPU2) > } > ----- > The thing is that the simple walk routine treated CPU1 and CPU2 as > real processors and order of attachment was P001, CPU1, P002, CPU2. > Thus, the second CPU was never attached, first was attached twice > and est (Enhanced SpeedStep cpufreq(4) driver) was failing to get > _PSS (processor P-states) from the CPU1. > > I greatly doubt that some real devices will be ever created as > aliases, since they should be real objects and not modified copies > of other device instances. And since ASL Alias() semantics is to > provide pseudonym, this modification should be "The Good Thing > (tm)". > > Signed-off-by: Eygene Ryabinkin > --- > sys/contrib/dev/acpica/aclocal.h | 1 + > sys/contrib/dev/acpica/acnamesp.h | 1 + > sys/contrib/dev/acpica/acpixf.h | 9 +++++ > sys/contrib/dev/acpica/excreate.c | 3 ++ > sys/contrib/dev/acpica/nswalk.c | 10 ++++- > sys/contrib/dev/acpica/nsxfeval.c | 69 > ++++++++++++++++++++++++++++++++++--- > sys/dev/acpica/acpi.c | 18 +++++---- > 7 files changed, 96 insertions(+), 15 deletions(-) > > diff --git a/sys/contrib/dev/acpica/aclocal.h > b/sys/contrib/dev/acpica/aclocal.h > index ba1145e..73e1568 100644 > --- a/sys/contrib/dev/acpica/aclocal.h > +++ b/sys/contrib/dev/acpica/aclocal.h > @@ -301,6 +301,7 @@ typedef struct acpi_namespace_node > #define ANOBJ_METHOD_ARG 0x04 /* Node is a > method argument */ > #define ANOBJ_METHOD_LOCAL 0x08 /* Node is a > method local */ > #define ANOBJ_SUBTREE_HAS_INI 0x10 /* Used to > optimize device initialization */ > +#define ANOBJ_IS_ALIAS 0x20 /* Node is an > alias to another one */ > > #define ANOBJ_IS_EXTERNAL 0x08 /* iASL only: This > object created via External() */ > #define ANOBJ_METHOD_NO_RETVAL 0x10 /* iASL only: > Method has no return value */ > diff --git a/sys/contrib/dev/acpica/acnamesp.h > b/sys/contrib/dev/acpica/acnamesp.h > index 8d07fb3..52a50bb 100644 > --- a/sys/contrib/dev/acpica/acnamesp.h > +++ b/sys/contrib/dev/acpica/acnamesp.h > @@ -146,6 +146,7 @@ > #define ACPI_NS_WALK_NO_UNLOCK 0 > #define ACPI_NS_WALK_UNLOCK 0x01 > #define ACPI_NS_WALK_TEMP_NODES 0x02 > +#define ACPI_NS_WALK_SKIP_ALIASES 0x04 > > > /* > diff --git a/sys/contrib/dev/acpica/acpixf.h > b/sys/contrib/dev/acpica/acpixf.h > index f85fd67..3757ad0 100644 > --- a/sys/contrib/dev/acpica/acpixf.h > +++ b/sys/contrib/dev/acpica/acpixf.h > @@ -238,6 +238,15 @@ AcpiWalkNamespace ( > void **ReturnValue); > > ACPI_STATUS > +AcpiWalkNamespaceNoAliases ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue); > + > +ACPI_STATUS > AcpiGetDevices ( > char *HID, > ACPI_WALK_CALLBACK UserFunction, > diff --git a/sys/contrib/dev/acpica/excreate.c > b/sys/contrib/dev/acpica/excreate.c > index d237dab..dba8312 100644 > --- a/sys/contrib/dev/acpica/excreate.c > +++ b/sys/contrib/dev/acpica/excreate.c > @@ -221,6 +221,9 @@ AcpiExCreateAlias ( > break; > } > > + /* Mark object as alias, so alias creation could be detected > */ + AliasNode->Flags |= ANOBJ_IS_ALIAS; > + > /* Since both operands are Nodes, we don't need to delete them > */ > > return_ACPI_STATUS (Status); > diff --git a/sys/contrib/dev/acpica/nswalk.c > b/sys/contrib/dev/acpica/nswalk.c > index a3ac86c..9cbc56d 100644 > --- a/sys/contrib/dev/acpica/nswalk.c > +++ b/sys/contrib/dev/acpica/nswalk.c > @@ -208,8 +208,7 @@ AcpiNsGetNextNode ( > * PARAMETERS: Type - ACPI_OBJECT_TYPE to search > for * StartNode - Handle in namespace where > search begins > * MaxDepth - Depth to which search is to > reach - * Flags - Whether to unlock the > NS before invoking > - * the callback routine > + * Flags - Flags that modify walk > parameters * UserFunction - Called when an > object of "Type" is found > * Context - Passed to user function > * ReturnValue - from the UserFunction if > terminated early. > @@ -300,6 +299,13 @@ AcpiNsWalkNamespace ( > Status = AE_CTRL_DEPTH; > } > > + /* Skip nodes created by Alias() routines if it was > requested */ > + else if ((ChildNode->Flags & ANOBJ_IS_ALIAS) && > + (Flags & ACPI_NS_WALK_SKIP_ALIASES)) > + { > + Status = AE_CTRL_DEPTH; > + } > + > /* Type must match requested type */ > > else if (ChildType == Type) > diff --git a/sys/contrib/dev/acpica/nsxfeval.c > b/sys/contrib/dev/acpica/nsxfeval.c > index 617002c..662a9df 100644 > --- a/sys/contrib/dev/acpica/nsxfeval.c > +++ b/sys/contrib/dev/acpica/nsxfeval.c > @@ -122,6 +122,16 @@ > #include > #include > > +static ACPI_STATUS > +_AcpiWalkNamespace ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue, > + UINT32 AddFlags); > + > > #define _COMPONENT ACPI_NAMESPACE > ACPI_MODULE_NAME ("nsxfeval") > @@ -491,11 +501,62 @@ AcpiWalkNamespace ( > void *Context, > void **ReturnValue) > { > - ACPI_STATUS Status; > + ACPI_FUNCTION_TRACE (AcpiWalkNamespace); > > + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, > + UserFunction, Context, ReturnValue, 0); > +} > > - ACPI_FUNCTION_TRACE (AcpiWalkNamespace); > +ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) > > +/***************************************************************** >************** + * > + * FUNCTION: AcpiWalkNamespaceNoAliases > + * > + * DESCRIPTION: The same as AcpiWalkNamespace, but skips nodes > that were + * created as the result of an Alias > function. + * > + * NOTE: for parameters/semantics see AcpiWalkNamespace. > + * > + > ******************************************************************* >***********/ + > +ACPI_STATUS > +AcpiWalkNamespaceNoAliases ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue) > +{ > + ACPI_FUNCTION_TRACE (AcpiWalkNamespaceNoAliases); > + > + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, > + UserFunction, Context, ReturnValue, > ACPI_NS_WALK_SKIP_ALIASES); +} > + > +ACPI_EXPORT_SYMBOL (AcpiWalkNamespaceNoAliases) > + > +/***************************************************************** >************** + * > + * FUNCTION: _AcpiWalkNamespace > + * > + * DESCRIPTION: Internal helper for AcpiWalkNamespace and > + * AcpiWalkNamespaceNoAliases. > + * > + > ******************************************************************* >***********/ + > +static ACPI_STATUS > +_AcpiWalkNamespace ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue, > + UINT32 AddFlags) > +{ > + ACPI_STATUS Status; > > /* Parameter validation */ > > @@ -519,15 +580,13 @@ AcpiWalkNamespace ( > } > > Status = AcpiNsWalkNamespace (Type, StartObject, MaxDepth, > - ACPI_NS_WALK_UNLOCK, > + AddFlags | ACPI_NS_WALK_UNLOCK, > UserFunction, Context, ReturnValue); > > (void) AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE); > return_ACPI_STATUS (Status); > } > > -ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) > - > > > /****************************************************************** >************* * > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c > index d79b413..18a9800 100644 > --- a/sys/dev/acpica/acpi.c > +++ b/sys/dev/acpica/acpi.c > @@ -1528,7 +1528,7 @@ acpi_device_scan_children(device_t bus, > device_t dev, int max_depth, > ctx.user_fn = user_fn; > ctx.arg = arg; > ctx.parent = h; > - return (AcpiWalkNamespace(ACPI_TYPE_ANY, h, max_depth, > + return (AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, h, > max_depth, acpi_device_scan_cb, &ctx, NULL)); > } > > @@ -1648,14 +1648,16 @@ acpi_probe_children(device_t bus) > * Scan the namespace and insert placeholders for all the > devices that * we find. We also probe/attach any early devices. > * > - * Note that we use AcpiWalkNamespace rather than > AcpiGetDevices because > - * we want to create nodes for all devices, not just those > that are - * currently present. (This assumes that we don't > want to create/remove - * devices as they appear, which might > be smarter.) > + * Note that we use AcpiWalkNamespaceNoAliases rather than > + * AcpiGetDevices because we want to create nodes for all > devices, + * not just those that are currently present. (This > assumes that we + * don't want to create/remove devices as they > appear, which might + * be smarter.) We avoid counting aliased > nodes, because we generally + * want to attach only to a > "genuine" devices. > */ > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "namespace scan\n")); > - AcpiWalkNamespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, > acpi_probe_child, > - bus, NULL); > + AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, > 100, + acpi_probe_child, bus, NULL); > > /* Pre-allocate resources for our rman from any sysresource > devices. */ acpi_sysres_alloc(bus); > @@ -2794,7 +2796,7 @@ acpi_wake_prep_walk(int sstate) > ACPI_HANDLE sb_handle; > > if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, "\\_SB_", > &sb_handle))) > - AcpiWalkNamespace(ACPI_TYPE_DEVICE, sb_handle, 100, > + AcpiWalkNamespaceNoAliases(ACPI_TYPE_DEVICE, sb_handle, 100, > acpi_wake_prep, &sstate, NULL); > return (0); > } > -- > 1.6.2.4 > --- ACPI-attach-children-without-aliases.diff ends here --- > > >Release-Note: > >Audit-Trail: > >Unformatted: From owner-freebsd-acpi@FreeBSD.ORG Mon May 4 21:26:11 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9B04106568C for ; Mon, 4 May 2009 21:26:11 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2A78FC12 for ; Mon, 4 May 2009 21:26:10 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: by fxm6 with SMTP id 6so4060812fxm.43 for ; Mon, 04 May 2009 14:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:organization:to :subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=l0lhDIryZr0uSVIiEOHSZZ8kgy5EeTWepeeWf5whLis=; b=R3Lmcn2ab1n85+woxB1MAHZJCxr4HF4YJqQ0yY5jXFpLNhQw/lbPxSO6T/pLj7Ipil KwgqLUE1MOhNQ7vjkzqOrdqr4ccygYpAlT4/Lh1JsUjNIZA7ccLdxkuKBJdNTxtG547t 9LJgAOh3Vak9sGHBDU5dtTG4edvraclNmEZ88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=XKGJZP98iT+xDuRRgtc6lpu5KuwjFtbx+5j5U2Y8deJj9mRz9pfqc/ylVCGMfzz8GP 3Inx12HD67Y78mdKd8GPXWR6J73k0d9AlZ98mZ/bCaldlb3xwOfVud7nMIa4N9JX+TS0 fHhC8UEfA3ToD4wGbtKS+h2CZKtb0RmoJNFTA= Received: by 10.103.246.1 with SMTP id y1mr3837102mur.120.1241470937420; Mon, 04 May 2009 14:02:17 -0700 (PDT) Received: from onyx_hp.dhcp.loc ([92.50.244.68]) by mx.google.com with ESMTPS id i5sm17361128mue.55.2009.05.04.14.02.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 14:02:16 -0700 (PDT) From: Dmitry Kolosov Organization: Home To: freebsd-acpi@freebsd.org Date: Tue, 5 May 2009 01:00:00 +0400 User-Agent: KMail/1.11.2 (FreeBSD/7.2-PRERELEASE; KDE/4.2.2; i386; ; ) References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> <49FE64C5.2020507@FreeBSD.org> In-Reply-To: <49FE64C5.2020507@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905050100.00739.ivakras1@gmail.com> Subject: Re: Fighting for the power. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivakras1@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:26:12 -0000 On =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 04 =CD=C1=D1 2009 07:45:09 Alexander M= otin wrote: > Adam McDougall wrote: > > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > >=20 > > I would like to summarize some of my knowledge on reducing FreeBSD po= wer > > 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, un= der > > amd64 8-CURRENT. > > =20 > > 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=20 > > 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" >=20 > Yes, backlight is also important. But there is not so much things could=20 > be done. >=20 > When I am leaving system for some time, I can just close the lid, if not= =20 > put system into S3 state, which require very small power (at least I was= =20 > unable to really measure it without all-day-long testing). Thanks to=20 > jkim@ we have more or less working S3 state for amd64 now. >=20 I'm using sysctl to controll brightness of my lcd (wrongly marked as crt by= sysctl, but it works fine): hw.acpi.video.crt1.brightness: 95 - current brightness of lcd (crt) hw.acpi.video.crt1.fullpower: 95 - top level of brightness set by acpi_vide= o if AC plugged hw.acpi.video.crt1.economy: 43 - bottom level of brightness set by acpi_vid= eo if AC unplugged hw.acpi.video.crt1.levels: 95 43 20 24 28 32 37 43 50 59 69 81 95 - various= brightness levels can be set manual by sysctl It works fine for me, and it's easy to write a script to react on different= events during a day. From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 07:27:22 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7CF1065672 for ; Tue, 5 May 2009 07:27:22 +0000 (UTC) (envelope-from patttern@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 421D58FC21 for ; Tue, 5 May 2009 07:27:21 +0000 (UTC) (envelope-from patttern@gmail.com) Received: by bwz9 with SMTP id 9so4239364bwz.43 for ; Tue, 05 May 2009 00:27:21 -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:content-type; bh=evYFoITHOmYld3R50/TsMv0/6AIKi55lL+KclILWRfE=; b=tU5F2Xp2ziZj06FkvknN6M4mg4kdiGr8bNHFILhp/jh/0AaBOv2yLuKPx7TKV9TP/w MSewWefujgCvwruahyUJTD0iDTNRV8DQTqjyUKa9M4xPlMednIw4Rgegh2MqXaWqj9Xz QawGo7mL07IWGMqIjf+ybUmpyI6+5u6e+cZeA= 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 :content-type; b=i0qlhu/7kTbf57k8hHonho0nKxMGe4fUrOjAR39CZ8HVzSyy1YXXpo57O6PcTEBtVO EHcEQtccul0sKgT/cQhvscXEc9HFnDAzNlo2wr+jKC3dqJ51Iw8B0193n0IlqlNPCseZ yK2/fMl92+jN1Vr5knHTbahNbWVMhYxHnUSyk= MIME-Version: 1.0 Received: by 10.204.62.135 with SMTP id x7mr6651789bkh.124.1241508439721; Tue, 05 May 2009 00:27:19 -0700 (PDT) In-Reply-To: <200905041532.52001.jkim@FreeBSD.org> References: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> <200905041532.52001.jkim@FreeBSD.org> Date: Tue, 5 May 2009 11:27:19 +0400 Message-ID: <107cc88f0905050027t32a1d1fegf94882b0e0d5e9b1@mail.gmail.com> From: Pattern To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ACPI on Toshiba A210 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:27:23 -0000 2009/5/4 Jung-uk Kim > On Monday 04 May 2009 09:21 am, Pattern wrote: > > Hi! > > I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. > > At loading FreeBSD by default, the system does not detect hard > > disks. Through acpidump i have received a dsl-file. > > (dsdt_SB600.dsl) After considerable editing of a file, i have > > received a file without errors. (dsdt_SB600.diff) > > Result of operation iasl: > > > > [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl > > Intel ACPI Component Architecture > > ASL Optimizing Compiler version 20070320 [Mar 31 2009] > > Copyright (C) 2000 - 2007 Intel Corporation > > Supports ACPI Specification Revision 3.0a > > ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 > > keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes > > 873 named objects 2398 executable opcodes > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 > > Optimizations > > > > I have placed the aml-file received as a result of operation in > > /boot and have registered it in loader.conf. > > > > [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf > > acpi_dsdt_load="YES" > > acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" > > > > After system reboot, hard disks as have not found out. In the > > console following errors are output. > > > > acpi0: om motherboard > > ACPI Error (evregion-0427): No handler for Region [ERAM] > > (0xc69cde80) [EmbeddedControl] [20070320] > > ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler > > [20070320] > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST > > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > > ... > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (irq) > > unknown: can't assign resources (port) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (irq) > > > > That the system has successfully booted it is required to apply the > > following file. (dsdt_SB600_addon.diff) > > (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl > > dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> > > dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date > > Why it occurs and how it to fix? > > > > http://pma.8855.ru/files/dsdt_SB600.dsl > > http://pma.8855.ru/files/dsdt_SB600.diff > > http://pma.8855.ru/files/dsdt_SB600_addon.diff > > I think you commented out too much. ;-) Please try the attached patch > for DSDT instead. > > Jung-uk Kim > Thanks for your answer. Patch (dsdt_SB600.diff ) is corrected with optimisation and in it changes which you have specified already contain. But these minimum changes don't troubleshoot ACPI, but only allow to load system with ACPI. It was possible to load system in a mode "ACPI disabled" and not to do any changes. But i wish to make working support ACPI on a notebook. In fact, the first patch after compilation does not contain any error (!!!), but nevertheless the system does not boot. And if to apply patch dsdt_SB600_addon.diff or comment a code below, only after that the system boots. Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, Z00B) } \_SB.HTEV (0x02) } This code as that influences initialization EmbeddedControl. However, even without this code, sometimes in the console the error on EmbeddedControl drops out, but the system successfully boots. What such problem can be linked? From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 09:30:36 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385B3106564A; Tue, 5 May 2009 09:30:36 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id B9B898FC0A; Tue, 5 May 2009 09:30:35 +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 fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n459JJBj029564; Tue, 5 May 2009 19:19:19 +1000 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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:30:36 -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-acpi@FreeBSD.ORG Tue May 5 16:45:48 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F93106566B; Tue, 5 May 2009 16:45:48 +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 DAD2A8FC0A; Tue, 5 May 2009 16:45:46 +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 TAA23083; Tue, 05 May 2009 19:45:44 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006D38.50901@icyb.net.ua> Date: Tue, 05 May 2009 19:45:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> In-Reply-To: <200905011501.40083.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:45:48 -0000 on 01/05/2009 22:01 John Baldwin said the following: > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it is > a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks > protecting the idle registers need to use spin locks instead. The problem with > blocking in the idle thread is that the scheduler assumes (even requires) that > the idle thread is _always_ runnable. Very interesting! So it seems that we are not having more of such crashes by a pure luck (low probability)? Looking at the method's signature: ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) I think that the name of the parameter type is a big hint. Further, looking into ACPICA reference document: > Wait for and acquire a spin lock. May be called from interrupt handlers, GPE > handlers, and Fixed event handlers. Single threaded OSL implementations should > always return AE_OK for this interface. P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be outdated/bogus too - first of all there is no Flags parameter (it's actualy a return value "to be used when lock is released") and, second, having ithreads is no excuse to not care about type of blocking, and the term 'blocking' is used incorrectly too: /* * The Flags parameter seems to state whether or not caller is an ISR * (and thus can't block) but since we have ithreads, we don't worry * about potentially blocking. */ -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 16:51:42 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6569C106564A; Tue, 5 May 2009 16:51:42 +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 058598FC1E; Tue, 5 May 2009 16:51:40 +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 TAA23148; Tue, 05 May 2009 19:51:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006E9A.7060806@icyb.net.ua> Date: Tue, 05 May 2009 19:51:38 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin , Jung-uk Kim References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> <4A006D38.50901@icyb.net.ua> In-Reply-To: <4A006D38.50901@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:51:43 -0000 BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. on 05/05/2009 19:45 Andriy Gapon said the following: > on 01/05/2009 22:01 John Baldwin said the following: >> The trace actually ends here. There is nothing super bad here but there is a >> big problem actually in that the idle threads cannot block on a lock, so it is >> a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks >> protecting the idle registers need to use spin locks instead. The problem with >> blocking in the idle thread is that the scheduler assumes (even requires) that >> the idle thread is _always_ runnable. > > > Very interesting! So it seems that we are not having more of such crashes by a > pure luck (low probability)? > > Looking at the method's signature: > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > I think that the name of the parameter type is a big hint. > > Further, looking into ACPICA reference document: >> Wait for and acquire a spin lock. May be called from interrupt handlers, GPE >> handlers, and Fixed event handlers. Single threaded OSL implementations should >> always return AE_OK for this interface. > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be > outdated/bogus too - first of all there is no Flags parameter (it's actualy a > return value "to be used when lock is released") and, second, having ithreads is > no excuse to not care about type of blocking, and the term 'blocking' is used > incorrectly too: > /* > * The Flags parameter seems to state whether or not caller is an ISR > * (and thus can't block) but since we have ithreads, we don't worry > * about potentially blocking. > */ > > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 20:09:46 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A88981065676; Tue, 5 May 2009 20:09:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 5 May 2009 16:09:35 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> In-Reply-To: <4A006E9A.7060806@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905051609.38689.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:09:47 -0000 On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > newer acpica imports, but it is not fixed both in stable/7 and > head. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) Jung-uk Kim > on 05/05/2009 19:45 Andriy Gapon said the following: > > on 01/05/2009 22:01 John Baldwin said the following: > >> The trace actually ends here. There is nothing super bad here > >> but there is a big problem actually in that the idle threads > >> cannot block on a lock, so it is a problem for the ACPI code to > >> be acquiring a mutex here. Perhaps the locks protecting the > >> idle registers need to use spin locks instead. The problem with > >> blocking in the idle thread is that the scheduler assumes (even > >> requires) that the idle thread is _always_ runnable. > > > > Very interesting! So it seems that we are not having more of such > > crashes by a pure luck (low probability)? > > > > Looking at the method's signature: > > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > > I think that the name of the parameter type is a big hint. > > > > Further, looking into ACPICA reference document: > >> Wait for and acquire a spin lock. May be called from interrupt > >> handlers, GPE handlers, and Fixed event handlers. Single > >> threaded OSL implementations should always return AE_OK for this > >> interface. > > > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 > > code) seems to be outdated/bogus too - first of all there is no > > Flags parameter (it's actualy a return value "to be used when > > lock is released") and, second, having ithreads is no excuse to > > not care about type of blocking, and the term 'blocking' is used > > incorrectly too: > > /* > > * The Flags parameter seems to state whether or not caller is an > > ISR * (and thus can't block) but since we have ithreads, we don't > > worry * about potentially blocking. > > */ From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 20:23:30 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A1461065673; Tue, 5 May 2009 20:23:30 +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 2AE368FC08; Tue, 5 May 2009 20:23:30 +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 C153F46B09; Tue, 5 May 2009 16:23:29 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [127.0.0.1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 24E518A022; Tue, 5 May 2009 16:23:28 -0400 (EDT) Message-ID: <4A00A042.20806@FreeBSD.org> Date: Tue, 05 May 2009 16:23:30 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jung-uk Kim References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> 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:23:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 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: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:23:31 -0000 Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for >> newer acpica imports, but it is not fixed both in stable/7 and >> head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock for > AcpiOsAcquireLock(). :-) I'm not sure all ACPI locks need to be spin locks, but any locks used by the idle code must be spin locks. Regardless, are you going to import a newer ACPI-CA and commit your patches soon? It sounds like several things are fixed in the outstanding patches by now including both this and the problem with the Alias() operator. > Jung-uk Kim > >> on 05/05/2009 19:45 Andriy Gapon said the following: >>> on 01/05/2009 22:01 John Baldwin said the following: >>>> The trace actually ends here. There is nothing super bad here >>>> but there is a big problem actually in that the idle threads >>>> cannot block on a lock, so it is a problem for the ACPI code to >>>> be acquiring a mutex here. Perhaps the locks protecting the >>>> idle registers need to use spin locks instead. The problem with >>>> blocking in the idle thread is that the scheduler assumes (even >>>> requires) that the idle thread is _always_ runnable. >>> Very interesting! So it seems that we are not having more of such >>> crashes by a pure luck (low probability)? >>> >>> Looking at the method's signature: >>> ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) >>> I think that the name of the parameter type is a big hint. >>> >>> Further, looking into ACPICA reference document: >>>> Wait for and acquire a spin lock. May be called from interrupt >>>> handlers, GPE handlers, and Fixed event handlers. Single >>>> threaded OSL implementations should always return AE_OK for this >>>> interface. >>> P.S. the comment before AcpiOsAcquireLock function (in stable/7 >>> code) seems to be outdated/bogus too - first of all there is no >>> Flags parameter (it's actualy a return value "to be used when >>> lock is released") and, second, having ithreads is no excuse to >>> not care about type of blocking, and the term 'blocking' is used >>> incorrectly too: >>> /* >>> * The Flags parameter seems to state whether or not caller is an >>> ISR * (and thus can't block) but since we have ithreads, we don't >>> worry * about potentially blocking. >>> */ -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 20:56:35 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5B6A51065673; Tue, 5 May 2009 20:56:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Tue, 5 May 2009 16:56:25 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org> <4A00A042.20806@FreeBSD.org> In-Reply-To: <4A00A042.20806@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905051656.27439.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org, Alan Amesbury , Andriy Gapon Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:56:35 -0000 On Tuesday 05 May 2009 04:23 pm, John Baldwin wrote: > Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for > >> newer acpica imports, but it is not fixed both in stable/7 and > >> head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > I'm not sure all ACPI locks need to be spin locks, but any locks > used by the idle code must be spin locks. There are several types of ACPI locks internally and externally. The AcpiOs{Create,Acquire,Release}Lock() is just one of them, which is a spin lock and it is mostly used for interrupt handlers, e.g., GPE and HW. I have to say there were a lot of confusions between ACPI developers because it was not well-documented. In fact, I personally had to exchange lengthy e-mails with Intel engineers to understand the meaning of these myself. Now Intel has documented everything you need to know about ACPI-CA for OS developers: http://git.moblin.org/cgit.cgi/acpica/tree/documents > Regardless, are you going to import a newer ACPI-CA and commit your > patches soon? It sounds like several things are fixed in the > outstanding patches by now including both this and the problem with > the Alias() operator. Unfortunately, I don't have much time to work on it recently. Couple of developers volunteered to do the actual import work although I haven't heard from them in a while. :-( Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 21:43:11 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 35A381065679; Tue, 5 May 2009 21:43:11 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 5 May 2009 17:43:01 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_nLLAKMdakiVOZxJ" Message-Id: <200905051743.03520.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:43:12 -0000 --Boundary-00=_nLLAKMdakiVOZxJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > newer acpica imports, but it is not fixed both in stable/7 and > > head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock > for AcpiOsAcquireLock(). :-) The attached patch is for -STABLE. Note that it is only compile tested on amd64. Jung-uk Kim --Boundary-00=_nLLAKMdakiVOZxJ Content-Type: text/plain; charset="iso-8859-1"; name="OsdSynch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="OsdSynch.diff" --- sys/dev/acpica/Osd/OsdSynch.c (revision 191834) +++ sys/dev/acpica/Osd/OsdSynch.c (working copy) @@ -1,6 +1,7 @@ /*- * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi + * Copyright (c) 2007-2009 Jung-uk Kim * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -35,365 +36,313 @@ #include #include "opt_acpi.h" +#include #include -#include -#include #include +#include #include +#include -#define _COMPONENT ACPI_OS_SERVICES +#define _COMPONENT ACPI_OS_SERVICES ACPI_MODULE_NAME("SYNCH") MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore"); -#define AS_LOCK(as) mtx_lock(&(as)->as_mtx) -#define AS_UNLOCK(as) mtx_unlock(&(as)->as_mtx) +/* Convert microseconds to hz. */ +static int +timeout2hz(long timo) +{ + struct timeval tv; + tv.tv_sec = timo / 1000000; + tv.tv_usec = timo % 1000000; + + return (tvtohz(&tv)); +} + +/* Adjust timeout from the previous uptime. */ +static long +adjust_timeout(long *tmop, struct timeval *tvp) +{ + struct timeval now, slept; + + getmicrouptime(&now); + slept = now; + timevalsub(&slept, tvp); + *tmop -= slept.tv_sec * 1000000 + slept.tv_usec; + *tvp = now; + + return (*tmop); +} + /* - * Simple counting semaphore implemented using a mutex. (Subsequently used - * in the OSI code to implement a mutex. Go figure.) + * ACPI_SEMAPHORE: a sleepable counting semaphore */ struct acpi_semaphore { - struct mtx as_mtx; - UINT32 as_units; - UINT32 as_maxunits; - UINT32 as_pendings; - UINT32 as_resetting; - UINT32 as_timeouts; + struct sx as_lock; + char as_name[32]; + struct cv as_cv; + UINT32 as_units; + UINT32 as_maxunits; }; -/* Default number of maximum pending threads. */ -#ifndef ACPI_NO_SEMAPHORES -#ifndef ACPI_SEMAPHORES_MAX_PENDING -#define ACPI_SEMAPHORES_MAX_PENDING 4 -#endif - -static int acpi_semaphore_debug = 0; -TUNABLE_INT("debug.acpi_semaphore_debug", &acpi_semaphore_debug); -SYSCTL_DECL(_debug_acpi); -SYSCTL_INT(_debug_acpi, OID_AUTO, semaphore_debug, CTLFLAG_RW, - &acpi_semaphore_debug, 0, "Enable ACPI semaphore debug messages"); -#endif /* !ACPI_NO_SEMAPHORES */ - ACPI_STATUS AcpiOsCreateSemaphore(UINT32 MaxUnits, UINT32 InitialUnits, ACPI_SEMAPHORE *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as; + struct acpi_semaphore *as; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (OutHandle == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); - if (InitialUnits > MaxUnits) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (OutHandle == NULL || InitialUnits > MaxUnits) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) - return_ACPI_STATUS (AE_NO_MEMORY); + if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - mtx_init(&as->as_mtx, "ACPI semaphore", NULL, MTX_DEF); - as->as_units = InitialUnits; - as->as_maxunits = MaxUnits; - as->as_pendings = as->as_resetting = as->as_timeouts = 0; + snprintf(as->as_name, sizeof(as->as_name), "ACPI sema (%p)", as); + sx_init(&as->as_lock, as->as_name); + cv_init(&as->as_cv, as->as_name); + as->as_units = InitialUnits; + as->as_maxunits = MaxUnits; - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "created semaphore %p max %d, initial %d\n", - as, InitialUnits, MaxUnits)); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "created semaphore %p, max %u, initial %u\n", + as, InitialUnits, MaxUnits)); - *OutHandle = (ACPI_HANDLE)as; -#else - *OutHandle = (ACPI_HANDLE)OutHandle; -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SEMAPHORE)as; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } ACPI_STATUS AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "destroyed semaphore %p\n", as)); - mtx_destroy(&as->as_mtx); - free(Handle, M_ACPISEM); -#endif /* !ACPI_NO_SEMAPHORES */ + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete semaphore %p\n", as)); - return_ACPI_STATUS (AE_OK); + if (as != NULL) { + sx_destroy(&as->as_lock); + cv_destroy(&as->as_cv); + free(as, M_ACPISEM); + return_ACPI_STATUS (AE_OK); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null semaphore\n")); + + return_ACPI_STATUS (AE_BAD_PARAMETER); } -/* - * This implementation has a bug, in that it has to stall for the entire - * timeout before it will return AE_TIME. A better implementation would - * use getmicrotime() to correctly adjust the timeout after being woken up. - */ ACPI_STATUS AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout) { -#ifndef ACPI_NO_SEMAPHORES - ACPI_STATUS result; - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - int rv, tmo; - struct timeval timeouttv, currenttv, timelefttv; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct timeval tv; + long tmo; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if (cold) - return_ACPI_STATUS (AE_OK); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "get %u units from semaphore %p (has %u), timeout %u\n", + Units, as, as->as_units, Timeout)); -#if 0 - if (as->as_units < Units && as->as_timeouts > 10) { - printf("%s: semaphore %p too many timeouts, resetting\n", __func__, as); - AS_LOCK(as); - as->as_units = as->as_maxunits; - if (as->as_pendings) - as->as_resetting = 1; - as->as_timeouts = 0; - wakeup(as); - AS_UNLOCK(as); - return_ACPI_STATUS (AE_TIME); - } - - if (as->as_resetting) - return_ACPI_STATUS (AE_TIME); -#endif - - /* a timeout of ACPI_WAIT_FOREVER means "forever" */ - if (Timeout == ACPI_WAIT_FOREVER) { - tmo = 0; - timeouttv.tv_sec = ((0xffff/1000) + 1); /* cf. ACPI spec */ - timeouttv.tv_usec = 0; - } else { - /* compute timeout using microseconds per tick */ - tmo = (Timeout * 1000) / (1000000 / hz); - if (tmo <= 0) - tmo = 1; - timeouttv.tv_sec = Timeout / 1000; - timeouttv.tv_usec = (Timeout % 1000) * 1000; - } - - /* calculate timeout value in timeval */ - getmicrotime(¤ttv); - timevaladd(&timeouttv, ¤ttv); - - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "get %d units from semaphore %p (has %d), timeout %d\n", - Units, as, as->as_units, Timeout)); - for (;;) { if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { - result = AE_OK; - break; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } - if (as->as_units >= Units) { - as->as_units -= Units; - result = AE_OK; - break; + if (as->as_maxunits < Units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* limit number of pending threads */ - if (as->as_pendings >= ACPI_SEMAPHORES_MAX_PENDING) { - result = AE_TIME; - break; + switch (Timeout) { + case ACPI_DO_NOT_WAIT: + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + break; + case ACPI_WAIT_FOREVER: + while (as->as_units < Units) + cv_wait(&as->as_cv, &as->as_lock); + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + default: + tmo = (long)Timeout * 1000; + getmicrouptime(&tv); + do { + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + if (cv_timedwait(&as->as_cv, &as->as_lock, + timeout2hz(tmo)) == EWOULDBLOCK) + break; + } while (adjust_timeout(&tmo, &tv) > 0); } + sx_xunlock(&as->as_lock); - /* if timeout values of zero is specified, return immediately */ - if (Timeout == 0) { - result = AE_TIME; - break; - } + return_ACPI_STATUS (AE_TIME); +} - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "semaphore blocked, calling msleep(%p, %p, %d, \"acsem\", %d)\n", - as, &as->as_mtx, PCATCH, tmo)); +ACPI_STATUS +AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +{ + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - as->as_pendings++; + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (acpi_semaphore_debug) { - printf("%s: Sleep %d, pending %d, semaphore %p, thread %d\n", - __func__, Timeout, as->as_pendings, as, AcpiOsGetThreadId()); - } + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - rv = msleep(as, &as->as_mtx, PCATCH, "acsem", tmo); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "return %u units to semaphore %p (has %u)\n", + Units, as, as->as_units)); - as->as_pendings--; - -#if 0 - if (as->as_resetting) { - /* semaphore reset, return immediately */ - if (as->as_pendings == 0) { - as->as_resetting = 0; - } - result = AE_TIME; - break; + if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } -#endif - - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "msleep(%d) returned %d\n", tmo, rv)); - if (rv == EWOULDBLOCK) { - result = AE_TIME; - break; + if (as->as_maxunits < Units || + as->as_maxunits - Units < as->as_units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* check if we already awaited enough */ - timelefttv = timeouttv; - getmicrotime(¤ttv); - timevalsub(&timelefttv, ¤ttv); - if (timelefttv.tv_sec < 0) { - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "await semaphore %p timeout\n", - as)); - result = AE_TIME; - break; - } + as->as_units += Units; + cv_broadcast(&as->as_cv); + sx_xunlock(&as->as_lock); - /* adjust timeout for the next sleep */ - tmo = (timelefttv.tv_sec * 1000000 + timelefttv.tv_usec) / - (1000000 / hz); - if (tmo <= 0) - tmo = 1; - - if (acpi_semaphore_debug) { - printf("%s: Wakeup timeleft(%jd, %lu), tmo %u, sem %p, thread %d\n", - __func__, (intmax_t)timelefttv.tv_sec, timelefttv.tv_usec, tmo, as, - AcpiOsGetThreadId()); - } - } - - if (acpi_semaphore_debug) { - if (result == AE_TIME && Timeout > 0) { - printf("%s: Timeout %d, pending %d, semaphore %p\n", - __func__, Timeout, as->as_pendings, as); - } - if (result == AE_OK && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Acquire %d, units %d, pending %d, sem %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, - AcpiOsGetThreadId()); - } - } - - if (result == AE_TIME) - as->as_timeouts++; - else - as->as_timeouts = 0; - - AS_UNLOCK(as); - return_ACPI_STATUS (result); -#else - return_ACPI_STATUS (AE_OK); -#endif /* !ACPI_NO_SEMAPHORES */ + return_ACPI_STATUS (AE_OK); } +/* + * ACPI_SPINLOCK: a non-sleepable spinlock + */ +struct acpi_spinlock { + struct mtx al_lock; + char al_name[32]; + int al_nested; +}; + ACPI_STATUS -AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +AcpiOsCreateLock(ACPI_SPINLOCK *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_spinlock *al; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS(AE_BAD_PARAMETER); + if (OutHandle == NULL) + return_ACPI_STATUS (AE_BAD_PARAMETER); + al = malloc(sizeof(*al), M_ACPISEM, M_NOWAIT | M_ZERO); + if (al == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "return %d units to semaphore %p (has %d)\n", - Units, as, as->as_units)); - if (as->as_maxunits != ACPI_NO_UNIT_LIMIT) { - as->as_units += Units; - if (as->as_units > as->as_maxunits) - as->as_units = as->as_maxunits; - } + /* Build a unique name based on the address of the handle. */ + if (OutHandle == &AcpiGbl_GpeLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (GPE)"); + else if (OutHandle == &AcpiGbl_HardwareLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (HW)"); + else + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (%p)", + OutHandle); + mtx_init(&al->al_lock, al->al_name, NULL, MTX_SPIN); - if (acpi_semaphore_debug && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Release %d, units %d, pending %d, semaphore %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, AcpiOsGetThreadId()); - } + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "created %s\n", al->al_name)); - wakeup(as); - AS_UNLOCK(as); -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SPINLOCK)al; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } -/* Combined mutex + mutex name storage since the latter must persist. */ -struct acpi_spinlock { - struct mtx lock; - char name[32]; -}; - -ACPI_STATUS -AcpiOsCreateLock (ACPI_SPINLOCK *OutHandle) +void +AcpiOsDeleteLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (OutHandle == NULL) - return (AE_BAD_PARAMETER); - h = malloc(sizeof(*h), M_ACPISEM, M_NOWAIT | M_ZERO); - if (h == NULL) - return (AE_NO_MEMORY); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - /* Build a unique name based on the address of the handle. */ - if (OutHandle == &AcpiGbl_GpeLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem GPE lock"); - else if (OutHandle == &AcpiGbl_HardwareLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock"); - else - snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle); - mtx_init(&h->lock, h->name, NULL, MTX_DEF); - *OutHandle = (ACPI_SPINLOCK)h; - return (AE_OK); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete %s\n", al->al_name)); + + if (al != NULL) { + mtx_destroy(&al->al_lock); + free(al, M_ACPISEM); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null spinlock\n")); } -void -AcpiOsDeleteLock (ACPI_SPINLOCK Handle) +ACPI_CPU_FLAGS +AcpiOsAcquireLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_destroy(&h->lock); - free(h, M_ACPISEM); -} + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); -/* - * The Flags parameter seems to state whether or not caller is an ISR - * (and thus can't block) but since we have ithreads, we don't worry - * about potentially blocking. - */ -ACPI_NATIVE_UINT -AcpiOsAcquireLock (ACPI_SPINLOCK Handle) -{ - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "acquire %s\n", al->al_name)); - if (Handle == NULL) + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + al->al_nested++; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "acquire nested %s, depth %d\n", + al->al_name, al->al_nested)); + } else + mtx_lock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot acquire null spinlock\n")); + return (0); - mtx_lock(&h->lock); - return (0); } void -AcpiOsReleaseLock (ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) +AcpiOsReleaseLock(ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_unlock(&h->lock); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "release %s\n", al->al_name)); + + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + if (al->al_nested > 0) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "release nested %s, depth %d\n", + al->al_name, al->al_nested)); + al->al_nested--; + } else + mtx_unlock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release unowned %s\n", al->al_name)); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release null spinlock\n")); } -/* Section 5.2.9.1: global lock acquire/release functions */ -#define GL_ACQUIRED (-1) -#define GL_BUSY 0 -#define GL_BIT_PENDING 0x1 -#define GL_BIT_OWNED 0x2 -#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) +/* Section 5.2.10.1: global lock acquire/release functions */ +#define GL_ACQUIRED (-1) +#define GL_BUSY 0 +#define GL_BIT_PENDING 0x01 +#define GL_BIT_OWNED 0x02 +#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) /* * Acquire the global lock. If busy, set the pending bit. The caller @@ -403,7 +352,7 @@ int acpi_acquire_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; @@ -422,7 +371,7 @@ int acpi_release_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; --Boundary-00=_nLLAKMdakiVOZxJ-- From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 21:55:56 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Tue May 5 22:44:11 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67368106566C for ; Tue, 5 May 2009 22:44:11 +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 BF0C78FC18 for ; Tue, 5 May 2009 22:44:10 +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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 22:44:11 -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-acpi@FreeBSD.ORG Tue May 5 23:53:00 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09651065676; Tue, 5 May 2009 23:53:00 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-m3.tc.umn.edu (mta-m3.tc.umn.edu [134.84.135.123]) by mx1.freebsd.org (Postfix) with ESMTP id 97A5D8FC23; Tue, 5 May 2009 23:53:00 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from [160.94.247.212] (optimator.oitsec.umn.edu [160.94.247.212]) by mta-m3.tc.umn.edu (UMN smtpd) with ESMTP Tue, 5 May 2009 18:37:59 -0500 (CDT) X-Umn-Remote-Mta: [N] optimator.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU+HN X-Umn-Classification: local Message-ID: <4A00CDD6.4080303@umn.edu> Date: Tue, 05 May 2009 18:37:58 -0500 From: Alan Amesbury User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Jung-uk Kim References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> <200905051743.03520.jkim@FreeBSD.org> In-Reply-To: <200905051743.03520.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 23:53:01 -0000 Jung-uk Kim wrote: > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. The platform in question is 7.1-RELEASE-p5/amd64, and the patch you supplied looks like it applies cleanly to it. While I am unable to pin down the specific trigger of this flaw (the host simply panicked a couple times while under moderate-to-heavy use), I'm willing to apply the patch to the host's current source tree, provided you and John Baldwin are in agreement that it's safe to do so. Note that's not meant to imply I don't trust your coding skills; I'm just not ready to modify production assets without a second look. ;-) Thanks again for your help on this. I appreciate it! -- Alan Amesbury OIT Security and Assurance University of Minnesota From owner-freebsd-acpi@FreeBSD.ORG Thu May 7 06:14:20 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Thu May 7 22:40:48 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E61D106566C for ; Thu, 7 May 2009 22:40:48 +0000 (UTC) (envelope-from lauren@rhodamine.com.au) Received: from rhodamine.com.au (dsl-210-15-212-138-static.VIC.netspace.net.au [210.15.212.138]) by mx1.freebsd.org (Postfix) with ESMTP id 402338FC15 for ; Thu, 7 May 2009 22:40:48 +0000 (UTC) (envelope-from lauren@rhodamine.com.au) Received: by rhodamine.com.au (Postfix, from userid 1036) id 666B321973C6; Fri, 8 May 2009 08:19:14 +1000 (EST) To: freebsd-acpi@freebsd.org From: received@postcard.org Message-Id: <20090507221914.666B321973C6@rhodamine.com.au> Date: Fri, 8 May 2009 08:19:14 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You have just received a virtual postcard from a friend ! X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 22:40:49 -0000 You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http:.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://85.17.150.185/~paco/postcard.gif.exe From owner-freebsd-acpi@FreeBSD.ORG Fri May 8 02:53:22 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1615106566C for ; Fri, 8 May 2009 02:53:22 +0000 (UTC) (envelope-from dsewnr.buffer@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 A69A88FC14 for ; Fri, 8 May 2009 02:53:21 +0000 (UTC) (envelope-from dsewnr.buffer@gmail.com) Received: by bwz9 with SMTP id 9so1125244bwz.43 for ; Thu, 07 May 2009 19:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type; bh=sCmWNorKazZx+C2M/QsqZQT9dq4/rbIomVDVqtc3+zc=; b=Kub4qm39VfsI3BnSELHpW0oCUAlLdRf06clFICBKgAozMCoqx2Ko0x7CIRwsay8OGN sJjwzu+PuR5rwuay5U/JQsgY+sG9ITEVk/o3OZv/TIP0bB0SNt1CTFNlBqmkiN5/7S8Z sShYVHeLPhaFoU9gcMrRfaqriyBLywgmykBmQ= 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 :content-type; b=Bnj3rpzBefSMfDItyB9IlpsnuIZoZ5m4IfEEjYrodamO4XtYNVGmMODS49yG+3dHeZ zD9FG9iQH9feDGoFqcSqzyZqxAc3DsqveuJbJSSXs5U1uepMojysooKpaRO/ueY1Xq8a EWgV4qqjN+luFjW1j3sf8UtJ/wQQez/gbQPjo= Received: by 10.204.121.140 with SMTP id h12mr3052177bkr.70.1241749437332; Thu, 07 May 2009 19:23:57 -0700 (PDT) Received: from dorara.twbbs.org (59-127-33-87.HINET-IP.hinet.net [59.127.33.87]) by mx.google.com with ESMTPS id 21sm484784fkx.30.2009.05.07.19.23.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 19:23:55 -0700 (PDT) Message-ID: <4A0397B2.5000303@gmail.com> Date: Fri, 08 May 2009 10:23:46 +0800 From: Dsewnr Lu User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: multipart/mixed; boundary="------------010207030806030006010706" Subject: acpi problem ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dsewnr.buffer@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 02:53:23 -0000 This is a multi-part message in MIME format. --------------010207030806030006010706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, My command "shutdown -p now" can not poweroff automatically, it halt on the last screen with uptime and my keyboard is hang, too. And "reboot" or "shutdown -h now" work fine. Is it an acpi problem ? There're my kernel config, dmesg and sysctl message. Any idea ? Thanks, Dsewnr Lu --------------010207030806030006010706 Content-Type: text/plain; name="kernel" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="kernel" IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBG cmVlQlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBs ZWFzZSByZWFkIHRoZSBoYW5kYm9vayBzZWN0aW9uIG9uCiMgS2VybmVsIENvbmZpZ3VyYXRp b24gRmlsZXM6CiMKIyAgICBodHRwOi8vd3d3LkZyZWVCU0Qub3JnL2RvYy9lbl9VUy5JU084 ODU5LTEvYm9va3MvaGFuZGJvb2sva2VybmVsY29uZmlnLWNvbmZpZy5odG1sCiMKIyBUaGUg aGFuZGJvb2sgaXMgYWxzbyBhdmFpbGFibGUgbG9jYWxseSBpbiAvdXNyL3NoYXJlL2RvYy9o YW5kYm9vawojIGlmIHlvdSd2ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90 aGVyd2lzZSBhbHdheXMgc2VlIHRoZQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVy IChodHRwOi8vd3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQojIGxhdGVzdCBpbmZvcm1hdGlv bi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVk IGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2UgbGluZXMgaXMgYWxzbyBwcmVzZW50IGlu IHRoZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBmaWxlcy4KIyBJZiB5b3UgYXJlIGlu IGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNr IGZpcnN0CiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogc3JjL3N5cy9hbWQ2NC9jb25mL0dF TkVSSUMsdiAxLjQ4NC4yLjE5LjIuMSAyMDA5LzA0LzE1IDAzOjE0OjI2IGtlbnNtaXRoIEV4 cCAkCgpjcHUJCUhBTU1FUgppZGVudAkJa2VybmVsCgojIFRvIHN0YXRpY2FsbHkgY29tcGls ZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNoaW50 cwkJIkdFTkVSSUMuaGludHMiCQkjIERlZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9yIGRldmlj ZXMuCgptYWtlb3B0aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkg ZGVidWcgc3ltYm9scwoKb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0 aW9ucyAJUFJFRU1QVElPTgkJIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uCm9w dGlvbnMgCUlORVQJCQkjIEludGVyTkVUd29ya2luZwpvcHRpb25zIAlJTkVUNgkJCSMgSVB2 NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAJU0NUUAkJCSMgU3RyZWFtIENv bnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sIApvcHRpb25zIAlGRlMJCQkjIEJlcmtlbGV5 IEZhc3QgRmlsZXN5c3RlbQpvcHRpb25zIAlTT0ZUVVBEQVRFUwkJIyBFbmFibGUgRkZTIHNv ZnQgdXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgCVVGU19BQ0wJCQkjIFN1cHBvcnQgZm9yIGFj Y2VzcyBjb250cm9sIGxpc3RzCm9wdGlvbnMgCVVGU19ESVJIQVNICQkjIEltcHJvdmUgcGVy Zm9ybWFuY2Ugb24gYmlnIGRpcmVjdG9yaWVzCm9wdGlvbnMgCVVGU19HSk9VUk5BTAkJIyBF bmFibGUgZ2pvdXJuYWwtYmFzZWQgVUZTIGpvdXJuYWxpbmcKb3B0aW9ucyAJTURfUk9PVAkJ CSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJTkZTQ0xJRU5UCQkj IE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdv cmsgRmlsZXN5c3RlbSBTZXJ2ZXIKb3B0aW9ucyAJTkZTTE9DS0QJCSMgTmV0d29yayBMb2Nr IE1hbmFnZXIKb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJl cyBORlNDTElFTlQKb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3RlbQpvcHRp b25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJ IyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQU0VV RE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9QQVJU X0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUdFT01fTEFCRUwJCSMg UHJvdmlkZXMgbGFiZWxpemF0aW9uCm9wdGlvbnMgCUNPTVBBVF80M1RUWQkJIyBCU0QgNC4z IFRUWSBjb21wYXQgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9JQTMyCQkjIENvbXBh dGlibGUgd2l0aCBpMzg2IGJpbmFyaWVzCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJIyBD b21wYXRpYmxlIHdpdGggRnJlZUJTRDQKb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENv bXBhdGlibGUgd2l0aCBGcmVlQlNENQpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDYJCSMgQ29t cGF0aWJsZSB3aXRoIEZyZWVCU0Q2Cm9wdGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxh eSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJh Y2UoMSkgc3VwcG9ydApvcHRpb25zIAlTVEFDSwkJCSMgc3RhY2soOSkgc3VwcG9ydApvcHRp b25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9ucyAJU1lT Vk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJ IyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hF RFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJ S0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9u cyAJQURBUFRJVkVfR0lBTlQJCSMgR2lhbnQgbXV0ZXggaXMgYWRhcHRpdmUuCm9wdGlvbnMg CVNUT1BfTk1JCQkjIFN0b3AgQ1BVUyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkKb3B0aW9u cyAJQVVESVQJCQkjIFNlY3VyaXR5IGV2ZW50IGF1ZGl0aW5nCm9wdGlvbnMgCUtEVFJBQ0Vf RlJBTUUJCSMgRW5zdXJlIGZyYW1lcyBhcmUgY29tcGlsZWQgaW4Kb3B0aW9ucyAJS0RUUkFD RV9IT09LUwkJIyBLZXJuZWwgRFRyYWNlIGhvb2tzCgojIE1ha2UgYW4gU01QLWNhcGFibGUg a2VybmVsIGJ5IGRlZmF1bHQKb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9j ZXNzb3IgS2VybmVsCgojIEFkZCBieSBtZQpkZXZpY2UgICAgICAgICAgZHJtCmRldmljZSAg ICAgICAgICByYWRlb25kcm0KZGV2aWNlICAgICAgICAgIGljaHdkCmRldmljZQkJY3B1Y3Rs CmRldmljZSAgICAgICAgICBjb3JldGVtcApvcHRpb25zCQlFTkFCTEVfQUxBUlQKb3B0aW9u cyAgICAgICAgIENPTVBBVF9MSU5VWDMyCm9wdGlvbnMgICAgICAgICBMSU5QUk9DRlMKb3B0 aW9ucyAgICAgICAgIExJTlNZU0ZTCm9wdGlvbnMgICAgICAgICBBQ1BJX0RFQlVHCm9wdGlv bnMgICAgICAgICBBTFRRCm9wdGlvbnMgICAgICAgICBBTFRRX0NCUQpvcHRpb25zICAgICAg ICAgQUxUUV9SRUQKb3B0aW9ucyAgICAgICAgIEFMVFFfUklPCm9wdGlvbnMgICAgICAgICBB TFRRX0hGU0MKb3B0aW9ucyAgICAgICAgIEFMVFFfQ0ROUgpvcHRpb25zICAgICAgICAgQUxU UV9QUklRCm9wdGlvbnMgICAgICAgICBBTFRRX05PUENDCm9wdGlvbnMgICAgICAgICBBTFRR X0RFQlVHCgojIENQVSBmcmVxdWVuY3kgY29udHJvbApkZXZpY2UJCWNwdWZyZXEKCiMgQnVz IHN1cHBvcnQuCmRldmljZQkJYWNwaQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCiNk ZXZpY2UJCWZkYwoKIyBBVEEgYW5kIEFUQVBJIGRldmljZXMKZGV2aWNlCQlhdGEKZGV2aWNl CQlhdGFkaXNrCQkjIEFUQSBkaXNrIGRyaXZlcwojZGV2aWNlCQlhdGFyYWlkCQkjIEFUQSBS QUlEIGRyaXZlcwpkZXZpY2UJCWF0YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVzCiNkZXZp Y2UJCWF0YXBpZmQJCSMgQVRBUEkgZmxvcHB5IGRyaXZlcwojZGV2aWNlCQlhdGFwaXN0CQkj IEFUQVBJIHRhcGUgZHJpdmVzCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJIyBTdGF0aWMgZGV2 aWNlIG51bWJlcmluZwoKIyBTQ1NJIENvbnRyb2xsZXJzCiNkZXZpY2UJCWFoYwkJIyBBSEEy OTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcwojb3B0aW9ucyAJQUhDX1JFR19QUkVU VFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91 dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVyLgojZGV2aWNlCQlhaGQJCSMgQUhBMzkzMjAv MjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzCiNvcHRpb25zIAlBSERfUkVHX1BS RVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMg b3V0cHV0LiAgQWRkcyB+MjE1ayB0byBkcml2ZXIuCiNkZXZpY2UJCWFtZAkJIyBBTUQgNTND OTc0IChUZWtyYW0gREMtMzkwKFQpKQojZGV2aWNlCQlocHRpb3AJCSMgSGlnaHBvaW50IFJv Y2tldFJhaWQgM3h4eCBzZXJpZXMKI2RldmljZQkJaXNwCQkjIFFsb2dpYyBmYW1pbHkKI2Rl dmljZSAJaXNwZncJCSMgRmlybXdhcmUgZm9yIFFMb2dpYyBIQkFzLSBub3JtYWxseSBhIG1v ZHVsZQpkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbgojZGV2aWNlCQluY3IJ CSMgTkNSL1N5bWJpb3MgTG9naWMKI2RldmljZQkJc3ltCQkjIE5DUi9TeW1iaW9zIExvZ2lj IChuZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3InKQojZGV2aWNlCQl0cm0JCSMgVGVr cmFtIERDMzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoKI2RldmljZQkJYWR2CQkjIEFkdmFu c3lzIFNDU0kgYWRhcHRlcnMKI2RldmljZQkJYWR3CQkjIEFkdmFuc3lzIHdpZGUgU0NTSSBh ZGFwdGVycwojZGV2aWNlCQlhaWMJCSMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFkYXB0ZXJz LCBBSUMtNlsyM102MC4KI2RldmljZQkJYnQJCSMgQnVzbG9naWMvTXlsZXggTXVsdGlNYXN0 ZXIgU0NTSSBhZGFwdGVycwoKCiMgU0NTSSBwZXJpcGhlcmFscwpkZXZpY2UJCXNjYnVzCQkj IFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NTSSkKI2RldmljZQkJY2gJCSMgU0NTSSBtZWRp YSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQojZGV2aWNl CQlzYQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpCiNkZXZpY2UJCWNkCQkjIENE CmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2Vz cykKI2RldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNB Ri1URSkKCiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5 c3RlbQojZGV2aWNlCQlhbXIJCSMgQU1JIE1lZ2FSQUlECiNkZXZpY2UJCWFyY21zcgkJIyBB cmVjYSBTQVRBIElJIFJBSUQKI2RldmljZQkJY2lzcwkJIyBDb21wYXEgU21hcnQgUkFJRCA1 KgojZGV2aWNlCQlkcHQJCSMgRFBUIFNtYXJ0Y2FjaGUgSUlJLCBJViAtIFNlZSBOT1RFUyBm b3Igb3B0aW9ucwojZGV2aWNlCQlocHRtdgkJIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxODJ4 CiNkZXZpY2UJCWhwdHJyCQkjIEhpZ2hwb2ludCBSb2NrZXRSQUlEIDE3eHgsIDIyeHgsIDIz eHgsIDI1eHgKI2RldmljZQkJaWlyCQkjIEludGVsIEludGVncmF0ZWQgUkFJRAojZGV2aWNl CQlpcHMJCSMgSUJNIChBZGFwdGVjKSBTZXJ2ZVJBSUQKI2RldmljZQkJbWx5CQkjIE15bGV4 IEFjY2VsZVJBSUQvZVh0cmVtZVJBSUQKI2RldmljZQkJdHdhCQkjIDN3YXJlIDkwMDAgc2Vy aWVzIFBBVEEvU0FUQSBSQUlECgojIFJBSUQgY29udHJvbGxlcnMKI2RldmljZQkJYWFjCQkj IEFkYXB0ZWMgRlNBIFJBSUQKI2RldmljZQkJYWFjcAkJIyBTQ1NJIHBhc3N0aHJvdWdoIGZv ciBhYWMgKHJlcXVpcmVzIENBTSkKI2RldmljZQkJaWRhCQkjIENvbXBhcSBTbWFydCBSQUlE CiNkZXZpY2UJCW1maQkJIyBMU0kgTWVnYVJBSUQgU0FTCiNkZXZpY2UJCW1seAkJIyBNeWxl eCBEQUM5NjAgZmFtaWx5CiNYWFggcG9pbnRlci9pbnQgd2FybmluZ3MKI2RldmljZQkJcHN0 CQkjIFByb21pc2UgU3VwZXJ0cmFrIFNYNjAwMAojZGV2aWNlCQl0d2UJCSMgM3dhcmUgQVRB IFJBSUQKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBT LzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZp Y2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRl dmljZQkJa2JkbXV4CQkjIGtleWJvYXJkIG11bHRpcGxleGVyCgpkZXZpY2UJCXZnYQkJIyBW R0EgdmlkZW8gY2FyZCBkcml2ZXIKCmRldmljZQkJc3BsYXNoCQkjIFNwbGFzaCBzY3JlZW4g YW5kIHNjcmVlbiBzYXZlciBzdXBwb3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29u c29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2aWNlCQlzYwoKZGV2 aWNlCQlhZ3AJCSMgc3VwcG9ydCBzZXZlcmFsIEFHUCBjaGlwc2V0cwoKIyBQQ0NBUkQgKFBD TUNJQSkgc3VwcG9ydAojIFBDTUNJQSBhbmQgY2FyZGJ1cyBicmlkZ2Ugc3VwcG9ydAojZGV2 aWNlCQljYmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQojZGV2aWNlCQlwY2NhcmQJCSMg UEMgQ2FyZCAoMTYtYml0KSBidXMKI2RldmljZQkJY2FyZGJ1cwkJIyBDYXJkQnVzICgzMi1i aXQpIGJ1cwoKIyBTZXJpYWwgKENPTSkgcG9ydHMKZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZb NDVdNTAgYmFzZWQgc2VyaWFsIHBvcnRzCmRldmljZQkJdWFydAkJIyBHZW5lcmljIFVBUlQg ZHJpdmVyCgojIFBhcmFsbGVsIHBvcnQKZGV2aWNlCQlwcGMKZGV2aWNlCQlwcGJ1cwkJIyBQ YXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQpCmRldmljZQkJbHB0CQkjIFByaW50ZXIKZGV2 aWNlCQlwbGlwCQkjIFRDUC9JUCBvdmVyIHBhcmFsbGVsCmRldmljZQkJcHBpCQkjIFBhcmFs bGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQpkZXZpY2UJCXZwbwkJIyBSZXF1aXJlcyBzY2J1 cyBhbmQgZGEKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxsZWwg UENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVy LCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25uZWN0 cyB0byBzaW8sIHVhcnQgYW5kL29yIHBwYyBkcml2ZXJzKToKI2RldmljZQkJcHVjCgojIFBD SSBFdGhlcm5ldCBOSUNzLgojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBU dWxpcCcnKQojZGV2aWNlCQllbQkJIyBJbnRlbCBQUk8vMTAwMCBHaWdhYml0IEV0aGVybmV0 IEZhbWlseQojZGV2aWNlCQlpZ2IJCSMgSW50ZWwgUFJPLzEwMDAgUENJRSBTZXJ2ZXIgR2ln YWJpdCBGYW1pbHkKI2RldmljZQkJaXhnYmUJCSMgSW50ZWwgUFJPLzEwR2JFIFBDSUUgRXRo ZXJuZXQgRmFtaWx5CiNkZXZpY2UJCWxlCQkjIEFNRCBBbTc5MDAgTEFOQ0UgYW5kIEFtNzlD OXh4IFBDbmV0CiNkZXZpY2UJCXR4cAkJIyAzQ29tIDNjUjk5MCAoYGBUeXBob29uJycpCiNk ZXZpY2UJCXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQoKIyBQQ0kgRXRo ZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxlciBjb2Rl LgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4g b3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMgc3Vw cG9ydAojZGV2aWNlCQlhZ2UJCSMgQXR0YW5zaWMvQXRoZXJvcyBMMSBHaWdhYml0IEV0aGVy bmV0CiNkZXZpY2UJCWFsZQkJIyBBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4MTE0IEV0aGVy bmV0CiNkZXZpY2UJCWJjZQkJIyBCcm9hZGNvbSBCQ001NzA2L0JDTTU3MDggR2lnYWJpdCBF dGhlcm5ldAojZGV2aWNlCQliZmUJCSMgQnJvYWRjb20gQkNNNDQweCAxMC8xMDAgRXRoZXJu ZXQKI2RldmljZQkJYmdlCQkjIEJyb2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRoZXJuZXQK I2RldmljZQkJZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJpb3VzIHdvcmthbGlrZXMK I2RldmljZQkJZXQJCSMgQWdlcmUgRVQxMzEwIDEwLzEwMC9HaWdhYml0IEV0aGVybmV0CiNk ZXZpY2UJCWZ4cAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1 OCkKI2RldmljZQkJam1lCQkjIEpNaWNyb24gSk1DMjUwIEdpZ2FiaXQvSk1DMjYwIEZhc3Qg RXRoZXJuZXQKI2RldmljZQkJbGdlCQkjIExldmVsIDEgTFhUMTAwMSBnaWdhYml0IEV0aGVy bmV0CiNkZXZpY2UJCW1zawkJIyBNYXJ2ZWxsL1N5c0tvbm5lY3QgWXVrb24gSUkgR2lnYWJp dCBFdGhlcm5ldAojZGV2aWNlCQluZmUJCSMgblZpZGlhIG5Gb3JjZSBNQ1Agb24tYm9hcmQg RXRoZXJuZXQKI2RldmljZQkJbmdlCQkjIE5hdFNlbWkgRFA4MzgyMCBnaWdhYml0IEV0aGVy bmV0CiNkZXZpY2UJCW52ZQkJIyBuVmlkaWEgbkZvcmNlIE1DUCBvbi1ib2FyZCBFdGhlcm5l dCBOZXR3b3JraW5nCiNkZXZpY2UJCXBjbgkJIyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMCAo cHJlY2VkZW5jZSBvdmVyICdsZScpCmRldmljZQkJcmUJCSMgUmVhbFRlayA4MTM5QysvODE2 OS84MTY5Uy84MTEwUwojZGV2aWNlCQlybAkJIyBSZWFsVGVrIDgxMjkvODEzOQojZGV2aWNl CQlzZgkJIyBBZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpCiNkZXZpY2UJCXNpcwkJ IyBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2CiNkZXZpY2UJ CXNrCQkjIFN5c0tvbm5lY3QgU0stOTg0eCAmIFNLLTk4MnggZ2lnYWJpdCBFdGhlcm5ldAoj ZGV2aWNlCQlzdGUJCSMgU3VuZGFuY2UgU1QyMDEgKEQtTGluayBERkUtNTUwVFgpCiNkZXZp Y2UJCXRpCQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJL0lJIGdpZ2FiaXQgRXRoZXJuZXQK I2RldmljZQkJdGwJCSMgVGV4YXMgSW5zdHJ1bWVudHMgVGh1bmRlckxBTgojZGV2aWNlCQl0 eAkJIyBTTUMgRXRoZXJQb3dlciBJSSAoODNjMTcwIGBgRVBJQycnKQojZGV2aWNlCQl2Z2UJ CSMgVklBIFZUNjEyeCBnaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCXZyCQkjIFZJQSBSaGlu ZSwgUmhpbmUgSUkKI2RldmljZQkJd2IJCSMgV2luYm9uZCBXODlDODQwRgojZGV2aWNlCQl4 bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xvbmUnJykKCiMgSVNBIEV0 aGVybmV0IE5JQ3MuICBwY2NhcmQgTklDcyBpbmNsdWRlZC4KI2RldmljZQkJY3MJCSMgQ3J5 c3RhbCBTZW1pY29uZHVjdG9yIENTODl4MCBOSUMKIyAnZGV2aWNlIGVkJyByZXF1aXJlcyAn ZGV2aWNlIG1paWJ1cycKI2RldmljZQkJZWQJCSMgTkVbMTJdMDAwLCBTTUMgVWx0cmEsIDNj NTAzLCBEUzgzOTAgY2FyZHMKI2RldmljZQkJZXgJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBy by8xMCBhbmQgUHJvLzEwKwojZGV2aWNlCQllcAkJIyBFdGhlcmxpbmsgSUlJIGJhc2VkIGNh cmRzCiNkZXZpY2UJCWZlCQkjIEZ1aml0c3UgTUI4Njk2eCBiYXNlZCBjYXJkcwojZGV2aWNl CQlzbgkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcwojZGV2aWNlCQl4 ZQkJIyBYaXJjb20gcGNjYXJkIEV0aGVybmV0CgojIFdpcmVsZXNzIE5JQyBjYXJkcwojZGV2 aWNlCQl3bGFuCQkjIDgwMi4xMSBzdXBwb3J0CiNkZXZpY2UJCXdsYW5fd2VwCSMgODAyLjEx IFdFUCBzdXBwb3J0CiNkZXZpY2UJCXdsYW5fY2NtcAkjIDgwMi4xMSBDQ01QIHN1cHBvcnQK I2RldmljZQkJd2xhbl90a2lwCSMgODAyLjExIFRLSVAgc3VwcG9ydAojZGV2aWNlCQl3bGFu X2FtcnIJIyBBTVJSIHRyYW5zbWl0IHJhdGUgY29udHJvbCBhbGdvcml0aG0KI2RldmljZQkJ d2xhbl9zY2FuX2FwCSMgODAyLjExIEFQIG1vZGUgc2Nhbm5pbmcKI2RldmljZQkJd2xhbl9z Y2FuX3N0YQkjIDgwMi4xMSBTVEEgbW9kZSBzY2FubmluZwojZGV2aWNlCQlhbgkJIyBBaXJv bmV0IDQ1MDAvNDgwMCA4MDIuMTEgd2lyZWxlc3MgTklDcy4KI2RldmljZQkJYXRoCQkjIEF0 aGVyb3MgcGNpL2NhcmRidXMgTklDJ3MKI2RldmljZQkJYXRoX2hhbAkJIyBBdGhlcm9zIEhB TCAoSGFyZHdhcmUgQWNjZXNzIExheWVyKQojb3B0aW9ucwkJQUhfU1VQUE9SVF9BUjU0MTYJ IyBlbmFibGUgQVI1NDE2IHR4L3J4IGRlc2NyaXB0b3JzCiNkZXZpY2UJCWF0aF9yYXRlX3Nh bXBsZQkjIFNhbXBsZVJhdGUgdHggcmF0ZSBjb250cm9sIGZvciBhdGgKI2RldmljZQkJYXdp CQkjIEJheVN0YWNrIDY2MCBhbmQgb3RoZXJzCiNkZXZpY2UJCXJhbAkJIyBSYWxpbmsgVGVj aG5vbG9neSBSVDI1MDAgd2lyZWxlc3MgTklDcy4KI2RldmljZQkJd2kJCSMgV2F2ZUxBTi9J bnRlcnNpbC9TeW1ib2wgODAyLjExIHdpcmVsZXNzIE5JQ3MuCgojIFBzZXVkbyBkZXZpY2Vz LgpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpkZXZpY2UJCXJhbmRvbQkJIyBF bnRyb3B5IGRldmljZQpkZXZpY2UJCWV0aGVyCQkjIEV0aGVybmV0IHN1cHBvcnQKZGV2aWNl CQlzbAkJIyBLZXJuZWwgU0xJUApkZXZpY2UJCXBwcAkJIyBLZXJuZWwgUFBQCmRldmljZQkJ dHVuCQkjIFBhY2tldCB0dW5uZWwuCmRldmljZQkJcHR5CQkjIFBzZXVkby10dHlzICh0ZWxu ZXQgZXRjKQpkZXZpY2UJCW1kCQkjIE1lbW9yeSAiZGlza3MiCmRldmljZQkJZ2lmCQkjIElQ djYgYW5kIElQdjQgdHVubmVsaW5nCmRldmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJl bGF5aW5nICh0cmFuc2xhdGlvbikKZGV2aWNlCQlmaXJtd2FyZQkjIGZpcm13YXJlIGFzc2lz dCBtb2R1bGUKCiMgVGhlIGBicGYnIGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNr ZXQgRmlsdGVyLgojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5j ZXMgb2YgZW5hYmxpbmcgdGhpcyEKIyBOb3RlIHRoYXQgJ2JwZicgaXMgcmVxdWlyZWQgZm9y IERIQ1AuCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiMgVVNCIHN1 cHBvcnQKZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCmRldmljZQkJ b2hjaQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCWVoY2kJCSMgRUhDSSBQ Q0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAyLjApCmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJl cXVpcmVkKQojZGV2aWNlCQl1ZGJwCQkjIFVTQiBEb3VibGUgQnVsayBQaXBlIGRldmljZXMK ZGV2aWNlCQl1Z2VuCQkjIEdlbmVyaWMKZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZh Y2UgRGV2aWNlcyIKZGV2aWNlCQl1a2JkCQkjIEtleWJvYXJkCiNkZXZpY2UJCXVscHQJCSMg UHJpbnRlcgpkZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVz IHNjYnVzIGFuZCBkYQpkZXZpY2UJCXVtcwkJIyBNb3VzZQojZGV2aWNlCQl1cmFsCQkjIFJh bGluayBUZWNobm9sb2d5IFJUMjUwMFVTQiB3aXJlbGVzcyBOSUNzCiNkZXZpY2UJCXVyaW8J CSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXIKI2RldmljZQkJdXNjYW5uZXIJIyBTY2Fu bmVycwojIFVTQiBTZXJpYWwgZGV2aWNlcwpkZXZpY2UJCXVjb20JCSMgR2VuZXJpYyBjb20g dHR5cwojZGV2aWNlCQl1YXJrCQkjIFRlY2hub2xvZ2llcyBBUkszMTE2IGJhc2VkIHNlcmlh bCBhZGFwdGVycwojZGV2aWNlCQl1YnNhCQkjIEJlbGtpbiBGNVUxMDMgYW5kIGNvbXBhdGli bGUgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXVic2VyCQkjIEJXQ1QgY29uc29sZSBzZXJp YWwgYWRhcHRlcnMKI2RldmljZQkJdWZ0ZGkJCSMgRm9yIEZUREkgdXNiIHNlcmlhbCBhZGFw dGVycwojZGV2aWNlCQl1aXBhcQkJIyBTb21lIFdpbkNFIGJhc2VkIGRldmljZXMKI2Rldmlj ZQkJdXBsY29tCQkjIFByb2xpZmljIFBMLTIzMDMgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJ CXVzbGNvbQkJIyBTSSBMYWJzIENQMjEwMS9DUDIxMDIgc2VyaWFsIGFkYXB0ZXJzCiNkZXZp Y2UJCXV2aXNvcgkJIyBWaXNvciBhbmQgUGFsbSBkZXZpY2VzCiNkZXZpY2UJCXV2c2NvbQkJ IyBVU0Igc2VyaWFsIHN1cHBvcnQgZm9yIERESSBwb2NrZXQncyBQSFMKIyBVU0IgRXRoZXJu ZXQsIHJlcXVpcmVzIG1paWJ1cwojZGV2aWNlCQlhdWUJCSMgQURNdGVrIFVTQiBFdGhlcm5l dAojZGV2aWNlCQlheGUJCSMgQVNJWCBFbGVjdHJvbmljcyBVU0IgRXRoZXJuZXQKI2Rldmlj ZQkJY2RjZQkJIyBHZW5lcmljIFVTQiBvdmVyIEV0aGVybmV0CiNkZXZpY2UJCWN1ZQkJIyBD QVRDIFVTQiBFdGhlcm5ldAojZGV2aWNlCQlrdWUJCSMgS2F3YXNha2kgTFNJIFVTQiBFdGhl cm5ldAojZGV2aWNlCQlydWUJCSMgUmVhbFRlayBSVEw4MTUwIFVTQiBFdGhlcm5ldAoKIyBG aXJlV2lyZSBzdXBwb3J0CiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUK I2RldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAoUmVxdWlyZXMgc2NidXMgYW5k IGRhKQojZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9uLXN0YW5k YXJkISkKI2RldmljZQkJZndpcAkJIyBJUCBvdmVyIEZpcmVXaXJlIChSRkMgMjczNCwzMTQ2 KQojZGV2aWNlCQlkY29ucwkJIyBEdW1iIGNvbnNvbGUgZHJpdmVyCiNkZXZpY2UJCWRjb25z X2Nyb20JIyBDb25maWd1cmF0aW9uIFJPTSBmb3IgZGNvbnMK --------------010207030806030006010706 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjItUkVMRUFTRSAjMzog TW9uIE1heSAgNCAyMzo1OTowOSBDU1QgMjAwOQogICAgcm9vdEBsb2NhbGhvc3Q6L3Vzci9v YmovdXNyL3NyYy9zeXMva2VybmVsClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwCkNQVTogUGVudGl1bShSKSBEdWFsLUNvcmUgIENQVSAgICAg IEU1MjAwICBAIDIuNTBHSHogKDI0OTMuNzYtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4g PSAiR2VudWluZUludGVsIiAgSWQgPSAweDEwNjc2ICBTdGVwcGluZyA9IDYKICBGZWF0dXJl cz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxT RVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZY U1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHhlMzlkPFNTRTMsUlNW RDIsTU9OLERTX0NQTCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNPgogIEFNRCBGZWF0 dXJlcz0weDIwMDAwODAwPFNZU0NBTEwsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4K ICBDb3JlcyBwZXIgcGFja2FnZTogMgp1c2FibGUgbWVtb3J5ID0gNDI4NDU1NTI2NCAoNDA4 NiBNQikKYXZhaWwgbWVtb3J5ICA9IDQxMTIwMzU4NDAgKDM5MjEgTUIpCkFDUEkgQVBJQyBU YWJsZTogPEFMQVNLQSBBIE0gST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl bSBEZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVAp OiBBUElDIElEOiAgMQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkCmtiZDEgYXQga2JkbXV4MAppY2h3ZCBtb2R1bGUgbG9hZGVkCmFjcGkwOiA8QUxB U0tBIEEgTSBJPiBvbiBtb3RoZXJib2FyZAphY3BpMDogW0lUSFJFQURdCmFjcGkwOiBQb3dl ciBCdXR0b24gKGZpeGVkKQpUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3 OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41 Nzk1NDVNSHo+IHBvcnQgMHg0MDgtMHg0MGIgb24gYWNwaTAKYWNwaV9ocGV0MDogPEhpZ2gg UHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24g YWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5 IDkwMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9u IGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liMQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9y dCAweGEwMDAtMHhhMGZmIG1lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhmZjgyMDAwMC0w eGZmODJmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKZHJtMDogPEFUSSBSYWRl b24gSEQgMzQ1MD4gb24gdmdhcGNpMAp2Z2FwY2kwOiBjaGlsZCBkcm0wIHJlcXVlc3RlZCBw Y2lfZW5hYmxlX2J1c21hc3RlcgppbmZvOiBbZHJtXSBJbml0aWFsaXplZCByYWRlb24gMS4y OS4wIDIwMDgwNTI4CnBjaTE6IDxtdWx0aW1lZGlhLCBIREE+IGF0IGRldmljZSAwLjEgKG5v IGRyaXZlciBhdHRhY2hlZCkKdWhjaTA6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gcG9ydCAweGIwYzAtMHhiMGRmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVo Y2kwOiBbR0lBTlQtTE9DS0VEXQp1aGNpMDogW0lUSFJFQURdCnVzYjA6IDxVSENJIChnZW5l cmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1 aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2IwCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aGNpMTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4 YjBhMC0weGIwYmYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG9uIHBjaTAKdWhjaTE6IFtHSUFO VC1MT0NLRURdCnVoY2kxOiBbSVRIUkVBRF0KdXNiMTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBj b250cm9sbGVyPiBvbiB1aGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiA8SW50 ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo Y2kyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiMDgwLTB4YjA5 ZiBpcnEgMTggYXQgZGV2aWNlIDI2LjIgb24gcGNpMAp1aGNpMjogW0dJQU5ULUxPQ0tFRF0K dWhjaTI6IFtJVEhSRUFEXQp1c2IyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+ IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IDxJbnRlbCBVSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMgp1aHVi MjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6IDxFSENJ IChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZmOTA0NDAwLTB4ZmY5MDQ3 ZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1MT0NLRURd CmVoY2kwOiBbSVRIUkVBRF0KdXNiMzogRUhDSSB2ZXJzaW9uIDEuMAp1c2IzOiBjb21wYW5p b24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIKdXNiMzogPEVI Q0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMzogVVNCIHJl dmlzaW9uIDIuMAp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2 IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApwY2kwOiA8bXVsdGltZWRpYSwgSERBPiBhdCBkZXZpY2Ug MjcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAxNyBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAy OC40IG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKYXRhcGNpMDogPEpN aWNyb24gSk1CMzYzIFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDkwNDAtMHg5MDQ3LDB4 OTAzMC0weDkwMzMsMHg5MDIwLTB4OTAyNywweDkwMTAtMHg5MDEzLDB4OTAwMC0weDkwMGYg bWVtIDB4ZmY3MDAwMDAtMHhmZjcwMWZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kz CmF0YXBjaTA6IFtJVEhSRUFEXQphdGFwY2kwOiBBSENJIGNhbGxlZCBmcm9tIHZlbmRvciBz cGVjaWZpYyBkcml2ZXIKYXRhcGNpMDogQUhDSSBWZXJzaW9uIDAxLjAwIGNvbnRyb2xsZXIg d2l0aCAyIHBvcnRzIGRldGVjdGVkCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kw CmF0YTI6IFtJVEhSRUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGEz OiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9uIGF0YXBjaTAKYXRhNDogW0lU SFJFQURdCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAy OC41IG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcmUwOiA8UmVhbFRl ayA4MTY4LzgxNjhCLzgxNjhDLzgxNjhDUC84MTY4RC84MTExQi84MTExQy84MTExQ1AgUENJ ZSBHaWdhYml0IEV0aGVybmV0PiBwb3J0IDB4ODAwMC0weDgwZmYgbWVtIDB4ZmY2MjAwMDAt MHhmZjYyMGZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k0CnJlMDogVXNpbmcgMSBN U0kgbWVzc2FnZXMKcmUwOiBDaGlwIHJldi4gMHgzODAwMDAwMApyZTA6IE1BQyByZXYuIDB4 MDAwMDAwMDAKbWlpYnVzMDogPE1JSSBidXM+IG9uIHJlMApyZ2VwaHkwOiA8UlRMODE2OVMv ODExMFMvODIxMUIgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMwCnJnZXBoeTA6 ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAw YmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoy MTo4NTozOTpkMzpiOQpyZTA6IFtGSUxURVJdCnVoY2kzOiA8VUhDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IHBvcnQgMHhiMDYwLTB4YjA3ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAg b24gcGNpMAp1aGNpMzogW0dJQU5ULUxPQ0tFRF0KdWhjaTM6IFtJVEhSRUFEXQp1c2I0OiA8 VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCnVzYjQ6IFVTQiByZXZp c2lvbiAxLjAKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNAp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWhjaTQ6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gcG9ydCAweGIwNDAtMHhiMDVmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVo Y2k0OiBbR0lBTlQtTE9DS0VEXQp1aGNpNDogW0lUSFJFQURdCnVzYjU6IDxVSENJIChnZW5l cmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKdXNiNTogVVNCIHJldmlzaW9uIDEuMAp1 aHViNTogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2I1CnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aGNpNTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4 YjAyMC0weGIwM2YgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTU6IFtHSUFO VC1MT0NLRURdCnVoY2k1OiBbSVRIUkVBRF0KdXNiNjogPFVIQ0kgKGdlbmVyaWMpIFVTQiBj b250cm9sbGVyPiBvbiB1aGNpNQp1c2I2OiBVU0IgcmV2aXNpb24gMS4wCnVodWI2OiA8SW50 ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYjYKdWh1YjY6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVo Y2kxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZjkwNDAw MC0weGZmOTA0M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kxOiBbR0lB TlQtTE9DS0VEXQplaGNpMTogW0lUSFJFQURdCnVzYjc6IEVIQ0kgdmVyc2lvbiAxLjAKdXNi NzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjQgdXNiNSB1c2I2 CnVzYjc6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kxCnVz Yjc6IFVTQiByZXZpc2lvbiAyLjAKdWh1Yjc6IDxJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNwp1aHViNzogNiBwb3J0cyB3 aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI1CmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTE6IDxJbnRlbCBJQ0g5IFNBVEEzMDAgY29u dHJvbGxlcj4gcG9ydCAweGIxOTAtMHhiMTk3LDB4YjE4MC0weGIxODMsMHhiMTcwLTB4YjE3 NywweGIxNjAtMHhiMTYzLDB4YjE1MC0weGIxNWYsMHhiMTQwLTB4YjE0ZiBpcnEgMTkgYXQg ZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kxOiBbSVRIUkVBRF0KYXRhNTogPEFUQSBjaGFu bmVsIDA+IG9uIGF0YXBjaTEKYXRhNTogW0lUSFJFQURdCmF0YTY6IDxBVEEgY2hhbm5lbCAx PiBvbiBhdGFwY2kxCmF0YTY6IFtJVEhSRUFEXQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+ IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTI6IDxJbnRlbCBJ Q0g5IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGIxMzAtMHhiMTM3LDB4YjEyMC0weGIx MjMsMHhiMTEwLTB4YjExNywweGIxMDAtMHhiMTAzLDB4YjBmMC0weGIwZmYsMHhiMGUwLTB4 YjBlZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGFwY2kyOiBbSVRIUkVBRF0K YXRhNzogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTIKYXRhNzogW0lUSFJFQURdCmF0YTg6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kyCmF0YTg6IFtJVEhSRUFEXQphY3BpX2J1dHRv bjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMTogPFBvd2VyIEJ1dHRv bj4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9y dCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAx IG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGti ZDA6IFtJVEhSRUFEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNt MDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVsIE1vdXNlTWFu KywgZGV2aWNlIElEIDAKc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9m IHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMDogY29u ZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9y dCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0 PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlw ZSAxNjU1MEEKc2lvMDogW0ZJTFRFUl0Kc2lvMTogY29uZmlndXJlZCBpcnEgNSBub3QgaW4g Yml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQK c2lvMTogY29uZmlndXJlZCBpcnEgNSBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAK c2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMTogPDE2NTUwQS1jb21wYXRpYmxl IENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSA1IG9uIGFjcGkwCnNpbzE6IHR5cGUg MTY1NTBBCnNpbzE6IFtGSUxURVJdCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBwb3J0IDB4Mzc4 LTB4MzdmIGlycSAzIGRycSAzIG9uIGFjcGkwCnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoTklC QkxFLW9ubHkpIGluIENPTVBBVElCTEUgbW9kZQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1 cz4gb24gcHBjMApwcGJ1czA6IFtJVEhSRUFEXQpwbGlwMDogPFBMSVAgbmV0d29yayBpbnRl cmZhY2U+IG9uIHBwYnVzMApwbGlwMDogV0FSTklORzogdXNpbmcgb2Jzb2xldGVkIElGRl9O RUVEU0dJQU5UIGZsYWcKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1 cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCnBwYzA6IFtH SUFOVC1MT0NLRURdCnBwYzA6IFtJVEhSRUFEXQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmNvcmV0ZW1wMDogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwCmVzdDA6 IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKZXN0OiBD UFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQu CmVzdDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciA2MWE0YzIxMDYwMDRjMjEKZGV2 aWNlX2F0dGFjaDogZXN0MCBhdHRhY2ggcmV0dXJuZWQgNgpwNHRjYzA6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmNvcmV0ZW1wMTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxCmVzdDE6 IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKZXN0OiBD UFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQu CmVzdDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciA2MWE0YzIxMDYwMDRjMjEKZGV2 aWNlX2F0dGFjaDogZXN0MSBhdHRhY2ggcmV0dXJuZWQgNgpwNHRjYzE6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQppY2h3ZDA6IDxJbnRlbCBJQ0g5IHdhdGNo ZG9nIHRpbWVyPiBvbiBpc2EwCmljaHdkMDogSW50ZWwgSUNIOSB3YXRjaGRvZyB0aW1lciAo SUNIOSBvciBlcXVpdmFsZW50KQpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAw eGQwMDAwLTB4ZDBmZmYsMHhkMTAwMC0weGRiN2ZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNv bnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29u c29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4 M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3VudGVycyB0 aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKYWNkMDogRFZEUiA8QVRBUEkgRFZEIEEgREgyMEE0UC85 UDU5PiBhdCBhdGE0LXNsYXZlIFVETUE2NgphZDEwOiA2MTA0ODBNQiA8V0RDIFdENjQwMEFB S1MtMDBBN0IyIDAxLjAzQjAxPiBhdCBhdGE1LW1hc3RlciBTQVRBMzAwClNNUDogQVAgQ1BV ICMxIExhdW5jaGVkIQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQxMHMyYSBp cyB1ZnNpZC80OWY3ODVhNmIwNjNhOGU3LgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlk ZXIgYWQxMHMyZCBpcyB1ZnNpZC80OWY3ODVhOGMxOTdkZTJmLgpHRU9NX0xBQkVMOiBMYWJl bCBmb3IgcHJvdmlkZXIgYWQxMHMyZSBpcyB1ZnNpZC80OWY3ODVhNmU3YzdjMzE1LgpHRU9N X0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQxMHMyZiBpcyB1ZnNpZC80OWY3ODVhNmI3 NzhkMTc2LgpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMTBzMmEKR0VP TV9MQUJFTDogTGFiZWwgdWZzaWQvNDlmNzg1YTZiMDYzYThlNyByZW1vdmVkLgpHRU9NX0xB QkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQxMHMyYSBpcyB1ZnNpZC80OWY3ODVhNmIwNjNh OGU3LgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80OWY3ODVhNmU3YzdjMzE1IHJlbW92ZWQu CkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDEwczJlIGlzIHVmc2lkLzQ5Zjc4 NWE2ZTdjN2MzMTUuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5Zjc4NWE2Yjc3OGQxNzYg cmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMTBzMmYgaXMgdWZz aWQvNDlmNzg1YTZiNzc4ZDE3Ni4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDlmNzg1YThj MTk3ZGUyZiByZW1vdmVkLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQxMHMy ZCBpcyB1ZnNpZC80OWY3ODVhOGMxOTdkZTJmLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80 OWY3ODVhNmIwNjNhOGU3IHJlbW92ZWQuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ5Zjc4 NWE2ZTdjN2MzMTUgcmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDlmNzg1YTZi Nzc4ZDE3NiByZW1vdmVkLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80OWY3ODVhOGMxOTdk ZTJmIHJlbW92ZWQuCldBUk5JTkc6IGF0dGVtcHQgdG8gbmV0X2FkZF9kb21haW4obmV0Z3Jh cGgpIGFmdGVyIGRvbWFpbmZpbmFsaXplKCkKZnVzZTRic2Q6IHZlcnNpb24gMC4zLjktcHJl MSwgRlVTRSBBQkkgNy44CnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmhkYWMwOiA8 SW50ZWwgODI4MDFJIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVyPiBtZW0gMHhm ZjkwMDAwMC0weGZmOTAzZmZmIGlycSAyMiBhdCBkZXZpY2UgMjcuMCBvbiBwY2kwCmhkYWMw OiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDA5MDMyOV8wMTMxCmhkYWMwOiBbSVRIUkVBRF0K aGRhYzA6IEhEQSBDb2RlYyAjMDogUmVhbHRlayBBTEM4ODgKaGRhYzE6IDxBVEkgUlY2MjAg SGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+IG1lbSAweGZmODMwMDAwLTB4ZmY4 MzNmZmYgaXJxIDE3IGF0IGRldmljZSAwLjEgb24gcGNpMQpoZGFjMTogSERBIERyaXZlciBS ZXZpc2lvbjogMjAwOTAzMjlfMDEzMQpoZGFjMTogW0lUSFJFQURdCmhkYWMxOiBIREEgQ29k ZWMgIzA6IEFUSSBSNnh4IEhETUkKcGNtMDogPEhEQSBSZWFsdGVrIEFMQzg4OCBQQ00gIzAg QW5hbG9nPiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20xOiA8SERBIFJlYWx0ZWsgQUxD ODg4IFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTI6IDxIREEg UmVhbHRlayBBTEM4ODggUENNICMyIERpZ2l0YWw+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMw CnBjbTM6IDxIREEgQVRJIFI2eHggSERNSSBQQ00gIzAgRGlnaXRhbD4gYXQgY2FkIDAgbmlk IDEgb24gaGRhYzEKcGlkIDExMTYgKG5vdGlmaWNhdGlvbi1kYWVtb24pLCB1aWQgMTAwMTog ZXhpdGVkIG9uIHNpZ25hbCA2Cg== --------------010207030806030006010706 Content-Type: text/plain; name="sysctl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sysctl" a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDcuMi1SRUxFQVNFCmtlcm4u b3NyZXZpc2lvbjogMTk5NTA2Cmtlcm4udmVyc2lvbjogRnJlZUJTRCA3LjItUkVMRUFTRSAj MzogTW9uIE1heSAgNCAyMzo1OTowOSBDU1QgMjAwOQogICAgcm9vdEBsb2NhbGhvc3Q6L3Vz ci9vYmovdXNyL3NyYy9zeXMva2VybmVsCgprZXJuLm1heHZub2RlczogMTAwMDAwCmtlcm4u bWF4cHJvYzogNjE2NAprZXJuLm1heGZpbGVzOiAxMjMyOAprZXJuLmFyZ21heDogMjYyMTQ0 Cmtlcm4uc2VjdXJlbGV2ZWw6IC0xCmtlcm4uaG9zdG5hbWU6IGxvY2FsaG9zdAprZXJuLmhv c3RpZDogMjk0NTA5MTExNgprZXJuLmNsb2NrcmF0ZTogeyBoeiA9IDEwMDAsIHRpY2sgPSAx MDAwLCBwcm9maHogPSAyMDAwLCBzdGF0aHogPSAxMzMgfQprZXJuLnBvc2l4MXZlcnNpb246 IDIwMDExMgprZXJuLm5ncm91cHM6IDE2Cmtlcm4uam9iX2NvbnRyb2w6IDEKa2Vybi5zYXZl ZF9pZHM6IDAKa2Vybi5ib290dGltZTogeyBzZWMgPSAxMjQxNzQ2MzM2LCB1c2VjID0gNzU4 OTU3IH0gRnJpIE1heSAgOCAwOTozMjoxNiAyMDA5Cmtlcm4uZG9tYWlubmFtZTogCmtlcm4u b3NyZWxkYXRlOiA3MDIwMDAKa2Vybi5ib290ZmlsZTogL2Jvb3Qva2VybmVsL2tlcm5lbApr ZXJuLm1heGZpbGVzcGVycHJvYzogMTEwOTUKa2Vybi5tYXhwcm9jcGVydWlkOiA1NTQ3Cmtl cm4uaXBjLm1heHNvY2tidWY6IDI2MjE0NAprZXJuLmlwYy5zb2NrYnVmX3dhc3RlX2ZhY3Rv cjogOAprZXJuLmlwYy5zb21heGNvbm46IDEyOAprZXJuLmlwYy5tYXhfbGlua2hkcjogMTYK a2Vybi5pcGMubWF4X3Byb3RvaGRyOiA2MAprZXJuLmlwYy5tYXhfaGRyOiA3NgprZXJuLmlw Yy5tYXhfZGF0YWxlbjogMTAwCmtlcm4uaXBjLm5tYmp1bWJvMTY6IDMyMDAKa2Vybi5pcGMu bm1ianVtYm85OiA2NDAwCmtlcm4uaXBjLm5tYmp1bWJvcDogMTI4MDAKa2Vybi5pcGMubm1i Y2x1c3RlcnM6IDI1NjAwCmtlcm4uaXBjLnBpcGVyZXNpemVhbGxvd2VkOiAxCmtlcm4uaXBj LnBpcGVyZXNpemVmYWlsOiAwCmtlcm4uaXBjLnBpcGVhbGxvY2ZhaWw6IDAKa2Vybi5pcGMu cGlwZWZyYWdyZXRyeTogMAprZXJuLmlwYy5waXBla3ZhOiA3MjA4OTYKa2Vybi5pcGMubWF4 cGlwZWt2YTogNjg5MDcwMDgKa2Vybi5pcGMubXNnc2VnOiAyMDQ4Cmtlcm4uaXBjLm1zZ3Nz ejogOAprZXJuLmlwYy5tc2d0cWw6IDQwCmtlcm4uaXBjLm1zZ21uYjogMjA0OAprZXJuLmlw Yy5tc2dtbmk6IDQwCmtlcm4uaXBjLm1zZ21heDogMTYzODQKa2Vybi5pcGMuc2VtYWVtOiAx NjM4NAprZXJuLmlwYy5zZW12bXg6IDMyNzY3Cmtlcm4uaXBjLnNlbXVzejogMTUyCmtlcm4u aXBjLnNlbXVtZTogMTAKa2Vybi5pcGMuc2Vtb3BtOiAxMDAKa2Vybi5pcGMuc2VtbXNsOiA2 MAprZXJuLmlwYy5zZW1tbnU6IDMwCmtlcm4uaXBjLnNlbW1uczogNjAKa2Vybi5pcGMuc2Vt bW5pOiAxMAprZXJuLmlwYy5zZW1tYXA6IDMwCmtlcm4uaXBjLnNobV9hbGxvd19yZW1vdmVk OiAwCmtlcm4uaXBjLnNobV91c2VfcGh5czogMAprZXJuLmlwYy5zaG1hbGw6IDgxOTIKa2Vy bi5pcGMuc2htc2VnOiAxMjgKa2Vybi5pcGMuc2htbW5pOiAxOTIKa2Vybi5pcGMuc2htbWlu OiAxCmtlcm4uaXBjLnNobW1heDogMzM1NTQ0MzIKa2Vybi5pcGMubWF4c29ja2V0czogMjU2 MDAKa2Vybi5pcGMubnVtb3BlbnNvY2tldHM6IDIxNQprZXJuLmlwYy5uc2ZidWZzdXNlZDog MAprZXJuLmlwYy5uc2ZidWZzcGVhazogMAprZXJuLmlwYy5uc2ZidWZzOiAwCmtlcm4uZHVt bXk6IDAKa2Vybi5wc19zdHJpbmdzOiAxNDA3Mzc0ODgzNTUyOTYKa2Vybi51c3JzdGFjazog MTQwNzM3NDg4MzU1MzI4Cmtlcm4ubG9nc2lnZXhpdDogMQprZXJuLmlvdl9tYXg6IDEwMjQK a2Vybi5ob3N0dXVpZDogMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAyMTg1MzlkM2I5Cmtl cm4uY2FtLmNhbV9zcmNoX2hpOiAwCmtlcm4uY2FtLnNjc2lfZGVsYXk6IDUwMDAKa2Vybi5j YW0uZGEuZGFfc2VuZF9vcmRlcmVkOiAxCmtlcm4uY2FtLmRhLmRlZmF1bHRfdGltZW91dDog NjAKa2Vybi5jYW0uZGEucmV0cnlfY291bnQ6IDQKa2Vybi5kaXNrczogYWQxMAprZXJuLmdl b20uY29sbGVjdHN0YXRzOiAxCmtlcm4uZ2VvbS5kZWJ1Z2ZsYWdzOiAwCmtlcm4uZ2VvbS5s YWJlbC5kZWJ1ZzogMAprZXJuLmVsZjY0LmZhbGxiYWNrX2JyYW5kOiAtMQprZXJuLmluaXRf c2h1dGRvd25fdGltZW91dDogMTIwCmtlcm4uaW5pdF9wYXRoOiAvc2Jpbi9pbml0Oi9zYmlu L29pbml0Oi9zYmluL2luaXQuYmFrOi9yZXNjdWUvaW5pdDovc3RhbmQvc3lzaW5zdGFsbApr ZXJuLmFjY3Rfc3VzcGVuZGVkOiAwCmtlcm4uYWNjdF9jb25maWd1cmVkOiAwCmtlcm4uYWNj dF9jaGtmcmVxOiAxNQprZXJuLmFjY3RfcmVzdW1lOiA0Cmtlcm4uYWNjdF9zdXNwZW5kOiAy Cmtlcm4uY3BfdGltZXM6IDE5NDYxIDAgMjcwNyA3NjggMTI4NzA0IDE5NTY0IDAgMjgzMiAz MzkgMTI4OTAyCmtlcm4uY3BfdGltZTogMzkwMjUgMCA1NTM5IDExMDcgMjU3NjA2Cmtlcm4u b3BlbmZpbGVzOiA1NTkKa2Vybi5rcV9jYWxsb3V0bWF4OiA0MDk2Cmtlcm4ucHNfYXJnX2Nh Y2hlX2xpbWl0OiAyNTYKa2Vybi5zdGFja3Byb3Q6IDcKa2Vybi5yYW5kb21waWQ6IDAKa2Vy bi5sYXN0cGlkOiAxMTgzCmtlcm4ua3RyYWNlLnJlcXVlc3RfcG9vbDogMTAwCmtlcm4ua3Ry YWNlLmdlbmlvX3NpemU6IDQwOTYKa2Vybi5tb2R1bGVfcGF0aDogL2Jvb3Qva2VybmVsOy9i b290L21vZHVsZXMKa2Vybi5tYWxsb2NfY291bnQ6IDI1MQprZXJuLmZhbGxiYWNrX2VsZl9i cmFuZDogLTEKa2Vybi5mZWF0dXJlcy5jb21wYXRfZnJlZWJzZDY6IDEKa2Vybi5mZWF0dXJl cy5jb21wYXRfZnJlZWJzZDU6IDEKa2Vybi5mZWF0dXJlcy5jb21wYXRfZnJlZWJzZDQ6IDEK a2Vybi5tYXh1c2VyczogMzg0Cmtlcm4uaWRlbnQ6IGtlcm5lbAprZXJuLmtzdGFja19wYWdl czogNAprZXJuLnNodXRkb3duLmtwcm9jX3NodXRkb3duX3dhaXQ6IDYwCmtlcm4uc2h1dGRv d24ucG93ZXJvZmZfZGVsYXk6IDUwMDAKa2Vybi5zeW5jX29uX3BhbmljOiAwCmtlcm4uY29y ZWZpbGU6ICVOLmNvcmUKa2Vybi5ub2R1bXBfY29yZWR1bXA6IDAKa2Vybi5jb3JlZHVtcDog MQprZXJuLnN1Z2lkX2NvcmVkdW1wOiAwCmtlcm4uc2lncXVldWUuYWxsb2NfZmFpbDogMApr ZXJuLnNpZ3F1ZXVlLm92ZXJmbG93OiAwCmtlcm4uc2lncXVldWUucHJlYWxsb2NhdGU6IDEw MjQKa2Vybi5zaWdxdWV1ZS5tYXhfcGVuZGluZ19wZXJfcHJvYzogMTI4Cmtlcm4uZm9yY2Vz aWdleGl0OiAxCmtlcm4uZnNjYWxlOiAyMDQ4Cmtlcm4udGltZWNvdW50ZXIudGljazogMQpr ZXJuLnRpbWVjb3VudGVyLmNob2ljZTogVFNDKC0xMDApIEhQRVQoOTAwKSBBQ1BJLWZhc3Qo MTAwMCkgaTgyNTQoMCkgZHVtbXkoLTEwMDAwMDApCmtlcm4udGltZWNvdW50ZXIuaGFyZHdh cmU6IEFDUEktZmFzdAprZXJuLnRpbWVjb3VudGVyLnN0ZXB3YXJuaW5nczogMAprZXJuLnRp bWVjb3VudGVyLnRjLmk4MjU0Lm1hc2s6IDY1NTM1Cmtlcm4udGltZWNvdW50ZXIudGMuaTgy NTQuY291bnRlcjogNjA1OTQKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5mcmVxdWVuY3k6 IDExOTMxODIKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5xdWFsaXR5OiAwCmtlcm4udGlt ZWNvdW50ZXIudGMuQUNQSS1mYXN0Lm1hc2s6IDE2Nzc3MjE1Cmtlcm4udGltZWNvdW50ZXIu dGMuQUNQSS1mYXN0LmNvdW50ZXI6IDE5NzE2OTUKa2Vybi50aW1lY291bnRlci50Yy5BQ1BJ LWZhc3QuZnJlcXVlbmN5OiAzNTc5NTQ1Cmtlcm4udGltZWNvdW50ZXIudGMuQUNQSS1mYXN0 LnF1YWxpdHk6IDEwMDAKa2Vybi50aW1lY291bnRlci50Yy5IUEVULm1hc2s6IDQyOTQ5Njcy OTUKa2Vybi50aW1lY291bnRlci50Yy5IUEVULmNvdW50ZXI6IDM4NDkxNjk1MzkKa2Vybi50 aW1lY291bnRlci50Yy5IUEVULmZyZXF1ZW5jeTogMTQzMTgxODAKa2Vybi50aW1lY291bnRl ci50Yy5IUEVULnF1YWxpdHk6IDkwMAprZXJuLnRpbWVjb3VudGVyLnRjLlRTQy5tYXNrOiA0 Mjk0OTY3Mjk1Cmtlcm4udGltZWNvdW50ZXIudGMuVFNDLmNvdW50ZXI6IDIzMjk5OTUwNTEK a2Vybi50aW1lY291bnRlci50Yy5UU0MuZnJlcXVlbmN5OiAyNDkzNzYxMzEyCmtlcm4udGlt ZWNvdW50ZXIudGMuVFNDLnF1YWxpdHk6IC0xMDAKa2Vybi50aW1lY291bnRlci5zbXBfdHNj OiAwCmtlcm4udGltZWNvdW50ZXIuaW52YXJpYW50X3RzYzogMAprZXJuLnRocmVhZHMudmly dHVhbF9jcHU6IDIKa2Vybi50aHJlYWRzLm1heF90aHJlYWRzX2hpdHM6IDAKa2Vybi50aHJl YWRzLm1heF90aHJlYWRzX3Blcl9wcm9jOiAxNTAwCmtlcm4uY2NwdTogMAprZXJuLnNjaGVk LnByZWVtcHRpb246IDEKa2Vybi5zY2hlZC50b3BvbG9neTogMAprZXJuLnNjaGVkLnN0ZWFs X3RocmVzaDogMQprZXJuLnNjaGVkLnN0ZWFsX2lkbGU6IDEKa2Vybi5zY2hlZC5zdGVhbF9o dHQ6IDEKa2Vybi5zY2hlZC5iYWxhbmNlX2ludGVydmFsOiAxMzMKa2Vybi5zY2hlZC5iYWxh bmNlOiAxCmtlcm4uc2NoZWQudHJ5c2VsZjogMQprZXJuLnNjaGVkLmFmZmluaXR5OiAzCmtl cm4uc2NoZWQucGlja19wcmk6IDEKa2Vybi5zY2hlZC5wcmVlbXB0X3RocmVzaDogNjQKa2Vy bi5zY2hlZC5pbnRlcmFjdDogMzAKa2Vybi5zY2hlZC5zbGljZTogMTMKa2Vybi5zY2hlZC5u YW1lOiBVTEUKa2Vybi5kZXZzdGF0LnZlcnNpb246IDYKa2Vybi5kZXZzdGF0LmdlbmVyYXRp b246IDIzMwprZXJuLmRldnN0YXQubnVtZGV2czogMQprZXJuLmtvYmpfbWV0aG9kY291bnQ6 IDE1MwprZXJuLmxvZ193YWtldXBzX3Blcl9zZWNvbmQ6IDUKa2Vybi5zZ3Jvd3NpejogMTMx MDcyCmtlcm4ubWF4c3NpejogNTM2ODcwOTEyCmtlcm4uZGZsc3NpejogODM4ODYwOAprZXJu Lm1heGRzaXo6IDM0MzU5NzM4MzY4Cmtlcm4uZGZsZHNpejogMTM0MjE3NzI4Cmtlcm4ubWF4 dHNpejogMTM0MjE3NzI4Cmtlcm4ubWF4YmNhY2hlOiA0MTk0MzA0MDAKa2Vybi5tYXhzd3pv bmU6IDMzNTU0NDMyCmtlcm4ubnN3YnVmOiAyNTYKa2Vybi5uYnVmOiAyNTYwMAprZXJuLm5j YWxsb3V0OiAxODUwOAprZXJuLmh6OiAxMDAwCmtlcm4ubXNnYnVmX2NsZWFyOiAwCmtlcm4u bXNnYnVmOiAKa2Vybi5hbHdheXNfY29uc29sZV9vdXRwdXQ6IDAKa2Vybi5sb2dfY29uc29s ZV9vdXRwdXQ6IDEKa2Vybi5zbXAuZm9yd2FyZF9yb3VuZHJvYmluX2VuYWJsZWQ6IDEKa2Vy bi5zbXAuZm9yd2FyZF9zaWduYWxfZW5hYmxlZDogMQprZXJuLnNtcC5jcHVzOiAyCmtlcm4u c21wLmRpc2FibGVkOiAwCmtlcm4uc21wLmFjdGl2ZTogMQprZXJuLnNtcC5tYXhjcHVzOiAx NgprZXJuLnNtcC5tYXhpZDogMQprZXJuLm5zZWxjb2xsOiAwCmtlcm4udHR5X25vdXQ6IDE0 MDM2OQprZXJuLnR0eV9uaW46IDM4NTcKa2Vybi5kcmFpbndhaXQ6IDMwMAprZXJuLmNvbnN0 dHlfd2FrZXVwc19wZXJfc2Vjb25kOiA1Cmtlcm4uY29uc21zZ2J1Zl9zaXplOiA4MTkyCmtl cm4uY29uc211dGU6IDAKa2Vybi5jb25zb2xlOiBjb25zb2xlY3RsLC9jb25zb2xlY3RsLHR0 eWQwLAprZXJuLm1pbnZub2RlczogMjUwMDAKa2Vybi5tZXRhZGVsYXk6IDI4Cmtlcm4uZGly ZGVsYXk6IDI5Cmtlcm4uZmlsZWRlbGF5OiAzMAprZXJuLmNocm9vdF9hbGxvd19vcGVuX2Rp cmVjdG9yaWVzOiAxCmtlcm4ucnBjLmludmFsaWQ6IDAKa2Vybi5ycGMudW5leHBlY3RlZDog MAprZXJuLnJwYy50aW1lb3V0czogMAprZXJuLnJwYy5yZXF1ZXN0OiAwCmtlcm4ucnBjLnJl dHJpZXM6IDAKa2Vybi5lbGYzMi5mYWxsYmFja19icmFuZDogLTEKa2Vybi5yYW5kb20ueWFy cm93LmdlbmdhdGVpbnRlcnZhbDogMTAKa2Vybi5yYW5kb20ueWFycm93LmJpbnM6IDEwCmtl cm4ucmFuZG9tLnlhcnJvdy5mYXN0dGhyZXNoOiAxOTIKa2Vybi5yYW5kb20ueWFycm93LnNs b3d0aHJlc2g6IDI1NgprZXJuLnJhbmRvbS55YXJyb3cuc2xvd292ZXJ0aHJlc2g6IDIKa2Vy bi5yYW5kb20uc3lzLnNlZWRlZDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5ldGhlcm5l dDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5wb2ludF90b19wb2ludDogMQprZXJuLnJh bmRvbS5zeXMuaGFydmVzdC5pbnRlcnJ1cHQ6IDEKa2Vybi5yYW5kb20uc3lzLmhhcnZlc3Qu c3dpOiAwCnZtLnZtdG90YWw6IApTeXN0ZW0gd2lkZSB0b3RhbHMgY29tcHV0ZWQgZXZlcnkg Zml2ZSBzZWNvbmRzOiAodmFsdWVzIGluIGtpbG9ieXRlcykKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUHJvY2Vzc2VzOgkJKFJVTlE6IDEgRGlz ayBXYWl0OiAzIFBhZ2UgV2FpdDogMCBTbGVlcDogNzkpClZpcnR1YWwgTWVtb3J5OgkJKFRv dGFsOiAxMzU5MTM3NkssIEFjdGl2ZSA5NDQ2OTZLKQpSZWFsIE1lbW9yeToJCShUb3RhbDog NTE1Njc2SyBBY3RpdmUgNDQ1MjI0SykKU2hhcmVkIFZpcnR1YWwgTWVtb3J5OgkoVG90YWw6 IDExNTc2NEsgQWN0aXZlOiAxMTM5MTJLKQpTaGFyZWQgUmVhbCBNZW1vcnk6CShUb3RhbDog NjcwODBLIEFjdGl2ZTogNjY4MTJLKQpGcmVlIE1lbW9yeSBQYWdlczoJMzM5MzU5NksKCnZt LmxvYWRhdmc6IHsgMC4yNiAwLjI2IDAuMjAgfQp2bS52X2ZyZWVfbWluOiA2NDA5CnZtLnZf ZnJlZV90YXJnZXQ6IDI3MDAwCnZtLnZfZnJlZV9yZXNlcnZlZDogMTM2NAp2bS52X2luYWN0 aXZlX3RhcmdldDogNDA1MDAKdm0udl9jYWNoZV9taW46IDI3MDAwCnZtLnZfY2FjaGVfbWF4 OiA1NDAwMAp2bS52X3BhZ2VvdXRfZnJlZV9taW46IDM0CnZtLnBhZ2VvdXRfYWxnb3JpdGht OiAwCnZtLnN3YXBfZW5hYmxlZDogMQp2bS5rbWVtX3NpemVfc2NhbGU6IDMKdm0ua21lbV9z aXplX21heDogMzg2NTQ2ODEwOQp2bS5rbWVtX3NpemVfbWluOiAwCnZtLmttZW1fc2l6ZTog MTM3ODE4NTIxNgp2bS5uc3dhcGRldjogMQp2bS5kbW1heDogMzIKdm0uc3dhcF9hc3luY19t YXg6IDQKdm0uem9uZV9jb3VudDogMTAyCnZtLnN3YXBfaWRsZV90aHJlc2hvbGQyOiAxMAp2 bS5zd2FwX2lkbGVfdGhyZXNob2xkMTogMgp2bS5leGVjX21hcF9lbnRyaWVzOiAxNgp2bS5z dGF0cy5taXNjLnplcm9fcGFnZV9jb3VudDogMjY2CnZtLnN0YXRzLm1pc2MuY250X3ByZXpl cm86IDAKdm0uc3RhdHMudm0udl9rdGhyZWFkcGFnZXM6IDAKdm0uc3RhdHMudm0udl9yZm9y a3BhZ2VzOiAwCnZtLnN0YXRzLnZtLnZfdmZvcmtwYWdlczogMTE2NTUKdm0uc3RhdHMudm0u dl9mb3JrcGFnZXM6IDI4MDM2MQp2bS5zdGF0cy52bS52X2t0aHJlYWRzOiA1NAp2bS5zdGF0 cy52bS52X3Jmb3JrczogMAp2bS5zdGF0cy52bS52X3Zmb3JrczogNDgKdm0uc3RhdHMudm0u dl9mb3JrczogMTA4MQp2bS5zdGF0cy52bS52X2ludGVycnVwdF9mcmVlX21pbjogMgp2bS5z dGF0cy52bS52X3BhZ2VvdXRfZnJlZV9taW46IDM0CnZtLnN0YXRzLnZtLnZfY2FjaGVfbWF4 OiA1NDAwMAp2bS5zdGF0cy52bS52X2NhY2hlX21pbjogMjcwMDAKdm0uc3RhdHMudm0udl9j YWNoZV9jb3VudDogMTYzNAp2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50OiAzNzQ5OAp2 bS5zdGF0cy52bS52X2luYWN0aXZlX3RhcmdldDogNDA1MDAKdm0uc3RhdHMudm0udl9hY3Rp dmVfY291bnQ6IDcxNzkyCnZtLnN0YXRzLnZtLnZfd2lyZV9jb3VudDogNTE1NDYKdm0uc3Rh dHMudm0udl9mcmVlX2NvdW50OiA4NDY3NjUKdm0uc3RhdHMudm0udl9mcmVlX21pbjogNjQw OQp2bS5zdGF0cy52bS52X2ZyZWVfdGFyZ2V0OiAyNzAwMAp2bS5zdGF0cy52bS52X2ZyZWVf cmVzZXJ2ZWQ6IDEzNjQKdm0uc3RhdHMudm0udl9wYWdlX2NvdW50OiAxMDA5NDE0CnZtLnN0 YXRzLnZtLnZfcGFnZV9zaXplOiA0MDk2CnZtLnN0YXRzLnZtLnZfdGZyZWU6IDE3NDQ0NzcK dm0uc3RhdHMudm0udl9wZnJlZTogNDc4NDc4CnZtLnN0YXRzLnZtLnZfZGZyZWU6IDAKdm0u c3RhdHMudm0udl90Y2FjaGVkOiAzMTE4CnZtLnN0YXRzLnZtLnZfcGRwYWdlczogMAp2bS5z dGF0cy52bS52X3Bkd2FrZXVwczogMAp2bS5zdGF0cy52bS52X3JlYWN0aXZhdGVkOiAxMzgz CnZtLnN0YXRzLnZtLnZfaW50cmFuczogMjg2CnZtLnN0YXRzLnZtLnZfdm5vZGVwZ3NvdXQ6 IDAKdm0uc3RhdHMudm0udl92bm9kZXBnc2luOiAyNTQ4Mwp2bS5zdGF0cy52bS52X3Zub2Rl b3V0OiAwCnZtLnN0YXRzLnZtLnZfdm5vZGVpbjogMjcxNQp2bS5zdGF0cy52bS52X3N3YXBw Z3NvdXQ6IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0udl9zd2Fw b3V0OiAwCnZtLnN0YXRzLnZtLnZfc3dhcGluOiAwCnZtLnN0YXRzLnZtLnZfb3pmb2Q6IDAK dm0uc3RhdHMudm0udl96Zm9kOiAxNzIxMDkxCnZtLnN0YXRzLnZtLnZfY293X29wdGltOiAz NjAKdm0uc3RhdHMudm0udl9jb3dfZmF1bHRzOiA1ODQ4Nwp2bS5zdGF0cy52bS52X3ZtX2Zh dWx0czogMTg3NjYxNwp2bS5zdGF0cy5zeXMudl9zb2Z0OiAzMzg0NDMKdm0uc3RhdHMuc3lz LnZfaW50cjogMTQ5ODY3CnZtLnN0YXRzLnN5cy52X3N5c2NhbGw6IDIyMzk5NTAwCnZtLnN0 YXRzLnN5cy52X3RyYXA6IDI2Nzc0MjQKdm0uc3RhdHMuc3lzLnZfc3d0Y2g6IDk3NDM1OTcK dm0uc3RhdHMub2JqZWN0LmJ5cGFzc2VzOiA3MTcKdm0uc3RhdHMub2JqZWN0LmNvbGxhcHNl czogNDcyOQp2bS52X2ZyZWVfc2V2ZXJlOiAzODg2CnZtLm1heF9wcm9jX21tYXA6IDEyMzA1 Mgp2bS5vbGRfbXN5bmM6IDAKdm0ubXN5bmNfZmx1c2hfZmxhZ3M6IDMKdm0uYm9vdF9wYWdl czogNDgKdm0ubWF4X3dpcmVkOiAzMzA1MDkKdm0ucGFnZW91dF9sb2NrX21pc3M6IDAKdm0u ZGlzYWJsZV9zd2Fwc3BhY2VfcGFnZW91dHM6IDAKdm0uZGVmZXJfc3dhcHNwYWNlX3BhZ2Vv dXRzOiAwCnZtLnN3YXBfaWRsZV9lbmFibGVkOiAwCnZtLnBhZ2VvdXRfc3RhdHNfaW50ZXJ2 YWw6IDUKdm0ucGFnZW91dF9mdWxsX3N0YXRzX2ludGVydmFsOiAyMAp2bS5wYWdlb3V0X3N0 YXRzX21heDogMjcwMDAKdm0ubWF4X2xhdW5kZXI6IDMyCnZtLnBoeXNfc2VnczogClNFR01F TlQgMDoKCnN0YXJ0OiAgICAgMHgxMDAwCmVuZDogICAgICAgMHg5YzAwMApmcmVlIGxpc3Q6 IDB4ZmZmZmZmZmY4MDdkMGNjOAoKU0VHTUVOVCAxOgoKc3RhcnQ6ICAgICAweDkwYjAwMApl bmQ6ICAgICAgIDB4MTAwMDAwMApmcmVlIGxpc3Q6IDB4ZmZmZmZmZmY4MDdkMGNjOAoKU0VH TUVOVCAyOgoKc3RhcnQ6ICAgICAweDEwMDAwMDAKZW5kOiAgICAgICAweGM2ZTFjMDAwCmZy ZWUgbGlzdDogMHhmZmZmZmZmZjgwN2QwOTIwCgpTRUdNRU5UIDM6CgpzdGFydDogICAgIDB4 Y2ZkOTYwMDAKZW5kOiAgICAgICAweGNmZjAwMDAwCmZyZWUgbGlzdDogMHhmZmZmZmZmZjgw N2QwOTIwCgpTRUdNRU5UIDQ6CgpzdGFydDogICAgIDB4MTAwMDAwMDAwCmVuZDogICAgICAg MHgxMmZmZjAwMDAKZnJlZSBsaXN0OiAweGZmZmZmZmZmODA3ZDA5MjAKCnZtLnBoeXNfZnJl ZTogCkZSRUUgTElTVCAwOgoKICBPUkRFUiAoU0laRSkgIHwgIE5VTUJFUgogICAgICAgICAg ICAgICAgfCAgUE9PTCAwICB8ICBQT09MIDEgIHwgIFBPT0wgMgotLSAgICAgICAgICAgIC0t IC0tICAgICAgLS0gLS0gICAgICAtLSAtLSAgICAgIC0tCiAgMTIgKCAxNjM4NEspICB8ICAg ICAxODQgIHwgICAgICAgMCAgfCAgICAgICAwCiAgMTEgKCAgODE5MkspICB8ICAgICAgIDEg IHwgICAgICAgMCAgfCAgICAgICAwCiAgMTAgKCAgNDA5NkspICB8ICAgICAgIDggIHwgICAg ICAgMSAgfCAgICAgICAwCiAgIDkgKCAgMjA0OEspICB8ICAgICAgIDkgIHwgICAgICAgMCAg fCAgICAgICAxCiAgIDggKCAgMTAyNEspICB8ICAgICAgIDEgIHwgICAgICAgMSAgfCAgICAg ICAwCiAgIDcgKCAgIDUxMkspICB8ICAgICAgIDAgIHwgICAgICAgMCAgfCAgICAgICAwCiAg IDYgKCAgIDI1NkspICB8ICAgICAgMTIgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDUgKCAg IDEyOEspICB8ICAgICAgMTYgIHwgICAgICAgMSAgfCAgICAgICAxCiAgIDQgKCAgICA2NEsp ICB8ICAgICAgNDQgIHwgICAgICAgNSAgfCAgICAgICA0CiAgIDMgKCAgICAzMkspICB8ICAg ICAgNjMgIHwgICAgICAxNCAgfCAgICAgIDI0CiAgIDIgKCAgICAxNkspICB8ICAgICAxNjcg IHwgICAgICAyMyAgfCAgICAgIDMyCiAgIDEgKCAgICAgOEspICB8ICAgICAgNjkgIHwgICAg ICAzNyAgfCAgICAgIDM5CiAgIDAgKCAgICAgNEspICB8ICAgICAgIDAgIHwgICAgICAyNyAg fCAgICAgIDQ2CgpGUkVFIExJU1QgMToKCiAgT1JERVIgKFNJWkUpICB8ICBOVU1CRVIKICAg ICAgICAgICAgICAgIHwgIFBPT0wgMCAgfCAgUE9PTCAxICB8ICBQT09MIDIKLS0gICAgICAg ICAgICAtLSAtLSAgICAgIC0tIC0tICAgICAgLS0gLS0gICAgICAtLQogIDEyICggMTYzODRL KSAgfCAgICAgICAwICB8ICAgICAgIDAgIHwgICAgICAgMAogIDExICggIDgxOTJLKSAgfCAg ICAgICAwICB8ICAgICAgIDAgIHwgICAgICAgMAogIDEwICggIDQwOTZLKSAgfCAgICAgICAx ICB8ICAgICAgIDAgIHwgICAgICAgMAogICA5ICggIDIwNDhLKSAgfCAgICAgICAxICB8ICAg ICAgIDAgIHwgICAgICAgMAogICA4ICggIDEwMjRLKSAgfCAgICAgICAwICB8ICAgICAgIDAg IHwgICAgICAgMAogICA3ICggICA1MTJLKSAgfCAgICAgICAxICB8ICAgICAgIDAgIHwgICAg ICAgMAogICA2ICggICAyNTZLKSAgfCAgICAgICAyICB8ICAgICAgIDAgIHwgICAgICAgMAog ICA1ICggICAxMjhLKSAgfCAgICAgICAyICB8ICAgICAgIDAgIHwgICAgICAgMAogICA0ICgg ICAgNjRLKSAgfCAgICAgICAzICB8ICAgICAgIDAgIHwgICAgICAgMAogICAzICggICAgMzJL KSAgfCAgICAgICAyICB8ICAgICAgIDAgIHwgICAgICAgMAogICAyICggICAgMTZLKSAgfCAg ICAgICAzICB8ICAgICAgIDAgIHwgICAgICAgMAogICAxICggICAgIDhLKSAgfCAgICAgICAx ICB8ICAgICAgIDAgIHwgICAgICAgMAogICAwICggICAgIDRLKSAgfCAgICAgICAyICB8ICAg ICAgIDAgIHwgICAgICAgMAoKdm0ucmVzZXJ2LnJlY2xhaW1lZDogMAp2bS5yZXNlcnYucGFy dHBvcHE6IApMRVZFTCAgICAgU0laRSAgTlVNQkVSCgogICAtMTogMjg2MzQ4SywgICAgMjI5 Cgp2bS5yZXNlcnYuZnJlZWQ6IDQ4MTEKdm0ucmVzZXJ2LmJyb2tlbjogMAp2bS5pZGxlemVy b19lbmFibGU6IDAKdm0ua3ZtX2ZyZWU6IDQ0MTQ1MDA4NjQKdm0ua3ZtX3NpemU6IDY0NDI0 NDY4NDgKdm0ucG1hcC5wbWFwX2NvbGxlY3RfYWN0aXZlOiAwCnZtLnBtYXAucG1hcF9jb2xs ZWN0X2luYWN0aXZlOiAwCnZtLnBtYXAucHZfZW50cnlfc3BhcmU6IDc1MDQKdm0ucG1hcC5w dl9lbnRyeV9hbGxvY3M6IDI5NzgwNzMKdm0ucG1hcC5wdl9lbnRyeV9mcmVlczogMjc5NDg5 Nwp2bS5wbWFwLnBjX2NodW5rX3RyeWZhaWw6IDAKdm0ucG1hcC5wY19jaHVua19mcmVlczog MTA0NDIKdm0ucG1hcC5wY19jaHVua19hbGxvY3M6IDExNTc3CnZtLnBtYXAucGNfY2h1bmtf Y291bnQ6IDExMzUKdm0ucG1hcC5wdl9lbnRyeV9jb3VudDogMTgzMTc2CnZtLnBtYXAucGRl LnByb21vdGlvbnM6IDAKdm0ucG1hcC5wZGUucF9mYWlsdXJlczogMAp2bS5wbWFwLnBkZS5t YXBwaW5nczogMAp2bS5wbWFwLnBkZS5kZW1vdGlvbnM6IDAKdm0ucG1hcC5zaHBncGVycHJv YzogMjAwCnZtLnBtYXAucHZfZW50cnlfbWF4OiAyMjQyMjE0CnZtLnBtYXAucGdfcHNfZW5h YmxlZDogMAp2ZnMubmZzLmRvd25kZWxheWluaXRpYWw6IDEyCnZmcy5uZnMuZG93bmRlbGF5 aW50ZXJ2YWw6IDMwCnZmcy5uZnMuc2tpcF93Y2NfZGF0YV9vbmVycjogMQp2ZnMubmZzLm5m czNfanVrZWJveF9kZWxheTogMTAKdmZzLm5mcy5yZWNvbm5lY3RzOiAwCnZmcy5uZnMuYnVm cGFja2V0czogNAp2ZnMubmZzLnJlYWxpZ25fY291bnQ6IDAKdmZzLm5mcy5yZWFsaWduX3Rl c3Q6IDAKdmZzLm5mcy5kZWZlY3Q6IDAKdmZzLm5mcy5pb2RtYXg6IDIwCnZmcy5uZnMuaW9k bWluOiAwCnZmcy5uZnMuaW9kbWF4aWRsZTogMTIwCnZmcy5uZnMuZGlza2xlc3Nfcm9vdHBh dGg6IAp2ZnMubmZzLmRpc2tsZXNzX3ZhbGlkOiAwCnZmcy5uZnMubmZzX2lwX3BhcmFub2lh OiAxCnZmcy5uZnMubmZzX2RpcmVjdGlvX2FsbG93X21tYXA6IDEKdmZzLm5mcy5uZnNfZGly ZWN0aW9fZW5hYmxlOiAwCnZmcy5uZnMuY2xlYW5fcGFnZXNfb25fY2xvc2U6IDEKdmZzLm5m cy5uZnN2M19jb21taXRfb25fY2xvc2U6IDAKdmZzLm5mcy5wcmltZV9hY2Nlc3NfY2FjaGU6 IDEKdmZzLm5mcy5hY2Nlc3NfY2FjaGVfdGltZW91dDogNjAKdmZzLnVmcy5kaXJoYXNoX2Rv Y2hlY2s6IDAKdmZzLnVmcy5kaXJoYXNoX21lbTogMjY2NzcwCnZmcy51ZnMuZGlyaGFzaF9t YXhtZW06IDIwOTcxNTIKdmZzLnVmcy5kaXJoYXNoX21pbnNpemU6IDI1NjAKdmZzLmRldmZz LnJ1bGVfZGVwdGg6IDEKdmZzLmRldmZzLmdlbmVyYXRpb246IDEzOQp2ZnMubmZzNC5hY2Nl c3NfY2FjaGVfdGltZW91dDogNjAKdmZzLnBmcy50cmFjZTogMAp2ZnMucGZzLnZuY2FjaGUu bWlzc2VzOiAwCnZmcy5wZnMudm5jYWNoZS5oaXRzOiAwCnZmcy5wZnMudm5jYWNoZS5tYXhl bnRyaWVzOiAwCnZmcy5wZnMudm5jYWNoZS5lbnRyaWVzOiAwCnZmcy5mbHVzaHdpdGhkZXBz OiAwCnZmcy5nZXRuZXdidWZyZXN0YXJ0czogMAp2ZnMuZ2V0bmV3YnVmY2FsbHM6IDk0NDgK dmZzLmhpZnJlZWJ1ZmZlcnM6IDI4NTQKdmZzLmxvZnJlZWJ1ZmZlcnM6IDE0MjcKdmZzLm51 bWZyZWVidWZmZXJzOiAyNTUyOQp2ZnMuZGlydHlidWZ0aHJlc2g6IDU3NzgKdmZzLmhpZGly dHlidWZmZXJzOiA2NDIwCnZmcy5sb2RpcnR5YnVmZmVyczogMzIxMAp2ZnMubnVtZGlydHli dWZmZXJzOiA3MQp2ZnMucmVjdXJzaXZlZmx1c2hlczogMTkzMQp2ZnMuYWx0YnVmZmVyZmx1 c2hlczogMAp2ZnMuYmR3cml0ZXNraXA6IDAKdmZzLmRpcnR5YnVmZmVyZmx1c2hlczogMAp2 ZnMuaGlydW5uaW5nc3BhY2U6IDEwNDg1NzYKdmZzLmxvcnVubmluZ3NwYWNlOiA1MjQyODgK dmZzLmJ1ZmRlZnJhZ2NudDogMAp2ZnMuYnVmZnJlZWt2YWNudDogMAp2ZnMuYnVmcmV1c2Vj bnQ6IDc5NzIKdmZzLmhpYnVmc3BhY2U6IDQxODc3NTA0MAp2ZnMubG9idWZzcGFjZTogNDE4 NzA5NTA0CnZmcy5tYXhtYWxsb2NidWZzcGFjZTogMjA5Mzg3NTIKdmZzLmJ1Zm1hbGxvY3Nw YWNlOiAxMDI0MAp2ZnMubWF4YnVmc3BhY2U6IDQxOTQzMDQwMAp2ZnMuYnVmc3BhY2U6IDEz MDYxMzI0OAp2ZnMucnVubmluZ2J1ZnNwYWNlOiAwCnZmcy52bWlvZGlyZW5hYmxlOiAxCnZm cy5jYWNoZS5udW1mdWxscGF0aGZvdW5kOiAxNTAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFp bDQ6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDI6IDAKdmZzLmNhY2hlLm51bWZ1bGxw YXRoZmFpbDE6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoY2FsbHM6IDE1MAp2ZnMuY2FjaGUu bmNoc3RhdHM6IDI0MjE4MiAxOTI0OCAzODMgMCA5NTUyIDAgMjg1IDEyNDUKdmZzLmNhY2hl Lm51bW5lZ2hpdHM6IDE5MjQ4CnZmcy5jYWNoZS5udW1uZWd6YXBzOiAxODUKdmZzLmNhY2hl Lm51bXBvc2hpdHM6IDI0MjIwMAp2ZnMuY2FjaGUubnVtcG9zemFwczogMTk4CnZmcy5jYWNo ZS5udW1taXNzemFwOiAyODMKdmZzLmNhY2hlLm51bW1pc3M6IDkyNjkKdmZzLmNhY2hlLm51 bWNoZWNrczogMjYyMzcwCnZmcy5jYWNoZS5kb3Rkb3RoaXRzOiAxMjk2CnZmcy5jYWNoZS5k b3RoaXRzOiAyNzMKdmZzLmNhY2hlLm51bWNhbGxzOiAyNzI5NzYKdmZzLmNhY2hlLm51bWNh Y2hlOiAzNjExCnZmcy5jYWNoZS5udW1uZWc6IDIyNAp2ZnMucmVhZF9tYXg6IDgKdmZzLndy aXRlX2JlaGluZDogMQp2ZnMubG9va3VwX3NoYXJlZDogMAp2ZnMudXNlcm1vdW50OiAwCnZm cy53b3JrbGlzdF9sZW46IDEyCnZmcy50aW1lc3RhbXBfcHJlY2lzaW9uOiAwCnZmcy5yZWFz c2lnbmJ1ZmNhbGxzOiAxNTYzNwp2ZnMuZnJlZXZub2RlczogNjg5CnZmcy53YW50ZnJlZXZu b2RlczogMjUwMDAKdmZzLm51bXZub2RlczogMzUzNgp2ZnMubmZzcnYubmZzX3ByaXZwb3J0 OiAwCnZmcy5uZnNydi5jb21taXRfbWlzczogMAp2ZnMubmZzcnYuY29tbWl0X2Jsa3M6IDAK dmZzLm5mc3J2LmFzeW5jOiAwCnZmcy5uZnNydi5yZWFsaWduX2NvdW50OiAwCnZmcy5uZnNy di5yZWFsaWduX3Rlc3Q6IDAKdmZzLm5mc3J2LmdhdGhlcmRlbGF5X3YzOiAwCnZmcy5uZnNy di5nYXRoZXJkZWxheTogMTAwMDAKdmZzLmZmcy5kb3JlYWxsb2NibGtzOiAxCnZmcy5mZnMu ZG9hc3luY2ZyZWU6IDEKdmZzLmZmcy5jb21wdXRlX3N1bW1hcnlfYXRfbW91bnQ6IDAKdmZz LmZ1c2Uua2VybmVsYWJpX21pbm9yOiA4CnZmcy5mdXNlLmtlcm5lbGFiaV9tYWpvcjogNwp2 ZnMuZnVzZS5tYXh0aWNrZXRzOiAwCnZmcy5mdXNlLmlvdl9jcmVkaXQ6IDE2CnZmcy5mdXNl Lmlvdl9wZXJtYW5lbnRfYnVmc2l6ZTogNTI0Mjg4CnZmcy5mdXNlLm1heGZyZWV0aWNrZXRz OiAxMDI0CnZmcy5mdXNlLmZ1c2U0YnNkX3ZlcnNpb246IDAuMy45LXByZTEKdmZzLmZ1c2Uu c3luY191bm1vdW50OiAxCnZmcy5mdXNlLmVuZm9yY2VfZGV2X3Blcm1zOiAwCnZmcy5mdXNl LmluaXRfYmFja2dyb3VuZGVkOiAxCm5ldC5sb2NhbC5zdHJlYW0ucmVjdnNwYWNlOiA4MTky Cm5ldC5sb2NhbC5zdHJlYW0uc2VuZHNwYWNlOiA4MTkyCm5ldC5sb2NhbC5kZ3JhbS5yZWN2 c3BhY2U6IDQwOTYKbmV0LmxvY2FsLmRncmFtLm1heGRncmFtOiAyMDQ4Cm5ldC5sb2NhbC5y ZWN5Y2xlZDogMApuZXQubG9jYWwudGFza2NvdW50OiAwCm5ldC5sb2NhbC5pbmZsaWdodDog MApuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9tdGltZTogNDUKbmV0LmluZXQuaXAucG9y dHJhbmdlLnJhbmRvbWNwczogMTAKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbWl6ZWQ6 IDEKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJlc2VydmVkbG93OiAwCm5ldC5pbmV0LmlwLnBv cnRyYW5nZS5yZXNlcnZlZGhpZ2g6IDEwMjMKbmV0LmluZXQuaXAucG9ydHJhbmdlLmhpbGFz dDogNjU1MzUKbmV0LmluZXQuaXAucG9ydHJhbmdlLmhpZmlyc3Q6IDQ5MTUyCm5ldC5pbmV0 LmlwLnBvcnRyYW5nZS5sYXN0OiA2NTUzNQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuZmlyc3Q6 IDQ5MTUyCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5sb3dsYXN0OiA2MDAKbmV0LmluZXQuaXAu cG9ydHJhbmdlLmxvd2ZpcnN0OiAxMDIzCm5ldC5pbmV0LmlwLmZvcndhcmRpbmc6IDAKbmV0 LmluZXQuaXAucmVkaXJlY3Q6IDEKbmV0LmluZXQuaXAudHRsOiA2NApuZXQuaW5ldC5pcC5y dGV4cGlyZTogMzYwMApuZXQuaW5ldC5pcC5ydG1pbmV4cGlyZTogMTAKbmV0LmluZXQuaXAu cnRtYXhjYWNoZTogMTI4Cm5ldC5pbmV0LmlwLnNvdXJjZXJvdXRlOiAwCm5ldC5pbmV0Lmlw LmludHJfcXVldWVfbWF4bGVuOiA1MApuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX2Ryb3BzOiAw Cm5ldC5pbmV0LmlwLmFjY2VwdF9zb3VyY2Vyb3V0ZTogMApuZXQuaW5ldC5pcC5rZWVwZmFp dGg6IDAKbmV0LmluZXQuaXAuZ2lmdHRsOiAzMApuZXQuaW5ldC5pcC5zYW1lX3ByZWZpeF9j YXJwX29ubHk6IDAKbmV0LmluZXQuaXAuc3VibmV0c19hcmVfbG9jYWw6IDAKbmV0LmluZXQu aXAuZmFzdGZvcndhcmRpbmc6IDAKbmV0LmluZXQuaXAubWF4ZnJhZ3BhY2tldHM6IDgwMApu ZXQuaW5ldC5pcC5tYXhmcmFnc3BlcnBhY2tldDogMTYKbmV0LmluZXQuaXAuZnJhZ3BhY2tl dHM6IDAKbmV0LmluZXQuaXAuY2hlY2tfaW50ZXJmYWNlOiAwCm5ldC5pbmV0LmlwLnJhbmRv bV9pZDogMApuZXQuaW5ldC5pcC5zZW5kc291cmNlcXVlbmNoOiAwCm5ldC5pbmV0LmlwLnBy b2Nlc3Nfb3B0aW9uczogMQpuZXQuaW5ldC5pY21wLm1hc2tyZXBsOiAwCm5ldC5pbmV0Lmlj bXAuaWNtcGxpbTogMjAwCm5ldC5pbmV0LmljbXAuYm1jYXN0ZWNobzogMApuZXQuaW5ldC5p Y21wLnF1b3RlbGVuOiA4Cm5ldC5pbmV0LmljbXAucmVwbHlfZnJvbV9pbnRlcmZhY2U6IDAK bmV0LmluZXQuaWNtcC5yZXBseV9zcmM6IApuZXQuaW5ldC5pY21wLmljbXBsaW1fb3V0cHV0 OiAxCm5ldC5pbmV0LmljbXAubG9nX3JlZGlyZWN0OiAwCm5ldC5pbmV0LmljbXAuZHJvcF9y ZWRpcmVjdDogMApuZXQuaW5ldC5pY21wLm1hc2tmYWtlOiAwCm5ldC5pbmV0LnRjcC5yZmMx MzIzOiAxCm5ldC5pbmV0LnRjcC5tc3NkZmx0OiA1MTIKbmV0LmluZXQudGNwLmtlZXBpZGxl OiA3MjAwMDAwCm5ldC5pbmV0LnRjcC5rZWVwaW50dmw6IDc1MDAwCm5ldC5pbmV0LnRjcC5z ZW5kc3BhY2U6IDMyNzY4Cm5ldC5pbmV0LnRjcC5yZWN2c3BhY2U6IDY1NTM2Cm5ldC5pbmV0 LnRjcC5rZWVwaW5pdDogNzUwMDAKbmV0LmluZXQudGNwLmRlbGFja3RpbWU6IDEwMApuZXQu aW5ldC50Y3AudjZtc3NkZmx0OiAxMDI0Cm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHVyZ2U6 IDAKbmV0LmluZXQudGNwLmhvc3RjYWNoZS5wcnVuZTogMzAwCm5ldC5pbmV0LnRjcC5ob3N0 Y2FjaGUuZXhwaXJlOiAzNjAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuY291bnQ6IDMyCm5l dC5pbmV0LnRjcC5ob3N0Y2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5pbmV0LnRjcC5ob3N0 Y2FjaGUuaGFzaHNpemU6IDUxMgpuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmNhY2hlbGltaXQ6 IDE1MzYwCm5ldC5pbmV0LnRjcC5yZWN2YnVmX21heDogMjYyMTQ0Cm5ldC5pbmV0LnRjcC5y ZWN2YnVmX2luYzogMTYzODQKbmV0LmluZXQudGNwLnJlY3ZidWZfYXV0bzogMQpuZXQuaW5l dC50Y3AuaW5zZWN1cmVfcnN0OiAwCm5ldC5pbmV0LnRjcC5yZmMzMzkwOiAxCm5ldC5pbmV0 LnRjcC5yZmMzMDQyOiAxCm5ldC5pbmV0LnRjcC5kcm9wX3N5bmZpbjogMApuZXQuaW5ldC50 Y3AuZGVsYXllZF9hY2s6IDEKbmV0LmluZXQudGNwLmJsYWNraG9sZTogMApuZXQuaW5ldC50 Y3AubG9nX2luX3ZhaW46IDAKbmV0LmluZXQudGNwLnNlbmRidWZfbWF4OiAyNjIxNDQKbmV0 LmluZXQudGNwLnNlbmRidWZfaW5jOiA4MTkyCm5ldC5pbmV0LnRjcC5zZW5kYnVmX2F1dG86 IDEKbmV0LmluZXQudGNwLnRzbzogMQpuZXQuaW5ldC50Y3AubmV3cmVubzogMQpuZXQuaW5l dC50Y3AubG9jYWxfc2xvd3N0YXJ0X2ZsaWdodHNpemU6IDQKbmV0LmluZXQudGNwLnNsb3dz dGFydF9mbGlnaHRzaXplOiAxCm5ldC5pbmV0LnRjcC5wYXRoX210dV9kaXNjb3Zlcnk6IDEK bmV0LmluZXQudGNwLnJlYXNzLm92ZXJmbG93czogMApuZXQuaW5ldC50Y3AucmVhc3MubWF4 cWxlbjogNDgKbmV0LmluZXQudGNwLnJlYXNzLmN1cnNlZ21lbnRzOiAwCm5ldC5pbmV0LnRj cC5yZWFzcy5tYXhzZWdtZW50czogMTYwMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxob2xl czogMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxtYXhob2xlczogNjU1MzYKbmV0LmluZXQu dGNwLnNhY2subWF4aG9sZXM6IDEyOApuZXQuaW5ldC50Y3Auc2Fjay5lbmFibGU6IDEKbmV0 LmluZXQudGNwLmluZmxpZ2h0LnN0YWI6IDIwCm5ldC5pbmV0LnRjcC5pbmZsaWdodC5tYXg6 IDEwNzM3MjU0NDAKbmV0LmluZXQudGNwLmluZmxpZ2h0Lm1pbjogNjE0NApuZXQuaW5ldC50 Y3AuaW5mbGlnaHQucnR0dGhyZXNoOiAxMApuZXQuaW5ldC50Y3AuaW5mbGlnaHQuZGVidWc6 IDAKbmV0LmluZXQudGNwLmluZmxpZ2h0LmVuYWJsZTogMQpuZXQuaW5ldC50Y3AuaXNuX3Jl c2VlZF9pbnRlcnZhbDogMApuZXQuaW5ldC50Y3AuaWNtcF9tYXlfcnN0OiAxCm5ldC5pbmV0 LnRjcC5wY2Jjb3VudDogMTEKbmV0LmluZXQudGNwLmRvX3RjcGRyYWluOiAxCm5ldC5pbmV0 LnRjcC50Y2JoYXNoc2l6ZTogNTEyCm5ldC5pbmV0LnRjcC5sb2dfZGVidWc6IDAKbmV0Lmlu ZXQudGNwLm1pbm1zczogMjE2Cm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5yc3Rfb25fc29ja19m YWlsOiAxCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5yZXhtdGxpbWl0OiAzCm5ldC5pbmV0LnRj cC5zeW5jYWNoZS5oYXNoc2l6ZTogNTEyCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5jb3VudDog MApuZXQuaW5ldC50Y3Auc3luY2FjaGUuY2FjaGVsaW1pdDogMTUzNjAKbmV0LmluZXQudGNw LnN5bmNhY2hlLmJ1Y2tldGxpbWl0OiAzMApuZXQuaW5ldC50Y3Auc3luY29va2llc19vbmx5 OiAwCm5ldC5pbmV0LnRjcC5zeW5jb29raWVzOiAxCm5ldC5pbmV0LnRjcC50aW1lcl9yYWNl OiAwCm5ldC5pbmV0LnRjcC5maW53YWl0Ml90aW1lb3V0OiA2MDAwMApuZXQuaW5ldC50Y3Au ZmFzdF9maW53YWl0Ml9yZWN5Y2xlOiAwCm5ldC5pbmV0LnRjcC5hbHdheXNfa2VlcGFsaXZl OiAxCm5ldC5pbmV0LnRjcC5yZXhtaXRfc2xvcDogMjAwCm5ldC5pbmV0LnRjcC5yZXhtaXRf bWluOiAzMApuZXQuaW5ldC50Y3AubXNsOiAzMDAwMApuZXQuaW5ldC50Y3Aubm9sb2NhbHRp bWV3YWl0OiAwCm5ldC5pbmV0LnRjcC5tYXh0Y3B0dzogNTEyMApuZXQuaW5ldC51ZHAuY2hl Y2tzdW06IDEKbmV0LmluZXQudWRwLm1heGRncmFtOiA5MjE2Cm5ldC5pbmV0LnVkcC5yZWN2 c3BhY2U6IDQyMDgwCm5ldC5pbmV0LnVkcC5zb3JlY2VpdmVfZGdyYW1fZW5hYmxlZDogMQpu ZXQuaW5ldC51ZHAuYmxhY2tob2xlOiAwCm5ldC5pbmV0LnVkcC5sb2dfaW5fdmFpbjogMApu ZXQuaW5ldC5zY3RwLm5hdF9mcmllbmRseV9pbml0OiAxCm5ldC5pbmV0LnNjdHAuZW5hYmxl X3NhY2tfaW1tZWRpYXRlbHk6IDAKbmV0LmluZXQuc2N0cC51ZHBfdHVubmVsaW5nX3BvcnQ6 IDAKbmV0LmluZXQuc2N0cC51ZHBfdHVubmVsaW5nX2Zvcl9jbGllbnRfZW5hYmxlOiAwCm5l dC5pbmV0LnNjdHAubW9iaWxpdHlfZmFzdGhhbmRvZmY6IDAKbmV0LmluZXQuc2N0cC5tb2Jp bGl0eV9iYXNlOiAwCm5ldC5pbmV0LnNjdHAuZGVmYXVsdF9mcmFnX2ludGVybGVhdmU6IDEK bmV0LmluZXQuc2N0cC5kZWZhdWx0X2NjX21vZHVsZTogMApuZXQuaW5ldC5zY3RwLmxvZ19s ZXZlbDogMApuZXQuaW5ldC5zY3RwLm1heF9yZXRyYW5fY2h1bms6IDMwCm5ldC5pbmV0LnNj dHAubWluX3Jlc2lkdWFsOiAxNDUyCm5ldC5pbmV0LnNjdHAuc3RyaWN0X2RhdGFfb3JkZXI6 IDAKbmV0LmluZXQuc2N0cC5hYm9ydF9hdF9saW1pdDogMApuZXQuaW5ldC5zY3RwLmhiX21h eF9idXJzdDogNApuZXQuaW5ldC5zY3RwLmRvX3NjdHBfZHJhaW46IDEKbmV0LmluZXQuc2N0 cC5tYXhfY2hhaW5lZF9tYnVmczogNQpuZXQuaW5ldC5zY3RwLmFiY19sX3ZhcjogMQpuZXQu aW5ldC5zY3RwLm5hdF9mcmllbmRseTogMQpuZXQuaW5ldC5zY3RwLmF1dGhfZGlzYWJsZTog MApuZXQuaW5ldC5zY3RwLmFzY29uZl9hdXRoX25vY2hrOiAwCm5ldC5pbmV0LnNjdHAuZWFy bHlfZmFzdF9yZXRyYW5fbXNlYzogMjUwCm5ldC5pbmV0LnNjdHAuZWFybHlfZmFzdF9yZXRy YW46IDAKbmV0LmluZXQuc2N0cC5jd25kX21heGJ1cnN0OiAxCm5ldC5pbmV0LnNjdHAuY210 X3BmOiAwCm5ldC5pbmV0LnNjdHAuY210X3VzZV9kYWM6IDAKbmV0LmluZXQuc2N0cC5ucl9z YWNrX29uX29mZjogMApuZXQuaW5ldC5zY3RwLmNtdF9vbl9vZmY6IDAKbmV0LmluZXQuc2N0 cC5vdXRnb2luZ19zdHJlYW1zOiAxMApuZXQuaW5ldC5zY3RwLmFkZF9tb3JlX29uX291dHB1 dDogMTQ1MgpuZXQuaW5ldC5zY3RwLnBhdGhfcnR4X21heDogNQpuZXQuaW5ldC5zY3RwLmFz c29jX3J0eF9tYXg6IDEwCm5ldC5pbmV0LnNjdHAuaW5pdF9ydHhfbWF4OiA4Cm5ldC5pbmV0 LnNjdHAudmFsaWRfY29va2llX2xpZmU6IDYwMDAwCm5ldC5pbmV0LnNjdHAuaW5pdF9ydG9f bWF4OiA2MDAwMApuZXQuaW5ldC5zY3RwLnJ0b19pbml0aWFsOiAzMDAwCm5ldC5pbmV0LnNj dHAucnRvX21pbjogMTAwMApuZXQuaW5ldC5zY3RwLnJ0b19tYXg6IDYwMDAwCm5ldC5pbmV0 LnNjdHAuc2VjcmV0X2xpZmV0aW1lOiAzNjAwCm5ldC5pbmV0LnNjdHAuc2h1dGRvd25fZ3Vh cmRfdGltZTogMTgwCm5ldC5pbmV0LnNjdHAucG10dV9yYWlzZV90aW1lOiA2MDAKbmV0Lmlu ZXQuc2N0cC5oZWFydGJlYXRfaW50ZXJ2YWw6IDMwMDAwCm5ldC5pbmV0LnNjdHAuYXNvY19y ZXNvdXJjZTogMTAKbmV0LmluZXQuc2N0cC5zeXNfcmVzb3VyY2U6IDEwMDAKbmV0LmluZXQu c2N0cC5zYWNrX2ZyZXE6IDIKbmV0LmluZXQuc2N0cC5kZWxheWVkX3NhY2tfdGltZTogMjAw Cm5ldC5pbmV0LnNjdHAuY2h1bmtzY2FsZTogMTAKbmV0LmluZXQuc2N0cC5taW5fc3BsaXRf cG9pbnQ6IDI5MDQKbmV0LmluZXQuc2N0cC5wY2JoYXNoc2l6ZTogMjU2Cm5ldC5pbmV0LnNj dHAudGNiaGFzaHNpemU6IDEwMjQKbmV0LmluZXQuc2N0cC5tYXhjaHVua3M6IDMyMDAKbmV0 LmluZXQuc2N0cC5tYXhidXJzdDogNApuZXQuaW5ldC5zY3RwLnBlZXJfY2hrb2g6IDI1Ngpu ZXQuaW5ldC5zY3RwLnN0cmljdF9pbml0OiAxCm5ldC5pbmV0LnNjdHAubG9vcGJhY2tfbm9j c3VtOiAxCm5ldC5pbmV0LnNjdHAuc3RyaWN0X3NhY2tzOiAxCm5ldC5pbmV0LnNjdHAuZWNu X25vbmNlOiAwCm5ldC5pbmV0LnNjdHAuZWNuX2VuYWJsZTogMQpuZXQuaW5ldC5zY3RwLmF1 dG9fYXNjb25mOiAxCm5ldC5pbmV0LnNjdHAucmVjdnNwYWNlOiAyMzMwMTYKbmV0LmluZXQu c2N0cC5zZW5kc3BhY2U6IDIzMzAxNgpuZXQuaW5ldC5yYXcucmVjdnNwYWNlOiA5MjE2Cm5l dC5pbmV0LnJhdy5tYXhkZ3JhbTogOTIxNgpuZXQuaW5ldC5hY2NmLnVubG9hZGFibGU6IDAK bmV0LmxpbmsuZ2VuZXJpYy5zeXN0ZW0uaWZjb3VudDogNQpuZXQubGluay5ldGhlci5pbmV0 LmxvZ19hcnBfcGVybWFuZW50X21vZGlmeTogMQpuZXQubGluay5ldGhlci5pbmV0LmxvZ19h cnBfbW92ZW1lbnRzOiAxCm5ldC5saW5rLmV0aGVyLmluZXQubG9nX2FycF93cm9uZ19pZmFj ZTogMQpuZXQubGluay5ldGhlci5pbmV0LnByb3h5YWxsOiAwCm5ldC5saW5rLmV0aGVyLmlu ZXQudXNlbG9vcGJhY2s6IDEKbmV0LmxpbmsuZXRoZXIuaW5ldC5tYXh0cmllczogNQpuZXQu bGluay5ldGhlci5pbmV0Lm1heF9hZ2U6IDEyMDAKbmV0LmxpbmsuZXRoZXIuaXBmdzogMApu ZXQubGluay5naWYucGFyYWxsZWxfdHVubmVsczogMApuZXQubGluay5naWYubWF4X25lc3Rp bmc6IDEKbmV0LmxpbmsubG9nX2xpbmtfc3RhdGVfY2hhbmdlOiAxCm5ldC5saW5rLnR1bi5k ZXZmc19jbG9uaW5nOiAxCm5ldC5pbmV0Ni5pcDYuZm9yd2FyZGluZzogMApuZXQuaW5ldDYu aXA2LnJlZGlyZWN0OiAxCm5ldC5pbmV0Ni5pcDYuaGxpbTogNjQKbmV0LmluZXQ2LmlwNi5t YXhmcmFncGFja2V0czogNjQwMApuZXQuaW5ldDYuaXA2LmFjY2VwdF9ydGFkdjogMApuZXQu aW5ldDYuaXA2LmtlZXBmYWl0aDogMApuZXQuaW5ldDYuaXA2LmxvZ19pbnRlcnZhbDogNQpu ZXQuaW5ldDYuaXA2Lmhkcm5lc3RsaW1pdDogMTUKbmV0LmluZXQ2LmlwNi5kYWRfY291bnQ6 IDEKbmV0LmluZXQ2LmlwNi5hdXRvX2Zsb3dsYWJlbDogMQpuZXQuaW5ldDYuaXA2LmRlZm1j YXN0aGxpbTogMQpuZXQuaW5ldDYuaXA2LmdpZmhsaW06IDMwCm5ldC5pbmV0Ni5pcDYua2Ft ZV92ZXJzaW9uOiBGcmVlQlNECm5ldC5pbmV0Ni5pcDYudXNlX2RlcHJlY2F0ZWQ6IDEKbmV0 LmluZXQ2LmlwNi5ycl9wcnVuZTogNQpuZXQuaW5ldDYuaXA2LnY2b25seTogMQpuZXQuaW5l dDYuaXA2LnJ0ZXhwaXJlOiAzNjAwCm5ldC5pbmV0Ni5pcDYucnRtaW5leHBpcmU6IDEwCm5l dC5pbmV0Ni5pcDYucnRtYXhjYWNoZTogMTI4Cm5ldC5pbmV0Ni5pcDYudXNlX3RlbXBhZGRy OiAwCm5ldC5pbmV0Ni5pcDYudGVtcHBsdGltZTogODY0MDAKbmV0LmluZXQ2LmlwNi50ZW1w dmx0aW1lOiA2MDQ4MDAKbmV0LmluZXQ2LmlwNi5hdXRvX2xpbmtsb2NhbDogMApuZXQuaW5l dDYuaXA2LnByZWZlcl90ZW1wYWRkcjogMApuZXQuaW5ldDYuaXA2LnVzZV9kZWZhdWx0em9u ZTogMApuZXQuaW5ldDYuaXA2Lm1heGZyYWdzOiA2NDAwCm5ldC5pbmV0Ni5pcDYubWNhc3Rf cG10dTogMApuZXQuaW5ldDYuaWNtcDYucmVkaXJhY2NlcHQ6IDEKbmV0LmluZXQ2LmljbXA2 LnJlZGlydGltZW91dDogNjAwCm5ldC5pbmV0Ni5pY21wNi5uZDZfcHJ1bmU6IDEKbmV0Lmlu ZXQ2LmljbXA2Lm5kNl9kZWxheTogNQpuZXQuaW5ldDYuaWNtcDYubmQ2X3VtYXh0cmllczog MwpuZXQuaW5ldDYuaWNtcDYubmQ2X21tYXh0cmllczogMwpuZXQuaW5ldDYuaWNtcDYubmQ2 X3VzZWxvb3BiYWNrOiAxCm5ldC5pbmV0Ni5pY21wNi5ub2RlaW5mbzogMwpuZXQuaW5ldDYu aWNtcDYuZXJycHBzbGltaXQ6IDEwMApuZXQuaW5ldDYuaWNtcDYubmQ2X21heG51ZGhpbnQ6 IDAKbmV0LmluZXQ2LmljbXA2Lm5kNl9kZWJ1ZzogMApuZXQuaW5ldDYuaWNtcDYubmQ2X21h eHF1ZXVlbGVuOiAxCm5ldC5pbmV0Ni5pY21wNi5uZDZfb25saW5rX25zX3JmYzQ4NjE6IDAK bmV0LmJwZi5tYXhpbnNuczogNTEyCm5ldC5icGYubWF4YnVmc2l6ZTogNTI0Mjg4Cm5ldC5i cGYuYnVmc2l6ZTogNDA5NgpuZXQuaXNyLnN3aV9jb3VudDogNwpuZXQuaXNyLmRyb3A6IDAK bmV0Lmlzci5xdWV1ZWQ6IDcKbmV0Lmlzci5kZWZlcnJlZDogMApuZXQuaXNyLmRpcmVjdGVk OiA2NDQyCm5ldC5pc3IuY291bnQ6IDY0NDIKbmV0Lmlzci5kaXJlY3Q6IDEKbmV0LnJhdy5y ZWN2c3BhY2U6IDgxOTIKbmV0LnJhdy5zZW5kc3BhY2U6IDgxOTIKbmV0Lm15X2ZpYm51bTog MApuZXQuYWRkX2FkZHJfYWxsZmliczogMQpuZXQuZmliczogMQpuZXQucm91dGUubmV0aXNy X21heHFsZW46IDI1NgpuZXQuZ3JhcGgubXNnX3ZlcnNpb246IDgKbmV0LmdyYXBoLmFiaV92 ZXJzaW9uOiAxMQpuZXQuZ3JhcGgubWF4ZGF0YTogNTEyCm5ldC5ncmFwaC5tYXhhbGxvYzog NDA5NgpuZXQuZ3JhcGgudGhyZWFkczogMgpuZXQuZ3JhcGguY29udHJvbC5wcm90bzogMgpu ZXQuZ3JhcGguZGF0YS5wcm90bzogMQpuZXQuZ3JhcGguZmFtaWx5OiAzMgpuZXQuZ3JhcGgu cmVjdnNwYWNlOiAyMDQ4MApuZXQuZ3JhcGgubWF4ZGdyYW06IDIwNDgwCmRlYnVnLmFjcGku c2VtYXBob3JlX2RlYnVnOiAwCmRlYnVnLmFjcGkubGV2ZWw6IE5PTkUKZGVidWcuYWNwaS5s YXllcjogTk9ORQpkZWJ1Zy5hY3BpLnN1c3BlbmRfYm91bmNlOiAwCmRlYnVnLmFjcGkuZG9f cG93ZXJzdGF0ZTogMQpkZWJ1Zy5hY3BpLmFjcGlfY2FfdmVyc2lvbjogMjAwNzAzMjAKZGVi dWcuYWNwaS5lYy50aW1lb3V0OiA3NTAKZGVidWcuYWNwaS5lYy5wb2xsZWQ6IDAKZGVidWcu YWNwaS5lYy5idXJzdDogMApkZWJ1Zy5hY3BpLmJhdHQuYmF0dF9zbGVlcF9tczogMApkZWJ1 Zy5tZGRlYnVnOiAwCmRlYnVnLmVsZjY0X2xlZ2FjeV9jb3JlZHVtcDogMApkZWJ1Zy5lbGY2 NF90cmFjZTogMApkZWJ1Zy5ib290dmVyYm9zZTogMApkZWJ1Zy5ib290aG93dG86IDAKZGVi dWcuY3B1ZnJlcS52ZXJib3NlOiAwCmRlYnVnLmNwdWZyZXEubG93ZXN0OiAwCmRlYnVnLnNp emVvZi5jZGV2X3ByaXY6IDM3NgpkZWJ1Zy5zaXplb2YuY2RldjogMjg4CmRlYnVnLnNpemVv Zi5nX2Jpb3E6IDcyCmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA5NgpkZWJ1Zy5zaXplb2Yu Z19wcm92aWRlcjogMTM2CmRlYnVnLnNpemVvZi5nX2dlb206IDEzNgpkZWJ1Zy5zaXplb2Yu Z19jbGFzczogMTM2CmRlYnVnLnNpemVvZi5raW5mb19wcm9jOiAxMDg4CmRlYnVnLnNpemVv Zi5idWY6IDY0MApkZWJ1Zy5zaXplb2YuYmlvOiAyMTYKZGVidWcuc2l6ZW9mLnByb2M6IDEx NDQKZGVidWcuc2l6ZW9mLnZub2RlOiA1MDQKZGVidWcuc2l6ZW9mLmRldnN0YXQ6IDI4OApk ZWJ1Zy5zaXplb2YubmFtZWNhY2hlOiA3MgpkZWJ1Zy50b19hdmdfbXBjYWxsczogMTQ4MApk ZWJ1Zy50b19hdmdfbXR4Y2FsbHM6IDAKZGVidWcudG9fYXZnX2djYWxsczogMTYKZGVidWcu dG9fYXZnX2RlcHRoOiAxNzEwCmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDAKZGVi dWcua2RiLnN0b3BfY3B1czogMQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAwCmRlYnVnLmtkYi50 cmFwOiAwCmRlYnVnLmtkYi5wYW5pYzogMApkZWJ1Zy5rZGIuZW50ZXI6IDAKZGVidWcua2Ri LmN1cnJlbnQ6IApkZWJ1Zy5rZGIuYXZhaWxhYmxlOiAKZGVidWcucm1hbl9kZWJ1ZzogMApk ZWJ1Zy50dHlkZWJ1ZzogMApkZWJ1Zy5kaXNhYmxlZnVsbHBhdGg6IDAKZGVidWcuZGlzYWJs ZWN3ZDogMApkZWJ1Zy52ZnNjYWNoZTogMQpkZWJ1Zy5udW1jYWNoZWh2OiA0OTMKZGVidWcu bnVtY2FjaGU6IDM2MTEKZGVidWcubnVtbmVnOiAyMjQKZGVidWcubmNuZWdmYWN0b3I6IDE2 CmRlYnVnLm5jaGFzaDogMTMxMDcxCmRlYnVnLnZubHJ1X25vd2hlcmU6IDAKZGVidWcucnVz aF9yZXF1ZXN0czogMApkZWJ1Zy5tcHNhZmV2ZnM6IDEKZGVidWcuaWZfdHVuX2RlYnVnOiAw CmRlYnVnLm5sbV9kZWJ1ZzogMApkZWJ1Zy5jb2xsZWN0c25hcHN0YXRzOiAwCmRlYnVnLnNu YXBkZWJ1ZzogMApkZWJ1Zy5kb3BlcnNpc3RlbmNlOiAwCmRlYnVnLmRpcl9lbnRyeTogNjUK ZGVidWcuZGlyZWN0X2Jsa19wdHJzOiA0OApkZWJ1Zy5pbm9kZV9iaXRtYXA6IDUxCmRlYnVn LmluZGlyX2Jsa19wdHJzOiAzOQpkZWJ1Zy5zeW5jX2xpbWl0X2hpdDogMApkZWJ1Zy5pbm9f bGltaXRfaGl0OiAwCmRlYnVnLmJsa19saW1pdF9oaXQ6IDAKZGVidWcuaW5vX2xpbWl0X3B1 c2g6IDAKZGVidWcuYmxrX2xpbWl0X3B1c2g6IDAKZGVidWcud29ya2xpc3RfcHVzaDogMApk ZWJ1Zy5tYXhpbmRpcmRlcHM6IDUwCmRlYnVnLnRpY2tkZWxheTogMgpkZWJ1Zy5tYXhfc29m dGRlcHM6IDQwMDAwMApkZWJ1Zy5kb2JrZ3Jkd3JpdGU6IDEKZGVidWcuYmlnY2dzOiAwCmRl YnVnLmRpcmNoZWNrOiAwCmRlYnVnLm1pbmlkdW1wOiAxCmRlYnVnLnN0b3BfY3B1c193aXRo X25taTogMQpkZWJ1Zy5wc20ucGt0ZXJydGhyZXNoOiAyCmRlYnVnLnBzbS51c2VjczogNTAw MDAwCmRlYnVnLnBzbS5zZWNzOiAwCmRlYnVnLnBzbS5lcnJ1c2VjczogMApkZWJ1Zy5wc20u ZXJyc2VjczogMgpkZWJ1Zy5wc20uaHo6IDIwCmRlYnVnLnBzbS5sb2dsZXZlbDogMApkZWJ1 Zy5lbGYzMl9sZWdhY3lfY29yZWR1bXA6IDAKZGVidWcuZWxmMzJfdHJhY2U6IDAKZGVidWcu cGZ1Z2lkaGFjazogMApody5tYWNoaW5lOiBhbWQ2NApody5tb2RlbDogUGVudGl1bShSKSBE dWFsLUNvcmUgIENQVSAgICAgIEU1MjAwICBAIDIuNTBHSHoKaHcubmNwdTogMgpody5ieXRl b3JkZXI6IDEyMzQKaHcucGh5c21lbTogNDI4NDU1NTI2NApody51c2VybWVtOiA0MDczMzk4 MjcyCmh3LnBhZ2VzaXplOiA0MDk2Cmh3LmZsb2F0aW5ncG9pbnQ6IDEKaHcubWFjaGluZV9h cmNoOiBhbWQ2NApody5yZWFsbWVtOiA1MTAwMjczNjY0Cmh3LmF0YS53YzogMQpody5hdGEu YXRhcGlfZG1hOiAxCmh3LmF0YS5hdGFfZG1hX2NoZWNrXzgwcGluOiAxCmh3LmF0YS5hdGFf ZG1hOiAxCmh3LnBjaS5ob25vcl9tc2lfYmxhY2tsaXN0OiAxCmh3LnBjaS5lbmFibGVfbXNp eDogMQpody5wY2kuZW5hYmxlX21zaTogMQpody5wY2kuZG9fcG93ZXJfcmVzdW1lOiAxCmh3 LnBjaS5kb19wb3dlcl9ub2RyaXZlcjogMApody5wY2kuZW5hYmxlX2lvX21vZGVzOiAxCmh3 LnBjaS5ob3N0X21lbV9zdGFydDogMjE0NzQ4MzY0OApody5zeXNjb25zLmtiZF9kZWJ1Zzog MQpody5zeXNjb25zLmtiZF9yZWJvb3Q6IDEKaHcuc3lzY29ucy5iZWxsOiAxCmh3LnN5c2Nv bnMuc2F2ZXIua2V5Ym9ubHk6IDEKaHcuc3lzY29ucy5zY19ub19zdXNwZW5kX3Z0c3dpdGNo OiAwCmh3LmludHJfc3Rvcm1fdGhyZXNob2xkOiAxMDAwCmh3LmF2YWlscGFnZXM6IDEwNDYw MzQKaHcuYnVzLmRldmN0bF9kaXNhYmxlOiAwCmh3LmJ1c2RtYS50b3RhbF9icGFnZXM6IDEw NTg1Cmh3LmJ1c2RtYS56b25lMC50b3RhbF9icGFnZXM6IDgyMDAKaHcuYnVzZG1hLnpvbmUw LmZyZWVfYnBhZ2VzOiA4MjAwCmh3LmJ1c2RtYS56b25lMC5yZXNlcnZlZF9icGFnZXM6IDAK aHcuYnVzZG1hLnpvbmUwLmFjdGl2ZV9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUwLnRvdGFs X2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUwLnRvdGFsX2RlZmVycmVkOiAwCmh3LmJ1c2Rt YS56b25lMC5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2RtYS56b25lMC5hbGlnbm1lbnQ6 IDEKaHcuYnVzZG1hLnpvbmUwLmJvdW5kYXJ5OiAwCmh3LmJ1c2RtYS56b25lMS50b3RhbF9i cGFnZXM6IDIwNDgKaHcuYnVzZG1hLnpvbmUxLmZyZWVfYnBhZ2VzOiAyMDQ4Cmh3LmJ1c2Rt YS56b25lMS5yZXNlcnZlZF9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLmFjdGl2ZV9icGFn ZXM6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUx LnRvdGFsX2RlZmVycmVkOiAwCmh3LmJ1c2RtYS56b25lMS5sb3dhZGRyOiAweGZmZmZmZmZm ZmZmZmZmZgpody5idXNkbWEuem9uZTEuYWxpZ25tZW50OiAyCmh3LmJ1c2RtYS56b25lMS5i b3VuZGFyeTogNjU1MzYKaHcuYnVzZG1hLnpvbmUyLnRvdGFsX2JwYWdlczogODAKaHcuYnVz ZG1hLnpvbmUyLmZyZWVfYnBhZ2VzOiA4MApody5idXNkbWEuem9uZTIucmVzZXJ2ZWRfYnBh Z2VzOiAwCmh3LmJ1c2RtYS56b25lMi5hY3RpdmVfYnBhZ2VzOiAwCmh3LmJ1c2RtYS56b25l Mi50b3RhbF9ib3VuY2VkOiA0NjIKaHcuYnVzZG1hLnpvbmUyLnRvdGFsX2RlZmVycmVkOiAw Cmh3LmJ1c2RtYS56b25lMi5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2RtYS56b25lMi5h bGlnbm1lbnQ6IDIKaHcuYnVzZG1hLnpvbmUyLmJvdW5kYXJ5OiA2NTUzNgpody5idXNkbWEu em9uZTMudG90YWxfYnBhZ2VzOiAyNTcKaHcuYnVzZG1hLnpvbmUzLmZyZWVfYnBhZ2VzOiAy NTcKaHcuYnVzZG1hLnpvbmUzLnJlc2VydmVkX2JwYWdlczogMApody5idXNkbWEuem9uZTMu YWN0aXZlX2JwYWdlczogMApody5idXNkbWEuem9uZTMudG90YWxfYm91bmNlZDogMApody5i dXNkbWEuem9uZTMudG90YWxfZGVmZXJyZWQ6IDAKaHcuYnVzZG1hLnpvbmUzLmxvd2FkZHI6 IDB4ZmZmZmZmZmYKaHcuYnVzZG1hLnpvbmUzLmFsaWdubWVudDogOApody5idXNkbWEuem9u ZTMuYm91bmRhcnk6IDAKaHcuY2xvY2tyYXRlOiAyNDkzCmh3Lmluc3RydWN0aW9uX3NzZTog MQpody5hcGljLmVuYWJsZV9leHRpbnQ6IDAKaHcucHNtLnRhcF90aW1lb3V0OiAxMjUwMDAK aHcucHNtLnRhcF90aHJlc2hvbGQ6IDI1Cmh3LmtiZC5rZXltYXBfcmVzdHJpY3RfY2hhbmdl OiAwCmh3LmFjcGkuc3VwcG9ydGVkX3NsZWVwX3N0YXRlOiBTMSBTMyBTNCBTNQpody5hY3Bp LnBvd2VyX2J1dHRvbl9zdGF0ZTogUzUKaHcuYWNwaS5zbGVlcF9idXR0b25fc3RhdGU6IFMx Cmh3LmFjcGkubGlkX3N3aXRjaF9zdGF0ZTogTk9ORQpody5hY3BpLnN0YW5kYnlfc3RhdGU6 IFMxCmh3LmFjcGkuc3VzcGVuZF9zdGF0ZTogUzMKaHcuYWNwaS5zbGVlcF9kZWxheTogMQpo dy5hY3BpLnM0YmlvczogMApody5hY3BpLnZlcmJvc2U6IDAKaHcuYWNwaS5kaXNhYmxlX29u X3JlYm9vdDogMApody5hY3BpLmhhbmRsZV9yZWJvb3Q6IDAKaHcuYWNwaS5jcHUuY3hfbG93 ZXN0OiBDMQpody5kcmkuMC5uYW1lOiByYWRlb24gMHgyMQpody5kcmkuMC52bTogCnNsb3Qg b2Zmc2V0CSAgICAgICAgc2l6ZSAgICAgICB0eXBlIGZsYWdzIGFkZHJlc3MgICAgICAgICAg ICBtdHJyCiAgIDAgMHgwMDAwMDAwMGZmODIwMDAwIDB4MDAwMTAwMDAgIFJFRyAgMHg4MiAw eGZmZmZmZmZlODAwODUwMDAgbm8KCmh3LmRyaS4wLmNsaWVudHM6IAphIGRldglwaWQgICAg dWlkCW1hZ2ljCSAgaW9jdGxzCgpody5kcmkuMC5kZWJ1ZzogMApody5zbmQubGF0ZW5jeV9w cm9maWxlOiAxCmh3LnNuZC5sYXRlbmN5OiA1Cmh3LnNuZC5yZXBvcnRfc29mdF9mb3JtYXRz OiAxCmh3LnNuZC5jb21wYXRfbGludXhfbW1hcDogMApody5zbmQuZmVlZGVyX2J1ZmZlcnNp emU6IDE2Mzg0Cmh3LnNuZC5mZWVkZXJfcmF0ZV9yb3VuZDogMjUKaHcuc25kLmZlZWRlcl9y YXRlX21heDogMjAxNjAwMApody5zbmQuZmVlZGVyX3JhdGVfbWluOiAxCmh3LnNuZC52ZXJi b3NlOiAxCmh3LnNuZC5tYXhhdXRvdmNoYW5zOiAxNgpody5zbmQuZGVmYXVsdF91bml0OiAw Cmh3LnNuZC52ZXJzaW9uOiAyMDA3MDYxNjAwL2FtZDY0Cmh3LnNuZC5kZWZhdWx0X2F1dG86 IDAKaHcubWlkaS5pbnN0cm9mZjogMApody5taWRpLmR1bXByYXc6IDAKaHcubWlkaS5kZWJ1 ZzogMApody5taWRpLnN0YXQudmVyYm9zZTogMApody5taWRpLnNlcS5kZWJ1ZzogMAptYWNo ZGVwLmFjcGlfdGltZXJfZnJlcTogMzU3OTU0NQptYWNoZGVwLmVuYWJsZV9wYW5pY19rZXk6 IDAKbWFjaGRlcC5hZGprZXJudHo6IC0yODgwMAptYWNoZGVwLndhbGxfY21vc19jbG9jazog MQptYWNoZGVwLmRpc2FibGVfcnRjX3NldDogMAptYWNoZGVwLmFjcGlfcm9vdDogOTg0MDAw Cm1hY2hkZXAuZGlzYWJsZV9tdHJyczogMAptYWNoZGVwLmNwdV9pZGxlX2hsdDogMQptYWNo ZGVwLmhsdF9jcHVzOiAwCm1hY2hkZXAucHJvdF9mYXVsdF90cmFuc2xhdGlvbjogMAptYWNo ZGVwLnBhbmljX29uX25taTogMQptYWNoZGVwLnRzY19mcmVxOiAyNDkzNzYxMzEyCm1hY2hk ZXAuaTgyNTRfZnJlcTogMTE5MzE4MgptYWNoZGVwLmNvbnNwZWVkOiA5NjAwCm1hY2hkZXAu Z2Ric3BlZWQ6IDk2MDAKbWFjaGRlcC5jb25yY2xrOiAxODQzMjAwCm1hY2hkZXAuaGx0X2xv Z2ljYWxfY3B1czogMAptYWNoZGVwLmxvZ2ljYWxfY3B1c19tYXNrOiAyCnVzZXIuY3NfcGF0 aDogL3Vzci9iaW46L2JpbjovdXNyL3NiaW46L3NiaW46CnVzZXIuYmNfYmFzZV9tYXg6IDk5 CnVzZXIuYmNfZGltX21heDogMjA0OAp1c2VyLmJjX3NjYWxlX21heDogOTkKdXNlci5iY19z dHJpbmdfbWF4OiAxMDAwCnVzZXIuY29sbF93ZWlnaHRzX21heDogMAp1c2VyLmV4cHJfbmVz dF9tYXg6IDMyCnVzZXIubGluZV9tYXg6IDIwNDgKdXNlci5yZV9kdXBfbWF4OiAyNTUKdXNl ci5wb3NpeDJfdmVyc2lvbjogMTk5MjEyCnVzZXIucG9zaXgyX2NfYmluZDogMAp1c2VyLnBv c2l4Ml9jX2RldjogMAp1c2VyLnBvc2l4Ml9jaGFyX3Rlcm06IDAKdXNlci5wb3NpeDJfZm9y dF9kZXY6IDAKdXNlci5wb3NpeDJfZm9ydF9ydW46IDAKdXNlci5wb3NpeDJfbG9jYWxlZGVm OiAwCnVzZXIucG9zaXgyX3N3X2RldjogMAp1c2VyLnBvc2l4Ml91cGU6IDAKdXNlci5zdHJl YW1fbWF4OiAyMAp1c2VyLnR6bmFtZV9tYXg6IDI1NQpwMTAwM18xYi5hc3luY2hyb25vdXNf aW86IDAKcDEwMDNfMWIubWFwcGVkX2ZpbGVzOiAxCnAxMDAzXzFiLm1lbWxvY2s6IDAKcDEw MDNfMWIubWVtbG9ja19yYW5nZTogMApwMTAwM18xYi5tZW1vcnlfcHJvdGVjdGlvbjogMApw MTAwM18xYi5tZXNzYWdlX3Bhc3Npbmc6IDAKcDEwMDNfMWIucHJpb3JpdGl6ZWRfaW86IDAK cDEwMDNfMWIucHJpb3JpdHlfc2NoZWR1bGluZzogMQpwMTAwM18xYi5yZWFsdGltZV9zaWdu YWxzOiAyMDAxMTIKcDEwMDNfMWIuc2VtYXBob3JlczogMApwMTAwM18xYi5mc3luYzogMApw MTAwM18xYi5zaGFyZWRfbWVtb3J5X29iamVjdHM6IDEKcDEwMDNfMWIuc3luY2hyb25pemVk X2lvOiAwCnAxMDAzXzFiLnRpbWVyczogMjAwMTEyCnAxMDAzXzFiLmFpb19saXN0aW9fbWF4 OiAtMQpwMTAwM18xYi5haW9fbWF4OiAtMQpwMTAwM18xYi5haW9fcHJpb19kZWx0YV9tYXg6 IC0xCnAxMDAzXzFiLmRlbGF5dGltZXJfbWF4OiAyMTQ3NDgzNjQ3CnAxMDAzXzFiLm1xX29w ZW5fbWF4OiAwCnAxMDAzXzFiLnBhZ2VzaXplOiA0MDk2CnAxMDAzXzFiLnJ0c2lnX21heDog NjIKcDEwMDNfMWIuc2VtX25zZW1zX21heDogMApwMTAwM18xYi5zZW1fdmFsdWVfbWF4OiAw CnAxMDAzXzFiLnNpZ3F1ZXVlX21heDogMTI4CnAxMDAzXzFiLnRpbWVyX21heDogMzIKc2Vj dXJpdHkuamFpbC5qYWlsZWQ6IDAKc2VjdXJpdHkuamFpbC5qYWlsX21heF9hZl9pcHM6IDI1 NQpzZWN1cml0eS5qYWlsLm1vdW50X2FsbG93ZWQ6IDAKc2VjdXJpdHkuamFpbC5jaGZsYWdz X2FsbG93ZWQ6IDAKc2VjdXJpdHkuamFpbC5hbGxvd19yYXdfc29ja2V0czogMApzZWN1cml0 eS5qYWlsLmVuZm9yY2Vfc3RhdGZzOiAyCnNlY3VyaXR5LmphaWwuc3lzdmlwY19hbGxvd2Vk OiAwCnNlY3VyaXR5LmphaWwuc29ja2V0X3VuaXhpcHJvdXRlX29ubHk6IDEKc2VjdXJpdHku amFpbC5zZXRfaG9zdG5hbWVfYWxsb3dlZDogMQpzZWN1cml0eS5ic2Quc3VzZXJfZW5hYmxl ZDogMQpzZWN1cml0eS5ic2QudW5wcml2aWxlZ2VkX3Byb2NfZGVidWc6IDEKc2VjdXJpdHku YnNkLmNvbnNlcnZhdGl2ZV9zaWduYWxzOiAxCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfZ2lk czogMQpzZWN1cml0eS5ic2Quc2VlX290aGVyX3VpZHM6IDEKc2VjdXJpdHkuYnNkLnVucHJp dmlsZWdlZF9yZWFkX21zZ2J1ZjogMQpzZWN1cml0eS5ic2QuaGFyZGxpbmtfY2hlY2tfZ2lk OiAwCnNlY3VyaXR5LmJzZC5oYXJkbGlua19jaGVja191aWQ6IDAKc2VjdXJpdHkuYnNkLnVu cHJpdmlsZWdlZF9nZXRfcXVvdGE6IDAKY29tcGF0LmlhMzIubWF4dm1lbTogMApjb21wYXQu aWEzMi5tYXhzc2l6OiA2NzEwODg2NApjb21wYXQuaWEzMi5tYXhkc2l6OiA1MzY4NzA5MTIK Y29tcGF0LmxpbnV4MzIubWF4dm1lbTogMApjb21wYXQubGludXgzMi5tYXhzc2l6OiA2NzEw ODg2NApjb21wYXQubGludXgzMi5tYXhkc2l6OiA1MzY4NzA5MTIKY29tcGF0LmxpbnV4Lm9z c192ZXJzaW9uOiAxOTgxNDQKY29tcGF0LmxpbnV4Lm9zcmVsZWFzZTogMi40LjIKY29tcGF0 LmxpbnV4Lm9zbmFtZTogTGludXgKZGV2Lm5leHVzLjAuJWRyaXZlcjogbmV4dXMKZGV2Lm5l eHVzLjAuJXBhcmVudDogcm9vdDAKZGV2LnJhbS4wLiVkZXNjOiBTeXN0ZW0gUkFNCmRldi5y YW0uMC4lZHJpdmVyOiByYW0KZGV2LnJhbS4wLiVwYXJlbnQ6IG5leHVzMApkZXYuYWNwaS4w LiVkZXNjOiBBTEFTS0EgQSBNIEkKZGV2LmFjcGkuMC4lZHJpdmVyOiBhY3BpCmRldi5hY3Bp LjAuJXBhcmVudDogbmV4dXMwCmRldi5hY3BpX3N5c3Jlc291cmNlLjAuJWRlc2M6IFN5c3Rl bSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4wLiVkcml2ZXI6IGFjcGlfc3lzcmVz b3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5Q Q0kwLk1DSF8KZGV2LmFjcGlfc3lzcmVzb3VyY2UuMC4lcG5waW5mbzogX0hJRD1QTlAwQzAx IF9VSUQ9MTAKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMC4lcGFyZW50OiBhY3BpMApkZXYuYWNw aV9zeXNyZXNvdXJjZS4xLiVkZXNjOiBTeXN0ZW0gUmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVz b3VyY2UuMS4lZHJpdmVyOiBhY3BpX3N5c3Jlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNl LjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLlNJTzEKZGV2LmFjcGlfc3lz cmVzb3VyY2UuMS4lcG5waW5mbzogX0hJRD1QTlAwQzAyIF9VSUQ9NzgKZGV2LmFjcGlfc3lz cmVzb3VyY2UuMS4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9zeXNyZXNvdXJjZS4yLiVkZXNj OiBTeXN0ZW0gUmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMi4lZHJpdmVyOiBhY3Bp X3N5c3Jlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjIuJWxvY2F0aW9uOiBoYW5kbGU9 XF9TQl8uUENJMC5TQlJHLlJNU0MKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMi4lcG5waW5mbzog X0hJRD1QTlAwQzAyIF9VSUQ9MTYKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMi4lcGFyZW50OiBh Y3BpMApkZXYuYWNwaV9zeXNyZXNvdXJjZS4zLiVkZXNjOiBTeXN0ZW0gUmVzb3VyY2UKZGV2 LmFjcGlfc3lzcmVzb3VyY2UuMy4lZHJpdmVyOiBhY3BpX3N5c3Jlc291cmNlCmRldi5hY3Bp X3N5c3Jlc291cmNlLjMuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5JQ0g5CmRldi5h Y3BpX3N5c3Jlc291cmNlLjMuJXBucGluZm86IF9ISUQ9UE5QMEMwMSBfVUlEPTQ1NQpkZXYu YWNwaV9zeXNyZXNvdXJjZS4zLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNl LjQuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS40LiVkcml2 ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuNC4lbG9jYXRpb246 IGhhbmRsZT1cX1NCXy5STUVNCmRldi5hY3BpX3N5c3Jlc291cmNlLjQuJXBucGluZm86IF9I SUQ9UE5QMEMwMSBfVUlEPTEKZGV2LmFjcGlfc3lzcmVzb3VyY2UuNC4lcGFyZW50OiBhY3Bp MApkZXYuYWNwaV9zeXNyZXNvdXJjZS41LiVkZXNjOiBTeXN0ZW0gUmVzb3VyY2UKZGV2LmFj cGlfc3lzcmVzb3VyY2UuNS4lZHJpdmVyOiBhY3BpX3N5c3Jlc291cmNlCmRldi5hY3BpX3N5 c3Jlc291cmNlLjUuJWxvY2F0aW9uOiBoYW5kbGU9XE9NU0MKZGV2LmFjcGlfc3lzcmVzb3Vy Y2UuNS4lcG5waW5mbzogX0hJRD1QTlAwQzAyIF9VSUQ9MzYwMQpkZXYuYWNwaV9zeXNyZXNv dXJjZS41LiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3RpbWVyLjAuJWRlc2M6IDI0LWJpdCB0 aW1lciBhdCAzLjU3OTU0NU1IegpkZXYuYWNwaV90aW1lci4wLiVkcml2ZXI6IGFjcGlfdGlt ZXIKZGV2LmFjcGlfdGltZXIuMC4lbG9jYXRpb246IHVua25vd24KZGV2LmFjcGlfdGltZXIu MC4lcG5waW5mbzogdW5rbm93bgpkZXYuYWNwaV90aW1lci4wLiVwYXJlbnQ6IGFjcGkwCmRl di5wY2lfbGluay4wLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0EKZGV2LnBjaV9saW5rLjAu JWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9T Ql8uTE5LQQpkZXYucGNpX2xpbmsuMC4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9MQpk ZXYucGNpX2xpbmsuMC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMS4lZGVzYzogQUNQ SSBQQ0kgTGluayBMTktCCmRldi5wY2lfbGluay4xLiVkcml2ZXI6IHBjaV9saW5rCmRldi5w Y2lfbGluay4xLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0IKZGV2LnBjaV9saW5rLjEu JXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTIKZGV2LnBjaV9saW5rLjEuJXBhcmVudDog YWNwaTAKZGV2LnBjaV9saW5rLjIuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LQwpkZXYucGNp X2xpbmsuMi4lZHJpdmVyOiBwY2lfbGluawpkZXYucGNpX2xpbmsuMi4lbG9jYXRpb246IGhh bmRsZT1cX1NCXy5MTktDCmRldi5wY2lfbGluay4yLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYg X1VJRD0zCmRldi5wY2lfbGluay4yLiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay4zLiVk ZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0QKZGV2LnBjaV9saW5rLjMuJWRyaXZlcjogcGNpX2xp bmsKZGV2LnBjaV9saW5rLjMuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5LRApkZXYucGNp X2xpbmsuMy4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9NApkZXYucGNpX2xpbmsuMy4l cGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuNC4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktF CmRldi5wY2lfbGluay40LiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay40LiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLkxOS0UKZGV2LnBjaV9saW5rLjQuJXBucGluZm86IF9ISUQ9 UE5QMEMwRiBfVUlEPTUKZGV2LnBjaV9saW5rLjQuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9s aW5rLjUuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LRgpkZXYucGNpX2xpbmsuNS4lZHJpdmVy OiBwY2lfbGluawpkZXYucGNpX2xpbmsuNS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktG CmRldi5wY2lfbGluay41LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD02CmRldi5wY2lf bGluay41LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay42LiVkZXNjOiBBQ1BJIFBDSSBM aW5rIExOS0cKZGV2LnBjaV9saW5rLjYuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5r LjYuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5LRwpkZXYucGNpX2xpbmsuNi4lcG5waW5m bzogX0hJRD1QTlAwQzBGIF9VSUQ9NwpkZXYucGNpX2xpbmsuNi4lcGFyZW50OiBhY3BpMApk ZXYucGNpX2xpbmsuNy4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktICmRldi5wY2lfbGluay43 LiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay43LiVsb2NhdGlvbjogaGFuZGxlPVxf U0JfLkxOS0gKZGV2LnBjaV9saW5rLjcuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTgK ZGV2LnBjaV9saW5rLjcuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfaHBldC4wLiVkZXNjOiBI aWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcgpkZXYuYWNwaV9ocGV0LjAuJWRyaXZlcjogYWNw aV9ocGV0CmRldi5hY3BpX2hwZXQuMC4lbG9jYXRpb246IHVua25vd24KZGV2LmFjcGlfaHBl dC4wLiVwbnBpbmZvOiB1bmtub3duCmRldi5hY3BpX2hwZXQuMC4lcGFyZW50OiBhY3BpMApk ZXYucGNpYi4wLiVkZXNjOiBBQ1BJIEhvc3QtUENJIGJyaWRnZQpkZXYucGNpYi4wLiVkcml2 ZXI6IHBjaWIKZGV2LnBjaWIuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwCmRldi5w Y2liLjAuJXBucGluZm86IF9ISUQ9UE5QMEEwOCBfVUlEPTAKZGV2LnBjaWIuMC4lcGFyZW50 OiBhY3BpMApkZXYucGNpYi4xLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRldi5wY2li LjEuJWRyaXZlcjogcGNpYgpkZXYucGNpYi4xLiVsb2NhdGlvbjogc2xvdD0xIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUDBQMgpkZXYucGNpYi4xLiVwbnBpbmZvOiB2ZW5kb3I9 MHg4MDg2IGRldmljZT0weDI5YzEgc3VidmVuZG9yPTB4MTQ2MiBzdWJkZXZpY2U9MHg3Mzk1 IGNsYXNzPTB4MDYwNDAwCmRldi5wY2liLjEuJXBhcmVudDogcGNpMApkZXYucGNpYi4xLndh a2U6IDAKZGV2LnBjaWIuMi4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi4y LiVkcml2ZXI6IHBjaWIKZGV2LnBjaWIuMi4lbG9jYXRpb246IHNsb3Q9MjggZnVuY3Rpb249 MCBoYW5kbGU9XF9TQl8uUENJMC5QRVgwCmRldi5wY2liLjIuJXBucGluZm86IHZlbmRvcj0w eDgwODYgZGV2aWNlPTB4Mjk0MCBzdWJ2ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAg Y2xhc3M9MHgwNjA0MDAKZGV2LnBjaWIuMi4lcGFyZW50OiBwY2kwCmRldi5wY2liLjIud2Fr ZTogMApkZXYucGNpYi4zLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRldi5wY2liLjMu JWRyaXZlcjogcGNpYgpkZXYucGNpYi4zLiVsb2NhdGlvbjogc2xvdD0yOCBmdW5jdGlvbj00 IGhhbmRsZT1cX1NCXy5QQ0kwLlBFWDQKZGV2LnBjaWIuMy4lcG5waW5mbzogdmVuZG9yPTB4 ODA4NiBkZXZpY2U9MHgyOTQ4IHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBj bGFzcz0weDA2MDQwMApkZXYucGNpYi4zLiVwYXJlbnQ6IHBjaTAKZGV2LnBjaWIuMy53YWtl OiAwCmRldi5wY2liLjQuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlkZ2UKZGV2LnBjaWIuNC4l ZHJpdmVyOiBwY2liCmRldi5wY2liLjQuJWxvY2F0aW9uOiBzbG90PTI4IGZ1bmN0aW9uPTUg aGFuZGxlPVxfU0JfLlBDSTAuUEVYNQpkZXYucGNpYi40LiVwbnBpbmZvOiB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDI5NGEgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwIGNs YXNzPTB4MDYwNDAwCmRldi5wY2liLjQuJXBhcmVudDogcGNpMApkZXYucGNpYi40Lndha2U6 IDAKZGV2LnBjaWIuNS4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi41LiVk cml2ZXI6IHBjaWIKZGV2LnBjaWIuNS4lbG9jYXRpb246IHNsb3Q9MzAgZnVuY3Rpb249MCBo YW5kbGU9XF9TQl8uUENJMC5QMFAxCmRldi5wY2liLjUuJXBucGluZm86IHZlbmRvcj0weDgw ODYgZGV2aWNlPTB4MjQ0ZSBzdWJ2ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAgY2xh c3M9MHgwNjA0MDEKZGV2LnBjaWIuNS4lcGFyZW50OiBwY2kwCmRldi5wY2liLjUud2FrZTog MApkZXYucGNpLjAuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjAuJWRyaXZlcjogcGNp CmRldi5wY2kuMC4lcGFyZW50OiBwY2liMApkZXYucGNpLjEuJWRlc2M6IEFDUEkgUENJIGJ1 cwpkZXYucGNpLjEuJWRyaXZlcjogcGNpCmRldi5wY2kuMS4lcGFyZW50OiBwY2liMQpkZXYu cGNpLjEud2FrZTogMApkZXYucGNpLjIuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjIu JWRyaXZlcjogcGNpCmRldi5wY2kuMi4lcGFyZW50OiBwY2liMgpkZXYucGNpLjIud2FrZTog MApkZXYucGNpLjMuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjMuJWRyaXZlcjogcGNp CmRldi5wY2kuMy4lcGFyZW50OiBwY2liMwpkZXYucGNpLjMud2FrZTogMApkZXYucGNpLjQu JWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjQuJWRyaXZlcjogcGNpCmRldi5wY2kuNC4l cGFyZW50OiBwY2liNApkZXYucGNpLjQud2FrZTogMApkZXYucGNpLjUuJWRlc2M6IEFDUEkg UENJIGJ1cwpkZXYucGNpLjUuJWRyaXZlcjogcGNpCmRldi5wY2kuNS4lcGFyZW50OiBwY2li NQpkZXYucGNpLjUud2FrZTogMApkZXYuaG9zdGIuMC4lZGVzYzogSG9zdCB0byBQQ0kgYnJp ZGdlCmRldi5ob3N0Yi4wLiVkcml2ZXI6IGhvc3RiCmRldi5ob3N0Yi4wLiVsb2NhdGlvbjog c2xvdD0wIGZ1bmN0aW9uPTAKZGV2Lmhvc3RiLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYg ZGV2aWNlPTB4MjljMCBzdWJ2ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAgY2xhc3M9 MHgwNjAwMDAKZGV2Lmhvc3RiLjAuJXBhcmVudDogcGNpMApkZXYudmdhcGNpLjAuJWRlc2M6 IFZHQS1jb21wYXRpYmxlIGRpc3BsYXkKZGV2LnZnYXBjaS4wLiVkcml2ZXI6IHZnYXBjaQpk ZXYudmdhcGNpLjAuJWxvY2F0aW9uOiBzbG90PTAgZnVuY3Rpb249MApkZXYudmdhcGNpLjAu JXBucGluZm86IHZlbmRvcj0weDEwMDIgZGV2aWNlPTB4OTVjNSBzdWJ2ZW5kb3I9MHgxMDQz IHN1YmRldmljZT0weDAxZDQgY2xhc3M9MHgwMzAwMDAKZGV2LnZnYXBjaS4wLiVwYXJlbnQ6 IHBjaTEKZGV2LmRybS4wLiVkZXNjOiBBVEkgUmFkZW9uIEhEIDM0NTAKZGV2LmRybS4wLiVk cml2ZXI6IGRybQpkZXYuZHJtLjAuJXBhcmVudDogdmdhcGNpMApkZXYudWhjaS4wLiVkZXNj OiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4wLiVkcml2ZXI6IHVo Y2kKZGV2LnVoY2kuMC4lbG9jYXRpb246IHNsb3Q9MjYgZnVuY3Rpb249MCBoYW5kbGU9XF9T Ql8uUENJMC5VU0IzCmRldi51aGNpLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNl PTB4MjkzNyBzdWJ2ZW5kb3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xhc3M9MHgwYzAz MDAKZGV2LnVoY2kuMC4lcGFyZW50OiBwY2kwCmRldi51aGNpLjAud2FrZTogMApkZXYudWhj aS4xLiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4xLiVk cml2ZXI6IHVoY2kKZGV2LnVoY2kuMS4lbG9jYXRpb246IHNsb3Q9MjYgZnVuY3Rpb249MSBo YW5kbGU9XF9TQl8uUENJMC5VU0I0CmRldi51aGNpLjEuJXBucGluZm86IHZlbmRvcj0weDgw ODYgZGV2aWNlPTB4MjkzOCBzdWJ2ZW5kb3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xh c3M9MHgwYzAzMDAKZGV2LnVoY2kuMS4lcGFyZW50OiBwY2kwCmRldi51aGNpLjEud2FrZTog MApkZXYudWhjaS4yLiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYu dWhjaS4yLiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMi4lbG9jYXRpb246IHNsb3Q9MjYgZnVu Y3Rpb249MgpkZXYudWhjaS4yLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI5 Mzkgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwIGNsYXNzPTB4MGMwMzAwCmRl di51aGNpLjIuJXBhcmVudDogcGNpMApkZXYudWhjaS4zLiVkZXNjOiBVSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4zLiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMy4l bG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5VU0IwCmRl di51aGNpLjMuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkzNCBzdWJ2ZW5k b3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuMy4l cGFyZW50OiBwY2kwCmRldi51aGNpLjMud2FrZTogMApkZXYudWhjaS40LiVkZXNjOiBVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS40LiVkcml2ZXI6IHVoY2kKZGV2 LnVoY2kuNC4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJ MC5VU0IxCmRldi51aGNpLjQuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4Mjkz NSBzdWJ2ZW5kb3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xhc3M9MHgwYzAzMDAKZGV2 LnVoY2kuNC4lcGFyZW50OiBwY2kwCmRldi51aGNpLjQud2FrZTogMApkZXYudWhjaS41LiVk ZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS41LiVkcml2ZXI6 IHVoY2kKZGV2LnVoY2kuNS4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MiBoYW5kbGU9 XF9TQl8uUENJMC5VU0IyCmRldi51aGNpLjUuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4MjkzNiBzdWJ2ZW5kb3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xhc3M9MHgw YzAzMDAKZGV2LnVoY2kuNS4lcGFyZW50OiBwY2kwCmRldi51aGNpLjUud2FrZTogMApkZXYu dXNiLjAuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyCmRldi51c2IuMC4l ZHJpdmVyOiB1c2IKZGV2LnVzYi4wLiVwYXJlbnQ6IHVoY2kwCmRldi51c2IuMS4lZGVzYzog VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXIKZGV2LnVzYi4xLiVkcml2ZXI6IHVzYgpk ZXYudXNiLjEuJXBhcmVudDogdWhjaTEKZGV2LnVzYi4yLiVkZXNjOiBVSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcgpkZXYudXNiLjIuJWRyaXZlcjogdXNiCmRldi51c2IuMi4lcGFy ZW50OiB1aGNpMgpkZXYudXNiLjMuJWRlc2M6IEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29u dHJvbGxlcgpkZXYudXNiLjMuJWRyaXZlcjogdXNiCmRldi51c2IuMy4lcGFyZW50OiBlaGNp MApkZXYudXNiLjQuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyCmRldi51 c2IuNC4lZHJpdmVyOiB1c2IKZGV2LnVzYi40LiVwYXJlbnQ6IHVoY2kzCmRldi51c2IuNS4l ZGVzYzogVUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXIKZGV2LnVzYi41LiVkcml2ZXI6 IHVzYgpkZXYudXNiLjUuJXBhcmVudDogdWhjaTQKZGV2LnVzYi42LiVkZXNjOiBVSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudXNiLjYuJWRyaXZlcjogdXNiCmRldi51c2Iu Ni4lcGFyZW50OiB1aGNpNQpkZXYudXNiLjcuJWRlc2M6IEVIQ0kgKGdlbmVyaWMpIFVTQiAy LjAgY29udHJvbGxlcgpkZXYudXNiLjcuJWRyaXZlcjogdXNiCmRldi51c2IuNy4lcGFyZW50 OiBlaGNpMQpkZXYudWh1Yi4wLiVkZXNjOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4wLiVkcml2ZXI6IHVodWIKZGV2 LnVodWIuMC4lcGFyZW50OiB1c2IwCmRldi51aHViLjEuJWRlc2M6IEludGVsIFVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjEuJWRy aXZlcjogdWh1YgpkZXYudWh1Yi4xLiVwYXJlbnQ6IHVzYjEKZGV2LnVodWIuMi4lZGVzYzog SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEK ZGV2LnVodWIuMi4lZHJpdmVyOiB1aHViCmRldi51aHViLjIuJXBhcmVudDogdXNiMgpkZXYu dWh1Yi4zLiVkZXNjOiBJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAw LzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4zLiVkcml2ZXI6IHVodWIKZGV2LnVodWIuMy4lcGFy ZW50OiB1c2IzCmRldi51aHViLjQuJWRlc2M6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjQuJWRyaXZlcjogdWh1Ygpk ZXYudWh1Yi40LiVwYXJlbnQ6IHVzYjQKZGV2LnVodWIuNS4lZGVzYzogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKZGV2LnVodWIuNS4l ZHJpdmVyOiB1aHViCmRldi51aHViLjUuJXBhcmVudDogdXNiNQpkZXYudWh1Yi42LiVkZXNj OiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MQpkZXYudWh1Yi42LiVkcml2ZXI6IHVodWIKZGV2LnVodWIuNi4lcGFyZW50OiB1c2I2CmRl di51aHViLjcuJWRlc2M6IEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxCmRldi51aHViLjcuJWRyaXZlcjogdWh1YgpkZXYudWh1Yi43LiVw YXJlbnQ6IHVzYjcKZGV2LmVoY2kuMC4lZGVzYzogRUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBj b250cm9sbGVyCmRldi5laGNpLjAuJWRyaXZlcjogZWhjaQpkZXYuZWhjaS4wLiVsb2NhdGlv bjogc2xvdD0yNiBmdW5jdGlvbj03IGhhbmRsZT1cX1NCXy5QQ0kwLlVTQkUKZGV2LmVoY2ku MC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyOTNjIHN1YnZlbmRvcj0weDE0 NjIgc3ViZGV2aWNlPTB4NzM5NSBjbGFzcz0weDBjMDMyMApkZXYuZWhjaS4wLiVwYXJlbnQ6 IHBjaTAKZGV2LmVoY2kuMC53YWtlOiAwCmRldi5laGNpLjEuJWRlc2M6IEVIQ0kgKGdlbmVy aWMpIFVTQiAyLjAgY29udHJvbGxlcgpkZXYuZWhjaS4xLiVkcml2ZXI6IGVoY2kKZGV2LmVo Y2kuMS4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249NyBoYW5kbGU9XF9TQl8uUENJMC5F VVNCCmRldi5laGNpLjEuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkzYSBz dWJ2ZW5kb3I9MHgxNDYyIHN1YmRldmljZT0weDczOTUgY2xhc3M9MHgwYzAzMjAKZGV2LmVo Y2kuMS4lcGFyZW50OiBwY2kwCmRldi5laGNpLjEud2FrZTogMApkZXYuYXRhcGNpLjAuJWRl c2M6IEpNaWNyb24gSk1CMzYzIFNBVEEzMDAgY29udHJvbGxlcgpkZXYuYXRhcGNpLjAuJWRy aXZlcjogYXRhcGNpCmRldi5hdGFwY2kuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0w IGhhbmRsZT1cX1NCXy5QQ0kwLlBFWDQuSk1CMApkZXYuYXRhcGNpLjAuJXBucGluZm86IHZl bmRvcj0weDE5N2IgZGV2aWNlPTB4MjM2MyBzdWJ2ZW5kb3I9MHgxOTdiIHN1YmRldmljZT0w eDIzODAgY2xhc3M9MHgwMTAxODUKZGV2LmF0YXBjaS4wLiVwYXJlbnQ6IHBjaTMKZGV2LmF0 YXBjaS4xLiVkZXNjOiBJbnRlbCBJQ0g5IFNBVEEzMDAgY29udHJvbGxlcgpkZXYuYXRhcGNp LjEuJWRyaXZlcjogYXRhcGNpCmRldi5hdGFwY2kuMS4lbG9jYXRpb246IHNsb3Q9MzEgZnVu Y3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5TQVQwCmRldi5hdGFwY2kuMS4lcG5waW5mbzog dmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyOTIxIHN1YnZlbmRvcj0weDE0NjIgc3ViZGV2aWNl PTB4NzM5NSBjbGFzcz0weDAxMDE4ZgpkZXYuYXRhcGNpLjEuJXBhcmVudDogcGNpMApkZXYu YXRhcGNpLjIuJWRlc2M6IEludGVsIElDSDkgU0FUQTMwMCBjb250cm9sbGVyCmRldi5hdGFw Y2kuMi4lZHJpdmVyOiBhdGFwY2kKZGV2LmF0YXBjaS4yLiVsb2NhdGlvbjogc2xvdD0zMSBm dW5jdGlvbj01IGhhbmRsZT1cX1NCXy5QQ0kwLlNBVDEKZGV2LmF0YXBjaS4yLiVwbnBpbmZv OiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI5MjYgc3VidmVuZG9yPTB4MTQ2MiBzdWJkZXZp Y2U9MHg3Mzk1IGNsYXNzPTB4MDEwMTg1CmRldi5hdGFwY2kuMi4lcGFyZW50OiBwY2kwCmRl di5hdGEuMi4lZGVzYzogQVRBIGNoYW5uZWwgMApkZXYuYXRhLjIuJWRyaXZlcjogYXRhCmRl di5hdGEuMi4lcGFyZW50OiBhdGFwY2kwCmRldi5hdGEuMy4lZGVzYzogQVRBIGNoYW5uZWwg MQpkZXYuYXRhLjMuJWRyaXZlcjogYXRhCmRldi5hdGEuMy4lcGFyZW50OiBhdGFwY2kwCmRl di5hdGEuNC4lZGVzYzogQVRBIGNoYW5uZWwgMgpkZXYuYXRhLjQuJWRyaXZlcjogYXRhCmRl di5hdGEuNC4lcGFyZW50OiBhdGFwY2kwCmRldi5hdGEuNS4lZGVzYzogQVRBIGNoYW5uZWwg MApkZXYuYXRhLjUuJWRyaXZlcjogYXRhCmRldi5hdGEuNS4lcGFyZW50OiBhdGFwY2kxCmRl di5hdGEuNi4lZGVzYzogQVRBIGNoYW5uZWwgMQpkZXYuYXRhLjYuJWRyaXZlcjogYXRhCmRl di5hdGEuNi4lcGFyZW50OiBhdGFwY2kxCmRldi5hdGEuNy4lZGVzYzogQVRBIGNoYW5uZWwg MApkZXYuYXRhLjcuJWRyaXZlcjogYXRhCmRldi5hdGEuNy4lcGFyZW50OiBhdGFwY2kyCmRl di5hdGEuOC4lZGVzYzogQVRBIGNoYW5uZWwgMQpkZXYuYXRhLjguJWRyaXZlcjogYXRhCmRl di5hdGEuOC4lcGFyZW50OiBhdGFwY2kyCmRldi5yZS4wLiVkZXNjOiBSZWFsVGVrIDgxNjgv ODE2OEIvODE2OEMvODE2OENQLzgxNjhELzgxMTFCLzgxMTFDLzgxMTFDUCBQQ0llIEdpZ2Fi aXQgRXRoZXJuZXQKZGV2LnJlLjAuJWRyaXZlcjogcmUKZGV2LnJlLjAuJWxvY2F0aW9uOiBz bG90PTAgZnVuY3Rpb249MApkZXYucmUuMC4lcG5waW5mbzogdmVuZG9yPTB4MTBlYyBkZXZp Y2U9MHg4MTY4IHN1YnZlbmRvcj0weDE0NjIgc3ViZGV2aWNlPTB4Mzk1YyBjbGFzcz0weDAy MDAwMApkZXYucmUuMC4lcGFyZW50OiBwY2k0CmRldi5taWlidXMuMC4lZGVzYzogTUlJIGJ1 cwpkZXYubWlpYnVzLjAuJWRyaXZlcjogbWlpYnVzCmRldi5taWlidXMuMC4lcGFyZW50OiBy ZTAKZGV2LnJnZXBoeS4wLiVkZXNjOiBSVEw4MTY5Uy84MTEwUy84MjExQiBtZWRpYSBpbnRl cmZhY2UKZGV2LnJnZXBoeS4wLiVkcml2ZXI6IHJnZXBoeQpkZXYucmdlcGh5LjAuJWxvY2F0 aW9uOiBwaHlubz0xCmRldi5yZ2VwaHkuMC4lcG5waW5mbzogb3VpPTB4NzMyIG1vZGVsPTB4 MTEgcmV2PTB4MgpkZXYucmdlcGh5LjAuJXBhcmVudDogbWlpYnVzMApkZXYuaXNhYi4wLiVk ZXNjOiBQQ0ktSVNBIGJyaWRnZQpkZXYuaXNhYi4wLiVkcml2ZXI6IGlzYWIKZGV2LmlzYWIu MC4lbG9jYXRpb246IHNsb3Q9MzEgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5TQlJH CmRldi5pc2FiLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkxOCBzdWJ2 ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAgY2xhc3M9MHgwNjAxMDAKZGV2LmlzYWIu MC4lcGFyZW50OiBwY2kwCmRldi5pc2EuMC4lZGVzYzogSVNBIGJ1cwpkZXYuaXNhLjAuJWRy aXZlcjogaXNhCmRldi5pc2EuMC4lcGFyZW50OiBpc2FiMApkZXYuYWNwaV9idXR0b24uMC4l ZGVzYzogU2xlZXAgQnV0dG9uCmRldi5hY3BpX2J1dHRvbi4wLiVkcml2ZXI6IGFjcGlfYnV0 dG9uCmRldi5hY3BpX2J1dHRvbi4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlNMUEIKZGV2 LmFjcGlfYnV0dG9uLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwRSBfVUlEPTAKZGV2LmFjcGlf YnV0dG9uLjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfYnV0dG9uLjAud2FrZTogMQpkZXYu YWNwaV9idXR0b24uMS4lZGVzYzogUG93ZXIgQnV0dG9uCmRldi5hY3BpX2J1dHRvbi4xLiVk cml2ZXI6IGFjcGlfYnV0dG9uCmRldi5hY3BpX2J1dHRvbi4xLiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLlBXUkIKZGV2LmFjcGlfYnV0dG9uLjEuJXBucGluZm86IF9ISUQ9UE5QMEMwQyBf VUlEPTE3MApkZXYuYWNwaV9idXR0b24uMS4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9idXR0 b24uMS53YWtlOiAxCmRldi5hdGtiZGMuMC4lZGVzYzogS2V5Ym9hcmQgY29udHJvbGxlciAo aTgwNDIpCmRldi5hdGtiZGMuMC4lZHJpdmVyOiBhdGtiZGMKZGV2LmF0a2JkYy4wLiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5QUzJLCmRldi5hdGtiZGMuMC4lcG5waW5m bzogX0hJRD1QTlAwMzAzIF9VSUQ9MApkZXYuYXRrYmRjLjAuJXBhcmVudDogYWNwaTAKZGV2 LmF0a2JkYy4wLndha2U6IDAKZGV2LmF0a2JkLjAuJWRlc2M6IEFUIEtleWJvYXJkCmRldi5h dGtiZC4wLiVkcml2ZXI6IGF0a2JkCmRldi5hdGtiZC4wLiVwYXJlbnQ6IGF0a2JkYzAKZGV2 LnBzbWNwbnAuMC4lZGVzYzogUFMvMiBtb3VzZSBwb3J0CmRldi5wc21jcG5wLjAuJWRyaXZl cjogcHNtY3BucApkZXYucHNtY3BucC4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAu U0JSRy5QUzJNCmRldi5wc21jcG5wLjAuJXBucGluZm86IF9ISUQ9UE5QMEYwMyBfVUlEPTAK ZGV2LnBzbWNwbnAuMC4lcGFyZW50OiBhY3BpMApkZXYucHNtY3BucC4wLndha2U6IDAKZGV2 LnBzbS4wLiVkZXNjOiBQUy8yIE1vdXNlCmRldi5wc20uMC4lZHJpdmVyOiBwc20KZGV2LnBz bS4wLiVwYXJlbnQ6IGF0a2JkYzAKZGV2LnNpby4wLiVkZXNjOiAxNjU1MEEtY29tcGF0aWJs ZSBDT00gcG9ydApkZXYuc2lvLjAuJWRyaXZlcjogc2lvCmRldi5zaW8uMC4lbG9jYXRpb246 IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuVUFSMQpkZXYuc2lvLjAuJXBucGluZm86IF9ISUQ9 UE5QMDUwMSBfVUlEPTEKZGV2LnNpby4wLiVwYXJlbnQ6IGFjcGkwCmRldi5zaW8uMS4lZGVz YzogMTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQKZGV2LnNpby4xLiVkcml2ZXI6IHNpbwpk ZXYuc2lvLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLlVBUjIKZGV2LnNp by4xLiVwbnBpbmZvOiBfSElEPVBOUDA1MDEgX1VJRD0yCmRldi5zaW8uMS4lcGFyZW50OiBh Y3BpMApkZXYucHBjLjAuJWRlc2M6IFBhcmFsbGVsIHBvcnQKZGV2LnBwYy4wLiVkcml2ZXI6 IHBwYwpkZXYucHBjLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLkxQVEUK ZGV2LnBwYy4wLiVwbnBpbmZvOiBfSElEPVBOUDA0MDAgX1VJRD0wCmRldi5wcGMuMC4lcGFy ZW50OiBhY3BpMApkZXYucHBidXMuMC4lZGVzYzogUGFyYWxsZWwgcG9ydCBidXMKZGV2LnBw YnVzLjAuJWRyaXZlcjogcHBidXMKZGV2LnBwYnVzLjAuJXBhcmVudDogcHBjMApkZXYucGxp cC4wLiVkZXNjOiBQTElQIG5ldHdvcmsgaW50ZXJmYWNlCmRldi5wbGlwLjAuJWRyaXZlcjog cGxpcApkZXYucGxpcC4wLiVwYXJlbnQ6IHBwYnVzMApkZXYubHB0LjAuJWRlc2M6IFByaW50 ZXIKZGV2LmxwdC4wLiVkcml2ZXI6IGxwdApkZXYubHB0LjAuJXBhcmVudDogcHBidXMwCmRl di5wcGkuMC4lZGVzYzogUGFyYWxsZWwgSS9PCmRldi5wcGkuMC4lZHJpdmVyOiBwcGkKZGV2 LnBwaS4wLiVwYXJlbnQ6IHBwYnVzMApkZXYuYXRkbWEuMC4lZGVzYzogQVQgRE1BIGNvbnRy b2xsZXIKZGV2LmF0ZG1hLjAuJWRyaXZlcjogYXRkbWEKZGV2LmF0ZG1hLjAuJWxvY2F0aW9u OiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLkRNQUQKZGV2LmF0ZG1hLjAuJXBucGluZm86IF9I SUQ9UE5QMDIwMCBfVUlEPTAKZGV2LmF0ZG1hLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0dGlt ZXIuMC4lZGVzYzogQVQgdGltZXIKZGV2LmF0dGltZXIuMC4lZHJpdmVyOiBhdHRpbWVyCmRl di5hdHRpbWVyLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLlRNUl8KZGV2 LmF0dGltZXIuMC4lcG5waW5mbzogX0hJRD1QTlAwMTAwIF9VSUQ9MApkZXYuYXR0aW1lci4w LiVwYXJlbnQ6IGFjcGkwCmRldi5hdHRpbWVyLjEuJWRlc2M6IEFUIHJlYWx0aW1lIGNsb2Nr CmRldi5hdHRpbWVyLjEuJWRyaXZlcjogYXR0aW1lcgpkZXYuYXR0aW1lci4xLiVsb2NhdGlv bjogaGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5SVEMwCmRldi5hdHRpbWVyLjEuJXBucGluZm86 IF9ISUQ9UE5QMEIwMCBfVUlEPTAKZGV2LmF0dGltZXIuMS4lcGFyZW50OiBhY3BpMApkZXYu ZnB1cG5wLjAuJWRlc2M6IExlZ2FjeSBJU0EgY29wcm9jZXNzb3Igc3VwcG9ydApkZXYuZnB1 cG5wLjAuJWRyaXZlcjogZnB1cG5wCmRldi5mcHVwbnAuMC4lbG9jYXRpb246IGhhbmRsZT1c X1NCXy5QQ0kwLlNCUkcuQ09QUgpkZXYuZnB1cG5wLjAuJXBucGluZm86IF9ISUQ9UE5QMEMw NCBfVUlEPTAKZGV2LmZwdXBucC4wLiVwYXJlbnQ6IGFjcGkwCmRldi5jcHUuMC4lZGVzYzog QUNQSSBDUFUKZGV2LmNwdS4wLiVkcml2ZXI6IGNwdQpkZXYuY3B1LjAuJWxvY2F0aW9uOiBo YW5kbGU9XF9QUl8uQ1BVMQpkZXYuY3B1LjAuJXBucGluZm86IF9ISUQ9bm9uZSBfVUlEPTAK ZGV2LmNwdS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5jcHUuMC50ZW1wZXJhdHVyZTogNDQKZGV2 LmNwdS4wLmZyZXE6IDI0OTMKZGV2LmNwdS4wLmZyZXFfbGV2ZWxzOiAyNDkzLy0xIDIxODEv LTEgMTg2OS8tMSAxNTU4Ly0xIDEyNDYvLTEgOTM0Ly0xIDYyMy8tMSAzMTEvLTEKZGV2LmNw dS4wLmN4X3N1cHBvcnRlZDogQzEvMApkZXYuY3B1LjAuY3hfbG93ZXN0OiBDMQpkZXYuY3B1 LjAuY3hfdXNhZ2U6IDEwMC4wMCUKZGV2LmNwdS4xLiVkZXNjOiBBQ1BJIENQVQpkZXYuY3B1 LjEuJWRyaXZlcjogY3B1CmRldi5jcHUuMS4lbG9jYXRpb246IGhhbmRsZT1cX1BSXy5DUFUy CmRldi5jcHUuMS4lcG5waW5mbzogX0hJRD1ub25lIF9VSUQ9MApkZXYuY3B1LjEuJXBhcmVu dDogYWNwaTAKZGV2LmNwdS4xLnRlbXBlcmF0dXJlOiA0NgpkZXYuY3B1LjEuY3hfc3VwcG9y dGVkOiBDMS8wCmRldi5jcHUuMS5jeF9sb3dlc3Q6IEMxCmRldi5jcHUuMS5jeF91c2FnZTog MTAwLjAwJQpkZXYuY29yZXRlbXAuMC4lZGVzYzogQ1BVIE9uLURpZSBUaGVybWFsIFNlbnNv cnMKZGV2LmNvcmV0ZW1wLjAuJWRyaXZlcjogY29yZXRlbXAKZGV2LmNvcmV0ZW1wLjAuJXBh cmVudDogY3B1MApkZXYuY29yZXRlbXAuMS4lZGVzYzogQ1BVIE9uLURpZSBUaGVybWFsIFNl bnNvcnMKZGV2LmNvcmV0ZW1wLjEuJWRyaXZlcjogY29yZXRlbXAKZGV2LmNvcmV0ZW1wLjEu JXBhcmVudDogY3B1MQpkZXYucDR0Y2MuMC4lZGVzYzogQ1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2wKZGV2LnA0dGNjLjAuJWRyaXZlcjogcDR0Y2MKZGV2LnA0dGNjLjAuJXBhcmVu dDogY3B1MApkZXYucDR0Y2MuMC5mcmVxX3NldHRpbmdzOiAxMDAwMC8tMSA4NzUwLy0xIDc1 MDAvLTEgNjI1MC8tMSA1MDAwLy0xIDM3NTAvLTEgMjUwMC8tMSAxMjUwLy0xCmRldi5wNHRj Yy4xLiVkZXNjOiBDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbApkZXYucDR0Y2MuMS4l ZHJpdmVyOiBwNHRjYwpkZXYucDR0Y2MuMS4lcGFyZW50OiBjcHUxCmRldi5wNHRjYy4xLmZy ZXFfc2V0dGluZ3M6IDEwMDAwLy0xIDg3NTAvLTEgNzUwMC8tMSA2MjUwLy0xIDUwMDAvLTEg Mzc1MC8tMSAyNTAwLy0xIDEyNTAvLTEKZGV2LmNwdWZyZXEuMC4lZHJpdmVyOiBjcHVmcmVx CmRldi5jcHVmcmVxLjAuJXBhcmVudDogY3B1MApkZXYuY3B1ZnJlcS4xLiVkcml2ZXI6IGNw dWZyZXEKZGV2LmNwdWZyZXEuMS4lcGFyZW50OiBjcHUxCmRldi5hcGljLjAuJWRlc2M6IEFQ SUMgcmVzb3VyY2VzCmRldi5hcGljLjAuJWRyaXZlcjogYXBpYwpkZXYuYXBpYy4wLiVwYXJl bnQ6IG5leHVzMApkZXYuaWNod2QuMC4lZGVzYzogSW50ZWwgSUNIOSB3YXRjaGRvZyB0aW1l cgpkZXYuaWNod2QuMC4lZHJpdmVyOiBpY2h3ZApkZXYuaWNod2QuMC4lcGFyZW50OiBpc2Ew CmRldi5vcm0uMC4lZGVzYzogSVNBIE9wdGlvbiBST01zCmRldi5vcm0uMC4lZHJpdmVyOiBv cm0KZGV2Lm9ybS4wLiVwYXJlbnQ6IGlzYTAKZGV2LnNjLjAuJWRlc2M6IFN5c3RlbSBjb25z b2xlCmRldi5zYy4wLiVkcml2ZXI6IHNjCmRldi5zYy4wLiVwYXJlbnQ6IGlzYTAKZGV2LnZn YS4wLiVkZXNjOiBHZW5lcmljIElTQSBWR0EKZGV2LnZnYS4wLiVkcml2ZXI6IHZnYQpkZXYu dmdhLjAuJXBhcmVudDogaXNhMApkZXYuYWNkLjAuJWRlc2M6IEFUQVBJIERWRCBBIERIMjBB NFAvOVA1OQpkZXYuYWNkLjAuJWRyaXZlcjogYWNkCmRldi5hY2QuMC4lcGFyZW50OiBhdGE0 CmRldi5hZC4xMC4lZGVzYzogV0RDIFdENjQwMEFBS1MtMDBBN0IyLzAxLjAzQjAxCmRldi5h ZC4xMC4lZHJpdmVyOiBhZApkZXYuYWQuMTAuJXBhcmVudDogYXRhNQpkZXYuaGRhYy4wLiVk ZXNjOiBJbnRlbCA4MjgwMUkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXIKZGV2 LmhkYWMuMC4lZHJpdmVyOiBoZGFjCmRldi5oZGFjLjAuJWxvY2F0aW9uOiBzbG90PTI3IGZ1 bmN0aW9uPTAKZGV2LmhkYWMuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgy OTNlIHN1YnZlbmRvcj0weDE0NjIgc3ViZGV2aWNlPTB4NzM5NSBjbGFzcz0weDA0MDMwMApk ZXYuaGRhYy4wLiVwYXJlbnQ6IHBjaTAKZGV2LmhkYWMuMC5wb2xsaW5nOiAwCmRldi5oZGFj LjAucG9sbGluZ19pbnRlcnZhbDogMjUwCmRldi5oZGFjLjAucGluZHVtcDogMApkZXYuaGRh Yy4xLiVkZXNjOiBBVEkgUlY2MjAgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXIK ZGV2LmhkYWMuMS4lZHJpdmVyOiBoZGFjCmRldi5oZGFjLjEuJWxvY2F0aW9uOiBzbG90PTAg ZnVuY3Rpb249MQpkZXYuaGRhYy4xLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMDAyIGRldmljZT0w eGFhMjggc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHhhYTI4IGNsYXNzPTB4MDQwMzAw CmRldi5oZGFjLjEuJXBhcmVudDogcGNpMQpkZXYuaGRhYy4xLnBvbGxpbmc6IDAKZGV2Lmhk YWMuMS5wb2xsaW5nX2ludGVydmFsOiAyNTAKZGV2LmhkYWMuMS5waW5kdW1wOiAwCmRldi5w Y20uMC4lZGVzYzogSERBIFJlYWx0ZWsgQUxDODg4IFBDTSAjMCBBbmFsb2cKZGV2LnBjbS4w LiVkcml2ZXI6IHBjbQpkZXYucGNtLjAuJXBhcmVudDogaGRhYzAKZGV2LnBjbS4wLnBsYXku dmNoYW5zOiAxCmRldi5wY20uMC5wbGF5LnZjaGFucmF0ZTogNDgwMDAKZGV2LnBjbS4wLnBs YXkudmNoYW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMC5yZWMudmNoYW5zOiAxCmRldi5wY20u MC5yZWMudmNoYW5yYXRlOiA0ODAwMApkZXYucGNtLjAucmVjLnZjaGFuZm9ybWF0OiBzMTZs ZQpkZXYucGNtLjAuYnVmZmVyc2l6ZTogMTYzODQKZGV2LnBjbS4xLiVkZXNjOiBIREEgUmVh bHRlayBBTEM4ODggUENNICMxIEFuYWxvZwpkZXYucGNtLjEuJWRyaXZlcjogcGNtCmRldi5w Y20uMS4lcGFyZW50OiBoZGFjMApkZXYucGNtLjEucGxheS52Y2hhbnM6IDEKZGV2LnBjbS4x LnBsYXkudmNoYW5yYXRlOiA0ODAwMApkZXYucGNtLjEucGxheS52Y2hhbmZvcm1hdDogczE2 bGUKZGV2LnBjbS4xLnJlYy52Y2hhbnM6IDEKZGV2LnBjbS4xLnJlYy52Y2hhbnJhdGU6IDQ4 MDAwCmRldi5wY20uMS5yZWMudmNoYW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMS5idWZmZXJz aXplOiAxNjM4NApkZXYucGNtLjIuJWRlc2M6IEhEQSBSZWFsdGVrIEFMQzg4OCBQQ00gIzIg RGlnaXRhbApkZXYucGNtLjIuJWRyaXZlcjogcGNtCmRldi5wY20uMi4lcGFyZW50OiBoZGFj MApkZXYucGNtLjIucGxheS52Y2hhbnM6IDEKZGV2LnBjbS4yLnBsYXkudmNoYW5yYXRlOiA0 ODAwMApkZXYucGNtLjIucGxheS52Y2hhbmZvcm1hdDogczE2bGUKZGV2LnBjbS4yLmJ1ZmZl cnNpemU6IDE2Mzg0CmRldi5wY20uMy4lZGVzYzogSERBIEFUSSBSNnh4IEhETUkgUENNICMw IERpZ2l0YWwKZGV2LnBjbS4zLiVkcml2ZXI6IHBjbQpkZXYucGNtLjMuJXBhcmVudDogaGRh YzEKZGV2LnBjbS4zLnBsYXkudmNoYW5zOiAxCmRldi5wY20uMy5wbGF5LnZjaGFucmF0ZTog NDgwMDAKZGV2LnBjbS4zLnBsYXkudmNoYW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMy5idWZm ZXJzaXplOiAxNjM4NAo= --------------010207030806030006010706-- From owner-freebsd-acpi@FreeBSD.ORG Fri May 8 10:34:54 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Fri May 8 13:10:39 2009 Return-Path: Delivered-To: freebsd-acpi@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-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development 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-acpi@FreeBSD.ORG Fri May 8 13:44:25 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B8B1065670 for ; Fri, 8 May 2009 13:44:25 +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 3CC9C8FC1F for ; Fri, 8 May 2009 13:44:24 +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 QAA20305; Fri, 08 May 2009 16:44:21 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A043734.7080700@icyb.net.ua> Date: Fri, 08 May 2009 16:44:20 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: dsewnr.buffer@gmail.com References: <4A0397B2.5000303@gmail.com> In-Reply-To: <4A0397B2.5000303@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi problem ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 13:44:25 -0000 on 08/05/2009 05:23 Dsewnr Lu said the following: > Hi all, > > My command "shutdown -p now" can not poweroff automatically, it halt on > the last screen with uptime and my keyboard is hang, too. > And "reboot" or "shutdown -h now" work fine. Is it an acpi problem ? > There're my kernel config, dmesg and sysctl message. Any idea ? > > Thanks, It might very well be. Some older BIOSes included ACPI tables with incorrect information. I don't think that this happens often on modern system, but it's still possible. Please share your acpidump -dt output. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri May 8 16:10:47 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A29106566C for ; Fri, 8 May 2009 16:10:47 +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 B5D548FC08 for ; Fri, 8 May 2009 16:10:46 +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 TAA22246; Fri, 08 May 2009 19:10:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A045983.9060600@icyb.net.ua> Date: Fri, 08 May 2009 19:10:43 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: dsewnr.buffer@gmail.com References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> In-Reply-To: <4A045715.3030503@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi problem ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 16:10:47 -0000 on 08/05/2009 19:00 Dsewnr Lu said the following: > This is my acpidump -dt output. I couldn't find anything obviously wrong, sorry. Maybe somebody else could spot something. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri May 8 16:13:18 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DDC71065670 for ; Fri, 8 May 2009 16:13:18 +0000 (UTC) (envelope-from dsewnr.buffer@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE108FC1A for ; Fri, 8 May 2009 16:13:18 +0000 (UTC) (envelope-from dsewnr.buffer@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so1265523rvb.43 for ; Fri, 08 May 2009 09:13:17 -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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=aqMLuVgR8KR8m/T6ysgBHee+LB6jimi1od+WypDaYB4=; b=RrIxcQ5y0WiBUiBgEBB84mBcJiGkNF9tsYUeaJJoqsZTfgdRznPUNF5prGykEJl1On Dm3i+eotu9hFQRzyO7BoFM4IDAvgcwa7gbNPaPBARkt+tk82Qy1xNi08avFwRxC6XCyb apcHbVk9O1+kkQawxFzXj/+cTxAUY5kIMHUJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EOPk3jZbUqY0piEE9Ae7K7Kp85MLpFXGbeQNFqX6AphWFpwW+baThn1/6BZSK8d1ke LX9UEH4Br7uQldTmYA3mkPO7s1JgxJ0qDZNunEZvD9lVEQZVKUzMZzxndpAXl48lh/uM ZgN29u68E6EcTWPFylTkWdzHXV4mJGC7vkfHs= Received: by 10.114.57.1 with SMTP id f1mr3621332waa.145.1241799197841; Fri, 08 May 2009 09:13:17 -0700 (PDT) Received: from dorara.twbbs.org (59-127-33-87.HINET-IP.hinet.net [59.127.33.87]) by mx.google.com with ESMTPS id n20sm4557638pof.27.2009.05.08.09.13.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 May 2009 09:13:16 -0700 (PDT) Message-ID: <4A045A18.90807@gmail.com> Date: Sat, 09 May 2009 00:13:12 +0800 From: Dsewnr Lu User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: Andriy Gapon References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> <4A045983.9060600@icyb.net.ua> In-Reply-To: <4A045983.9060600@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi problem ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dsewnr.buffer@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 16:13:18 -0000 Andriy Gapon wrote: > on 08/05/2009 19:00 Dsewnr Lu said the following: > >> This is my acpidump -dt output. >> > > I couldn't find anything obviously wrong, sorry. Maybe somebody else could spot > something. > > Thanks a lot. :) Dsewnr Lu From owner-freebsd-acpi@FreeBSD.ORG Sat May 9 16:06:58 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9752106564A for ; Sat, 9 May 2009 16:06:58 +0000 (UTC) (envelope-from root@free.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 82A9B8FC0A for ; Sat, 9 May 2009 16:06:56 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id C1D3ECA987B for ; Sat, 9 May 2009 17:51:07 +0200 (CEST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 4FB538180C2 for ; Sat, 9 May 2009 17:51:01 +0200 (CEST) Received: from free.fr (evr27-1-88-172-40-194.fbx.proxad.net [88.172.40.194]) by smtp3-g21.free.fr (Postfix) with ESMTP id 6D10481808E for ; Sat, 9 May 2009 17:50:59 +0200 (CEST) From: rmgls@free.fr To: freebsd-acpi@freebsd.org Date: Sat, 09 May 2009 17:50:55 +0200 Sender: root@free.fr Message-Id: <20090509155059.6D10481808E@smtp3-g21.free.fr> Subject: Temperature problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 16:06:59 -0000 Hello everyone, i encounter a temperature problem on my laptop a SONY VAIO S5, running current. This problem occurs since perhaps five months only. when compiling some big programs, say src and even, only libc, i see on a distant console (dconschat): acpi_tz0 temperature 93.9C decreasing clock speed from 2133MHZ to 1867MHZ. and the machine freeze. this happen without any modification of the clock hz in rc.loader. Please, can you help to solve this problem? many thanks. Raoul rmgls@free.fr P.S. please cc: rmgls@free.fr, i am not subscribed. From owner-freebsd-acpi@FreeBSD.ORG Sat May 9 20:53:15 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0E51065670 for ; Sat, 9 May 2009 20:53:15 +0000 (UTC) (envelope-from ghostp@mcss.hu) Received: from s2.mcss.hu (s2.mcss.hu [87.229.26.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6313E8FC20 for ; Sat, 9 May 2009 20:53:15 +0000 (UTC) (envelope-from ghostp@mcss.hu) Received: from dzsy-note.dzsy.org (catv-89-135-84-146.catv.broadband.hu [89.135.84.146]) by s2.mcss.hu (Postfix) with ESMTP id 0C1634E58F1 for ; Sat, 9 May 2009 22:26:28 +0200 (CEST) Message-ID: <4A05E6F6.8000309@mcss.hu> Date: Sat, 09 May 2009 22:26:30 +0200 From: =?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?= User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD no brightness control on Acer laptop X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 20:53:15 -0000 Hi everyone, I have a Acer Extensa 5620 laptop and i didn't change the brightness with keys or sysctl value. I loaded asus, ibm and other laptop acpi modul, but nothing change. Anyone has an idea how can i change the brightness fater the system booted? ( Without ACPI i can change, the brightness. ) I send a PR too: http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 Now my system is: FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 23:13:54 CEST 2009 ... i386 Thanks, Peter From owner-freebsd-acpi@FreeBSD.ORG Sat May 9 21:09:55 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E32106564A for ; Sat, 9 May 2009 21:09:55 +0000 (UTC) (envelope-from ghostp@dzsy.org) Received: from s2.mcss.hu (s2.mcss.hu [87.229.26.185]) by mx1.freebsd.org (Postfix) with ESMTP id E94588FC08 for ; Sat, 9 May 2009 21:09:54 +0000 (UTC) (envelope-from ghostp@dzsy.org) Received: from dzsy-note.dzsy.org (catv-89-135-84-146.catv.broadband.hu [89.135.84.146]) by s2.mcss.hu (Postfix) with ESMTP id F407E4E58F3 for ; Sat, 9 May 2009 22:41:55 +0200 (CEST) Message-ID: <4A05EA96.4090908@dzsy.org> Date: Sat, 09 May 2009 22:41:58 +0200 From: =?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?= User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: No brightness control on Acer laptop X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 21:09:55 -0000 Hi everyone, I have a Acer Extensa 5620 laptop and i didn't change the brightness with keys or sysctl value. I loaded asus, ibm and other laptop acpi modul, but nothing change. Anyone has an idea how can i change the brightness fater the system booted? ( Without ACPI i can change, the brightness. ) I send a PR too: http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 Now my system is: FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 23:13:54 CEST 2009 ... i386 Thanks, Peter