NovHak's questions

24.10 user here. Counting from current boot only (less than three hours ago), I already have more than 6k useless messages like this in the journal :

audit: type=1400 audit(1736012989.876:317033): apparmor="ALLOWED" operation="file_perm" class="file" profile="transmission-gtk" name=<redacted> pid=11838 comm="transmission-gt" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001

Considering I’m a very modest user of Transmission, I guess it must get very heavy on active Transmission users’ disk space, easily counting in the hundreds of thousands, if not millions.

I’ve set the transmission-gtk profile to default_allow, which seems to get rid of the problem, but makes it somehow enforced too, i.e. explicit deny rules will be applied, so I will probably set it back to complain, but with an “allow all” rule… or maybe trash the whole shebang, which looks like a very sexy option at the time being.

However, correcting a bad profile would be better. Does anyone know how I can explicitly allow those file_perm operations ?

Problem :

A few months ago, I got a new MSI gaming laptop (GP76 Leopard w/Intel Core i7-10870H and Nvidia RTX 3070).

However, since the very beginning, I've been experiencing a very annoying behaviour : the CPU goes crazy too often, hence the fans, and for no good reason.

Workaround :

I worked around this problem by simply disabling Intel Turbo Boost : echo 1 >/sys/devices/system/cpu/intel_pstate/no_turbo

Here are two log outputs of turbostat --Summary --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6, with Turbo Boost disabled/enabled on the same task that's not very demanding.

Turbo Boost disabled :

turbostat version 20.09.30 - Len Brown <[email protected]>
CPUID(0): GenuineIntel 0x16 CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:a5:2 (6:165:2)
CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
cpu2: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH TURBO)
CPUID(7): SGX
cpu2: MSR_IA32_FEATURE_CONTROL: 0x00020005 (Locked )
CPUID(0x15): eax_crystal: 2 ebx_tsc: 184 ecx_crystal_hz: 0
TSC: 2208 MHz (24000000 Hz * 184 / 2 / 1000000)
CPUID(0x16): base_mhz: 2200 max_mhz: 5000 bus_mhz: 100
cpu2: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination DISable-EPB DISable-OOB)
RAPL: 5825 sec. Joule Counter Range, at 45 Watts
cpu2: MSR_PLATFORM_INFO: 0x8083bf1011600
8 * 100.0 = 800.0 MHz max efficiency frequency
22 * 100.0 = 2200.0 MHz base frequency
cpu2: MSR_IA32_POWER_CTL: 0x003c005f (C1E auto-promotion: ENabled)
cpu2: MSR_TURBO_RATIO_LIMIT: 0x292b2c2d2e2f3132
41 * 100.0 = 4100.0 MHz max turbo 8 active cores
43 * 100.0 = 4300.0 MHz max turbo 7 active cores
44 * 100.0 = 4400.0 MHz max turbo 6 active cores
45 * 100.0 = 4500.0 MHz max turbo 5 active cores
46 * 100.0 = 4600.0 MHz max turbo 4 active cores
47 * 100.0 = 4700.0 MHz max turbo 3 active cores
49 * 100.0 = 4900.0 MHz max turbo 2 active cores
50 * 100.0 = 5000.0 MHz max turbo 1 active cores
cpu2: MSR_CONFIG_TDP_NOMINAL: 0x00000016 (base_ratio=22)
cpu2: MSR_CONFIG_TDP_LEVEL_1: 0x00120118 (PKG_MIN_PWR_LVL1=0 PKG_MAX_PWR_LVL1=0 LVL1_RATIO=18 PKG_TDP_LVL1=280)
cpu2: MSR_CONFIG_TDP_LEVEL_2: 0x00000000 ()
cpu2: MSR_CONFIG_TDP_CONTROL: 0x00000000 ( lock=0)
cpu2: MSR_TURBO_ACTIVATION_RATIO: 0x00000015 (MAX_NON_TURBO_RATIO=21 lock=0)
cpu2: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3, UNdemote-C1, demote-C3, demote-C1, locked, pkg-cstate-limit=8 (unlimited))
/dev/cpu_dma_latency: 2000000000 usec (default)
current_driver: intel_idle
current_governor: menu
current_governor_ro: menu
cpu2: POLL: CPUIDLE CORE POLL IDLE
cpu2: C1ACPI: ACPI FFH MWAIT 0x0
cpu2: C2ACPI: ACPI FFH MWAIT 0x33
cpu2: C3ACPI: ACPI FFH MWAIT 0x60
cpu2: cpufreq driver: intel_pstate
cpu2: cpufreq governor: powersave
cpufreq intel_pstate no_turbo: 1
cpu2: MSR_MISC_FEATURE_CONTROL: 0x00000000 (L2-Prefetch L2-Prefetch-pair L1-Prefetch L1-IP-Prefetch)
cpu0: MSR_PM_ENABLE: 0x00000001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x01081632 (high 50 guar 22 eff 8 low 1)
cpu0: MSR_HWP_REQUEST: 0x80001608 (min 8 max 22 des 0 epp 0x80 window 0x0 pkg 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x00000000 (Dis_Guaranteed_Perf_Change, Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min)
cpu0: EPB: 6 (balanced)
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061 Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x00000168 (45 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x43864000df8640 (UNlocked)
cpu0: PKG Limit #1: ENabled (200.000000 Watts, 56.000000 sec, clamp ENabled)
cpu0: PKG Limit #2: ENabled (200.000000 Watts, 0.002441* sec, clamp ENabled)
cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de00000000 (UNlocked)
cpu0: DRAM Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: Cores Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: GFX Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x05640000 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88380000 (44 C)
cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x00000003 (100 C, 100 C)
cpu2: MSR_PKGC3_IRTL: 0x0000884e (valid, 79872 ns)
cpu2: MSR_PKGC6_IRTL: 0x00008876 (valid, 120832 ns)
cpu2: MSR_PKGC7_IRTL: 0x00008894 (valid, 151552 ns)
cpu2: MSR_PKGC8_IRTL: 0x000088fa (valid, 256000 ns)
cpu2: MSR_PKGC9_IRTL: 0x0000894c (valid, 339968 ns)
cpu2: MSR_PKGC10_IRTL: 0x00008bf2 (valid, 1034240 ns)
Busy%   Bzy_MHz IRQ PkgTmp  PkgWatt CorWatt GFXWatt RAMWatt
3.50    2034    6940    44  6.56    1.70    0.00    0.76
3.55    1446    9321    45  4.96    1.08    0.00    0.90
4.60    1361    11377   45  5.07    1.29    0.00    1.02
6.91    2080    17822   50  7.85    3.26    0.00    0.85
6.84    2196    10866   50  9.36    3.72    0.00    0.85
7.01    2185    11353   50  8.50    3.79    0.00    0.84
7.27    2196    13078   50  8.80    3.96    0.00    0.84
7.36    2200    10385   49  10.00   4.12    0.00    0.84
7.27    2200    11124   49  7.43    4.17    0.00    0.84
7.24    2200    10872   49  7.37    4.11    0.00    0.84
7.27    2200    10866   50  7.34    4.08    0.00    0.84
7.25    2186    10891   50  7.21    3.95    0.00    0.84
7.29    2200    11188   50  7.27    4.01    0.00    0.84
7.24    2200    11702   49  7.30    4.03    0.00    0.84
7.28    2200    11692   50  7.35    4.08    0.00    0.84
7.26    2200    11515   50  7.31    4.05    0.00    0.84
7.26    2200    11103   50  7.32    4.05    0.00    0.84
7.35    2200    13125   50  7.38    4.12    0.00    0.84
7.62    2200    18003   50  7.56    4.29    0.00    0.85
7.15    2145    14333   47  7.13    3.85    0.00    0.86
1.64    1839    4533    45  6.88    0.68    0.00    0.76
1.45    1830    2615    46  7.60    0.58    0.00    0.74

WHEREAS BEFORE (Turbo Boost enabled) :

turbostat version 20.09.30 - Len Brown <[email protected]>
CPUID(0): GenuineIntel 0x16 CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:a5:2 (6:165:2)
CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
cpu10: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH TURBO)
CPUID(7): SGX
cpu10: MSR_IA32_FEATURE_CONTROL: 0x00020005 (Locked )
CPUID(0x15): eax_crystal: 2 ebx_tsc: 184 ecx_crystal_hz: 0
TSC: 2208 MHz (24000000 Hz * 184 / 2 / 1000000)
CPUID(0x16): base_mhz: 2200 max_mhz: 5000 bus_mhz: 100
cpu10: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination DISable-EPB DISable-OOB)
RAPL: 5825 sec. Joule Counter Range, at 45 Watts
cpu10: MSR_PLATFORM_INFO: 0x8083bf1011600
8 * 100.0 = 800.0 MHz max efficiency frequency
22 * 100.0 = 2200.0 MHz base frequency
cpu10: MSR_IA32_POWER_CTL: 0x003c005f (C1E auto-promotion: ENabled)
cpu10: MSR_TURBO_RATIO_LIMIT: 0x292b2c2d2e2f3132
41 * 100.0 = 4100.0 MHz max turbo 8 active cores
43 * 100.0 = 4300.0 MHz max turbo 7 active cores
44 * 100.0 = 4400.0 MHz max turbo 6 active cores
45 * 100.0 = 4500.0 MHz max turbo 5 active cores
46 * 100.0 = 4600.0 MHz max turbo 4 active cores
47 * 100.0 = 4700.0 MHz max turbo 3 active cores
49 * 100.0 = 4900.0 MHz max turbo 2 active cores
50 * 100.0 = 5000.0 MHz max turbo 1 active cores
cpu10: MSR_CONFIG_TDP_NOMINAL: 0x00000016 (base_ratio=22)
cpu10: MSR_CONFIG_TDP_LEVEL_1: 0x00120118 (PKG_MIN_PWR_LVL1=0 PKG_MAX_PWR_LVL1=0 LVL1_RATIO=18 PKG_TDP_LVL1=280)
cpu10: MSR_CONFIG_TDP_LEVEL_2: 0x00000000 ()
cpu10: MSR_CONFIG_TDP_CONTROL: 0x00000000 ( lock=0)
cpu10: MSR_TURBO_ACTIVATION_RATIO: 0x00000015 (MAX_NON_TURBO_RATIO=21 lock=0)
cpu10: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3, UNdemote-C1, demote-C3, demote-C1, locked, pkg-cstate-limit=8 (unlimited))
/dev/cpu_dma_latency: 2000000000 usec (default)
current_driver: intel_idle
current_governor: menu
current_governor_ro: menu
cpu10: POLL: CPUIDLE CORE POLL IDLE
cpu10: C1ACPI: ACPI FFH MWAIT 0x0
cpu10: C2ACPI: ACPI FFH MWAIT 0x33
cpu10: C3ACPI: ACPI FFH MWAIT 0x60
cpu10: cpufreq driver: intel_pstate
cpu10: cpufreq governor: powersave
cpufreq intel_pstate no_turbo: 0
cpu10: MSR_MISC_FEATURE_CONTROL: 0x00000000 (L2-Prefetch L2-Prefetch-pair L1-Prefetch L1-IP-Prefetch)
cpu0: MSR_PM_ENABLE: 0x00000001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x01081632 (high 50 guar 22 eff 8 low 1)
cpu0: MSR_HWP_REQUEST: 0x80003208 (min 8 max 50 des 0 epp 0x80 window 0x0 pkg 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x00000000 (Dis_Guaranteed_Perf_Change, Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min)
cpu0: EPB: 6 (balanced)
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061 Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x00000168 (45 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x43864000df8640 (UNlocked)
cpu0: PKG Limit #1: ENabled (200.000000 Watts, 56.000000 sec, clamp ENabled)
cpu0: PKG Limit #2: ENabled (200.000000 Watts, 0.002441* sec, clamp ENabled)
cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de00000000 (UNlocked)
cpu0: DRAM Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: Cores Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: GFX Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x05640000 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88370000 (45 C)
cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x00000003 (100 C, 100 C)
cpu10: MSR_PKGC3_IRTL: 0x0000884e (valid, 79872 ns)
cpu10: MSR_PKGC6_IRTL: 0x00008876 (valid, 120832 ns)
cpu10: MSR_PKGC7_IRTL: 0x00008894 (valid, 151552 ns)
cpu10: MSR_PKGC8_IRTL: 0x000088fa (valid, 256000 ns)
cpu10: MSR_PKGC9_IRTL: 0x0000894c (valid, 339968 ns)
cpu10: MSR_PKGC10_IRTL: 0x00008bf2 (valid, 1034240 ns)
Busy%   Bzy_MHz IRQ PkgTmp  PkgWatt CorWatt GFXWatt RAMWatt
1.88    3641    5797    43  10.07   4.34    0.00    0.75
2.61    1697    7673    42  6.49    1.79    0.00    0.88
4.35    2100    15882   68  8.27    4.20    0.00    0.97
5.19    2608    15240   42  11.41   7.50    0.00    0.90
5.45    3552    11849   66  17.01   11.81   0.00    0.88
6.21    4349    11560   77  21.86   17.17   0.00    0.84
7.14    4489    13990   79  26.32   21.18   0.00    0.89
6.48    4621    11100   79  25.58   20.96   0.00    0.84
6.49    4684    10883   81  26.02   21.41   0.00    0.84
6.47    4609    10874   81  25.73   20.99   0.00    0.84
6.45    4388    11430   78  24.04   19.43   0.00    0.85
6.47    4551    11377   76  25.07   20.44   0.00    0.84
6.50    4668    10891   80  25.98   21.25   0.00    0.84
6.43    4433    11053   80  24.43   19.80   0.00    0.85
6.47    4588    11079   79  25.59   20.86   0.00    0.84
6.52    4688    10827   82  26.35   21.61   0.00    0.84
6.52    4689    11453   82  26.27   21.64   0.00    0.84
6.72    4684    18989   76  27.30   22.66   0.00    0.84
6.53    4457    15215   82  26.02   21.28   0.00    0.85
2.97    3515    9289    46  12.27   6.32    0.00    0.82
0.32    942 1432    44  7.17    0.18    0.00    0.73
1.73    3185    2361    45  10.26   3.19    0.00    0.75

This worked well, my CPU is very calm, but while playing some games, I now encounter slowdowns/FPS drops even in situations where everything was fine on my old laptop from 2014. That of course, is unacceptable.

My research until now :

I had this very same problem on Windows too when it was installed anew, and installing Dragon Center (a Windows-only, MSI-specific utility) solved the problem. After digging some information, it seems it's related to something MSI calls MSI shift technology which I guess is closely related to Intel SpeedStep.

After digging even more, it seems it's managed via the laptop's embedded controller, by writing at EC memory address 0xD2 this way :

• Bit 7 should always be 1.
• Bit 6 should be 1 if MSI shift is enabled, 0 otherwise.
• Bits 5, 4, 3 are unused (set to zero).
• Bits 2, 1, 0 should be set depending on performance level required, according to the following :
  • 010 : Economy (low)
  • 001 : Green (medium)
  • 000 : Comfort (high)
  • 100 : Sport (Turbo)
  • 011 : User-defined

So I wrote a module doing exactly that, but it doesn't seem to change a thing. I'm obviously missing something, but I must be near. Here's a simple module that's supposed to set CPU performance to battery mode, but as I said it doesn't work (while I'm not an experienced kernel-mode coder by far, I don't think there are big mistakes here since I use similar code to successfully enable/disable display overdrive) :

#include <linux/kernel.h>
#include <linux/acpi.h>
#include <linux/module.h>

MODULE_AUTHOR("NovHak <[email protected]>");
MODULE_DESCRIPTION("MSI GP76 ACPI EC fiddler (battery)");
MODULE_LICENSE("GPL");

static int __init acpi_msiecbt_init(void)
{
  u8 byte_read;
  int err = 0;

  err = ec_read(0xd2, &byte_read);
  if (err)
    {
      pr_notice("Read error %d\n", err);
      return 0;
    }
  else
    pr_info("Value read : %x\n", byte_read);

  byte_read = 0xc2;

  err = ec_write(0xd2, byte_read);
  if (err)
    pr_notice("Write error %d\n", err);
  else
    pr_info("Value written : %x (battery mode enabled)\n", byte_read);
  
  return 0;
}

static void __exit acpi_msiecbt_exit(void)
{
  return;
}

module_init(acpi_msiecbt_init);
module_exit(acpi_msiecbt_exit);

Another option would be of course the general approach of trying the CPU MSR registers directly, but I suspect I may have a few surprises, since there may be reasons why MSI did this through the EC.

Further research :

The TCC offset workaround :

Reference documentation can be found here, the register is defined in volume 4 of the manuals : Model-specific registers

BEWARE, improper execution may crash your system or even damage your hardware

I've now another workaround (thanks Doug Smythies) that consists in lowering the temperature limit of the CPU, through modification of the MSR_TEMPERATURE_TARGET (address 0x1a2) register. Bits 23 to 16 contain the temperature target, in degrees Celsius, that's the lowest temperature at which the PROCHOT# signal will always be asserted. This limit can be lowered by an offset that can be written from bits 29 to 24. (Depending on your system, that value may be available for modification in your BIOS' settings, in case you don't fancy the raw MSR write)

How to do this : you have to use the rdmsr and wrmsr commands :

1. Make sure Secure Boot is disabled. Otherwise you won't be able to perform raw writes to the MSR register.
2. Be root, or prepare to use sudo in the usual way.
3. (optional) Execute rdmsr -d -f 23:16 0x1a2 to get your CPU package's temperature target.
4. (optional) Execute rdmsr -d -f 29:24 0x1a2 to get the current TCC activation offset.
5. Execute rdmsr 0x1a2 to get the full contents of the register, in hex. Let's assume it's 5640000. Bits 29 to 24 are 5 hex (5 decimal), bits 23 to 16 are 64 hex (100 decimal), hence the current temperature limit is 100-5=95°C. Suppose you want to reduce the temperature limit to 75°C, hence an offset of 25°C (19 hex). The new value of the register, in hex, should then be 19640000.
6. Execute wrmsr 0x1a2 0x19640000.
7. The target temperature is now 75°C.

While it worked well, the fans are more calm, and I don't experience slowdowns, this is only a workaround since my CPU then remains at 75°C during the whole gaming session, which is still far too hot considering the task.

I've noticed with my current Groovy, that if I rely solely on the graphical Update Manager, some packages aren't kept up to date. Currently, 18 packages are concerned : gnome-shell-common gnome-shell-extension-prefs gnome-shell libpulse-dev libpulse-mainloop-glib0 libpulse0 (amd64 & i386) libpulsedsp lshw pulseaudio-module-bluetooth pulseaudio-utils pulseaudio qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils.

Any apt or apt-get full-upgrade, dist-upgrade or upgrade command would upgrade the packages, but not the Update Manager, which keeps telling that my system is up to date. Even when I open a tty (text only) session, I get the message that no updates are available (which I suppose means the Update Manager comes into play here too).

Is this a bug, or intended behaviour ? But then if it's intended, what is the logic ?

EDIT : After performing an apt update, the update manager detected a few updates, among which was a security update that has likely been added in the meantime, but for some mysterious reason it then decided to upgrade the Pulse Audio-related packages as well.

Then I ran the following commands in order (output included) :

$ apt list --upgradable

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
gnome-shell-common/groovy-updates,groovy-updates 3.38.2-1ubuntu1~20.10.1 all [upgradable from: 3.38.1-1ubuntu1.1]
gnome-shell-extension-prefs/groovy-updates 3.38.2-1ubuntu1~20.10.1 amd64 [upgradable from: 3.38.1-1ubuntu1.1]
gnome-shell/groovy-updates 3.38.2-1ubuntu1~20.10.1 amd64 [upgradable from: 3.38.1-1ubuntu1.1]
lshw/groovy-updates 02.18.85-0.3ubuntu2.20.10.1 amd64 [upgradable from: 02.18.85-0.3ubuntu2]
qemu-block-extra/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-common/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-data/groovy-updates,groovy-updates 1:5.0-5ubuntu9.3 all [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-gui/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-x86/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-utils/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]

$ apt-cache policy gnome-shell
gnome-shell:
  Installed: 3.38.1-1ubuntu1.1
  Candidate: 3.38.2-1ubuntu1~20.10.1
  Version table:
     3.38.2-1ubuntu1~20.10.1 500
        500 http://fr.archive.ubuntu.com/ubuntu groovy-updates/main amd64 Packages
 *** 3.38.1-1ubuntu1.1 100
        100 /var/lib/dpkg/status
     3.38.1-1ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu groovy/main amd64 Packages

# apt update

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Hit:1 http://fr.archive.ubuntu.com/ubuntu groovy InRelease
Hit:2 http://security.ubuntu.com/ubuntu groovy-security InRelease
Hit:3 http://fr.archive.ubuntu.com/ubuntu groovy-updates InRelease
Hit:4 http://fr.archive.ubuntu.com/ubuntu groovy-backports InRelease
Reading package lists...
Building dependency tree...
Reading state information...
10 packages can be upgraded. Run 'apt list --upgradable' to see them.

Then I ran apt list --upgradable and apt-cache policy gnome-shell, again, and got the exact same output as before apt update (I compared the redirected outputs with cmp). update-manager still says my system is up to date.

Since I've upgraded to Groovy, my window manager repeatedly crashes. I've found a simple and reliable way to repeat the crash, so here it is :

1. Install the qemu-system-x86 package
2. Run the following command : qemu-system-x86_64 -nodefaults -display gtk -device VGA -full-screen

... and GNOME Shell crashes. You can see the screen blink, that's the crash. All windows that were previously minimised will be raised again. To quit Qemu full screen, type Ctrl+Alt+F.

Here's the part of the log that I think is relevant :

Dec 03 20:51:26 NovHak-P2 gnome-shell[13840]: JS ERROR: TypeError: actor.__animationInfo is undefined
                                              _sizeChangedWindow@resource:///org/gnome/shell/ui/windowManager.js:1385:9
Dec 03 20:51:26 NovHak-P2 gnome-shell[13840]: Error in freeze/thaw accounting
Dec 03 20:51:26 NovHak-P2 gnome-shell[13840]: GNOME Shell crashed with signal 5
Dec 03 20:51:26 NovHak-P2 gnome-shell[13840]: == Stack trace for context 0x55ba9a140220 ==
Dec 03 20:51:26 NovHak-P2 systemd[11078]: [email protected]: Main process exited, code=dumped, status=5/TRAP
Dec 03 20:51:26 NovHak-P2 systemd[11078]: [email protected]: Failed with result 'core-dump'.
Dec 03 20:51:26 NovHak-P2 systemd[11078]: [email protected]: Scheduled restart job, restart counter is at 4.
Dec 03 20:51:26 NovHak-P2 systemd[11078]: Stopped GNOME Shell on X11.
Dec 03 20:51:26 NovHak-P2 systemd[11078]: Starting GNOME Shell on X11...

The first two lines are probably the most informative. I suspect it affects almost all systems, can anyone confirm ?

Besides those crashes, I noticed another annoying thing, when I play a game full screen (namely DCSS, apt install crawl-tiles), when I come back to the desktop, the time showed in the upper bar isn't current, it's the time when I started playing. Moving the cursor on the time has it updated to current. I have the feeling it is related to the crashes somehow...

(While playing, the text in the DCSS log has strange artifacts, I suspect it's related too, but maybe that's a DCSS problem after all)

Any suggestions on how to avoid those crashes ?

EDIT : While it's an already reported bug, it would still be interesting if someone finds a workaround during the (long ?) time until the fix reaches us. Apart from leaving Gnome 3 that is (which I'm considering more and more btw, with those impractical design choices that are definitely not improving, but that's another mutter... eeeh matter).

This is very annoying, and is affecting the top and bottom panels. I had the problem with Eoan too, but I noticed it only appeared if I have a tty session opened as the same user when starting Flashback. Now that I've upgraded to Focal it can't get rid of it, even if Flashback is the first session opened as that user.

I tried explicitly setting the background and text color (Alt-Right click on the panel), but I didn't manage to get back to what is supposed to be the default anyway. I simply would like it to behave like it's configured to. Any advice ?

EDIT : To make things clearer, I use the default theme. I tried with the Intel and the Nvidia GPUs (I have an Optimus laptop), same problem. And here's a screenshot :

Notice the white border of Windows too. It wasn't like that before...

2ND EDIT : It turns out my "problem" is not really one, the theme has changed in 20.04. So the problem would rather be "How to set the theme of Gnome Flashback to the previous default one ?"

The title says it all. I don't want that applet because when I'm in an environment where wifi is of poor quality, it has the very annoying tendency to popup windows that interrupt other activities, such as playing games full screen. My network manager configuration is OK, thank you nm-applet, so shut up, please.

My current solution is to kill the nm-applet process. This isn't good practice however, and should not start in the first place. I could remove the package too, but it's not a good solution either since I still may want to use it sometimes, and uninstalling/reinstalling each and every time is really ugly, as well as fiddling with the package files such as clearing the execute bit or renaming, which makes for a package-inconsistent install.

I've tried copying /etc/xdg/autostart/nm-applet.desktop to ~/.config/autostart, and :

• Setting NotShowIn=KDE;GNOME;GNOME-Flashback; => no luck
• Setting X-GNOME-Autostart-enabled=false => no luck
• ln -s /dev/null ~/.config/autostart/nm-applet.desktop => no luck

Hence my guess is, it's not started from /etc/xdg/autostart.

I tried gsettings set org.gnome.nm-applet show-applet false, no luck either. I thought it was very much self-explanatory and would work, but no.

To be more precise, I use the session that's named GNOME Flashback (Metacity) in the GDM login screen.

Any advices ? Is it hardcoded or what ?

SOLVED :

Thanks to the answer below, I found the file is indeed in the autostart directory, but not the one I was looking. However, rather that modifying the file itself, I copied it in ~/.config/autostart and appended X-GNOME-Autostart-enabled=false. The answerer's method applies system-wide, and my method works for the current user only.

In 19.04, in X sessions, fullscreen displays such as Youtube videos were unredirected from Mutter compositing. That was obvious while using the intel modesetting driver, from the tearing.

However, now that I switched to 19.10, I notice no more tearing on fs Youtube videos. In an older window manager such as Metacity however, tearing is still atrocious so I know the change isn't coming from the driver.

So is it just me or did Mutter stop systematically unredirecting full screen program displays ? And then, did they go back to unconditional compositing or are special criteria used to avoid compositing games' displays ?

This one is tricky, since I can't just identify the package and file a bug concerning the package, because it's not a problem concerning its behaviour in a regular desktop environment.

Actually the problem is that the live system keeps /var/crash and /var/log mounted on the support. Not quite read-only any more huh ?

Because of this :

• The live image is modified (failing further checksum-based integrity checks one would want to make before booting)
• It's not possible to load to RAM and eject

Actually it's possible to load to RAM and eject (what's impossible with Linux after all ?), but that requires more steps :

# umount /var/crash
# fuser -m -k -TERM /var/log ; umount /var/log # repeat until it works (usually once is enough)

And then eject, the usual way, e.g. from the Nautilus interface.

But it's not supposed to be a place to report bugs here, hence my question : how shall I report ?

EDIT : I found out that persistence is enabled by default. One has to pass the nopersistent parameter at boot to prevent the live system from creating an additional r/w partition on the support. This is annoying...

As can be guessed from the subject, I have an Optimus laptop. As long as I was running 19.04, I was able to switch to the Nvidia dGPU and back, using Prime (via the prime-select {intel|nvidia} command). Things changed after the upgrade to 19.10 though : the day following the upgrade, the system froze with the kernel complaining about some tasks being stucked, such as an rmmod one. I managed to get back my system by running prime-select nvidia in a chroot root login environment.

I won't get too much into side details such as removing the iGPU/dGPU drivers from the initramfs (what do these have to do into the initramfs anyway ?), but now it boots at least, with or without the dGPU prime-activated.

And that's where I come to the problem : if my system boots with the intel profile activated, switching to the nvidia profile doesn't work, since the dGPU isn't detected in hardware. And indeed, it is absent from an lspci listing. I have to reboot for the dGPU to be detected again. Hence, when I shutdown my system, I should always think of activating the nvidia profile beforehand, or I will have to reboot to be able to use it the next time.

That's my main problem. Another, less annoying one, is that I always have to restart the gdm service when switching from nvidia to intel. I can live with that, but that's a problem I didn't have in 19.04.

Advices on this problem are welcome ! Either prevent the dGPU from disappearing from the hardware list, or a method to have it detected again by the system, without rebooting that is.

Fwiw, my iGPU is Intel HD Graphics 4600, and my dGPU is an Nvidia GTX 880M.

EDIT : @Syfer Polski, thanks for your informative reply !

I noticed there was an on-demand profile, but I discarded it as likely some useless attempt, as I had read not so long ago that a truly working Optimus implementation would not come anytime soon... I should have read that readme !

So I immediately tried that on-demand profile. At first it didn't work since I had the 430 driver that doesn't support it. There should have been some driver check refusing to enable the profile for people who are not running a supporting version, and I suspect that's why my system crashed, because that on-demand profile was automatically activated during the upgrade (only assuming, I didn't check at the time).

Anyway... so I installed the 435 driver and indeed the on-demand profile works. However, I don't find it satisfying enough, since my GPU isn't powered off when it's not used, and trying to power if off myself doesn't work. I tried powering it off via a direct ACPI call, and indeed it powered off but :

NVRM: GPU at PCI:0000:01:00: GPU-9b8a3387-4913-0c33-619e-da118e532a5f
NVRM: Xid (PCI:0000:01:00): 79, pid=29013, GPU has fallen off the bus.
NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.
NVRM: A GPU crash dump has been created. If possible, please run
NVRM: nvidia-bug-report.sh as root to collect this data before
NVRM: the NVIDIA kernel module is unloaded.

So, unfortunately for me, as long as the proprietary drivers are unable to power off my dGPU when it's not used, I guess I'll stick with the classic intel/nvidia profiles system.

Which brings me back to my original question, when I boot with the intel mode enabled : how can I get my dGPU back without rebooting ?

A rescan (echo 1 >/sys/bus/pci/rescan) shows it in the logs :

pci 0000:01:00.0: [10de:1198] type 00 class 0x030000
pci 0000:01:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff]
pci 0000:01:00.0: reg 0x14: [mem 0xe0000000-0xefffffff 64bit pref]
pci 0000:01:00.0: reg 0x1c: [mem 0xf0000000-0xf1ffffff 64bit pref]
pci 0000:01:00.0: reg 0x24: [io  0xe000-0xe07f]
pci 0000:01:00.0: reg 0x30: [mem 0xf7000000-0xf707ffff pref]
pci 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:01.0 (capable of 126.016 Gb/s with 8 GT/s x16 link)
pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none

But lspci remains silent. I can power the device on/off at will through ACPI calls, the kernel shows it upon rescan, but it's not detected by drivers that consequently won't load. There must be something to do, but what ?