If anyone is interested on nightly r4.3 ISO installer builds, you could find them at https://openqa.qubes-os.org/
Go to one of Qubes OS Build4.3 tests which has not failed miserably.
Go to install_iso_file test and click the yellow circle.
Go to scheduled product link.
Download the iso from ISO_URL link.
Do not try the iso in production environment. It might not even boot.
Do not report bugs you find on Github (unless you know what you are doing and you have a proper fix). Discussing bugs and changes on forum should be fine.
2 Likes
Amazing, thanks!
Would be interested in hearing GPU passthrough experiences for r4.3 for anyone testing
3 Likes
We have it already backported to Xen 4.17 in R4.2.
3 Likes
FYI dom0 in R4.3 got migrated to F41. The in-place upgrade (from F37-based R4.3 dom0) is definitely not straightforward right now, but possible after editing repo files and solving few conflicts manually.
3 Likes
barto
September 3, 2024, 3:08pm
25
Can you please point me to the relevant documentation regarding this driver? i.e. when to use, how to enable, how to check/debug?
1 Like
You can check this issue:
opened 10:23PM - 12 Dec 18 UTC
T: bug
C: Xen
P: major
r4.1-buster-stable
hardware support
r4.1-bullseye-stable
r4.1-dom0-stable
needs diagnosis
pr submitted
r4.1-centos-stream8-cur-test
r4.1-bookworm-stable
r4.2-host-cur-test
affects-4.1
affects-4.2
### Qubes OS version:
<!-- (e.g., `R3.2`)
You can get it from the dom0 teā¦ rminal with the command
`cat /etc/qubes-release`
Type below this line. -->
R4.0
### Affected component(s):
intel_pstate
acpi-cpufreq
xenpm
---
### Steps to reproduce the behavior:
<!-- Use single backticks (`) for in-line code snippets and
triple backticks (```) for code blocks.
Type below this line. -->
Tested on:
- Lenovo T480s
- Lenovo X1 Carbon Gen. 6
- Huawei Matebook X Pro.
All with Intel i7-8550U.
Latest BIOS revisions for the respective systems as of Dec. 2018
Kernel: 4.19.2-3.pvops.qubes.x86_64.
EFI install.
In dom0, `sudo xenpm get-cpufreq-para`
### Expected behavior:
The processor is rated at 1.8 GHz (4.0 turbo), so we would expect to see appropriate scaling in that range, available frequencies from 1800000 - 4000000.
Further, we would expect to see `scaling_driver = intel_pstate`.
### Actual behavior:
The CPU frequencies do not scale correctly. Why?
Frequencies are pinned at 2 GHz max, 400 MHz min, across all cores.
```
# xenpm cpu-freq-para
...
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [2001000] min [400000] cur [2001000]
scaling_driver : acpi-cpufreq
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
ondemand specific :
sampling_rate : max [10000000] min [10000] cur [20000]
up_threshold : 80
scaling_avail_freq : 2001000 2000000 1900000 1800000 1700000 1500000 1400000 1300000 1200000 1100000 1000000 800000 700000 600000 500000 *400000
scaling frequency : max [2001000] min [400000] cur [400000]
turbo mode : enabled
...
```
Confirmed with `watch -n1 "cat /proc/cpuinfo | grep \"[c]pu MHz\""`
`xenpm set-scaling-maxfreq` and `-minfreq` have no effect.
`xenpm get-cpufreq-states` shows 16 total/usable P-states.
Changing the governor to `performance` has no effect. Default is `ondemand`
`dmidecode` reports a max of 2 GHz on the Lenovos, and an apparently erroneous speed on the Huawei (~ 8 GHz).
```
# dmidecode | grep -i speed
Speed: 2400 MT/s
Configured Clock Speed: 2400 MT/s
Speed: 2400 MT/s
Configured Clock Speed: 2400 MT/s
Speed: Unknown
Speed: Unknown
Speed: Unknown
Max Speed: 2000 MHz
Current Speed: 1800 MHz
```
The `scaling_driver` is legacy `acpi-cpufreq`. Interestingly, `intel_pstate` can be seen initializing during boot, but it does not take over handling anything. Attempting to `blacklist acpi-cpufreq` in `modprobe.d` has no effect.
```
# dmesg | grep pstate
[ 5.067624] intel_pstate: Intel P-state driver initializing
```
`/sys/devices/system/cpu/intel_pstate/` contains the expected attributes, but as mentioned in the "related issue" linked below, `no_turbo`, `num_pstates`, and `turbo_pct` error `Resource temporarily unavailable`.
`/sys/devices/system/cpu/intel_pstate/status` always returns `off`, and does not respond to `echo "active" >`. This behavior has been tested with various kernel command line parameters, including `intel_pstate=force`, `intel_pstate=disabled`, `intel_pstate=no_hwp`, `intel_pstate=enable` with no change in performance aside from `../cpu/intel_pstate/` attributes disappearing when `no_hwp` or `disabled` were in effect. Also tried `processor.ignore_ppc=1`.
Strangely, none of the appropriate attributes for `cpufreq` exist in `/sys/devices/system/cpu/cpu*/`.
```
# ls /sys/devices/system/cpu/cpu0/
acpi_cppc driver hotplug power topology
cache firmware_node node0 subsystem uevent
```
`lsmod | grep cpufreq` shows no results, trying to `modprobe acpi-cpufreq` or `cpufreq-xen` returns errors. `xen_acpi_processor` is loaded.
```
# modprobe acpi-cpufreq
modprobe: ERROR: could not insert 'acpi_cpufreq': No such device
# modprobe cpufreq-xen
modprobe: FATAL: Module cpufreq-xen not found in directory /lib/modules/4.19.2-3.pvops.qubes.x86_64
```
`cpupower frequency-info` is completely unresponsive, with zero information available about the processor.
```
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
CPUs which run at the same hardware frequency: Not Available
CPUs which need to have their frequency coordinated by software: Not Available
maximum transition latency: Cannot determine or is not supported.
Not Available
available cpufreq governors: Not Available
Unable to determine current policy
current CPU frequency: Unable to call hardware
current CPU frequency: Unable to call to kernel
boost state support:
Supported: yes
Active: yes
```
Though it shouldn't have any effect, testing was attempted with `smt=on` and `off`, and `Hyperthreading` enabled/disabled in the BIOS appropriately.
Testing was also performed while toggling various BIOS settings.
- enable/disable `Intel SpeedStep`
- power settings at `Maximum Performance` vs. `Balanced`
It does not appear to be a thermal throttling issue, with idle ~ 37*C and under load ~60*C observed consistently.
`tlp` was tested with no effect on the frequency scaling, regardless of being enabled or disabled. `tlp-stat` yields minimal additional info, with what seems to be an outdated recommendation for the Lenovos to install `tp-smapi kernel modules`, that are in fact deprecated in favor of `thinkpad_acpi`, which appears to be active on the Thinkpads.
```
dmesg | grep thinkpad
[ 19.589434] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[ 19.589439] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 19.589440] thinkpad_acpi: ThinkPad BIOS N22ET50W (1.27 ), EC unknown
[ 19.589441] thinkpad_acpi: Lenovo ThinkPad T480s, model 20L7CTO1WW
[ 19.591883] thinkpad_acpi: radio switch found; radios are enabled
[ 19.591898] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[ 19.591899] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
[ 19.612278] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked
[ 19.643468] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[ 19.674512] thinkpad_acpi: battery 1 registered (start 0, stop 100)
[ 19.674576] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/
```
`thermald` is not loaded.
### General notes:
https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html
- This link suggests removing `irqbalance` but I'm skeptical.
https://askubuntu.com/questions/1067866/ubuntu-18-04-steam-games-frame-rate-drop/1073353#1073353?newreg=c7c120f373da4effb7317104571cd573
- https://cateee.net/lkddb/web-lkddb/XEN_ACPI_PROCESSOR.html
Regarding xen_acpi_processor: "It also registers itself as the SMM so that other drivers (such as ACPI cpufreq scaling driver) will not load."
How could `lsmod` report `xen_acpi_processor` as loaded but `xenpm` shows the scaling driver `acpi-cpufreq` ? This might make sense as to the missing `/sys/devices/.../cpufreq` entries.
- The following exchange is dubious at best, the final post gets down to the point of disabling intel microcode. They also suggest the use of `msr-tools`, but that really shouldn't be necessary.
https://bbs.archlinux.org/viewtopic.php?id=231077
- This is good work, but in my opinion, running a script every few seconds in dom0 isn't a legitimate fix.
https://github.com/erpalma/lenovo-throttling-fix
---
### Related issues:
https://github.com/QubesOS/qubes-issues/issues/4491
https://github.com/QubesOS/qubes-issues/issues/450
1 Like
It is enabled by default (if given hardware support it).
2 Likes
barto
September 3, 2024, 7:07pm
28
Thanks! I read through the github link that @apparatus posted, and the linked issues in there. It works fine for me. Kudos.
1 Like
fjdh
September 5, 2024, 1:56pm
29
So just for the sake of clarity: the 4.3 alpha is currently still using x11?
Yes. It is still x11.
Transition to Wayland is a relatively big multi-phase project. You could find more details about it if you watch DemiMarieās presentation on the 1st day of Qubes Summit 2023. Or reading the relevant issues on Github. Transition of domains (qubes) and GUI domain might not happen at the same time. It needs a lot of work.
5 Likes
fjdh
September 5, 2024, 7:39pm
31
okay. Yeah I saw that presentation but I also see that DemiMarieās qubes-wayland repo hasnāt been updated in a year. Have the plans or priorities changed since that 2023 presentation?
We have to take some facts into consideration:
Quoting from Xfce Wayland Development Roadmap :
It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).
So the transition of GUI domain to Wayland might not be easy if keeping Xfce as the default DE is desired (I might be wrong).
Looking at qubes-gui-daemon
I have seen EWMH usage in some parts (If I am not mistaken).
Disclaimer: I am not a Qubes OS core developer. I might be totally wrong.
2 Likes
fjdh
September 6, 2024, 6:27am
33
Yeah thatās why I was hoping for some clarity on what the state of play, current goals and potential roadblocks / blocking issues are, as the github issues donāt really say much about this (or eg how the work talex5 is doing relates to this).
Just upgraded dom0 to F41. Beside some minor issues with F41 GPG signing keys, switching to modular libvirt daemon was the only thing I had to do manually. No major issues so far. There are some minor issues such as Global Config is unable to show the Xen version (perhaps I could work on it) . And the DNF5 patch to allow search or other actions.
Sneak peek for people interested:
fepitre
September 9, 2024, 10:11am
36
3 Likes
fjdh
September 12, 2024, 4:17pm
37
I installed this and tried to import backups from (Qubes R4.2 from) april 2024, had an issue that I could only import 1 VM per cycle as it would otherwise simply not import the data.
It would be very good if you could try the CLI version (qvm-backup-restore --verbose) and share the logs for troubleshooting.
1 Like
There is another minor bug with qubes-dom0-update. DNF5 in Fedora 41 based UpdateVM does a lot of ANSI colourization of the output if it detects a TTY (which is the case). This is not filtered properly at the moment. I could think of 3 fixes:
Disable script command usage to emulate a TTY. This will also disable status bars and progress output.
Fix qvm-run to filter ANSI colourization codes properly.
Find the proper workaround to disable colourization in DNF5. (So far, I have not managed to find it).
1 Like
barto
September 13, 2024, 9:15am
40
A quick search renders an easy way to disable DNF5 color output: āācolor=neverā.
Note that this can be set in the [base] section of /etc/dnf.conf as ācolor = neverā but then all invocations of dnf commands will be colorlessā¦
1 Like
