Bug#1036530: linux-signed-amd64: Hard lock up of system
Control: tags -1 - moreinfo
Hi,
I repeated the git bisect, and the bad commit seems to be:
(git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
commit 24867516f06dabedef3be7eea0ef0846b91538bc
Author: Mario Limonciello
Date: Tue Aug 23 13:51:31 2022 -0500
ACPI: OSI: Remove Linux-Dell-Video _OSI string
This string was introduced because drivers for NVIDIA hardware
had bugs supporting RTD3 in the past.
Before proprietary NVIDIA driver started to support RTD3, Ubuntu had
had a mechanism for switching PRIME on and off, though it had required
to logout/login to make the library switch happen.
When the PRIME had been off, the mechanism had unloaded the NVIDIA
driver and put the device into D3cold, but the GPU had never come back
to D0 again which is why ODMs used the _OSI to expose an old _DSM
method to switch the power on/off.
That has been fixed by commit 5775b843a619 ("PCI: Restore config space
on runtime resume despite being unbound"). so vendors shouldn't be
using this string to modify ASL any more.
Reviewed-by: Lyude Paul
Signed-off-by: Mario Limonciello
Signed-off-by: Rafael J. Wysocki
drivers/acpi/osi.c | 9 -
1 file changed, 9 deletions(-)
This machine is a Dell with an nvidia chip so it looks like this really
could be the commit that that is causing the problems. The description
of the commit also seems (to my untrained eye) to be consistent with the
error reported on the console when the lockup occurs:
[ 58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due to previous error
(AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[ 58.729904] ACPI Error: Aborting method \_SB.PCI0.PEG0.PG00._ON due to
previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[ 60.083261] vfio-pci :01:00.0 Unable to change power state from D3cold
to D0, device inaccessible
Hopefully this is enough information for experts to resolve this.
Regards,
Nick.
* Salvatore Bonaccorso [230526 20:30]:
> Control: tags -1 + moreinfo
>
> Hi Nick,
>
> On Fri, May 26, 2023 at 09:25:23AM +0900, Nick Hastings wrote:
> > Hi Salvatore,
> >
> > thanks for your help. However, I'm now not sure if I really have
> > identified the commit that causes my problems. I fear I may have made
> > one or more mistakes when setting "git bisect good". I had been under
> > the impression that the lock up would happen no more than a few tens of
> > minutes after booting, however it seems that sometimes it can take a few
> > hours to occur.
> >
> > So, I'm running the git bisect again and will be more careful before
> > marking "git bisect good". It could take a few days.
> >
> > Should this particular bug be closed?
>
> Thanks a lot for reporting back, you time put in into bisect is very
> appreciated and valued! No, no need to close this one, as the bug
> still persist. Just followup please once you have identified the
> culprit with the fresh bisect.
>
> Please do remove by then as well the moreinfo tag again (you can write
> a control message with tag -1 - moreinfo, so won't appear as bug
> needing information from reporter).
>
> Thank you!
>
> Regards,
> Salvatore
Processed: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system
Processing control commands: > tags -1 - moreinfo Bug #1036530 [src:linux] linux-signed-amd64: Hard lock up of system Removed tag(s) moreinfo. -- 1036530: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Processing control commands: > reassign -1 src:lxcfs 5.0.3-1 Bug #1036818 [src:linux] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Bug reassigned from package 'src:linux' to 'src:lxcfs'. No longer marked as found in versions linux/6.1.1-1~exp1. Ignoring request to alter fixed versions of bug #1036818 to the same values previously set Bug #1036818 [src:lxcfs] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Marked as found in versions lxcfs/5.0.3-1. > forwarded -1 https://github.com/lxc/lxcfs/issues/553 Bug #1036818 [src:lxcfs] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Set Bug forwarded-to-address to 'https://github.com/lxc/lxcfs/issues/553'. > affects -1 src:mariadb Bug #1036818 [src:lxcfs] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Added indication that 1036818 affects src:mariadb -- 1036818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Control: reassign -1 src:lxcfs 5.0.3-1 Control: forwarded -1 https://github.com/lxc/lxcfs/issues/553 Control: affects -1 src:mariadb Hi, On Sat, May 27, 2023 at 11:51:26AM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Sat, May 27, 2023 at 11:50:06AM +0200, Salvatore Bonaccorso wrote: > > Hi Helge, hi Otto, > > > > On Sat, May 27, 2023 at 09:26:06AM +0200, Helge Deller wrote: > > > Just wondering / guessing: > > > > > > Are the ARM machines on ci.debian.net (ci-worker-arm??-??) > > > physical machines, or are they running on qemu-user VMs? > > > > > > If they run qemu, this bug report > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653 > > > might be similiar. > > > > > > If so, then qemu probably needs fixing of the output of /proc/cpuinfo > > > for ARM, e.g. like this: > > > https://gitlab.com/qemu-project/qemu/-/commit/e0174afeea23e56765db56fbbe465ed1fcbdd07a > > > > The suspect is that /proc/cpuinfo is empty or not readable, and this > > seems to be a problem with lxcfs after mentioning the issue today to > > Paul and Jochen. > > > > Jochen, understanding you correctly there is already an upstream fix > > which is supposed to addres the issue? > > The upstream issue should be: https://github.com/lxc/lxcfs/issues/553 Now reassigning to the lxcfs package. lxcfs maintainers, can you please adjust the severity as needed. It affects at least mariadb's autopkgtests. Otto, spaking of the issue, I guess Paul will agree, that you can ignore it for now for the mariadb upload to unstable. Regards, Salvatore
Re: Information About The Linux Kernel Maintenance In Debian
Hi Federico! > I'm a CERN employee currently evaluating Debian as a possible solution for our > systems in use to control particle accelerators. I would like to know more > about > how the Debian community handles the Linux kernel integration. In particular, > I > can't easily find the following information: Cool, if you have more specific followup questions, don't hesitate to ask. > - Criteria to select a kernel version for a Debian release. It looks to me you >are following LTS releases, but as you know kernel LTS is a moving target > in >terms of duration. So, how you choose? Debian releases happen every two years at approximately the end of the second quarter of uneven years. kernel.org LTS releases are usually announced/picked by end of each calendar year and the latest kernel.org LTS gets picked as the kernel version for Debian. Debian 9 has 4.9.x, Debian 10 had 4.19.x, Debian 11 and 5.10 and Debian 12 will have 6.1. > - How much a Debian kernel diverges from kernel.org release overtime? Not much, you can have a look yourself for the current patches applied to the 6.1.27 kernel which will be part of the initial Debian 12 release (and future updates will rebase to 6.1.x LTS releases): https://salsa.debian.org/kernel-team/linux/-/tree/sid/debian/patches Anything in bugfix are cherrypicked bugfixes, debian/ contains a small set of Debian-specific patches (for narrow toolchain or software freedom issues) and feature contains a small set of backports (e.g. currently for improved support for some non-x86 systems). In the past that also included backported support for some NICs or RAID controllers (but these usually only appear later in a release cycle). > - I see you explain how to build and run any kernel from kernel.org, but I do >not see and discouragement in doing so. Is this because you do not see any >known incompatibilities ? Generally running a patched or bespoke kernel is supported. It's mostly a matter of people power to do it properly (since one needs to rebase to security updates and applying custom patches might need rebases if underlying kernel code for updated). Some parts of the OS (e.g. systemd) expectsa given set of kernel features to be present to operate properly, but usually these are quite common and unlikely to be absent in custom configs anyway. If you start with the current Debian kernel config as a base (found under /boot/config-VERSION) you won't run into any surprises. Cheers, Moritz
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Hi, On Sat, May 27, 2023 at 11:50:06AM +0200, Salvatore Bonaccorso wrote: > Hi Helge, hi Otto, > > On Sat, May 27, 2023 at 09:26:06AM +0200, Helge Deller wrote: > > Just wondering / guessing: > > > > Are the ARM machines on ci.debian.net (ci-worker-arm??-??) > > physical machines, or are they running on qemu-user VMs? > > > > If they run qemu, this bug report > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653 > > might be similiar. > > > > If so, then qemu probably needs fixing of the output of /proc/cpuinfo > > for ARM, e.g. like this: > > https://gitlab.com/qemu-project/qemu/-/commit/e0174afeea23e56765db56fbbe465ed1fcbdd07a > > The suspect is that /proc/cpuinfo is empty or not readable, and this > seems to be a problem with lxcfs after mentioning the issue today to > Paul and Jochen. > > Jochen, understanding you correctly there is already an upstream fix > which is supposed to addres the issue? The upstream issue should be: https://github.com/lxc/lxcfs/issues/553 Regards, Salvatore
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Hi Helge, hi Otto, On Sat, May 27, 2023 at 09:26:06AM +0200, Helge Deller wrote: > Just wondering / guessing: > > Are the ARM machines on ci.debian.net (ci-worker-arm??-??) > physical machines, or are they running on qemu-user VMs? > > If they run qemu, this bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653 > might be similiar. > > If so, then qemu probably needs fixing of the output of /proc/cpuinfo > for ARM, e.g. like this: > https://gitlab.com/qemu-project/qemu/-/commit/e0174afeea23e56765db56fbbe465ed1fcbdd07a The suspect is that /proc/cpuinfo is empty or not readable, and this seems to be a problem with lxcfs after mentioning the issue today to Paul and Jochen. Jochen, understanding you correctly there is already an upstream fix which is supposed to addres the issue? Regards, Salvatore
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Just wondering / guessing: Are the ARM machines on ci.debian.net (ci-worker-arm??-??) physical machines, or are they running on qemu-user VMs? If they run qemu, this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653 might be similiar. If so, then qemu probably needs fixing of the output of /proc/cpuinfo for ARM, e.g. like this: https://gitlab.com/qemu-project/qemu/-/commit/e0174afeea23e56765db56fbbe465ed1fcbdd07a Helge
Processed: tagging 1036818
Processing commands for cont...@bugs.debian.org: > tags 1036818 + moreinfo Bug #1036818 [src:linux] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1036818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 1036818 to src:linux
Processing commands for cont...@bugs.debian.org: > # use Debian revisions > reassign 1036818 src:linux 6.1.1-1~exp1 Bug #1036818 [linux] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Bug reassigned from package 'linux' to 'src:linux'. No longer marked as found in versions 6.1.0. Ignoring request to alter fixed versions of bug #1036818 to the same values previously set Bug #1036818 [src:linux] linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat Marked as found in versions linux/6.1.1-1~exp1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1036818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)
Processing control commands: > severity -1 minor Bug #1035933 [src:linux] linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?) Severity set to 'minor' from 'serious' > tags -1 + moreinfo Bug #1035933 [src:linux] linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?) Added tag(s) moreinfo. -- 1035933: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035933 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)
Control: severity -1 minor Control: tags -1 + moreinfo Hi Claude, given your information and that the package builds fine on the buildds I downgrade this to minor and add a moreinfo tag. Cheers Jochen * Jochen Sprickerhof [2023-05-25 14:56]: Thanks for the information. I don't see why it should use llvm, on the other hand the kernel Makefile is rather clear when to use it. Can you check if you an still reproduce the problem? * Claude Heiland-Allen [2023-05-25 11:47]: Hi Jochen, I didn't set any non-standard compiler options as far as I recall. I certainly was not intending to build with LLVM. Unfortunately I have not kept the log of the failing build, but I remember seeing that gcc was used for the majority of the compilation. Regards, Claude signature.asc Description: PGP signature
