• 0 Posts
  • 9 Comments
Joined 3 years ago
Cake day: June 10th, 2023
  • vole@lemmy.worldtoLinux@lemmy.ml•Why is the TPM so slow on boot?English
    11·
    1 month ago

    The first thing is to do is to understand what you’re looking at. Read this:

    systemd-analyze blame¶

    This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame does not display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the time units spent in “activating” state, which is not defined for units such as device units that transition directly from “inactive” to “active”. This command hence gives an impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.

    For example: I have passphrase disk encryption (no TPM encryption), and the time I take to enter the passphrase is added to many entries in systemd-analyze blame. Here is the output of systemd-analyze blame if I wait 2 minutes to enter my disk encryption passphrase:

    2min 12.640s sys-module-fuse.device
2min 12.618s sys-devices-platform-MSFT0101:00-tpm-tpm0.device
2min 12.618s dev-tpm0.device
2min 12.551s dev-ttyS0.device
2min 12.551s sys-devices-pnp0-00:00-00:00:0-00:00:0.0-tty-ttyS0.device
2min 12.550s dev-ttyS2.device
...

    So, I guess my advice is that systemd-analyze blame is not always going to be a clear indicator that a particular service is holding your boot times back. The .device entries in particular probably just represent how long after boot that the device became active. And unfortunately the systemd-analyze tools do not always lead you to the underlying delay.

    $ systemd-analyze critical-chain dev-tpm0.device
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dev-tpm0.device +2min 12.618s

$ systemd-analyze critical-chain dracut-initqueue.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dracut-initqueue.service +2min 11.123s
└─systemd-udev-trigger.service @770ms +158ms
  └─systemd-udevd-varlink.socket @760ms +65us
    └─system.slice
      └─-.slice

    If you are trying to deal with an issue that is causing significant delays in your boot time, journalctl --boot can sometimes be helpful. For the example boot above where I waited 2 minutes before entering the disk encryption passphrase:

    Jul 31 14:09:39 mycomputer kernel: Linux version 7.1.5-201.fc44.x86_64 (mockbuild@9b86e96a386140128351588d751166fd) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld versi>
... (a lot of log lines within a few seconds, but then I find a big jump) ...
Jul 31 14:09:44 mycomputer kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
Jul 31 14:11:48 mycomputer systemd-cryptsetup[551]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/...
... (and then there are a lot of log lines in the following seconds after the above line) ...
  • vole@lemmy.worldtoLinux@lemmy.ml•Fedora - changes in pp_table don't persist after restartEnglish
    9·
    1 year ago

    I’m not familiar with Radeon PowerPlay, so I don’t know if there is a proper way to solve this, but you should be able to make a systemd system service to run the upp command on boot.

    To do so, I think you can use the following:

    [Unit]
Description=Run my_user_script
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


[Service]
Type=oneshot
ExecStart=upp -p /sys/class/drm/card1/device/pp_table set --write smc_pptable/SocketPowerLimitAc/0=312 smc_pptable/SocketPowerLimitDc/0=293 smc_pptable/TdcLimit/0=300 smc_pptable/FreqTableSocclk/1=1350 smc_pptable/FreqTableFclk/1=2000 smc_pptable/FclkBoostFreq=2000

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

    To configure this service:

    • Save the text (using sudo/root) to a new .service file in /etc/systemd/service. (e.g. /etc/systemd/system/my_update_pp.service)
    • run sudo systemctl daemon-reload to tell systemd to re-read the service files
    • run sudo systemctl restart my_update_pp.service to manually run the service
    • run sudo systemctl enable my_update_pp.service to tell systemd to run your service automatically on boot/wake (WantedBy tells systemd when it should include the unit/service, After, Wants, Requires, and Before help systemd decide the order to run all the units/services)

    Notes

    • Usually for simple systemd services, you can omit After and set WantedBy to just WantedBy=multi-user.target, but if you also need to run upp after sleep or hibernate, then you probably need something more complex. I copied the After and WantedBy from a stackexchange answer, but I haven’t tried using those targets before. You might have to add multi-user.target to the WantedBy list.
    • I don’t actually know if you need to run upp after sleep/hibernate. Running on boot might be sufficient.
    • I think you can skip the chmod if you run upp as sudo/root. Systemd system services run as root by default.
    • I don’t know how safe it is to mess with PowerPlay during boot. My gut says it’s probably fine, but it also seems like something that could cause graphics to not work. Tread carefully.

    References:

  • vole@lemmy.worldtoLinux@lemmy.ml•Fedora - changes in pp_table don't persist after restartEnglish
    3·
    1 year ago

    Use triple backticks for blocks of code-type stuff

    ```

    like so

    ```

    example, wrapped in a spoiler tag. 
    upp -p /sys/class/drm/card1/device/pp_table dump
header:
  structuresize: 2470
  format_revision: 15
  content_revision: 0
table_revision: 2
table_size: 802
golden_pp_id: 2466
golden_revision: 16307
format_id: 128
platform_caps: 24
thermal_controller_type: 28
small_power_limit1: 0
small_power_limit2: 0
boost_power_limit: 0
software_shutdown_temp: 118
reserve:
  reserve 0: 0
  reserve 1: 0
  reserve 2: 0
  reserve 3: 0
  reserve 4: 0
  reserve 5: 0
  reserve 6: 1
  reserve 7: 0
power_saving_clock:
  revision: 1
  reserve:
... and so on ...
  • vole@lemmy.worldtoLinux@lemmy.ml•Would downscaling a display allow for better battery life?English
    101·
    2 years ago

    I’d think so. 3k is so many pixels to compute and send 60 times a second.

    But this video says the effect on battery life in their test was like 6%, going from 4k to 800x600. I can imagine that some screens are better at saving power when running at lower resolutions… but what screen manufacturer would optimize energy consumption for anything but maximum resolution? 🤔 I guess the computation of the pixels isn’t much compared to the expense of having those physical dots. But maybe if your web browser was ray-traced? … ?!

    Also, if you take a 2880x1800 screen and divide by 2 (to avoid fractional scaling), you get 1440x900 (this is not 1440p), which is a little closer to 720p than 1080p.

  • vole@lemmy.worldtoLinux@lemmy.ml•[Question] Setting up a bridged network for HomeAssistant in KVM FedoraEnglish
    2·
    2 years ago

    I haven’t made a bridge to a VM before today, or made a bridge with Network Manager. That being said, I was able to persuade Network Manger to get a bridge working, and there are a few things I can note:

    • When you setup the bridge, the host network interface should become a slave to the bridge. This means that the physical network interface should not have an IP Address, and your bridge should now be where you configure the host’s IP address.

      • After you start the VM, you should be able to run ip link | grep 'master br0' on the host, and it should display 2 interfaces which are slaves to br0. One for the physical ethernet interface, one for the VM (vnet). And it should only list your ethernet interface when the VM is off.

    • The RedHat tutorial does not show the bridge and the host having different IP addresses, the RedHat tutorial shows the bridge and the guest having different IP addresses. Actually, no, the RedHat tutorial shows the libvirt NAT bridge, not even the bridge that the tutorial describes creating… If you set the IP address of virbr0, I don’t know what happens.

    • If your VM’s network adapter is connected to the host’s bridge, then you should be able to log into your VM and set a static IP address.

    I had a lot of problems getting Network Manager to actually use my ethernet interface as a slave for the bridge. Here’s what worked for me, though:

    nmcli con show
nmcli con down 'Wired Connection 1'
nmcli con modify 'Wired Connection 1' connection.autoconnect no
nmcli con add type bridge con-name br0 ifname br0
nmcli connection add type bridge-slave ifname enp7s0 master br0
nmcli con modify br0 connection.autoconnect yes
nmcli con modify bridge-slave-enp7s0 connection.autoconnect yes
nmcli con modify br0 ipv4.method manual ipv4.addresses 172.16.0.231/24 bridge.stp no
sudo systemctl restart NetworkManager.service
nmcli con show
ip addr
    • Instead of enp7s0, you’d use enp1s0 I guess.
    • Above, I manually set my bridge IP address to a static address because my ethernet interface is wired directly to another computer, so no DHCP for me. If you have DHCP on your ethernet network, you probably don’t need to set “ipv4.method” or “ipv4.addresses”.
    • I set “bridge.stp” to “no” because my network doesn’t have any redundant paths, and the stp process seems to take like 25 seconds before I can use the bridge network.

    After that, I can go into “Virtual Machine Manger”, set my VM’s NIC’s Network Source to “Bridge device…”, Device name to"br0", boot my VM, login to my VM, configure my VM’s ip address. And then I can connect to the VM’s IP address from the physical ethernet network.