Processed: tagging 1065112
Processing commands for cont...@bugs.debian.org: > tags 1065112 + upstream Bug #1065112 [src:linux] linux-image-6.1.0-18-amd64: System unresponsive after resume from suspend when WoWLAN enabled in iwlwifi Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 1065112: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065112 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1065112: linux-image-6.1.0-18-amd64: System unresponsive after resume from suspend when WoWLAN enabled in iwlwifi
Package: src:linux
Version: 6.1.76-1
Severity: normal
X-Debbugs-Cc: da...@balch.co.uk
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I am trying to get WoWLAN working on an old DELL via a PCIe WiFi card (
https://www.amazon.co.uk/dp/B0BTCNG9TD?psc=1=ppx_yo2ov_dt_b_product_details
)
that uses the Intel 7265 chipset (
https://www.intel.com/content/www/us/en/products/sku/83635/intel-dual-band-wirelessac-7265/specifications.html
).
The card's result from lspci:
03:00.0 Network controller [0280]: "Intel Corporation Wireless 7265
[8086:095a] (rev 59)"
* What exactly did you do (or not do) that was effective (or
ineffective)?
1. Enabled WoWLAN with magic-packet with `iw phy0 wowlan enable magic-packet`
2. Suspend PC with `echo "mem" > /sys/power/state`
3. After suspend, press a key.
I also tried this with a pristine build of linux 6.7.6, and encountered the
same problem.
* What was the outcome of this action?
The display lit up, showing the same information as before suspend, but the
mouse and keyboard don't respond.
Magic SysRq does respond.
I found my way to seeing the kernel crash message (via preventing
console_suspend, and tweaking /proc/sys/kernel/{prink,sysrq} values),
as shown in the image at: https://imgur.com/a/E7dD0ND
Initial analysis of that photo from iam_tj[m]1 on irc #debian-kernel
(2024-02-29 19:48):
>From your photo we see
>`drivers/net/wireless/intel/iwlwifi/iwl-trans.c::iwl_trans_txq_enable_cfg()`
>report "bad state" and that is called from
>`drivers/net/wireless/intel/iwlwifi/mvm/d3.c::iwl_mvm_send_wowlan_get_status()`
> that reports "failed to query wakeup status (-5)".
>From reading the code around WoWLAN it seems a special WoWLAN firmware should
>be loaded into the device on suspend and on resume the driver is checking it
>is (still) there.
If not the driver should cause a full device reset.
`asm_exc_invalid_op` is a TRAP leading to
`arch/x86/kernel/traps.c::handle_invalid_op()` which may imply the code in RAM
has been corrupted (in the function `iwl_pcie_tx_start()` presumably).
Doesn't seem too likely though since code (.text sections) should be read-only
unless the RAM itself is faulty - but if that one wouldn't expect the same
error every time.
* What outcome did you expect instead?
The system resumes from suspend and is fully interactive (as it does when
WoWLAN is disabled).
-- Package-specific info:
** Version:
Linux version 6.1.0-18-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-18-amd64
root=UUID=b15802a9-4b38-4cb9-9109-fdf1cad881b0 ro quiet crashkernel=384M-:128M
** Not tainted
** Kernel log:
[4.039828] mei_me :00:16.0: enabling device ( -> 0002)
[4.064801] input: PC Speaker as /devices/platform/pcspkr/input/input9
[4.066671] ee1004 0-0051: 512 byte EE1004-compliant SPD EEPROM, read-only
[4.066685] ee1004 0-0053: 512 byte EE1004-compliant SPD EEPROM, read-only
[4.110654] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=4,
TCOBASE=0x0400)
[4.112303] dcdbas dcdbas: Dell Systems Management Base Driver (version
5.6.0-3.4)
[4.113931] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[4.128354] cfg80211: Loading compiled-in X.509 certificates for regulatory
database
[4.128506] cfg80211: Loaded X.509 cert 'b...@debian.org:
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[4.128645] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com:
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[4.128783] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[4.128917] cfg80211: Loaded X.509 cert 'wens:
61c038651aabdcf94bd0ac7ff06c7248db18c600'
[4.133009] platform regulatory.0: firmware: direct-loading firmware
regulatory.db
[4.133129] platform regulatory.0: firmware: direct-loading firmware
regulatory.db.p7s
[4.133616] input: Dell WMI hotkeys as
/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input10
[4.154628] Intel(R) Wireless WiFi driver for Linux
[4.166726] pcieport :00:1d.0: Intel SPT PCH root port ACS workaround
enabled
[4.166880] iwlwifi :03:00.0: enabling device (0100 -> 0102)
[4.169833] iwlwifi :03:00.0: firmware: direct-loading firmware
iwlwifi-7265D-29.ucode
[4.169856] iwlwifi :03:00.0: Found debug destination: EXTERNAL_DRAM
[4.169857] iwlwifi :03:00.0: Found debug configuration: 0
[4.170045] iwlwifi :03:00.0: loaded firmware version 29.4063824552.0
7265D-29.ucode op_mode iwlmvm
[4.184779] snd_hda_intel :00:1f.3: enabling device (0100 -> 0102)
[4.187148] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms
ovfl timer
[4.187150] RAPL PMU: hw unit of domain
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. > > The relevant code in Linux is: > > | quiet_cmd_btf_ko = BTF [M] $@ > | cmd_btf_ko = \ > | if [ ! -f vmlinux ]; then \ > | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ > | else \ > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ > | $(RESOLVE_BTFIDS) -b vmlinux $@; \ > | fi; > > Which change is needed here to use vmlinux.h instead? My understanding is that you don't need this command at all; the included vmlinux.h already contains the necessary type definitions for libbpf, for the kernel source version in question - ie: instead of needing to run pahole or bpftool to extract these definitions from a specific vmlinux image, this file is distributed with them already included. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > With the new vmlinux.h shipped in the headers package, the BTF case > should be covered. The relevant code in Linux is: | quiet_cmd_btf_ko = BTF [M] $@ | cmd_btf_ko = \ | if [ ! -f vmlinux ]; then \ | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ | else\ | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ | $(RESOLVE_BTFIDS) -b vmlinux $@;\ | fi; Which change is needed here to use vmlinux.h instead? Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > > Why was this never the case before? And can you be more precise about what > > "stuff" is missing? Is there a previous bug report I can reference? > > It complains loudly about BTF. With the new vmlinux.h shipped in the headers package, the BTF case should be covered. I think we should nudge packages to use that, rather than looking at the kernel image, or worse sysfs from the running kernel, which is completely wrong for obvious reasons. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
> The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. To be honest, "it does not really fail without, but lacks stuff" seems like the use case that "Recommends:" (or even "Suggests:") was designed for, rather than "Depends:", don't you agree? I'm not sure, of course, what problem is being addressed here; it's possible that there's a more elegant solution available. Is there a previous bug describing the problem? My concern is that I have a specific build server which builds kernels and modules for other machines in a farm. It needs to have the header files for specific target kernel versions installed, but it is not sensible to have the corresponding image packages installed (in many cases, those images wouldn't even run on this build server). Colm On Thu 29 Feb 2024, 11:03 Colm Buckley, wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? > > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. > > Colm > > > On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > >> Control: tags -1 wontfix >> >> On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: >> > The linux-headers packages for kernel version 6.6 seem to depend on the >> corresponding >> > linux-image packages, but I believe that this should not be the case >> (and was not the >> > case in previous versions). >> >> It should. The build wants the image available (it does not really fail >> without, but lacks stuff) and we need some dependency to keep image and >> headers in sync for people using dkms. >> >> Bastian >> >> -- >> Vulcans never bluff. >> -- Spock, "The Doomsday Machine", stardate 4202.1 >> >
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? It complains loudly about BTF. > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. Sure, but installing the image does not break much. But not installing the headers breaks much. Maybe you can provide a proposal how that would work? Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Why was this never the case before? And can you be more precise about what "stuff" is missing? Is there a previous bug report I can reference? DKMS should handle its own dependencies, I'd have thought - I see a clear use case for installing header files without the corresponding images. Colm On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > Control: tags -1 wontfix > > On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > > The linux-headers packages for kernel version 6.6 seem to depend on the > corresponding > > linux-image packages, but I believe that this should not be the case > (and was not the > > case in previous versions). > > It should. The build wants the image available (it does not really fail > without, but lacks stuff) and we need some dependency to keep image and > headers in sync for people using dkms. > > Bastian > > -- > Vulcans never bluff. > -- Spock, "The Doomsday Machine", stardate 4202.1 >
Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Processing control commands: > tags -1 wontfix Bug #1064976 [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Added tag(s) wontfix. -- 1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > The linux-headers packages for kernel version 6.6 seem to depend on the > corresponding > linux-image packages, but I believe that this should not be the case (and was > not the > case in previous versions). It should. The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Processed: Update to 1064976
Processing commands for cont...@bugs.debian.org: > reassign 1064976 linux-headers-amd64 Bug #1064976 [linux-headers-6.6.13+bpo-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bug reassigned from package 'linux-headers-6.6.13+bpo-amd64' to 'linux-headers-amd64'. Ignoring request to alter found versions of bug #1064976 to the same values previously set Ignoring request to alter fixed versions of bug #1064976 to the same values previously set > -- Stopping processing here. Please contact me if you need assistance. -- 1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
