Cet article est un transcript de notre webinaire sur le Linux Hardening.

ztmux => tmux Superset. Contribute to MenkeTechnologies/ztmux development by creating an account on GitHub.

This is the motto of the FreeBSD operating system – _The Power to Serve_ – which also greatly fits for the topic of this article. Decade ago (yes time flies) I even made a wallpaper with this motto – still available on the DeviatArt page. Time for FreeBSD article covering its power management features. It also applies to _FreeBSD Desktop_ series but its not limited to it. Popular opinion seems to be that FreeBSD is so server oriented that it lacks any power management mechanisms. Nothing more far from the truth. While less important on the desktop (but will still lower your electricity bill) or servers it is desirable to properly configure power management on laptops to so they will have longer battery life and will run more quiet. I write this as the _FreeBSD Handbook_ does not cover all that information in the 11.13. Power and Resource Management chapter. The _FreeBSD on Laptops_ article part 4. Power Management is from the ancient times of FreeBSD 10.1-RELEASE. There is some information on the FreeBSD Wiki page but parts of it are outdated. FreeBSD offers many mechanisms in the power management department: * power off devices without attached driver * scale CPU frequency and power * supports CPU sleep states (C1/C1E/C2/C3/…) * enabling/disabling Turbo Mode available in most CPUs * per USB device power management options * SATA/AHCI channels/controllers power management * suspend/resume support (along with using laptop lid for it) * support for vendor specific tools that help to measure power management * tools and ACPI support for fan speed control * tools and ACPI support for setting screen brightness * battery capacity status and running time estimation * network interfaces power saving options * support for AMD PowerNow! * support for Intel (Enhanced) SpeedStep * support for Intel Speed Shift * support for AMD Turbo Core * support for Intel Turbo Boost One word about different files for the settings in the FreeBSD system: * **`/etc/rc.conf`** – does not require reboot just daemons reloading * **`/etc/sysctl.conf`** – does not require reboot – you can set them at runtime * **`/boot/loader.conf`** – these settings REQUIRE reboot Here is the _Table of Contents_ (non-clickable) for the article. * **Information** * **Battery** * **Battery Wear** * **CPU** * **`lscpu(1)`** * **`dmesg(8)`** * **CPU Frequency Scaling** * **`powerd(8)`** * **`powerdxx(8)`** * **C-States** * **CPU Turbo Mode** * **USB Devices** * **SATA/AHCI Power Management** * **Devices without Driver** * **Nvidia Optimus** * **Suspend and Resume** * **Network Interfaces** * **Vendor Tools** * **DTrace** * **Other** * **ZFS** * **Applications** * **Hardware** * **UPDATE 1 – Graphics Card Power Saving** * **UPDATE 2 – AMD CPU Temperatures** * **UPDATE 3 – Suspend/Resume Tips** * **UPDATE 4 – Intel Speed Shift** # Information Let’s start by describing where to get needed information about current CPU speed, used C-states, current power management modes for USB devices, battery capacity and remaining time, etc. ## Battery To get battery information you can use the **`acpiconf(8)`** tool. This is the **`acpiconf(8)`** output for my main battery (in the ThinkPad T420s laptop) with AC power attached. % **acpiconf -i 0** Design capacity: 44000 mWh Last full capacity: 37930 mWh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 1896 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 45N1037 Serial number: 28608 Type: LION OEM info: SANYO State: high Remaining capacity: 100% Remaining time: unknown Present rate: 0 mW Present voltage: 12495 mV … and with AC power detached. % **acpiconf -i 0** Design capacity: 44000 mWh Last full capacity: 37930 mWh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 1896 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 45N1037 Serial number: 28608 Type: LION OEM info: SANYO State: high Remaining capacity: 100% Remaining time: 2:31 Present rate: 0 mW Present voltage: 12492 mV Now as AC power is detached from the laptop the **`Remaining time:`** field will show you remaining time estimation for this single battery shows as **`2:31`** here (two hours and thirty one minutes). Below is **`acpiconf(8)`** output for my secondary battery (in ThinkPad T420s ultrabay instead of DVD drive). % **acpiconf -i 1** Design capacity: 31320 mWh Last full capacity: 24510 mWh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 1225 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 45N1041 Serial number: 260 Type: LiP OEM info: SONY State: high Remaining capacity: 100% Remaining time: unknown Present rate: 0 mW Present voltage: 12082 mV … and with AC power detached. % **acpiconf -i 1** Design capacity: 31320 mWh Last full capacity: 24510 mWh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 1225 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 45N1041 Serial number: 260 Type: LiP OEM info: SONY State: discharging Remaining capacity: 98% Remaining time: 1:36 Present rate: 14986 mW Present voltage: 11810 mV With AC power detached it shows the **`Remaining time:`** as **`1:36`** for the secondary battery. So its total **`4:07`** time on battery estimated. The same time in minutes (**`247`**) will be shown in the **`sysctl(8)`** value named **`hw.acpi.battery.time`** as shown below. % **sysctl hw.acpi.battery.time** hw.acpi.battery.time: 247 You can also get more ‘complete’ battery information with below **`sysctl(8)`** values under **`hw.acpi.battery`** MIB. % **sysctl hw.acpi.battery** hw.acpi.battery.info_expire: 5 hw.acpi.battery.units: 2 hw.acpi.battery.state: 1 hw.acpi.battery.time: 247 hw.acpi.battery.life: 99 The **`hw.acpi.battery.time`** will show you ‘**`-1`** ‘ value if you have AC power attached. % **sysctl hw.acpi.battery** hw.acpi.battery.info_expire: 5 hw.acpi.battery.units: 2 hw.acpi.battery.state: 0 hw.acpi.battery.time: -1 hw.acpi.battery.life: 100 ## Battery Wear As time passes by batteries lose their ‘design’ capacity. After 1-2 years such battery can have only 70% or less of its original efficiency. All the information needed to check that is provided by the **`acpiconf(8)`** command with **`Design capacity:`** and **`Last full capacity:`** values. I have made a **`battery-capacity.sh`** script that will tell you what the current battery efficiency is. Here is how it looks in action. % **battery-capacity.sh 0** Battery '0' model '45N1037' has efficiency: 86% % **battery-capacity.sh 1** Battery '1' model '45N1041' has efficiency: 78% Here is the **`battery-capacity.sh`** script itself. #! /bin/sh if [ ${#} -ne 1 ] then echo "usage: ${0##*/} BATTERY" exit fi if acpiconf -i ${1} 1> /dev/null 2> /dev/null then DATA=$( acpiconf -i ${1} ) MAX=$( echo "${DATA}" | grep '^Design\ capacity:' | awk -F ':' '{print $2}' | tr -c -d '0-9' ) NOW=$( echo "${DATA}" | grep '^Last\ full\ capacity:' | awk -F ':' '{print $2}' | tr -c -d '0-9' ) MOD=$( echo "${DATA}" | grep '^Model\ number:' | awk -F ':' '{print $2}' | awk '{print $1}' ) echo -n "Battery '${1}' model '${MOD}' has efficiency: " printf '%1.0f%%\n' $( bc -l -e "scale = 2; ${NOW} / ${MAX} * 100" -e quit ) else echo "NOPE: Battery '${1}' does not exists on this system." echo "INFO: Most systems has only '0' or '1' batteries." exit 1 fi ## CPU To get information about current CPU’s you will have to use **`dev.cpu` MIB or `dev.cpu.0`** for the first physical CPU core. % **sysctl dev.cpu.0** dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 412905 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 290us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.freq_levels: 2501/35000 2500/35000 2200/29755 2000/26426 1800/23233 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 dev.cpu.0.freq: 800 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU If you load the **`coretemp(4)`** kernel module with **`kldload(8)`** command you will get additional temperature information. Below is same **`sysctl(8)` `dev.cpu.0`** MIB with **`coretemp(4)`** kernel module loaded. % **sysctl dev.cpu.0** dev.cpu.0.temperature: 49.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.coretemp.tjmax: 100.0C dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.delta: 51 dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 16549 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 1489us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.freq_levels: 2501/35000 2500/35000 2200/29755 2000/26426 1800/23233 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 dev.cpu.0.freq: 800 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU Let me describe some most useful ones. CPU core temperature. **`dev.cpu.0.temperature: 49.0C`** CPU supported C-states (C1 and C2 for this CPU). **`dev.cpu.0.cx_supported: C1/1/1 C2/3/104`** CPU statistics for C-states usage (only C1 state been used). **`dev.cpu.0.cx_usage_counters: 16549 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 1489us`** CPU maximum (most deep) C state enabled. **`dev.cpu.0.cx_lowest: C1`** CPU supported frequency levels with power usage after the ‘`/`‘ character. The **`2500/35000`** can be read as 2.5 GHz frequency with 35 W power usage and **`2501`** is the Turbo Mode. The lowest is 800 MHz with about 9 W usage. **`dev.cpu.0.freq_levels: 2501/35000 2500/35000 2200/29755 2000/26426 1800/23233 1600/20164 1400/17226 1200/14408 1000/11713 800/9140`** CPU current frequency (will vary when You use **`powerd(8)`** or **`powerdxx(8)`** daemon). **`dev.cpu.0.freq: 800`** The **`hw.acpi.thermal.tz0.temperature`** MIB will also show you current thermal zone temperature. % **sysctl hw.acpi.thermal.tz0.temperature** hw.acpi.thermal.tz0.temperature: 49.1C To check how many cores you have use these commands. % **grep FreeBSD/SMP /var/run/dmesg.boot** FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) % **sysctl kern.smp.cpus** kern.smp.cpus: 2 If my description does not feel useful then you should also check the **`-d`** flag for **`sysctl(8)`** command as shown below. % **sysctl -d dev.cpu.0.freq** dev.cpu.0.freq: Current CPU frequency ## `lscpu(1)` There is also third party tool called **`lscpu(8)`** that will describe your CPU features and model. You will have to add it from packages. # **pkg install lscpu** To make **`lscpu(8)`** work the **`cpuctl(4)`** kernel module is needed. Here is how it looks for my dual core CPU. # **kldload cpuctl** # **lscpu** Architecture: amd64 Byte Order: Little Endian Total CPU(s): 2 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 0 Vendor: GenuineIntel CPU family: 6 Model: 42 Model name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz Stepping: 7 L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3M Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 cflsh ds acpi mmx fxsr sse sse2 ss htt tm pbe sse3 pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline aes xsave osxsave avx syscall nx rdtscp lm lahf_lm ## `dmesg(8)` Also **`dmesg(8)`** command (or **`/var/run/dmesg.boot`** file after longer uptime) covers your CPU model and features information. % **grep CPU /var/run/dmesg.boot** CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.97-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: on acpi0 coretemp0: on cpu0 # CPU Frequency Scaling For CPU scaling feature you may use the **`powerd(8)`** daemon available in the FreeBSD base system or **`powerdxx(8)`** from the FreeBSD Ports or packages. The **`powerdxx(8)`** daemon aims to better scale multicore systems and not turning all cores to high state when there is moderate load on the system but some people may prefer that approach to have full power available when they do anything and to save power when they do nothing. Thus **`powerd(8)`** is not better then **`powerdxx(8)`** or vice versa. They are just different so that gives you more options for your needs. No matter which one you will choose it has to be configured in the **`/etc/rc.conf`** file. ## `powerd(8)` Here are the options for **`powerd(8)`** daemon. powerd_enable=YES powerd_flags="-n adaptive -a hiadaptive -b adaptive -m 800 -M 1600" The **`-n`** option of for the unknown state – if for some reason the **`powerd(8)`** will not be able to determine if you are running on the AC power or battery. The **`-a`** is for AC power and **`-b`** for running on the battery. The **`adaptive`** setting is less ‘aggressive’ so its more battery time friendly. The **`hiadaptive`** is more aggressive this its preferred when you are running on AC power. The **`-m`** option sets minimum CPU frequency to be used and **`-M`** the maximum. Both in MHz units. Check **`powerd(8)`** man page for more details. ## `powerdxx(8)` First you will need to install it. # **pkg install powerdxx** Then its options are identical as those of **`powerd(8)`** daemon. powerdxx_enable=YES powerdxx_flags="-n adaptive -a hiadaptive -b adaptive -m 800 -M 1600" Check the **`powerdxx(8)`** section above for the flags/parameters description. Decade ago CPU frequency scaling on FreeBSD was not that ‘easy’ as it is now, you may check my old HOWTO: FreeBSD CPU Scaling and Power Saving in that topic from 2008. ## C-States The C-states can be configured in the **`/etc/rc.conf`** file with these options. * **`performance_cx_lowest`** * **`economy_cx_lowest`** The **`economy_cx_lowest`** parameter is for running on battery and **`performance_cx_lowest`** parameter is for running on AC power. Both are set using the **`/etc/rc.d/power_profile`** script used by **`rc(8)`** subsystem. It sets the **`hw.acpi.cpu.cx_lowest`** parameter which sets/controls all **`dev.cpu.*.cx_lowest`** values. You can also track the changes in the **`/var/log/messages` **file when you attach/detach the AC power. % **tail -f /var/log/messages** Nov 28 13:14:42 t420s power_profile[48231]: changed to 'economy' Nov 28 13:14:46 t420s power_profile[56835]: changed to 'performance' Usually I jest use these values. performance_cx_lowest=C1 economy_cx_lowest=Cmax These settings above are generally sufficient for most systems. To check which C-states your CPU supports get the value of **`dev.cpu.0.cx_supported`** MIB. % **sysctl dev.cpu.0.cx_supported** dev.cpu.0.cx_supported: C1/1/1 C2/3/104 My CPU supports only C1 and C2 but yours may support more. I remember once when using some old Core 2 Duo laptop that the C2 state had quite ‘noticeable’ delay when getting back from C1 (running) state to C2 (sleep) state so following setting is needed. You do not use the **`performance_cx_lowest`** and **`economy_cx_lowest`** parameters. You set the first core to C1 and all other cores to C2. This way even on battery you have fully responsive system and all other cores may sleep and save energy. For example if You would have 4 cores and your maximum (deepest) supported C-state would be C3, then you would put these into the **`/etc/sysctl.conf`** file. % **grep cx_lowest /etc/sysctl.conf** dev.cpu.0.cx_lowest=C1 dev.cpu.1.cx_lowest=C3 dev.cpu.2.cx_lowest=C3 dev.cpu.3.cx_lowest=C3 ## CPU Turbo Mode There are two ways to enable Turbo mode. One way is to set **`powerd(8)`** or **`powerdxx(8)`** daemon with maximum frequency set above nominal CPU speed. For example if you have CPU described as dual-core 2.3 GHz then set the maximum speed with **`-M`** flag to **`4000`** for example (which would mean 4GHz). If you do not use CPU frequency scaling daemon then you will use **`dev.cpu.0.freq`** parameter with highest (first) value from the **`dev.cpu.0.freq_levels`** MIB. Supported CPU frequency levels on my system. % **sysctl dev.cpu.0.freq_levels** dev.cpu.0.freq_levels: 2501/35000 2500/35000 2200/29755 2000/26426 1800/23233 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 The highest value (left) is **`2501/35000`** so I need to set **`dev.cpu.0.freq`** parameter with this value to use Turbo Mode. You need to only use the ‘frequency’ value part because if you paste it with power requirements description it will fail. # **sysctl dev.cpu.0.freq=2501/35000** sysctl: invalid integer '2501/35000' This is how it should be used. # **sysctl dev.cpu.0.freq=2501** dev.cpu.0.freq: 800 -> 2501 # USB Devices To list attached USB devices use the **`usbconfig(8)`** tool. % **usbconfig** ugen1.1: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) You will see that **`pwr`** parameter (short for power) will show you current power setting which can be: * **`ON`** * **`OFF`** * **`SAVE`** To set new USB power option for the **`ugen1.1`** device also use the **`usbconfig(8)`** tool with the **`power_save`** parameter in the following way. # **usbconfig -u 1 -a 1 power_save** The USB power management does not have dedicated config file on FreeBSD so we will put them into universal **`/etc/rc.local`** file which is being run at the end of the start-up process managed by the **`rc(8)`** subsystem. Here is the added content with exception for the ‘**`Lenovo USB Receiver`** ‘ which is my wireless mouse. % **grep -A 10 POWER /etc/rc.local** # POWER SAVE USB DEVICES usbconfig \ | grep -v 'Lenovo USB Receiver' \  | grep -v 'Unifying Receiver Logitech' \ | awk '{print $1}' \ | sed 's|ugen||'g \ | tr -d : \ | awk -F '.' '{print $1 " " $2 }' \ | while read U A do usbconfig -u ${U} -a ${A} power_save 2> /dev/null done It’s good idea to NOT save power for mouse or tracked devices because you will probably find it annoying to have to wait about a second each time you would like to use it. I use a `for` loop to set power saving for all USB devices except wireless USB mouse (identified as ‘**`Lenovo USB Receiver`** ‘ device). # SATA/AHCI Power Management FreeBSD offers AHCI channels power management via **`acpich(4)`** driver. These power management settings can be set at boot using the **`hint.ahcich.*.pm_level`** parameter in the **`/boot/loader.conf`** file. I use configuration up to 8 channels while I only have three. % **grep ahcich /var/run/dmesg.boot** ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 That is because settings for non-existent devices are harmless and will not display any error messages but you will not have to use different settings for various systems which saves time. This is the **`hint.ahcich.*.pm_level`** description from the **`ahci(4)`** man page. **hint.ahcich.X.pm_level** controls SATA interface Power Management for the specified channel, allowing some power to be saved at the cost of additional command latency. Some controllers, such as ICH8, do not implement modes 2 and 3 with NCQ used. Because of artificial entering latency, performance degradation in modes 4 and 5 is much smaller then in modes 2 and 3. Possible power management options are: * **`0`** – interface Power Management is disabled (default) * **`1`** – device is allowed to initiate PM state change, host is passive * **`2`** – host initiates PARTIAL PM state transition every time port becomes idle * **`3`** – host initiates SLUMBER PM state transition every time port becomes idle * **`4`** – driver initiates PARTIAL PM state transition 1ms after port becomes idle * **`5`** – driver initiates SLUMBER PM state transition 125ms after port becomes idle Here are my setting from the **`/boot/loader.conf`** file. # AHCI POWER MANAGEMENT FOR EVERY USED CHANNEL (ahcich 0-7) hint.ahcich.0.pm_level=5 hint.ahcich.1.pm_level=5 hint.ahcich.2.pm_level=5 hint.ahcich.3.pm_level=5 hint.ahcich.4.pm_level=5 hint.ahcich.5.pm_level=5 hint.ahcich.6.pm_level=5 hint.ahcich.7.pm_level=5 # Devices without Driver FreeBSD has power saving option to not power devices that does not have attached driver. Its called **`hw.pci.do_power_nodriver`** and you can set it in the **`/boot/loader.conf`** file. Here is its description from then **`pci(4)`** man page. **hw.pci.do_power_nodriver** (Defaults to 0) Place devices into a low power state (D3) when a suitable device driver is not found. It can be set to one of the following values: * **`0`** – All devices are left fully powered (defaults). * **`1`** – Like ‘`2`‘ except that storage controllers are also not powered down. * **`2`** – Powers down most devices (display/memory/peripherals not powered down). * **`3`** – Powers down all PCI devices without a device driver. Here is my setting from the **`/boot/loader.conf`** file. # POWER OFF DEVICES WITHOUT ATTACHED DRIVER hw.pci.do_power_nodriver=3 The **`pciconf(8)`** utility will show you what devices are in your system and which driver is attached to it. If no driver is attached you will see **`none*@`** for such devices, as **`none0@`** below. You can also check man page for most drivers like **`em(4)`** man page for **`em0`** device or **`xhci(4)`** page for **`xhci0`** device. % **pciconf -l** hostb0@pci0:0:0:0: class=0x060000 card=0x21d217aa chip=0x01048086 rev=0x09 hdr=0x00 vgapci0@pci0:0:2:0: class=0x030000 card=0x21d217aa chip=0x01268086 rev=0x09 hdr=0x00 none0@pci0:0:22:0: class=0x078000 card=0x21d217aa chip=0x1c3a8086 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x020000 card=0x21ce17aa chip=0x15028086 rev=0x04 hdr=0x00 ehci0@pci0:0:26:0: class=0x0c0320 card=0x21d217aa chip=0x1c2d8086 rev=0x04 hdr=0x00 hdac0@pci0:0:27:0: class=0x040300 card=0x21d217aa chip=0x1c208086 rev=0x04 hdr=0x00 pcib1@pci0:0:28:0: class=0x060400 card=0x21d217aa chip=0x1c108086 rev=0xb4 hdr=0x01 pcib2@pci0:0:28:1: class=0x060400 card=0x21d217aa chip=0x1c128086 rev=0xb4 hdr=0x01 pcib3@pci0:0:28:3: class=0x060400 card=0x21d217aa chip=0x1c168086 rev=0xb4 hdr=0x01 pcib4@pci0:0:28:4: class=0x060400 card=0x21d217aa chip=0x1c188086 rev=0xb4 hdr=0x01 ehci1@pci0:0:29:0: class=0x0c0320 card=0x21d217aa chip=0x1c268086 rev=0x04 hdr=0x00 isab0@pci0:0:31:0: class=0x060100 card=0x21d217aa chip=0x1c4f8086 rev=0x04 hdr=0x00 ahci0@pci0:0:31:2: class=0x010601 card=0x21d217aa chip=0x1c038086 rev=0x04 hdr=0x00 ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x21d217aa chip=0x1c228086 rev=0x04 hdr=0x00 iwn0@pci0:3:0:0: class=0x028000 card=0x11118086 chip=0x42388086 rev=0x3e hdr=0x00 sdhci_pci0@pci0:5:0:0: class=0x088000 card=0x21d217aa chip=0xe8221180 rev=0x07 hdr=0x00 xhci0@pci0:13:0:0: class=0x0c0330 card=0x01941033 chip=0x01941033 rev=0x04 hdr=0x00 You can also use **`-v`** flag to get more detailed information. % **pciconf -l -v** (...) xhci0@pci0:13:0:0: class=0x0c0330 card=0x01941033 chip=0x01941033 rev=0x04 hdr=0x00 vendor = 'NEC Corporation' device = 'uPD720200 USB 3.0 Host Controller' class = serial bus subclass = USB ## Nvidia Optimus If for some reason your BIOS/UEFI firmware does not allow you to disable Nvidia discrete graphics card you may use this script to disable it so it will not drain power from your system. It requires the **`acpi_call(4)`** kernel module which is provided by the **`acpi_call`** package. # **mkdir /root/bin** # **cd /root/bin** # **fetch https://people.freebsd.org/~xmj/turn_off_gpu.sh** # **pkg install acpi_call** # **kldload acpi_call** # **chmod +x /root/bin/turn_off_gpu.sh** # **/root/bin/turn_off_gpu.sh** You may add it to the **`/etc/rc.local`** file after the USB power saving options with this entry. # DISABLE NVIDIA CARD /root/bin/turn_off_gpu.sh It will store the working ACPI call in the **`/root/.gpu_method`** file and execute it each next time. # Suspend and Resume The biggest enemies of suspend/resume mechanism are bugs in your BIOS/UEFI firmware for your hardware. Sometimes disabling Bluetooth helps – that is the option for ThinkPad T420s for example. To check which suspend modes are supported on your system check the **`hw.acpi.supported_sleep_state`** MIB from **`sysctl(8)`** subsystem. % **sysctl hw.acpi.supported_sleep_state** hw.acpi.supported_sleep_state: S3 S4 S5 To enter ACPI S3 sleep state (suspend) you can use **`acpiconf(8)`** tool or **`zzz(8)`** tool. # **zzz** … or with **`acpiconf(8)`** tool. # **acpiconf -s 3** Its exactly the same as stated in the **`zzz(8)`** man page. You can also set **`sysctl(8)`** value that everytime you close your laptop lid your system will go to sleep. To achieve that put **`hw.acpi.lid_switch_state=S3`** into the **`/etc/sysctl.conf`** file. No matter if you put you hardware to sleep by command or by closing the lid your laptop will resume after opening the lid. Of course if you haven’t closed the lid after the **`zzz(8)`** command you will either have to close and open the lid or push the power button to resume. Of course you may also suspend/resume desktops or even your backup server if it has its purpose. It’s not limited to laptops only. There are also dedicated kernel modules for various vendor ACPI subsystems. Here they are: * **`/boot/kernel/acpi_asus_wmi.ko`** * **`/boot/kernel/acpi_asus.ko`** * **`/boot/kernel/acpi_dock.ko`** * **`/boot/kernel/acpi_fujitsu.ko`** * **`/boot/kernel/acpi_hp.ko`** * **`/boot/kernel/acpi_ibm.ko`** * **`/boot/kernel/acpi_panasonic.ko`** * **`/boot/kernel/acpi_sony.ko`** * **`/boot/kernel/acpi_toshiba.ko`** * **`/boot/kernel/acpi_video.ko`** * **`/boot/kernel/acpi_wmi.ko`** For example if you have IBM/Lenovo ThinkPad the you will use the **`acpi_ibm.ko`** kernel module. # **kldload acpi_ibm** After loading each module you will get new **`sysctl(8)`** values for your use. For example related to fan speed, keyboard backlit or screen brightness. Below is new **`dev.acpi_ibm`** section in **`sysctl(8)`** after loading the **`acpi_ibm(4)`** kernel module. % **sysctl dev.acpi_ibm** dev.acpi_ibm.0.handlerevents: NONE dev.acpi_ibm.0.mic_led: 0 dev.acpi_ibm.0.fan: 0 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan_speed: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.volume: 0 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.hotkey: 1425 dev.acpi_ibm.0.eventmask: 134217727 dev.acpi_ibm.0.events: 1 dev.acpi_ibm.0.availmask: 134217727 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.%pnpinfo: _HID=LEN0068 _UID=0 dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.%parent: Here are descriptions of more interesting ones. This one will turn the LED light on the Microphone mute button. **`dev.acpi_ibm.0.mic_led`** Select if you want to manage CPU fan (**`0`**) or leave it to the manufacturer defaults (**`1`**). **`dev.acpi_ibm.0.fan`** If CPU fan is enabled, set its speed. **`dev.acpi_ibm.0.fan_level`** This one will tell you how fast the CPU fan is spinning (in RPMs). **`dev.acpi_ibm.0.fan_speed`** Enable/disable WiFi (if its enabled in BIOS). **`dev.acpi_ibm.0.wlan`** Enable/disable Bluetooth (if its enabled in BIOS). **`dev.acpi_ibm.0.bluetooth`** Enable/disable ThinkLight. **`dev.acpi_ibm.0.thinklight`** Mute/unmute speakers. **`dev.acpi_ibm.0.mute`** Speakers volume. **`dev.acpi_ibm.0.volume`** Screen brightness. **`dev.acpi_ibm.0.lcd_brightness`** For most of the cases its not needed to use them as you will probably just use the vendor defined keyboard shortcuts (probably with **`Fn`** key) or vendor specific dedicated buttons. Sometimes you want to create/use your own setup or need custom keyboard shortcuts, or you want to control the fan speed depending on the CPU temperature other way then your vendor predefined it. This is when these dedicated ACPI kernel modules are most useful. For example I recently thought that my CPU fan seems to be little louder then it should be so I created custom **`cron(8)`** based **`acpi-thinkpad-fan.sh`** script to use lower fan speeds or even lower quieter speeds when CPU temperature is low enough. I will post it here. Maybe you will find it useful for your purposes. To describe it shortly it disables the fan when CPU temperature is below 50 (C) degrees, it sets it to level ‘1’ if its between 50 (C) and 60 (C) degrees and sets it to level ‘3’ when temperature reaches more then 60 (C) degrees. #! /bin/sh if ! kldstat | grep -q acpi_ibm.ko then doas kldload acpi_ibm fi doas sysctl dev.acpi_ibm.0.fan=0 1> /dev/null TEMP=$( sysctl -n hw.acpi.thermal.tz0.temperature | awk -F'.' '{print $1}' ) if [ ${TEMP} -lt 50 ] then doas sysctl dev.acpi_ibm.0.fan_level=0 1> /dev/null exit 0 fi if [ ${TEMP} -lt 60 ] then doas sysctl dev.acpi_ibm.0.fan_level=1 1> /dev/null exit 0 fi if [ ${TEMP} -ge 60 ] then doas sysctl dev.acpi_ibm.0.fan_level=3 1> /dev/null exit 0 fi … and here is its **`crontab(5)`** entry: % **crontab -l** # ACPI/IBM/FAN * * * * * ~/scripts/acpi-thinkpad-fan.sh # Network Interfaces There is also **`ifconfig(8)`** option to save power if a driver supports such feature, its called **`powersave`** and its used like that. # **ifconfig wlan0 powersave** I use it in my **`network.sh`** network management script described broadly in the FreeBSD Network Management with `network.sh` article. # Vendor Tools There are also vendor tools available on FreeBSD like **`powermon(8)`** for example. Remember that it requires **`cpuctl(4)`** kernel module to work. # **pkg install powermon** # **kldload cpuctl** # **powermon** Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (Arch: Sandy Bridge, Limit: 44W) 5.11W [=======> ] Package: Uncore: x86 Cores: GPU: Current: 5.11W Current: 3.17W Current: 1.73W Current: 0.21W Total: 98.33J Total: 60.86J Total: 33.49J Total: 3.98J # DTrace The dynamic tracing framework that like ZFS found its way from Solaris/Illumos to FreeBSD may be also useful weapon in the battle for more time on your battery. First add the **`dtrace-toolkit`** package. # **pkg install dtrace-toolkit** Your system stops saving energy or wakes CPU up because something needs to be run/done. To check what is run on your system you mostly run **`ps(1)`** or **`top(1)`** utilities but that will not show you what exactly is being started or how often something is being run. This is where DTrace comes with help. We will use the **`/usr/share/dtrace/toolkit/execsnoop`** script from the **`dtrace-toolkit` **package. It will print EVERY COMMAND that is being run with all its arguments.It will remain silent when no commands are run, be advised. Here is example output for my **`dzen2`** toolbar update. # **/usr/local/share/dtrace-toolkit/execsnoop** UID PID PPID ARGS 1000 97748 97509 /usr/local/bin/zsh -c ~/scripts/dzen2-update.sh > ~/.dzen2-fifo 1000 97748 1 /bin/sh /home/vermaden/scripts/dzen2-update.sh 1000 99157 97748 sysctl -n kern.smp.cpus 1000 311 97748 ps ax -o %cpu,rss,command -c 1000 3118 1521 awk -v SMP=200 /\ idle$/ {printf("%.1f%%",SMP-$1)} 1000 4462 97748 date +%Y/%m/%d/%a/%H:%M 1000 4801 97748 sysctl -n dev.cpu.0.freq 1000 6009 97748 sysctl -n hw.acpi.thermal.tz0.temperature 1000 6728 97748 sysctl -n vm.stats.vm.v_inactive_count 1000 7043 97748 sysctl -n vm.stats.vm.v_free_count 1000 7482 97748 sysctl -n vm.stats.vm.v_cache_count 1000 10363 8568 bc -l 1000 10863 10363 dc -x 1000 13143 7773 grep --color -q ^\. 1000 13798 97748 /bin/sh /home/vermaden/scripts/__conky_if_ip.sh 1000 15089 14235 ifconfig -u 1000 16439 14235 grep -v 127.0.0.1 1000 17738 14235 grep -c inet 1000 19069 18612 ifconfig -l -u 1000 19927 18612 sed s/lo0//g 1000 20772 13798 ifconfig wlan0 1000 23388 21410 grep ssid 1000 24588 13798 grep -q " 1000 25965 25282 awk /ssid/ {print $2} 1000 27917 27217 awk /inet / {print $2} 1000 29941 97748 /bin/sh /home/vermaden/scripts/__conky_if_gw.sh 1000 32808 31412 route -n -4 -v get default 1000 34012 31412 awk END{print $2} 1000 34895 97748 /bin/sh /home/vermaden/scripts/__conky_if_dns.sh 1000 36118 34895 awk /^nameserver/ {print $2; exit} /etc/resolv.conf 1000 37628 97748 /bin/sh /home/vermaden/scripts/__conky_if_ping.sh dzen2 1000 38829 37628 ping -c 1 -s 0 -t 1 -q 9.9.9.9 1000 42079 41566 mixer -s vol 1000 42177 41566 awk -F : {printf("%s",$2)} 1000 44434 43254 zfs list -H -d 0 -o name,avail 1000 45866 43254 awk {printf("%s/%s ",$1,$2)} 1000 47004 97748 /bin/sh /home/vermaden/scripts/__conky_battery_separate.sh dzen2 1000 48282 47004 sysctl -n hw.acpi.battery.units 1000 49494 47004 sysctl -n hw.acpi.battery.life 1000 49948 47004 sysctl -n hw.acpi.acline 1000 52073 51441 acpiconf -i 0 1000 53055 51441 awk /^State:/ {print $2} 1000 53981 53186 acpiconf -i 0 1000 55354 53186 awk /^Remaining capacity:/ {print $3} 1000 55968 55631 acpiconf -i 1 1000 57187 55631 awk /^State:/ {print $2} 1000 58405 57471 acpiconf -i 1 1000 59201 57471 awk /^Remaining capacity:/ {print $3} 1000 60961 59252 bsdgrep -v -E (COMMAND|idle)$ 1000 63534 59252 head -3 1000 62194 59252 sort -r -n 1000 64629 59252 awk {printf("%s/%d%%/%.1fGB ",$3,$1,$2/1024/1024)} 1000 64634 93198 tail -1 /home/vermaden/.dzen2-fifo Lots of processes just to update the information on the top of the screen. That is why I refresh **`dzen2`** information only every 5 minutes and if I want exact information and system status for current moment I just ‘click’ on then **`dzen2`** bar to run all these commands and refresh itself. This way using DTrace you will know if something unwanted does not steal you precious battery time. You may find such **`dzen2`** config in my FreeBSD Desktop – Part 13 – Configuration – Dzen2 article. # Other ## ZFS By default ZFS will commit transaction group every 5 seconds and that is good default setting for the **`vfs.zfs.txg.timeout`** parameter. You may want to increase it a little if needed. To 10 for example. I say about that parameter mostly because lots of guides advice to set it to 1 for various performance reasons but keep in mind that setting it to 1 will prevent your disk (and CPU) from going to sleep thus draining more battery life. If you want to mess with **`vfs.zfs.txg.timeout`** value set it in the **`/boot/loader.conf`** file. ## Applications To get more time on battery used applications are also crucial. For example Thunar uses less CPU time then Caja or Nautilus. The Geany text editor uses less CPU resources and memory then Scite or Gedit editors, even GVim takes more resources. Not to mention that custom Openbox/Fluxbox/`**${YOUR_FAVORITE_WM}**` window manager based setup will consume a lot less CPU time then entire Gnome or Mate environment. # Hardware It’s sometimes possible to literally buy more battery time. For example when you want to buy new SSD for you laptop then pick not the fastest one but the most power efficient one. You will probably not feel the performance difference anyway but you will appreciate more battery time. Most RAM modules come with 1.5V current voltage but there is chance that your laptop may support low power DDR modules with 1.35V current thus increasing your battery time. Also keep in mind that each RAM stick uses about 0.5-1.0W of power so using single 8 GB RAM stick will provide you more battery time the the same 8 GB of memory using two 4 GB RAM modules. This also have performance drawback because with single RAM module you will not be able to use dual channel technology so you will limit you RAM speed. Some laptops have even 4 RAM slots (like ThinkPad W520 for example) so without losing anything you should use two 8 GB RAM sticks instead of four 4 GB RAM sticks for longer battery life. It is sometimes possible to swap your DVD drive to internal secondary battery. Examples of such laptops are Dell Latitude D630, ThinkPad T420s or ThinkPad T500/W500. Sometimes vendors offer entire slice battery that will stick to the bottom of your laptop like slice battery for ThinkPad X220 or T420/T520/W520 laptops or for the 1st generation of ThinkPad X1 laptop. Hope that this information will help you squeeze some battery time (or at least save some power) on FreeBSD 🙂 ## UPDATE 1 – Graphics Card Power Saving If You have the `**graphics/drm-kmod**` package installed you probably use the latest `**i915kms.ko**` kernel module. To set maximum power management for integrated Intel graphics cards put these into the `**/boot/loader.conf**` file. # INTEL DRM WITH graphics/drm-kmod PACKAGE (NEW) # SKIP UNNECESSARY MODE SETS AT BOOT TIME compat.linuxkpi.fastboot=1 # USE SEMAPHORES FOR INTER RING SYNC compat.linuxkpi.semaphores=1 # ENABLE POWER SAVING RENDER C-STATE 6 compat.linuxkpi.enable_rc6=7 # ENABLE POWER SAVING DISPLAY C-STATES compat.linuxkpi.enable_dc=2 # ENABLE FRAME BUFFER COMPRESSION FOR POWER SAVINGS compat.linuxkpi.enable_fbc=1 In the past these settings below were used but they are not present anymore. # INTEL DRM WITH graphics/drm-kmod PACKAGE (OLD) drm.i915.enable_rc6=7 drm.i915.semaphores=1 drm.i915.intel_iommu_enabled=1 ## UPDATE 2 – AMD CPU Temperatures While the `**coretemp(4)**` kernel module is used for Intel CPUs the `**amdtemp(4)**` kernel module will provide additional temperature information for AMD CPUs. ## UPDATE 3 – Suspend/Resume Tips The biggest enemies of suspend/resume subsystem are bugs in the BIOS/UEFI firmware. Sometimes disabling the _Bluetooth_ helps – that is the option for the _Lenovo ThinkPad T420s_ for example. On the _Lenovo ThinkPad X240_ it is disabling the _TPM_ (_Trusted Platform Module_). ## UPDATE 4 – Intel Speed Shift As I run FreeBSD on very decent but also pretty old 2011 _ThinkPad W520_ this option is a mystery for me – but for those who run more fresh systems may benefit from it. With the introduction of _Intel Skylake_ (6th Generation) CPUs the FreeBSD operating system is able to utilize the _Intel Speed Shift_ technology. You can read more about it in the `**hwpstate_intel(4)**` man page. To make use of it include the following line in the `**/boot/loader.conf**` file. machdep.hwpstate_pkg_ctrl=0 Then in the `**/etc/sysctl.conf**` file you would add a line for each CPU thread (not core) with your desired settings. dev.hwpstate_intel.N.epp=Y The `**N**` here stands for the thread number. On a dual core CPU with 4 threads you would have 4 such lines. On a octa core CPU with 8 threads you would have 8 lines. The `**Y**` value means: * **0** – maximum performance * **50** – balanced (default) * **100** – maximum power savings To get the most power savings you would use `**100**` value for all threads as shown below. dev.hwpstate_intel.0.epp=100 dev.hwpstate_intel.1.epp=100 dev.hwpstate_intel.2.epp=100 dev.hwpstate_intel.3.epp=100 dev.hwpstate_intel.4.epp=100 dev.hwpstate_intel.5.epp=100 dev.hwpstate_intel.6.epp=100 dev.hwpstate_intel.7.epp=100 You could of course use full performance for a single thread, keep one balanced thread and save power on the rest of the threads as shown below. dev.hwpstate_intel.0.epp=0 dev.hwpstate_intel.1.epp=50 dev.hwpstate_intel.2.epp=100 dev.hwpstate_intel.3.epp=100 dev.hwpstate_intel.4.epp=100 dev.hwpstate_intel.5.epp=100 dev.hwpstate_intel.6.epp=100 dev.hwpstate_intel.7.epp=100 … and when you will be running on AC instead on battery then you may prefer to use that unlimited power with all values of `**0**` for all threads. Settings below. dev.hwpstate_intel.0.epp=0 dev.hwpstate_intel.1.epp=0 dev.hwpstate_intel.2.epp=0 dev.hwpstate_intel.3.epp=0 dev.hwpstate_intel.4.epp=0 dev.hwpstate_intel.5.epp=0 dev.hwpstate_intel.6.epp=0 dev.hwpstate_intel.7.epp=0 Ideally you would use _performance_ settings when on AC power and run in _power save_ mode when running on battery. You can achieve that with this simple script below running in `**cron(8)**` daemon. #! /bin/sh case $( sysctl -n hw.acpi.acline ) in (0) # BATTERY doas sysctl dev.hwpstate_intel.0.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.1.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.2.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.3.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.4.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.5.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.6.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.7.epp=100 1> /dev/null 2> /dev/null ;; (1) # AC doas sysctl dev.hwpstate_intel.0.epp=0 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.1.epp=50 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.2.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.3.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.4.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.5.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.6.epp=100 1> /dev/null 2> /dev/null doas sysctl dev.hwpstate_intel.7.epp=100 1> /dev/null 2> /dev/null ;; esac … and now the `**crontab(5)**` entry. I am also assuming here that you have needed `**doas(1)**` permissions. Modify the script if you use `**sudo(8)**` instead. % **crontab -l** # INTEL/SPEED/SHIFT * * * * * ~/scripts/acpi-intel-speed-shift.sh Unfortunately as I do not own laptop with Intel Speed Shift CPU so I do not know if running the `**0**` and `**50**` for the first two threads works best. Maybe its better to switch all threads to `**100**` to save more power. I will let you know when I will get such laptop in the future 🙂 ## UPDATE 5 – Intel CPU Power Envelope Seems that we have to few ways to manage CPU speed and power management so Intel came up with another one … and its called Intel RAPL. Fortunatelly there is FreeBSD driver for it at https://github.com/spagu/intel_rapl Microslop GitHub repo. I do not own laptop that needs that bullshit – so if You are less lucky then me – follow instructions that are on that Microslop GitHub page. Take care, vermaden EOF ### Share this: * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Like Loading... ### _Related_

Attached: 1 image the graveyard

Open, edit and re-export databases entirely on your device — a spreadsheet grid, a hand-written SQL console, and a .sqlite writer the official engine's integrity check signs off on.

L'exécutif souhaite "recentrer" les certificats d'économies d'énergie sur l'électrification. Le dispositif Action des collectivités territoriales pour l'efficacité énergétique évoque une "décision incompréhensible".

Fluxheim est un serveur web modulaire hautes performances, reverse proxy et serveur de cache écrit en Rust.

Le remplacement des tâches humaines par l’intelligence artificielle se poursuit. Selon de nombreux experts, celle-ci pourrait à terme détruire la Terre à la place de l’homme.

Petit guide pratique pour lire le vieil anglais à voix haute : voyelles, consonnes, accent tonique, comparés aux sons du français, avec les premiers vers de Beowulf en exemple.

**Au cœur de la saison de taille, le constat survient fréquemment au détour d’un massif de rosiers : l’outil ne tranche plus, il écrase, coince dans le bois dur et effiloche le végétal. Face à cette résistance, la tentation immédiate pousse de nombreux jardiniers amateurs vers le rayon outillage pour investir dans du matériel neuf. Une dépense totalement inutile quand on sait qu’une lame émoussée retrouve son efficacité d’origine grâce à une intervention ciblée de quelques minutes.** Photo : Shutterstock Un sécateur qui déchire les tiges ne représente pas seulement un effort physique accru et une fatigue prématurée pour le poignet. Pour le végétal, la blessure s’avère critique : une coupe nette cicatrise rapidement, tandis qu’une écorce broyée constitue une porte d’entrée ouverte aux champignons, aux bactéries et à diverses maladies horticoles. Loin d’un simple grattage superficiel, la remise en état exige un protocole précis. L’efficacité du geste réside dans un détail technique fondamental : le travail exclusif sur une zone spécifique de la lame. ## **Le secret d’affûtage : tout se joue sur un seul côté** La structure des outils de coupe du jardin — qu’il s’agisse d’un modèle à coupe franche (_bypass_) ou d’un modèle à enclume — repose sur un principe mécanique strict. L’erreur la plus répandue consiste à frotter indistinctement toutes les surfaces métalliques. Pour préserver le mécanisme, il faut cibler uniquement le biseau de la lame coupante. La contre-lame (ou l’enclume en acier tendre/plastique) ne doit en aucun cas recevoir le moindre coup de lime ou de pierre. Un aiguisage intempestif de la contre-lame détruit l’alignement d’usine, crée du jeu entre les pièces et dégrade définitivement la précision du matériel. L’angle d’origine du biseau se situe généralement entre 20 et 30 degrés (souvent fixé autour de 25 degrés). L’astuce consiste à poser la lame platement contre la pierre à aiguiser humidifiée, puis à pivoter délicatement l’outil jusqu’à sentir le contact parfait de toute la surface chanfreinée. **Étape**| **Action recommandée**| **Erreur à éviter** ---|---|--- **Angle d’affûtage**| Respecter l’angle d’origine (20° à 30°)| Modifier l’inclinaison d’usine **Mouvement**| Du talon vers la pointe, vers l’extérieur| Mouvement de va-et-vient **Contre-lame**| Nettoyage et désinfection uniquement| Aiguisage ou ponçage **Outillage**| Pierre à eau (grain 400-1000) ou lime diamant| Meuleuse électrique (surchauffe) Le geste doit s’effectuer de la base vers la pointe, en poussant vers l’extérieur, sans jamais réaliser de mouvement de va-et-vient. Comptez entre 5 passes pour un entretien régulier et 20 passes pour une lame très émoussée. Les experts de l’outillage déconseillent formellement l’utilisation d’une meuleuse électrique : la chaleur dégagée par la friction rapide altère la trempe de l’acier et annule ses propriétés de résistance. ## **Préparation, ébavurage et protection : le protocole complet** Avant de procéder à l’affûtage, une préparation méticuleuse est indispensable. La sève séchée, les poussières et les résidus de rouille forment un film abrasif qui encrasse le grain de la pierre et fausse le geste. Un nettoyage complet au chiffon imbibé d’alcool élimine ces dépôts tout en désinfectant les lames, évitant ainsi la propagation de germes d’un arbre à l’autre. Une fois les 5 à 20 passes d’affûtage effectuées sur le biseau, une fine bavure métallique appelée « morfil » apparaît sur la face plate de la lame. Pour l’éliminer, il suffit de passer la pierre une ou deux fois à plat sur le dos de la lame, sans jamais créer de biseau secondaire. Pour finaliser l’entretien, appliquez quelques gouttes d’huile végétale ou d’huile pour machine sur le tranchant et l’axe de pivotement. Cette pellicule protectrice empêche l’oxydation due à l’humidité ambiante et garantit une grande fluidité d’ouverture. Appliquée au moins une fois par saison sur l’ensemble de vos outils (cisailles à haies, ébrancheurs, couteaux de jardin), cette méthode prolonge la durée de vie de vos équipements tout en assurant des coupes parfaitement saines. * Quelle est la hauteur de coupe idéale pour une pelouse parfaite toute l’année ? * Quelle est la température idéale à la maison ? Réponse pièce par pièce. * Plantes aromatiques : pour les couper sans les abimer suivez cette technique très précise * Géothermie * Hivernage : ignorer cette étape cruciale va détruire votre tondeuse avant le printemps Partager : * Partager sur Facebook * Share on X * Partager sur Linkedin * Partager sur Flipboard * Partager sur WhatsApp * Partager par mail

Soutenez Blast, média indépendant en accès libre grâce au soutien de ses abonnés : https://www.blast-info.fr/soutenir Que respire-t-on quand la police gaze la manifestation, est-ce réellement dang...

Bloque en quelques secondes les comptes d’extrême droite sur X, Instagram, TikTok, Facebook et YouTube. Liste collective, gratuite, un profil à la fois.

En quelques jours, il est devenu l'ennemi public numéro 1 en Italie. Pourtant, Lorenzo Baldini, journaliste de 31 ans, se considère plutôt comme un lanceur d'alerte.

A prisoner on Monday lost his challenge to an Australian state’s ban on inmates eating Vegemite after he argued in court that withholding the polarizing yeast-based spread breached his human right to “enjoy his culture as an Australian.”

Unofficial Free S.A.S. ISP Freebox API exporter for Prometheus - shackerd/freebox-exporter-rs

A fast, keyboard-driven terminal UI for todo.txt. Contribute to webstonehq/tuxedo development by creating an account on GitHub.

The Omarchy desktop on FreeBSD: installer ISO and build tooling - jordanhubbard/daemonarchy

Entre humour et virulence, l'ancien président américain a multiplié les attaques contre son successeur et appelé les électeurs à se mobiliser, à dix jours du scrutin.

Deux jours avant la manifestation du 24 octobre, le Premier ministre Sébastien Lecornu a demandé à Orange, SFR, Free et Bouygues Telecom de se tenir prêts à couper l’accès à TikTok, Instagram ,Snapchat et X. Blast révèle la lettre et le compte rendu de la…

Le four à micro-ondes est un appareil très pratique. Mais cet outil du quotidien suscite parfois des inquiétudes. Emilie Steinbach démêle le vrai du faux.

* * * **Le dispositif de répression totalement mis en échec, malgré des blindés, une violence immense et deux manifestantes mutilées** * * * #### signal-2026-10-25-11-32-58-480_002 #### signal-2026-10-25-11-32-58-480_007 #### signal-2026-10-25-11-32-58-480_008 #### signal-2026-10-25-11-32-58-480_011 #### signal-2026-10-25-11-32-58-480_003 #### signal-2026-10-25-11-32-58-480_004 #### signal-2026-10-25-11-32-58-480_005 #### signal-2026-10-25-11-32-58-480_009 #### signal-2026-10-25-11-32-58-480_010 #### signal-2026-10-25-11-32-58-480_006 #### signal-2026-10-25-11-32-58-480_012 15, 20, 30.000 personnes ? Peu importe le nombre que nous étions : notre victoire n’est pas dans les chiffres égrainés sur les plateaux télé, mais dans la vie que nous avons su insuffler à cette manifestation populaire et indomptable. Il était de toute façon impossible de compter les manifestant·es, puisqu’à aucun moment de cette folle journée la foule n’a pu se réunir au même endroit. Ce n’était pourtant pas partie gagnée : la propagande anxiogène s’est déversée toute la semaine sur les « chaînes d’info » pour salir le 17 octobre insurrectionnel, les corps sont encore parfois traumatisés de la violence d’une police déchaînée, la météo annonce de la pluie en continu et les appels au calme se comptent même à gauche, alors que LFI ou la CGT appellent à « manifester pacifiquement ». À Nantes, la CGT a été l’autrice non pas d’une, mais de deux trahisons : alors que l’Assemblée de lutte avait validé 4 points de rendez-vous, la centrale syndicale a d’abord passé un appel au Miroir d’eau, lieu de départ convenu des manifs chiantes, car propice à la répression. Puis, face à l’interdiction de manifester dans l’ensemble du centre-ville, la CGT a montré sa docilité en appelant à un « rassemblement » place de la République, à côté de la Maison des syndicats (plus pratique pour prendre le café) et de l’autre côté de la Loire, dans la zone autorisée. Tout était donc fait pour que nous perdions, mais le peuple nantais a accumulé les victoires ce 24 octobre. D’abord dès 13h, alors qu’une cinquantaine de syndicalistes de Solidaires avec chasubles et drapeaux se mettent en marche depuis Talensac (le siège du syndicat) pour rejoindre le Miroir d’eau. L’objectif : se rendre au rendez-vous, permettre aux gens de se réunir, et voir sur place si le rapport de force est favorable ou si on permet un départ collectif vers l’appel pourri de République. La présence syndicale rassure les personne qui se joignent au petit cortège, qui passe les barrages de police jusqu’au Miroir d’eau quasi-désert, cerné d’une petite armée de flics. On bouge à République le temps de grossir les rangs. Et peu à peu, c’est une véritable manifestation qui se balade dans la zone interdite, réunissant quasiment 2000 personnes au cri de « Siamo tutti antifascisti ». La jonction avec le cortège de République est impressionnante, et c’est une marée humaine qui prend la rue en direction de l’ouest de l’île de Nantes. Objectif : soit on sort de l’île pour rejoindre le centre, soit on envahi le centre commercial Beaulieu. La foule est encore calme et s’engage en direction du pont Bonduelle, où attendent un canon à eau et un escadron de gendarmes mobiles. Le lieu de rendez-vous imposé par l’intersyndicale oblige le cortège à traverser un pont pour rejoindre le centre, les forces de l’ordre s’y concentrent et attendent de charger avec gourmandise. Sans sommation, le jet glacial s’abat sur les manifestant·es, et les premières grenades de la journée sont lancées. Explosives, les grenades, probablement les nouvelles GL304. Les flics ont soif de vengeance après avoir été débordés le 17 octobre, les détonations résonnent dans tout le quartier. Une femme voit une grenade exploser à ses pieds : fracture ouverte du tibia. La blessée est rapidement prise en charge par des médics, qui la sortent des gaz au bord de la Loire. Un autre est pris en charge avec le doigt ouvert jusqu’à l’os. C’est alors que l’information est donnée au mégaphone : un camion de teufeur est courageusement parvenu jusqu’au miroir d’eau, agrégeant quelques milliers de personnes qui remontent actuellement la rue de Strasbourg. Le vers est dans le fruit, dans la zone interdite résonnent des caissons de basse. Le cortège repart alors en sens inverse, et peut traverser la Loire au pont Audibert : malgré le dispositif policier délirant, la masse est telle qu’il est impossible de la contenir. La manif déborde sur la chaussée de la Madeleine, se fait gazer, contourne l’hôpital, se fait de nouveau gazer. Et à chaque fois, des groupes de manifestant·es éparses parviennent à passer derrière les lignes de flics, se regroupent, forment des cortèges qui se baladent à travers la zone interdite jusque dans le quartier cossu de Graslin, pourchassés par des policiers complètement dépassés. Vers 15h la police a définitivement perdu la partie : un gigantesque cortège se forme sur le Cours des 50 Otages, débordant dans les petites rues. Place du Cirque les CRS bloquent avec un canon à eau, chaque charge est plus violente que la précédente, les détonations résonnent dans tout le centre-ville. Mais à chaque nouvelle attaque policière, de nouveaux cortèges partent dans les petites rues, envahissent Bouffay et chargent des flics déboussolés à coups de chaises et de parasols. La préfecture est attaquée, place Foch est aussi reprise et un groupe s’enfonce dans la rue Joffre après un gazage massif coûtant plus cher qu’un lit d’hôpital. Malgré le report des Tekno Parades prévues le même jour, trois chars de son improvisés accompagnent également la manifestation. À 17h, l’un d’eux est violemment attaqué par la BAC rue de Strasbourg. Les vitres du véhicule sont brisées et les conducteurs violemment interpellés. En réaction, à 17h30, l’un des trois camions pirates est enflammé à proximité d’Hôtel Dieu, encore rempli de matériel de son. Les teufeur·ses aux manettes ont choisi de brûler leur matériel plutôt que de le voir saisi, et on les comprend. Ce n’est finalement pas la police qui met fin à l’émeute, mais la joie de se retrouver dans les bistrots et de partager un moment de convivialité avec ses ami·es. En terrasse des inconnus partagent leurs histoires, se racontent les dingueries du jour et savourent cette victoire historique. Car ce soir du 24 octobre une certitude s’impose : ce n’est pas Macron et sa police qui décident d’autoriser les manifestations, c’est la rue elle-même qui juge le moment venu de se soulever pour déboulonner les tyrans. Cerise sur le gâteau, des groupes d’extrême droite tourneront jusque tard dans la soirée afin de s’attaquer à ce qui pourrait, de près ou de loin, ressembler à un gauchiste. Il paraîtrait que certains des nervis fascistes auraient fini en mauvais état. * * * Photos : Oli Mouazan, Tonio, Rartefact ## **SOUTENEZ CONTRE ATTAQUE** Depuis 2012, nous vous offrons une information de qualité, libre et gratuite. Pour continuer ce travail essentiel nous avons besoin de votre aide : chaque euro compte ! faire un don Les cryptos-fascistes de la Big Tech peuvent supprimer Contre Attaque des réseaux « sociaux » du jour au lendemain, d’un simple clic. Pour renforcer l’autonomie des médias révolutionnaires, il est urgent de se doter de moyens de diffusion indépendants. Tous les 15 jours, recevez nos dernières actualités et bien plus directement sur votre adresse mail en vous inscrivant à la newsletter de Contre Attaque ! S’abonner à la newsletter

Hostux Page, une page de nouvel onglet sans compte : fonds d’écran personnels et en ligne, liens, météo, notes et synchronisation chiffrée facultative.

Attached: 1 image The world's airline routes Saturday 24 October 2026 · 18,858 routes · 3,214 airports (by u/keequalshalfmvsqrd)

Sortir en IPv6 c'est bien, mais protégé c'est mieux. Saviez-vous que le firewall IPv6 de votre Freebox est désactivé par défaut ?

**Plusieurs jours après la panne mobile qui a touché des millions de clients Orange et Sosh, l’opérateur révèle les causes de cet incident majeur. Un bug logiciel sur un équipement Nokia a provoqué une défaillance en cascade, neutralisant également les systèmes de secours.** Non il ne s’agissait pas d’une migration ratée…Dans un entretien accordé au _Figaro_ , Jérôme Hénique, directeur général d’Orange France, revient sur la panne nationale du 21 octobre, qui a privé des millions d’abonnés de services mobiles pendant plusieurs heures. _« C’est un incident majeur, inédit et exceptionnel par sa complexité. Nous n’avions pas connu d’incident comparable depuis quatorze ans »,_ reconnaît-il. ## Un bug logiciel qui a également neutralisé les équipements de secours L”incident qui a débuté précisément à 11h37, a été provoqué par un bug logiciel sur un équipement Nokia de son nouveau cœur de réseau mobile. Le dysfonctionnement a affecté simultanément les équipements principaux et ceux de secours, tous utilisant le même logiciel._« Le bug avait pour effet de les faire tomber lorsqu’ils recevaient certains messages d’erreur. Chaque fois que nous essayions de les remettre en service, ils tombaient à nouveau. Le problème touchait donc aussi les équipements de secours »,_ explique Jérôme Hénique. Cette défaillance généralisée explique pourquoi les dispositifs de continuité de service n’ont pas fonctionné. Nokia a finalement identifié le problème vers 17 heures, permettant un rétablissement progressif entre 18h30 et 20h30. ## Orange écarte une migration ratée Contrairement aux premières hypothèses, notamment avancées par Numerama, Orange exclut qu’une migration ratée vers son nouveau cœur de réseau soit à l’origine de l’incident. L’opérateur écarte également une cyberattaque et une mise à jour défectueuse._« Cette migration se déroule depuis dix-huit mois, par lots d’environ 100 000 clients, sans difficulté particulière »,_ assure Jérôme Hénique. Les abonnés encore raccordés à l’ancien cœur de réseau ont été épargnés. Orange précise également que la 3G, les appels d’urgence et son réseau fibre sont restés opérationnels. L’opérateur poursuit désormais ses investigations avec Nokia pour comprendre l’origine exacte du bug et revoir ses mécanismes de secours. _« Ce qui est extrêmement rare, dans le cas présent, c’est que la redondance n’ait pas fonctionné et qu’on ait mis du temps à identifier le bug »_ , souligne le dirigeant. Cet article a été repris sur le site Univers FreeBox

Un pirate revendique une fuite de données chez La France insoumise : 1,2 million de lignes liées aux adresses, au porte-à-porte et aux campagnes.

Read the article. Skip the wall. Paste a link and read it free, no signup.