Bug#1070367: linux-image-6.7.12-amd64: No WiFi
Control: merge -1 1070353 On Saturday, 4 May 2024 16:56:10 CEST Kurt Meyer wrote: > Package: src:linux > Version: 6.7.12-1 > Severity: important > > * What led up to the situation? > > Booting with the linux-image-6.7.12-amd64 kernel results in Wi-Fi not > working and Wi-Fi isn't even an option under network-manager. This issue > also manifested when I attempted to boot using the linux-image-6.6.15-amd64 > kernel, so the issue may have started with that kernel. This seems the exact same bug as 1070353, thus merging signature.asc Description: This is a digitally signed message part.
Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done
Control: severity -1 grave On 07 May 2024 19:35:30 +0200 Nicolas Noirbent wrote: > Package: how-can-i-help > Version: 18 > Severity: important > Tags: patch > > Running how-can-i-help outputs nothing past the initial banner, due to an > undefined variable: Which makes the package unusable, so upgrading severity accordingly > ``` > /usr/bin/how-can-i-help:338:in `': undefined local variable or method `autorm_header_done' for main:Object (NameError) > > autorm_header_done == 0 > ^^ > Did you mean? autorm_date > ``` Can confirm that error message > Looking at the code following it, this should probably be: > > ``` > autorm_header_done = 0 > ``` Can confirm that that made it work (properly) again. Thanks! signature.asc Description: This is a digitally signed message part.
Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions
Control: forcemerge -1 1054889 On Monday, 8 April 2024 10:44:12 CEST dada007 wrote: > I had an earlier report with this bug No need to have 2 bugs for the same problem, thus merging signature.asc Description: This is a digitally signed message part.
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Hi Cyril, On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote: > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64 > leads to losing some SMART information, at least as queried by munin (in > Debian 12) when it comes to sensors. Does the problem go away if you revert the following commits on top of -19? db6338f45971b4285ea368432a84033690eaf53c scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2 scsi: core: Move scsi_host_busy() out of host lock if it is for per-command cf33e6ca12d814e1be2263cb76960d0019d7fb94 scsi: core: Add struct for args to execution functions signature.asc Description: This is a digitally signed message part.
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
On Wednesday, 10 April 2024 15:32:02 CEST Cyril Brulebois wrote: > Cyril Brulebois (2024-04-10): > > Salvatore Bonaccorso (2024-04-10): > > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote: > > > > Does the problem go away if you revert the following commits on top of > > > > -19? > > > > > > > > db6338f45971b4285ea368432a84033690eaf53c > > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH > > > > handler > > > > > > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2 > > > > scsi: core: Move scsi_host_busy() out of host lock if it is for > > > > per-command > > > > > > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94 > > > > scsi: core: Add struct for args to execution functions > > > > Preparing that test right now, thanks Diederik. > > This doesn't build, but I didn't try very hard: > > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function > ‘sd_read_block_zero’: > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: > implicit declaration of function ‘scsi_execute_cmd’; did you mean > ‘scsi_execute_req’? [-Werror=implicit-function-declaration] Then it got troublesome even earlier then I expected ;-) If you do `gitk -- drivers/scsi/` on 'master', then you'll see a huge list of recent commits ... which probably didn't get backported all ... A lot of them landed in 6.8. That Salvatore could confirm the issue should help. Good luck, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'
Control: forcemerge -1 1065184 On Saturday, 13 April 2024 16:32:04 CEST Andreas Metzler wrote: > > If you agree, please merge these two bugs. > > FTR: Bug #1065184 is already fixed in git. > > FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is > installed. Thanks, then I'm merging the bugs. Today a "release to sid" commit was made, so this bug will be closed/fixed real soon now. signature.asc Description: This is a digitally signed message part.
Bug#1069077: es8316 driver causes kernel oops / panic on rockpro64
Control: retitle -1 es8316 driver causes kernel oops / panic on rockpro64
On Tuesday, 16 April 2024 01:37:57 CEST Forest wrote:
> The current debian unstable kernel causes a variety of failures that are not
> present in the bookworm kernel, on the RockPro64 single board computer.
> (This is an arm64 machine built upon the Rockchip rk3399 SoC.)
On Tuesday, 16 April 2024 05:21:13 CEST Forest wrote:
> Blacklisting the snd_soc_es8316 module in /etc/modprobe.d seems to restore
> kernel stability, as far as I have seen from half a dozen reboots.
Can you try the Debian Testing kernel, which is at version 6.6.15?
If the 6.6.15 kernel does work properly, then the 3 commits for
the es8316 driver in kernel 6.7 are the most likely suspects:
869f30782cda ASoC: es8316: Enable support for MCLK div by 2
a43c0dc1004c ASoC: es8316: Replace NR_SUPPORTED_MCLK_LRCK_RATIOS with
ARRAY_SIZE()
2f06f231f0bf ASoC: es8316: Enable support for S32 LE format
Attached you'll find 3 patches which revert those commits.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply patches to the
(6.7) kernel. If that makes the 6.7 kernel work properly again, we
likely have found the culprit for the kernel oops/panic.
Can you first try the Testing (6.6.15) kernel and if that works try
applying the attached patches to the 6.7 kernel?>From 407672343a738ede6f5e955e3afa57d16b37f4e6 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Tue, 16 Apr 2024 10:24:39 +0200
Subject: [PATCH 1/3] Revert "ASoC: es8316: Enable support for MCLK div by 2"
This reverts commit 869f30782cdad0a86598a700a864e4a2bf44f8cc.
---
sound/soc/codecs/es8316.c | 45 ++-
sound/soc/codecs/es8316.h | 3 ---
2 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index e53b2856d625..a1c3e10c3cf1 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -469,42 +469,19 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream,
u8 bclk_divider;
u16 lrck_divider;
int i;
- unsigned int clk = es8316->sysclk / 2;
- bool clk_valid = false;
-
- /* We will start with halved sysclk and see if we can use it
- * for proper clocking. This is to minimise the risk of running
- * the CODEC with a too high frequency. We have an SKU where
- * the sysclk frequency is 48Mhz and this causes the sound to be
- * sped up. If we can run with a halved sysclk, we will use it,
- * if we can't use it, then full sysclk will be used.
- */
- do {
- /* Validate supported sample rates that are autodetected from MCLK */
- for (i = 0; i < ARRAY_SIZE(supported_mclk_lrck_ratios); i++) {
- const unsigned int ratio = supported_mclk_lrck_ratios[i];
-
- if (clk % ratio != 0)
-continue;
- if (clk / ratio == params_rate(params))
-break;
- }
- if (i == ARRAY_SIZE(supported_mclk_lrck_ratios)) {
- if (clk == es8316->sysclk)
-return -EINVAL;
- clk = es8316->sysclk;
- } else {
- clk_valid = true;
- }
- } while (!clk_valid);
- if (clk != es8316->sysclk) {
- snd_soc_component_update_bits(component, ES8316_CLKMGR_CLKSW,
- ES8316_CLKMGR_CLKSW_MCLK_DIV,
- ES8316_CLKMGR_CLKSW_MCLK_DIV);
- }
+ /* Validate supported sample rates that are autodetected from MCLK */
+ for (i = 0; i < ARRAY_SIZE(supported_mclk_lrck_ratios); i++) {
+ const unsigned int ratio = supported_mclk_lrck_ratios[i];
- lrck_divider = clk / params_rate(params);
+ if (es8316->sysclk % ratio != 0)
+ continue;
+ if (es8316->sysclk / ratio == params_rate(params))
+ break;
+ }
+ if (i == ARRAY_SIZE(supported_mclk_lrck_ratios))
+ return -EINVAL;
+ lrck_divider = es8316->sysclk / params_rate(params);
bclk_divider = lrck_divider / 4;
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
diff --git a/sound/soc/codecs/es8316.h b/sound/soc/codecs/es8316.h
index 0ff16f948690..c335138e2837 100644
--- a/sound/soc/codecs/es8316.h
+++ b/sound/soc/codecs/es8316.h
@@ -129,7 +129,4 @@
#define ES8316_GPIO_FLAG_GM_NOT_SHORTED 0x02
#define ES8316_GPIO_FLAG_HP_NOT_INSERTED 0x04
-/* ES8316_CLKMGR_CLKSW */
-#define ES8316_CLKMGR_CLKSW_MCLK_DIV 0x80
-
#endif
--
2.43.0
>From c309d8cf7e3c192683beacb3781458a2f8bfef81 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Tue, 16 Apr 2024 10:24:55 +0200
Subject: [PATCH 2/3] Revert "ASoC: es8316: Replace
NR_SUPPORTED_MCLK_LRCK_RATIOS with ARRAY_SIZE()"
This reverts commit a43c0dc1004cbe2edbae9b6e6793db71f6896449.
---
sound/soc/codecs/es8316.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index a1c3e10c3cf1..09fc0b25f600 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -27,6 +27,7 @@
* MCLK/LRCK ratios, but we also add ratio 400, which is commonly used
Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
On Tuesday, 16 April 2024 16:41:46 CEST Roland Rosenfeld wrote:
> A.B says on stackexchange, that both patches have to be reverted to
> make this working again.
>
> I did not yet try this out myself, because I use precompiled kernels
> for ages and have to re-learn again how to patch and build a kernel.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply (the attached) patches
HTH>From 21f7e476d0afe832f6656b917b976c6efe6b24f3 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Tue, 16 Apr 2024 16:53:16 +0200
Subject: [PATCH 1/2] Revert "net: usb: ax88179_178a: avoid the interface
always configured as random address"
This reverts commit fc77240f6316d17fc58a8881927c3732b1d75d51.
---
drivers/net/usb/ax88179_178a.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e0e9b4c53cb0..d837c1887416 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1273,8 +1273,6 @@ static void ax88179_get_mac_addr(struct usbnet *dev)
if (is_valid_ether_addr(mac)) {
eth_hw_addr_set(dev->net, mac);
- if (!is_local_ether_addr(mac))
- dev->net->addr_assign_type = NET_ADDR_PERM;
} else {
netdev_info(dev->net, "invalid MAC address, using random\n");
eth_hw_addr_random(dev->net);
--
2.43.0
>From 75b1a1f4d80ca93591e7833c0683a651d54edc38 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Tue, 16 Apr 2024 16:53:36 +0200
Subject: [PATCH 2/2] Revert "net: usb: ax88179_178a: avoid two consecutive
device resets"
This reverts commit 5c4cbec5106d2f3c055ad138165e60a73f5b355c.
---
drivers/net/usb/ax88179_178a.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index d837c1887416..5a1bf42ce156 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1315,6 +1315,8 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf)
netif_set_tso_max_size(dev->net, 16384);
+ ax88179_reset(dev);
+
return 0;
}
--
2.43.0
signature.asc
Description: This is a digitally signed message part.
Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2
Control: tag -1 -moreinfo +upstream Control: forwarded -1 https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWTTGfKJSRxY=ht...@mail.gmail.com/ On Monday, 22 April 2024 10:32:00 CEST Jeremy Lainé wrote: > Over the weekend I reported the issue to the linux-bluetooth mailing > list, which led to bisecting the issue down to a single commit: > > https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWT > TGfKJSRxY=ht...@mail.gmail.com/ Nice work :) signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Sunday, 16 June 2024 15:20:05 CEST Leith Bade wrote: > I need to work out how to submit these fixes to the Linux device tree > maintainers. My experience is primarily/only with Rockchip based devices/SoCs and their upstream development process, but it may help wrt MediaTek's. - If you think something is wrong, determine with ``git blame`` which commit added that (presumably) incorrect statement(s) - In the commit message, you'll often find a ``Link: `` line which points to the discussion of that change and should point to https://lore.kernel.org/ - If there isn't a ``Link: `` line, you can put the title of the commit in the 'lore' search box and search through all the archives; reasonable chance that'll point you to the discussion thread(s) - Read through the whole discussion as it may already provide answers to questions you may have - At the bottom of each 'lore' page, you'll find instructions on how to reply in case you have further questions/disagree/etc https://lists.infradead.org/mailman/listinfo/linux-mediatek is where patch discussion takes place (which gets 'archived' on lore.k.o). You may want to subscribe to that list to get an idea how the upstreaming process takes place. Keep in mind that the volume of that/those list(s) can be huge and that your email address will be publicly/wildly known (just like on Debian bug reports). https://git-send-email.io/ is probably worth a look and also the ``b4`` tool. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#973364: firmware-linux-free: Maybe missing soft dependency on wireless-regdb
On Thu, 29 Oct 2020 14:22:16 +0100 Axel Beckert wrote: > Package: firmware-linux-free > Version: 20200122-1 > > now that "iw" dropped the dependency on "crda" (see > https://bugs.debian.org/972994), "wireless-regdb" gets uninstalled, too, > as it was only pulled in via dependency by crda, at least on some of my > machines. FWIW: iw 5.9-3 added wireless-regdb as Recommends signature.asc Description: This is a digitally signed message part.
Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file
Source: linux Version: 6.9.2-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 When removing or 'even' purging a linux-image- package, it reports the following issue: rmdir: failed to remove '/lib/modules/': Directory not empty The reason for that is that there's still a ``modules.weakdep`` file. It seems to me that at least with purging that file should be removed and subsequently the ``/lib/modules/`` dir. FWIW: I do not have any DKMS package which could also result in the inability to remove the modules dir. - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZnVlCwAKCRDXblvOeH7b bvdqAPwOCZQoQ5xXUbW+FkytY5Ovj5xoPizPFOWdFTvtaXro0QD/RhTTHvmL4cZ4 GfAOEDPN4Rv+vnze+lNZt+xCrTSa4AY= =QCxl -END PGP SIGNATURE-
Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file
Control: found -1 6.6.15-1 On Friday, 21 June 2024 13:41:38 CEST Christoph Berg wrote: > I just had the same problem on linux-image-6.6.15-amd64. Updating found version accordingly. > > It seems to me that at least with purging that file should be removed > > and subsequently the ``/lib/modules/`` dir. > > TBH, I'd even argue plain "remove" should remove the debris from the > modules directory, it's not like there's anything of value in the > modules.* files left behind. I didn't have that many kernels installed, so I only verified it with 1 and for that I used 'purge'. But I'm inclined to agree that remove should remove that file too. signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 07:10:48 CEST Leith Bade wrote:
> I finished my first round of testing the new kerned on my BPI-R3 board.
This is more extensive testing then I normally see. Nice :-)
> This likely due to my unfamiliarity with building the Debian kernel.
Given your interest (similar to mine ~2 y/o) and skill set (higher then mine),
it's probably worth learning that ;-)
> So instead after constructing a working testing/sid root filesystem on an
> SD card via debootstrap I have installed and tested a v6.10 kernel build
> that Diederik supplies me with. The kernel version string for this is:
> Linux version 6.10-rc3+unreleased-arm64 (debian-ker...@lists.debian.org)
> (aarch64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils
> for Debian) 2.42) #1 SMP Debian 6.10~rc3-1~cknow (2024-04-24)
I plan to build a 6.10~rc5 soon ...
> The device tree is a modified version of the
> upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb"
Can you share those changes? I analyzed and enabled modules purely on what's
available upstream.
> The device tree requires applying various overlay files
> ("mt7986a-bananapi-bpi-r3-nor.dtbo", "mt7986a-bananapi-bpi-r3-nand.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-sd.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-emmc.dtbo") to select the correct
> configuration for the attached storage chips. These chips are
> enabled/disabled by the boot selection DIP switch labelled "SW1" on the
> board. You can choose between the NOR or NAND chip, as well as the SD card
> slot or eMMC chip. So the combinations are: NOR + SD, NOR + eMMC, NAND +
> SD, NAND + eMMC. Since I was booting from an SD card I have not yet tested
> the eMMC chip.
I forgot to analyze the dtbo files and consequently added the needed kernel
modules for it. Will include that in my 6.10~rc5 build.
> The kernel boots successfully and I make it all the way to the login screen
> via serial as well as the SSH server working.
\o/
> All tested devices work except for:
>
> SoC Hardware Accelerated Cryptography
> Device Tree name: "crypto: crypto@1032"
> DT compatible: "inside-secure,safexcel-eip97"
> Issue:
>
> In the kernel dmesg boot log there are a variety of errors like:
> > [8.910388] alg: ahash: safexcel-sha384 test failed (wrong result) on
> > test vector 1, cfg="init+update+final aligned buffer"
> > [8.921577] alg: self-tests for sha384 using safexcel-sha384 failed
> > (rc=-22)
>
> These errors are repeated for: "safexcel-sha384" "safexcel-sha512"
> "safexcel-hmac-sha384" "safexcel-hmac-sha512"
> ...
> I did not see this error in the Ubuntu v6.8 kernel, so I will be interested
> to test the Debian v6.8 kernel once I get it building to see if this is a
> regression in the v6.10 kernel.
There have been *no* upstream commits to ``drivers/crypto/inside-secure/``
since 6.8, so that would surprise me. Possible causes:
- Ubuntu has a patch for this
- Ubuntu's kernel config enables options which the Debian kernel doesn't
The latter is more likely, which can mean that upstream's kernel module is
missing some depends/selects? This is speculation though.
> SoC SNFI Serial Flash Bus
> ...
> The fix here is to build the "spi-mtk-snfi" module from the MTD drivers.
Ack. CONFIG_SPI_MTK_SNFI (tristate)
> SPIM NAND Chip
> ...
> The fix here is to build the "spi-nand" module from the MTD drivers.
Ack. CONFIG_MTD_SPI_NAND (tristate)
> SFP RJ45 2.5 GbE Modules
> ...
> kernel finds them in the boot log:
> > [2.744506] sfp sfp-1: Host maximum power 3.0W
> > [2.768976] sfp sfp-2: Host maximum power 3.0W
> > [3.105275] sfp sfp-2: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070133 dc 240507
> > [3.135654] sfp sfp-1: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070134 dc 240507
>
> But the resulting eth0/eth1 devices do not work. Searching on the Banana Pi
> forum, and then the kernel net mailing list it appears that patches to
> support these devices have not yet been accepted upstream.
Note that for inclusion in the Debian kernel the device should be *usable*.
It does not require that everything works perfectly.
If you learn to build a Debian kernel, there's ``debian/patches`` where you
could put those patches in so they get included in your build. You could then
share your test finding with the upstream discussion of those patches and
ideally add a "Tested-by: you " which helps to get things
merged upstream (which then will find its way into a future Debian kernel)
> 2.4 GHz & 5 GHz WiFi
> Device Tree name: "wifi: wifi@1800"
> DT compatible: "mediatek,mt7986-wmac"
> Issue:
> Initially the kernel boot log was saying the required firmware files could
> not be found:
> ...
> > [ 33.775740] mt798x-wmac 1800.wifi: probe with driver mt798x-wmac
> > failed with error -110
>
> I then installed the "linux-firmware" package from testing/sid APT
... so close ...
> repository, but the error message persisted. Addi
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:43:38 CEST Leith Bade wrote:
> On Mon, 24 Jun 2024 at 22:10, Leith Bade wrote:
> > > After inspecting the /lib/firmware directory, it seems the APT package
> > >
> >> > "firmware-misc-nonfree" has firmware for older MediaTek chips, but is
> >> > missing files for ant MT79xx including MT7981 and MT7986.
> >>
> >> d1c24e6cfa18 ("mediatek: Synchronize with 20230625's WHENCE file")
> >> added those files and has been released to *experimental* in version
> >> 20230625-3~exp2. You'd need the firmware-mediatek package though.
> >
> > Thanks for finding this. The various firmware packages and their differing
> > names is highly confusing. I wonder if there is some sort of script that
> > can go find the right packages for your initrd.
``apt-file search ``
is the usual way to find which file is in what package
> So I removed linux-firmware-upstream, then installed firmware-mediatek
> from experimental, then did an update-initramfs. After rebooting the WiFi
> is still working.
Cool :)
> What other testing is required before this can make its way into unstable?
I don't know; that's up to the kernel team.
(The above mentioned commit is from me as well as the commit that split out
the mediatek firmware into its own package, but I'm not part of the team)
signature.asc
Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:10:18 CEST Leith Bade wrote: > On 24 Jun 2024 at 20:32, Diederik de Haas wrote: > > > This likely due to my unfamiliarity with building the Debian kernel. > > I will eventually manage to figure it out. Part of the problem is that > there is a lot of different advice around the place and a lot of it is out > of date. https://kernel-team.pages.debian.net/kernel-handbook/ or the offline version in the debian-kernel-handbook package *should* give you the proper advice. If not, then that's a bug. > > > The device tree is a modified version of the > > > upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb" > > > > Can you share those changes? I analyzed and enabled modules purely on > > what's available upstream. > > Yes, I just need to tidy them up into a series of git commits. I don't > think I had to change anything module related, Ok, I use the "compatible" string to figure out what modules are needed. > the main issue was the GPIO pin conflicts. I plan to coordinate with the > original author of the file (who is on the Banana Pi forum) to work towards > getting them submitted to Linux. Awesome > Thanks for the advice. The patches I have seen are fairly minor - mainly > adding another special case to match the SFP name string. > > I think the upstream concern stems from the way these vendors of these > cheap SFP modules are just programming so many different model strings to > rebadge them as they see fit. There is even a documented case where two > devices from two different vendors have the exact same ID strings, but two > different incompatible PHY chips inside. sigh. I can understand upstream's concern. > > I'm still missing a "Tested-by:" tag for my changes ;-P > > Tested-by: Leith Bade Haha, thanks :) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1067858: reset SuperSpeed USB device number 2 using xhci_hcd
On Saturday, 22 June 2024 13:02:24 CEST Pierre Tomon wrote: > Control: tags -1 + fixed-upstream > > This bug is now fixed upstream. > > Commit: 7926d51f73e0 - scsi: sd: Use READ(16) when reading block zero on > large capacity disks Releases: v6.1.95, v6.6.35 and v6.9.6 That's awesome. Great work! signature.asc Description: This is a digitally signed message part.
Bug#1074253: hut: Upstream moved to https://sr.ht/~xenrox/hut/
Package: hut Version: 0.5.0-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The 'homepage' now has the following warning: Warning: this project has migrated to https://git.sr.ht/~xenrox/hut But without the ``.git`` part fits better as (new) homepage. - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hut depends on: ii libc6 2.38-13 hut recommends no packages. hut suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZnqVKwAKCRDXblvOeH7b bgpeAQD9VSpiw9M0e7i0HMQv8YZsEAi6Qp5vejfSpcTslfJkqgD/To0G6QxGF2V4 IrEeNEe4KM/YSWh7kxaZVLIKs6w24Qo= =ks5Z -END PGP SIGNATURE-
Bug#1063161:
Control: reopen -1
Control: found -1 6.8.9-1
Control: found -1 6.9.2-1~exp1
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote:
> Le 2024-05-23 17:12, Nathan MALO a écrit :
> > Thank you very much for enabling those two features in the kernel.
> > Your work is much appreciated !
> >
> > Maybe I am missing something but I've download the 6.8.9-1 package from
> > and while fiddling with it, I was not able to find the keys
> > CONFIG_AMDTEE and CONFIG_AMD_PMF in the /boot/config file.
> >
> > Am I missing something ?
> > Maybe the package was not rebuilt with this new configuration ?
>
> We are just lacking a configuration symbol. Diederik, starting with
> linux 6.8 AMD PMF requires TEE. Do you want me to send a MR?
As Vincent remarked, that means the bug is not fixed, so reopening it.
@Vincent: Can you add a Closes: #1063161 to ``debian/changelog``?
And while you're at it, add the following line to the commit message?
Fixes: 7399dff4b4af ("[amd64] drivers/platform/x86/amd/pmf: Enable AMD_PMF as
module")
> Thanks for the report,
Indeed. Sorry for missing that.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1072459: wxsvg: FTBFS with ffmpeg 7.0: me diadec_ffmpeg.cpp:168:75: error: ‘AVCodecPa rameters’ {aka ‘struct AVCodecParameters ’} has no member named ‘channels’
Control: tag -1 +upstream +fixed-upstream On 2 Jun 2024 15:27:58 +0200 Sebastian Ramacher wrote: > Source: wxsvg > Version: 2:1.5.24+dfsg-2.1 > Severity: important > Tags: trixie sid ftbfs > Usertags: ffmpeg-7.0 > > during a rebuild of the reverse dependencies for the transition to > ffmpeg 7.0, your package failed to build There's a new upstream version 1.5.25 which contains a compatibility with ffmpeg 7.0 fix, so releasing a new upstream version would fix this bug. https://sourceforge.net/p/wxsvg/git/ci/7e7f7cd017591da772399125669c402dce9bbea2/ signature.asc Description: This is a digitally signed message part.
Bug#1072435: minidlna: FTBFS with ffmpeg 7.0 : libav.h:177:36: error: ‘AVCodecParameters ’ has no member named ‘channels’
Control: forwarded -1 https://sourceforge.net/p/minidlna/bugs/363/
https://sourceforge.net/p/minidlna/git/merge-requests/58/
Control: tag -1 patch
On Wednesday, 5 June 2024 14:43:17 CEST Diederik de Haas wrote:
> Control: tag -1 upstream
> Control: forwarded -1 https://sourceforge.net/p/minidlna/bugs/363/
>
> On 2 Jun 2024 15:22:21 +0200 Sebastian Ramacher wrote:
> > during a rebuild of the reverse dependencies for the transition to
> > ffmpeg 7.0, your package failed to build
>
> There's an upstream bug for it, but not yet a solution.
> Updating metadata accordingly.
And there's also an upstream merge request for it.
Attaching a patch to add that patch to the Debian package.
Or you can use https://salsa.debian.org/debian/minidlna/-/merge_requests/7
which is a MR with the attach patch applied.
Cheers,
Diederik>From 1a77e07ca0f2dce15b756ac45d192ea12e8ecace Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Wed, 26 Jun 2024 13:12:09 +0200
Subject: [PATCH] d/patches: Add 16-Add-compatibility-with-FFMPEG-7.0.patch
Closes: #1072435
Link: https://bugs.debian.org/1072435
---
...16-Add-compatibility-with-FFMPEG-7.0.patch | 40 +++
debian/patches/series | 1 +
2 files changed, 41 insertions(+)
create mode 100644 debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
diff --git a/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch b/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
new file mode 100644
index 000..f56de1c
--- /dev/null
+++ b/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
@@ -0,0 +1,40 @@
+From 243cf2dd27ebcaf4ef1093c79b96077378d52018 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Robert-Andr=C3=A9=20Mauchin?=
+Date: Sat, 4 May 2024 18:36:58 +0200
+Subject: [PATCH] Add compatibility with FFMPEG 7.0
+Origin: other, https://sourceforge.net/u/eclipseo/minidlna/ci/243cf2dd27ebcaf4ef1093c79b96077378d52018/
+Bug-Debian: https://bugs.debian.org/1072435
+
+channel_layout has been replaced with ch_layout
+---
+ libav.h | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libav.h b/libav.h
+index b69752c..fae094b 100644
+--- a/libav.h
b/libav.h
+@@ -117,6 +117,8 @@ typedef AVMetadataTag AVDictionaryEntry;
+ # endif
+ #endif
+
++#define HAVE_CH_LAYOUT (LIBAVUTIL_VERSION_INT >= ((57<<16)+(28<<8)+100))
++
+ static inline int
+ lav_open(AVFormatContext **ctx, const char *filename)
+ {
+@@ -174,7 +176,11 @@ lav_get_interlaced(AVStream *s)
+ #define lav_codec_tag(s) s->codecpar->codec_tag
+ #define lav_sample_rate(s) s->codecpar->sample_rate
+ #define lav_bit_rate(s) s->codecpar->bit_rate
++#if HAVE_CH_LAYOUT
++#define lav_channels(s) s->codecpar->ch_layout.nb_channels
++#else
+ #define lav_channels(s) s->codecpar->channels
++#endif
+ #define lav_width(s) s->codecpar->width
+ #define lav_height(s) s->codecpar->height
+ #define lav_profile(s) s->codecpar->profile
+--
+2.45.2
+
diff --git a/debian/patches/series b/debian/patches/series
index 05164a6..83ea738 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@
13-spelling-and-typos.patch
14-autoupdate.patch
15-thumbnails.patch
+16-Add-compatibility-with-FFMPEG-7.0.patch
--
2.45.2
signature.asc
Description: This is a digitally signed message part.
Bug#1035655: /usr/bin/startplasmamobile: 22: [[: not found
On Wed, 11 Oct 2023 01:53:04 -0400 Yifei Zhan wrote: > It seems like this issue has been addressed by upstream and the next release > will be depending on bash: > > startplasmamobile: Specify bash in the shebang > https://invent.kde.org/plasma/plasma-mobile/-/commit/cdeba03d5ea807d8cfc30661f7437c5db8770ebe And rightfully reverted later and later still, properly fixed: https://invent.kde.org/plasma/plasma-mobile/-/commit/7b310c8076eaccd9bce5366cd80933be7e948e11 signature.asc Description: This is a digitally signed message part.
Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Control: tag -1 upstream, fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/11360
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837
On 14 Jun 2024 13:36:54 +0200 Emilio Pozuelo Monfort wrote:
> Control: reassign -1 mesa 24.1.1-2
> Control: affects -1 kuserfeedback
> Control: retitle -1 mesa: fails to initialize OpenGL on s390x: Unexpected
> format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
>
> Actually this looks like a regression in mesa in 24.1. A few rdeps are
> failing their autopkgtests with the same PIPE_FORMAT_X8B8G8R8_SRGB error,
> e.g.:
>
> https://ci.debian.net/packages/k/kodi/testing/s390x/47675600/
> https://ci.debian.net/packages/o/openscad/testing/s390x/47689316/
This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
("dri: Fix BGR format exclusion"), which I attached for your convenience.
I haven't tried it as I don't have access to a s390x machine, so if
someone can verify it, that would be most welcome.
Cheers,
Diederik>From 5ca85d75c05de9df7c3170122dfdb04bc795b43a Mon Sep 17 00:00:00 2001
From: Daniel Stone
Date: Fri, 21 Jun 2024 11:24:31 +0100
Subject: [PATCH] dri: Fix BGR format exclusion
Origin: upstream, https://gitlab.freedesktop.org/mesa/mesa/-/commit/5ca85d75c05de9df7c3170122dfdb04bc795b43a
Bug-Debian: https://bugs.debian.org/1072971
The check we had for BGR vs. RGB formats was testing completely the
wrong thing. Fix it so we can restore the previous set of configs we
expose to the frontend, which also fixes surfaceless platform on s390x.
Signed-off-by: Daniel Stone
Fixes: ad0edea53a73 ("st/dri: Check format properties from format helpers")
Closes: mesa/mesa#11360
Part-of:
---
src/gallium/frontends/dri/dri_screen.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/frontends/dri/dri_screen.c b/src/gallium/frontends/dri/dri_screen.c
index 97d11f324ee0b..2e9ce01147a89 100644
--- a/src/gallium/frontends/dri/dri_screen.c
+++ b/src/gallium/frontends/dri/dri_screen.c
@@ -386,17 +386,21 @@ dri_fill_in_modes(struct dri_screen *screen)
uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
/* Expose only BGRA ordering if the loader doesn't support RGBA ordering. */
- if (!allow_rgba_ordering &&
- util_format_get_component_shift(pipe_formats[f],
- UTIL_FORMAT_COLORSPACE_RGB, 0)
+ if (!allow_rgba_ordering) {
+ unsigned sh_ax = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+ unsigned sh_b = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
#if UTIL_ARCH_BIG_ENDIAN
- >
+ unsigned sz_b = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
+
+ if (sz_b + sh_b == sh_ax)
+ continue;
#else
- <
+ unsigned sz_ax = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+
+ if (sz_ax + sh_ax == sh_b)
+ continue;
#endif
- util_format_get_component_shift(pipe_formats[f],
- UTIL_FORMAT_COLORSPACE_RGB, 2))
- continue;
+ }
if (!allow_rgb10 &&
util_format_get_component_bits(pipe_formats[f],
--
GitLab
signature.asc
Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Control: tag -1 patch On Wednesday, 26 June 2024 03:04:15 CEST Leith Bade wrote: > Diederik provided me with a new v6.10 kernel build to try: > [0.00] Linux version 6.10-rc5+unreleased-arm64 ( > debian-ker...@lists.debian.org) (aarch64-linux-gnu-gcc-13 (Debian > 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP Debian > 6.10~rc5-1~cknow (2024-04-24) > > I can confirm the NAND flash chip is now recognised, and shows up in > /dev/mtd*: > [ 11.027448] spi-nand spi0.0: Winbond SPI NAND was found. > [ 11.027469] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: > 2048, OOB size: 64 > > I also finished testing the other UART ports on the CON1 header and can > confirm both work. I am working on getting more bits and pieces so I can > test the I2C, SPI, and audio codec pins. I submitted a MR to fix this bug with my changes here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 signature.asc Description: This is a digitally signed message part.
Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Control: tag -1 -patch
On Friday, 28 June 2024 09:55:24 CEST Michel Dänzer wrote:
> > This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
> > ("dri: Fix BGR format exclusion"), which I attached for your convenience.
>
> Beware that this commit caused a regression on little endian platfors:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/11398
Thanks for that. Let's remove the patch tag then.
The discussion has been reopened in the forwarded MR:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837#note_2470033
signature.asc
Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > AMD has introduced a feature called Power Management Framework. > See here for more info: https://www.phoronix.com/news/AMD-PMF-Linux-Driver > > It seems that this module is not included in the Debian Linux Kernel. With the upload of 6.9.7 this module now is available in the kernel. AFAIK one of my systems should benefit from this too: MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 CPU(/APU?): AMD Ryzen 5 5500GT amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) power-profiles-daemon: 0.21-2 So I think I'm all set... > A bit of context: > The power-profiles-daemon software gained recently support for amd-pstate > driver, and also gained support to handle simultaneously cpu driver > (amd-pstate) and platform driver (amd-pmf). > (https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_request > s/127). It seems that the power-profiles-daemon in unstable do not include > the commit that allows to handle both drivers at the same time. > So I've installed the power-profile-daemons for jammy from this Ubuntu PPA > (https://launchpad.net/~superm1/+archive/ubuntu/ppd/+packages). The version in that PPA is 0.21-1, so the Debian Testing/Unstable version should be fine now? > And when I list the existing power-profiles I get the following: > > user@machine:> sudo powerprofilesctl > performance: > CpuDriver:amd_pstate > Degraded: no > > * balanced: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > power-saver: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > This (PlatformDriver: placeholder) indicates that the AMD_PMF module is not > included in the kernel. So I booted into the 6.9.7 kernel and ran that command ... only to be greeted with the exact same output ... So I verified whether AMD_PMF was indeed included ... and it was. Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I did NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it was: ```sh # lsmod | grep amd amd_pmf61440 0 amdtee 28672 0 amd_sfh49152 1 amd_pmf tee45056 2 amd_pmf,amdtee amdgpu 12845056 0 amd_atl40960 1 edac_mce_amd 28672 0 kvm_amd 184320 0 kvm 1343488 1 kvm_amd amdxcp 12288 1 amdgpu drm_exec 12288 1 amdgpu gpu_sched 65536 1 amdgpu drm_buddy 20480 1 amdgpu drm_suballoc_helper12288 1 amdgpu drm_display_helper262144 1 amdgpu drm_ttm_helper 12288 1 amdgpu ttm 102400 2 amdgpu,drm_ttm_helper drm_kms_helper249856 2 drm_display_helper,amdgpu platform_profile 12288 2 amd_pmf,asus_wmi i2c_algo_bit 12288 1 amdgpu ccp 155648 2 kvm_amd,amdtee video 73728 2 asus_wmi,amdgpu button 24576 1 amd_pmf drm 737280 11 gpu_sched,drm_kms_helper,drm_exec,drm_suballoc_helper,drm_display_helper,drm_buddy,amdgpu,drm_ttm_helper,ttm,amdxcp hid 172032 3 usbhid,hid_generic,amd_sfh gpio_amdpt 16384 0 gpio_generic 20480 1 gpio_amdpt ``` Ran ``powerprofilesctl`` again ... and saw no change (thus still 'placeholder') > There may be technical limitations that I am not aware of. I would have expected that amd_pmf and related modules would be loaded automatically. And ofc that it would actually work. The only real thing that I can think off that could interfere (from my side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. What other causes could there be that makes it not work properly? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 17:49:40 CEST Mario Limonciello wrote: > On 6/28/2024 10:41, Diederik de Haas wrote: > > On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > >> AMD has introduced a feature called Power Management Framework. > > > > With the upload of 6.9.7 this module now is available in the kernel. > > > AFAIK one of my systems should benefit from this too: > > MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 > > CPU(/APU?): AMD Ryzen 5 5500GT > > amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) > > firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) > > power-profiles-daemon: 0.21-2 > > > > So I think I'm all set... > > I don't think so. I've never heard of this actually used in a desktop > board. It's for mobile designs AFAIK. I can understand that the initial/original goal/target was mobile. But is there a(ny) technical reason why it couldn't also support 'desktop' systems? IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> The power-profiles-daemon software gained recently support for amd-pstate > >> driver, and also gained support to handle simultaneously cpu driver > >> (amd-pstate) and platform driver (amd-pmf). > > > > The version in that PPA is 0.21-1, so the Debian Testing/Unstable version > > should be fine now? > > Yes. Excellent > >> And when I list the existing power-profiles I get the following: > >> > >> user@machine:> sudo powerprofilesctl > >> > >>performance: > >> CpuDriver:amd_pstate > >> Degraded: no > >> > >> * balanced: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >>power-saver: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >> This (PlatformDriver: placeholder) indicates that the AMD_PMF module is > >> not included in the kernel. > > > > So I booted into the 6.9.7 kernel and ran that command ... only to be > > greeted with the exact same output ... > > > > So I verified whether AMD_PMF was indeed included ... and it was. > > Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I > > did > > NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... > > > > So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it > > was: > > ... > > Ran ``powerprofilesctl`` again ... and saw no change (thus still > > 'placeholder')> > >> There may be technical limitations that I am not aware of. > > > > I would have expected that amd_pmf and related modules would be loaded > > automatically. And ofc that it would actually work. > > > > The only real thing that I can think off that could interfere (from my > > side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. > > > > What other causes could there be that makes it not work properly? > > If there is no matching PMF ACPI device the driver won't automatically load. Ok. I might be able to convince Asus to add it, but I can also configure my system to 'modprobe' it on boot up. > The way that it works is that the OEM will set bits in their BIOS for > that ACPI device indicating which "AMD_PMF" features they support. > That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > notifications. I have no idea what those things are, but I can research it ... > I think someone with a laptop that supports PMF would be best to confirm > this. Framework 13 AMD and Framework 16 both support it. It would be great if someone with such a system can confirm whether it now can/ does work for the original target. But I think everyone and the planet would benefit from a (more) energy efficient system, regardless if it (normally) runs on batteries or not. In my case, this system will likely be my NAS, so idle 99(.9)% of the time and (in the future) on 24/7, so I'm extra motivated to make it consume as little energy as possible. Cheers and thanks for your fast response, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > On 6/28/2024 11:18, Diederik de Haas wrote: > >> I don't think so. I've never heard of this actually used in a desktop > >> board. It's for mobile designs AFAIK. > > > > I can understand that the initial/original goal/target was mobile. > > But is there a(ny) technical reason why it couldn't also support 'desktop' > > systems? > > IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > > It needs information about the hardware thermal design to change the > correct coefficients. Isn't that something that AMD would know? > For example just changing the sPPT or fPPT without the appropriate > thermal headroom will cause the SOC to go into thermal throttling > prematurely and hurt your performance. > > That's why OEMs encode this information in their EC or in the BIOS and > advertise it in the PMF ACPI tables what they can do. > > > Ok. I might be able to convince Asus to add it, but I can also configure > > my system to 'modprobe' it on boot up. > > Loading it with modprobe doesn't do anything if there is no ACPI device > to bind to. It's just like having it compiled into your kernel and it > not binding to any device. Ok, understood. I'm not too positive I could convince Asus to add that to their 'BIOS', but I can try. > Like I said; I've never seen it on a desktop. Because of what it's > intended to do in it's current form, I think it's unlikely that it would > be added there. Understood. Hopefully this does make AMD aware that non-laptop/mobile devices could (or should!) be a potential target too. Even if it won't directly benefit me now, that would still be a win :) > >> The way that it works is that the OEM will set bits in their BIOS for > >> that ACPI device indicating which "AMD_PMF" features they support. > >> That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > >> notifications. > > > > I have no idea what those things are, but I can research it ... > > > > But I think everyone and the planet would benefit from a (more) energy > > efficient system, regardless if it (normally) runs on batteries or not. > > In my case, this system will likely be my NAS, so idle 99(.9)% of the time > > and (in the future) on 24/7, so I'm extra motivated to make it consume as > > little energy as possible. > > > > Keep in mind PPD does multiple things based on what the hardware > advertises support for. > > For your system, you are using amd-pstate in active mode. I can see > this from your powerprofilesctl output. This will make sure the SoC is > properly biased towards efficiency or performance based on your preference. > > It will operate under the limitations of the coefficients programmed by > the firmware at max load (so you can't change PPT), but when idle it > shouldn't consume more power than needed. > > There is a kernel patch series coming in kernel 6.11 for "Core > performance boost" which will let you turn on/off boost above nominal > frequency. You can turn it off, and then CPU cores won't ever go above > nominal frequency. > > I'm proposing that we would leave boost on for PPD balanced and > performance states. For PPD power-saver we would turn it off. > > This is merged in the PPD tree and unless anyone complains will be part > of the next PPD release. > > The other thing that could be really interesting to do for power savings > purposes is to put certain tasks only the non-preferred cores or tune > EPP towards efficiency on cores running long running tasks that don't > need to finish quickly. > > In my opinion this is going to open up a lot of potential for sched-ext. > and for systemd. Userspace can read the core rankings and when starting > up and moving tasks around adjust EPP, boost and which cores tasks run > on. It's a lot of complicated work ahead though with a lot of profiling > needed. I hadn't used PPD before, so I'll experiment with it. Looks like I have lots of research to do ;-) Thanks for your detailed response :-) Hack (and Save) the Planet! Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:24:58 CEST Mario Limonciello wrote: > On 6/28/2024 12:05, Diederik de Haas wrote: > > On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > >> On 6/28/2024 11:18, Diederik de Haas wrote: > >>>> I don't think so. I've never heard of this actually used in a desktop > >>>> board. It's for mobile designs AFAIK. > >>> > >>> I can understand that the initial/original goal/target was mobile. > >>> But is there a(ny) technical reason why it couldn't also support > >>> 'desktop' > >>> systems? > >>> IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> > >> It needs information about the hardware thermal design to change the > >> correct coefficients. > > > > Isn't that something that AMD would know? > > I have software interfaces that I can use to tell you what APU > coefficient is currently programmed. I can tell you what the MAX an APU > can support is but I can't tell you what the "rest" of the hardware > design can support. > > This depends on hardware stuff. For example: > 1) how big of a heat pipe there is > 2) how big of a power supply there is > 3) how many fans there are > 4) is there a beefy GPU sharing power > 5) etc. > > Even if you have the thermal headroom if you turn PPT limits up too much > your GPU performance might suffer. As this will normally be a headless system, I'm actually looking if I can turn the GPU off, *unless* there's an HDMI cable plugged in. So (at least for now), the GPUs only function is to have a display when I need it for troubleshooting. > Designers do thermal simulations to come up with the numbers for all > this stuff and it's proprietary information to go with their design. > > That's why it's encoded in BIOS or EC and OS will read it and offer the > interface to the user. I really don't think it makes sense in a design > it yourself desktop. Ah, ok. Clear :-) I (initially) thought you meant hardware thermal design *of the CPU*, but I now know it's 'a bit' more then that. Thanks, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:40:50 CEST Mario Limonciello wrote: > > As this will normally be a headless system, I'm actually looking if I can > > turn the GPU off, *unless* there's an HDMI cable plugged in. > > So (at least for now), the GPUs only function is to have a display when I > > need it for troubleshooting. > > With nothing plugged in, modern AMD GPUs will go into runtime PM and > depending on the motherboard design either D3hot or D3cold. I need to figure out how I can query the various things and learn what they actually mean. F.e. on the frame.work forum I found: `cat /sys/class/drm/card0/device/power/runtime_status` and that returns 'active', but I have no idea what that means. Like I said before: lots of research to do ;-) > D3cold is as close to off as you can get. Good to know :-) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1074505: dpkg: warning: while removing linux-image-6.8.11-amd64, directory '/lib/modules/6.8.11-amd64' not empty so not removed
Control: reassign -1 src:linux Control: forcemerge -1 1093998 On Sunday, 30 June 2024 06:07:55 CEST Dan Jacobson wrote: > Package: linux-image-amd64 > > dpkg: warning: while removing linux-image-6.8.11-amd64, directory > '/lib/modules/6.8.11-amd64' not empty so not removed # ls -l > /lib/modules/6.8.11-amd64 > total 4 > -rw-r--r-- 1 root root 55 05-27 14:48 modules.weakdep See https://bugs.debian.org/1073998 signature.asc Description: This is a digitally signed message part.
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
On Saturday, 4 February 2023 22:12:24 CEST Salvatore Bonaccorso wrote: > Hi, > > On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote: > > Hi! > > > > Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]: > > > > Would they fit into a separate source package not associated with > > > > raspi-config? > > > > > > I do strongly think they do not belong in the raspi-firmware package for > > > the reason I retitled this bug and retitled my response Subject. > > > Another reason is that the raspi-firmware package makes (several) > > > assumptions, namely that they are only used/usable on RPi devices and > > > have a /boot/firmware directory (where a FAT partition is mounted, > > > although that part is not checked for). I have previously expressed my > > > concerns/doubts about that, but that's outside the scope of this bug. > > > It also looks 'weird' to install the raspi-firmware package while you > > > only care about the wifi firmware and not care about RPi's at all. > > > > Right, I agree this should be a package of its own. I didn't know > > raspi-nonfree came from a "coherent" set of firmware sources provided > > by a single upstream. It is a distorsion that peopleinterested in > > brcmfmac firmware have to install raspi-firmware if they have > > different hardware. > > So I guess we can close this bug here, and the files can be shipped > with a new dedicated source package containing the firmware files, > since the last option of having them merged upstream in > linux-firmware.git seems unrealistic for now? > > Regards, > Salvatore > > p.s.: sorry misstyped initially the origin source package, was obviously > not meaning raspi-config, so raspi-firmware. Just quoting this here as AFAICT Salvatore's solution (new source package) is the right one (and removed from the raspi-firmware package). I'll not remove the 'upstream' tag as it's set by the maintainer, but if you think the RPi Foundation will do the work to send it to the linux-firmware repo, then I have a bridge I'd like to sell you. signature.asc Description: This is a digitally signed message part.
Bug#1061321: marked as done (firmware-nonfree: Important changes coming up with upstream version 20230919)
On zondag 30 juni 2024 22:33:03 CEST you wrote: > I don't know the details anymore, but I recently ran into an interesting > problem though as the 'physical' firmware file was put in the atheros > packages instead of a link to the place of the qcom-soc package. Could be a > PEBKAC issue, but you might verify whether it's doing the right thing. Not a PEBKAC issue. ``ath10k/WCN3990/hw1.0/wlanmbsp.mbn`` file (3.6MB) is in firmware-atheros while that file ought to be in firmware-qcom-soc (and a *link* to that file in firmware-atheros) signature.asc Description: This is a digitally signed message part.
Bug#1061321: marked as done (firmware-nonfree: Important changes coming up with upstream version 20230919)
On Monday, 1 July 2024 09:17:43 CEST Diederik de Haas wrote: > On zondag 30 juni 2024 22:33:03 CEST you wrote: > > I don't know the details anymore, but I recently ran into an interesting > > problem though as the 'physical' firmware file was put in the atheros > > packages instead of a link to the place of the qcom-soc package. Could be > > a > > PEBKAC issue, but you might verify whether it's doing the right thing. > > Not a PEBKAC issue. ``ath10k/WCN3990/hw1.0/wlanmbsp.mbn`` file (3.6MB) is in > firmware-atheros while that file ought to be in firmware-qcom-soc (and a > *link* to that file in firmware-atheros) Forgot to mention that I checked the .deb files produced by MR 96 (but that is consistent with the deb files that I build locally with which I noticed the issue) signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Monday, 1 July 2024 17:17:46 CEST Nathan MALO wrote: > It seems to me that it is working as expected ! Awesome :-) signature.asc Description: This is a digitally signed message part.
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
On Wednesday, 8 March 2023 15:49:03 CET Cyril Brulebois wrote: > This is definitely a blocking issue for booting on both Pi 4 (SD card) > and CM4 (SD card or internal eMMC). That's also seen with v6.1.15 > (annotating accordingly) and v6.2 (not annotating as we have no such > package in the archive at the moment). Thankfully that's gone in > v6.3-rc1. > > You can find my analysis in: > > https://lore.kernel.org/linux-arm-kernel/20230308144105.di552lbogqv2s7fk@mr > aw.org/ > > Hopefully we'll get that fixed via stable/6.1.y soon. I might propose a > patch series against the Debian package right away though, Raspberry Pi > users have suffered long enough from that regression… The relevant patches are queued up for 6.1.16: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/ commit/queue-6.1?id=a5ed16fdb1a2a3a9b50c3da79abcfe9366b2c47a signature.asc Description: This is a digitally signed message part.
Bug#1032582: linux: Enable CAN_MCP251XFD
Control: tag -1 moreinfo On Thursday, 9 March 2023 15:04:11 CET Bastian Germann wrote: > The driver CAN_MCP251X is already enabled on all platforms. > Please enable CAN_MCP251XFD as module as well. Thank you! Can you describe *why* this would a useful addition? For CAN_MCP251X the motivation was: "Without CONFIG_CAN_MCP251X=m, MCP251X based CAN controllers are unusable. This is often found paired with single board computers like the RPi, ODROID, UDOO, Toradex, etc." signature.asc Description: This is a digitally signed message part.
Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin
On Thursday, 9 March 2023 03:38:13 CET d...@kataplop.net wrote: > Here's the result of using latest package: > > [38.546040] brcmfmac :01:00.0: firmware: failed to load > brcm/brcmfmac4356-pcie.bin (-2) [ 38.546408] brcmfmac :01:00.0: > firmware: failed to load brcm/brcmfmac4356-pcie.bin (-2) [ 38.546416] > brcmfmac :01:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.bin > failed with error -2 > > Downgrading it and reloading the module brings the interface up: The brcm/brcmfmac4356-pcie.bin file (f.e.) has been moved/renamed to cypress/ cyfmac4356-pcie.bin and *maybe* that causes the issue. If you can access this file, could you try if it solves the issue? https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4035730/artifacts/ file/debian/output/firmware-brcm80211_20230210-3+salsaci_all.deb signature.asc Description: This is a digitally signed message part.
Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin
On Friday, 10 March 2023 04:00:44 CET d...@kataplop.net wrote: > March 9, 2023 5:25 PM, "Diederik de Haas" wrote: > > The brcm/brcmfmac4356-pcie.bin file (f.e.) has been moved/renamed to > > cypress/cyfmac4356-pcie.bin and *maybe* that causes the issue. > > > > If you can access this file, could you try if it solves the issue? > > https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4035730/ > > artifacts/file/debian/output/firmware-brcm80211_20230210-3+salsaci_all.deb > > I've installed this package and still get the same faulty behavior: > > [87955.527647] brcmfmac :01:00.0: firmware: failed to load brcm/ > brcmfmac4356-pcie.bin (-2) > [87955.527654] brcmfmac :01:00.0: Direct firmware load for brcm/ > brcmfmac4356-pcie.bin failed with error -2 > > Let me know if I can test something else, I'm 99% sure this would be a *workaround*, but let's verify anyway: In the /lib/firmware directory, create a symlink from brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin signature.asc Description: This is a digitally signed message part.
Bug#1032623: lintian-brush: vcswatch should not raise error on repos > 1GiB in size
Package: lintian-brush Version: 0.147 Severity: normal X-Debbugs-Cc: debian...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm not sure this is the right package, but filed it against lintian-brush as it contains vcswatch.py. On https://tracker.debian.org/pkg/linux there is a high-priority action needed item because vcswatch "Failed to analyze the VCS repository". The reason: "Repository size 1135554560 exceeds 1 GiB, blocking it" So I queried `udd` to see what it had to tell: udd=> select vcs, url, status, error from vcswatch where source = 'linux'; vcs | url | status | error - -+++--- Git | https://salsa.debian.org/kernel-team/linux.git | ERROR | Repository size 1135554560 exceeds 1 GiB, blocking it (1 row) The thing is that the Debian kernel repository is big and that's NOT an error; it's just big. There is no need to take action to fix it. AFAIC, the error is in the tool that put the error in udd. I don't know the reason for this (self-imposed?) limit is, but IMO that limit should be removed or contain some allow-list with src:linux in it, so that it will still be scanned. Alternatively (or in addition to), `vcswatch` should not propagate the error when it's due to the limit of 1 GiB in repo size. Cheers, Diederik - -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.23.2 ii python3 3.11.2-1 ii python3-asyncpg 0.27.0-1+b2 ii python3-breezy 3.3.2-2+b1 ii python3-debian 0.1.49 ii python3-debmutate0.65 ii python3-distro-info 1.5 ii python3-dulwich 0.21.2-1+b1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-levenshtein 0.12.2-2+b4 ii python3-pyinotify0.9.6-2 ii python3-ruamel.yaml 0.17.21-1 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.11.6-1 ii python3-tqdm 4.64.1-1 ii python3-upstream-ontologist 0.1.35-1 Versions of packages lintian-brush recommends: ii debhelper 13.11.4 ii decopy 0.2.4.8-0.1 ii dos2unix 7.4.3-1 ii gpg2.2.40-1 ii lintian2.116.3 ii ognibuild 0.0.18+git20230208.1.9b890a2-1 ii python3-bs44.11.2-2 ii python3-debianbts 4.0.1 ii python3-docutils 0.19+dfsg-6 ii python3-lxml 4.9.2-1+b1 ii python3-markdown 3.4.1-2 Versions of packages lintian-brush suggests: ii brz-debian 2.8.76 ii git-buildpackage 0.9.30 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 247 - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZAsTEwAKCRDXblvOeH7b buACAP9LooUG2xFr3Eg2SwUHLijgXzGIOEktqJUXcCdem+E0PwD/Q3tOIar0KoUf ott/cpmwos9YVvahGpCanHDSfcBpjgU= =FaJq -END PGP SIGNATURE-
Bug#1032623: lintian-brush: vcswatch should not raise error on repos > 1GiB in size
Hi,
On Friday, 10 March 2023 12:47:45 CET Christoph Berg wrote:
> Re: Diederik de Haas
> > The thing is that the Debian kernel repository is big and that's NOT an
> > error; it's just big. There is no need to take action to fix it.
>
> quantz.debian.org has been running out of disk space several times in
> the past years, and blacklisting the biggest repos helped a lot.
> (There are some that are even > 4 GB.)
Ok, I can understand the limit being put in place.
OTOH, running out of disk space is a problem and 1-4GB is not *that* big IMO
and that issue should be resolved (asap).
> Specifically on the kernel, vcswatch is of limited use anyway since
> there are several packages using the repo, but only one of them
> ("linux") contains a debian/changelog where the package name matches.
> On "linux", I had the impression that the vcswatch info would be
> helpful in practise, but I forgot the details.
>
> Were you able to see useful vcswatch info on the kernel packages in
> the past?
I'm a big fan of automated checks, be it Salsa's CI or vcswatch or (pretty
much) any other tool.
I don't know if vcswatch (specifically) provided useful information in the
past. Possibly it didn't report an issue before the size limit was imposed.
That is useful info and it becomes even more useful if it would find an actual
issue.
I think tracker.d.o is awesome and when looking for ways to contribute to a
package, I often check the 'action needed' section and work on that.
But when it reports an issue which can not be solved, like in this case, then
I find that problematic as it then lowers the barier to also ignore other
issues. In Salsa's CI I tend to disable a test rather then allow failure, so
when the result is not all green, I should take action.
The best solution would be to fix it at the source (bigger HDD?), but if that's
not feasible (in the short term), then don't turn the 1GiB self-imposed limit
into a 'problem' (to be fixed) for someone else.
IOW: filter out this specific issue.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin
Control: reassign -1 src:linux 6.1.15-1 Control: tag -1 -moreinfo +upstream Control: forwarded -1 https://lore.kernel.org/linux-wireless/2716728.5R3jveeIG6@prancing-pony/ On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote: > March 10, 2023 10:57 AM, "Diederik de Haas" wrote: > > I'm 99% sure this would be a *workaround*, but let's verify anyway: > > In the /lib/firmware directory, create a symlink from > > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin > > As expected, it works with the symlink :) Thanks, then it's a kernel issue so I'm reassigning accordingly. signature.asc Description: This is a digitally signed message part.
Bug#1032367: brcm/brcmfmac4356-pcie.bin failed with error -2
On Thursday, 9 March 2023 19:17:10 CET Diederik de Haas wrote:
> In https://bugs.debian.org/1032367 we have a user who reported that the
> brcm/brcmfmac4356-pcie.bin firmware file failed to load with a new firmware-
> brcm80211 package, while it succeeded with an old one.
>
> In
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> / I found 2 commits that seem relevant:
> - 04f71fe564552c22dc7ece0d2b8afc11b33de392 where various cypress firmware
> and clm_blob files (including 4356) were added to the *cypress* directory.
> - 0f0aefd733f70beae4c0246edbd2c158d5ce974c which removed old brcm firmware
> files that have a newer cypress variant ... from the *brcm* directory.
>
> So in essence a bunch of firmware files were moved from 'brcm' dir to
> 'cypress'.
>
> I don't know how the firmware file loading mechanism works, but could it be
> that it (also) needs to look in the new (cypress) location for those files?
I am now reasonably certain that that is indeed the issue.
I asked the reporter of the issue to create symlinks and that 'fixed' it:
On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote:
> March 10, 2023 10:57 AM, "Diederik de Haas" wrote:
> > I'm 99% sure this would be a *workaround*, but let's verify anyway:
> > In the /lib/firmware directory, create a symlink from
> > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin
>
> As expected, it works with the symlink :)
AFAICT in drivers/net/wireless/broadcom/brcm80211/brcmfmac/ there is pcie.c
and firmware.[c|h] and it uses BRCMF_FW_DEFAULT_PATH (="brcm/") to construct
the location of the firmware files.
Now that several firmware files are stored in a different directory ('cypress')
and also have a different file 'prefix' ('cyfmac') the firmware files that are
stored in/moved to the cypress directory are no longer found.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1032680: kdiff3: Crashes when comparing 2 directories (signal: Aborted)
Package: kdiff3 Version: 1.10.0-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I tried to compare 2 directories with kdiff3 and it crashed the moment it was supposed to show the diff. This happened initially when selecting the dirs in Dolphin. Then via the crash handler I restarted kdiff3 and was presented with a dialog to select files/folders to compare. Selected the same 2 directories again and it crashed immediately. The KDE Crash Handler said the trace was useful, so copied below: Application: KDiff3 (kdiff3), signal: Aborted [KCrash Handler] #4 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #5 0x7f51868a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #6 0x7f518685aef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #7 0x7f5186845472 in __GI_abort () at ./stdlib/abort.c:79 #8 0x7f5186845395 in __assert_fail_base (fmt=0x7f5180148894 "%s%s%s:%u: %s%sControletest '%s' faalt.\n%n", assertion=assertion@entry=0x561be34287a8 "!m_modificationTime.isNull()", file=file@entry=0x561be3428728 "./src/fileaccess.cpp", line=line@entry=762, function=function@entry=0x561be3428a38 "QDateTime FileAccess::lastModified() const") at ./assert/assert.c:92 #9 0x7f5186853df2 in __GI___assert_fail (assertion=0x561be34287a8 "!m_modificationTime.isNull()", file=0x561be3428728 "./src/fileaccess.cpp", line=762, function=0x561be3428a38 "QDateTime FileAccess::lastModified() const") at ./assert/assert.c:101 #10 0x561be33b21c0 in FileAccess::lastModified (this=) at ./src/fileaccess.cpp:762 #11 0x561be33ee182 in MergeFileInfos::compareFilesAndCalcAges (this=this@entry=0x561be3ff9c70, errors=..., pOptions=..., pDMW=0x561be3e28490) at ./src/MergeFileInfos.cpp:192 #12 0x561be334c4d0 in DirectoryMergeWindow::DirectoryMergeWindowPrivate::prepareListView (this=this@entry=0x561be395d740, pp=...) at ./src/directorymergewindow.cpp:1331 #13 0x561be334ffbb in DirectoryMergeWindow::DirectoryMergeWindowPrivate::init (this=0x561be395d740, bDirectoryMerge=, bReload=) at ./src/directorymergewindow.cpp:951 #14 0x561be3350ee0 in DirectoryMergeWindow::init (this=, bDirectoryMerge=, bReload=) at ./src/directorymergewindow.cpp:736 #15 0x561be3366d59 in KDiff3App::doDirectoryCompare (this=this@entry=0x561be39f6c00, bCreateNewInstance=bCreateNewInstance@entry=false) at ./src/pdiff.cpp:1627 #16 0x561be333ba3f in KDiff3App::completeInit (this=0x561be39f6c00, fn1=..., fn2=..., fn3=...) at ./src/kdiff3.cpp:432 #17 0x561be332dda8 in KDiff3Shell::KDiff3Shell (this=0x561be36e5b50, bCompleteInit=, __in_chrg=, __vtt_parm=) at ./src/kdiff3_shell.cpp:60 #18 0x561be33227bb in main (argc=, argv=) at ./src/main.cpp:197 [Inferior 1 (process 6106) detached] Cheers, Diederik - -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdiff3 depends on: ii kio 5.103.0-1 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libkf5configcore5 5.103.0-1 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5kiocore55.103.0-1 ii libkf5kiowidgets5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii libqt5core5a 5.15.8+dfsg-3 ii libqt5gui55.15.8+dfsg-3 ii libqt5printsupport5 5.15.8+dfsg-3 ii libqt5widgets55.15.8+dfsg-3 ii libstdc++612.2.0-14 Versions of packages kdiff3 recommends: ii kdiff3-doc 1.10.0-1 kdiff3 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZAvHYAAKCRDXblvOeH7b bmgpAQDtCOVCPSztfaBEC0HOyC0WReV2g18Is8j9NCdb6nW3JAEAg7WS9tVso3gB 3fSlNEGJR6o3XcwqpT9Y3jRVc83iigQ= =213e -END PGP SIGNATURE-
Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin
On Friday, 10 March 2023 17:16:48 CET Diederik de Haas wrote: > On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote: > > March 10, 2023 10:57 AM, "Diederik de Haas" wrote: > > > I'm 99% sure this would be a *workaround*, but let's verify anyway: > > > In the /lib/firmware directory, create a symlink from > > > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin > > > > As expected, it works with the symlink :) > > Thanks, then it's a kernel issue so I'm reassigning accordingly. New development: I now think it *is* an issue in firmware-brcm80211. I think it would still be good if the kernel would also check the `cypress` directory, but this seems to be a packaging issue. Via https://snapshot.debian.org/binary/firmware-brcm80211/ you can find various old versions of the package, and I want you to do the following test: 1) First remove the symlink you created above. 2) Get the .deb for version 20230117-2 and install that 3) Reboot and verify that your wifi works as it should 4) If so, upgrade to the 20230210-1 version and reboot 5) verify that wifi is now broken Let me/us know how that test goes. signature.asc Description: This is a digitally signed message part.
Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin
Control: reassign -1 firmware-brcm80211 20230210-1 Control: notforwarded -1 Control: tag -1 -upstream Control: found -1 20210315-3 On Saturday, 11 March 2023 03:39:19 CET d...@kataplop.net wrote: > > 1) First remove the symlink you created above. > > 2) Get the .deb for version 20230117-2 and install that > > 3) Reboot and verify that your wifi works as it should > > it works as expected... > > > 4) If so, upgrade to the 20230210-1 version and reboot > > 5) verify that wifi is now broken > > ... and this breaks the wifi with module not finding the fw, as expected > (same error message) I still think the upstream kernel should do something with the 'new' use of the cypress directory as I described in my mail to the ML(s). But the cause for the breakage is actually a (Debian) packaging change and I'm about to revert that ... On Friday, 10 March 2023 10:57:15 CET Diederik de Haas wrote: > I'm 99% sure this would be a *workaround*, but let's verify anyway: > In the /lib/firmware directory, create a symlink from > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin ... as this was likely less of a 'workaround' and more a 'solution'. signature.asc Description: This is a digitally signed message part.
Bug#1032582: linux: Enable CAN_MCP251XFD
On Monday, 13 March 2023 16:23:19 CET Bastian Germann wrote: > Am 09.03.23 um 15:31 schrieb Diederik de Haas: > > Can you describe*why* this would a useful addition? > > The chip is in several industrial PCs but the most popular device should be > the Waveshare 2-Channel Isolated CAN FD Expansion HAT for Raspberry Pi. Works for me: https://salsa.debian.org/kernel-team/linux/-/merge_requests/678 signature.asc Description: This is a digitally signed message part.
Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"
Control: tag -1 moreinfo Hi Julian, On Thursday, 12 January 2023 19:31:37 CET Julian Groß wrote: > My computer just froze on Kernel version 5.19.11-1. Though nothing got > logged. What's the current status on this bug? Currently there is a version 6.1.15 in Testing/Unstable and it would be useful to know if the problem is still there. There's another version in the pipeline (6.1.19 or higher) which is a rather big update, so testing that when it becomes available is useful too. I also looked into the 'forwarded' URL and saw questions by (upstream) kernel maintainers, but I didn't see a response from you to those questions? Any progress in capturing output f.e. as Bernard described? signature.asc Description: This is a digitally signed message part.
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
On Tuesday, 14 March 2023 14:55:04 CET Julien Cristau wrote: > Package: src:linux > Version: 6.1.12-1 > > After upgrading to 6.1.12-1 my laptop started hanging regularly (3 times > in a few hours). Downgraded to 6.1.8-1 and I've not seen this for a > week, so this looks like a recent regression. Testing now has 6.1.15-1, can you test it with that? There's another update in the pipeline (at least to 6.1.19) and when it becomes available, it would be useful if you could test that as well. signature.asc Description: This is a digitally signed message part.
Bug#1032924: linux-image-amd64: new upstream stable kernel 6.2.6 fixes some rtl8192e, cfg80211 and tpm bugs
Previously I tried to be nice and gave you pointers which I hoped would give you insight as to why your behavior is unhelpful, which in turn would result in improved behavior. That did not have the intended effect. So now I'm NOT going to be nice, so I added commun...@debian.org in the address list because: 1) I consider your behavior in violation of the CoC: https://www.debian.org/code_of_conduct 2) You and possibly others will complain about my style of communication, so it'll end up in the Debian Community Team's plate anyway. On 2023-01-19 I wrote in https://bugs.debian.org/1029159#16: > On Wed, 18 Jan 2023 17:41:33 +0100 xevilstar wrote: > > Package: linux-headers-6.2.0-rc4 > > Version: 6.2.0-rc4-2 > > > > I am trying to dpkg-buildpackage -us -uc linux-6.2-rc4.tar.gz > > Because I strongly want to learn how to contribute. > > It's great that you want to learn how to contribute, but please don't abuse > the Debian BTS for that. Only use that to report actual issues in actual > existing packages/versions. > > There are various resources that will help you get started, f.e. on > wiki.debian.org and there's also #debian-mentors on IRC where you can ask > questions related to Debian packaging. But the available resources should > already teach you how you can start making contributions and also when it's > appropriate to submit a RFS bug and how to do it. > > As for learning how to build a Debian kernel, please read the debian-kernel- > handbook which explains many things on how the Debian kernel gets build. > > As for (potential) issues wrt rt packages, you may want to take a look at: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/629 > > Where the commits should tell you how to deal with that. > > Good luck! Despite me asking you to NOT file bugs for packages/versions which do not exist in the Debian archive, you continue to do so: On 2023-01-30 I wrote in https://bugs.debian.org/1030013#12 > On Monday, 30 January 2023 10:49:32 CET xevilstar wrote: > > The new rc kernel version 6.2~rc6 is out, still not displayed on > > https://tracker.debian.org/pkg/linux Can I dput the packages ? > > Stop filing bug reports on things which are not bugs. > And it's not just one, but several. For emphasis: *And it's not just one, but several.* (on 2023-01-30!) This mail contains quotes from several different bug reports, but not 'even' all of them. > You said you wanted to contribute, but all you've accomplished thus far is > annoy people and cause people to spend time on things which are MUCH better > spend on actual issues. Please stop! > > The focus is, as it should be, on getting the kernel ready for the Bookworm > release and that should be version 6.1. > Until Bookworm is released, any later version is not important to the Debian > kernel team, so stop *continuously* asking for it. Before that I said in https://bugs.debian.org/1027921#25: > On Wednesday, 4 January 2023 16:39:33 CET Renato Gallo wrote: > > 5.10 should be EOL by now > > Please refrain from comments like that. > It doesn't help at all and is also plain false. 5.10 is Bullseye's kernel and it's also a Super Long Term Support release, meaning it will probably receive ~ 20 YEARS of support. But that's not the point I want to make here, which is that you send an unsolicited email, aka spam, to a bug report with which you were not involved and your message was plain wrong and unhelpful. Then in https://bugs.debian.org/1022126#112 this happened: On Monday, 20 February 2023 10:30:43 CET vmxevils...@gmail.com wrote: > I have stopped sending kernel packages as per your request (you defined > it spamming). > For who might be interested I am making the 6.2.0 kernel amd64 packages > myself ... > Since this version fixes bug 1022126 (and, I am sure others), This is another bug you inserted yourself into with not only an unhelpful reply, but one which angered the OP of that bug. How is that helping? Why are you surprised that this kind of behavior is considered spamming? Contributing is about helping the maintainer(s) of a package by lessening their load or in case there is no maintainer, by f.e. adopting a package. Or if there is a maintainer but for some reason has been unable to work on their package for a while, work on that *with their permission*. The Debian kernel package does not fall in that category, quite the opposite. On 2023-01-15 https://bugs.debian.org/1028965 happened: RFS: linux/6.1.6-1~exp1 [ITP] -- Linux for multiprocessor On Sunday, 15 January 2023 20:40:16 CET I wrote: > On Sun, 15 Jan 2023 15:59:13 +0100 vmxevils...@gmail.com wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "linux": > > * Package name : linux > > > >Version : 6.1.6-1~exp1 > >Upstream contact : Salvatore Bonaccorso > > > > * URL : https://www.kernel.org/ > > * License : Unicode-data, LGPL
Bug#1033002: kodi: switch B-D from libcec-dev to libv4l-dev for CEC support?
Source: kodi Version: 2:20.1+dfsg-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 User '6by9' said the following in: https://github.com/lategoodbye/rpi-zero/issues/43#issuecomment-1464044950 === 200~CEC is handled through the vc4 driver in mainline - no need for VCHIQ. cec-client doesn't handle multiple Linux kernel CEC API interfaces - it has hard defines like that at https://github.com/Pulse-Eight/libcec/blob/master/include/cectypes.h#L287 Use cec-ctl (part of v4l-utils) instead of libcec - libcec is largely abandonware. === The part about abandonware and not capable of handling the Linux kernel CEC API interfaces sound rather problematic. So maybe it's a good idea to switch in the Trixie dev cycle? - -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZBHhVwAKCRDXblvOeH7b bmj4AP4oYzvd5FCzQ3mA4ME4VRJB9ZDkHrTHlotUBmwl8enQYgEA11FdHjOQnjYI cyk9tBPvQjBOfCW05O3qWu3eRfgNuA0= =BkX9 -END PGP SIGNATURE-
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
On Thursday, 16 March 2023 18:11:27 CET Julien Cristau wrote: > > I rebooted on 6.1.15-1 last night and things are still looking good so > > I'll call this fixed. Thanks. > > Spoke too soon: > > [84564.498495] BUG: kernel NULL pointer dereference, address: > > 0398 [84564.498502] #PF: supervisor write access in kernel > > mode > > [84564.498504] #PF: error_code(0x0002) - not-present page > > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0 > > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI > > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted > > 6.1.0-6-amd64 #1 Debian 6.1.15-1 [84564.498516] Hardware name: LENOVO > > 20XW00ABUS/20XW00ABUS, BIOS N32ET82W (1.58 ) 12/05/2022 [84564.498518] > > Workqueue: kacpi_notify acpi_os_execute_deferred Bummer. Since 6.1.8 I found the following 2 commits in drivers/usb/typec/ucsi: 3d7f77e55da3455c8844b651e37779c90e201f48 titled "usb: ucsi: Ensure connector delayed work items are flushed" fdd11d7136fd070b3a74d6d8799d9eac28a57fc5 titled "usb: typec: ucsi: Don't attempt to resume the ports before they exist" Especially the first one looks 'promising'. Can you make a patch which reverts that commit and use 'test-patches' from https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html to build a kernel and test that? signature.asc Description: This is a digitally signed message part.
Bug#769380: python3-mako: Please make the package multi-arch compatible
On Tue, 5 Dec 2017 02:37:06 +0100 "Manuel A. Fernandez Montecelo" wrote: > Hi Piotr, > > 2017-12-04 23:16 GMT+01:00 Piotr Ożarowski : > >> So, Piotr, do you think that any of the options is preferable? > >> > >> If there's no reply I'd like to upload an NMU with a fix for this > >> problem. > >> > >> I think that changing the package to "Architecture: any" and "M-A: same" > >> is safer than dropping a dependency to recommends. It's not ideal, but > >> in the end is just causes a small overhead, and changing dependencies > >> can even break reverse-depends and introduce bugs difficult to detect. > > > > please point me to the policy if it's already known what's the right > > approach > > It's not documented in Policy yet. The best source of information is: > https://wiki.debian.org/Multiarch > > Although probably Ubuntu is best/more accurate/more complete: > https://wiki.ubuntu.com/MultiarchSpec > > Abut this package, since the package could be marked "foreign" (as in > "package from foreign arch satisfies dependency") if it was only for > its contents (because it's an arch:all, the same in all arches), but > since it exposes arch-independent behaviour throught dependencies > (i.e. needs to load arch-dependent modules for markupsafe), it cannot > be marked in that way, which is the most beneficial and the original > suggestion. It has to be marked as "give me the version for the same > architecture that the package to be built that depends on this one". > > Despite having binaries in /usr/bin/ and libraries shipped in /usr/lib > but not // (see next url), since they are byte-for-byte the > same across architectures, it should be covered by the same provisions > as if the files were in /usr/include (but not inside subdir > //), /usr/share, etc. -- at least that's how I interpret it. > > https://packages.debian.org/sid/all/python-mako/filelist Are there any new developments/insights after 5 years? It would be great if this bug could be resolved. signature.asc Description: This is a digitally signed message part.
Bug#769380: python3-mako: Please make the package multi-arch compatible
On Friday, 17 March 2023 17:46:36 CET Helmut Grohne wrote: > Do not dare asking whether this can be done for bookworm. Haha! Don't worry :-) I just happen to stumble upon it. Thanks for the explanation and your cross-build work in general :-) signature.asc Description: This is a digitally signed message part.
Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed
Hi Simon,
On Tue, 20 Dec 2022 11:47:10 + Simon McVittie wrote:
> Source: mutter
> Version: 43.2-1
> Tags: ftbfs
>
> Recent uploads of mutter have had a FTBFS on armhf and sometimes armel,
> with this test failure in "mutter:core+mutter/wayland / xwayland":
>
> > mutter-xwayland: ../../src/xcb_io.c:626: _XAllocID: Assertion
> > `ret != inval_id' failed.
I assume this is a PEBKAC issue, but I got this error too in a different
condition and as such it might help with this bug. If not, please ignore.
I cloned mutter's Salsa repo and added Salsa's default CI pipeline and it
consistently fails on the 'build i386' job in the same test case
("mutter:core+mutter/wayland / xwayland") with the same assertion failure.
See https://salsa.debian.org/diederik/mutter/-/jobs/4063218
I _think_ Salsa's CI runners run on amd64 and thus fails on an i386 job.
I also _think_ that armhf and armel are (often?) build on an arm64 native
host, but this could be dependent on which specific host it happens to get
build and thus cause the inconsistent error/non-error situation?
HTH and if not, sorry for the noise,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1033095: Disable TIOCSTI for trixie
On Saturday, 18 March 2023 21:17:52 CET Salvatore Bonaccorso wrote:
> > https://www.openwall.com/lists/oss-security/2023/03/14/2
> >
> > Filing a bug (for trixie (added in 6.2), can be applied early to notice
> > potentially affected applications early on)
>
> Just for reference in the bug, this possible since 83efeeeb3d04 ("tty:
> Allow TIOCSTI to be disabled") in 6.2-rc1.
>
> Early on trixie cycle, we can set it to be disabled (unless even
> upstream changes the default) and see where it will cause issues.
>
> https://git.kernel.org/linus/83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d
How early do you want it? ;-)
Should I set it to 'n' or "CONFIG_LEGACY_TIOCSTI is not set" in my MR?
signature.asc
Description: This is a digitally signed message part.
Bug#1033095: Disable TIOCSTI for trixie
On Saturday, 18 March 2023 22:42:15 CET Salvatore Bonaccorso wrote: > "early", i.e. it can be in one of the first uploads to experimental we > will do. But I will prefer to have it separate from the rebase to new > upstream version, i.e. as own dedicated change/mr. > > So please keep the default in the !651 merge request. Will do. signature.asc Description: This is a digitally signed message part.
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
On Saturday, 18 March 2023 21:33:10 CET Salvatore Bonaccorso wrote: > > The following looks similar, though it is reported to happen on dock > > unplug. I assume your issue is independent on that? I guess that is https://bugzilla.kernel.org/show_bug.cgi?id=217106 ? > And if you do some bisection/tests with the above questions from > Diederik, might you try as well > > https://patchwork.kernel.org/project/linux-usb/patch/20230306103359.6591-2-h > dego...@redhat.com/ Not sure why patchwork still shows v2 of the patch as v4 is available here: https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/ signature.asc Description: This is a digitally signed message part.
Bug#1033176: linux: Future Android/Waydroid support
Source: linux Version: Future Android/Waydroid support Severity: wishlist Forwarded: https://github.com/waydroid/waydroid/issues/811 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In https://salsa.debian.org/kernel-team/linux/-/merge_requests/651 I had initially removed the 2 Android related patches for the following reason: Drop patches: - debian/android-enable-building-ashmem-and-binder-as-modules.patch - debian/export-symbols-needed-by-android-drivers.patch After https://bugs.debian.org/901492 the preceding 2 patches were created for anbox support. However in kernel 5.18 `ashmem` was removed from the upstream kernel and since then, anbox has not been working as reported in https://bugs.debian.org/1014329. Then in https://bugs.debian.org/1032304, titled "RM: anbox -- ROM; Upstream discontinued", the anbox package has been removed from the Debian archive. And on Anbox's GH page one can see the following: "It's development has however stalled in the past years and it's only fair to say that now in 2023 it's no longer actively developed." So it's of no use to continue carrying these patches. Even though anbox is removed from the Debian archive and upstream more or less 'dead', it turns out that Waydroid (= ~ anbox's successor) could probably benefit from support in the Debian kernel too. So I undid/reverted the dropping of those patches. Removal of Android support should be done separately and ideally based on a bug report in the BTS, hence this bug report. In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream' for recommendations on which/how/what kernel modules to enable. - -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZBZPHwAKCRDXblvOeH7b bpbCAPsFqbmYhJzizpispzGdw+ksgNnm59ZQDtmSMSYcNk5S5gD9FcHWbGx6XtJ2 5YefJ1PVNv1BbtdAkofzw2Nz5gLLDgE= =pyYQ -END PGP SIGNATURE-
Bug#1033398: linux-image-amd64: reproducible kernel freeze on 5.19+
Control: reassign -1 src:linux 6.1.20-1 On Friday, 24 March 2023 12:44:33 CET Tim Rühsen wrote: > Package: linux-image-amd64 > Version: 6.1.20-1 > > We run a priviledged eBPF based tool with a communication between kernel and > user space. It runs without issues on kernels 4.15 to 5.18. > On kernels 5.19+, the whole system freezes after a few minutes. Via https://snapshot.debian.org/binary/linux-image-amd64/ you can easily test various kernel versions. Could you try whether 5.19~rc4-1~exp1 indeed produces the problem? > Since the running program is rather complex, it is not easily possible to > carve out a small reproducer. We can provide gdb backtraces from freezes > inside qemu. Someone else would have to chime in for the backtraces; that's beyond my skill set. Verifying in which kernel version/commit the issue started is still useful. signature.asc Description: This is a digitally signed message part.
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
On Sunday, 23 October 2022 15:15:36 CEST inasprecali wrote: > It does not boot at all, I'm unable to SSH into it. It's not > merely that the display does not work. Then I'm inclined to think this *is* a separate issue, which is due to the upgrade to -19, but that you happen to have an AMD GPU is 'not' relevant. On Sunday, 23 October 2022 15:18:03 CEST inasprecali wrote: > In my case, it's because, without command line parameters, the > kernel will select the "radeon" driver, while I want to use the > "amdgpu" driver instead. > > The options "radeon.si_support=0 amdgpu.si_support=1" disable > radeon support and enable amdgpu support respectively. I realize it's not what you want, but may result in an useful extra data point if you (for this test) switch those parameters to enable radeon support and disable amdgpu support. Can you try that? If that test does not make a difference, then I'm quite sure it's a separate issue and it would be best to open a new bug report for that. signature.asc Description: This is a digitally signed message part.
Bug#1022061: debian-kernel-handbook: improve kernel build steps for newbies
Hi Dan! Thanks so much for your description, it already gives me some ideas how to improve things wrt the documentation :-) On Wednesday, 19 October 2022 23:56:23 CEST Dan Coleman wrote: > use test-patches in debian/bin/test-patches. >From bug 1022025: On Thursday, 20 October 2022 21:48:20 CEST Diederik de Haas wrote: > On Thursday, 20 October 2022 19:53:22 CEST Dan Coleman wrote: > > > Apparently "test-patches" does not build a 'headers-common' package and > > > therefor installing the headers failed which in turn made DKMS fail. > > > > That seems like less-than-ideal behavior for test-patches. > > Is that a bug that would benefit from being reported? I (now) do think it is useful to file a (wishlist) bug against src:linux in which you request improvements to the 'test-patches' script: 1) also creates a headers-common package. > When I finally managed to get the test kernel compiled, I couldn't install > it, either via apt or dpkg. I was told that apt would take care of removing > the dependencies causing the conflict, but it didn't. DKMS wasn't > triggered, it was a mess. 2) make it easy/easier to install the resulting kernel deb, which does not involve removing an existing kernel (meta) package. By setting the 'abiname' 'property' you can achieve that, but I don't know if that idea has been evaluated before and discarded. But the kernel maintainers should be able to answer that. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1022042: kernel 5.10.149-2 does not help
On zondag 23 oktober 2022 19:01:06 CEST Andreas Wirooks wrote: > Am 23.10.22 um 14:27 schrieb Diederik de Haas: > > On zondag 23 oktober 2022 14:10:11 CEST Andreas Wirooks wrote: > >>> You both have kernel parameters like these. Can you explain why? > >>> I have an AMD GPU on a machine and I have never set parameters like > >>> these. > >> > >> These are parameters for Southern Islands (si) and Sea Islands (cik) AMD > >> GPUs: > > I see you're already 'in' > > https://gitlab.freedesktop.org/drm/amd/-/issues/2216 and that seems like > > an important distinction to mention (to me). > > All the other cases for where this issue was fixed, seem to have (much) > > newer generation of GPUs. > > I will write an update in the drm issue too. > > I tested the old radeon driver by removing all si/cki options with > kernel 5.10.149-2 and it boots ok and uses drm 2 instead drm 3. Excellent. I saw you already added that info to the upstream bug :-) > The debian 11/bullseye backport kernel 5.19.11-1~bpo11+1 boots ok with > the amdgpu driver too using drm 3. Alex Deucher (@agd5f) indicated the problem was caused by an incorrect backport to 5.10 and maybe the 2 identified ones aren't the only ones. On zondag 23 oktober 2022 17:44:17 CEST inasprec...@disroot.org wrote: > I tried booting 5.10.0-19 with an empty command line string and it > worked > > I don’t know if this an entirely separate issue, however. I can > file a separate bug if you think it is appropriate. Given that switching to the radeon driver fixed the issue for you both, then I guess it's the same issue. So let's keep it to this bug, at least for now. signature.asc Description: This is a digitally signed message part.
Bug#1022544: linux-image-6.0.0-2-amd64: No more sound after upgrade to 6.0.0-2
Control: tag -1 upstream On Sunday, 23 October 2022 19:01:52 CEST pdorm...@free.fr wrote: > After upgrade from 6.0.0-1 to 6.0.0-2, I don't have sound anymore. > I believe that the relevant dmesg message is this one, as it is not printed > with the 6.0.0-1 version: > > snd_hda_codec_hdmi ehdaudio0D2: failed to create hda codec -12 > snd_hda_codec_hdmi ehdaudio0D2: ASoC: error at snd_soc_component_probe on > ehdaudio0D2: -12 skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: failed to > instantiate card -12 skl_hda_dsp_generic: probe of skl_hda_dsp_generic > failed with error -12 > > git bisect indicates that the bad commit is: > [7494e2e6c55ed192f2b91c821fd6832744ba8741] ALSA: hda: Fix page fault in > snd_hda_codec_shutdown() Thanks for that wonderful analyses! Both you and Lisandro had "sof-audio-pci-intel-tgl" in dmesg, but I don't. Lisandro also has the firmware-intel-sound package installed (but not you). Sound on my system works with 6.0.0-2, so the 'intel' part looks relevant. Could you report it upstream by replying to the thread linked in that commit: https://lore.kernel.org/all/20220816111727.3218543-7-cezary.rojew...@intel.com/ signature.asc Description: This is a digitally signed message part.
Bug#1022097: Fixed
Control: severity -1 serious Control: merge -1 1022042 On maandag 24 oktober 2022 09:38:45 CEST beks...@westnet.com.au wrote: > Installation of updates on 24 October fixed problem. This is the same problem as reported and fixed (for most ppl) in 1022042. signature.asc Description: This is a digitally signed message part.
Bug#1022097: Fixing merging bugs
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/2216 Control: tag -1 patch pending upstream Control: merge -1 1022042 signature.asc Description: This is a digitally signed message part.
Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0
Control: forcemerge -1 1022126 On woensdag 26 oktober 2022 18:18:28 CEST Daniel Smolik wrote: > Hi, I have normal boot with 5.10-18 see attached dmesg. And 2 > screenshots with boot failure under 5.10.-19. I was pretty certain I had heard of such an issue before, but couldn't find it. Until just now and it's the same issue as in 1022126, so merging the bugs. signature.asc Description: This is a digitally signed message part.
Bug#1022268: Processed: Re: Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0
Control: forwarded -1 1022...@bugs.debian.org Control: tag -1 -moreinfo On woensdag 26 oktober 2022 23:57:05 CEST Debian Bug Tracking System wrote: > Unset Bug forwarded-to-address Oeps signature.asc Description: This is a digitally signed message part.
Bug#1022268: Processed: Re: Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0
Control: forwarded -1 https://lore.kernel.org/linux-scsi/y1jkuktjvyrow...@eldamar.lan/T/#u On donderdag 27 oktober 2022 00:21:32 CEST you wrote: > Control: forwarded -1 1022...@bugs.debian.org Pfft *facepalm* signature.asc Description: This is a digitally signed message part.
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
On Thursday, 27 October 2022 15:56:28 CEST Stephan Verbücheln wrote: > Version: 6.0.3-1 > > When I boot with kernel 6.0.x, grub-install, efibootmgr etc. keep > failing. With kernel 5.19.x it works on the same machine with the same > userland. Can you try whether applying the following patch fixes that issue? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/? h=linux-6.0.y&id=c2a000ad03bb3a0d0f389adcfc9f8c61622da363 That is part of upstream's v6.0.4 tag/release. signature.asc Description: This is a digitally signed message part.
Bug#1022806: linux-image-5.10.0-19-amd64: amggpu unbootable problem persists
On woensdag 26 oktober 2022 12:43:02 CEST Alexis Huxley wrote: > 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. AFAICT, which may be incorrect, the issue is slightly different from the other related bug report (#1022042) in that here it is a system which does not boot. The other problem that is fixed, is where the system does boot, but the graphics don't work correctly. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022042#105 is where Andreas Wirooks (See also https://gitlab.freedesktop.org/drm/amd/-/issues/ 2216#note_1601632) reported on that/this issue and in msg 110 'inasprecali' reported the same issue (AFAICT). See also the msgs that follow, which may give hints as to where the non-boot issue may come from. It _may_ also be related to older chipset variants. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1022939: linux-image-6.0.0-2-amd64: 6.0.0-2-amd64 regressions: Lenovo Carbon X1 gen7 can't suspend, sound card not instantiated
On Friday, 28 October 2022 04:07:05 CEST Akkana Peck wrote: > - systemctl suspend no longer works: instead of suspending, it freezes, > and I have to hold the power button for 10 seconds to force a power down > - the laptop's built-in sound card (intel, using the firmware-intel-sound > package) is no longer seen. In dmesg there's a "failed to instantiate > card" error It's likely the 2nd issue is the same as https://bugs.debian.org/1022544 which should be fixed in the just uploaded 6.0.5-1 version. Please test that version and tell us whether the 1st issue is resolved then too or still present. signature.asc Description: This is a digitally signed message part.
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
On Friday, 28 October 2022 14:57:12 CEST Bogdan Veringioiu wrote: > this issue affecting the LVDS connector was reported here: > > https://gitlab.freedesktop.org/drm/intel/-/issues/7301 > > and fixed. > > Any chance it will be backported in 5.10? https://lore.kernel.org/all/20221026101134.20865-1-ville.syrj...@linux.intel.com/ is where the changes have been submitted upstream. When that gets accepted by the upstream maintainer, then a request for a backport to the _upstream_ 5.10 kernel can be made and when done and accepted then it should land in Debian's 5.10 kernel too. Ben: it would be really great and interesting to know whether the patches would solve your issue too. Are you able to test that? signature.asc Description: This is a digitally signed message part.
Bug#1022939: linux-image-6.0.0-2-amd64: 6.0.0-2-amd64 regressions: Lenovo Carbon X1 gen7 can't suspend, sound card not instantiated
On Friday, 28 October 2022 18:58:12 CEST Akkana Peck wrote: > That does sound like exactly the same sound issue. Sorry if this is a > dumb question, but where would I find 6.0.5-1? I tried searching for > linux-image-6.0.5, 6.0.5 and 6.0.5-1 in both unstable and experimental It'll takes some time for it to become available for users. First the upload needs to get accepted, then kernel are build and then a new upload happens for the signed variant and those need to be build and the final step is distributing it to the various Debian archive mirrors. It's only after the last step that they'll be visible for apt. It'll become available on unstable, you just need to have some patience :-) signature.asc Description: This is a digitally signed message part.
Bug#1022981: linux-image-6.0.0-2-amd64: after boot kernel 6.0 failed to instatiate audio card regression from 5.19
Control: tag -1 upstream Control: merge -1 1022544 On Friday, 28 October 2022 19:51:43 CEST karol wrote: > Version: 6.0.3-1 > Severity: important signature.asc Description: This is a digitally signed message part.
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Control: found -1 6.0.5-1 On Friday, 28 October 2022 23:09:00 CEST Stephan Verbücheln wrote: > I have now compiled and booted vanilla kernel 6.0.5. “efibootmgr -o” is > not working. > > I double-checked that with kernel 5.19.11 (Debian), it is working fine. Thanks for testing and reporting back. Updating metadata accordingly. This was the message with which this bug was opened: On Thursday, 27 October 2022 15:56:28 CEST Stephan Verbücheln wrote: > When I boot with kernel 6.0.x, grub-install, efibootmgr etc. keep > failing. With kernel 5.19.x it works on the same machine with the same > userland. Adding debian-boot@l.d.o in the loop as 'grub-install' and 'efibootmgr' are subjects on which that list has more expertise (I think). signature.asc Description: This is a digitally signed message part.
Bug#1014451: firmware-brcm80211: brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.txt on a Raspberry Pi 4
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. signature.asc Description: This is a digitally signed message part.
Bug#1023003: linux-image-6.0.0-2-amd64: No intel sound card detected when updated to kernel 6
Control: tag -1 upstream Control: forcemerge -1 1022544 On Saturday, 29 October 2022 00:09:10 CEST zezamoral wrote: > Package: src:linux > Version: 6.0.3-1 > Severity: important > >* Updating to Linux Image amd64 6.0.3-1 caused the sound card to be > undetected.. Same issue as 1022544, thus merging (and closing) signature.asc Description: This is a digitally signed message part.
Bug#1009334: firmware-amd-graphics: Freeze for VCN videos
Control: tag -1 moreinfo On Monday, 11 April 2022 23:32:26 CEST Tobias Koeck wrote: > Package: firmware-amd-graphics > Version: 20210818-1 > > I was affected by a freeze by this bug > > https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-FW-Avoid-VCN-Mult > i-Hang > > Can you add the firmware files AMD added today? Can you verify whether your issue is fixed with version 20220913-1 ? signature.asc Description: This is a digitally signed message part.
Bug#1021157: missing firmwares for Qualcomm NFA725A
Control: tag -1 moreinfo On Monday, 3 October 2022 01:53:49 CEST Marco d'Itri wrote: > The card works just fine with a 5.19 kernel after installing these files > in /usr/lib/firmware/ath11k/WCN6855/hw2.0/: > https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.H > SP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/amss.bin > https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN. > HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/m3.bin > https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/board-2.b > in > https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/regdb.bin > > And then creating a symlink from /usr/lib/firmware/ath11k/WCN6855/hw2.1/ > to hw2.0/ . > > (I do not understand the structure of the directories in > WCN6855/hw2.0/1.1/, so I choose the newest files.) > > Some other firmwares from > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > /tree/qca are needed for Bluetooth support and are missing as well: > > qca/rampatch_usb_00130201.bin > qca/nvm_usb_00130201_gf.bin I found all the mentioned file names in the buildd log for 20220913-1, so I guess the issue is fixed. Can you verify that and update/close the bug accordingly? signature.asc Description: This is a digitally signed message part.
Bug#1001927: firmware-iwlwifi: iwlwifi-8265-36.ucode does not load: Failed to start INIT ucode: -110
Control: tag -1 moreinfo On Sunday, 19 December 2021 04:12:27 CEST Alexander Prinsier wrote: > Package: firmware-iwlwifi > Version: 20210818-1 > > Recently did a dist upgrade, which upgraded firmware-iwlwifi to version > 20210818-1. > > On the next reboot (at least I believe it was the first reboot after the > upgrade), my wifi interface is missing. > > ... > > I.e. it reverted back to firmware iwlwifi-8265-22.ucode. My wifi interface > is back now. > > Seems the new 8265-36 firmware is buggy. Can you test the recently uploaded version 20220913-1 and update this bug? signature.asc Description: This is a digitally signed message part.
Bug#1022559: firmware-misc-nonfree: With firmware-misc-nonfree instaled, system crashes (complete freeze/lockup) every few minutes
Control: tag -1 moreinfo On Sunday, 23 October 2022 22:51:09 CEST the.wingmanx wrote: > Package: firmware-misc-nonfree > Version: 20210818-1 Can you verify whether the issue is fixed with version 20220913-1 ? signature.asc Description: This is a digitally signed message part.
Bug#1008972: firmware-iwlwifi: iwlwifi reports errors while shutdown computer
Control: tag -1 moreinfo On Tuesday, 5 April 2022 13:11:14 CEST dasebastian wrote: > Package: firmware-iwlwifi > Version: 20210315-3 > > after updating my system to bullseye, I mostly always get a lot of errors > when shuting down the computer (if I was logged in into a wireless > network). Things like: > > [ 536.451518] iwlwifi :03:00.0: Error sending REPLY_SCAN_ABORT_CMD: time > out after 2000ms. [ 536.451668] iwlwifi :03:00.0: Current CMD queue > read_ptr 28 write_ptr 29 [ 536.699549] iwlwifi :03:00.0: Loaded > firmware version: 18.168.6.1 6000g2a-6.ucode > > -- System Information: > Debian Release: 11.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') Architecture: amd64 (x86_64) Stable backports has version 20210818-1~bpo11+1, could you try and report back whether that improves/fixes your issue? Unstable recently got version 20220913-1 and if the above version didn't fix it, it would be useful to know whether the latest version does. signature.asc Description: This is a digitally signed message part.
Bug#981616: RPi4B 5GHz WiFi problems #985632 & #981616 completely went away by replacing brcmfmac43455-sdio.bin and brcmfmac43455-sdio.clm_blob
Control: tag -1 moreinfo On Monday, 29 March 2021 14:54:19 CEST Ryutaroh Matsumoto wrote: > Control: reassign 981616 firmware-brcm80211 20201218-3 > > two RPi4B 5GHz WiFi problems > > #985632 > firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with > 20210208-4, 20201218-3 was fine > > and > > #981616 > 5GHz WiFi does not work with vc4.ko on RPi4 and 4K display > > completely went away by replacing > /lib/firmware/brcm/brcmfmac43455-sdio.bin and > /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob There have been several firmware releases since, including the (very) recent version 20220913-1. Could you update both bug with updated firmware? signature.asc Description: This is a digitally signed message part.
Bug#1023016: linux-image-6.0.0-2-amd64: crashes in kernel 6.0.2 (6.0.0-2-amd64) during resume
On Saturday, 29 October 2022 11:08:01 CEST karol wrote: > Package: src:linux > Version: 6.0.3-1 > > I noticed several internal crashed in linux kernel ... > This happened today during resume. > > They are follow as below: > > paź 29 10:55:35 karol kernel: [ cut here ] > paź 29 10:55:35 karol kernel: WARNING: CPU: 4 PID: 20960 at > kernel/workqueue.c:3066 __flush_work.isra.0+0x270/0x280 Commit c0feea594e058223973db94c1c32a830c9807c86 changed `kernel/workqueue.c` around line 3066 and is the only change in that file that is part of 6.0 and not part of 5.19. So it would be an interesting test to see if the issue 'goes away' if you'd build a kernel with that commit reverted (and boot into it ofc). Can you try that? signature.asc Description: This is a digitally signed message part.
Bug#1021157: missing firmwares for Qualcomm NFA725A
On zaterdag 29 oktober 2022 07:15:19 CEST Vincent Bernat wrote: > On 2022-10-29 00:50, Diederik de Haas wrote: > >> The card works just fine with a 5.19 kernel after installing these files > >> in /usr/lib/firmware/ath11k/WCN6855/hw2.0/: > >> https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLA > >> N.H SP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/amss.bin > >> https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLA > >> N. > >> HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/m3.bin > >> https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/board-2 > >> .b > >> in > >> https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/regdb.b > >> in > >> > >> And then creating a symlink from /usr/lib/firmware/ath11k/WCN6855/hw2.1/ > >> to hw2.0/ . > >> > >> (I do not understand the structure of the directories in > >> WCN6855/hw2.0/1.1/, so I choose the newest files.) > >> > >> Some other firmwares from > >> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.g > >> it/tree/qca are needed for Bluetooth support and are missing as well: > >> > >> qca/rampatch_usb_00130201.bin > >> qca/nvm_usb_00130201_gf.bin > > > > I found all the mentioned file names in the buildd log for 20220913-1, so > > I guess the issue is fixed. > > Can you verify that and update/close the bug accordingly? > > They are not present. > > 07:14 ❱ dpkg -L firmware-atheros | grep -E '(WCN6855|nvm_usb_00130201)' Thanks for checking. It turned out my checks were 'incomplete'. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?qt=grep&q=WCN6855 does show various results which come very close ...SILICONZ_LITE-3.6510.7 vs the referenced ...SILICONZ_LITE-3.6510.16. And one commit is for symlinks to hw2.1 qca/rampatch_usb_00130201.bin is also present in the upstream repo, but searching for nvm_usb_00130201_gf.bin did not yield any results. So this looks like upstream does have most of the needed files, albeit a slightly older version? I don't know if anything should be done based on this, but figured I'd share my findings. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1023025: linux-image-6.0.0-2-686: kernel BUG at mm/memory.c:2660!
Control: tag -1 -a11y On zaterdag 29 oktober 2022 12:33:59 CEST femenia wrote: > Package: src:linux > Version: 6.0.3-1 > Severity: grave > Tags: a11y I don't see how a11y is relevant here, so removing the tag signature.asc Description: This is a digitally signed message part.
Bug#1023076: linux-headers-6.0.0-2-amd64: bluetooth crashes after returning from suspend
Control: reassign -1 src:linux 6.0.3-1 Control: severity -1 important On Sunday, 30 October 2022 00:50:25 CEST Gabriel Francisco wrote: > Package: linux-headers-6.0.0-2-amd64 > Version: 6.0.3-1 > Severity: normal > > With this kernel seems to crash bluetooth when returning from > suspend. Few days ago my cursor froze, the computer rebooted and I > couldn't find logs in /var/log/syslog. > > I think it might be related to #1021905. Indeed many similarities, but not exactly the same ... > [24595.999699] general protection fault, > ... > [24595.999793] ? bt_sock_wait_ready+0x128/0x1a0 [bluetooth] These things are different. I increased severity because of GPF. Before we look further, can you test 6.0.5-1 available in Unstable? signature.asc Description: This is a digitally signed message part.
Bug#1023107: linux-image-amd64: Memory leak on kernel image
Control: reassign -1 src:linux 4.19.260-1 signature.asc Description: This is a digitally signed message part.
Bug#1021157: missing firmwares for Qualcomm NFA725A
On Saturday, 29 October 2022 23:17:20 CET Vincent Bernat wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi > > t/log/?qt=grep&q=WCN6855 does show various results which come very close > > ...SILICONZ_LITE-3.6510.7 vs the referenced ...SILICONZ_LITE-3.6510.16. > > And one commit is for symlinks to hw2.1 > > > > qca/rampatch_usb_00130201.bin is also present in the upstream repo, but > > searching for nvm_usb_00130201_gf.bin did not yield any results. > > > > So this looks like upstream does have most of the needed files, albeit a > > slightly older version? > > I don't know if anything should be done based on this, but figured I'd > > share my findings. > > I suppose the search engine only works for stuff mentioned directly in > commit messages. The file present in the repository: > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > tree/qca/nvm_usb_00130201_gf.bin. https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/37 looks interesting :-) signature.asc Description: This is a digitally signed message part.
Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless
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. Also a factor is https://bugs.debian.org/984873 and https://bugs.debian.org/984873 where the same bug submitter did not respond to questions for more info, probably due to email bounces. signature.asc Description: This is a digitally signed message part.
Bug#1023183: mpt3sas driver does not load
Control: reassign -1 src:linux 5.10.149-2 Control: tag -1 moreinfo On maandag 31 oktober 2022 11:30:29 CET Taavi Ansper wrote: > Package: Linux Kernel > Version: 5.10.19 > > After the new security patch to upgrade kernel to 5.10.19 we noticed that > our external NetApp disk bay drives did not show up in our servers. Further > investigation pinpointed this to the mpt3sas driver. Are you using Xen? We had a/2 recent reports wrt mpt3sas (#1022126) but that involved Xen. > Here is dmesg output. > > mpt3sas_cm0: failure at > drivers/scsi/mpt3sas/mpt3sas_scsih.c:11069/_scsih_probe()! Can you share more, preferably all, of the dmesg output? signature.asc Description: This is a digitally signed message part.
Bug#992304: Dell PowerEdge T140
On Thursday, 27 October 2022 15:56:33 CET Gabriel Rolland [Res Novae] wrote: > Same problem with the Dell PowerEdge T140 with LSI MegaRAID SAS-3 3008 > [Fury] (rev 02) and linux-image-5.10.0-19-amd64 (NO UEFI) > > No problem booting with the old 4.19.0-22-amd64 kernel The best way to make progress with this is doing a `git bisect` where good = v4.19.194 (= 4.19.0-17)* and bad = v5.10.46 https://wiki.debian.org/DebianKernel/GitBisect *) I think that's better/faster then v4.19.260 (=4.19.0-22), but I'm not sure. Hopefully someone can confirm/deny that and offer a better/faster strategy. signature.asc Description: This is a digitally signed message part.
Bug#1023321: vmdb2: Seems to require 'mount-on' parameter for mounting root filesystem
Package: vmdb2
Version: 0.26-2
Severity: important
Tags: upstream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In https://salsa.debian.org/raspi-team/image-specs/-/merge_requests/61
I am/was trying to fix an ambiguity issue I had by replacing tag values
which look like filesystem paths with 'tag-X'.
For mounting 'tag-root' I explicitly added ``dirname: '/'``.
Old:
```
- mount: /
```
New:
```
- mount: tag-root
dirname: '/'
```
I did NOT set the 'mount-on' parameter as there was not an already
mounted filesystem.
But trying to build an image resulted in the following error:
```
remembering /dev/mapper/loop0p1 as tag-firmware
remembering /dev/mapper/loop0p2 as tag-root
Exec: ['/sbin/mkfs', '-t', 'vfat', '-n', 'RASPIFIRM', '/dev/mapper/loop0p1']
Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p1']
Exec: ['/sbin/mkfs', '-t', 'ext4', '-L', 'RASPIROOT', '/dev/mapper/loop0p2']
Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p2']
ERROR: no mount-on tag given
ERROR: Exception('no mount-on tag given')
Something went wrong, cleaning up!
```
The [documentation](https://vmdb2-manual.liw.fi/#step-mount) already has
``FIXME: this may be wrong?`` and that statement seems to be correct.
- -- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vmdb2 depends on:
ii cmdtest 0.32.14.gcdfe14e-5
ii debootstrap 1.0.128+nmu2
ii e2fsprogs 1.46.6~rc1-1+b1
ii kpartx 0.9.0-4+b1
ii parted 3.5-2
ii python3 3.10.6-1
ii python3-jinja2 3.0.3-2
ii python3-yaml6.0-3
ii qemu-utils 1:7.1+dfsg-2+b1
Versions of packages vmdb2 recommends:
ii ansible 6.4.0+dfsg-1
ii dosfstools4.2-1
ii qemu-user-static 1:7.1+dfsg-2+b1
vmdb2 suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY2JI3AAKCRDXblvOeH7b
bt2HAP9m9MT+8dnx6kw5k1e4I9b/mPoRT5OWOPZT0ACQh+gMGQEA5LAyv78YMj1x
Mkd9wkFPf2CLwrCnRO3w0PTGd9Lc+gE=
=Aspx
-END PGP SIGNATURE-
Bug#1023321: vmdb2: Seems to require 'mount-on' parameter for mounting root filesystem
Control: severity -1 normal On 02 Nov 2022 11:39:33 +0100 Diederik de Haas wrote: > Package: vmdb2 > Version: 0.26-2 > Severity: important > Tags: upstream > > For mounting 'tag-root' I explicitly added ``dirname: '/'``. Removing that and it succeeds, so lowering severity to normal. ``` remembering /dev/mapper/loop0p1 as tag-firmware remembering /dev/mapper/loop0p2 as tag-root Exec: ['/sbin/mkfs', '-t', 'vfat', '-n', 'RASPIFIRM', '/dev/mapper/loop0p1'] Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p1'] Exec: ['/sbin/mkfs', '-t', 'ext4', '-L', 'RASPIROOT', '/dev/mapper/loop0p2'] Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p2'] Exec: ['mount', '/dev/mapper/loop0p2', '/tmp/tmpx5_qtdal'] Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpx5_qtdal/.//boot/firmware'] ``` signature.asc Description: This is a digitally signed message part.
Bug#1023321: vmdb2: Seems to require 'mount-on' parameter for mounting root filesystem
On woensdag 2 november 2022 12:37:53 CET you wrote:
> > For mounting 'tag-root' I explicitly added ``dirname: '/'``.
>
> Removing that and it succeeds, so lowering severity to normal.
https://gitlab.com/larswirzenius/vmdb2/-/blob/main/vmdb/plugins/mount_plugin.py#L50:
```
def mount_rootfs(self, values, settings, state):
tag = values["mount"]
dirname = values["dirname"] or None
mount_on = values["mount-on"] or None
device = state.tags.get_dev(tag)
if dirname:
if not mount_on:
raise Exception("no mount-on tag given")
```
The code indicates they MUST be used both or neither.
signature.asc
Description: This is a digitally signed message part.
Bug#1023326: vmdb2: The 'require_empty_target' of the 'debootstrap' step is not documented
Package: vmdb2 Version: 0.26-2 Severity: minor Tags: upstream X-Debbugs-Cc: l...@liw.fi -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For the 'Raspberry Pi image specs' project, I made a MR to switch from 'qemu-debootstrap' to 'debootstrap': https://salsa.debian.org/raspi-team/image-specs/-/merge_requests/62 But just replacing 'qemu-debootstrap' with 'debootstrap' wasn't sufficient and caused a build failure. That surprised me as I _thought_ 'qemu-debootstrap' just called debootstrap and we didn't get any failure then. Trying to find the cause of this failure let me to inspect the source and then I found 'require_empty_target', but found it was not documented in the upstream manual: https://vmdb2-manual.liw.fi/#step-debootstrap Hopefully this bug will remedy that. Cheers, Diederik - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vmdb2 depends on: ii cmdtest 0.32.14.gcdfe14e-5 ii debootstrap 1.0.128+nmu2 ii e2fsprogs 1.46.6~rc1-1+b1 ii kpartx 0.9.0-4+b1 ii parted 3.5-2 ii python3 3.10.6-1 ii python3-jinja2 3.0.3-2 ii python3-yaml6.0-3 ii qemu-utils 1:7.1+dfsg-2+b1 Versions of packages vmdb2 recommends: ii ansible 6.4.0+dfsg-1 ii dosfstools4.2-1 ii qemu-user-static 1:7.1+dfsg-2+b1 vmdb2 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY2JriwAKCRDXblvOeH7b bgG5AQCMe7BvfZyUpHs+ilC+aH3VWUiugKajQvUUXegkXwFxqQEA1HSaBML8c6bF +yqI4Zd5kxyux4kscP6w4J/hsg4wOwA= =stqp -END PGP SIGNATURE-
Bug#1023348: Null dereference in dentry_unlink_inode / kswapd
Control: severity -1 normal On Wednesday, 2 November 2022 18:16:12 CET nmr wrote: > Package: src:linux > Version: 5.10.4-1 This is one of the very first 5.10.x versions! ... > -- System Information: > Debian Release: 11.5 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Stable-security currently has 5.10.149-2 and Debian release 11.5 was released less then 2 months ago. Your system seems configured correctly and up-to-date, but that doesn't match your kernel version. Even the initial release of Bullseye was with a much newer kernel version from the 5.10 series. Lowering the severity until you can reproduce this issue with an up-to-date kernel version. signature.asc Description: This is a digitally signed message part.
Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless
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. signature.asc Description: This is a digitally signed message part.
Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless
On donderdag 3 november 2022 12:37:19 CET you wrote: > 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. While commit 4190e8bbcbc77a9c36724681801cedc5229e7fc2 wasn't backported, only ae71ab585c819f83aec84f91eb01157a90552ef2 was, I do wonder why. While it wasn't needed to fix the boot problem, it may still leave another problem still present (even if I don't know which that is). signature.asc Description: This is a digitally signed message part.
