Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 | What: /sys/firmware/acpi/bgrt/ Date: January 2012 Contact: Matthew Garrett <mjg@redhat.com> Description: The BGRT is an ACPI 5.0 feature that allows the OS to obtain a copy of the firmware boot splash and some associated metadata. This is intended to be used by boot splash applications in order to interact with the firmware boot splash in order to avoid jarring transitions. image: The image bitmap. Currently a 32-bit BMP. status: 1 if the image is valid, 0 if firmware invalidated it. type: 0 indicates image is in BMP format. ======== =================================================== version: The version of the BGRT. Currently 1. xoffset: The number of pixels between the left of the screen and the left edge of the image. yoffset: The number of pixels between the top of the screen and the top edge of the image. ======== =================================================== What: /sys/firmware/acpi/hotplug/ Date: February 2013 Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Description: There are separate hotplug profiles for different classes of devices supported by ACPI, such as containers, memory modules, processors, PCI root bridges etc. A hotplug profile for a given class of devices is a collection of settings defining the way that class of devices will be handled by the ACPI core hotplug code. Those profiles are represented in sysfs as subdirectories of /sys/firmware/acpi/hotplug/. The following setting is available to user space for each hotplug profile: ======== ======================================================= enabled: If set, the ACPI core will handle notifications of hotplug events associated with the given class of devices and will allow those devices to be ejected with the help of the _EJ0 control method. Unsetting it effectively disables hotplug for the correspoinding class of devices. ======== ======================================================= The value of the above attribute is an integer number: 1 (set) or 0 (unset). Attempts to write any other values to it will cause -EINVAL to be returned. What: /sys/firmware/acpi/interrupts/ Date: February 2008 Contact: Len Brown <lenb@kernel.org> Description: All ACPI interrupts are handled via a single IRQ, the System Control Interrupt (SCI), which appears as "acpi" in /proc/interrupts. However, one of the main functions of ACPI is to make the platform understand random hardware without special driver support. So while the SCI handles a few well known (fixed feature) interrupts sources, such as the power button, it can also handle a variable number of a "General Purpose Events" (GPE). A GPE vectors to a specified handler in AML, which can do a anything the BIOS writer wants from OS context. GPE 0x12, for example, would vector to a level or edge handler called _L12 or _E12. The handler may do its business and return. Or the handler may send send a Notify event to a Linux device driver registered on an ACPI device, such as a battery, or a processor. To figure out where all the SCI's are coming from, /sys/firmware/acpi/interrupts contains a file listing every possible source, and the count of how many times it has triggered:: $ cd /sys/firmware/acpi/interrupts $ grep . * error: 0 ff_gbl_lock: 0 enable ff_pmtimer: 0 invalid ff_pwr_btn: 0 enable ff_rt_clk: 2 disable ff_slp_btn: 0 invalid gpe00: 0 invalid gpe01: 0 enable gpe02: 108 enable gpe03: 0 invalid gpe04: 0 invalid gpe05: 0 invalid gpe06: 0 enable gpe07: 0 enable gpe08: 0 invalid gpe09: 0 invalid gpe0A: 0 invalid gpe0B: 0 invalid gpe0C: 0 invalid gpe0D: 0 invalid gpe0E: 0 invalid gpe0F: 0 invalid gpe10: 0 invalid gpe11: 0 invalid gpe12: 0 invalid gpe13: 0 invalid gpe14: 0 invalid gpe15: 0 invalid gpe16: 0 invalid gpe17: 1084 enable gpe18: 0 enable gpe19: 0 invalid gpe1A: 0 invalid gpe1B: 0 invalid gpe1C: 0 invalid gpe1D: 0 invalid gpe1E: 0 invalid gpe1F: 0 invalid gpe_all: 1192 sci: 1194 sci_not: 0 =========== ================================================== sci The number of times the ACPI SCI has been called and claimed an interrupt. sci_not The number of times the ACPI SCI has been called and NOT claimed an interrupt. gpe_all count of SCI caused by GPEs. gpeXX count for individual GPE source ff_gbl_lock Global Lock ff_pmtimer PM Timer ff_pwr_btn Power Button ff_rt_clk Real Time Clock ff_slp_btn Sleep Button error an interrupt that can't be accounted for above. invalid it's either a GPE or a Fixed Event that doesn't have an event handler. disable the GPE/Fixed Event is valid but disabled. enable the GPE/Fixed Event is valid and enabled. =========== ================================================== Root has permission to clear any of these counters. Eg.:: # echo 0 > gpe11 All counters can be cleared by clearing the total "sci":: # echo 0 > sci None of these counters has an effect on the function of the system, they are simply statistics. Besides this, user can also write specific strings to these files to enable/disable/clear ACPI interrupts in user space, which can be used to debug some ACPI interrupt storm issues. Note that only writing to VALID GPE/Fixed Event is allowed, i.e. user can only change the status of runtime GPE and Fixed Event with event handler installed. Let's take power button fixed event for example, please kill acpid and other user space applications so that the machine won't shutdown when pressing the power button:: # cat ff_pwr_btn 0 enabled # press the power button for 3 times; # cat ff_pwr_btn 3 enabled # echo disable > ff_pwr_btn # cat ff_pwr_btn 3 disabled # press the power button for 3 times; # cat ff_pwr_btn 3 disabled # echo enable > ff_pwr_btn # cat ff_pwr_btn 4 enabled /* * this is because the status bit is set even if the enable * bit is cleared, and it triggers an ACPI fixed event when * the enable bit is set again */ # press the power button for 3 times; # cat ff_pwr_btn 7 enabled # echo disable > ff_pwr_btn # press the power button for 3 times; # echo clear > ff_pwr_btn /* clear the status bit */ # echo disable > ff_pwr_btn # cat ff_pwr_btn 7 enabled |