Bug#1058890: more info

2024-01-04 Thread Dr . André Desgualdo Pereira
The bug first appeared in linux-image-6.1.0-14-amd64 and persists through 
linux-image-6.1.0-15-amd64, linux-image-6.1.0-16-amd64 and 
linux-image-6.1.0-17-amd64.

-- 
André Desgualdo Pereira



Bug#1058890: More tests

2024-01-04 Thread Dr . André Desgualdo Pereira
Changing /etc/systemd/sleep.conf to have "SuspendState=standby" or 
"SuspendState=freeze" seems to make things worse because the notebook seems 
unable to enter sleep mode, while "SuspendState=mem" causes the same behavior 
as reported here, i. e., the notebook seems unable to wake up from sleeping. 

-- 
André Desgualdo Pereira



Processed: reassign 1059969

2024-01-04 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 1059969 cpufrequtils 008-2
Bug #1059969 [src:linux] linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y 
breaks cpu frequency scaling governor kernel module
Bug reassigned from package 'src:linux' to 'cpufrequtils'.
No longer marked as found in versions linux/6.6.9-1.
Ignoring request to alter fixed versions of bug #1059969 to the same values 
previously set
Bug #1059969 [cpufrequtils] linux-image-6.6.9-amd64: 
CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module
Marked as found in versions cpufrequtils/008-2.
> retitle 1059969 cpufrequtils: compressed kernel modules are not supported
Bug #1059969 [cpufrequtils] linux-image-6.6.9-amd64: 
CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module
Changed Bug title to 'cpufrequtils: compressed kernel modules are not 
supported' from 'linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks 
cpu frequency scaling governor kernel module'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1059969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059969
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module

2024-01-04 Thread Jy Deng
On Thu, 04 Jan 2024 15:04:53 +0100 Diederik de Haas 
 wrote:

> On Thursday, 4 January 2024 14:34:10 CET Jy Deng wrote:
> > 3. I find that if CONFIG_CPU_FREQ_GOV_POWERSAVE=m, then though such
> > module cannot be in use after boot at once, but it is possible to
> > manually modprobe them. So it may indicate that to use
> > CONFIG_CPU_FREQ_GOV_POWERSAVE=m with CONFIG_MODULE_COMPRESS_XZ=y is
> > actually possible. The problem we find here may be not so fundamental.
>
> That's actually how it always worked.
> $ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
>
> likely only lists 'performance' and 'schedutil'.
> /lib/modules/$(uname -r)/kernel/drivers/cpufreq/ lists several more 
governors
> and when you modprobe them, they get added to 
'scaling_available_governors'.

> And also to `cpupower frequency-info` -> 'available cpufreq governors'.
>

> So if you can verify whether it works with 'modprobe' then this is 
not a bug.


Fine. I have found the problem. It is a bug, but maybe I should say it 
not a bug of kernel but a bug of cooperation.


The backgroud is : Debian (unlike some other distros) uses 'loadcpufreq' 
to load scaling governors. However, 'loadcpufreq' is an out-of-date .sh 
script that does not support compressed kmod (which end with like .ko.xz 
or .ko.zst rather than .ko, which is not considered in the script).


So when kernel team decided to change the config to compress the kmod 
with xz, the maintainer of package 'cpufrequtils' (which includes 
'loadcpufreq' script) did not get such information so he/she did not 
make any update so that now the governors are not available out of box.


I will report bug to 'cpufrequtils' tomorrow.

Thanks.



Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module

2024-01-04 Thread Jy Deng



在 2024/1/4 22:26, Jy Deng 写道:
On Thu, 04 Jan 2024 15:04:53 +0100 Diederik de Haas 
 wrote:

> On Thursday, 4 January 2024 14:34:10 CET Jy Deng wrote:
> > 3. I find that if CONFIG_CPU_FREQ_GOV_POWERSAVE=m, then though such
> > module cannot be in use after boot at once, but it is possible to
> > manually modprobe them. So it may indicate that to use
> > CONFIG_CPU_FREQ_GOV_POWERSAVE=m with CONFIG_MODULE_COMPRESS_XZ=y is
> > actually possible. The problem we find here may be not so fundamental.
>
> That's actually how it always worked.
> $ cat 
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors

>
> likely only lists 'performance' and 'schedutil'.
> /lib/modules/$(uname -r)/kernel/drivers/cpufreq/ lists several more 
governors
> and when you modprobe them, they get added to 
'scaling_available_governors'.

> And also to `cpupower frequency-info` -> 'available cpufreq governors'.

>So if you can verify whether it works with 'modprobe' then this is 
not a bug.



The problem is that those modules of governors, when without kernel 
module compression, they will be automatically loaded. However, when 
module compression like CONFIG_MODULE_COMPRESS_XZ is set as 'y', then 
I have to manually load them by 'modprobe'. While it is OK to say this 
is not a bug, it is also important to find out what makes such difference.






Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module

2024-01-04 Thread Diederik de Haas
On Thursday, 4 January 2024 14:34:10 CET Jy Deng wrote:
> 3. I find that if CONFIG_CPU_FREQ_GOV_POWERSAVE=m, then though such
> module cannot be in use after boot at once, but it is possible to
> manually modprobe them. So it may indicate that to use
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m with   CONFIG_MODULE_COMPRESS_XZ=y is
> actually possible. The problem we find here may be not so fundamental.

That's actually how it always worked.
$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors

likely only lists 'performance' and 'schedutil'.
/lib/modules/$(uname -r)/kernel/drivers/cpufreq/ lists several more governors 
and when you modprobe them, they get added to 'scaling_available_governors'.
And also to `cpupower frequency-info` -> 'available cpufreq governors'.

So if you can verify whether it works with 'modprobe' then this is not a bug.

signature.asc
Description: This is a digitally signed message part.


Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module

2024-01-04 Thread Jy Deng

On Thu, 04 Jan 2024 12:37:51 +0100 Luca Boccassi  wrote:
> On Thu, 04 Jan 2024 17:16:57 +0800 Jy Deng <1700011...@pku.edu.cn>
> wrote:
> > Package: src:linux
> > Version: 6.6.9-1
> > Severity: normal
> > Tags: patch
> > X-Debbugs-Cc: 1700011...@pku.edu.cn
> >
> > Dear Maintainer,
> >
> > In short, current configuration of debian kernel makes some scaling
> governors
> > not usable, for example amd_pstate=passive Ondemand. Some small
> changes to
> > configuration can solve the problem.
> >
> > To sovle the problem there is two optional ways:
> > 1. Change some configurations like CONFIG_CPU_FREQ_GOV_POWERSAVE to y
> rather
> > than m
> > All the configuraion below needs to be chanegd to y:
> > CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> >
> > 2. Change the configuration CONFIG_MODULE_COMPRESS_XZ=y to
> > CONFIG_MODULE_COMPRESS_NONE=y
> > Notice that CONFIG_MODULE_COMPRESS_XZ=y not only breaks cpu frequency
> governors
> > but also breaks make bindeb-pkg. See
> > https://bugzilla.kernel.org/show_bug.cgi?id=218341
> > So that choose this option can deal with this issue too.
> >
> > Two file attached is about the two ways above to fix the problem.
> >
> >
> >
> > Here is some explanation:
> >
> > Debian kernel used to set configuration as
> CONFIG_MODULE_COMPRESS_NONE=y. but
> > after 6.6 debian kernel configuration use CONFIG_MODULE_COMPRESS_XZ=y
> to
> > compress the kernel module. However, modules for cpu frequency
> governors is not
> > usable when it's module is compressed.
> >
> > For example, CONFIG_CPU_FREQ_GOV_POWERSAVE=m is fine to work if
> > CONFIG_MODULE_COMPRESS_NONE=y , but if CONFIG_MODULE_COMPRESS_XZ=y is
> set then
> > powersave governor is unavailable. This problem is same to other cpu
> frequency
> > governor configurations like CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> >
> > On the other hand, configuration like CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> build the
> > governor into kernel rather than module, so that such problem does
> not exist.
> >


Some tips that I already have:

1. Many distros like arch or fedora have change 
CONFIG_CPU_FREQ_GOV_POWERSAVE from m to y. It is possible that they all 
have met such problem.


2. In Debian bug report I find something that may have some relation. 
See bug #1010581


3. I find that if CONFIG_CPU_FREQ_GOV_POWERSAVE=m, then though such 
module cannot be in use after boot at once, but it is possible to 
manually modprobe them. So it may indicate that to use 
CONFIG_CPU_FREQ_GOV_POWERSAVE=m with   CONFIG_MODULE_COMPRESS_XZ=y is 
actually possible. The problem we find here may be not so fundamental.



What else I want to say:

1. Changing such configs from m to y can solve the problem with almost 
not cost. So I suggest thinking about it.


2.  Surely I accept your suggestion that it is very likely a small 
mistake from kernel upstream, since even at userspace I can load and use 
these module by manually modprobe. I want to communicate with upstream 
but  I do not know how to use kernel.org bugzilla. The problem I have is 
that, I do not know how to make a line end. You can see here 
(https://bugzilla.kernel.org/show_bug.cgi?id=218341) that I use some 
stupid way to make new lines. So could you teach me how to start new 
line in kernel bugzilla?



Thanks,

Jy Deng



Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module

2024-01-04 Thread Luca Boccassi
On Thu, 04 Jan 2024 17:16:57 +0800 Jy Deng <1700011...@pku.edu.cn>
wrote:
> Package: src:linux
> Version: 6.6.9-1
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: 1700011...@pku.edu.cn
> 
> Dear Maintainer,
> 
> In short, current configuration of debian kernel makes some scaling
governors
> not usable, for example amd_pstate=passive Ondemand. Some small
changes to
> configuration can solve the problem.
> 
> To sovle the problem there is two optional ways:
> 1. Change some configurations like CONFIG_CPU_FREQ_GOV_POWERSAVE to y
rather
> than m
> All the configuraion below needs to be chanegd to y:
> CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> 
> 2. Change the configuration CONFIG_MODULE_COMPRESS_XZ=y to
> CONFIG_MODULE_COMPRESS_NONE=y
> Notice that CONFIG_MODULE_COMPRESS_XZ=y not only breaks cpu frequency
governors
> but also breaks make bindeb-pkg. See
> https://bugzilla.kernel.org/show_bug.cgi?id=218341
> So that choose this option can deal with this issue too.
> 
> Two file attached is about the two ways above to fix the problem.
> 
> 
> 
> Here is some explanation:
> 
> Debian kernel used to set configuration as
CONFIG_MODULE_COMPRESS_NONE=y. but
> after 6.6 debian kernel configuration use CONFIG_MODULE_COMPRESS_XZ=y
to
> compress the kernel module. However, modules for cpu frequency
governors is not
> usable when it's module is compressed.
> 
> For example, CONFIG_CPU_FREQ_GOV_POWERSAVE=m is fine to work if
> CONFIG_MODULE_COMPRESS_NONE=y , but if CONFIG_MODULE_COMPRESS_XZ=y is
set then
> powersave governor is unavailable. This problem is same to other cpu
frequency
> governor configurations like CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> 
> On the other hand, configuration like CONFIG_CPU_FREQ_GOV_POWERSAVE=y
build the
> governor into kernel rather than module, so that such problem does
not exist.
> 
> Notice that such problem not only breaks scaling driver acpi-cpufreq,
but also
> breaks modules for example amd pstate.

Why do those config break when the compression config is enabled? That
sounds like a bug in the kernel for those features, have you reported
that upstream? At the very least, the configuration system should
automatically set those to built-in, or refuse the wrong combination

-- 
Kind regards,
Luca Boccassi