Uploading linux (6.1.6-1)
Hi I would like to upload linux version 6.1.6-1 to unstable. It consist of importing 6.1.5 and 6.1.6 and covering as well some known assigned CVEs (CVE-2023-23455, CVE-2023-23454, CVE-2023-0210 and CVE-2023-0266). Additionally cherry picking the fix for CVE-2023-0179. An ABI bump is included. Notably though there is no fix for #1028451, currently under discussion if it should block transition to testing. We want to follow closely here on upstream decision. Other changes are adding further hardware support, one CVE fix and a bugfix for cross-compilation: * Fix cross Build-Depends: Annotate python3 and python3-jinja2 dependencies :native. (Closes: #1028184) * [hppa] Add i2c-modules udeb * [x86] Enable Intel Speed Select Technology as module (Closes: #1028344) - Enable INTEL_SPEED_SELECT_INTERFACE. * [amd64] Enable the Intel Data Accelerators performance monitor (Closes: #1028509) - Enable INTEL_IDXD_PERFMON. * [rt] Refresh "arm: Add support for lazy preemption" * Bump ABI to 2 * netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits (CVE-2023-0179) An ABI bump is for the moment required on every update due to the issues in #1003210 or #1022202. Regards, Salvatore signature.asc Description: PGP signature
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > upstream here: > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > Thanks! About an hour ago the suggested fix was to revert commit > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > describes a procedure to build a kernel with the proposed patch (attached). > > OdyX: Can you try to see whether that resolves the issue? Should we keep 6.1.y based kernel out of testing until this is clear? As we aim though to have 6.1.y into bookworm I would see it as more preferable to get 6.1.4 in for testing, we will need to followup as well soonish with another interation for e.g. for fixing CVE-2023-0266. Now if it turns out that this is the same issue as the referenced upstream, reverting I think we only should really revert the commit if that's queued up for 6.1. There is currently some furhter discussion on https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 Given the size of the revert, there is as well a chance to re-break other parts. So preferring to closely follow upstream here, whatever the decision will be. Regards, Salvatore
Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address
Hi Jakub, On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote: > * Salvatore Bonaccorso , 2022-11-19 11:11: > > Given you were able to tackle the issue further, can you report the > > issue to upstream > > Don't count on me. Sorry! Okay thanks for beeing explicit on that. Then I guess it's on our end to try to get that upstream. Regards, Salvatore
Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency
Hi, On Thu, Jan 12, 2023 at 02:28:59PM -0800, Ian Rogers wrote: > On Wed, Jan 11, 2023 at 10:08 AM Andreas Gerstmayr > wrote: > > > > On 11.01.23 18:13, Ian Rogers wrote: > > > On Wed, Jan 11, 2023 at 5:18 AM Andreas Gerstmayr > > > wrote: > > >> > > >> On 10.01.23 20:51, Ian Rogers wrote: > > >>> On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr > > >>> wrote: > > > > On 05.01.23 10:24, Ian Rogers wrote: > > > On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers wrote: > > >> > > >> Currently flame graph generation requires a d3-flame-graph template > > >> to > > >> be installed. Unfortunately this is hard to come by for things like > > >> Debian [1]. If the template isn't installed warn and download it from > > >> jsdelivr CDN. If downloading fails generate a minimal flame graph > > >> again with the javascript coming from jsdelivr CDN. > > >> > > >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839 > > >> > > >> Signed-off-by: Ian Rogers > > > > I'm not entirely convinced that this perf script should make a network > > request. In my opinion > > > > * best would be if this template gets packaged in Debian > > * alternatively print instructions how to install the template: > > > > sudo mkdir /usr/share/d3-flame-graph > > sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html > > https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html > > > > * or eventually just embed the entire template (66 KB) in the Python > > file (not sure if this is permissible though, it's basically a minified > > HTML/JS blob)? > > * if the above options don't work, I'd recommend asking the user before > > making the network request, and eventually persist the template > > somewhere so it doesn't need to be downloaded every time > > > > What do you think? > > >>> > > >>> So the script following this patch is going to try 3 things: > > >>> 1) look for a local template HTML, > > >>> 2) if a local template isn't found warn and switch to downloading the > > >>> CDN version, > > >>> 3) if the CDN version fails to download then use a minimal (embedded > > >>> in the script) HTML file with JS dependencies coming from the CDN. > > >>> > > >>> For (1) there are references in the generated HTML to www.w3.org, > > >>> meaning the HTML isn't fully hermetic - although these references may > > >>> not matter. > > >> > > >> The references to w3.org are XML namespace names. As far as I'm aware > > >> they do not matter, as they are merely identifiers and are never > > >> accessed [1,2]. Therefore the generated HTML file in its current form is > > >> hermetic. > > >> > > >> This was a design decision from the start - the flame graph generation > > >> and the resulting HTML file should not use any external resources loaded > > >> over the network (the external host could be inaccessible or compromised > > >> at any time). I understand that this requirement may not apply to every > > >> user or company. > > >> > > >>> For (2) there will be a download from the CDN of the template during > > >>> the execution of flamegraph. The template is better than (3) as it > > >>> features additional buttons letting you zoom out, etc. The HTML will > > >>> contain CDN references. > > >>> For (3) the generated HTML isn't hermetic and will use the CDN. > > >>> > > >>> For (2) we could give a prompt before trying to download the template, > > >>> or we could change it so that we give the wget command. I wouldn't > > >>> have the wget command require root privileges, I'd say that the > > >>> template could be downloaded and then the path of the download given > > >>> as an option to the flamegraph program. Downloading the file and then > > >>> adding an option to flamegraph seems inconvenient to the user, > > >>> something that the use of urllib in the patch avoids - it is > > >>> essentially just doing this for the user without storing the file on > > >>> disk. I think I prefer to be less inconvenient, and so the state of > > >>> the code at the moment looks best to me. Given that no choice results > > >>> in a fully hermetic HTML file, they seem similar in this regard. Is it > > >>> okay to try a download with urllib? Should there be a prompt? I think > > >>> the warning is enough and allows scripts, etc. using flamegraph to > > >>> more easily function across differing distributions. > > >> > > >> I fully agree, your changes make the flame graph generation more > > >> convenient in case the template is not installed. Also, downloading the > > >> template to a local directory and having to specify the path to the > > >> template every time is an inconvenience. > > >> > > >> I think it is a tradeoff between convenience and security/privacy. > > >> jsdelivr can get compromised, serving malicious JS (well, in that case, > > >> printing instructions to
Bug#1028376: linux-image-5.10.0-20-amd64: PHP Performance on kernels above 5.10.0-16-amd64 on Debian 11
Hi, On Tue, Jan 10, 2023 at 10:00:51AM +0100, Tomeu Vidal Vázquez wrote: > Package: src:linux > Version: 5.10.158-2 > Severity: normal > > Dear Maintainer, > >* What led up to the situation? After kernel 5.10.0-16-amd64 > (5.10.0-17-amd64 and above) the performace of the machine is dropping. The > same machine running kernel 5.10.0-16-amd64 has about 100% less of load. > >* What exactly did you do (or not do) that was effective (or ineffective)? > Booting machine with kernel 5.10.0-16-amd64. >* What was the outcome of this action? Booting machine with kernel > 5.10.0-16-amd64 solve the problem. Above kernels from 5.10.0-17-amd64 to > 5.10.0-20-amd64 has 100% more load. >* What outcome did you expect instead? I expect the same performace > between diferent kernels The update bumping ABI to 17, 5.10.136-1, was the one introducing mitigations for RETbleed on AMD (CVE-2022-29900) and Intel (CVE-2022-29901) processors. Have a look at https://lore.kernel.org/all/ph0pr05mb8448a203a909959fac754b7aaf...@ph0pr05mb8448.namprd05.prod.outlook.com/ The noticable performance drops vary differently depending on the affected CPU. If you do not need the mitigations in your particular case, disable those. Does performace measured improves again? The call depth tracking mitigations mentioned in the above thread did then land in v6.2-rc1. Regards, Salvatore
Bug#1028344: linux: Enable Intel Speed Select Technology
Control: tags -1 + moreinfo Hi Miguel, I have a question back on your request: On Mon, Jan 09, 2023 at 12:29:31PM -0600, Miguel Bernal Marin wrote: > Source: linux > Severity: wishlist > Tags: sid > X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, > jair.de.jesus.gonzalez.plascen...@intel.com > > Dear Maintainer, > > Intel is planing to release the next-generation Xeon products [1] and some > of the features are not enabled on Debian. It would be useful to have this > feature in Bookworm. > > # Intel(R) Speed Select Technology > > CONFIG_INTEL_SPEED_SELECT_INTERFACE=m > > The Intel(R) Speed Select Technology (Intel(R) SST) provides a powerful > new collection of features that give more granular control over CPU > performance. With Intel(R) SST, one server can be configured for power > and performance for a variety of diverse workload requirements. > > Refer to the links below for an overview of the technology: > > * > https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html > * > https://builders.intel.com/docs/networkbuilders/intel-speed-select-technology-base-frequency-enhancing-performance.pdf > > These capabilities are further enhanced in some of the newer generations > of server platforms where these features can be enumerated and controlled > dynamically without pre-configuring via BIOS setup options. This dynamic > configuration is done via mailbox commands to the hardware. One way to > enumerate and configure these features is by using the Intel Speed Select > utility. > > [1] > https://www.intel.com/content/www/us/en/newsroom/news/intel-technology-roadmaps-milestones.html As we do not build those intel-speed-select too, does it still make sense to enable it, are there other ways to control the features? Or does it only make sense if we would build intel-speed-select as well? Regards, Salvatore
Bug#1028184: unsatisfiable cross Build-Depends: python3-jinja2
Hi Helmut, On Sun, Jan 08, 2023 at 07:44:16AM +0100, Helmut Grohne wrote: > Source: linux > Version: 6.1.4-1 > Tags: patch > Severity: important > Justification: breaks architecture bootstrap > User: helm...@debian.org > Usertags: rebootstrap > User: debian-cr...@lists.debian.org > Usertags: cross-satisfiability > > Hi, > > the addition of the python3-jinja2 build dependency happens to break > architecture bootstrap. It's not as bad as it may sound initially > though. > > python3-jinja2 is an architecture-dependent package due to being a C > extension. As such it is installed for the host architecture by default. > Thus apt tries to install the whole python stack for the host > architecture and that doesn't go well. We cannot make python3-jinja2 > Multi-Arch: foreign, because it really isn't, so consumers (like linux) > have to choose how they use it instead. In this case, it's meant to be > run during build and that means it should be annotated :native. While at > it, I think that it is more honest to also apply this to python3 as well > in order to disallow a host architecture Python interpreter. > > This happens to be easy to work around in rebootstrap, so don't upload > linux just for this bug, but please include the patch in your next > regular upload to unstable. Thanks, picked it up locally, and will later push to sid branch and will be included in the next unstable upload. Regards, Salvatore
Bug#1028116: linux-image-6.0.0-4-amd64: Bluetooth no longer working with Mediatek MT7921K chipset
Hi Matthew, On Sat, Jan 07, 2023 at 10:52:58AM -0800, Matthew McAllister wrote: > Sorry for my mistake. I upgraded to 6.0.12-1 and still no bluetooth. I > additionally downgraded to 5.10.149-2, and that version had no bluetooth and > no wifi support either. I wasn't able to even install 5.19.11-1; I suspect > 5.19 may have been the last version I had installed where bluetooth actually > worked. > > I don't know how to install experimental kernel versions on testing, but I'm > willing to try it out or compile it myself. Thanks for your quick response. For installing 5.19.11-1 to confirm it works: When a package is not anymore in the archive, you can use the snapshots service which contains the old versions: https://snapshot.debian.org/ You can get from there the old binary package which you can install: https://snapshot.debian.org/package/linux/ (to get the unsigned packages), or https://snapshot.debian.org/package/linux-signed-amd64/ for the signed one. You can use the same as well for installing the newer versions (or alternatively add, temporarily, the experimental and unstable sources.list entries and install the packages). For testing newer versions, 6.1.4-1 was uploaded earlier today to unstable. Knowing first if it's a regression from the linux packages would be helpful, so confirming it indeed still works with 5.19.11-1. Does this gives you some hints on how to start? Regards, Salvatore
Bug#1028116: linux-image-6.0.0-4-amd64: Bluetooth no longer working with Mediatek MT7921K chipset
Control: tags -1 + moreinfo Hi Matthew, On Fri, Jan 06, 2023 at 09:24:11PM -0800, Matthew McAllister wrote: > Package: src:linux > Version: 6.0.8-1 > Severity: normal > Tags: upstream > X-Debbugs-Cc: matthew.mcalliste...@gmail.com > > Dear Maintainer, > > Bluetooth is no longer usable with this chipset on this kernel version. > /sys/class/bluetooth is not present after booting or rebooting. There are no > lines relating to bluetooth in dmesg. Here is the relevant part of lsmod: > mt7921e32768 0 > mt7921_common 94208 1 mt7921e > mt76_connac_lib73728 2 mt7921e,mt7921_common > mt76 106496 3 mt7921e,mt7921_common,mt76_connac_lib > mac80211 1159168 3 mt76,mt7921_common,mt76_connac_lib > cfg80211 1118208 4 mt76,mac80211,mt7921_common,mt76_connac_lib > > WiFi *does* continue to work with this chipset. Only bluetooth seems to be > affected. As 6.0.8-1 is not the most recent kernel in testing, can you test with 6.0.12-1 as well, or ideally even better with 6.1.2-1~exp1? Does the problem persist there? If yes, would you be able to bisect against an older known working kernel version to identify where the problem arise and got introduced? Regards, Salvatore
Uploading linux (6.1.3-1)
Hi I would like to upload linux version 6.1.3-1 (possibly 6.1.4-1 instead) to unstable. Note this is aimed to be the kernel we want to use for Debian bookworm. An ABI bump is included. It is a new upstream version switching from the 6.0.y stable release to 6.1.y. Apart from switching from 6.0.y to 6.1.y there are additional changes covering: * Fix build regression in stage1 and pkg.linux.nokernel profiles * linux-perf: Simplify build-dependency on libbabeltrace-dev * linux-perf: Build with libzstd * linux-perf: Disable building with libdebuginfod * linux-perf: Update variable definitions to disable building with libbfd * [arm64] Fix/enable audio on rk356x devices * [arm64] Enable various Pine64's SOQuartz features * [arm64] Enable several Pine64's SOQuartz baseboards * [arm64] Backport rk3568-odroid-m1.dts file from upstream. * [x86] Enable X86_SGX_KVM (Closes: #1026174) * [arm64,powerpc*,s390x,x86] arch: Enable RANDOMIZE_KSTACK_OFFSET_DEFAULT (Closes: #1016056) * [x86] drivers/thermal/intel: Enable INTEL_HFI_THERMAL (Closes: #1026336) * lockdown: Correct mentioning of mode when LOCK_DOWN_IN_EFI_SECURE_BOOT is enabled (Closes: #1025417) * [x86] drivers/cpufreq: Change X86_AMD_PSTATE from module to built-in * [rt] Update to 6.1-rc7-rt5 * net: wwan: iosm: fix dma_alloc_coherent incompatible pointer type (Fixes FTBFS on armhf) * [arm64] drivers/perf: Enable ARM_SPE_PMU as a module * [arm64] drivers/perf: Enable ARM_DSU_PMU as a module * [arm64] drivers/perf: Convert CCN_PMU from builtin to a module * trace: Enable HIST_TRIGGERS for all kernels * [x86] drivers/hwmon: Enable SENSORS_AQUACOMPUTER_D5NEXT as module (Closes: #1019496) * [arm64] Drop "arm64: dts: rockchip: correct voltage selector on Firefly-RK3399" (never applied upstream) * [x86] drivers/hwmon: Enable SENSORS_CORSAIR_CPRO as module (Closes: #1023992) * [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_SOF_ES8336_MACH as module (Closes: #1014595) * [s390x] debian/config: Drop explicit enable of RELOCATABLE. * mm: Enable Multi-Gen LRU implementation (not enabled by default) * Enable CXL_BUS for amd64 arm64 ppc64el riscv64 (Closes: #1021998) * [riscv64] Set CONFIG_I2C=y to match most other architectures and fix an FTBFS due to modules ending-up in more than one package. * [riscv64] Improve Microchip Polarfire support: - Enable HW_RANDOM_POLARFIRE_SOC. - Enable MAILBOX and POLARFIRE_SOC_MAILBOX. - Enable POLARFIRE_SOC_SYS_CTRL. - Enable RTC_DRV_POLARFIRE_SOC. * [arm64] Enable ARCH_NXP. * verity: enable DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING * ima: enable ARCH_POLICY to let IMA check the status of SecureBoot * Enable CONFIG_INTEGRITY_MACHINE_KEYRING to load keys from MoK into the new machine keyring, trust by default and link into trusted and secondary keyrings. Refresh/drop obsolete out-of-tree patches. * [arm64] Enable ARCH_BCM to re-enable various RPi options * [arm64] Enable support for Rockchip rk356x devices (Rock 3A, Quartz64, Odroid M1, etc.): - Enable ARM_SCMI_PROTOCOL, COMMON_CLK_SCMI, RESET_SCMI. - Enable CHARGER_RK817. - Enable MMC_SDHCI_OF_DWCMSHC. - Enable MOTORCOMM_PHY. - Enable PCIE_ROCKCHIP_DW_HOST, PHY_ROCKCHIP_SNPS_PCIE3. - Enable PHY_ROCKCHIP_INNO_CSIDPHY, PHY_ROCKCHIP_INNO_DSIDPHY, PHY_ROCKCHIP_NANENG_COMBO_PHY. - Enable ROCKCHIP_VOP2. - Enable SND_SOC_RK817, SND_SOC_ROCKCHIP_I2S_TDM. - Enable SPI_ROCKCHIP_SFC. * drivers/net/ethernet/sfc: Re-enable support for Solarflare SFC9000 (Closes: #1022276) - Enable SFC_SIENA as module - Enable SFC_SIENA_MTD, SFC_SIENA_MCDI_MON, SFC_SIENA_SRIOV and SFC_SIENA_MCDI_LOGGING Several other changes and improvements around the packaging were done. There is the issue around https://lists.debian.org/debian-kernel/2022/12/msg00166.html which needs to be resolved for the bookworm release. Regards, Salvatore signature.asc Description: PGP signature
Bug#1028001: closing 1028001
Hi, On Thu, Jan 05, 2023 at 04:35:44PM -0500, Raouf M. Bencheraiet wrote: > Hi > > On Thu, Jan 5, 2023 at 4:27 PM Salvatore Bonaccorso > wrote: > > > Hi, > > > > On Thu, Jan 05, 2023 at 04:15:16PM -0500, Raouf M. Bencheraiet wrote: > > > is 2.5.4-1~exp1 available for debian stable?! > > > > No, it will be in the next upcoming stable release Debian bookworm, as > > we finally catched up following upstream releases more closely now > > (Debian bookworm will likely have a 2.6.2 based version). > > > > > The Debian BTS can handle version tracking, so it will show the stable > > version still as affected. If backporting fixes to the 1.3.4 version > > is feasible then we might pick those up as well via a bullseye point > > release for the older version. > > > > My guess is that it will though be unfortunately too risky to actually > > do that for 1:1.3.4-6. > > > > I'll see if I can try that (backporting) on my own. > Although, building 2.6.2 for bullseye seems the easy way out (I do have > 2.6.x running on other > clients albeit on a different distro -- gentoo --). I guess we'll see what > panes out! > Great thanks for the quick replies! Alright! Maybe someone of the team is willing to provide as well an official 2.6.2 backport for bullseye-backports (but I cannot commit to doing so). Regards, Salvatore
Bug#1028001: closing 1028001
Hi, On Thu, Jan 05, 2023 at 04:15:16PM -0500, Raouf M. Bencheraiet wrote: > is 2.5.4-1~exp1 available for debian stable?! No, it will be in the next upcoming stable release Debian bookworm, as we finally catched up following upstream releases more closely now (Debian bookworm will likely have a 2.6.2 based version). The Debian BTS can handle version tracking, so it will show the stable version still as affected. If backporting fixes to the 1.3.4 version is feasible then we might pick those up as well via a bullseye point release for the older version. My guess is that it will though be unfortunately too risky to actually do that for 1:1.3.4-6. Regards, Salvatore
Bug#1022126: mpt3sas broken with xen dom0
Hi Taavi, On Mon, Jan 02, 2023 at 03:54:16PM +0200, Taavi Ansper wrote: > Are there any news regarding when the fix would be implemented for bullseye? See https://lore.kernel.org/linux-scsi/181536c494aa39ca78b190396a97072448739411.ca...@suse.com/ for an upstream status. Once the patches land in mainline, they can be picked up for the stable series. Then it will be included as well for bullseye as we follow the stable series and try to rebase at least on each point release. So I would expect we can see the fix in the next update. Regards, Salvatore
Bug#1027430: linux-image-5.10.0-20-amd64: No sound on Lenovo IdeaPad 3
Hi Martin,
On Sun, Jan 01, 2023 at 08:50:34PM +0100, Martin Furlanic wrote:
> I'm quite a knowlegeable user and glad to help, but I think I'll be needing
> some directons on how to do it. At this point I'm booting the machine with
> the linux-image-5.10.0-19, just the one before the december release of
> updates, and everything is working well as before.
Thank you. In #1027483 PÁLFFY Dániel bisected the issue down to commit
c34db0d6b88b ("ASoC: soc-pcm: Don't zero TDM masks in
__soc_pcm_open()").
If you would be able to confirm as well that such a revert fixes the
issue that would be of help indeed.
We have some instruction here on how to build Debian's kernel with a
single patch on top:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
The patch which would need to be applied is the revert of the above
commit, which I'm attaching here.
Regards,
Salvatore
>From 039fd15cf22a0807f8e68fc8ba9fa0d3c015bf18 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso
Date: Mon, 2 Jan 2023 11:32:44 +0100
Subject: [PATCH] Revert "ASoC: soc-pcm: Don't zero TDM masks in
__soc_pcm_open()"
This reverts commit c34db0d6b88b1da95e7ab3353e674f4f574cccee.
---
sound/soc/soc-pcm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index fb874f924bbe..9a60d62f12fe 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -723,6 +723,11 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
ret = snd_soc_dai_startup(dai, substream);
if (ret < 0)
goto err;
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ dai->tx_mask = 0;
+ else
+ dai->rx_mask = 0;
}
/* Dynamic PCM DAI links compat checks use dynamic capabilities */
--
2.39.0
Bug#1027483: linux-image-5.10.0-20-amd64: sound with firmware-sof-intel on Intel Lake stops working with newer kernel
Hi Malvin, On Sun, Jan 01, 2023 at 07:27:31PM +0100, Malvin Gattinger wrote: > Dear Salvatore, > > > https://wiki.debian.org/DebianKernel/GitBisect > > Thank you for the quick reply and suggestion to bisect this. But > (un)fortunately the laptop where the problem occurs is not my own and I have > neither the experience nor time to compile and try kernels on it. Sorry if > this would be my job, now that I made a report. I only saw those forum posts > so far and was mostly hoping to get other eyes on this by filing a bug. No worries, was more the question if you can further help pinpointing the issue. Dániel bisected the issue down to a change introduced in 5.10.157. Regards, Salvatore
Bug#1027430: linux-image-5.10.0-20-amd64: No sound on Lenovo IdeaPad 3
Control: tags -1 + moreinfo On Sat, Dec 31, 2022 at 01:12:13PM +0100, Martin Furlanič wrote: > Package: src:linux > Version: 5.10.158-2 > Severity: normal > X-Debbugs-Cc: martin.furla...@gmail.com > > > > -- Package-specific info: > ** Version: > Linux version 5.10.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-10 > (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) > #1 SMP Debian 5.10.158-2 (2022-12-13) > > ** Command line: > BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 > root=UUID=87df20a8-1d34-4d1a-a72f-a638f3903070 ro quiet > > ** Not tainted > > ** Kernel log: > [5.440482] audit: type=1400 audit(1672488471.944:3): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="lsb_release" pid=497 > comm="apparmor_parser" > [5.445266] audit: type=1400 audit(1672488471.948:4): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="/usr/bin/akonadiserver" > pid=498 comm="apparmor_parser" > [5.451349] audit: type=1400 audit(1672488471.956:5): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=505 > comm="apparmor_parser" > [5.452211] audit: type=1400 audit(1672488471.956:6): apparmor="STATUS" > operation="profile_load" profile="unconfined" > name="/usr/lib/snapd/snap-confine" pid=500 comm="apparmor_parser" > [5.452213] audit: type=1400 audit(1672488471.956:7): apparmor="STATUS" > operation="profile_load" profile="unconfined" > name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=500 > comm="apparmor_parser" > [5.454140] audit: type=1400 audit(1672488471.956:8): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" > pid=503 comm="apparmor_parser" > [5.454755] audit: type=1400 audit(1672488471.960:9): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="postgresql_akonadi" > pid=504 comm="apparmor_parser" > [5.457653] audit: type=1400 audit(1672488471.960:10): apparmor="STATUS" > operation="profile_load" profile="unconfined" > name="/usr/libexec/ibus-engine-hangul" pid=508 comm="apparmor_parser" > [5.465292] audit: type=1400 audit(1672488471.968:11): apparmor="STATUS" > operation="profile_load" profile="unconfined" name="libvirtd" pid=509 > comm="apparmor_parser" > [5.479178] rtw_8822ce :01:00.0: enabling device ( -> 0003) > [5.482956] rtw_8822ce :01:00.0: firmware: direct-loading firmware > rtw88/rtw8822c_wow_fw.bin > [5.482961] rtw_8822ce :01:00.0: Firmware version 9.9.4, H2C version 15 > [5.484112] rtw_8822ce :01:00.0: firmware: direct-loading firmware > rtw88/rtw8822c_fw.bin > [5.484120] rtw_8822ce :01:00.0: Firmware version 9.9.6, H2C version 15 > [5.657215] sof-audio-pci :00:1f.3: DSP detected with PCI > class/subclass/prog-if info 0x040100 > [5.657234] sof-audio-pci :00:1f.3: Digital mics found on Skylake+ > platform, using SOF driver > [5.657249] sof-audio-pci :00:1f.3: enabling device ( -> 0002) > [5.657475] sof-audio-pci :00:1f.3: DSP detected with PCI > class/subclass/prog-if 0x040100 > [5.657577] sof-audio-pci :00:1f.3: bound :00:02.0 (ops > i915_audio_component_bind_ops [i915]) > [5.665146] sof-audio-pci :00:1f.3: use msi interrupt mode > [5.708490] intel_rapl_msr: PL4 support detected. > [5.708519] intel_rapl_common: Found RAPL domain package > [5.708521] intel_rapl_common: Found RAPL domain core > [5.708522] intel_rapl_common: Found RAPL domain uncore > [5.783997] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: > bound :00:02.0 (ops i915_hdcp_component_ops [i915]) > [5.789421] rtw_8822ce :01:00.0 wlp1s0: renamed from wlan0 > [5.789808] Bluetooth: Core ver 2.22 > [5.789896] NET: Registered protocol family 31 > [5.789896] Bluetooth: HCI device and connection manager initialized > [5.789900] Bluetooth: HCI socket layer initialized > [5.789901] Bluetooth: L2CAP socket layer initialized > [5.789904] Bluetooth: SCO socket layer initialized > [5.809119] usbcore: registered new interface driver btusb > [5.810049] sof-audio-pci :00:1f.3: hda codecs found, mask 5 > [5.810051] sof-audio-pci :00:1f.3: using HDA machine driver > skl_hda_dsp_generic now > [5.810056] sof-audio-pci :00:1f.3: DMICs detected in NHLT tables: 2 > [5.812606] sof-audio-pci :00:1f.3: firmware: direct-loading firmware > intel/sof/sof-tgl.ri > [5.812614] sof-audio-pci :00:1f.3: warning: unknown sof_ext_man > header type 6 size 0x20 > [5.812615] sof-audio-pci :00:1f.3: Firmware info: version 1:7:0-47d07 > [5.812616] sof-audio-pci :00:1f.3: Firmware: ABI 3:18:1 Kernel ABI > 3:17:0 > [5.812617] sof-audio-pci :00:1f.3: warn: FW ABI is more recent than > kernel > [5.812621] sof-audio-pci :00:1f.3: warning: unknown sof_ext_man > header type 3 size 0x30 > [
Bug#1027483: linux-image-5.10.0-20-amd64: sound with firmware-sof-intel on Intel Lake stops working with newer kernel
Control: tags -1 + moreinfo On Sun, Jan 01, 2023 at 04:34:28PM +0100, Salvatore Bonaccorso wrote: > Control: reassign -1 src:linux 5.10.158-2 > > Hi Malvin, > > On Sun, Jan 01, 2023 at 02:36:28PM +0100, Malvin Gattinger wrote: > > Package: linux-image-5.10.0-20-amd64 > > Version: 5.10.158-2 > > Severity: normal > > X-Debbugs-Cc: mal...@w4eg.eu > > > > Dear Maintainer, > > > > I am unsure if this problem belongs to linux-image-amd64 as a > > regression or is actually a but in firmware-sof-intel. > > > > On an HP ProBook with this sound card (from lspci): > > > > 00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP > > Smart Sound Technology Audio Controller (rev 20) > > > > Updating from linux-image-5.10.0-19-amd64 to > > linux-image-5.10.0-20-amd64 breaks sound. > > > > Sound output from VLC works fine immediately after boot, but using > > the microphone or other audio use cases later disables all output. > > Unfortunately the only reproducible example on this laptop was to > > open the proprietary zoom video-conferencing software which > > immediately stops all output, but other symptoms are discussed here: > > > > https://forums.debian.net/viewtopic.php?t=153585 > > > > https://forums.debian.net/viewtopic.php?p=764594 > > > > PulseAudio claims that the output is still running, i.e. pavucontrol > > and KDE audio settings still show a moving bar for the output. > > > > The only workaround for now is to use the older kernel from > > linux-image-5.10.0-19-amd64. > > To pin point the possibly breaking change in the kernel, would you be > able to build kernels, first both upstream kernels mathcing the > 5.10.149 (for the 19 ABI one), and 5.10.158 and then bisect betweeen > the two? > > https://wiki.debian.org/DebianKernel/GitBisect Following that, I wonder if #1027483, #1026834 (and maybe #1010733) will have all the same underlying cause. Regards, Salvatore
Bug#1027483: linux-image-5.10.0-20-amd64: sound with firmware-sof-intel on Intel Lake stops working with newer kernel
Control: reassign -1 src:linux 5.10.158-2 Hi Malvin, On Sun, Jan 01, 2023 at 02:36:28PM +0100, Malvin Gattinger wrote: > Package: linux-image-5.10.0-20-amd64 > Version: 5.10.158-2 > Severity: normal > X-Debbugs-Cc: mal...@w4eg.eu > > Dear Maintainer, > > I am unsure if this problem belongs to linux-image-amd64 as a > regression or is actually a but in firmware-sof-intel. > > On an HP ProBook with this sound card (from lspci): > > 00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP > Smart Sound Technology Audio Controller (rev 20) > > Updating from linux-image-5.10.0-19-amd64 to > linux-image-5.10.0-20-amd64 breaks sound. > > Sound output from VLC works fine immediately after boot, but using > the microphone or other audio use cases later disables all output. > Unfortunately the only reproducible example on this laptop was to > open the proprietary zoom video-conferencing software which > immediately stops all output, but other symptoms are discussed here: > > https://forums.debian.net/viewtopic.php?t=153585 > > https://forums.debian.net/viewtopic.php?p=764594 > > PulseAudio claims that the output is still running, i.e. pavucontrol > and KDE audio settings still show a moving bar for the output. > > The only workaround for now is to use the older kernel from > linux-image-5.10.0-19-amd64. To pin point the possibly breaking change in the kernel, would you be able to build kernels, first both upstream kernels mathcing the 5.10.149 (for the 19 ABI one), and 5.10.158 and then bisect betweeen the two? https://wiki.debian.org/DebianKernel/GitBisect Regards, Salvatore
Bug#1027325: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: inaccessible or not found
Hi,
Thanks Diederik.
On Fri, Dec 30, 2022 at 01:01:55PM +0100, Diederik de Haas wrote:
> On Friday, 30 December 2022 12:42:53 CET Thorsten Glaser wrote:
> > I think I reported the same thing against experimental some time ago,
> > but it now is a regression in stable. Building kernel modules shows:
> >
> > tglase@tglase-edge:~/lnx/master/janz $ make
> > make -C '/lib/modules/5.10.0-20-amd64/build'
> > M='/home/tglase/lnx/master/janz' modules make[1]: Entering directory
> > '/usr/src/linux-headers-5.10.0-20-amd64' W: /bin/sh:
> > /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh:
> > inaccessible or not found
>
> That's likely https://bugs.debian.org/1008501 that was fixed here:
> https://salsa.debian.org/kernel-team/linux/-/commit/ee29a5e231886d26cef901285bf46a1f929ad4eb
Upstream commit c5006abb80e2 ("kbuild: Unify options for BTF
generation for vmlinux and modules") was as well backported in the
last rounds to 5.10.151, so yes we need the same fix for bullseye as
well.
Have added it to the bullseye branch for the next upload.
Regards,
Salvatore
Bug#1027174: linux-image-*-cloud-amd64: please add support for the 9p filesystem
Hi, Related earlier request in #955232 for cross-reference. Regards, Salvatore
Bug#1021391: Possible solved with kernel 6.0.12
Hi Bernhard, On Mon, Dec 26, 2022 at 04:37:48PM +, Bernhard wrote: > Hello all > > It seems, with Kernel 6.0.12 this problem is solved. > This problem was never shown with kernel 6.0.12. > > I'll have a further look for the next days. > After that, i'll close this bug. Many thanks for reporting back. If it does not show furthr up in the next few days then please do close it as you said, add please a corresponding fixed version to 6.0.12-1. Regards, Salvatore
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
Control: tags -1 + moreinfo Hi Albert, On Sat, Dec 24, 2022 at 09:01:14PM +, Albert Nash wrote: > Package: linux-image-5.10.0-20-amd64 > Version: 5.10.158-2 > How to reproduce: > 1) Boot Debian GNU/Linux 11 (bullseye), which is „stable“ now, on Lenovo > ThinkPad T14s Gen 1 with Intel Core i7-10610U. > 2) Search for „Error“ in the output of dmesg. > 3) Find > ACPI Error: Needed [Integer/String/Buffer], found [Package] 0b621212 > (20200925/exresop-469) > [ 4.387053] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for > [OpcodeName unavailable] (20200925/dswexec-431) > [ 4.387198] ACPI Error: Aborting method \ADBG due to previous error > (AE_AML_OPERAND_TYPE) (20200925/psparse-529) > [ 4.387346] ACPI Error: Aborting method \_SB.HIDD._DSM due to previous error > (AE_AML_OPERAND_TYPE) (20200925/psparse-529) > [ 4.387486] ACPI: \_SB_.HIDD: failed to evaluate _DSM (0x3003) > The anonymized prefix of the dmesg output till this error is attached. > Now, since we see an “error”, we wonder what exactly goes wrong. How do we > translate this into plain English? What exactly should we worry about? These might indicate a firmware issue, cf. eg. the older https://bugzilla.kernel.org/show_bug.cgi?id=199983 . Can you please check if there are further firwmare updates available for your device from Lenovo? Regards, Salvatore
Bug#1026870: linux-image-6.0.0-6-amd64 - significant performance degradation
Hi, On Thu, Dec 22, 2022 at 10:20:44PM +0100, Kamila Szewczyk wrote: > Package: src:linux > Version: 6.0.12-1 > Severity: important > X-Debbugs-Cc: kspalaiolo...@gmail.com > > Dear Maintainer, > > I have recently upgraded my Linux kernel to package version 6.0.12-1 > (6.0.0-6) from version 6.0.8 (6.0.0-4). Since then I am experiencing > significant performance degradation. I have tried to observe the > cause of it using the `perf' tool, however, I haven't had any luck > with this so far, and the kernel has been logging the following > messages throughout the procedure: > > >>> > Message from syslogd@laplace at Dec 22 21:51:20 ... > kernel:[ 5212.738589] Uhhuh. NMI received for unknown reason 2d on CPU 9. > > Message from syslogd@laplace at Dec 22 21:51:20 ... > kernel:[ 5212.738607] Dazed and confused, but trying to continue > > Message from syslogd@laplace at Dec 22 21:51:21 ... > kernel:[ 5214.422563] Uhhuh. NMI received for unknown reason 2d on CPU 7. > > Message from syslogd@laplace at Dec 22 21:51:21 ... > kernel:[ 5214.422582] Dazed and confused, but trying to continue > <<< > > So far I have observed that returning to the previously installed > kernel version solves most of my problems. I have also compared the > execution times using `perf' on both of the kernels. > > New kernel: > <<< > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > E: Unable to locate package asdfghjkl > > Performance counter stats for 'apt install asdfghjkl': > > 2,409.28 msec task-clock #0.999 CPUs > utilized > 11 context-switches #4.566 /sec > 4 cpu-migrations #1.660 /sec > 2,526 page-faults #1.048 K/sec >961,017,382 cycles #0.399 GHz >(83.39%) > 15,353,337 stalled-cycles-frontend #1.60% frontend > cycles idle (83.40%) >226,730,321 stalled-cycles-backend # 23.59% backend > cycles idle (83.40%) > 2,018,766,682 instructions #2.10 insn per > cycle > #0.11 stalled cycles > per insn (83.39%) >383,290,701 branches # 159.089 M/sec >(83.35%) > 1,819,464 branch-misses#0.47% of all > branches (83.24%) > >2.411797623 seconds time elapsed > >2.349918000 seconds user >0.062534000 seconds sys > >>> > > Old kernel: > <<< > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > E: Unable to locate package asdfghjkl > > Performance counter stats for 'apt install asdfghjkl': > > 852.22 msec task-clock #0.940 CPUs > utilized >392 context-switches # 459.975 /sec > 3 cpu-migrations #3.520 /sec > 2,548 page-faults #2.990 K/sec > 1,172,831,665 cycles #1.376 GHz >(83.08%) > 43,524,987 stalled-cycles-frontend #3.71% frontend > cycles idle (83.76%) >412,509,320 stalled-cycles-backend # 35.17% backend > cycles idle (82.83%) > 2,060,235,707 instructions #1.76 insn per > cycle > #0.20 stalled cycles > per insn (83.60%) >396,100,764 branches # 464.786 M/sec >(83.18%) > 1,892,879 branch-misses#0.48% of all > branches (83.77%) > >0.906939283 seconds time elapsed > >0.795226000 seconds user >0.059521000 seconds sys > >>> > > If there is any troubleshooting or important information > I could provide, please let me know. > > I have noticed that the clock speeds tend to be much lower > on the new Linux kernel, however, I don't know the cause of it. > All the system data (including e.g. CPU governor configuration) > stays the same. As we will soonish move to the 6.1.y series (which as LTS kernel upstream is aimed to be the one we will use for bookworm), do you observe the same regression when moving to the kernel available in experimental? (Ideally test the just uploaded 6.1.1-1~exp1 once it is built). If it is still reproducible with latest kernel, would you be able to bisect the changes between 6.0.8 and 6.0.12 to isolate the change introducing the regression for you? The following resource might be helpful for the later case: https://wiki.debian.org/DebianKernel/GitBisect Regards, Salvatore
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Floris, On Sat, Dec 17, 2022 at 01:26:27PM +0100, Floris Bruynooghe wrote: > Hi Salvatore, > > On Fri 16 Dec 2022 at 22:54 +0100, Salvatore Bonaccorso wrote: > > On Fri, Dec 16, 2022 at 10:34:08PM +0100, Floris Bruynooghe wrote: > >> On Fri 16 Dec 2022 at 21:50 +0100, Salvatore Bonaccorso wrote: > >> > On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: > >> >> Package: src:linux > >> >> Version: 6.0.10-2 > >> >> Severity: important > >> >> > >> >> Dear Maintainer, > >> >> > >> >> Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. > >> >> Downgrading to the 6.0.0-4 kernel fixes it and the driver works > >> >> flawlessly across resume, changing displays etc. > >> >> > >> >> On the -5 kernel the following errors are observed when the driver > >> >> crashes: > >> >> > >> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 > >> >> should not be sleeping > >> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 > >> >> should not be sleeping > >> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 > >> >> should not be sleeping > >> >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* > >> >> Sending link address failed with -5 > >> >> Dec 13 11:26:58 fredriksen kernel: [ cut here ] > >> >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > >> >> drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) > >> >> Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > >> >> drivers/gpu/drm/i915/display/intel_tc.c:711 int> > >> >> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm > >> >> rfcomm cmac algif_hash algif_skcipher af_alg> > >> >> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic > >> >> snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> > >> >> Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables > >> >> x_tables autofs4 btrfs blake2b_generic libcrc32c> > >> >> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: > >> >> kworker/u32:101 Not tainted 6.0.0-5-amd64 #1 Debian > > >> >> Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO > >> >> 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 > >> >> Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound > >> >> async_run_entry_fn > >> >> Dec 13 11:26:58 fredriksen kernel: RIP: > >> >> 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] > >> >> Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c > >> >> 8b 2f e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> > >> >> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: > >> >> 00010286 > >> >> Dec 13 11:26:58 fredriksen kernel: RAX: RBX: > >> >> 9c812065 RCX: > >> >> Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: > >> >> a4b7eeea RDI: > >> >> Dec 13 11:26:58 fredriksen kernel: RBP: R08: > >> >> a5262260 R09: a5b5348a > >> >> Dec 13 11:26:58 fredriksen kernel: R10: R11: > >> >> 004a R12: 9c81101a2000 > >> >> Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: > >> >> R15: 9c81101a2000 > >> >> Dec 13 11:26:58 fredriksen kernel: FS: () > >> >> GS:9c883f40() knlGS: > >> >> Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: > >> >> 80050033 > >> >> Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: > >> >> 0002db810003 CR4: 00770ef0 > >> >> Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 > >> >> Dec 13 11:26:58 fredriksen kernel: Call Trace: > >> >> Dec 13 11:26:58 fredriksen kernel: > >> >> Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 > >> >> [i915] > >> >> Dec 13 11:26:58 fredriksen kernel: > >> >> intel_m
Bug#1026391: SMU binary missing from AMD firmware update
Control: tags -1 + confirmed pending Hi, On Mon, Dec 19, 2022 at 02:09:47PM +0100, Aigars Mahinovs wrote: > Package: firmware-amd-graphics > Version: 20221214-1 > Severity: important > > Despite > https://metadata.ftp-master.debian.org/changelogs//non-free/f/firmware-nonfree/firmware-nonfree_20221214-1_changelog > mentioning "amdgpu: add SMU 13.0.0 firmware for amd-5.4" > and the andgpu/smu_13_0_0.bin file being available in the upstream > release, the corresponding file /lib/firmware/amdgpu/smu_13_0_0.bin is > not part of > http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-amd-graphics_20221214-1_all.deb > > This causes boot failures for Debian sid users with AMD Radeon RX 7900 > XT(X) video cards. As mentioned in > https://www.reddit.com/r/debian/comments/zp7qyw/amd_radeon_rx_7900_xt_xtx_should_it_work_now_on/ When prepared the update I aimed to split the changes upstream wich do not require a packaging change and those with packaging changes, but missed to actually do the correct thing for the SMU 13.0.0 firmware. Fixed in git https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/2d705025066fb518ba7a84107e674f520814076f and will be in the next upload. Regards, Salvatore
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Floris, On Fri, Dec 16, 2022 at 10:34:08PM +0100, Floris Bruynooghe wrote: > Hi Salvatore, > > On Fri 16 Dec 2022 at 21:50 +0100, Salvatore Bonaccorso wrote: > > > Hi Floris, > > > > On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: > >> Package: src:linux > >> Version: 6.0.10-2 > >> Severity: important > >> > >> Dear Maintainer, > >> > >> Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. > >> Downgrading to the 6.0.0-4 kernel fixes it and the driver works > >> flawlessly across resume, changing displays etc. > >> > >> On the -5 kernel the following errors are observed when the driver > >> crashes: > >> > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should > >> not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 > >> should not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 > >> should not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* > >> Sending link address failed with -5 > >> Dec 13 11:26:58 fredriksen kernel: [ cut here ] > >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > >> drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) > >> Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > >> drivers/gpu/drm/i915/display/intel_tc.c:711 int> > >> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm > >> cmac algif_hash algif_skcipher af_alg> > >> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic > >> snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> > >> Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables > >> autofs4 btrfs blake2b_generic libcrc32c> > >> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 > >> Not tainted 6.0.0-5-amd64 #1 Debian > > >> Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO > >> 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 > >> Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound > >> async_run_entry_fn > >> Dec 13 11:26:58 fredriksen kernel: RIP: > >> 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] > >> Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b > >> 2f e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> > >> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: > >> 00010286 > >> Dec 13 11:26:58 fredriksen kernel: RAX: RBX: > >> 9c812065 RCX: > >> Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: > >> a4b7eeea RDI: > >> Dec 13 11:26:58 fredriksen kernel: RBP: R08: > >> a5262260 R09: a5b5348a > >> Dec 13 11:26:58 fredriksen kernel: R10: R11: > >> 004a R12: 9c81101a2000 > >> Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: > >> R15: 9c81101a2000 > >> Dec 13 11:26:58 fredriksen kernel: FS: () > >> GS:9c883f40() knlGS: > >> Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: > >> 80050033 > >> Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: > >> 0002db810003 CR4: 00770ef0 > >> Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 > >> Dec 13 11:26:58 fredriksen kernel: Call Trace: > >> Dec 13 11:26:58 fredriksen kernel: > >> Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] > >> Dec 13 11:26:58 fredriksen kernel: > >> intel_modeset_setup_hw_state+0x3b1/0x1410 [i915] > >> Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 > >> Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 > >> Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] > >> Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 > >> Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 > >> [i915] > >> Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] > >> Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] > >> Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] >
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Floris, On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: > Package: src:linux > Version: 6.0.10-2 > Severity: important > > Dear Maintainer, > > Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. > Downgrading to the 6.0.0-4 kernel fixes it and the driver works > flawlessly across resume, changing displays etc. > > On the -5 kernel the following errors are observed when the driver > crashes: > > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* Sending > link address failed with -5 > Dec 13 11:26:58 fredriksen kernel: [ cut here ] > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) > Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > drivers/gpu/drm/i915/display/intel_tc.c:711 int> > Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm > cmac algif_hash algif_skcipher af_alg> > Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic > snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> > Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables > autofs4 btrfs blake2b_generic libcrc32c> > Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 > Not tainted 6.0.0-5-amd64 #1 Debian > > Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO > 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 > Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound > async_run_entry_fn > Dec 13 11:26:58 fredriksen kernel: RIP: > 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] > Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f > e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> > Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: 00010286 > Dec 13 11:26:58 fredriksen kernel: RAX: RBX: > 9c812065 RCX: > Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: > a4b7eeea RDI: > Dec 13 11:26:58 fredriksen kernel: RBP: R08: > a5262260 R09: a5b5348a > Dec 13 11:26:58 fredriksen kernel: R10: R11: > 004a R12: 9c81101a2000 > Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: > R15: 9c81101a2000 > Dec 13 11:26:58 fredriksen kernel: FS: () > GS:9c883f40() knlGS: > Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: > 80050033 > Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: > 0002db810003 CR4: 00770ef0 > Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 > Dec 13 11:26:58 fredriksen kernel: Call Trace: > Dec 13 11:26:58 fredriksen kernel: > Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] > Dec 13 11:26:58 fredriksen kernel: intel_modeset_setup_hw_state+0x3b1/0x1410 > [i915] > Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 > Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 > Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] > Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 > Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 [i915] > Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] > Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] > Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] > Dec 13 11:26:58 fredriksen kernel: ? pci_pm_poweroff_noirq+0x100/0x100 > Dec 13 11:26:58 fredriksen kernel: dpm_run_callback+0x47/0x150 > Dec 13 11:26:58 fredriksen kernel: device_resume+0x88/0x190 > Dec 13 11:26:58 fredriksen kernel: async_resume+0x19/0x30 > Dec 13 11:26:58 fredriksen kernel: async_run_entry_fn+0x2d/0x130 > Dec 13 11:26:58 fredriksen kernel: process_one_work+0x1c4/0x380 > Dec 13 11:26:58 fredriksen kernel: worker_thread+0x4d/0x380 > Dec 13 11:26:58 fredriksen kernel: ? rescuer_thread+0x3a0/0x3a0 > Dec 13 11:26:58 fredriksen kernel: kthread+0xe6/0x110 > Dec 13 11:26:58 fredriksen kernel: ? kthread_complete_and_exit+0x20/0x20 > Dec 13 11:26:58 fredriksen kernel: ret_from_fork+0x1f/0x30 > Dec 13 11:26:58 fredriksen kernel: > Dec 13 11:26:58 fredriksen kernel: ---[ end trace ]--- > Dec 13 11:26:58 fredriksen kernel: [ cut here ] > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > drm_WARN_ON(dig_port->tc_lock_wakeref) > Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > drivers/gpu/drm/i915/display/intel_tc.c:712 int> > Dec 13
Bug#1026174: linux: Please enable CONFIG_X86_SGX_KVM=y
Hi, On Thu, Dec 15, 2022 at 10:54:22PM +0100, Wojtek Porczyk wrote: > Source: linux > Severity: normal > > Dear Maintainer, > > Please consider CONFIG_X86_SGX_KVM=y config option. This option enables using > SGX inside KVM virtual machines. Support for this landed in qemu around 7.0 > (I don't recall the exact version) and in libvirt 8.10. So I assume with libvirt 8.10. beeing in bookworm as well in meanwhile, the whole stack is functional/working? Out of interest, you were able to test it? Regards, Salvatore
Re: Compatibility between kernel and modules
Hi Bastian, Thanks for raising the topic. On Sat, Dec 10, 2022 at 02:27:12PM +0100, Bastian Blank wrote: > Hi > > Our documented, I think, policy is, that we don't support loading new > modules into an old kernel within the same ABI. This forces a reboot > after kernel installation. > > However in a lot of cases this just worked. You could update the kernel > package and continue loading most modules. > > Now we have BTF support enabled, which trashes this compatibility > mostly, as it requires a way more strict match between kernel image and > modules. > > We need to fix that somehow. Options are as far as I see > - remove BTF from modules, > - allow to load modules even on BTF mismatch, or > - reinforce that a user can't do that. > > If we go with the last option we would have also some direct advantages. > We could stop signing modules with the secure boot key, but use a > temporary key. This would for a system with signature checking enabled > effectively trash all possibilities to load modules for a different > kernel build. > > This would do directly for use: > - A way faster build, as we don't longer require multi-10k signatures, > but only a handfull, from the HSM. > - We might be forced by shim/UEFI to support SBAT if we load secure boot > signed stuff. If we just need to revoke the complete kernel, SBAT on > the kernel itself is enough. > - We can do pre-built initramfs and unified image without two rounds in > the signing service. > - We fix the current signatures without certificate chain, but which are > still chained to the Debian secure boot CA. (sign-file simply can't > handle cert chains, while the kernel itself can check them on loading.) > > What should we do? I do agree we have to handle this before the bookworm release. Most of the time it was a non-issue but only due to the fact that an ABI bump was the most sensible next step for the upload (recent stable updates have enough changes per release which makes as well easier rollback for users in case of issues). So at least in my case I almost every time bumped ABI, but every time we do not a report about the BTF mismatch problem get reported. That said, I'm not sure what we should do. Ben? Salvatore
Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u
Source: linux Source-Version: 5.10.158-2 Hi Adi, On Tue, Dec 13, 2022 at 03:40:04PM +0100, Adi Kriegisch wrote: > Source: linux > Version: 5.10.158-1 > > Dear maintainers, > > we just upgraded our xen test cluster's kernel to the latest kernel from > s-p-u and noticed that network communication is broken. We do have a > 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no > communication is possible for the domU. > > We can see packets arrive at the domU and packets leave the domU; but they > never arrive at the virtual interface in dom0 (rx counter stays at 0 and error > counters stay at 0 too). > > When migrating the domU back to the other server which has not been > upgraded, the machine is reachable again. > > If there is anything we can do to help fixing that issue, we'll gladly do > that! > > Thank you very much! This is adressed with a subsequent upload which should hit the archive soon and hopefully in time for the point release (I did miss to close this bug with the upload, doing so manually to have proper version tracking). Regards, Salvatore
Bug#1026028: Qualcomm NFA725A not working on firmware-linux-nonfree 20221109-4
Control: tags -1 + moreinfo
Hi,
On Tue, Dec 13, 2022 at 02:12:24PM +0100, Tarek Saier wrote:
> Package: firmware-linux-nonfree
> Version: 20221109-4
> Severity: important
>
> Dear Maintainer,
>
> same as the reporter of #1021157, I am also using a ThinkPad T14s Gen3
> with the Qualcomm NFA725A wifi card ("Qualcomm Wi-Fi 6E NFA725A 11AX
> (2x2) & Bluetooth(R) 5.0" reported in lshw as "QCNFA765 Wireless
> Network Adapter").
>
> On a fresh install of Debian 12 from the current ISO
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bookworm_di_alpha1+nonfree/amd64/iso-cd/
> no wireless card is detected. After updating packages, installing
> firmware-linux-nonfree, and rebooting, Debian tries to load firmware
> (ath11k/WCN6855.hw2.1/amss.bin) but this fails.
>
> dmesg output:
> [2.635425] mhi mhi0: firmware: failed to load
> ath11k/WCN6855/hw2.1/amss.bin (-2)
> [2.635435] firmware_class: See https://wiki.debian.org/Firmware
> or information about missing firmware
> [2.635444] mhi mhi0: firmware: failed to load
> ath11k/WCN6855/hw2.1/amss.bin (-2)
> [2.635448] mhi mhi0: Direct firmware load for
> ath11k/WCN6855/hw2.1/amss.bin failed with error -2
> [2.635451] mhi mhi0: Error loading firmware: -2
> [2.635493] ath11k_pci :01:00.0: failed to power up mhi: -110
> [2.635499] ath11k_pci :01:00.0: failed to start mhi: -110
> [2.635506] ath11k_pci :01:00.0: failed to power up :-110
>
> Given that bug report #1021157 was closed with
> - firmware-nonfree (20221012-1) unstable
> and I am running
> - firmware-nonfree 20221109-4 on testing
> I assumed the card should work. If I'm missing something please let me know.
The firmware is contained in the firmware-atheros package:
firmware-atheros: /lib/firmware/ath11k/WCN6855/hw2.1/amss.bin
Do you have that one installed as well?
Regards,
Salvatore
Bug#1025537: nfsd: Kernel Oops while serving NFS
Hi Olivier, On Sun, Dec 11, 2022 at 12:01:31AM +1100, Olivier Mehani wrote: > Hi Salvatore, > > On Fri 09 Dec 2022 at 22:22:49 +0100, Salvatore Bonaccorso wrote: > > > On testing/bookworm, since booting on a 6-versioned linux-image, I have > > > noticed frequent hang ups of the nfs server, rendering it mostly > > > unusable. This is accompanied with Kernel Oops in the dmesg. > > > This sounds similar to previous bugs #1014793 and #1020548, both RESOLVED > > > by > > > later patches. > > How easy can you trigger and reproduce the issue? If you can easily > > reach that situation, can you try to bisect the issue? Easiest would > > be to first pin point between Debian revisions, and later further > > bisect in upstream stable series. > > Do you have the possibility to do that? > > It seems to be fairly reliable. > > I'll give that a go, starting with > * linux-image-5.19.0-2-amd64_5.19.11-1_amd64.deb > * linux-image-6.0.0-1-amd64_6.0.2-1_amd64.deb Great, thanks. > I'm not certain how to bisect further. Which source and which kconfig should > I use to build intermediate commits? Does the following reference helps you further? https://wiki.debian.org/DebianKernel/GitBisect Thanks for taking time for pinpointing your issue. Regards, Salvatore
Bug#1017869: nfs-utils: nfs-common and nfs-kernel-server initscripts are /bin/bash and shellcheck-dirty
Hi, On Sun, Aug 21, 2022 at 10:12:42PM +0200, наб wrote: > Source: nfs-utils > Version: 1:1.3.4-6 > Severity: minor > Tags: patch > > Dear Maintainer, > > See subject; also, neither of them use any bash extensions. > > Please consider the patch, below, based on current Salsa HEAD; > this may also close #762939. For changing to #!/bin/sh, as Ben explained in #762939: This is true, but it sources /etc/default/nfs-common which could contain bashisms. I don't think this is worth the risk. The same holds here for changing the scripts to #!/bin/sh. Regards, Salvatore
Bug#1025537: nfsd: Kernel Oops while serving NFS
Hi Olivier, On Tue, Dec 06, 2022 at 10:54:31PM +1100, Olivier Mehani wrote: > Package: src:linux > Version: 6.0.10-1 > Severity: important > File: nfsd > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > On testing/bookworm, since booting on a 6-versioned linux-image, I have > noticed frequent hang ups of the nfs server, rendering it mostly > unusable. This is accompanied with Kernel Oops in the dmesg. > > This sounds similar to previous bugs #1014793 and #1020548, both RESOLVED by > later patches. How easy can you trigger and reproduce the issue? If you can easily reach that situation, can you try to bisect the issue? Easiest would be to first pin point between Debian revisions, and later further bisect in upstream stable series. Do you have the possibility to do that? Regards, Salvatore
Uploading linux (6.0.12-1)
Hi I would like to upload linux version 6.0.12-1 to unstable either today or tomorrow. It includes a rebase to the 6.0.12 stable release which includes as well fixes for CVE-2022-45869, CVE-2022-3344 and CVE-2022-3435. (Speaking of CVEs, fixes for XSA-423, CVE-2022-3643, and for XSA-424, CVE-2022-42328, CVE-2022-42329 are cherry-picked as well. An ABI bump is included. Additional changes are: * [rt] Refresh "serial: 8250: implement write_atomic" * Bump ABI to 6 * [s390x] debian/config: Drop explicit enable of RELOCATABLE. * [x86] drivers/cpufreq: Change X86_AMD_PSTATE from module to built-in * xen/netback: Ensure protocol headers don't fall in the non-linear area (XSA-423, CVE-2022-3643) * xen/netback: don't call kfree_skb() with interrupts disabled (XSA-424, CVE-2022-42328, CVE-2022-42329) Regards, Salvatore signature.asc Description: PGP signature
Bug#1021391: Possible solution with kernel 6.0.11
Hi Bernhard, On Mon, Dec 05, 2022 at 12:21:48PM +, Bernhard wrote: > Hello Salvatore > > It is possible, that kernel 6.0.11 solves the Bug #1021391 because of > > >>> > - [arm64,armhf] bus: sunxi-rsb: Remove the shutdown callback > - [arm64,armhf] bus: sunxi-rsb: Support atomic transfers > <<< > > If i have a look at the ARM kernel mailinglist, there are bugfixes for this > I2C: > > >>> > Shutting down the RSB controller prevents communicating with a PMIC > inside pm_power_off(), so it breaks system poweroff on some boards. > <<< > > >>> > This series fixes a couple of issues that occur when powering off a > board using a PMIC attached to the RSB bus. > > These issues only affected 32-bit platforms, because 64-bit platforms > use PSCI for pm_power_off(), and the PSCI firmware reinitializes the > RSB controller. > <<< > > >>> > When communicating with a PMIC during system poweroff (pm_power_off()), > IRQs are disabled and we are in a RCU read-side critical section, so we > cannot use wait_for_completion_io_timeout(). Instead, poll the status > register for transfer completion. > <<< > > Is it planned, to release this kernel in the next days? > I'm really very interested in testing. I was pondering it actually, and the changes are waiting in the sid branch, but wanted to include the changes of upcoming 6.0.12 as well in the next update. Regards, Salvatore
Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel
Hi Louis,
On Tue, Nov 29, 2022 at 09:05:48AM +0100, Louis Bouchard wrote:
> Hello Salvatore,
>
> Le 28/11/2022 à 19:22, Salvatore Bonaccorso a écrit :
> > Hi Louis,
> >
> > The rough plan would be to have it included in the next bullseye point
> > release. That is scheduled to be on 17th of december[1]. It would be
> > great to recieve testing feedback actually on the change.
> >
> > [1] https://lists.debian.org/debian-live/2022/11/msg6.html
> >
> > Regards,
> > Salvatore
>
> Thank you for your quick & precise answer. I really appreciate.
One concern to enable CONFIG_AMD_MEM_ENCRYPT would be what earlier
resulted in #994453. But the good thing is at least that 711885906b5c
("x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
automatically") was backported to 5.10.y as well to 5.10.75, and this
has not changed since.
So as long we do not enable it by default it might still be sensible
to make the change for the next point release.
Regards,
Salvatore
Bug#1025132: firmware-linux: Missing firmware for Intel AX201
Hi, On Wed, Nov 30, 2022 at 03:05:28AM +0100, TeoCol wrote: > Package: firmware-linux > Version: 20221109-2 > Severity: normal > X-Debbugs-Cc: teodoro777.coluc...@live.com > > Dear Maintainer, > > After performing a clean install of debian testing, installing the proprietary > firmware, everything works fine, except bluetooth. > This is caused by lack of firmware to handle the device. > Indeed dmesg reports: > "[ 5.655154] Bluetooth: hci0: Failed to load Intel firmware file > intel/ibt-0040-4150.sfi (-2)" > As far as I've found, the drivers are present upstream: > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- > firmware.git/tree/intel. > Hope this can help. I have uploaded a new version including this one, https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/5894870eccac67e81fa0a0f47e10a8b55add12e7 . Can you specify what is the device in question? Regards, Salvatore
Uploading linux (6.0.10-2)
Hi I would like to upload linux version 6.0.10-2 to unstable later today with one single change: * [x86] drm/i915: fix TLB invalidation for Gen12 video and compute engines (CVE-2022-4139) For that no ABI change required. It will soon be followed by 6.0.11-1 or later though. Regards, Salvatore signature.asc Description: PGP signature
Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel
Hi Louis, On Mon, Nov 28, 2022 at 10:19:16AM +0100, Louis Bouchard wrote: > Hello Salvatore, > > > I will likely pick that change as well for the next 5.10.y based > > upload via the upcoming point release (it might count as "enabling > > furhter hardware support" allowed for stable release updates). > > > > Regards, > > Salvatore > > This is a very good news. > > Would you happen to have an idea on the timetable for the availability of > the upcoming 5.10 kernel ? > > I am currently working on building a custom kernel with this option enabled > so we can make Bullseye available again on our SEV enabled offer until the > backport becomes available. If it is expected to happen soon, we may elect > to wait for an official kernel. The rough plan would be to have it included in the next bullseye point release. That is scheduled to be on 17th of december[1]. It would be great to recieve testing feedback actually on the change. [1] https://lists.debian.org/debian-live/2022/11/msg6.html Regards, Salvatore
Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel
Hi Luis, On Wed, Nov 23, 2022 at 11:59:23AM +0100, Louis Bouchard wrote: > Package: src:linux > Version: 5.10.149-2 > Severity: important > X-Debbugs-Cc: lbouch...@scaleway.com > > Dear Kernel team, > > A fix for bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989040 is > included in kernel 5.13 but still not available for the stable kernel. > > Could you please backport the fix for that bug into the stable 5.10 kernel > so it becomes available in a standard Debian Bullseye installation. Without > this fix, Debian Bullseye is unbootable in > a virtual machine which uses Secure Enhanced Virtualization (SEV). > > The fix is the enablement of the CONFIG_AMD_MEM_ENCRYPT configuration > option. I will likely pick that change as well for the next 5.10.y based upload via the upcoming point release (it might count as "enabling furhter hardware support" allowed for stable release updates). Regards, Salvatore
Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds
Control: tags -1 + moreinfo On Fri, Jun 14, 2019 at 03:48:02PM +0200, Thorsten Glaser wrote: > Package: linux-image-4.19.0-5-amd64 > Version: 4.19.37-3 > Severity: important > > We’re back to tasks hanging, 99% of CPU being in wait. > This is somewhat similar to #913138 but not identical: > HDD reads seem to still work, as do some new writes, > but not all of them (e.g. I can run reportbug, but not > “man reportbug”; I can start new shells, which call > ansiweather and store the result, but I cannot run a > new Firefox instance; I can run sudo dmesg (below), > but not zless the linux-image-4.19.0-5-amd64 changelog). Is this issue still reproducible with a recent kernel? Regards, Salvatore
Uploading linux (6.0.10-1)
Hi, I would like to upload linux version 6.0.10-1 to unstable later today. It includes a rebase to the 6.0.10 stable release and including fixes for CVE-2022-3169, CVE-2022-3521 (not affecting binary packages built as option not enabled in Debian) and #1023025. An ABI bump is included. Additional changes are: * net/cdc_ncm: Fix multicast RX support for CDC NCM devices with ZLP (Closes: #1024328) * net: neigh: decrement the family specific qlen (Closes: #1024070) Regards, Salvatore signature.asc Description: PGP signature
Bug#1024802: updated amd firmware breaks (some) display output
Control: tags -1 + moreinfo Hi Timothy, On Fri, Nov 25, 2022 at 08:03:51AM -0500, Timothy L. Mieszkowski wrote: > Package: firmware-amd-graphics > Version: 20221109-2 > > After upgrading to bookworm the display output for some monitors shows no > output. There are no errors and the system is working headless. > Tried on: Display Port monitor -- doesn't work no output >non-smart tv -- doesn't work no output > hdmi smart tv -- works > > motherboard: mag tomahawk b550 wifi motherboard > gpu : amd rx6500 xt 4gb > cpu: ryzen 7 5800x > > kernel: > Linux debian 6.0.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.8-1 > (2022-11-11) x86_64 GNU/Linux > > lspci: > 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > Root Complex > 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU > 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP > Bridge > 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP > Bridge > 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP > Bridge > 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > Internal PCIe GPP Bridge 0 to bus[E:B] > 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > PCIe Dummy Host Bridge > 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > Internal PCIe GPP Bridge 0 to bus[E:B] > 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev > 61) > 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev > 51) > 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 0 > 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 1 > 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 2 > 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 3 > 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 4 > 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 5 > 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 6 > 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer > Data Fabric: Device 18h; Function 7 > 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD > Controller PM9A1/PM9A3/980PRO > 02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 500 Series > Chipset USB 3.1 XHCI Controller > 02:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 500 Series > Chipset SATA Controller > 02:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] 500 Series Chipset > Switch Upstream Port > 03:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43ea > 03:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43ea > 29:00.0 Network controller: MEDIATEK Corp. MT7921K (RZ608) Wi-Fi 6E 80MHz > 2a:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE > Controller (rev 05) > 2b:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL > Upstream Port of PCI Express Switch (rev c1) > 2c:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL > Downstream Port of PCI Express Switch > 2d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Navi 24 [Radeon RX 6400/6500 XT/6500M] (rev c1) > 2d:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 > HDMI/DP Audio Controller > 2e:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. > [AMD] Starship/Matisse PCIe Dummy Function > 2f:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. > [AMD] Starship/Matisse Reserved SPP > 2f:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] > Starship/Matisse Cryptographic Coprocessor PSPCPP > 2f:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 > Host Controller > 2f:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse > HD Audio Controller >From the report is not entirely clear to me if you only updated firmware-amd-graphics to the bookworm version (20221109-2) or updating the system
Re: Bug#1024082: Bug#1022172: Bug#1024082: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
Hi Marco, On Mon, Nov 14, 2022 at 07:06:30PM +0100, Marco d'Itri wrote: > > Try something like this in /lib/udev/rules.d/60-nfs.rules: > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", \ > RUN+="/sbin/sysctl -q --pattern ^sunrpc --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="rpcrdma", \ > RUN+="/sbin/sysctl -q --pattern ^sunrpc.svc_rdma --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="lockd", \ > RUN+="/sbin/sysctl -q --pattern ^fs.nfs.n[sl]m --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfsv4", \ > RUN+="/sbin/sysctl -q --pattern > ^fs.nfs.(nfs_callback_tcpport|idmap_cache_timeout) --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfs", \ > RUN+="/sbin/sysctl -q --pattern ^fs.nfs --system" > > Differently from the original file I tired anchoring the patterns, which > looks more correct to me. I have posted the patch(es) upstream implementing your proposal at https://lore.kernel.org/linux-nfs/20221125130725.1977606-1-car...@debian.org/T/ . Regards, Salvatore
Bug#1024753: libvirtd doesn't run: "SCHED_CORE not supported by kernel"
Control: reassign -1 src:libvirt 8.9.0-1
On Thu, Nov 24, 2022 at 10:10:49AM +0100, Philipp Marek wrote:
> Package: src:linux
> Version: 6.0.8-1
> Severity: important
> X-Debbugs-Cc: phil...@marek.priv.at
>
>
> Sorry about the German messages.
>
> libvirt version: 8.9.0, package: 1 (Andrea Bolognani
> Sat, 19 Nov 2022 23:00:34 +0100)
>
> Nicht unterstützte Konfiguration: SCHED_CORE not supported by kernel
> Initialisierung des QEMU Status-Treibers fehlgeschlagen: Nicht
> unterstützte Konfiguration: SCHED_CORE not supported by kernel
> Treiber Status Initialisierung fehlgeschlagen
>
> My libvirt-daemon is 8.9.0-1; downgrading to 8.5.0-1 makes it work
> again, should the error be reported against that one,
> or does it make sense to recompile the kernel with that config?
Doing for now the reassignment to src:libvirt. In fact SCHED_CORE has
been disabled by default with upstream commit, d2343cb8d154
("sched/core: Disable CONFIG_SCHED_CORE by default"), in v5.14-rc1:
| commit d2343cb8d154fe20c4499711bb3a9af2095b2b4b
| Author: Ingo Molnar
| Date: Mon Jun 28 21:55:16 2021 +0200
|
| sched/core: Disable CONFIG_SCHED_CORE by default
|
| This option at minimum adds extra code to the scheduler - even if
| it's default unused - and most users wouldn't want it.
|
| Reported-by: Linus Torvalds
| Signed-off-by: Ingo Molnar
|
| diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
| index bd7c4147b9a8..5876e30c5740 100644
| --- a/kernel/Kconfig.preempt
| +++ b/kernel/Kconfig.preempt
| @@ -102,7 +102,6 @@ config PREEMPT_DYNAMIC
|
| config SCHED_CORE
| bool "Core Scheduling for SMT"
| - default y
| depends on SCHED_SMT
| help
| This option permits Core Scheduling, a means of coordinated task
| @@ -115,7 +114,8 @@ config SCHED_CORE
| - mitigation of some (not all) SMT side channels;
| - limiting SMT interference to improve determinism and/or
performance.
|
| - SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
| - unused there should be no impact on performance.
| + SCHED_CORE is default disabled. When it is enabled and unused,
| + which is the likely usage by Linux distributions, there should
| + be no measurable impact on performance.
I have not checked what other distributions do, but given the above it
looks to me that we are doing already the okayish thing for
distributions. Libvirt-maintainers, what is your take on it?
How is your /etc/libvirt/qemu.conf configured with respect to the
"sched_core" setting?
Regards,
Salvatore
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Hi Kevin, On Mon, Nov 21, 2022 at 04:49:16PM -0500, Kevin P. Fleming wrote: > On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote: > > On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote: > > > >> If that would be helpful, we have some instructions on "simple > >> patching and building" the kernel with a additional patches on top > >> here: > >> > >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > > > I found those via another path, and used them :-) Had a few little > > issues along the way: failing to set DEBFULLNAME produces a broken > > changelog entry so then the build won't run (and leaves the tree in a > > broken state as well). Once I solved that problem I was able to make > > packages, but the linux-headers-common package didn't get produced, so > > I had to use --force-depends-version when installing the packages > > (which I knew was safe since the headers had not changed). > > > > I now have the patched kernel in operation and should know whether the > > problem is solved in 24-48 hours. > > It's been more than 24 hours and connectivity is still in place, and > it never lasted this long without the patch. I'm comfortable saying > that this patch resolved the problem. Thanks for testing. I will try to make it included in the next unstable upload (waiting for 6.0.10 which should come around friday). Regards, Salvatore
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Hi Stuart, Thanks for the report! On Wed, Nov 23, 2022 at 06:31:48PM +, Stuart Hayhurst wrote: > Source: linux > Version: 5.19.6-1 > Severity: important > Tags: patch upstream > X-Debbugs-Cc: stuart.a.hayhu...@gmail.com > > Dear Maintainer, > > The Samsung PM9B1 misreports its NID when resuming from sleep, > causing the root filesystem to be unmounted, and the system left in > an unstable state. Mostly this results in the device crashing, but > if the device somehow continues running, it's incredibly unstable, > where basically nothing works. It's an OEM drive found in some newer > laptops (like my Lenovo Yoga 7 Gen 7) > There's a bug report and patch upstream for this, but personally I > think it might be a good idea to include it in Debian until it's > accepted, as machines with this drive are near-unusable. > Upstream issue: > https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ > I've tested the patch against the current Debian 6.1-rc5 kernel on > my laptop, and this fixes the problem without any other issues. On the other hand, we only should include it once we are fairly confident that upstream accepts the fix and will include. Can you ping this bug once upstream maintainers have acked the change and queued it? If you have tested the patch, then you can as well reply to the thread mentioning you sucessfully tested the patch adding a Tested-by tag. Regards, Salvatore
Bug#963025: fixed in firmware-nonfree 20210315-1~exp1
Source: firmware-nonfree Source-Version: 20221012-1 Hi On Mon, Nov 21, 2022 at 09:43:48PM +, Stefan Pietsch wrote: > On 08.04.21 11:50, Stefan Pietsch wrote: > > On 30.03.21 13:35, maximilian attems wrote: > > > reopen 963025 > > > found -1 20210315-2 > > > tags -1 moreinfo > > > stop > > > > > > > [18661.586025] CPU: 0 PID: 8408 Comm: hostapd Tainted: G W > > > > 5.10.0-5-amd64 #1 Debian 5.10.24-1 > > > > [18661.586029] Hardware name: LENOVO 20N2007GGE/20N2007GGE, BIOS > > > > N2IET81W (1.59 ) 11/29/2019 > > > > > > > > > Please could you upgrade the BIOS to latest for T490, 1.72 2021/03/17 > > > to exclude this guy fault. > > > > > > I upgraded the Lenovo T490 BIOS from 1.59 to 1.72. > > That did not make any difference. > > > I cannot reproduce this with firmware version 46.9d0122c0.0 > 9000-pu-b0-jf-b0-46.ucode from firmware-iwlwifi 20221012-1. This > seems to be fixed. Thanks for testing! The update which includes that firmware verison was AFAICS 20210716-1~exp1, but will still mark it with the above. There is as well 20221109-2 in unstable right now, which would migrate to testing in 2 days (including another update for the 9000-pu-b0-jf-b0-46.ucode to version 46.50fdb42f.0). Regards, Salvatore
Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)
Hi Diederik,
On Sun, Nov 20, 2022 at 04:26:45PM +0100, Diederik de Haas wrote:
> Control: notfound -1 4.9.88-1+deb9u1
> Control: found -1 4.9.88-1
Hmm this one I do not understand, as 4.9.88-1+deb9u1 was a very
targetted fix for two CVEs and reverting the "random: fix crng_ready()
test" changes re-opening CVE-2018-1108.
> On zondag 20 november 2022 13:55:09 CET Salvatore Bonaccorso wrote:
> > Seems the BSP was productive :).
>
> Yeah, once I set up the VM and created the script, it was actually quite easy.
:-)
> > If you have spare cycles, might you
> > check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
> > in 5.16-rc4 is the commit we are searching?
> > That one was backported to the 5.10.y series in 5.10.84 and in 5.15.y series
> > in 5.15.7 which would fall into your found ranges as well.
>
> IOW: that's your educated guess a git bisect could turn up?
Not really. I was more looking at between versions you are not able to
reproduce the issue, looking through the upstream changes commits and
noticing that dacb5d8875cc ("tcp: fix page frag corruption on page
fault") mentions:
[...]
Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.
[...]
and then noticing that the upstrema commit was backported to 5.10.84
an 5.15.7, which fall exactly in the ranges you have the switch of
result.
> I can try that*, although I'm not clear onto what I should apply it.
> Should I apply it to linux/5.10.70-1 or 5.10.46-4 f.e.? Or onto an entirely
> different version?
Basically I wonder if c6f340a331fb72e5ac23a083de9c780e132ca3ae in
5.10.84 fixes the issue, and
c6f340a331fb72e5ac23a083de9c780e132ca3ae~1 still would show the
problem.
Alterntively if 5.10.70-1 + commit fixes the issue.
Regards,
Salvatore
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Hi Kevin,
On Sun, Nov 20, 2022 at 08:23:04AM -0500, Kevin P. Fleming wrote:
> On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> > Hi,
> >
> > On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
> >> Control: tags -1 + moreinfo
> >>
> >> Hi,
> >>
> >> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> >> > Package: src:linux
> >> > Version: 6.0.7-1
> >> > Severity: normal
> >> > Tags: ipv6
> >> >
> >> > Dear Maintainer,
> >> >
> >> > This system has been operating for most of the last 12 months, using
> >> > ProxyNDP on its external interface for eight addresses. After
> >> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
> >> > solicitations for those addresses after startup... it does not happen
> >> > immediately, but reliably occurs. When the system is in this state
> >> > (not responding to ND solicitations for the proxy addresses), the
> >> > proxy addresses are still shown in 'ip neigh show proxy', and the
> >> > single non-proxy address on the same interface continues operating
> >> > normally.
> >> >
> >> > Booting the system with the 5.19.0-2 kernel package cures the problem,
> >> > with no other changes.
> >> >
> >> > Example output:
> >> >
> >> > root@net22:~# ip neigh show proxy
> >> > 2607:5300:203:9743::1 dev ve-diw20 proxy
> >> > 2607:5300:203:9743::1 dev ve-matrix20 proxy
> >> > 2607:5300:203:9743::1 dev ve-ns3 proxy
> >> > 2607:5300:203:9743::1 dev ve-ldl20 proxy
> >> > 2607:5300:203:9743::1 dev ve-quassel21 proxy
> >> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy
> >> > 2607:5300:203:9743::1 dev ve-monica21 proxy
> >> > 2607:5300:203:9743::1 dev ve-mail20 proxy
> >> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy
> >> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy
> >> >
> >> > The addresses on enp1s0f0 are the ones which stop responding.
> >>
> >> Does the following matches your problem?
> >>
> >> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
> >>
> >> Would you be able to test the mentioned patch to verify a fix for your
> >> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
> >> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
> >
> > For reference, the commit would be v2 as applied in netdev as
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1
>
> While that description does not exactly match my problem, it is so
> similar as to almost certainly be the cause. I would be happy to try
> applying that patch, but it's been a while since I built a patched
> Debian kernel so it may take a couple of days :-)
If that would be helpful, we have some instructions on "simple
patching and building" the kernel with a additional patches on top
here:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
Hope this helps for it.
Regards,
Salvatore
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Hi,
On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> > Package: src:linux
> > Version: 6.0.7-1
> > Severity: normal
> > Tags: ipv6
> >
> > Dear Maintainer,
> >
> > This system has been operating for most of the last 12 months, using
> > ProxyNDP on its external interface for eight addresses. After
> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
> > solicitations for those addresses after startup... it does not happen
> > immediately, but reliably occurs. When the system is in this state
> > (not responding to ND solicitations for the proxy addresses), the
> > proxy addresses are still shown in 'ip neigh show proxy', and the
> > single non-proxy address on the same interface continues operating
> > normally.
> >
> > Booting the system with the 5.19.0-2 kernel package cures the problem,
> > with no other changes.
> >
> > Example output:
> >
> > root@net22:~# ip neigh show proxy
> > 2607:5300:203:9743::1 dev ve-diw20 proxy
> > 2607:5300:203:9743::1 dev ve-matrix20 proxy
> > 2607:5300:203:9743::1 dev ve-ns3 proxy
> > 2607:5300:203:9743::1 dev ve-ldl20 proxy
> > 2607:5300:203:9743::1 dev ve-quassel21 proxy
> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy
> > 2607:5300:203:9743::1 dev ve-monica21 proxy
> > 2607:5300:203:9743::1 dev ve-mail20 proxy
> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy
> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy
> >
> > The addresses on enp1s0f0 are the ones which stop responding.
>
> Does the following matches your problem?
>
> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
>
> Would you be able to test the mentioned patch to verify a fix for your
> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
For reference, the commit would be v2 as applied in netdev as
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1
.
Regards,
Salvatore
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Control: tags -1 + moreinfo
Hi,
On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> Package: src:linux
> Version: 6.0.7-1
> Severity: normal
> Tags: ipv6
>
> Dear Maintainer,
>
> This system has been operating for most of the last 12 months, using
> ProxyNDP on its external interface for eight addresses. After
> upgrading to the 6.0 kernel series, the kernel stops responding to ND
> solicitations for those addresses after startup... it does not happen
> immediately, but reliably occurs. When the system is in this state
> (not responding to ND solicitations for the proxy addresses), the
> proxy addresses are still shown in 'ip neigh show proxy', and the
> single non-proxy address on the same interface continues operating
> normally.
>
> Booting the system with the 5.19.0-2 kernel package cures the problem,
> with no other changes.
>
> Example output:
>
> root@net22:~# ip neigh show proxy
> 2607:5300:203:9743::1 dev ve-diw20 proxy
> 2607:5300:203:9743::1 dev ve-matrix20 proxy
> 2607:5300:203:9743::1 dev ve-ns3 proxy
> 2607:5300:203:9743::1 dev ve-ldl20 proxy
> 2607:5300:203:9743::1 dev ve-quassel21 proxy
> 2607:5300:203:9743::1 dev ve-mastodon22 proxy
> 2607:5300:203:9743::1 dev ve-monica21 proxy
> 2607:5300:203:9743::1 dev ve-mail20 proxy
> 2607:5300:203:9743:4::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:1::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:8::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:5::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:3::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:2::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:6::1 dev enp1s0f0 proxy
> 2607:5300:203:9743:7::1 dev enp1s0f0 proxy
>
> The addresses on enp1s0f0 are the ones which stop responding.
Does the following matches your problem?
https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
Would you be able to test the mentioned patch to verify a fix for your
issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
Regards,
Salvatore
Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)
Hi,
On Sun, Nov 20, 2022 at 12:30:53PM +0100, Diederik de Haas wrote:
> Control: found -1 5.14.9-2
> Control: found -1 5.15.5-2
> Control: fixed -1 5.15.15-2
> Control: fixed -1 5.16.11-1
> Control: fixed -1 5.18.16-1
> Control: fixed -1 6.0.3-1
>
> On zondag 20 november 2022 12:18:50 CET you wrote:
> > Control: found -1 5.14.9-2 5.15.5-2
> > Control: fixed -1 5.15.15-2 5.16.11-1 5.18.16-1 6.0.3-1
>
> That doesn't seem to work and I probably should just use the last version
> for 'found' and the first one for 'fixed', but I wanted to make sure (and
> log)
> that the latter ones *all* are fixed.
Seems the BSP was productive :). If you have spare cycles, might you
check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
in 5.16-rc4 is the commit we are searching? That one was backported to
the 5.10.y series in 5.10.84 and in 5.15.y series in 5.15.7 which
would fall into your found ranges as well.
OTOH, it fixes 5640f7685831 ("net: use a per task frag allocator")
which is way much longer back as where the people noticed to be
introduced.
Regards,
Salvatore
Bug#1023876: linux-image-5.19.0-0.deb11.2-amd64: infinite loop whit RAID1 when shutting down
Hi
On Fri, Nov 11, 2022 at 06:33:23PM -0300, Joao Eriberto Mota Filho wrote:
> Package: src:linux
> Version: 5.19.11-1~bpo11+1
> Severity: important
>
> Dear maintainer,
>
> I have a desktop with 3 polls over RAID1 (2 SSD, 2 HDD, plus 2 SSD). The
> current kernel on BPO creates an infinite loop when shutting down the system.
> I
> can see several messages like:
>
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> [...]
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> [...]
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> [...]
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> [...]
>
> There is a solution from Arch Linux[1]:
>
> "Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid".
>
> [1] https://bbs.archlinux.org/viewtopic.php?id=279383
>
> Please, consider disabling the deprecated BLOCK_LEGACY_AUTOLOAD, enabled by
> default in current kernel on Debian:
>
> $ cat /boot/config-5.19.0-0.deb11.2-amd64 | grep BLOCK_LEGACY_AUTOLOAD
> CONFIG_BLOCK_LEGACY_AUTOLOAD=y
>
> Thanks in advance.
I'm not sure, can we can do that (yet)? Some context about this is in
https://lore.kernel.org/all/yhe%2fc0k0fn9j8...@bombadil.infradead.org/
. In fact back for 5.18-rc1 upstream has weakened the removal schedule
for block device autoloading and with 451f0b6f4c44 ("block: default
BLOCK_LEGACY_AUTOLOAD to y")[1].
Initially it was planned to make it for 5.19, see fbdee71bb5d8
("block: deprecate autoloading based on dev_t")[2].
[1]: https://git.kernel.org/linus/451f0b6f4c44d7b649ae609157b114b71f6d7875
[2]: https://git.kernel.org/linus/fbdee71bb5d8d054e1bdb5af4c540f2cb86fe296
Regards,
Salvatore
Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address
Hello Jakub,
On Fri, Nov 18, 2022 at 09:53:49PM +0100, Jakub Wilk wrote:
> I've bisected this; the first bad commit is 1854bc6e24204726 ("mm/readahead:
> Align file mappings for non-DAX").
Given you were able to tackle the issue further, can you report the
issue to upstream (and keep this bug in the loop), including to the
memory managment maintainers explicitly William Kucharski
and Matthew Wilcox (Oracle)
as well?
Regards,
Salvatore
Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)
Source: firmware-nonfree Source-Version: 20220913-1 On Tue, Jun 21, 2022 at 03:06:19PM -0300, ng wrote: > I tried on a separate partition to run Fedora with the firmware 20220310, > and it works correctly there. You were right. The updated update raven VCN firmware is now included since the 20220913-1 update. Upstream commit: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?h=20220310=efcfe180c92302c4eec8ed6cfb26dadc0b391fbe Regards, Salvatore
Bug#1023025: linux-image-6.0.0-2-686: kernel BUG at mm/memory.c:2660!
Control: tags -1 + pending Hi, On Wed, Nov 02, 2022 at 07:55:50AM -0300, Luiz Fellipe Carneiro wrote: > Package: src:linux > Version: 6.0.5-1 > Followup-For: Bug #1023025 > X-Debbugs-Cc: l...@duck.com > > Dear Maintainer, > > Computer boot to a black screen and looks unresponsive from the keyboard and > mouse after the update. > In recover mode it boots to a black screen with the mouse pointer only, but > accessible via SSH, and with dmesg found the bug in message: > [ 117.318446] kernel BUG at mm/memory.c:2660! This should be fixed with upstream commit https://git.kernel.org/linus/1fdbed657a4726639c4f17841fd2a0fb646c746e in 6.1~rc5 (and which is backported to 6.0.9 as well). Regards, Salvatore
Re: Bug#1022172: Bug#1024082: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
Hi Marco, On Mon, Nov 14, 2022 at 07:06:30PM +0100, Marco d'Itri wrote: > > Try something like this in /lib/udev/rules.d/60-nfs.rules: > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", \ > RUN+="/sbin/sysctl -q --pattern ^sunrpc --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="rpcrdma", \ > RUN+="/sbin/sysctl -q --pattern ^sunrpc.svc_rdma --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="lockd", \ > RUN+="/sbin/sysctl -q --pattern ^fs.nfs.n[sl]m --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfsv4", \ > RUN+="/sbin/sysctl -q --pattern > ^fs.nfs.(nfs_callback_tcpport|idmap_cache_timeout) --system" > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfs", \ > RUN+="/sbin/sysctl -q --pattern ^fs.nfs --system" > > Differently from the original file I tired anchoring the patterns, which > looks more correct to me. Thanks, I will try to test this and bring to nfs-utils upstream. Michael or Andras, if you can help testing it in your use cases that would be helpful. Regards, Salvatore
Bug#1019204: closed by Stéphane Hoc (ss command freeze and the process cannot be killed)
Control: fixed -1 6.0~rc7-1~exp1 Hi Stéphane On Tue, Nov 15, 2022 at 11:42:03AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the iproute2 package: > > #1019204: ss command freeze and the process cannot be killed > > It has been closed by Stéphane Hoc . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Stéphane Hoc > by > replying to this email. > > > -- > 1019204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019204 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > From: Stéphane Hoc > Date: Tue, 15 Nov 2022 12:38:01 +0100 > To: 1019204-d...@bugs.debian.org > Subject: ss command freeze and the process cannot be killed > > Version: 6.0.0-1 > > It's also fixed on my side, kernel 6.0.0-4-amd64 (6.0.8-1) on Debian > unstable. > This bug can now be closed. The fix was probably https://git.kernel.org/linus/76dd07281338da6951fdab3432ced843fa87839c which is in 6.0-rc7 upstream (and would have been backported to 5.19.12 (but the later was never uploaded as we switched to to the 6.x series after 5.19.11-1). Regards, Salvatore
reassign 1019204 to src:linux, notfixed 1019204 in 6.0.0-1, closing 1019204
reassign 1019204 src:linux 5.19.6-1 notfixed 1019204 6.0.0-1 close 1019204 6.0.8-1 thanks
Re: Bug#1024082: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
Control: tags 1024082 + upstream Control: forwarded 1024082 https://lore.kernel.org/linux-nfs/y1kokwu88pulc...@eldamar.lan/ On Mon, Nov 14, 2022 at 03:45:42PM +0100, Marco d'Itri wrote: > On Nov 14, Michael Prokop wrote: > > > FYI: I reported this one as #1024082, looks like the new > > /lib/modprobe.d/50-nfs.conf file is causing quite some problems. > At this point we have established that for good or for worse kmod is > behaving as documented, so we are down to one of: > > - initramfs-tools learns to parse the install directives > - nfs-kernel-server uses udev rules instead > > I recommend the second option, which is much more general and robust. FWIW, I asked a while back upstream about it, and they would be open to change this. https://lore.kernel.org/linux-nfs/y1kokwu88pulc...@eldamar.lan/ and https://lore.kernel.org/linux-nfs/166656275785.12462.14027406790454668...@noble.neil.brown.name/ But it needs someone who is implementing the change and submits it upstream. Michael, would you be able to work on this and submit the change upstream? Once accepted there we can happily cherry pick it for us. We should not diverge to much from upstream at this point, this was exactly one of the problems that nfs-utils remained for ages at an ancient 1.3.4 based version. Now we have reduced the delta massively, which helps keeping on track with upstream versions. Regards, Salvatore
Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted
Control: forwarded -1 https://lore.kernel.org/linux-input/Y26BMXn15Kbt6a2u@localhost/ Control: tags -1 - moreinfo Hi Josh. On Fri, Nov 11, 2022 at 09:07:41AM -0800, Josh Triplett wrote: > On Fri, Feb 25, 2022 at 02:43:59PM +0100, Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > > > Hi Josh, > > > > On Mon, Feb 21, 2022 at 04:31:39PM -0800, Josh Triplett wrote: > > > Package: src:linux > > > Version: 5.16.7-2 > > > Severity: normal > > > X-Debbugs-Cc: j...@joshtriplett.org > > > > > > I have an external ThinkPad USB keyboard: > > > > > > $ lsusb | grep -i keyboard > > > Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with > > > TrackPoint > > > > > > The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard: > > > > > > $ cat > > > /sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock > > > 1 > > > > > > However, this attribute appears inverted for this particular keyboard: > > > it seems to be 1 when FnLock is *disabled* and 0 when FnLock is > > > *enabled*. > > > > If you can reproduce this with either 5.16.10-1 (or later today > > 5.16.11-1) or the current version in experimental (5.17~rc4-1~exp1) > > would it be possible you report it upstream and keep us updated on the > > progress? > > Reproduced with 6.0.6-2, and reported upstream (CCed to this bug). Thank you for re-testing and reporting it upstream. Regards, Salvatore
Bug#996008: Bug #996008: i225 NIC no longer recognized after 11.1 point release
Hi On Tue, Jun 07, 2022 at 04:50:09PM +0200, Diederik de Haas wrote: > Control: reassign -1 src:linux 5.10.70-1 > Control: tag -1 moreinfo > > On Sun, 10 Oct 2021 00:25:44 + (UTC) TarotApprentice > wrote: > > Package: linux-image-amd64 > > Version: 5.10.0-9 (5.10.70-1) > > > > Two machines (ASUS X570-P/CSM) with built-in NIC (realtek) and > > add-in 2.5GbE NIC (intel i225). After installing point release 11.1 the > > add-in NIC is no longer recognized on either machine. The built-in NIC still > > works. Clearly it was working before the point release as it used the > > 2.5G NIC to do the apt upgrade. > > > > Both machines were running kernel 5.10.0-8 and Bullseye prior to the > > upgrade. > > Rebooting the machine using the 5.10.0-8 kernel (selecting it from grub) > > doesn't help - NIC enumeration fails. > > > > # grep igc /var/log/messages > > Oct 10 08:50:00 *** kernel: [4.829780] igc :04:00.0 enp4s0: NIC > > Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX > > Oct 10 09:03:26 *** kernel: [3.819348] igc: probe of :04:00.0 > > failed with error -13 > > Oct 10 10:59:51 *** kernel: [3.826878] igc: probe of :04:00.0 > > failed with error -13 > > I'm inclined to think/agree that this is a kernel issue, but what is then > confusing is that it still doesn't work with the same kernel version with > which > it previously did work. Which suggests that another update caused the failure. > > The latest point release is now 11.3, so verifying whether the problem is > still > present there, with a newer 5.10 kernel, seems like a good first step. > > If that's the case, a more complete output of dmesg or /var/log/messages would > be useful. > Also testing with a kernel from Testing/Unstable and/or Bullseye backports > would also give useful extra information. Do you still experience the same issues with the most recent kernel in bullseye (5.10.149-2). I'm inclined otherwise to close this bugreport, assuming it's not reproducible. If it is reproducible, does the same issue shows up with more recent kernels from unstable and/or backports? Regards, Salvatore
Bug#927710: ath10k locks to regulatory domain US on ACPI platforms
Control: forwarded -1
https://lore.kernel.org/ath10k/2ab7cc1d-f756-ba3c-64b7-65f8a739a...@newmedia-net.de/#t
On Sat, May 29, 2021 at 02:23:22PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Sun, Apr 21, 2019 at 09:48:17PM +0200, Rene 'Renne' Bartsch, B.Sc.
> Informatics wrote:
> > Package: linux-image
> > Version: 4.19.28-2
> >
> > The ath10k 802.11 driver reads the country code for the radio regulatory
> > domain from the ACPI table.
> > If it can't get a valid value it locks to US regulatory domain which is
> > wrong for most countries.
> > This makes Atheros devices in master mode unusable on ACPI devices in most
> > countries.
> >
> > Sven Gottschall suggested on ath10k mailing-list to return -EOPNOTSUPP in
> > function
> > ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd) in file
> > drivers/net/wireless/ath/ath10k/mac.c to solve this.
> >
> >
> > static int ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd)
> > {
> > return -EOPNOTSUPP;
> > }
>
> Was there a conclusion upstream?
As this looks is not going to change in upstream, I'm closing this
downstream bug about it as well.
Regards,
Salvatore
Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter USA-49WLC failed to load firmware
Hi Jakob, On Tue, Feb 08, 2022 at 08:03:19AM +0100, Salvatore Bonaccorso wrote: > Hi Jakob, > > On Mon, Feb 07, 2022 at 03:33:49PM +0100, Jakob Haufe wrote: > > This still affects 5.15.0-3-amd64: > > > > [624300.704569] usb 5-1: new full-speed USB device number 2 using ohci-pci > > [624300.901723] usb 5-1: New USB device found, idVendor=06cd, > > idProduct=011a, bcdDevice=80.01 > > [624300.901746] usb 5-1: New USB device strings: Mfr=0, Product=0, > > SerialNumber=0 > > [624300.903869] keyspan 5-1:1.0: Keyspan - (without firmware) converter > > detected > > [624300.904014] usb 5-1: firmware: direct-loading firmware > > keyspan/usa49wlc.fw > > [624304.121517] usb 5-1: ezusb_ihex_firmware_download - ezusb_writememory > > failed writing internal memory (-110 7F92 b8cbdc0a 1) > > [624304.121545] usb 5-1: failed to load firmware "keyspan/usa49wlc.fw" > > [624304.121559] keyspan: probe of 5-1:1.0 failed with error -2 > > > > The patch applies with some fuzz but still solves the issue. > > Refreshed patch is attached. > > > > Has anyone already contacted upstream about this? I couldn't find > > anything related on the linux-usb ML. > > Not that I'm aware of. Given you have a tested patch, would it be > possible that you contact upstream about it, keeping us in the loop or > at least notify when it is applied in mainline? Jakob, were you able to forward the patch upstream? I'm including Johan and linux-usb list in this reply now. Johan, fo context, it is about an older bug reported in Debian as https://bugs.debian.org/833035 with users of the Keyspan USB serial adapter USA-49WLC faling to load firmware. There was a patch used, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833035#68 tough which hs no commit message or Signed-off-by's . Original patch is from Ben in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833035#24 . Regards, Salvatore
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Hi Stephan, On Fri, Nov 11, 2022 at 06:53:46AM +, Stephan Verbücheln wrote: > Yesterday, kernel 6.0.8 was released with a number of EFI fixes. I have > compiled the vanilla kernel and I am happy to confirm that it solves > the issue. Thanks for confirming, 6.0.8-1 will be uploaded soon. Regards, Salvatore
Uploading linux (6.0.8-1)
Hi I would like to upload linux version 6.0.8-1 to unstable later today. It includes a rebase to 6.0.8 stable release and including fix CVE-2022-3628 and closing Debian bugs #1023450 and #1023726. An ABI bump is included. Additional changes are: * [x86] drivers/platform/x86: Enable GIGABYTE_WMI as module (Closes: #1023613) Regards, Salvatore signature.asc Description: PGP signature
Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection
Hi Guy, [Thanks to Diederik for taking time as well to contribute!] On Thu, Nov 10, 2022 at 06:22:48PM +0100, Guy Durrieu wrote: > Hi Salvatore, > > I did the test using the kernel image you built for me. After reactivating > rasdaemon (and rebooting), all apparently work fine. Good news, thanks for your testing! So it's the same as #1023726. > I have a last question: Do I keep this version, and what will happen when > the next kernel update occurs ? And what about the 6.0.0.2 one ? As it is an unofficial build, please do revert back to an official one. I plan to upload 6.0.8-1 based on the today's released 6.0.8 "soonish" which will contain the fix as well. Hope this helps so far, Regards, Salvatore
Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection
Hi Guy, On Wed, Nov 09, 2022 at 06:05:58PM +0100, Guy Durrieu wrote: > Hi Salvatore, > > OK, I will try that as soon as possible. Am I supposed to re-enable the > rasdeamon once the patch applied ? Anyway I will report you the result (f I > don't make any mistake). Yes right, the idea would be to boot the new kernel with rasdeamon enabled again and see if the system is stable again. Be aware though that rasdaemon itself might segfault, there is a second issue, where rasdaemon needs fixing as well, see #1023725. Regards, Salvatore
Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection
Hi Guy, On Wed, Nov 09, 2022 at 05:20:25PM +0100, Guy Durrieu wrote: > Hi Salvatore, > > Sorry. My first attempt was under 6.0.0-2... I tried again disabling > rasdaemon under 5.19.0-2 (it worked). Then I restarted 6.0.0-2 and the issue > seems to have disapeared (after a first bad start). Thanks for confirming, so there is good indication you are seeing the same as #1023726 and will later merge those. > Concerning the patch, my question remains (I don't have the source for > ring_buffer). It looks I was too slow, my answer was on the way and overlapped with this followup. There are instructions on how to "simple test patches". But I have uploaded as well intermediate deb files (unsigned) which you can use if you have enough trust level on the path to fetch them. Regards, Salvatore
Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection
Hi Guy, On Wed, Nov 09, 2022 at 04:55:36PM +0100, Guy Durrieu wrote: > Hi Salvatore, > > Thanks for your quick answer ! > > I tried the command "rasdaemon --disable" (as sudoer) , but it blocks and > apparently doesn't product any effect. I also tried to directly kill the > rasdaemon process, without success. To test the behaviour without having rasdaemon started at all, do mask the service and the reboot: systemctl mask rasdaemon.service (to unmask again, systemctl unmask rasdaemon.service). > Additionnally, I am not sure to know how to proceed in order to apply the > patch you sent. Could you give me some hint ? There is our documentation at https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 . But would you be willing to test (but be aware, unsigned!) test packages fetched by https://people.debian.org ? https://people.debian.org/~carnil/tmp/linux/6.0.7-2/ I have put a sha256sum file with signature on it with my gpg key to have an additional verification on those. https://db.debian.org/fetchkey.cgi?fingerprint=04A4407CB9142C23030C17AE789D6F057FD863FE Regards, Salvatore
Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection
Hi Guy, On Wed, Nov 09, 2022 at 11:38:51AM +0100, Guy Durrieu wrote: > Package: src:linux > Version: 6.0.5-1 > Severity: normal (I would say serious...) > > Dear Maintainer, > > Until today, my linux-image-6.0.0-2-amd64 was OK. After the recent updates I > get a serious problem: no more network connection (neither ethernet, wifi > nor USB), and no more pulseaudio server connection. > > When rebooting with the previous available version > (linux-image-5.19.0-2-amd64) all work fine. > > I thus send this report using thisversion of the kernel but you will find > below the 200 lines of the kernel.log when booting > linux-image-6.0.0-2-amd64. Hope it will help. > > Thanks in advance for your help ! > > Best regards. > > -- Guy Durrieu > > > > 2022-11-09T10:10:15.885062+01:00 ITI kernel: [ 3.701731] amdgpu > :06:00.0: No more image in the PCI ROM > 2022-11-09T10:10:15.885063+01:00 ITI kernel: [ 3.701751] amdgpu > :06:00.0: amdgpu: Fetched VBIOS from ROM BAR > 2022-11-09T10:10:15.885063+01:00 ITI kernel: [ 3.701753] amdgpu: ATOM > BIOS: > 115-D009PI2-101 > 2022-11-09T10:10:15.885065+01:00 ITI kernel: [ 3.701768] [drm] UVD is > enabled in VM mode > 2022-11-09T10:10:15.885066+01:00 ITI kernel: [ 3.701769] [drm] UVD ENC is > enabled in VM mode > 2022-11-09T10:10:15.885066+01:00 ITI kernel: [ 3.701770] [drm] VCE > enabled > in VM mode > 2022-11-09T10:10:15.885066+01:00 ITI kernel: [ 3.701771] amdgpu > :06:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported > 2022-11-09T10:10:15.885067+01:00 ITI kernel: [ 3.701812] [drm] vm size is > 64 > GB, 2 levels, block size is 10-bit, fragment size is 9-bit > 2022-11-09T10:10:15.885067+01:00 ITI kernel: [ 3.701850] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_mc.bin > 2022-11-09T10:10:15.885069+01:00 ITI kernel: [ 3.701856] amdgpu > :06:00.0: amdgpu: VRAM: 8192M 0x00F4 - 0x00F5 > (8192M used) > 2022-11-09T10:10:15.885070+01:00 ITI kernel: [ 3.701859] amdgpu > :06:00.0: amdgpu: GART: 256M 0x00FF - 0x00FF0FFF > 2022-11-09T10:10:15.885070+01:00 ITI kernel: [ 3.701863] [drm] Detected > VRAM > RAM=8192M, BAR=256M > 2022-11-09T10:10:15.885070+01:00 ITI kernel: [ 3.701865] [drm] RAM width > 256bits GDDR5 > 2022-11-09T10:10:15.885071+01:00 ITI kernel: [ 3.701900] [drm] amdgpu: > 8192M > of VRAM memory ready > 2022-11-09T10:10:15.885071+01:00 ITI kernel: [ 3.701901] [drm] amdgpu: > 7975M > of GTT memory ready. > 2022-11-09T10:10:15.885072+01:00 ITI kernel: [ 3.701911] [drm] GART: num > cpu > pages 65536, num gpu pages 65536 > 2022-11-09T10:10:15.885074+01:00 ITI kernel: [ 3.702755] sr 15:0:0:0: > Attached scsi CD-ROM sr0 > 2022-11-09T10:10:15.885074+01:00 ITI kernel: [ 3.703580] [drm] PCIE GART > of > 256M enabled (table at 0x00F40090). > 2022-11-09T10:10:15.885074+01:00 ITI kernel: [ 3.703686] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_pfp_2.bin > 2022-11-09T10:10:15.885075+01:00 ITI kernel: [ 3.703702] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_me_2.bin > 2022-11-09T10:10:15.885075+01:00 ITI kernel: [ 3.703717] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_ce_2.bin > 2022-11-09T10:10:15.885076+01:00 ITI kernel: [ 3.703719] [drm] Chained IB > support enabled! > 2022-11-09T10:10:15.885078+01:00 ITI kernel: [ 3.703738] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_rlc.bin > 2022-11-09T10:10:15.885078+01:00 ITI kernel: [ 3.703813] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec_2.bin > 2022-11-09T10:10:15.885078+01:00 ITI kernel: [ 3.703887] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec2_2.bin > 2022-11-09T10:10:15.885079+01:00 ITI kernel: [ 3.704362] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma.bin > 2022-11-09T10:10:15.885116+01:00 ITI kernel: [ 3.704383] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma1.bin > 2022-11-09T10:10:15.885117+01:00 ITI kernel: [ 3.704403] amdgpu: > hwmgr_sw_init smu backed is polaris10_smu > 2022-11-09T10:10:15.885119+01:00 ITI kernel: [ 3.704495] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_uvd.bin > 2022-11-09T10:10:15.885120+01:00 ITI kernel: [ 3.704497] [drm] Found UVD > firmware Version: 1.130 Family ID: 16 > 2022-11-09T10:10:15.885120+01:00 ITI kernel: [ 3.705128] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_vce.bin > 2022-11-09T10:10:15.885121+01:00 ITI kernel: [ 3.705131] [drm] Found VCE > firmware Version: 53.26 Binary ID: 3 > 2022-11-09T10:10:15.885121+01:00 ITI kernel: [ 3.705702] amdgpu > :06:00.0: firmware: direct-loading firmware amdgpu/polaris10_k_smc.bin >
Bug#1014595: linux-image-5.19.0-rc4-amd64: Enable CONFIG_SND_SOC_INTEL_SOF_ES8336_MACH=m
Control: tags -1 + pending Hi, On Mon, Nov 07, 2022 at 12:53:40PM -0500, Giovanni Caligaris wrote: > Hi, can anyone pick this up and push it to the latest kernel versions > please. I have created a merge request for this change: https://salsa.debian.org/kernel-team/linux/-/merge_requests/575 and should land in the next experimental upload based on 6.1-rc4. Regards, Salvatore
Uploading linux (6.0.7-1)
Hi I would like to upload linux version 6.0.7-1 to unstable later today. It includes a rebase to 6.0.7 stable release, including a fix for CVE-2022-3524 and bugfix for #1023167 (regression in squashfs fixed). An ABI bump is included, which will resolve as well the fallout of the previous announced non-ABI change, which then caused #1023298. Additional changes are: * wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update() (Closes: #1023329) * Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM (CVE-2022-42896) * Bluetooth: L2CAP: Fix attempting to access uninitialized memory (CVE-2022-42895) Regards, Salvatore signature.asc Description: PGP signature
Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)
Hi Vincent, On Tue, Nov 01, 2022 at 12:15:30PM +0100, Vincent Lefevre wrote: > Control: tags -1 upstream > > Hi Salvatore, > > On 2022-11-01 08:05:28 +0100, Salvatore Bonaccorso wrote: > > What happens if you downgrade firmware-iwlwifi to 20210818-1? > > Actually, I cannot reproduce the failure with the new kernel, even > with the current firmware-iwlwifi. > > I don't know what happened, but there could be random failures with > recent kernels, as other users got exactly the same error: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1859592 > > (bug reported in 2020-01) and > > https://bbs.archlinux.org/viewtopic.php?id=271459 Reading through the reports and https://bugzilla.kernel.org/show_bug.cgi?id=215167 I wonder if you can more easily reproduce your issue with doing cold boot of the machine or reboot it. I'm asking because it looks that for some people a workaround was to increase the sleeping time in btusb_qca_cmd_timeout(). If you get to the point where you can it more easily to reproduce with a failure, that would be helpful to report the information you get fo Marcel Holtmann (supporter:BLUETOOTH DRIVERS) Johan Hedberg (supporter:BLUETOOTH DRIVERS) Luiz Augusto von Dentz (supporter:BLUETOOTH DRIVERS) linux-blueto...@vger.kernel.org (open list:BLUETOOTH DRIVERS) linux-ker...@vger.kernel.org (open list) Could you do that and keep this bug in the loop? Regards, Salvatore
Bug#995153: linux-image-5.14.0-trunk-amd64: no more bluetooth
Control: tags -1 + moreinfo Hi Xavier, On Mon, Sep 27, 2021 at 10:09:34AM +0200, Xavier Bestel wrote: > Package: src:linux > Version: 5.14.3-1~exp1 > Severity: normal > > Dear Maintainer, > > In the previous package (something like 5.14.1 IIRC) bluetooth used to work > not too bad (I have a Qualcomm QCA6390). Since the last version there's > no more BT, and the log show this: > > [ 35.080973] Bluetooth: hci0: Reading QCA version information failed (-110) > [ 35.080979] Bluetooth: hci0: Retry BT power ON:1 > [ 37.417010] Bluetooth: hci0: command 0xfc00 tx timeout > [ 45.577106] Bluetooth: hci0: Reading QCA version information failed (-110) > [ 45.577121] Bluetooth: hci0: Retry BT power ON:2 > [ 47.913194] Bluetooth: hci0: command 0xfc00 tx timeout > [ 56.073023] Bluetooth: hci0: Reading QCA version information failed (-110) > > HTH, > Xav If you have still the device available, does the problem persist with a more recent kernel version as available in unstable (6.0.6-2) or experimental (6.1~rc3-1~exp1)? Regards, Salvatore
Bug#1000766: bugs.debian.org: After upgrade to linux kernel 15.15.0-1-amd64 bluetooth controller doen't start
Control: retitle -1 After upgrade to linux kernel 5.15.0-1-amd64 bluetooth controller doen't start Control: tags -1 + moreinfo Hi, On Sun, Nov 28, 2021 at 07:40:34PM +0100, kirill wrote: > Package: bugs.debian.org > Severity: normal > X-Debbugs-Cc: safi...@gmx.de > > Dear Maintainer, > >* What led up to the situation? >* After upgrading to linux kernel 15.15.0-1-amd64 from 15.14.0-4-amd64 > bluetooth doesn't work. bluetoothctl says "no controller available". I have a > bit older HP laptop with Intel Dual Band Wireless-AC 7265. On startup I get > following errors regarding bluetooth: > Bluetooth: hci0: Reading Intel version command failed (-110) > Bluetooth: hci0: command 0xfc05 tx timeout > >* What exactly did you do (or not do) that was effective (or > ineffective)? >* If I start debian with previos kernel (15.14.0-4-amd54) blueooth is > working againg Your issue likely is similar to the one reported in https://bugzilla.kernel.org/show_bug.cgi?id=215167 at least. Please test with current kernel from unstable (6.0.6-2) or ideally from experimental (6.1~rc3-1~exp1). If the issue still persist, please provide kernel logs and information specific to your hardware (in particular pci and usb devices, but best is to reportbug to run the bug script to collect information). Regards, Salvatore
Bug#1022806: [SOLVED UPSTREAM?] linux-image-5.10.0-19-amd64: amggpu unbootable problem persists
Control: tags -1 + confirmed pending Hi Cosimo, On Fri, Nov 04, 2022 at 01:32:32AM +0100, Cosimo Agati wrote: > I experienced this problem on a machine with the following > hardware: > > CPU: AMD FX-8350 (8) @ 4.000GHz > GPU: AMD ATI Radeon R7 370 / R9 270/370 OEM > > After bisecting from the 5.10.149 sources, I found that the commit > responsible for this bug was > 867b2b2b6802fb3995a0065fc39e0e7e20d8004d, corresponding to > upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820. > > This commit was reverted already on the 5.10 tree: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=357db159e965efa6a0b7b6f9efa1c34bf876db2d > > Indeed, vanilla Linux 5.10.153, which contains this revert and > which is the currently latest release in the 5.10 branch, seems to > boot properly with the amdgpu driver. > > The Debian package linux-image-5.10.0-19-amd64 is built from > sources corresponding to the upstream release 5.10.149, which did > NOT contain the fix. This seems to explain why many people with > AMD GPUs, myself included, were experiencing problems during boot. > > Since this problem seems to have been fixed upstream, I don’t > think there is anything to do on the Debian side... except of > course packaging the next linux-image package with a Linux source > tree containing these fixes. > > I’m happy to provide more information about this if anyone deems > it necessary. Thanks for doing the bisec and confirming. The revert you mention landed in 5.10.150. The fix will be in the next upload. Regards, Salvatore
Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless
Hi Diederik!
On Thu, Nov 03, 2022 at 12:37:19PM +0100, Diederik de Haas wrote:
> Control: found -1 6.0.5-1
> Control: fixed -1 6.0.6-2
> Control: fixed -1 6.1~rc3-1~exp1
> Control: severity -1 grave
> Control: tag -1 -moreinfo
> Control: tag -1 upstream fixed-upstream
> Control: retitle -1 RPi 0-3 fail to boot on kernel 5.19+ without HDMI
> connected
> Control: forwarded -1
> https://lore.kernel.org/all/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e9622...@cerno.tech/
>
> On Monday, 31 October 2022 00:37:54 CET Diederik de Haas wrote:
> > Control: found -1 5.19.6-1
> > Control: severity -1 important
> > Control: tag -1 moreinfo
> >
> > On 30 Oct 2022 13:24:55 +0100 Jan Huijsmans
> > wrote:
> > > Package: linux-image-5.19.0-1-arm64
> > > Severity: critical
> > > Justification: breaks the whole system
> >
> > Only affecting RPi3 in certain conditions, thus lowering severity.
>
> I was able to reproduce this on a RPi 1, found that is was reported upstream
> here:
> https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak...@pengutronix.de/
>
> and found the patches that were applied upstream in 6.1-rc2 where there were
> 2 commits and saw that 1 commit was backported to the linux-6.0 branch, but
> that seemed sufficient as installing kernel 6.0.6-2 from unstable, fixed the
> issue.
>From the cover letter in the series:
> The first patch will fix this, and the second will make sure we avoid that
> situation entirely in the future. This has been tested with 5.19.12. Earlier
> versions might need a backport of 88110a9f6209 ("clk: bcm2835: fix
> bcm2835_clock_choose_div").
So I think it is safe to consider it fixed in all those versions where
the first patch was applied.
Regards,
Salvatore
Bug#1023329: fix unexpected wakeups with WCN6855
Control: tags -1 + pending Hi Marco, On Wed, Nov 02, 2022 at 02:14:44PM +0100, Marco d'Itri wrote: > Package: src:linux > Version: 6.0.5-1 > Severity: normal > Tags: upstream patch > > As reported on > https://forums.lenovo.com/t5/Other-Linux-Discussions/T14s-G3-AMD-Linux-Sleep/m-p/5172287?page=4, > this patch from ath-next fixes unexpected wakeups on Lenovo hardware > using the Qualcomm Wi-Fi card like my T14s Gen3: > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath11k?h=ath-next=d99884ad9e3673a12879bc2830f6e5a66cccbd78 > > Can you include it in the next 6.0 upload please? I picked the commit for the next upload to unstable (probably for 6.0.7-1 and making an ABI bump so we can resolve the FTBFS on arm64 and armhf currently present). Regards, Salvatore
Bug#1023298: linux: FTBFS on arm64 and armhf (ABI changes)
Source: linux Version: 6.0.6-2 Severity: serious Justification: FTBFS X-Debbugs-Cc: car...@debian.org Documenting the build failures on arm64 and armhf due to ABI changes: https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=6.0.6-2=1667324068=0 https://buildd.debian.org/status/fetch.php?pkg=linux=armhf=6.0.6-2=1667316319=0 Regards, Salvatore
Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)
Hi Vincent, On Tue, Nov 01, 2022 at 02:24:44AM +0100, Vincent Lefevre wrote: > Hi Salvatore, > > On 2022-10-31 22:27:15 +0100, Salvatore Bonaccorso wrote: > > There were no Bluetooth related changes in the relatively small 6.0.3 > > to 6.0.5 update and I cannot reproduce the issue. Can you provide the > > full boot and kernel logs? (ideally from both runs). > > I've attached the journalctl output for the boot: > * journal-6.0.5-1 > * journal-6.0.3-1 after downgrading the kernel. What happens if you downgrade firmware-iwlwifi to 20210818-1? (While the one which your HW needs to load is still present in the binary package there was the removal of old unsupported 3160/7260/7265/8000/8265 firmware which might have an influence). Regards, Salvatore
Uploading linux (6.0.6-1)
Hi I would like to upload linux version 6.0.6-1 to unstable. The update just consits of further importing 6.0.6 upstream. No ABI bump is required. Regards, Salvatore signature.asc Description: PGP signature
Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)
Control: severity -1 important Control: tags -1 + moreinfo Hi Vincent, On Mon, Oct 31, 2022 at 01:09:31PM +0100, Vincent Lefevre wrote: > Package: src:linux > Version: 6.0.5-1 > Severity: grave > Justification: renders package unusable > > (Setting to grave because Bluetooth is a major component.) > > Bluetooth no longer works at all. > > zira:~> journalctl -b -g bluetooth > Oct 31 12:55:16 zira kernel: Bluetooth: Core ver 2.22 > Oct 31 12:55:16 zira kernel: NET: Registered PF_BLUETOOTH protocol family > Oct 31 12:55:16 zira kernel: Bluetooth: HCI device and connection manager > initialized > Oct 31 12:55:16 zira kernel: Bluetooth: HCI socket layer initialized > Oct 31 12:55:16 zira kernel: Bluetooth: L2CAP socket layer initialized > Oct 31 12:55:16 zira kernel: Bluetooth: SCO socket layer initialized > Oct 31 12:55:17 zira systemd[1]: Starting Bluetooth service... > Oct 31 12:55:17 zira systemd[795]: ConfigurationDirectory 'bluetooth' already > exists but the mode is different. (File system: 755 > ConfigurationDirectoryMode: 555) > Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth daemon 5.65 > Oct 31 12:55:17 zira systemd[1]: Started Bluetooth service. > Oct 31 12:55:17 zira systemd[1]: Reached target Bluetooth Support. > Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth management interface 1.22 > initialized > Oct 31 12:55:17 zira dbus-daemon[801]: [system] Activating via systemd: > service name='org.freedesktop.hostname1' > unit='dbus-org.freedesktop.hostname1.service' requested by ':1.2' (uid=0 > pid=795 comm="/usr/libexec/bluetooth/bluetoothd") > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP filters: protocol multicast > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP socket layer initialized > Oct 31 12:55:17 zira NetworkManager[950]: [1667217317.6273] Loaded > device plugin: NMBluezManager > (/usr/lib/x86_64-linux-gnu/NetworkManager/1.40.2/libnm-device-plugin-bluetooth.so) > Oct 31 12:55:19 zira kernel: Bluetooth: hci0: Reading Intel version command > failed (-110) > Oct 31 12:55:19 zira kernel: Bluetooth: hci0: command 0xfc05 tx timeout > > With the 6.0.3-1 kernel version, I got: > > Oct 31 11:17:59 zira kernel: Bluetooth: Core ver 2.22 > Oct 31 11:17:59 zira kernel: NET: Registered PF_BLUETOOTH protocol family > Oct 31 11:17:59 zira kernel: Bluetooth: HCI device and connection manager > initialized > Oct 31 11:17:59 zira kernel: Bluetooth: HCI socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: L2CAP socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: SCO socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Legacy ROM 2.5 revision 8.0 > build 2 week 3 2013 > Oct 31 11:17:59 zira kernel: bluetooth hci0: firmware: direct-loading > firmware intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq > Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Intel Bluetooth firmware file: > intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq > Oct 31 11:17:59 zira systemd[1]: Starting Bluetooth service... > [...] > > So it appears that the 6.0.5-1 kernel version can't load the firmware. There were no Bluetooth related changes in the relatively small 6.0.3 to 6.0.5 update and I cannot reproduce the issue. Can you provide the full boot and kernel logs? (ideally from both runs). Regards, Salvatore
Bug#1023103: linux-image-5.10.0-14-amd64: Wrong power value on APU2 with bullseye
Hi Alexis, On Sun, Oct 30, 2022 at 10:41:12AM +0100, Alexis Domjan wrote: > Hi Salvatore, > > Le 30.10.22 à 10:21, Salvatore Bonaccorso a écrit : > > Control: tags -1 + moreinfo > > Since 5.10.113-1 is already superseeded by several uploads, can you > > confirm the issue you are seeing is still present in the most current > > uploaded version? (5.10.149-2). > > Sorry, indeed, I didn't noticed it wasn't the latest available version of the > kernel. > > After the update, however, the issue is still present with the same symptoms. > > Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux > > Do you need more information ? Thank you for testing. And before 5.10.113 can you pin point to a version in which showed sensible versions? If so you have a starting point to bisect where the problem is introduced which would be very helpfull to determine the pontential issue. Does the issue persist with a more recent kernel (either from backports or from unstable)? Regards, Salvatore
Bug#1023103: linux-image-5.10.0-14-amd64: Wrong power value on APU2 with bullseye
Control: tags -1 + moreinfo Hi Alexis, On Sun, Oct 30, 2022 at 09:47:03AM +0100, Alexis Domjan wrote: > Package: src:linux > Version: 5.10.113-1 > Severity: normal > > Dear Maintainer, > > With bullseye, /sys/class/hwmon/hwmon0/power1_average is wrong > when the system is idle (80-120W on a system whose max is probably > 10); it is correct when the CPU is used. The bug is not present in > buster. With or without amd64 microcode, no change either. Since 5.10.113-1 is already superseeded by several uploads, can you confirm the issue you are seeing is still present in the most current uploaded version? (5.10.149-2). Regards, Salvatore
Bug#1013211: problem is gone
Control: tags -1 + moreinfo On Sun, Oct 30, 2022 at 03:55:46AM +, Douglas Silva wrote: > I can no longer reproduce this. Currently running Ubuntu 22.10 with > kernel 5.19.0-23-generic. C-states enabled in the BIOS. But what about Debian's kernels? Are you able to reproduce your issue still with most recent kernel in unstable? (6.0.5-1). Regards, Salvatore
Re: Bug#1005400: closed by Diederik de Haas (Re: Bug#1005400: firmware-nonfree: Please package AMD SEV firmware.)
Hi, On Sat, Oct 29, 2022 at 10:37:11AM +0200, Diederik de Haas wrote: > On Saturday, 29 October 2022 09:01:49 CEST Salvatore Bonaccorso wrote: > > > They are part of the above version, thus closing. > > > > Actually they are shipped with amd64-microcode instead: > > Indeed. How come it 'still' shows up in firmware-nonfree's build log? > https://buildd.debian.org/status/fetch.php?pkg=firmware-nonfree=all=20220913-1=1666990396=0 > > It was based on that log that I did most/all my recent bug closing. The files are present in the source and copied to debian/build/install . But they are then not installed in any of the produced binary packages in the later install steps for the various binary packages. (see debian/config/*/defines). Does this help? Regards, Salvatore
Re: Proposed changes to linux package
Hi Bastian, On Sun, Oct 23, 2022 at 03:27:24PM +0200, Bastian Blank wrote: > On Sat, Oct 22, 2022 at 11:15:05AM +0200, Bastian Blank wrote: > > On Sat, Oct 22, 2022 at 10:59:30AM +0200, Bastian Blank wrote: > > > I would like to do some last minute changes to the linux package > > # Drop special case use of rcX as abi name > > > > While having the ability to distiguish between different RC, it changes > > the package names every time. > > Or should we just go for 0? This would also remove the ordering > weirdness a lot of people experienced. So instead of having linux-image-6.1.0-rc2-amd64 (for version 6.1~rc2-1~exp1) that would have been linux-image-6.1.0-0-amd64 and so sorting before linux-image-6.1.0-1-amd64 once we go to an unstable upload with ABI 1, correct? Your suggestion sounds like a sensible idea. The distinguishing about the rc releases would be easier if we retain the former variant, but I assume concerns for those experimental targeting uploads is less of an issue. Ben, opinions on it? Regards, Salvatore
Bug#1006500: marked as done (Missing bnx2x firmware 7.13.21.0 renders NIC unusable with Linux 5.16)
Hi, On Sat, Oct 29, 2022 at 12:31:18AM +0200, Christoph Anton Mitterer wrote: > Hey Bastian. > > Thanks for fixing. > > Is this going to be backported to bullseye? We do similar with intel-microcode updates, so maybe this is something we should consider to. But I think it's to early to think about a potential 20220913-1~deb11u1 via a bullseye point release. (just my personal opinion though). Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Hi Christoph, On Sat, Oct 29, 2022 at 12:36:01AM +0200, Christoph Anton Mitterer wrote: > Hey Salvatore. > > On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote: > > I did decide to still do so, so we can have the CVE fix migrate > > finally to testing (which took some time as well given there was the > > perl transition ongoing). > > Fine for me... I think it would be nice if there was a better mechanism > to have bugs shown in apt-listbugs out of the box, while still not > preventing migration to testing. There is one, involving the release team that they can force a specific version. In fact I was offlist in contact with Sebastian Ramacher from the release team who could have done so. In the end the src:linux was able to migrate on the next run, so downgrading the bug severity was the quickest action without need to let a release team emmber intervene. In the end, yes, the cleanest solution, assuming kernel-team considered the bug a RC bug, it would have been the right solution to just ask the release team to force the migration despite of the RC bug. > Oh and another off-topic thing: > > Right now the kernel image meta-packages depend on the (secure boot) > signed version of that... and it seems that these take always longer to > be available than the unsigned ones. > > However, if people want the nice service to have linux-image-amd64 > installed and pull in just the current package, they need to wait for > the signed one to become available - even if they don't use secure boot > at all. > > So question is,.. would it make sense to request that linux-image-amd64 > depends on the signed | unsigned version? No unfortunately we cannot do that. The reason is similar to what lead to https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 or caused bugs like #916927. In meanwhile furthermore linux-image-amd64 is anyway not anymore from a separate metapackage but built from linux-signed-amd64. The signed packages need always longer as this needs action of signing them trough a seprate manual process of ftp-masters. > > I did import already 6.0.5 and will upload next so we get the btrfs > > fix. And I have made the bug now as well again back RC severity. > > Thanks as always for your continued efforts. Thank you for those encouraging words! Salvatore
Bug#1014451: firmware-brcm80211: brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.txt on a Raspberry Pi 4
Hi, On Sat, Oct 29, 2022 at 12:18:16AM +0200, Diederik de Haas wrote: > Control: fixed -1 20220913-1 > > On Wednesday, 6 July 2022 12:46:16 CEST Enrique wrote: > > Package: firmware-brcm80211 > > Version: 20210315-3 > > > > I have installed pure Debian on a Raspberry Pi 4 and the kernel shows > > this error messages at boot: > > > > jul 06 11:57:25 alcatraz kernel: brcmfmac mmc0:0001:1: firmware: failed to > > load brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model > > B.txt (-2) > > This should be resolved with the above mentioned version, uploaded to > unstable. As the bug reported seems to only use Stable, I'm not marking it as > 'done' (yet). I'll leave that up to the maintainer. As a though on it: As the BTS can track multiple versions and mark a bug done in multiple versions in the sense of housekeeping cleanup the bugs it would rather close it (it can be closed a second time if the bug get fixed as well in stable with a respective backported version). Regards, Salvatore
Bug#1005400: closed by Diederik de Haas (Re: Bug#1005400: firmware-nonfree: Please package AMD SEV firmware.)
Hi, > Version: 20220913-1 > > On Saturday, 12 February 2022 21:40:30 CEST Sebastian Andrzej Siewior wrote: > > Version: 20210818-1 > > > > The orig contains already the AMD SEV firmware in the amd folder: > > | $ ls -lh amd > > | 33K Aug 18 13:08 amd_sev_fam17h_model0xh.sbin > > | 43K Aug 18 13:08 amd_sev_fam17h_model3xh.sbin > > > > Could this be please package? I have an AMD box asking for this. > > They are part of the above version, thus closing. Actually they are shipped with amd64-microcode instead: amd64-microcode (3.20220411.1) unstable; urgency=medium * Update package data from linux-firmware 20220411: * New microcode updates from AMD upstream (20220408) (closes: #1006444, #1009333) + New Microcode patches: sig 0x00830f10, patch id 0x08301055, 2022-02-15 sig 0x00a00f10, patch id 0x0a001058, 2022-02-10 sig 0x00a00f11, patch id 0x0a001173, 2022-01-31 sig 0x00a00f12, patch id 0x0a001229, 2022-02-10 + Updated Microcode patches: sig 0x00800f12, patch id 0x0800126e, 2021/11/11 * New AMD-SEV firmware from AMD upstream (20220308) Fixes: CVE-2019-9836 (closes: #970395) + New SEV firmware: Family 17h models 00h-0fh: version 0.17 build 48 Family 17h models 30h-3fh: version 0.24 build 15 Family 19h models 00h-0fh: version 1.51 build 3 * README: update for new release * debian: ship AMD-SEV firmware. Upstream license is the same license used for amd-ucode -- Henrique de Moraes Holschuh Fri, 15 Apr 2022 18:27:36 -0300 and amd64-microcode: /lib/firmware/amd/amd_sev_fam17h_model0xh.sbin amd64-microcode: /lib/firmware/amd/amd_sev_fam17h_model3xh.sbin Regards, Salvatore
Bug#1022823: nfs-kernel-server: /etc/default/nfs-kernel-server needs RPCNFSDOPTS
Source: nfs-common Source-Version: 1:2.6.1-1 Hi Alfredo, On Wed, Oct 26, 2022 at 01:48:58PM +, Alfredo Sola wrote: > Package: nfs-kernel-server > Version: 1:1.3.4-6 > Severity: wishlist > > Dear Maintainer, > > I needed a way to have rpc.nfsd bind to a specific IP address. > > The man page for rpc.nfsd documents a parameter exactly for this, plus some > others. > > At first signt, it seems that there is no Debian way to pass parameters to > rpc.nfsd. > > But there is; RPCNFSDOPTS can be set on /etc/default/nfs-kernel-server. It > will then > be sourced from /usr/lib/systemd/scripts/nfs-utils_env.sh, which sends its > variables > to /run/sysconfig/nfs-utils, from where they are read by nfs-server.service. > > Setting RPCNFSDOPTS solves this issue, so I am suggesting that it be added > (empty) > to /etc/default/nfs-kernel-server, along with a commentary pointing to the > rpc.nfsd > man page for information on parameters. Sincd version 1:2.6.1-1 /etc/nfs.conf settings can be done, or in dropins in /etc/nfs.conf.d/ so closing this bug with that version. Starting there you can set the host= and other parameters in the configuration file in the [nfsd] stanza. Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 serious Hi Christoph, Thanks for the quick feedback! On Thu, Oct 27, 2022 at 09:10:53PM +0200, Christoph Anton Mitterer wrote: > Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso > : > >According to your references there is the workaround of mounting with > >clear_cache,space_cache=v2 and convert the filesystem. > > > >What would one prevent doing so? > > v2 space cache is still rather new and had only recently some bug > that could have caused catastrophic data corruption... so not > everyone might want to switch. > > Similarly, people may want to have these filesystems mounted with > older kernels, whose v2 support isn't that good yet. Thanks, this is very important input. > >I'm downgrading the severity to important as it does not make the > >kernel unbootable or unstable on common hardware or all systems that a > >flavour is supposed to support. > > But now it a) migrates to testing an possibly leaves even more > systems with an unbootable system... b) with severity important, > people using e.g. apr-listbugs won't see it. > > OTOH, fixing the CVE is of course important, too. I did decide to still do so, so we can have the CVE fix migrate finally to testing (which took some time as well given there was the perl transition ongoing). I did import already 6.0.5 and will upload next so we get the btrfs fix. And I have made the bug now as well again back RC severity. Thank you! Regards, Salvatore
Bug#1022806: linux-image-5.10.0-19-amd64: amggpu unbootable problem persists
Hi Alexis, [Cc'ing Alex Deucher who addressed the previous regressions as well] On Wed, Oct 26, 2022 at 12:43:02PM +0200, Alexis Huxley wrote: > Package: src:linux > Version: 5.10.149-2 > Severity: serious > Justification: 1022025, 1022051, 1022062, 1022070, 1022097, 1022147 marked > serious so this marked serious too > > Dear Maintainer, > > Following other reports of post-grub kernel hangs on systems with > amdgpu, I waited for new release of linux-image-5.10.0-19-amd64, > which came quickly, but it did not solve the problem for me. > > Symptoms are: grub loads kernel and a few seconds into the > scrolling messages from the kernel the system hangs. The screen > is blank. The system is not accessible over the network. > > I reverted to linux-image-5.10.0-18-amd64 and all is okay again. > > The crash happens pretty early on: I believe X has not yet tried > to start. Both /var/log/syslog and /var/log/messages contain > no entries pertaining to the hanging boot (only messages from > where the earlier shutdown of 18 and the later start of 18). > > Output from lscpu is below. > > Automatically included output (e.g. kernel version) pertains > to linux-image-5.10.0-18-amd64, as I am unable to boot > linux-image-5.10.0-19-amd64. I don't remove it in case it contains > other pertinent information. > > I'm happy to test with other kernels or provide any requested > files/output. Would you be able to start own kenel builds, confirming it does not happen with 5.10.140 upstream but with 5.10.149, and isolate the breaking change? (Are you able to boot the kernel from bullseye-backports?) Regards, Salvatore
Bug#1022806: Bug#1022025: fixed in linux 5.10.149-2
Hi, On Thu, Oct 27, 2022 at 07:12:43PM +, inasprecali wrote: > On Thu, 27 Oct 2022 21:01:15 +0200 Salvatore Bonaccorso > wrote: > > Can you please fill a new bug for your issue, which would still > > be > > present in the 5.10.149-2 release? There are two users which > > report > > that they still have problems with the amdgpu driver still in > > 5.10.149-2. > > I think bug 1022806 is a recent one referring to 5.10.149-2 > specifically, which is about this same issue. I don't think there > is a need to report yet another bug about it. Yes this is indeed enough. Regards, Salvatore
Bug#1022025: fixed in linux 5.10.149-2
Hi On Thu, Oct 27, 2022 at 05:21:32PM +, inasprecali wrote: > On Thu, 27 Oct 2022 06:17:10 + Debian FTP Masters > wrote: > > Source: linux > > Source-Version: 5.10.149-2 > > Done: Salvatore Bonaccorso > > > > We believe that the bug you reported is fixed in the latest > version of > > linux, which is due to be installed in the Debian FTP archive. > > I'm sorry, but your belief seems to be mistaken, since we have > multiple reports o 5.10.149-2 still not booting with the amdgpu > driver. Can you please fill a new bug for your issue, which would still be present in the 5.10.149-2 release? There are two users which report that they still have problems with the amdgpu driver still in 5.10.149-2. Thanks already, let's folloup there with some questions. Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 important Hi, On Wed, Oct 26, 2022 at 10:23:35PM +0200, Christoph Anton Mitterer wrote: > Source: linux > Version: 5.19.6-1 > Severity: critical > Justification: breaks the whole system > > > Hi. > > 6.0.3 introduced a commit that causes (permanent) CPU soft lockups > for some people with btrfs filesystems, effectively breaking the > system, e.g. when booting. According to your references there is the workaround of mounting with clear_cache,space_cache=v2 and convert the filesystem. What would one prevent doing so? I'm downgrading the severity to important as it does not make the kernel unbootable or unstable on common hardware or all systems that a flavour is supposed to support. While I agree it is important to fix, this issue should not block the migration of the current kernel to address CVE-2022-2602. I will work next on importing the newer 6.0.y versions which include a fix for this issue as well. Regards, Salvatore
