Bug#1063161:
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote: > 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? Sure. Bit surprised it wouldn't be automatically selected though. signature.asc Description: This is a digitally signed message part.
Bug#1071258: linux-image-6.1.0-21-amd64: Mouse, trackpad, keyboard behave inconsistently
On Thursday, 23 May 2024 09:59:52 CEST Eduardo Casais wrote: > 4) Determining whether the bug was introduced by the passage from kernel > 5.10.0 to 6.1.0, or whether it was an error introduced between releases > of image 6.1.0-*. > > Attempted resolution: > > I looked at the image versions available in Synaptic, installed the > oldest one available: linux-image-6.1.0-11-amd64, and restarted the system. > > Result: > > The problem occurs again. I did not try installing other images between > 6.1.10-11 and 6.1.10-21. > > At this stage, I must leave it to you to investigate and suggest further > operations that may help diagnose the problem and ferret out the bug. Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find deb packages for all the versions released to Debian which includes kernels older then 6.1.10-11. With that you can find the latest version that still works and the next version where this bug occurs. signature.asc Description: This is a digitally signed message part.
Bug#1071559: linux-headers-6.8.9-amd64: error creating r8125 module with dkms
Control: reassign -1 r8125-dkms On Tuesday, 21 May 2024 10:41:54 CEST Pierpaolo Toniolo wrote: > Was installing the linux-image-6.8.9-amd64 and it's fellow linux- > headers-6.8.9-headers. > At modules creation with dkms I got an error building module r8125 (package > r8125-dkms) Which is a problem of r8125-dkms, thus reassigning signature.asc Description: This is a digitally signed message part.
Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate
On Monday, 20 May 2024 21:07:49 CEST Salvatore Bonaccorso wrote: > - I did read you cannot trigger with 5.15. If you build 6.1.90 from > upstream without Debian patches I assume you can trigger the issue > likewise? If so could you bisect the changes introducing the issue? If the test with the upstream 6.1.90 version also has this problem, there's another (series of) test(s) worth doing, which could shorten the bisect operation significantly. I got the impression that you have only tried it with version 6.1.90. Have you tried it with earlier versions in the 6.1 series to see if the issue is present there? Via https://snapshot.debian.org/package/linux-signed-arm64/ you can find earlier versions from the 6.1 series already compiled and packaged. To take version 6.1.52 as (random) example: - click on the ``6.1.52+1`` link - In the ``Binary packages`` list, click on the linux-image-6.1.0-X-arm64 link, where 'X' is 12 in this case - Click the ``linux-image-6.1.0-12-arm64_6.1.52-1_arm64.deb`` link to download the deb file which you can then install as root or with sudo by executing ``apt install ./linux-image-_arm64.deb`` If the problem does NOT occur with 6.1.52-1, then you try a higher version. Continue that process until you've found the latest version that works and the earliest version where it stopped working. If the problem also occurs with 6.1.52-1, then you try an (even) older version. This is to test whether it was a regression *within* the 6.1 series and if so, to get the narrowest range without having to compile yourself. HTH signature.asc Description: This is a digitally signed message part.
Re: Contacting Debian Kernel team
On Monday, 20 May 2024 12:41:48 CEST Ben Hutchings wrote: > > - Can I do anything for you? > > My top priority would be more computing resources for Salsa, and > particularly for CI runners. +1 That was the first thing that came to my mind too, but it felt out of place for me to suggest that. I've less problems giving a '+1' on a suggestion from someone like Ben. >From "Salsa stats for the curious" on debian-project ML: On Friday, 12 April 2024 17:32:04 CEST Joerg Jaspert wrote: > The VM this all runs on has 8 cores and 32g I had several thoughts about that: - The PC on which I'm typing this email has twice the resources - It's impressive that the whole of Salsa can run on that - But why doesn't have f.e. 4x or 8x those resources? I think Salsa is great and I'm a big fan of CI. But IMO Salsa isn't exactly fast and particularly running the CI pipelines takes (way) longer then I'd like. The major value of a CI is in providing a fast feedback loop. Not hindered by any knowledge in this specific area, this seems an area where throwing money at it will actually help. Possibly substantially. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1071184: Kernel 6.6 and 6.7 route-leak between VRF and default leads to Time to live exceeded
On Friday, 17 May 2024 15:08:17 CEST Development EasyNet wrote: > I will try. Meanwhile I was troubleshooting this issue for some time and > I notice a change in FRRouting between 9.1 and 10.0. > Before 10.0 FRRouting was installing the routes in kernel using the > destination interface of the route. Starting from 10.0 FRRouting is > installing all routes towards the VRF interface. > > Here is my bug reported on FRRouting: > https://github.com/FRRouting/frr/issues/15909 I have no (particular) knowledge about kernel routing or FRRouting, so I can't help with that aspect. But if the problem is resolved with 6.8.9, then that seems the easiest solution and means the underlying issue is fixed. If not, it's useful to know if there is a(n older) kernel version where it does work. But given there's also a FRR 9.x -> 10.x upgrade at play, I'm not so sure the problem is actually in the kernel. signature.asc Description: This is a digitally signed message part.
Bug#1071184: Kernel 6.6 and 6.7 route-leak between VRF and default leads to Time to live exceeded
Control: tag -1 moreinfo On 15 May 2024 16:08:27 +0200 Development EasyNet wrote: > Package: linux-image > Version: 6.6.15-2 and 6.7.12-1 > > I'm facing for some time a strange behavior of the route-leak. It happen > on both IPv4 and IPv6. > Configuration used: Debian Trixie, Kernel 6.7.12 with FRRouting 10.1 - git > VRF: internet > Default: just local management Sid recently got a 6.8.9 kernel, can you test whether that fixes the issue? signature.asc Description: This is a digitally signed message part.
Bug#1071263: linux-image-6.8.9-amd64: Vulkan applications crash on computers using amdgpu
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/3343 signature.asc Description: This is a digitally signed message part.
Bug#1069077: rockpro64: multiple kernel oops and frequent boot failures
On Friday, 17 May 2024 03:36:35 CEST Forest wrote: > A git bisect reveals it to be fixed by this commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id= > f7a59018953910032231c0a019208c4b0a4a8bc3 > > maple_tree: make mas_erase() more robust > > > > mas_erase() may not deal correctly with all maple states. Make the > > function more robust by ensuring the state is in one of the two acceptable > > states. Kernel 6.8.9 has recently been uploaded to Unstable which has that commit. Can you verify that it indeed fixes this bug? signature.asc Description: This is a digitally signed message part.
Re: Updates to linux-firmware
Hi Mark, On Tuesday, 7 May 2024 19:30:59 CEST Mark Pearson wrote: > > I already mentioned that MR 85 is a BIG one (but the only one which needs > > to go through NEW), which in turn means that reviewing takes more then 10 > > minutes (to put it mildly). > > > > The updates after that are indicative of what I suspect/hope future > > updates will look like. Unless a kernel-team member thinks that I didn't > > do it correctly. While I did my best, that's surely a possibility. > > Cool - I have taken a very quick look and kudos - amazing job. Cheers :) > A few follow on questions: > > - It looks like it is stuck on someone doing the upload (guessing nobody > has time to do that). Unfortunately I can't help with that bit - not a DM > and nowhere near enough experience. As it has to go through NEW, the uploader must be a DD (not a DM). AFAIK, it's not the upload that's the blocker (that should be rather quick), but the *review* of MR 85. And those reviews are VERY important (more on that later). > And, thinking about the comment previously about funding - is this something > where somebody needs some paid time to do the exercise? IIF that's an option then I'd guess they'd contact you, most likely privately. The most likely scenario, as is the case for 99% (just a guess) of the software packaged for Debian, is that someone needs to find the time (and motivation) to do that 'work' in their FREE time. > - I love what you've done with the monthly cadence of updates, that seems > smart to me but I appreciate it's a chunk of work every month. My guess is that it'll take a couple (probably <4) of hours a month. > I also noted in one of the commits you mentioned "I don't particularly care > about this package, but just wanted to do something about the (big) backlog > AND make it easier to prevent a backlog from appearing again in the future > (by making it easier for everyone to make an update)", so I'm assuming you'd > like done with it ASAP. Debian is often described as a do-ocracy so I did what was in my power and that was making a MR which would/could fix the problem I was seeing. It wasn't the most enjoyable thing I've done, but someone needed to do the 'work', so why not me? > You noted earlier that it wasn't documented and added some useful notes. > Would it be helpful to work through that process with an idiot (aka...me) to > get an initial document down as a starting point? I haven't added my procedure to a MR because I wanted to have a review first. As I've learned over time, there tends to be very good reasons why things are done (and described in README.source) a certain way. I didn't manage to find the reason why the described update procedure was as written down. It could be that 'my' procedure does something wrong or is incomplete or not the best/appropriate way, which I expect will be pointed out in the review. If the reviewer thinks my procedure is actually better, then I'll write it down and submit that as MR too. That shouldn't take much time. > With the last MR being a few months old now, would it be reasonable > for me to take a stab at doing an update and (worst-case) learning from it? Generally the best way to learn something is by doing it ;-) > - Previously you noted "Upstream now also produces a deb package per > tag/release" - I had a look for those but couldn't find it. Do you have a > location I can check those out? Figured it would be interesting to have a > look. https://gitlab.com/kernel-firmware/linux-firmware/ is now the place where upstream changes are merged. When a release is tagged, their CI now produces a deb (and rpm) package. So on https://gitlab.com/kernel-firmware/linux-firmware/-/tags you'll see a (hopefully green) checkmark indicating the success of the pipeline run. https://gitlab.com/kernel-firmware/linux-firmware/-/pipelines/1247368343 would be the one for the 20240410 tag/release and if you click through to the 'deb- release' job and then you can download or browse through to the artifact(s), which in this case is a 347 MiB deb package with all the firmware. > >> I can't highlight all patches needed for Meteorlake/Hawkpoint support - > >> that would be huge. I can highlight that a 6.8 kernel is needed; and > >> which FW packages are needed. > > > > But (my) update-to-6.8 MR has now been merged into master, so an update to > > the 6.8 kernel is in the works. > > That's awesome. If you want any sanity checks run on it, let me know - When you submit a MR you are (generally) expected to have verified it works as intended. While I did build a 6.8 kernel, I tend to use the 'nodoc' profile. The review of that MR (in this case by Ben) turned out that it actually contained an error ... in building the documentation. So while using the 'nodoc' is generally fine for my use case, next time I really should also make a build with the 'doc' profile (which is the default). That's why those reviews are so important! > I have a number of
Re: Updates to linux-firmware
On Tuesday, 7 May 2024 15:49:45 CEST Mark Pearson wrote: > > As I see it, the primary problem is the lack of people actively > > contributing to the Debian kernel team's work. In general. > > Interesting read, and combined with my notes to Didier - is this something > where I and some in my team could maybe help? If you think it would be > worthwhile, does it make sense to setup a training session to walk me > through the steps so I can attempt a first pass, and then review where the > problems are and which bits are useful/not-useful. If the review/link > updating/etc was all done - would it make it easier for a DM to look at it > and go "yeah, that's solid" and release? *I* don't see where you/your team could help now. At least not for this particular issue. General help with f.e. bug triaging would still be welcomed I presume. At https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/ you can find the MRs I made to make the firmware-nonfree packages all up to date. MR 85 is 'the BIG one' and in there I also mentioned that I also have an update to 20240312 in my fork which I can submit as MR too. MR 85 is also reviewed by a DD, but while they are *allowed* to make uploads for any package, they choose not to. And FWIW: I agree with that. I already mentioned that MR 85 is a BIG one (but the only one which needs to go through NEW), which in turn means that reviewing takes more then 10 minutes (to put it mildly). The update to 20230804 is also larger then average as some changes needed to be 'postponed' due to needing a new upstream version. The updates after that are indicative of what I suspect/hope future updates will look like. Unless a kernel-team member thinks that I didn't do it correctly. While I did my best, that's surely a possibility. So if you want to know what's generally involved into updating the firmware- nonfree packages, I suggest to look into my MRs. I have a tendency to be verbose in my commit messages, which may help. And the procedure I described earlier should match what you'll see in the updates after 20230804. > I can't highlight all patches needed for Meteorlake/Hawkpoint support - that > would be huge. I can highlight that a 6.8 kernel is needed; and which FW > packages are needed. While firmware package updates have lagged before, the kernel packages are normally quite up-to-date. But sometimes there are other factors which cause delays which normally aren't there. The time64 transition f.e. caused 'some' disruptions. But (my) update-to-6.8 MR has now been merged into master, so an update to the 6.8 kernel is in the works. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Re: Updates to linux-firmware
On Tuesday, 7 May 2024 08:25:23 CEST Didier 'OdyX' Raboud wrote: > What I did back then to try to help getting the firmware package in better > shape was to dive in the (complex) packaging and try to produce "ready-to- > merge" merge-requests for new upstream releases, fixes, etc, then pinging > Ben at (what I considered) reasonable intervals. I see that Diederik > (CC'ed) has started to do the same for recent versions. What I did was indeed my effort to get things into better shape with the hope/ goal that it would be easier to do going forward. Which in turn hopefully means that it would be done more regularly which would not make it a monumental task ... which no-one is looking forward to do or has the capacity (time/motivation/etc) to do. > The package is complex and a mined land of legal concerns, It was a HUGE amount of work, partly because I wanted to get things into what I consider a better shape. Another part which made it *look* complex, were inconsistencies. In one of my commits I determined in which sequence the control fields were going to get placed and then fixed all the config files to conform to that sequence. I also ordered the entries alphabetically. I haven't documented it (yet), but I followed a different procedure then 'the official one', which I think makes it easier and better ... lowering the barrier for future contributions/MRs. It was basically the following: 1) Have the upstream repo locally and checkout the next tag/release and open that with gitk 2) Start a new branch in your local Debian firmware-nonfree repo 3) Go through each commit and decide what to do with it - Upstream merge commit: ignore it - Upstream working on their own infra: ignore it. Unless it has an effect on (future) Debian packaging, then add it to d/changelog. And use the secondary commit message to properly document it. - Updated version of firmware files: if it has a(n explicit) version number, update the version in the appropriate ``defines`` file. - New links (documented in WHENCE): Add that entry to the ``files:`` section of the Debian ``defines`` file. - New files: Add an entry to the `files:` section and add a Stanza for it with its 'ID'/Name, description and if available the version number - Check whether d/copyright covers any new files and if it doesn't expand the 'regex' so that it does if the license is already known. Otherwise add an entry and the license text to d/copyright* With updated versions or new links or new files, add an entry to d/changelog which is mostly or fully upstream's primary commit message, prepended by the Debian package name. This way there's an almost 1-on-1 match between the Debian and upstream's commit (message). This should also make reviews easier. I ordered the entries by Debian package name, so that if someone only has AMD graphics firmware, it doesn't have to read the full changelog, only the part which is about amd-graphics. Upstream's git commit log sequence is rather random, which isn't useful or helpful to our users (IMO ofc) *) I did improve d/copyright too, but not fully. All the license texts have been moved to the bottom, but I didn't fix the sequencing of all the stanzas. > the upstream repo needs repacking, Upstream now also produces a deb package per tag/release, but that's 350MB in size ... and growing. And it includes firmware which isn't DFSG compliant and therefor we shouldn't ship or f.e. can only be shipped as part of the kernel, so we can't distribute them. > and the (upstream & debian/) repositories are split; I think the split is very useful, especially for our users. Some users only need one or a few small firmware files. Not having to download >350MB for that for every upstream/Debian release/version is quite useful. Not everyone has unmetered GbE internet connection ... or wants to waste 300+MB for files for which they have no need/use. > I have not found this a very pleasant experience, sadly. I didn't find it pleasant either, but I hope/expect that with my updates and restructuring it shouldn't be that bad either. When things are kept up-to-date it's quite doable, but when you have to work through months of 'backlog' the 'fun' quickly diminishes. > And again; no-one to blame here: there _is_ tooling to help, and immense > work has been put towards making this manageable! I'm merely saying it's not > a matter of running "debian/rules get-new-upstream" at all. The tooling is mostly great. *I* do think that the script which imports upstream's changelog should go though as it makes 'you' think you're quickly done. But if you want to do things right, you should still go through all the commits to actually update the versions and add the new links and new files. If you don't, and the temptations is IMO rather high, then you'd create another monumental task like the one I went through. And that REALLY did not make me happy or considered fun. At all. As I see
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#1069870: linux-image-6.7.7-686-pae: please enable i915 mtl_* firmware
Control: reassign -1 src:firmware-nonfree 20230625-2 On Friday, 26 April 2024 07:36:16 CEST Martin-Éric Racine wrote: > Package: src:linux > Version: 6.7.7-1 > Severity: normal > > W: Possible missing firmware /lib/firmware/i915/mtl_gsc_1.bin for module > i915 W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for > module i915 W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin > for module i915 Should be fixed when firmware-nonfree version 20230919 is released signature.asc Description: This is a digitally signed message part.
Bug#1068365: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al
Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867 https://lore.kernel.org/all/20240328-mips_save_syscall-v1-1-9e1d62d69...@flygoat.com/ On Thursday, 25 April 2024 22:10:12 CEST Chris Hofstaedtler wrote: > reassign 1068365 src:linux > affects 1068365 src:util-linux > thanks It's already marked as 'upstream' and 'fixed-upstream', so the tags are fine. Upstream commit 4370b673ccf240bf7587b0cb8e6726a5ccaf1f17 titled "MIPS: scall: Save thread_info.syscall unconditionally on entry" That commit is part of 6.9-rc4 and autoselected for 6.8, 6.1 and 5.10 on 2024-04-22 by Sasha Levin, but I haven't seen them in their respective Stable queues yet? 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#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#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 on
* In
Re: Questions about 6.6 future kernel in Debian
On Monday, 15 April 2024 10:41:55 CEST Eric Valette wrote: > Why is there no 6.6 up-to-date kernel pushed in testing as well? Do you > plan to wait until 6.6 enter stable? When? Nothing gets 'pushed' to Testing. Packages *transition* to Testing when several conditions are met. https://tracker.debian.org/pkg/linux shows several reasons why 6.7.9-2 hasn't transitioned to Testing yet. The 6.6 kernel is not relevant for Debian (Testing). Generally, upstream LTS kernels are relevant for Debian around the freeze for the next Stable version. The current Debian Stable (Bookworm) will stay on 6.1. 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#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#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#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages
Please always reply to the bug report (I'll see it then too)! On woensdag 3 april 2024 22:01:20 CEST you wrote: > Thanks, I am working on that, but it's not trivial > > (1) About firmware > > These are provided by debian and cause the problem > -rw-r--r-- 1 root root 1299660 2023-05-01 21:30 > iwlwifi-QuZ-a0-hr-b0-59.ucode -rw-r--r-- 1 root root 1370356 2023-05-01 > 21:30 iwlwifi-QuZ-a0-hr-b0-72.ucode > > I grabbed new fw from a TI git repo, but the debian kernel does not load any > of them. Is fw signed? Do I need to sign it with my MOK? Use the upstream repo to get the files. The files aren't signed. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ The `dmesg` command will tell you which firmware files it's trying to load. Then DL that(/those) file(s) from the repo and put them in /lib/firmware/ Then on next boot the kernel will find them. > -rw-r--r-- 1 root root 1369976 2024-04-03 21:24 > iwlwifi-QuZ-a0-hr-b0-73.ucode -rw-r--r-- 1 root root 1371668 2024-04-03 > 21:24 iwlwifi-QuZ-a0-hr-b0-74.ucode -rw-r--r-- 1 root root 1404184 > 2024-04-03 21:24 iwlwifi-QuZ-a0-hr-b0-77.ucode > > (2) About kernel experiments, unfortunately it is a production server with > samba-ad and ad replication. It uses btrfs and snapshots work great, but it > needs some work (disable email services, make snapshots, stop all clients, > testing, restore snapshots, reenable email, restart clients). > > (3) Instead I will try first to use debian testing on a different NUC, but > this will take some time. > > 2. April 2024 20:28, "Diederik de Haas" schrieb: > > On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote: > >> Package: src:linux > >> Version: 6.1.76-1 > >> Severity: important > >> Tags: upstream > > > > I am/was inclined to remove that tag, but the problem is likely caused by > > firmware which is too old for the 'backported' patches that upstream > > applied.> > >> The driver fills the eventlog with millions !!! of messages, see below. > >> It otherwise works. The problem can be reproduced on different NUC > >> systems. > > > > If you downgrade the kernel version, does the issue then go away? > > > >> ** Kernel log: > >> [30911.569896] BTRFS info (device sda4): disk space caching is enabled > >> [30974.905443] net_ratelimit: 67420 callbacks suppressed > >> [30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 > >> [30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 > >> [30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 > > > > https://unix.stackexchange.com/a/721474 looks related and the solution is > > to upgrade the firmware to a newer version. > > That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from > > Testing should be safe. Not sure if that version is new enough though. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi > > t > > is the upstream repo and you could 'grab' the firmware files which `dmesg` > > reports it can't find. > > > >> -- System Information: > >> Debian Release: 12.5 > >> APT prefers stable-security > >> APT policy: (500, 'stable-security'), (500, 'stable') > >> Architecture: amd64 (x86_64) > >> > >> Versions of packages linux-image-6.1.0-18-amd64 is related to: > >> ii firmware-amd-graphics 20230210-5 > >> pn firmware-atheros > >> pn firmware-bnx2 > >> pn firmware-bnx2x > >> pn firmware-brcm80211 > >> pn firmware-cavium > >> ii firmware-intel-sound 20230210-5 > >> pn firmware-intelwimax > >> pn firmware-ipw2x00 > >> pn firmware-ivtv > >> ii firmware-iwlwifi 20230210-5 > > > > My guess is that those 'backported' patches expect newer firmware then > > that. signature.asc Description: This is a digitally signed message part.
Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages
On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote: > Package: src:linux > Version: 6.1.76-1 > Severity: important > Tags: upstream I am/was inclined to remove that tag, but the problem is likely caused by firmware which is too old for the 'backported' patches that upstream applied. > The driver fills the eventlog with millions !!! of messages, see below. > It otherwise works. The problem can be reproduced on different NUC systems. If you downgrade the kernel version, does the issue then go away? > ** Kernel log: > [30911.569896] BTRFS info (device sda4): disk space caching is enabled > [30974.905443] net_ratelimit: 67420 callbacks suppressed > [30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 > [30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 > [30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707 https://unix.stackexchange.com/a/721474 looks related and the solution is to upgrade the firmware to a newer version. That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from Testing should be safe. Not sure if that version is new enough though. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ is the upstream repo and you could 'grab' the firmware files which `dmesg` reports it can't find. > -- System Information: > Debian Release: 12.5 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Versions of packages linux-image-6.1.0-18-amd64 is related to: > ii firmware-amd-graphics 20230210-5 > pn firmware-atheros > pn firmware-bnx2 > pn firmware-bnx2x > pn firmware-brcm80211 > pn firmware-cavium > ii firmware-intel-sound 20230210-5 > pn firmware-intelwimax > pn firmware-ipw2x00 > pn firmware-ivtv > ii firmware-iwlwifi 20230210-5 My guess is that those 'backported' patches expect newer firmware then that. signature.asc Description: This is a digitally signed message part.
Bug#1065611: Additional support for SolidRun HoneyComb
On Tuesday, 19 March 2024 11:52:29 CET Josua Mayer wrote: > May I ask if you are analyzing dts manually, or whether you are aware > of an automatic tool? Analyses is done by a MUCH improved scripts based upon what I came up with a while ago: https://salsa.debian.org/kernel-team/linux/-/merge_requests/906#note_442903 My script came forth as I was analysing dts[i] files manually by looking up the ``compatible = "xyz"`` ... and at some point I made a script to help with that. Even the much improved version doesn't find them all so I regularly end up filling in the things it didn't find, but usually it does find 80-90+%. HTH, Diederik dts2config Description: application/shellscript diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ ../dts2config arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts includes: arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts - ARCH_LAYERSCAPE - arch/arm64/Kconfig.platforms - ARCH_LAYERSCAPE (bool) - debian/config/arm64/config - CONFIG_ARCH_LAYERSCAPE=y - debian/config/arm64/config.cloud-arm64 - # CONFIG_ARCH_LAYERSCAPE is not set compatible: "solidrun,honeycomb" compatible: "solidrun,lx2160a-cex7" compatible: "fsl,lx2160a" dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi includes: arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi compatible: "gpio-keys" - source: drivers/input/keyboard/gpio_keys.c - KEYBOARD_GPIO - drivers/input/keyboard/Kconfig - KEYBOARD_GPIO (tristate) - debian/config/config - # CONFIG_KEYBOARD_GPIO is not set - debian/config/config.cloud - # CONFIG_KEYBOARD_GPIO is not set - debian/config/arm64/config - CONFIG_KEYBOARD_GPIO=m - INPUT_KEYBOARD - drivers/input/keyboard/Kconfig - INPUT_KEYBOARD (bool, default y) - debian/config/config - CONFIG_INPUT_KEYBOARD=y - INPUT - drivers/input/Kconfig - INPUT (tristate, default y) - debian/config/config - CONFIG_INPUT=y compatible: "sff,sfp" - source: drivers/net/phy/sfp.c - SFP - drivers/net/phy/Kconfig - SFP (tristate) - debian/config/config - CONFIG_SFP=m dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi includes: arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi compatible: "solidrun,lx2160a-cex7" compatible: "fsl,lx2160a" compatible: "regulator-fixed" - source: drivers/regulator/fixed.c - REGULATOR_FIXED_VOLTAGE - drivers/regulator/Kconfig - REGULATOR_FIXED_VOLTAGE (tristate) - debian/config/config - # CONFIG_REGULATOR_FIXED_VOLTAGE is not set - debian/config/arm64/config - CONFIG_REGULATOR_FIXED_VOLTAGE=m - REGULATOR - drivers/regulator/Kconfig - REGULATOR (bool) - debian/config/config - # CONFIG_REGULATOR is not set - debian/config/config.cloud - # CONFIG_REGULATOR is not set - debian/config/arm64/config - CONFIG_REGULATOR=y compatible: "nxp,pca9547" - source: drivers/i2c/muxes/i2c-mux-pca954x.c - I2C_MUX_PCA954x - drivers/i2c/muxes/Kconfig - I2C_MUX_PCA954x (tristate) - debian/config/config - # CONFIG_I2C_MUX_PCA954x is not set - debian/config/arm64/config - CONFIG_I2C_MUX_PCA954x=m compatible: "atmel,24c512" - source: drivers/misc/eeprom/at24.c - EEPROM_AT24 - drivers/misc/eeprom/Kconfig - EEPROM_AT24 (tristate) - debian/config/config - CONFIG_EEPROM_AT24=m compatible: "atmel,spd" - source: drivers/misc/eeprom/at24.c - EEPROM_AT24 - drivers/misc/eeprom/Kconfig - EEPROM_AT24 (tristate) - debian/config/config - CONFIG_EEPROM_AT24=m compatible: "atmel,24c02" - source: drivers/misc/eeprom/at24.c - EEPROM_AT24 - drivers/misc/eeprom/Kconfig - EEPROM_AT24 (tristate) - debian/config/config - CONFIG_EEPROM_AT24=m compatible: "ti,amc6821" - source: drivers/hwmon/amc6821.c - SENSORS_AMC6821 - drivers/hwmon/Kconfig - SENSORS_AMC6821 (tristate) - debian/config/config - CONFIG_SENSORS_AMC6821=m - I2C - drivers/i2c/Kconfig - I2C (tristate) - debian/config/arm64/config - CONFIG_I2C=y compatible: "lltc,ltc3882" - source: drivers/hwmon/pmbus/ltc2978.c - SENSORS_LTC2978 - drivers/hwmon/pmbus/Kconfig - SENSORS_LTC2978 (tristate) - PMBUS - drivers/hwmon/pmbus/Kconfig - PMBUS (tristate) - debian/config/config - # CONFIG_PMBUS is not set - HWMON - drivers/hwmon/Kconfig - HWMON (tristate, default y) - debian/config/config - CONFIG_HWMON=y
btrfs: Kernel warning when using/mount RAID 5/6
Hi,
Since https://bugs.debian.org/863290 (2017) the Debian kernel has had a
patch to warn about the use of RAID 5/6 with BTRFS.
That bug mentions "It looks like there's a consensus that such a warning
should live in the kernel rather than userland"
Via [1] and [2] it seems userland did get a warning. It is mentioned in
the kernel documentation (``Documentation/btrfs-man5.rst``) (and [3]
and [4]), but AFAICT users are still not warned by the kernel when
using RAID 5/6.
I stumbled upon this issue when I was (locally) rebasing the Debian kernel
patch for kernel 6.8. I attached my rebased version of the original patch.
(I may have done it completely wrong as I know very little about BTRFS.)
But more importantly, IMO such a warning shouldn't be in a downstream
kernel (Debian), but in the upstream kernel source?
Cheers,
Diederik
[1] https://lore.kernel.org/linux-btrfs/20161208153004.ga31...@angband.pl/
[2]
https://lore.kernel.org/linux-btrfs/bf9594ea55ce40af8054070427ad97daf78a.1598374255.git.jo...@toxicpanda.com/
[3]
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices
[4]
https://lore.kernel.org/linux-btrfs/dbf47c42-932c-9cf0-0e50-75f1d779d...@cryptearth.de/From: Adam Borowski
Date: Tue, 28 Mar 2017 16:55:05 +0200
Subject: btrfs: warn about RAID5/6 being experimental at mount time
Bug-Debian: https://bugs.debian.org/863290
Origin: https://bugs.debian.org/863290#5
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski
[bwh: Also add_taint() so this is flagged in bug reports]
[2023-01-10: still accurate according to btrfs-progs own manpage:
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=922797e15590b836e377d6dc47b828356cafc2a9]
[2024-03-17: still accurate; manpage is now in Documentation/btrfs-man5.rst
implementation went from disk-io.c to super.c]
---
fs/btrfs/super.c | 12
1 file changed, 12 insertions(+)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 101f786963d4..2c409bce1bf5 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -731,6 +731,18 @@ static void set_device_specific_options(struct btrfs_fs_info *fs_info)
!fs_info->fs_devices->rotating)
btrfs_set_opt(fs_info->mount_opt, SSD);
+ /*
+ * Warn about RAID5/6 being experimental at mount time
+ */
+ if ((fs_info->avail_data_alloc_bits |
+ fs_info->avail_metadata_alloc_bits |
+ fs_info->avail_system_alloc_bits) &
+ BTRFS_BLOCK_GROUP_RAID56_MASK) {
+ btrfs_alert(fs_info,
+ "btrfs RAID5/6 is EXPERIMENTAL and has known data-loss bugs");
+ add_taint(TAINT_AUX, LOCKDEP_STILL_OK);
+ }
+
/*
* For devices supporting discard turn on discard=async automatically,
* unless it's already set or disabled. This could be turned off by
signature.asc
Description: This is a digitally signed message part.
Bug#1065611: Additional support for SolidRun HoneyComb
Hi Josua, On Tuesday, 12 March 2024 16:28:06 CET Josua Mayer wrote: > I believe I found the answer: > EDAC_MPC85XX is for power-pc only, > EDAC_LAYERSCAPE is for arm (see drivers/edac/layerscape_edac.c). You're right. In the commit I referenced earlier (ea2eb9a8b6207ee4), I misinterpreted the commit message. That commit also created ``drivers/edac/fsl_ddr_edac.c`` which got the arch independent (or at least dual arch) parts. Its header has this: ``` * Support Power-based SoCs including MPC85xx, MPC86xx, MPC83xx and * ARM-based Layerscape SoCs including LS2xxx. Originally split * out from mpc85xx_edac EDAC driver. ``` > Am 12.03.24 um 16:13 schrieb Josua Mayer: > > > > Thank you for taking care of this! > > First the additional changes you found seem reasonable. Excellent, then I'll make a MR for them (except EDAC_MPC85XX): - drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and SENSORS_LTC2978 as modules - drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module - drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module - drivers/soc/fsl: Enable FSL_RCPM > > Regarding edac - I checked NXPs reference BSP for LX2160, > > and their linux fork has the same status, driver can not be enabled on > > arm64. > > However I also agree it should be enabled if it were possible. > > The driver appears to setup ecc bit error interrupts so that hey can be > > reported by Linux. > > ... > > I may have access to an lx2160a system with ecc memory within the coming > > week, so I could test (on vendor kernel based on 5.10 only) whether any > > problems show up. If not, perhaps a patch to the kernel is advisable. As EDAC_LAYERSCAPE got enabled in 5.5.17-1 via bug 948576 (with a patch from you), ECC support should already work with the Stable 6.1 kernel (or newer). > > Am 07.03.24 um 13:34 schrieb Diederik de Haas: > >> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote: > >> > >>> LX2160 SoC early silicon revisions have a pci-e generation 4 > >>> controller. > >>> It requires a different driver from newer gen-3 silicon. > >>> > >>> This affects the SolidRun Honeycomb Workstation which > >>> is otherwise fully supported in Debian. > >> > >> I cloned bug report #1061116 into #1065611 to discuss some additional > >> support for the SolidRun HoneyComb. > >> > >> I analyzed the HoneyComb dts file and the following included .dtsi > >> files: > >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi > >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi > >> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi If my MR gets merged, then there's truly full support in Debian :) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1065611: Additional support for SolidRun HoneyComb
Hi Josua, On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote: > LX2160 SoC early silicon revisions have a pci-e generation 4 controller. > It requires a different driver from newer gen-3 silicon. > > This affects the SolidRun Honeycomb Workstation which > is otherwise fully supported in Debian. I cloned bug report #1061116 into #1065611 to discuss some additional support for the SolidRun HoneyComb. I analyzed the HoneyComb dts file and the following included .dtsi files: - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi If I exclude the kernel modules from 1061116 and 1061117, then I still have the following list of additional modules to enable: - drivers/edac: Enable EDAC_MPC85XX - drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and SENSORS_LTC2978 as modules - drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module - drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module - drivers/soc/fsl: Enable FSL_RCPM If you agree that this is a good list I can make a MR to get them enabled. A MR for 1061116 and 1061117 has just been merged in our 'master' branch. But I ran into an issue when looking at the ``EDAC_MPC85XX`` stanza in``drivers/edac/Kconfig``: ``depends on FSL_SOC && EDAC=y`` But ``FSL_SOC`` is (only) defined in ``arch/powerpc/Kconfig``, which means ``EDAC_MPC85XX`` can not be enabled on ``arm64``. That module was found based on ``compatible = "fsl,qoriq-memory-controller"``, which sounds like something you would want to have. Upstream commit ea2eb9a8b6207ee4 has the following commit message: ``` EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx The mpc85xx-compatible DDR controllers are used on ARM-based SoCs too. Carve out the DDR part from the mpc85xx EDAC driver in preparation to support both architectures. ``` Which I interpret as all (?) the preparations for supporting both powerpc and ARM were made, but they forgot to update the strict dependency of ``EDAC_MPC85XX`` to powerpc to actually support both architectures? Can you shed some light on this? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1061116: linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon
Control: clone -1 -2 Control: retitle -2 Additional support for SolidRun HoneyComb On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote: > LX2160 SoC early silicon revisions have a pci-e generation 4 controller. > It requires a different driver from newer gen-3 silicon. > > This affects the SolidRun Honeycomb Workstation which > is otherwise fully supported in Debian. Cloning this bug into a new one to discuss some additional support for the SolidRun HoneyComb. signature.asc Description: This is a digitally signed message part.
Bug#1064579: new git url for non-free firmware
Control: tag -1 moreinfo On Saturday, 24 February 2024 14:16:53 CET Harald Dunkel wrote: > Package: firmware-iwlwifi > Version: 20230625-2 > > The source URL mentioned in the copyright file doesn't work anymore. Which URL do you mean? https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git works, although it redirects to https://git.kernel.org/pub/scm/linux/kernel/git/ firmware/linux-firmware.git signature.asc Description: This is a digitally signed message part.
Bug#1035880: radeon: radeon driver only partial support of pipelines
Control: reassign -1 src:linux 5.10.178-1 On Wednesday, 10 May 2023 15:41:44 CET Christian Kiss wrote: > Package: firmware-amd-graphics > Version: 20210315-3 > > kernel.log reports that radeon: 1 quad pipes, 2 z pipes initialized. > the gpu an rv530 has atleast double to 4 of these each. > > the rudimentary partial support of the hardware features includes oddity > clock at 85.5Mhz instead 500 / 1100ram > > while the bit width 128seems to becorrect > > additionally to this the realtime kernel scheduling seems to break the gpu/ > non optimised coordination cpu gpu scheduling of cpucycles This seems to be a kernel issue, reassigning accordingly. signature.asc Description: This is a digitally signed message part.
Bug#988335: RTL8125B Failure of key exchange and association
Control: tag -1 moreinfo On Mon, 10 May 2021 18:13:43 + static wrote: > Package: firmware-realtek > Version: 20210315-2 > > I am trying to install from scratch firmware-edu-bullseye-DI-rc1-amd64- > BD-1.iso (also tried on debian-bullseye-DI-rc1-amd64-DVD-1.iso but interface > is not detected), on "Configure Network" it detects my RTL8125B Adapter with > Wifi. Is this still an issue with a non-rcX version? Preferably test with Bookworm. signature.asc Description: This is a digitally signed message part.
Bug#949436: firmware-iwlwifi: Got an HT rate (flags:0x88/mcs:15) for a non data frame
Control: tag -1 moreinfo On 20 Jan 2020 22:32:26 +0100 Patrice Duroux wrote: > Package: firmware-iwlwifi > Version: 20190717-2 > > I am reporting this «exception» here without being sure this is the right > package or if it has been already reported (not easy to check). > > [ 48.335755] [ cut here ] > [ 48.335766] Got an HT rate (flags:0x88/mcs:15) for a non data frame > [ 48.335839] WARNING: CPU: 7 PID: 543 at > drivers/net/wireless/intel/iwlwifi/mvm/tx.c:333 > ... > [ 48.336015] CPU: 7 PID: 543 Comm: irq/37-iwlwifi Tainted: G OE > 5.4.0-3-amd64 #1 Debian 5.4.13-1 > [ 48.336018] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 > Ver. 01.25 08/29/2019 > [ 48.336039] RIP: 0010:iwl_mvm_get_tx_rate.isra.0+0xc0/0xd0 [iwlmvm] > ... > [ 48.336079] Call Trace: > [ 48.336105] iwl_mvm_set_tx_cmd_rate+0x66/0xc0 [iwlmvm] > [ 48.336125] iwl_mvm_set_tx_params+0x337/0x4f0 [iwlmvm] > ... > [ 48.336862] ---[ end trace c6ab05d82de48c15 ]--- While firmware may be relevant, a kernel stack trace indicates it's more likely to be a kernel problem. Can you reproduce this issue with more recent firmware and kernel? signature.asc Description: This is a digitally signed message part.
Bug#949161: firmware-ti-connectivity: please include TIInit_10.6.15.bts
On Fri, 17 Jan 2020 17:24:14 +0200 Sicelo wrote: > Package: firmware-ti-connectivity > Version: 20190717-2 > > Please include TIInit_10.6.15.bts [1], which is needed for bluetooth on > the Motorola Droid 4 and similar boards. Similar files are already part > of the debian package, and the licence file [2] seems to allow > redistribution. > > [1] https://github.com/TI-ECS/bt-firmware/blob/master/TIInit_10.6.15.bts > [2] https://github.com/TI-ECS/bt-firmware/blob/master/LICENCE Please file an issue in that repo for them to submit that file (and possibly the other .bts files too) to the linux-firmware upstream repo here: https://gitlab.com/kernel-firmware/linux-firmware Once that is done, it can be included in a future package update. signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Control: retitle -1 firmware-iwlwifi: Please update to version 20230804 On Sunday, 11 February 2024 18:56:23 CET Diederik de Haas wrote: > It could/might be there would be some improvement somewhere with newer > firmware, but as long as things keep working that is fine. > Consequently, I've reassigned/renamed the bug to a request for a new > upstream version (the one which has the -83 firmware file(s)). Those are actually added in 20230804, so update title accordingly. signature.asc Description: This is a digitally signed message part.
Bug#1062817: firmware-amd-graphics: Invalid UVD handle causes the graphics driver to crash
Control: tag -1 moreinfo On Saturday, 3 February 2024 17:33:32 CET Aly Ghobashy wrote: > Package: firmware-amd-graphics > Version: 20230210-5 > >* What led up to the situation? > opening a video file with VLC >* What exactly did you do > video file to open normally. >* What was the outcome of this action? > system crash, here are the journald logs: > Feb 03 18:14:50 bastion kernel: [drm:radeon_uvd_cs_parse [radeon]] > *ERROR* Invalid UVD handle 0xc1da0033! > Feb 03 18:14:50 bastion kernel: [drm:radeon_cs_ioctl [radeon]] > *ERROR* Invalid command stream ! > Feb 03 18:15:01 bastion kernel: radeon :01:00.0: ring 5 stalled > for more than 10500msec > Feb 03 18:15:01 bastion kernel: radeon :01:00.0: failed to get a > new IB (-35) > > -- System Information: > Debian Release: 12.4 > > Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE What's the reason this bug is filed against firmware-amd-graphics? A crash in the graphics driver seems more like a kernel issue? signature.asc Description: This is a digitally signed message part.
Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919
On maandag 22 januari 2024 15:42:48 CET you wrote: > I'm currently working on an update for upstream version 20230919, based > upon MR86 (Release 20230804) [1], which itself is based upon MR85 > (Update to 20230625) [2] and I'm running into some major issues: > > 1) Salsa's CI now always fails as the (archive) size is now too big for >it to handle it. Likely due to some additions to Files-Excluded in MR86 (20230804), it now does pass. Pretty sure we'll still hit that limit soon (TM) though. I did extend d/README.source in that MR with instructions to build and run lintian so everyone can do it locally. signature.asc Description: This is a digitally signed message part.
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
On Tuesday, 20 February 2024 09:22:06 CET Ben Mesman | Spark Narrowcasting wrote: > mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be > detected by BIOS > ... > Link: > https://lore.kernel.org/r/20240203102908.4683-1-fredaibayhubt...@126.com > > I'm still waiting for the patch to land in the stable kernel series (both > 6.1 and 6.6) That patched is queued in both 6.1 and 6.6 (and 6.7) so should normally land in the next upstream point release. signature.asc Description: This is a digitally signed message part.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On Tuesday, 13 February 2024 17:59:55 CET Mario Limonciello wrote: > > I think it's important to facilitate people having f.e. the following > > combos: > > - Intel CPU with AMD GPU > > - AMD CPU with Nvidia GPU > > - AMD CPU with AMD GPU (discrete or integrated) > > > > Preferably without having to install 100s of MB of firmware files of which > > 95% the user doesn't actually need. (See f.e. > > https://bugs.debian.org/1057786) > You don't currently split up the AMD APU integrated graphics and dGPU, > and I doing this is a bad idea as it's possible to reuse IP versions on > APU and dGPU hardware. If they are the same then they would use the > same firmware binaries. I have/had no plan to make a split for iGPU and dGPU, both would need to install the `firmware-amd-graphics` package. For the 3 scenario's above: - `intel-microcode` + `firmware-amd-graphics` - `amd64-microcode` + `firmware-nvidia`* - `amd64-microcode` + `firmware-amd-graphics` AMD APU's would fall into scenario 3. *) If my MR gets accepted, otherwise `firmware-misc-nonfree` > For reference on the size: > > $ du -sh amdgpu > 60M amdgpu > > $ du -sh du -sh amdtee/ > 20K amdtee/ > > $ du -sh amd-ucode/ > 112Kamd-ucode/ > > $ du -sh amd > 268Kamd What I want(ed) to prevent is that for scenario 2, the user should NOT have to install the `firmware-amd-graphics` package to get the amdtee firmware. > These aren't yet upstream, but so you can see the size: > > $ du -sh amdnpu/ > 3.3Mamdnpu/ And that seems like a future candidate too for amd64-microcode package. > I think your suggestion to combine all the non graphics related binaries > to a single package and all graphics related binaries to another is fine. Excellent, then I think we're all in agreement :) I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and Henrique can add those files to the amd64-microcode package. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On Monday, 12 February 2024 21:25:35 CET Mario Limonciello wrote: > > My logic was that this is about AMD TEE (Trusted Execution Environment), > > which I *assumed* is part of/tied to the CPU. This thought is based on > > that on ARM platforms, you also have a TEE and that is part of the CPU > > (and implemented in TF-A IIUC). I can be wrong here ofc. > > To me using the nomenclature of "CPU" is confusing. We should be > calling these SoCs. While SoC may be technically more accurate, I'm not in favor of using it in this context as it doesn't give any hint on what it does. I'd use CPU for general processing and GPU for graphics processing. > Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly > called PSP) and various others. I would describe an APU as a CPU with integrated GPU. My guess is most people/end-users aren't even aware of the ASP/PSP. I would classify the various ASICs (like IPU/NPU) as part of the CPU, but it is (by definition?) an arbitrary qualification/separation. > > There's no need to pick an existing binary package. I could add it to amd- > > graphics, but I consider that a poor choice. I could create a new binary > > package `amdtee` in firmware-nonfree (source package). > > That would be fine afaic. > > > > So I have no strong feelings about it, just trying to find the best place > > for the `amdtee` dir. > > My general feeling is that having separated binary packages for all the > AMD 'things' makes things "generally" confusing for end users and is > needless extra work for you to maintain. I mostly agree. It isn't (much) extra work for 'me' though. > 'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries > will go to linux-firmware.git and then where do those go? My (current) thinking is to have 2 categories: - AMD CPU related - AMD GPU/graphics related > Current products only put the IPU/NPU in APU chips, but who is to stay; > those might end up in SoCs without graphics in the future too. I think it's important to facilitate people having f.e. the following combos: - Intel CPU with AMD GPU - AMD CPU with Nvidia GPU - AMD CPU with AMD GPU (discrete or integrated) Preferably without having to install 100s of MB of firmware files of which 95% the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786) > How would you feel about making a master "amd" metapackage that pulls > them all? You can split as you see fit then and people who want the > 'easy button' can just install that package. I'm not much of a fan of such metapackages. I think it mostly indicates that the purpose of the various packages isn't clear, so let's install all of them. Clarifying the purpose better is a better solution imo. I'm aware others feel different: https://bugs.debian.org/522415 I prefer to keep that discussion out of this bug though, feel free to open a new bug for that if you do want it. signature.asc Description: This is a digitally signed message part.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote: > On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote: > > This is about "AMD Platform Management Framework TA", which seems to be > > about AMD CPU features. The first (and only) commit message has this: > > > > ``` > > amd_pmf: Add initial PMF TA for Smart PC Solution Builder > > > > AMD PMF driver loads the PMF TA (Trusted Application) into the AMD > > ASP's (AMD Security Processor) TEE (Trusted Execution Environment). > > ``` > > > > Firmware for AMD graphics belongs in firmware-nonfree, but the > > ``amdtee`` directory seems to fit better in amd64-microcode? > > Could be, yes. It isn't needed at early boot at all, but then neither is > AMD-SEV, and it is in amd64-microcode. > > So yeah, I could carry it on amd64-microcode, but we need to coordinate it > re. linux-firmware packages, since it has to move from one package to the > other. Unless it has never made it to any linux-firmware packages ? It has never made it into any firmware-nonfree package, so nothing needs to move. I'm working on a 20230804 update where I have added AMD-SEV to the Files- Excluded section. I then came across the 'amdtee' dir and was wondering what (best) to do with that, hence this bug. > And I need to know what I should do about it on the backport branches and > security update branches. I don't know/understand what you mean by this. Can you clarify? On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello wrote: > The firmware is only used on mobile APUs (which contain graphics). So > if needing to pick an existing binary package instead of a new one I can > see a stronger argument to bundle it with the graphics package. My logic was that this is about AMD TEE (Trusted Execution Environment), which I *assumed* is part of/tied to the CPU. This thought is based on that on ARM platforms, you also have a TEE and that is part of the CPU (and implemented in TF-A IIUC). I can be wrong here ofc. That it *currently* is only used on mobile APUs is something I consider to be an implementation detail. I can be wrong on this too. There's no need to pick an existing binary package. I could add it to amd- graphics, but I consider that a poor choice. I could create a new binary package `amdtee` in firmware-nonfree (source package). That would be fine afaic. But as I assumed AMD TEE is a CPU feature, adding it to a package which already deals with AMD CPU features seems the most logical. And if AMD TEE becomes available in the future in 'normal' desktop CPUs (without graphics) it would be 'weird' to have to install firmware-amd-graphics to make use of it (and then a move probably would be needed). So I have no strong feelings about it, just trying to find the best place for the `amdtee` dir. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable)
Control: forwarded -1 https://lore.kernel.org/netdev/3179622f-7090-4a57-98ba-9042809a0...@its-lehmann.de/ On Monday, 12 February 2024 12:56:45 CET Arno Lehmann wrote: > Reported upstream, see > > https://lore.kernel.org/netdev/3179622f-7090-4a57-98ba-9042809a0d2a@its-lehm > ann.de/T/#u Excellent, thanks signature.asc Description: This is a digitally signed message part.
Bug#1063660: the amdgpu module is missing from the kernel
Control: reassign -1 firmware-amd-graphics 20230210-5 Control: retitle -1 firmware-amd-graphics: Please backport newer firmware to Bookworm Control: tag -1 -moreinfo Control: severity -1 wishlist On Sunday, 11 February 2024 20:11:19 CET saber716rus wrote: > В Вс, 11/02/2024 в 19:48 +0100, Diederik de Haas пишет: > > Control: tag -1 moreinfo > > > > On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote: > > > Package: linux-image-amd64 > > > Version: 6.1.76-1 > > > > > > > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64 > > > > W: Possible missing firmware > > > > /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu > > > > ... > > > > W: Possible missing firmware > > > > /lib/firmware/amdgpu/psp_13_0_11_ta.bin > > > > for module amdgpu > > > > What I see in these messages that it's requesting new(er) *firmware* > > files, but the bug title implicates that there is a *kernel* module missing. > > The latter would be very surprising and would make your/any graphics > > output on AMD GPUs not work. > > Can you confirm it's actually a firmware issue? > > there are no errors in dmesg. and I don't see any graphical artifacts, > but the error about the lack of modules is very alarming to me. Apparently some new (AMD) kernel files have been backported to the 6.1 branch, which causes it to request firmware files which didn't exist when 6.1 was released. I've reassigned and changed this bug report into a request for a backport of newer firmware files for Bookworm, although I'm not so sure that's a good idea. While it may look alarming, it's highly likely harmless. Just noisy. signature.asc Description: This is a digitally signed message part.
Bug#1063660: the amdgpu module is missing from the kernel
Control: tag -1 moreinfo On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote: > Package: linux-image-amd64 > Version: 6.1.76-1 > > > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64 > > W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for > > module amdgpu > > W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for > > module amdgpu > > W: Possible missing firmware > > /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu > > W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for > > module amdgpu > > W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_ta.bin > > for module amdgpu What I see in these messages that it's requesting new(er) *firmware* files, but the bug title implicates that there is a *kernel* module missing. The latter would be very surprising and would make your/any graphics output on AMD GPUs not work. Can you confirm it's actually a firmware issue? signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Control: reassign -1 firmware-iwlwifi 20230625-2 Control: retitle -1 firmware-iwlwifi: Please update to version 20230919 On Sunday, 11 February 2024 16:34:16 CET Miguel Angel Rojas wrote: > > While 'annoying', this is expected behavior. It tries to load the newest > > (-83) > Yes, this is the expected behavior from our Linux kernel. However, I agree > with you and these messages are very annoying and should be removed. IMO it's working as expected and as it should do. It's aware of newer firmware so it tries to load that first, but then 'fall back' to older versions in case it can't find the newer firmware files. > > It could be it wouldn't be shown if it had already found one of the > > earlier logged firmware files. > Interesting theory! When the new version of the firmware packages is > uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears Great > > Bit confused about that version number, but looks like success. > Why are you confused with the numbers? I thought it might have been some custom file, but that's an error on my part. Apparently it detects the 'internal' firmware version and reports that. > And yes, wifi is working fine although I haven't properly done any > performance test yet. It could/might be there would be some improvement somewhere with newer firmware, but as long as things keep working that is fine. Consequently, I've reassigned/renamed the bug to a request for a new upstream version (the one which has the -83 firmware file(s)). Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Miguel, On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote: > I forgot to include you the dmesg as promised: > > [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002) > [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id > 0x80401 wfpm id 0x8030 > [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, > rfid=0x10a100 > [2.237845] iwlwifi :00:14.3: firmware: failed to load > iwlwifi-so-a0-hr-b0-83.ucode (-2) > [2.237867] iwlwifi :00:14.3: firmware: failed to load > iwlwifi-so-a0-hr-b0-83.ucode (-2) > ... more firmware load failures > [2.238098] iwlwifi :00:14.3: Direct firmware load for > iwlwifi-so-a0-hr-b0-73.ucode failed with error -2 > [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware > iwlwifi-so-a0-hr-b0-72.ucode While 'annoying', this is expected behavior. It tries to load the newest (-83) and when it can't find that, it tries an older one and ends up with '-72'. > [2.247819] iwlwifi :00:14.3: api flags index 2 larger than > supported by driver > [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: > 0.0.2.36 > [2.248049] iwlwifi :00:14.3: firmware: failed to load > iwl-debug-yoyo.bin (-2) <- > [2.248067] iwlwifi :00:14.3: firmware: failed to load > iwl-debug-yoyo.bin (-2) <- This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT available in the upstream linux-firmware repo. It could be it wouldn't be shown if it had already found one of the earlier logged firmware files. I might look into this particular issue at some later date. > [2.248078] iwlwifi :00:14.3: loaded firmware version > 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm Bit confused about that version number, but looks like success ... > [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 > 160MHz, REV=0x430 > [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 > [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee > [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 > [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP, > with index: 0 > [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 ... and from this it seems the device appears to be working properly? If that's indeed the case then this bug would essentially be a request for a new upstream version. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
On Sunday, 11 February 2024 11:11:53 CET Miguel Angel Rojas wrote: > My bad. Let me explain again. Taking into account the firmware errors: > >- Realtek messages are fixed now. There are no actions to be done here. Good. >- iwlwifi: If you are still working on a new version containing the -83 >file, that should fix some warning messages but not all of them. There is > another message (*firmware: failed to load iwl-debug-yoyo.bin (-2)*) that I > think is related to bug #966218. This bug has been there for a while, so I > don't know what's happening here. Nobody explains what's going on or why > this file is not included in the firmware package. While it's unfortunate/annoying that those warnings (which sometimes get 'promoted' to errors) exist and should go away with a new upstream version, that doesn't (automatically) mean that there is a 'real' bug. So, is the device using iwlwifi working or not? My request for a full dmesg was precisely to determine whether there is an actual bug or whether this bug is merely a request for a new upstream version. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Control: tag -1 moreinfo Hi, On Friday, 9 February 2024 19:35:01 CET Miguel A. Rojas wrote: > A few days ago, I went to > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > and update the missing loaded modules. > > Indeed, I noticed that I have another messages related to the iwlwifi > module: "kernel: iwlwifi :00:14.3: firmware: failed to load > iwlwifi-so-a0-hr-b0-83.ucode (-2)". The reason I asked for more dmesg lines is that it likely then tried (f.e.) -81, then -79 and then probably succeeded at some point. The Debian kernel (unfortunately imo) 'promoted' warning/info messages to errors, which make it appear more severe then they actually are. > I think the the root cause is that the current Debian packages firmware > packages are 6 months old and they need to be updated accordingly. New > Debian Linux kernel expects a specific version of the firmware or the > name of the firmware has changed. I do think that the old package versions are a problem, so I have been working on Merge Requests for updating them. Version 20230804 would make the -83 file available. But the device using and older version should still work. If it doesn't work with an older version, but it does work with a newer, that's important info. But I'm still a bit confused as this bug is about *realtek* firmware, not iwlwifi? Can you answer the question I asked previously? signature.asc Description: This is a digitally signed message part.
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable)
On Friday, 9 February 2024 13:39:23 CET Arno Lehmann wrote: > [Fr Feb 9 13:25:08 2024] CPU: 20 PID: 84300 Comm: kworker/20:0 Not > tainted 6.5.0-0.deb12.4-amd64 #1 Debian 6.5.10-1~bpo12+1 > [Fr Feb 9 13:25:08 2024] Hardware name: ASUS System Product Name/ROG > STRIX X670E-A GAMING WIFI, BIOS 1904 01/29/2024 I see you have (now) an up-to-date BIOS. Good. > [Fr Feb 9 13:25:08 2024] Workqueue: events igc_watchdog_task [igc] > [Fr Feb 9 13:25:08 2024] RIP: 0010:igc_rd32+0x8d/0xa0 [igc] > [Fr Feb 9 13:25:08 2024] Code: 48 c7 c6 10 36 3a c0 e8 81 aa dd e6 48 > 8b bb 28 ff ff ff e8 05 12 b4 e6 84 c0 74 bc 89 ee 48 c7 c7 38 36 3a c0 > e8 c3 2e 53 e6 <0f> 0b eb aa b8 ff ff ff ff e9 15 0f 04 e7 0f 1f 44 00 > 00 90 90 90 > [Fr Feb 9 13:25:08 2024] RSP: 0018:b034cc61bdd8 EFLAGS: 00010282 > [Fr Feb 9 13:25:08 2024] RAX: RBX: 97078f882cb8 > RCX: 0027 > [Fr Feb 9 13:25:08 2024] RDX: 97169e7213c8 RSI: 0001 > RDI: 97169e7213c0 > [Fr Feb 9 13:25:08 2024] RBP: c030 R08: > R09: b034cc61bc68 > [Fr Feb 9 13:25:08 2024] R10: 0003 R11: 9716dde3ac28 > R12: 97078f882000 > [Fr Feb 9 13:25:08 2024] R13: R14: 970784592d40 > R15: c030 > [Fr Feb 9 13:25:08 2024] FS: () > GS:97169e70() knlGS: > [Fr Feb 9 13:25:08 2024] CS: 0010 DS: ES: CR0: 80050033 > [Fr Feb 9 13:25:08 2024] CR2: 7f5271155f80 CR3: 000434bc6000 > CR4: 00750ee0 > [Fr Feb 9 13:25:08 2024] PKRU: 5554 > [Fr Feb 9 13:25:08 2024] Call Trace: > [Fr Feb 9 13:25:08 2024] > [Fr Feb 9 13:25:08 2024] ? igc_rd32+0x8d/0xa0 [igc] > [Fr Feb 9 13:25:08 2024] ? __warn+0x81/0x130 > [Fr Feb 9 13:25:08 2024] ? igc_rd32+0x8d/0xa0 [igc] > [Fr Feb 9 13:25:08 2024] ? report_bug+0x171/0x1a0 > [Fr Feb 9 13:25:08 2024] ? srso_alias_return_thunk+0x5/0x7f > [Fr Feb 9 13:25:08 2024] ? prb_read_valid+0x1b/0x30 > [Fr Feb 9 13:25:08 2024] ? handle_bug+0x41/0x70 > [Fr Feb 9 13:25:08 2024] ? exc_invalid_op+0x17/0x70 > [Fr Feb 9 13:25:08 2024] ? asm_exc_invalid_op+0x1a/0x20 > [Fr Feb 9 13:25:08 2024] ? igc_rd32+0x8d/0xa0 [igc] > [Fr Feb 9 13:25:08 2024] ? igc_rd32+0x8d/0xa0 [igc] > [Fr Feb 9 13:25:08 2024] igc_update_stats+0x8a/0x6d0 [igc] > [Fr Feb 9 13:25:08 2024] igc_watchdog_task+0x9d/0x4a0 [igc] > [Fr Feb 9 13:25:08 2024] process_one_work+0x1df/0x3e0 > [Fr Feb 9 13:25:08 2024] worker_thread+0x51/0x390 > [Fr Feb 9 13:25:08 2024] ? __pfx_worker_thread+0x10/0x10 > [Fr Feb 9 13:25:08 2024] kthread+0xe5/0x120 > [Fr Feb 9 13:25:08 2024] ? __pfx_kthread+0x10/0x10 > [Fr Feb 9 13:25:08 2024] ret_from_fork+0x31/0x50 > [Fr Feb 9 13:25:08 2024] ? __pfx_kthread+0x10/0x10 > [Fr Feb 9 13:25:08 2024] ret_from_fork_asm+0x1b/0x30 > [Fr Feb 9 13:25:08 2024] > [Fr Feb 9 13:25:08 2024] ---[ end trace ]--- > > Can anybody suggest what information I can provide to tackle this? I think it's best to take this issue upstream. $ scripts/get_maintainer.pl drivers/net/ethernet/intel/igc/ returned this: Jesse Brandeburg (supporter:INTEL ETHERNET DRIVERS) Tony Nguyen (supporter:INTEL ETHERNET DRIVERS) "David S. Miller" (maintainer:NETWORKING DRIVERS) Eric Dumazet (maintainer:NETWORKING DRIVERS) Jakub Kicinski (maintainer:NETWORKING DRIVERS) Paolo Abeni (maintainer:NETWORKING DRIVERS) intel-wired-...@lists.osuosl.org (moderated list:INTEL ETHERNET DRIVERS) net...@vger.kernel.org (open list:NETWORKING DRIVERS) linux-ker...@vger.kernel.org (open list) To do that, I'd certainly send an email to net...@vger.kernel.org as that is the Mailing List. You can choose to add others from that list too. In that email I recommend to include the following info: - Description of the problems: I'd focus on the NIC stuff, but do also mention the issue you encountered with NVMe. - A list or table with the kernel versions you detected the problem with. Try to find/use the upstream version as the Debian version (6.1.0-17) is often not (that) useful for the upstream maintainers. `uname -a` will show both. Via https://tracker.debian.org/pkg/linux I found that 6.1.0-17 is upstream version 6.1.69 as the 6.1.69-1 upload had "Bump ABI to 17" at the end of the changelog. IIUC this is not a regression; mention that too. - A/The stacktrace(s) you got. This usually allows the upstream maintainers to pinpoint where the problem lies. HTH signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
Control: tag -1 moreinfo On Monday, 5 February 2024 15:47:08 CET Nate wrote: > Would be possible to compile it as a module in the kernel ? > There may be technical limitations that I am not aware of. The kernel module depends on AMDTEE (Trusted Execution Environment) and I'm not sure if you'd need amdtee firmware for that. In https://bugs.debian.org/1062678 I requested that, but that is about AMD PMF TA (Trusted Application) and that *could* be something else. signature.asc Description: This is a digitally signed message part.
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
On Friday, 2 February 2024 20:10:53 CET Miguel Angel wrote: > Package: firmware-realtek > Version: 20230625-2 > Severity: important > X-Debbugs-Cc: mianro...@gmail.com > > At system boot, the following message is shown: > "Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2". > > It seesm that the firmware is not properly loaded by kernel at boot. Can you provide the dmesg output which would show that? Doesn't have to be the full dmesg output, but don't 'grep' for it either as that will likely filter out the surrounding lines which are often relevant. https://packages.debian.org/sid/all/firmware-realtek/filelist does show ``rtl_nic/rtl8125b-2.fw``, so I'm a bit surprised. signature.asc Description: This is a digitally signed message part.
Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
Package: amd64-microcode Version: 3.20231019.1 Severity: normal X-Debbugs-Cc: debian-kernel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While working on a firmware-nonfree update I came across a commit where a new file was added in a new directory: ``amdtee``: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdtee This is about "AMD Platform Management Framework TA", which seems to be about AMD CPU features. The first (and only) commit message has this: ``` amd_pmf: Add initial PMF TA for Smart PC Solution Builder AMD PMF driver loads the PMF TA (Trusted Application) into the AMD ASP's (AMD Security Processor) TEE (Trusted Execution Environment). ``` Firmware for AMD graphics belongs in firmware-nonfree, but the ``amdtee`` directory seems to fit better in amd64-microcode? - -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-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 amd64-microcode depends on no packages. Versions of packages amd64-microcode recommends: ii initramfs-tools 0.142 amd64-microcode suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZb0dXwAKCRDXblvOeH7b bhbwAQDt0VW65WhlRttuxWFueuSVHvzo/3zN4deCEESRxvVFrAEA+WrBIu/CWSX+ tMw/Lg8VsnRIstVaqZbTMeAyjgv8fQA= =3uCZ -END PGP SIGNATURE-
Bug#1061688: marked as done (rtl8821: WARNING: CPU: 37 PID: 1366 at drivers/iommu/dma-iommu.c:1091 iommu_dma_unmap_page+0x7d/0x90)
On Thursday, 1 February 2024 14:33:05 CET Debian Bug Tracking System wrote: > Source: rust-url > Architecture: source > Version: 2.5.0-1 > Maintainer: Debian Rust Maintainers > Changed-By: Peter Michael > Green > Closes: 1061688 > Changes: > rust-url (2.5.0-1) unstable; urgency=medium > . >* Team upload. >* Package url 2.5.0 from crates.io using debcargo 2.6.1 (Closes: > #1061688) * Reduce idna dependency to 0.4. I see there's bug 1061668 for rust-url, so I guess you closed the wrong bug? signature.asc Description: This is a digitally signed message part.
Bug#966218: Warning about the work-around listed here
On Thursday, 1 February 2024 05:51:53 CET Francois Marier wrote: > My solution is simple: ignore the "failed to load iwl-debug-yoyo.bin (-2)" > for now. Thanks for the warning and your solution seems sound to me. signature.asc Description: This is a digitally signed message part.
Bug#1061680: linux-image-armmp: Add modules to better support Tegra Chromebooks
Control: tag -1 -moreinfo On Sunday, 28 January 2024 17:34:05 CET Diederik de Haas wrote: > It seems to use a NVIDIA Tegra K1 CD570M-A1 which seems to be ARM > Cortex-A15. So should these options (only) be enabled on armhf? Got a response on IRC: yes signature.asc Description: This is a digitally signed message part.
Bug#1061680: linux-image-armmp: Add modules to better support Tegra Chromebooks
Control: tag -1 moreinfo On Sunday, 28 January 2024 17:23:15 CET Alex wrote: > Various Tegra K1 Chromebooks exist such as the Acer CB5-311, which are > capable of booting Debian with an unmodified kernel. However there are a > few missing modules which are needed for full functionality. > > On the aforementioned Acer Chromebook the following kernel configs enable > useful modules: > - CONFIG_MWIFIEX > - CONFIG_MWIFIEX_SDIO > - CONFIG_CHARGER_BQ24735 > - CONFIG_SENSORS_LM90 > - CONFIG_CEC_TEGRA > ... > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: armhf (armv7l) Hi Alex ;-) It seems to use a NVIDIA Tegra K1 CD570M-A1 which seems to be ARM Cortex-A15. So should these options (only) be enabled on armhf? signature.asc Description: This is a digitally signed message part.
Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu
Patrice,
On Sunday, 28 January 2024 11:44:59 CET Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 27.01.24 14:14, Salvatore Bonaccorso wrote:
> > In Debian (https://bugs.debian.org/1061449) we got the following
> > quotred report:
> >
> > On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
> >> Giving a try to 6.7, here is a message extracted from dmesg:
> >> [4.177226] [ cut here ]
> >> [4.177227] WARNING: CPU: 6 PID: 248 at
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
> >> construct_phy+0xb26/0xd60 [amdgpu]
> >
> > [...]
>
> Not my area of expertise, but looks a lot like a duplicate of
> https://gitlab.freedesktop.org/drm/amd/-/issues/3122#note_2252835
>
> Mario (now CCed) already prepared a patch for that issue that seems to work.
If you can build and test a kernel with the `test-patches` script like before
with the attached patch, but *without* the previous patch (which just reverted
commit b17ef04bf3a4346d66404454d6a646343ddc9749), that would be really useful.
When you've done that, do a Reply-All to Thorsten Leemhuis' message so that
everyone sees the results. Optionally also reply to the gitlab issue Thorsten
mentioned.
(It didn't seem useful to send these instructions to all the people/lists)diff --git a/drivers/gpu/drm/amd/display/dc/link/link_factory.c b/drivers/gpu/drm/amd/display/dc/link/link_factory.c
index 37d3027c32dc..cf45d33ce2b7 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_factory.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_factory.c
@@ -377,17 +377,21 @@ static uint8_t translate_dig_inst_to_pwrseq_inst(struct dc_link *link)
DC_LOGGER_INIT(dc_ctx->logger);
- switch (link->eng_id) {
- case ENGINE_ID_DIGA:
+ if (dc_ctx->dce_version >= DCN_VERSION_3_0) {
+ switch (link->eng_id) {
+ case ENGINE_ID_DIGA:
+ pwrseq_inst = 0;
+ break;
+ case ENGINE_ID_DIGB:
+ pwrseq_inst = 1;
+ break;
+ default:
+ DC_LOG_WARNING("Unsupported pwrseq engine id: %d!\n", link->eng_id);
+ ASSERT(false);
+ break;
+ }
+ } else {
pwrseq_inst = 0;
- break;
- case ENGINE_ID_DIGB:
- pwrseq_inst = 1;
- break;
- default:
- DC_LOG_WARNING("Unsupported pwrseq engine id: %d!\n", link->eng_id);
- ASSERT(false);
- break;
}
return pwrseq_inst;
signature.asc
Description: This is a digitally signed message part.
Bug#1061430: firmware-realtek: Realtek 10ec:8136 wrongly identified as Fast Ethernet instead of Gigabit
Control: tag -1 moreinfo On Wednesday, 24 January 2024 12:18:01 CET Răzvan Sandu wrote: > ackage: firmware-realtek > Version: 20230210-5 > Severity: normal > > I've noted that two Realtek-based Ethernet cards (hardware ID > [10ec:8136], chipset RTL8111C) in my system operate as Fast Ethernet, https://linux-hardware.org/?view=search=10ec=8136 indicates it is Fast Ethernet. https://duckduckgo.com/?q=10ec:8136 also indicates Fast Ethernet. What's the reason you filed it against firmware-realtek? Correctly identifying the hardware is the job of the kernel (which then can request firmware). > despite having Gigabit capability. > They were advertised as "PCI-E Network Adapter" with support for > Windows, Mac and GNU/Linux (10/100/1000 Mbps). Based on the hardware ID it looks like it does NOT support GbE. > In order to help, I've entered full hardware data for this ID at > https://h-node.org/ethernetcards/view/en/2358/Realtek-Semiconductor-Co---Ltd > --RTL810xE-PCI-Express-Fast-Ethernet-controller--rev-05- > Please include correct identification data for this RTL8111C Ethernet > controller, so it can use its full hardware capabilities. FWIW, you used hardware ID [10ec:0123] (not [10ec:8136]) That page includes information which should've been part of this bug report... "this no-name adapter uses the Realtek RTL8111C chipset" Why do you think that? signature.asc Description: This is a digitally signed message part.
Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu
Control: tag -1 =upstream On Wednesday, 24 January 2024 21:41:29 CET Patrice Duroux wrote: > Finally, no more complaints! > > $ uname -a > Linux kos-moceratops 6.7+unreleased-amd64 #1 SMP PREEMPT_DYNAMIC > Debian 6.7.1-1~exp1a~test (2024-01-24) x86_64 GNU/Linux Excellent, now we know commit b17ef04bf3a4346d66404454d6a646343ddc9749 introduced the regression. > Does this need further testing from my side? No, but it should be reported upstream so that an actual fix can be made. Unfortunately the commit doesn't link to a/the patch discussion (on f.e. lore.kernel.org), so I don't know where it should be reported. Hopefully someone else does ... signature.asc Description: This is a digitally signed message part.
Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu
Control: tag -1 moreinfo
On Wednesday, 24 January 2024 19:38:16 CET Patrice Duroux wrote:
> Package: src:linux
> Version: 6.7.1-1~exp1
> Severity: normal
>
> Giving a try to 6.7, here is a message extracted from dmesg:
Is that dmesg output from 6.7(.0) or 6.7.1?
If from 6.7.1, does the error NOT occur with 6.7.0?
If that's the case, can you test the attached patch with the `test-patches`
script? See the following link for instructions:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4>From 48e0efa8ff3b5f97cd2b12040b676dad09dbcefd Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Wed, 24 Jan 2024 19:59:35 +0100
Subject: [PATCH] Revert "drm/amd/display: Pass pwrseq inst for backlight and
ABM"
This reverts commit f90fb3a482d1d4705603ab6c320de0ccd611055c.
---
.../drm/amd/display/dc/bios/bios_parser2.c| 4 +-
.../drm/amd/display/dc/bios/command_table2.c | 12 ++--
.../drm/amd/display/dc/bios/command_table2.h | 2 +-
.../gpu/drm/amd/display/dc/dc_bios_types.h| 2 +-
drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c | 8 +--
.../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c | 7 +--
.../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.h | 2 +-
.../amd/display/dc/dcn31/dcn31_panel_cntl.c | 5 +-
.../amd/display/dc/hwss/dce110/dce110_hwseq.c | 16 ++---
.../amd/display/dc/hwss/dcn21/dcn21_hwseq.c | 36 +++
drivers/gpu/drm/amd/display/dc/inc/hw/abm.h | 3 +-
.../drm/amd/display/dc/inc/hw/panel_cntl.h| 2 -
.../drm/amd/display/dc/link/link_factory.c| 59 ++-
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 14 +
14 files changed, 53 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index b5b29451d2db..2d1f5efa9091 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1698,7 +1698,7 @@ static enum bp_result bios_parser_enable_disp_power_gating(
static enum bp_result bios_parser_enable_lvtma_control(
struct dc_bios *dcb,
uint8_t uc_pwr_on,
- uint8_t pwrseq_instance,
+ uint8_t panel_instance,
uint8_t bypass_panel_control_wait)
{
struct bios_parser *bp = BP_FROM_DCB(dcb);
@@ -1706,7 +1706,7 @@ static enum bp_result bios_parser_enable_lvtma_control(
if (!bp->cmd_tbl.enable_lvtma_control)
return BP_RESULT_FAILURE;
- return bp->cmd_tbl.enable_lvtma_control(bp, uc_pwr_on, pwrseq_instance, bypass_panel_control_wait);
+ return bp->cmd_tbl.enable_lvtma_control(bp, uc_pwr_on, panel_instance, bypass_panel_control_wait);
}
static bool bios_parser_is_accelerated_mode(
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
index ab0adabf9dd4..90a02d7bd3da 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
@@ -976,7 +976,7 @@ static unsigned int get_smu_clock_info_v3_1(struct bios_parser *bp, uint8_t id)
static enum bp_result enable_lvtma_control(
struct bios_parser *bp,
uint8_t uc_pwr_on,
- uint8_t pwrseq_instance,
+ uint8_t panel_instance,
uint8_t bypass_panel_control_wait);
static void init_enable_lvtma_control(struct bios_parser *bp)
@@ -989,7 +989,7 @@ static void init_enable_lvtma_control(struct bios_parser *bp)
static void enable_lvtma_control_dmcub(
struct dc_dmub_srv *dmcub,
uint8_t uc_pwr_on,
- uint8_t pwrseq_instance,
+ uint8_t panel_instance,
uint8_t bypass_panel_control_wait)
{
@@ -1002,8 +1002,8 @@ static void enable_lvtma_control_dmcub(
DMUB_CMD__VBIOS_LVTMA_CONTROL;
cmd.lvtma_control.data.uc_pwr_action =
uc_pwr_on;
- cmd.lvtma_control.data.pwrseq_inst =
- pwrseq_instance;
+ cmd.lvtma_control.data.panel_inst =
+ panel_instance;
cmd.lvtma_control.data.bypass_panel_control_wait =
bypass_panel_control_wait;
dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
@@ -1012,7 +1012,7 @@ static void enable_lvtma_control_dmcub(
static enum bp_result enable_lvtma_control(
struct bios_parser *bp,
uint8_t uc_pwr_on,
- uint8_t pwrseq_instance,
+ uint8_t panel_instance,
uint8_t bypass_panel_control_wait)
{
enum bp_result result = BP_RESULT_FAILURE;
@@ -1021,7 +1021,7 @@ static enum bp_result enable_lvtma_control(
bp->base.ctx->dc->debug.dmub_command_table) {
enable_lvtma_control_dmcub(bp->base.ctx->dmub_srv,
uc_pwr_on,
-pwrseq_instance,
+panel_instance,
bypass_panel_control_wait);
return BP_RESULT_OK;
}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.h b/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
index 41c8c014397f..b6d09bf6cf72 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
@@ -96,7 +96,7 @@ struct cmd_tbl {
struct bios_parser *bp, uint8_t id);
enum bp_result (*en
Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919
On Monday, 22 January 2024 15:42:48 CET Diederik de Haas wrote: > I'm currently working on an update for upstream version 20230919, based > upon MR86 (Release 20230804) [1], which itself is based upon MR85 > (Update to 20230625) [2] and I'm running into some major issues: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/87 > 3) Upstream commit a0142c57045701b7557c3060af5c4246c420e4d8 titled >"ath10k/WCN3990: move wlanmdsp to qcom/sdm845" would mean moving >entries from ``debian/config/atheros`` to ``debian/config/qcom-soc`` >and adding a 'recommends' field to ``atheros``'s ``defines`` file. >Which means that qcom-soc recommends atheros and atheros recommends >qcom-soc. Technically doable, but it raises the question whether this >separation still makes sense. Small correction: qcom-soc no longer recommends atheros as the 'wlanmdsp' file was the (sole) reason for the recommends, so that can be dropped. I still think the separation is rather arbitrary and unlikely to be useful (going forward). signature.asc Description: This is a digitally signed message part.
Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919
Source: firmware-nonfree Version: 20230625-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm currently working on an update for upstream version 20230919, based upon MR86 (Release 20230804) [1], which itself is based upon MR85 (Update to 20230625) [2] and I'm running into some major issues: 1) Salsa's CI now always fails as the (archive) size is now too big for it to handle it. 2) Upstream introduced a new keyword RawFile to 'list files that must not be compressed'. I'm guessing one or more script files need to be updated for it? 3) Upstream commit a0142c57045701b7557c3060af5c4246c420e4d8 titled "ath10k/WCN3990: move wlanmdsp to qcom/sdm845" would mean moving entries from ``debian/config/atheros`` to ``debian/config/qcom-soc`` and adding a 'recommends' field to ``atheros``'s ``defines`` file. Which means that qcom-soc recommends atheros and atheros recommends qcom-soc. Technically doable, but it raises the question whether this separation still makes sense. [1] https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/86 [2] https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/85 - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.11-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/XblvOeH7bbgUCZa5+3wAKCRDXblvOeH7b br9tAQCbvKeLqadcQE0fBigvlCW66k55+X76p0gd+R45PUc6ngEAqjJuUSHra5Jd Liswzmc7gOnYa8DEg4Y2ZXzl8xep0wc= =33X+ -END PGP SIGNATURE-
Bug#920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend
Control: found -1 20190717-1 On Wed, 24 Mar 2021 11:12:02 +0100 maximilian attems wrote: > > I seem to have the same problem with version 20190717 (debian testing > > 5.4.13-1 amd64). > > How about firmware 20210208-4, which should have an upgrade and > latest linux in Debian Bullseye? What's the status when used with current Stable (kernel 6.1.x + firmware 20230210-5)? Or if possible with kernel + firmware from Testing/Unstable? signature.asc Description: This is a digitally signed message part.
Bug#1050852: firmware-misc-nonfree: System crashes and reboots when i915/kbl_dmc_ver1_04.bin is present
Control: tag -1 moreinfo On Wednesday, 30 August 2023 10:34:03 CET hanzoh wrote: > installing Debian 12 on an HP ProDesk 400 G5 Mini works fine, but gives the > following warning in dmesg: > Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin > So when installing firmware-misc-nonfree, this firmware file becomes > available and is loaded correctly. Unfortunately, this leads to the system > crashing every few minutes. > > I have narrowed it down to the following situation: > - When firmware-misc-nonfree is installed, but I delete or rename > /lib/firmware/i915/kbl_dmc_ver1_04.bin, the system no longer crashes > - With i915/kbl_dmc_ver1_04.bin present and a monitor being connected and > turned on, the system no longer crashes Can you share (full, possibly anonymized) `dmesg` output when things work? > Kernel: Linux 6.1.0-11-amd64 (SMP w/6 CPU threads; PREEMPT) Can you try with a more recent kernel? There hasn't been an update to the firmware, but 'in any case', the kernel shouldn't crash and it can be that a later kernel version fixed the crashing. signature.asc Description: This is a digitally signed message part.
Bug#1034903: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin navi10_mes.bin for module amdgpu
On Friday, 23 June 2023 18:33:44 CET Alex Deucher wrote:
> On Wed, Jun 21, 2023 at 11:38 AM Ben Hutchings wrote:
> > On Thu, 27 Apr 2023 15:43:28 +0800 xiao sheng wen(
> > wrote:
> > > Package: firmware-amd-graphics
> > > Version: 20230310-1~exp1
> > >
> > > When I upgrade to kernel 5.10.0-22-arm64, there are following error
> > >
> > > infos:
> > > W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin
> > > for module amdgpu W: Possible missing firmware
> > > /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu>
> > [...]
>
> Those could be dropped. They are not really used by the driver. They
> are for a feature which was not ultimately productized on those parts.
Does this mean that *this* bug can be closed?
Further discussions are about different firmware files, but not the ones
this bug was about.
> > More recently amdgpu added:
> >
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes_2.bin");
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
> >
> > and these are also missing from linux-firmware.git.
> >
> > Is this firmware intended to be available to the public?
>
> Yes, those will be available soon.
From current master WHENCE file:
File: amdgpu/gc_11_0_3_me.bin
File: amdgpu/gc_11_0_3_mec.bin
File: amdgpu/gc_11_0_3_mes1.bin
File: amdgpu/gc_11_0_3_mes_2.bin
So 2 out of 3 are now available, but not the `*_mes.bin` file.
signature.asc
Description: This is a digitally signed message part.
Re: Proposal: Switch to linear git history
On Monday, 15 January 2024 14:07:42 CET Emanuele Rocca wrote: > A partial explanation for the confusion is that right now the master > branch is where you land changes that target experimental, while the sid > branch is for changes targeting sid. However, obviously not all commits > end up in Debian experimental - And my proposal is that 'all' changes (refactorings/new modules) target the master branch which then land in Experimental first. And when the time is right (usually around version .0/.1/.2), then it gets uploaded to Sid. But imo new features/modules should NOT go directly to Sid. > but the guideline is to always send changes to master anyways. I don't think such a guideline exists, at least not 'formally'. There currently is just 1 (old) MR targeting Sid, but there have been more in the past. I just checked the merged MRs and the current practice does seem to be targeting master, but there are some older ones (>4 months) which went directly to Sid which I think they shouldn't. signature.asc Description: This is a digitally signed message part.
Re: Proposal: Switch to linear git history
I don't feel qualified on the general topic, but ... On Thursday, 21 December 2023 17:30:26 CET Bastian Blank wrote: > - All changes need to go via master, which they should do anyway. I think this as a general rule, with few clearly defined exceptions (like stable release updates), would be a good thing. Now it feels like targeting 'sid' is a way to (quickly) 'sneak' in some changes. Moreover targeting 'sid' or 'master' seems rather arbitrary atm. signature.asc Description: This is a digitally signed message part.
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
On Saturday, 13 January 2024 20:22:39 CET Arno Lehmann wrote: > Am 13.01.2024 um 17:13 schrieb Diederik de Haas: > > Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy > > access to previous (6.1) kernels uploaded to Debian with which you can > > check if the problem was present in early 6.1 kernels. > > The oldest record of this issue has happened with Linux version > 6.1.0-11-amd64 > > As I usually keep this box updated, and the problems happens only > randomly, I think the best way forward might be to try with a kernel > that did *not* show this problem. > > Does that look reasonable? Yes > So I conclude I should look at something earlier than what was used with > boot 86e1a04baba04a409c34796c0fb079ff, i.e. > > journalctl --boot 86e1a04baba04a409c34796c0fb079ff | head -n 1 > Aug 30 18:16:18 Zwerg kernel: Linux version 6.1.0-11-amd64 > (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU > ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian > 6.1.38-4 (2023-08-08) > > correct? > > Via the page you reference, I find a kernel package > linux-image-6.1.0-1-amd64 6.1.4-1 which might be worth a try. > > I'll need some time to sort out how to install such a package... https://snapshot.debian.org/package/linux-signed-amd64/6.1.4%2B1/#linux-image-6.1.0-1-amd64_6.1.4-1 It should be as simple as downloading that .deb file and installing it via ``dpkg -i `` or ``apt install ./`` If you also have custom kernel modules via dkms, then you'd also need the corresponding linux-headers package. https://snapshot.debian.org/package/linux/6.1.4-1/#linux-headers-6.1.0-1-amd64_6.1.4-1 You could also try version 6.1~rc3+1~exp1, but if it's present in 6.1.4-1, then I guess it's safe to say the issue is present in the whole 6.1 series and it probably has never worked (as Salvatore thought). signature.asc Description: This is a digitally signed message part.
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
On Saturday, 13 January 2024 16:39:51 CET Arno Lehmann wrote: > > Just to be clear, can you confirm this is or is not a regression from > > a previous running 6.1.y kernel? > > On this hardware, the network issues appeared right from the start. > ... > Actually I don't even know which was the first kernel version I had on > this host, but it's been on Bookworm for all its lifetime. Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy access to previous (6.1) kernels uploaded to Debian with which you can check if the problem was present in early 6.1 kernels. signature.asc Description: This is a digitally signed message part.
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
On Saturday, 13 January 2024 11:45:29 CET Arno Lehmann wrote: > Hardware name: ASUS System Product Name/ROG STRIX X670E-A GAMING WIFI, > BIOS 1410 04/28/2023 Possibly not related, but there's BIOS 1807 available. signature.asc Description: This is a digitally signed message part.
Bug#1059969: linux-image-6.6.9-amd64: CONFIG_MODULE_COMPRESS_XZ=y breaks cpu frequency scaling governor kernel module
On Thursday, 4 January 2024 14:34:10 CET Jy Deng wrote: > 3. I find that if CONFIG_CPU_FREQ_GOV_POWERSAVE=m, then though such > module cannot be in use after boot at once, but it is possible to > manually modprobe them. So it may indicate that to use > CONFIG_CPU_FREQ_GOV_POWERSAVE=m with CONFIG_MODULE_COMPRESS_XZ=y is > actually possible. The problem we find here may be not so fundamental. That's actually how it always worked. $ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors likely only lists 'performance' and 'schedutil'. /lib/modules/$(uname -r)/kernel/drivers/cpufreq/ lists several more governors and when you modprobe them, they get added to 'scaling_available_governors'. And also to `cpupower frequency-info` -> 'available cpufreq governors'. So if you can verify whether it works with 'modprobe' then this is not a bug. signature.asc Description: This is a digitally signed message part.
Bug#1059607: linux-image-6.1.0-16-amd64: Steam Deck does not recognize USB keyboard on Bookworm
On Friday, 29 December 2023 13:50:34 CET Salvatore Bonaccorso wrote: > > Version: 6.1.67-1 > > > > When the system reboots, it switches to the 6.1.0-16 kernel package. At > > this point, power delivery through the Steam Deck's USB-C connector works, > > but it will not recognize a keyboard or ethernet adapter. > > > > Everything works fine if I boot from 6.1.0-10, so this is a regression in > > bookworm-updates. > > I realize this is asking much, but do you think you would be able to > bisect the upstream versions accordingly to see if you find the > introducing commit for the issue? Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find ready- made kernel between -10 en -16 which should help narrow the range of the problematic commit. FYI: kernel 6.1.38-3 got ABI 11 (thus 6.1.0-11) But: do NOT use version 6.1.64-1 (6.1.0-14) as it contains an ext4 bug which could cause data loss (https://bugs.debian.org/1057843) signature.asc Description: This is a digitally signed message part.
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
On Wednesday, 20 December 2023 22:08:27 CET Thorsten Glaser wrote: > >So it was present on 5.9.0-2 (5.9.6-1), but no longer on 5.10.X? > > Yes to the former, unsure to the latter. > > >Do you want to keep the bug open for your other/original system? The latter question was based on it on the assumption that it was fixed on 5.10.x, but as you're unsure, let's keep it open. signature.asc Description: This is a digitally signed message part.
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
On Wednesday, 20 December 2023 14:02:57 CET Thorsten Glaser wrote: > >The firmware file iwlwifi-4965-2.ucode hasn't been updated since > >2009-07-09, but maybe/hopefully the kernel deals better with it now? > > Perhaps. On this different Thinkpad, I’m running bullseye and > don’t get the messages. iwl-related dmesg entries: So it was present on 5.9.0-2 (5.9.6-1), but no longer on 5.10.X? Do you want to keep the bug open for your other/original system? signature.asc Description: This is a digitally signed message part.
Bug#1053994: the es8316 module does not work on the huawei mate d15 laptop
On Wednesday, 20 December 2023 18:28:44 CET Nikolay Sabelnikov wrote: > also, the kernel should be built with this parameter of the kernel config > > CONFIG_SND_SOC_AMD_LEGACY_MACH=m That's currently not enabled in Debian's kernel config, so that needs to be added then. signature.asc Description: This is a digitally signed message part.
Bug#1053994: the es8316 module does not work on the huawei mate d15 laptop
On woensdag 20 december 2023 18:25:38 CET you wrote: > it was possible to test only on the kernel version 6.7 built for ubuntu. > Unfortunately, debian does not have this version of the kernel. Even in the > experimental repository. Then you wait until that kernel is available in Debian and test with that. Or you build your own kernel with Debian's config. If you want, you can use my branch for that: https://salsa.debian.org/diederik/linux/-/tree/update-to-6.7 > The 1st link is an error to a person who understands this and sends patches > to the upstream kernel. The second link comes from the upstream core. The upstream commit was useful. As it isn't marked as a bugfix, it'll be send to Linus in the 6.8 merge window, so it won't end up (by default) in the 6.7 upstream kernel and thus not (by default) in Debian's. signature.asc Description: This is a digitally signed message part.
Bug#1053994: the es8316 module does not work on the huawei mate d15 laptop
On Wednesday, 20 December 2023 17:20:18 CET Nikolay Sabelnikov wrote: > I also got a bug. I tried it on the 6.7-rc6 core. in my case, the sound did > not work. > > https://github.com/codepayne/linux-sound-huawei/issues/27 What works, or in this case doesn't work, on a Ubuntu kernel, is completely irrelevant to the Debian kernel as they use different kernel configs. Please don't pollute Debian kernel bugs with such info, or at least clearly mark it *in the Debian bug* that it's from a different distro. signature.asc Description: This is a digitally signed message part.
Bug#1026906: /lib/firmware/iwlwifi-cc-a0-72.ucode: "Microcode SW error detected" after idle for a while and breaks wifi
On Friday, 23 December 2022 18:40:32 CET Yuxuan Wang wrote: > Package: firmware-iwlwifi > Version: 20221109-4 > > With firmware iwlwifi-cc-a0-72.ucode, the wifi chip would throw "Microcode > SW error detected" after the system is idle for a while. After wakig up the > system, the wifi would appears to be connected (in NetworkManager), but > pinging the router will give "Destination Host Unreachable", and I have to > turn wifi off and one again in NetworkManager to fix it. > > This is the kernel log when the error happens: > ... > (delay=0ms). Dec 20 16:00:14 perch kernel: ieee80211 phy0: Hardware restart > was requested > > The hardware info according to `lspci -nn -d ::280` is: > > 3b:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 > [8086:2723] (rev 1a) > > I tried to downgrade it, via: > > mv /lib/firmware/iwlwifi-cc-a0-72.ucode > /lib/firmware/iwlwifi-cc-a0-72.ucode.backup > > And then reload the kernel models, which loaded 71 instead, but that still > has a similar issue: instead of "Destination Host Unreachable", pinging the > router gives me super high latency (in seconds instead of milliseconds) and > the network is almost unusable, and I have to turn wifi off and on again in > NetworkManager to fix it. The kernel log for 71 is: > > I have to downgrade again (from 71 to 63, there's no version in between) to > fix the issue. So to summarize: It works with 63, but it fails with 71 or 72? And in order to make it work, you have to (actively) remove the 71 and 72 versions? signature.asc Description: This is a digitally signed message part.
Bug#1025476: firmware-linux: Unrecognized video cards and wifi
Control: tag -1 moreinfo On Mon, 05 Dec 2022 11:57:40 + Teo wrote: > Package: firmware-linux > Version: 20210315-3 > Severity: important > > I'm trying to install Debian Stable on an msi pulse gl76 equipped with an i7 > 12700h and an Nvidia 3060 laptop. > The problem is that neither video card seems to be recognized. > > I upload the dsmeg result as an attachment and I'm available if you need any > more information. The only message wrt firmware seems to be related to your mouse... > Finally I must say that on the same device I also tried debian testing and > in this case the video cards and wifi work fine, only the bluetooth didn't > work and I opened a bug https://bugs.debian.org/1025132. > This is also why I can't figure out why with all the backports here it still > doesn't work. I'm not sure what this bug is about if it is working on Testing. Is it that you want to run Stable, but there it doesn't work and the backports versions (of the kernel) didn't seem to (fully?) work? But this bug is filed against the firmware package, not the kernel ... Anyway, is the problem still present? signature.asc Description: This is a digitally signed message part.
Bug#942563: linux-image-5.2.0-3-amd64: iwlwifi continously restarts
Control: tag -1 moreinfo On Fri, 18 Oct 2019 09:36:07 +0200 Kamil Jońca wrote: >* What led up to the situation? > Trying to use wifi under new kernel > > When I install new kernel my wifi starts continously restart, when i do: > (xz -dc /var/log/syslog-2019*.xz; cat /var/log/syslog-20191018 /var/log/ syslog) |grep 'Microcode SW error detected' |less -N > i got > 1 2019-10-08T14:45:44.172176+02:00 dorsz kernel: [23505.590088] iwlwifi :3a:00.0: Microcode SW error detected. Restarting 0x200. Is this issue still occurring? If so, an you share a full dmesg? That should show which kernel and which WiFi card with which firmware file/ version you're using. signature.asc Description: This is a digitally signed message part.
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
Control: tag -1 moreinfo On Sat, 21 Nov 2020 11:32:08 +0100 Thorsten Glaser wrote: > Package: firmware-iwlwifi > Version: 20200918-1 > Followup-For: Bug #934781 > X-Debbugs-Cc: t...@mirbsd.de > > It still happens. > > [583944.226966] iwl4965 :03:00.0: Microcode SW error detected. > Restarting 0x200. > [583944.226974] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24 > [583944.226991] iwl4965 :03:00.0: Start IWL Error Log Dump: > [583944.226996] iwl4965 :03:00.0: Status: 0x000213E4, count: 5 > [583944.227139] iwl4965 :03:00.0: Desc > Time data1 data2 line > [583944.227146] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) > 2382371429 0x0002 0x0263 208 > [583944.227150] iwl4965 :03:00.0: pc blink1 blink2 ilink1 ilink2 > hcmd > [583944.227155] iwl4965 :03:00.0: 0x0046C 0x02156 0x004C2 0x006DA 0x005F2 > 0x41E0048 > [583944.227160] iwl4965 :03:00.0: FH register values: > [583944.227176] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_STTS_WPTR_REG: > 0X22aec200 > [583944.227192] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_RBDCB_BASE_REG: > 0X022ae4d0 > [583944.227208] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: > 0X0080 > [583944.227224] iwl4965 :03:00.0: FH49_MEM_RCSR_CHNL0_CONFIG_REG: > 0X80809000 > [583944.227239] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: > 0X003c > [583944.227255] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_STATUS_REG: > 0X0263 > [583944.227271] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: > 0X > [583944.227286] iwl4965 :03:00.0: FH49_TSSR_TX_STATUS_REG: > 0X07ff0002 > [583944.227302] iwl4965 :03:00.0: FH49_TSSR_TX_ERROR_REG: > 0X > [583944.228668] iwl4965 :03:00.0: Can't stop Rx DMA. > [583944.228708] ieee80211 phy0: Hardware restart was requested > > Kernel: Linux 5.9.0-2-amd64 (SMP w/2 CPU threads) Is this issue still happening? The firmware file iwlwifi-4965-2.ucode hasn't been updated since 2009-07-09, but maybe/hopefully the kernel deals better with it now? 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
On Friday, 23 December 2022 12:25:08 CET Rui Dinis wrote: > Installed the new firmware-nonfree 20221214-1 unstable and Debian still > crashes after a few minutes/hours. The machine completely freezes/locks up. > The graphic card is not defective, installed windows to test, played a few > games, and had no issue in windows (I hate windows). Tried with Linux Mint > with proprietary drivers, and no issues, works flawless, no crashes or > issues in games with wine and games with a virtual machine. If the firmware files are also installed on Linux Mint, then the issue is likely with the nouveau drivers. Debian does have a nvidia-graphics-drivers source package, so maybe an appropriate version of that may help? In any case, when crashes happen, it REALLY helps if f.e. `dmesg` output is shared which shows the crash. > This is a SERIOUS problem and after a few months, the issue is not solved. People like me spend their FREE time trying to help you with YOUR problem. If you're not getting your money's worth, get a SLA. And pay for that. IOW: drop the attitude signature.asc Description: This is a digitally signed message part.
Bug#1023631: firmware-misc-nonfree: Possibly missing firmware for Creative Labs Sound Blaster Z PCIe sound card
Control: tag -1 moreinfo On Monday, 7 November 2022 23:35:44 CET Julian Groß wrote: > Package: firmware-misc-nonfree > Version: 20221012-1 > > I have been running into weird behaviour on my Creative Labs Sound Blaster Z > (Serial number either SB1500 or SB1502). Just now I noticed that a > seemingly related firmware file doesn't get loaded. Here is a section out > of dmesg: > > [9.591329] snd_hda_intel :02:00.0: firmware: failed to load > ctefx-desktop.bin (-2) [9.591355] firmware_class: See > https://wiki.debian.org/Firmware for information about missing firmware [ > 9.591387] snd_hda_intel :02:00.0: firmware: failed to load > ctefx-desktop.bin (-2) [9.591409] snd_hda_intel :02:00.0: Direct > firmware load for ctefx-desktop.bin failed with error -2 [9.592599] > snd_hda_intel :02:00.0: firmware: direct-loading firmware ctefx.bin > > ctefx-desktop.bin shows up in the list of firmware that is supposed to be > included in Debian. https://wiki.debian.org/Firmware/List ctefx-desktop.bin is not in the upstream firmware repo and (thus) also not in Debian's package. I haven't looked closely at that wiki page/script to see where it got it from. https://www.alsa-project.org/files/pub/firmware/ does have that file though. The error you got is Debian specific, but the last line does show it has loaded 'a' (fallback) firmware. > While the driver seems to load a different firmware file, and the sound card > works most of the time, the identification in lspci seems wrong, and there > is random issues like no audio output until reboot, "electric" audio output > until reboot, no audio input until reboot, settings needing to be applied > multiple times, and alsactl store failing. lspci reports a "Subsystem: > Creative Labs SB1570 SB Audigy Fx", while this card is from a different > series and looks completely different from it. Not knowing much about this > sort of thing, I am assuming the driver is falling back to the firmware for > a different sound card, which might be causing a bunch of my issues. There could be several issues at play here. Can you DL via the above mentioned URL the latest `alsa-firmware-.tar.bz` and place the ctefx-desktop.bin in the appropreate location and see if that resolves this issue? > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.0.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, > TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE It's also useful to know if there are any changes (for the better) with more recent kernels. That can be a 6.1 kernel from Stable or a 6.5+ one from Testing/Unstable/Experimental. signature.asc Description: This is a digitally signed message part.
Bug#1058999: linux-image-6.5.0-5-amd64: System hangs when connecting an ethernet NIC to network which was not connected on boot
On Tuesday, 19 December 2023 19:16:33 CET Erwan David wrote: > Same behaviour with 6.6.3-1 from experimental (that's what apt gave me, > maybe tomoroow the 6.6.4). Either your APT cache should be updated or you're using a mirror which is rather severely out of date. 6.6.4-1 was uploaded to Debian on 2023-12-03, a day after .3-1. signature.asc Description: This is a digitally signed message part.
Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau
Control: tag -1 +patch On dinsdag 19 december 2023 17:14:22 CET you wrote: > > If you manually create those links from the above "+Link:" lines, > > would that fix the issues? > > I've added only the ga107 symlinks (since this is what is needed > for my machine) with > ... > and this fixes all the issues Thanks, submitted the following MR to get the Debian package updated: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/80 signature.asc Description: This is a digitally signed message part.
Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau
Control: severity -1 important Control: tag -1 moreinfo On Tuesday, 19 December 2023 13:57:51 CET Vincent Lefevre wrote: > Another piece of information: this is a regression. > > With the 6.1.0-16-amd64 kernel from stable, "journalctl -b -g ga107" > gives > > Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1) > Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load > nvidia/ga107/nvdec/scrubber.bin (-2) Dec 19 04:57:07 qaa kernel: nouveau > :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2) > > and I don't have any issue with the machine. > > With the 6.5.0-5-amd64 kernel, "journalctl -b -1 -g ga107" gives Upstream kernel commit 4b569ded09fdadb0c14f797c8dae4e8bc4bbad9f added lines to load the firmware files and was merged into kernel 6.2, so that it doesn't show up in a 6.1 kernel is expected. Upstream firmware commit 2c2be4215fe29870dcd9a059ff8778e73269ddc1 added the files but it seems the Link lines weren't added to the Debian package in commit 9714742762ab2b278fd0961652a4dd54ff82ea8b ``` $ git show 2c2be4215fe29870dcd9a059ff8778e73269ddc1 | grep Link @@ -5182,6 +5182,71 @@ Link: nvidia/tu117/nvdec/scrubber.bin -> ../../tu116/ nvdec/scrubber.bin Link: nvidia/tu117/sec2/desc.bin -> ../../tu116/sec2/desc.bin Link: nvidia/tu117/sec2/image.bin -> ../../tu116/sec2/image.bin Link: nvidia/tu117/sec2/sig.bin -> ../../tu116/sec2/sig.bin +Link: nvidia/ga103/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin +Link: nvidia/ga103/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin +Link: nvidia/ga103/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin +Link: nvidia/ga103/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin +Link: nvidia/ga103/sec2/desc.bin -> ../../ga102/sec2/desc.bin +Link: nvidia/ga103/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin +Link: nvidia/ga103/sec2/image.bin -> ../../ga102/sec2/image.bin +Link: nvidia/ga103/sec2/sig.bin -> ../../ga102/sec2/sig.bin +Link: nvidia/ga104/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin +Link: nvidia/ga104/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin +Link: nvidia/ga104/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin +Link: nvidia/ga104/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin +Link: nvidia/ga104/sec2/desc.bin -> ../../ga102/sec2/desc.bin +Link: nvidia/ga104/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin +Link: nvidia/ga104/sec2/image.bin -> ../../ga102/sec2/image.bin +Link: nvidia/ga104/sec2/sig.bin -> ../../ga102/sec2/sig.bin +Link: nvidia/ga106/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin +Link: nvidia/ga106/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin +Link: nvidia/ga106/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin +Link: nvidia/ga106/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin +Link: nvidia/ga106/sec2/desc.bin -> ../../ga102/sec2/desc.bin +Link: nvidia/ga106/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin +Link: nvidia/ga106/sec2/image.bin -> ../../ga102/sec2/image.bin +Link: nvidia/ga106/sec2/sig.bin -> ../../ga102/sec2/sig.bin +Link: nvidia/ga107/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin +Link: nvidia/ga107/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin +Link: nvidia/ga107/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin +Link: nvidia/ga107/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin +Link: nvidia/ga107/sec2/desc.bin -> ../../ga102/sec2/desc.bin +Link: nvidia/ga107/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin +Link: nvidia/ga107/sec2/image.bin -> ../../ga102/sec2/image.bin +Link: nvidia/ga107/sec2/sig.bin -> ../../ga102/sec2/sig.bin ``` If you manually create those links from the above "+Link:" lines, would that fix the issues? On Tuesday, 19 December 2023 13:36:17 CET Vincent Lefevre wrote: > for the above firmware, there's no "acr" directory in nvidia/ga107: The directory is not physically present, but it ought to consists of symlinks to the ga102 directory, which does have an `acr` directory. signature.asc Description: This is a digitally signed message part.
Bug#1053994: the es8316 module does not work on the huawei mate d15 laptop
Control: reassign -1 src:linux 6.1.55-1 Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=218085 Control: tag -1 upstream On Sunday, 29 October 2023 19:03:30 CET Николай wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=218085 updating metadata accordingly On Monday, 18 December 2023 07:25:54 CET Nikolay Sabelnikov wrote: > It looks like there is a solution. > https://bugzilla.kernel.org/show_bug.cgi?id=215119#c52 Should your upstream bug be merged with this one? (No idea if that's possible or how that should be done though) I verified that the commits are part of 6.7-rc1. None have a "Fixes:" tag though, so it probably won't be automatically backported to 6.1 kernels. signature.asc Description: This is a digitally signed message part.
Bug#1058595: Bug - linux-image-6.1.0-15-amd64 - system won't shut down if using rtl8192cu wifi adapter.
Control: reassign -1 src:linux 6.1.66-1 Control: close -1 6.1.67-1 On Wednesday, 13 December 2023 15:27:14 CET Doug Behl wrote: > Package: linux-image-6.1.0-15-amd64 > Version: 6.1.661 > > Recent update from Linux image 6.1.0-13-amd64 to Linux image > 6.1.0-15-amd64 created an issue with system shutdown while using a wifi > adapter (D-Link DWA-121 150 Pico, rtl8192cu). Firmware-realtek is > installed. When shutting down, the system hangs while trying to > shutdown wpasupplicant and network-manager. Similar as bug #1057967 and #1057969 which are fixed in 6.1.67-1 signature.asc Description: This is a digitally signed message part.
Bug#1057967: Bug#1057969: linux-image-6.1.0-15-amd64: suspend/resume broken in 6.1.66 on Lenovo Thinkpad X230
On Monday, 11 December 2023 12:29:01 CET Salvatore Bonaccorso wrote:
> I cannot test for the regression explicitly myself, but 6.1.67 was
> released with just db46c77f3d51 ("Revert "wifi: cfg80211: fix CQM for
> non-range use""). Would you be in the position of do a test build with
> that commit (or with 6.1.67 upstream) to verify your issue goes away?
On Monday, 11 December 2023 12:37:44 CET Salvatore Bonaccorso wrote:
> I'm right now curious to find out if we see the same as
> #1057969 and if the upstream commit db46c77f3d51 ("Revert "wifi:
> cfg80211: fix CQM for non-range use"") in 6.1.67 upstream fixes the
> issue.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes an easy way to test it and the patch you should use is attached.From db46c77f3d51d24402731ea181b2a591e7dd1ac3 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman
Date: Mon, 11 Dec 2023 10:16:15 +0100
Subject: [PATCH] Revert "wifi: cfg80211: fix CQM for non-range use"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 307a6525c82a5a1bc5364711ece92c2d2487e1ad which is
commit 7e7efdda6adb385fbdfd6f819d76bc68c923c394 upstream.
It needed to have commit 076fc8775daf ("wifi: cfg80211: remove wdev
mutex") applied to properly work, otherwise regressions happen.
Link: https://lore.kernel.org/r/e374bb16-5b13-44cc-b11a-2f4eefb1e...@manjaro.org
Link: https://lore.kernel.org/r/87sf4belmm@turtle.gmx.de
Link: https://lore.kernel.org/r/20231210213930.61378-1-...@leolam.fr
Reported-by: L??o Lam
Reported-by: Sven Joachim
Reported-by: Philip M??ller
Cc: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
net/wireless/core.h| 1 -
net/wireless/nl80211.c | 50 --
2 files changed, 19 insertions(+), 32 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index ee980965a7cf..e1accacc6f23 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -297,7 +297,6 @@ struct cfg80211_cqm_config {
u32 rssi_hyst;
s32 last_rssi_event_value;
enum nl80211_cqm_rssi_threshold_event last_rssi_event_type;
- bool use_range_api;
int n_rssi_thresholds;
s32 rssi_thresholds[];
};
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 42c858219b34..b19b5acfaf3a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12574,6 +12574,10 @@ static int cfg80211_cqm_rssi_update(struct cfg80211_registered_device *rdev,
int i, n, low_index;
int err;
+ /* RSSI reporting disabled? */
+ if (!cqm_config)
+ return rdev_set_cqm_rssi_range_config(rdev, dev, 0, 0);
+
/*
* Obtain current RSSI value if possible, if not and no RSSI threshold
* event has been received yet, we should receive an event after a
@@ -12648,6 +12652,18 @@ static int nl80211_set_cqm_rssi(struct genl_info *info,
wdev->iftype != NL80211_IFTYPE_P2P_CLIENT)
return -EOPNOTSUPP;
+ if (n_thresholds <= 1 && rdev->ops->set_cqm_rssi_config) {
+ if (n_thresholds == 0 || thresholds[0] == 0) /* Disabling */
+ return rdev_set_cqm_rssi_config(rdev, dev, 0, 0);
+
+ return rdev_set_cqm_rssi_config(rdev, dev,
+ thresholds[0], hysteresis);
+ }
+
+ if (!wiphy_ext_feature_isset(>wiphy,
+ NL80211_EXT_FEATURE_CQM_RSSI_LIST))
+ return -EOPNOTSUPP;
+
if (n_thresholds == 1 && thresholds[0] == 0) /* Disabling */
n_thresholds = 0;
@@ -12655,20 +12671,6 @@ static int nl80211_set_cqm_rssi(struct genl_info *info,
old = rcu_dereference_protected(wdev->cqm_config,
lockdep_is_held(>mtx));
- /* if already disabled just succeed */
- if (!n_thresholds && !old)
- return 0;
-
- if (n_thresholds > 1) {
- if (!wiphy_ext_feature_isset(>wiphy,
- NL80211_EXT_FEATURE_CQM_RSSI_LIST) ||
- !rdev->ops->set_cqm_rssi_range_config)
- return -EOPNOTSUPP;
- } else {
- if (!rdev->ops->set_cqm_rssi_config)
- return -EOPNOTSUPP;
- }
-
if (n_thresholds) {
cqm_config = kzalloc(struct_size(cqm_config, rssi_thresholds,
n_thresholds),
@@ -12683,26 +12685,13 @@ static int nl80211_set_cqm_rssi(struct genl_info *info,
memcpy(cqm_config->rssi_thresholds, thresholds,
flex_array_size(cqm_config, rssi_thresholds,
n_thresholds));
- cqm_config->use_range_api = n_thresholds > 1 ||
- !rdev->ops->set_cqm_rssi_config;
rcu_assign_pointer(wdev->cqm_config, cqm_config);
-
- if (cqm_config->use_range_api)
- err = cfg80211_cqm_rssi_update(rdev, dev, cqm_config);
- else
- err = rdev_set_cqm_rssi_config(rdev, dev,
- thresholds[0],
- hysteresis);
} else {
RCU_INIT_POINTER(wdev->cqm_config, NULL);
- /* if enabled as range also disable via range */
- if (old->use_range_api)
- err = rdev_set_cqm_rssi_range_config(rdev, dev, 0, 0);
- else
- err = rdev_set_cqm_rssi_config(rdev, dev, 0, 0);
}
+ err = cfg80211_cqm_rssi_update(rdev, dev, cqm_config);
if (err) {
rcu_assign_pointer(wdev->cqm_config, old);
Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable
On Monday, 11 December 2023 13:01:58 CET Grand T wrote: > Linux 6.6.6 is out and its only change over Linux 6.6.5 released just a few > days ago is reverting the patch "wifi: cfg80211: fix CQM for non-range > use." That patch ended up regressing Linux wireless support with deadlocks > in the IWD wireless daemon hangs on shutdown, and related issues with > user-space network managers Kernel 6.6.6 fixes an issue introduced in 6.6.5, but both have NOT been uploaded to Debian. If they were, that would've been to Experimental or Unstable, where breakage from time to time should be expected. Kernel 6.1.67 *is* relevant and is also a revert of that commit. signature.asc Description: This is a digitally signed message part.
Bug#1058028: linux-image-6.1.0-14-amd64 breaks suspend
On Monday, 11 December 2023 12:46:40 CET Dr. André Desgualdo Pereira wrote: > Package: src:linux > Version: 6.1.64-1 > Severity: important Stop using that kernel version ASAP! It has an ext4 bug which could cause data loss. See https://bugs.debian.org/1057843 and https://www.debian.org/News/2023/20231210 signature.asc Description: This is a digitally signed message part.
Bug#1052304: Debian 6.1 Kernels suspect
On Saturday, 9 December 2023 00:28:50 CET Jeffrey Altman wrote: > The bug is considered valid by upstream. A proposed fix for this issue is > being reviewed. > http://lists.infradead.org/pipermail/linux-afs/2023-December/007408.html > Please leave this issue open until the fix has been back ported into the > kernels shipped by Debian. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 describes a simple procedure with which one can test patches. I've attached the above referenced patch and verified that it applies (cleanly) onto a 6.1 kernel. Bill: can you test this patch and see if it resolved the issue?From: David Howells Subject: afs: Fix refcount underflow from error handling race Date: Fri, 08 Dec 2023 22:07:09 + Origin: https://lore.kernel.org/r/2633992.1702073...@warthog.procyon.org.uk If an AFS cell that has an unreachable (eg. ENETUNREACH) Volume Location server listed, an asynchronous probe to one of its addresses may fail immediately because sendmsg() returns an error. When this happens, a refcount underflow can happen if certain events hit a very small window. The way this occurs is: (1) There are two levels of "call" object, the afs_call and the rxrpc_call. Each of them can be transitioned to a "completed" state in the event of success or failure. (2) Asynchronous afs_calls are self-referential whilst they are active to prevent them from evaporating when they're not being processed. This reference is disposed of when the afs_call is completed. Note that an afs_call may only be completed once; once completed completing it again will do nothing. (3) When a call transmission is made, the app-side rxrpc code queues a Tx buffer for the rxrpc I/O thread to transmit. The I/O thread invokes sendmsg() to transmit it - and in the case of failure, it transitions the rxrpc_call to the completed state. (4) When an rxrpc_call is completed, the app layer is notified. In this case, the app is kafs and it schedules a work item to process events pertaining to an afs_call. (5) When the afs_call event processor is run, it goes down through the RPC-specific handler to afs_extract_data() to retrieve data from rxrpc - and, in this case, it picks up the error from the rxrpc_call and returns it. The error is then propagated to the afs_call and that is completed too. At this point the self-reference is released. (6) If the rxrpc I/O thread manages to complete the rxrpc_call within the window between rxrpc_send_data() queuing the request packet and checking for call completion on the way out, then rxrpc_kernel_send_data() will return the error from sendmsg() to the app. (7) Then afs_make_call() will see an error and will jump to the error handling path which will attempt to clean up the afs_call. (8) The problem comes when the error handling path in afs_make_call() tries to unconditionally drop an async afs_call's self-reference. This self-reference, however, may already have been dropped by afs_extract_data() completing the afs_call (9) The refcount underflows when we return to afs_do_probe_vlserver() and that tries to drop its reference on the afs_call. Fix this by making afs_make_call() attempt to complete the afs_call rather than unconditionally putting it. That way, if afs_extract_data() manages to complete the call first, afs_make_call() won't do anything. The bug can be forced by making do_udp_sendmsg() return -ENETUNREACH and sticking an msleep() in rxrpc_send_data() after the 'success:' label. The error message looks something like: refcount_t: underflow; use-after-free. WARNING: CPU: 3 PID: 720 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 ... RIP: 0010:refcount_warn_saturate+0xba/0x110 ... afs_put_call+0x1dc/0x1f0 [kafs] afs_fs_get_capabilities+0x8b/0xe0 [kafs] afs_fs_probe_fileserver+0x188/0x1e0 [kafs] afs_lookup_server+0x3bf/0x3f0 [kafs] afs_alloc_server_list+0x130/0x2e0 [kafs] afs_create_volume+0x162/0x400 [kafs] afs_get_tree+0x266/0x410 [kafs] vfs_get_tree+0x25/0xc0 fc_mount+0xe/0x40 afs_d_automount+0x1b3/0x390 [kafs] __traverse_mounts+0x8f/0x210 step_into+0x340/0x760 path_openat+0x13a/0x1260 do_filp_open+0xaf/0x160 do_sys_openat2+0xaf/0x170 or something like: refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0x99/0xda ... afs_put_call+0x4a/0x175 afs_send_vl_probes+0x108/0x172 afs_select_vlserver+0xd6/0x311 afs_do_cell_detect_alias+0x5e/0x1e9 afs_cell_detect_alias+0x44/0x92 afs_validate_fc+0x9d/0x134 afs_get_tree+0x20/0x2e6 vfs_get_tree+0x1d/0xc9 fc_mount+0xe/0x33 afs_d_automount+0x48/0x9d __traverse_mounts+0xe0/0x166 step_into+0x140/0x274 open_last_lookups+0x1c1/0x1df path_openat+0x138/0x1c3 do_filp_open+0x55/0xb4
Bug#1057790: linux-image-6.5.0-5-amd64: deadlock on RTL8125 in jumbo mtu mode
Control: reassign -1 src:linux 6.5.13-1 Control: fixed-upstream On Friday, 8 December 2023 16:10:50 CET Timo van Roermund wrote: > Package: linux-image-6.5.0-5-amd64 > Version: linux-image-6.5.0-5-amd64 > Severity: important > > My RTL8125 NIC stoped working after upgrading the kernel (linux-image-amd64) > from version 6.5.10+1 to 6.5.13+1. > > The issue has been fixed in kernel 6.6.5: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/driv > ers/net/ethernet/realtek?h=v6.6.5=a9ef897677f957401842e45f2006167cdf757ee > 4 > > But I'm not sure if kernel 6.5.x will still receive a fix, as it's EOL. Upstream won't. There might be a Debian backport, but I don't expect it. An update to 6.6.5 is already present in Debian kernel's git repo and that or a later 6.6 version should be released to Experimental or Unstable at some point, but AFAIK it's not known yet when and where. signature.asc Description: This is a digitally signed message part.
Bug#1057786: firmware-misc-nonfree: Split firmware firmware-misc-nonfree based on architecture
On Friday, 8 December 2023 14:51:52 CET David Heidelberg wrote: > would be lovely to have a firmware-misc-nonfree based on architecture. > Multiple of these firmwares are bound to arm64, x86_64 or other archs. > > Installing them for example in the CI for x86_64 leads to needing using: > > dpkg -L firmware-misc-nonfree | grep -v "i915" | xargs rm # drop extra 50M I have no opinion on whether splitting based on architecture is a good idea, but I did notice there were quite a number of f.e. nvidia firmware files in firmware-misc-nonfree which could be split into their own package? I haven't checked, but the same may be true for others like intel or mediatek. >From firmware-misc-nonfree Description: "This is a collection of firmware blobs which are not individually large enough to warrant a standalone package." It seems some *do* warrant a standalone package. signature.asc Description: This is a digitally signed message part.
Bug#1057040: firmware-qcom-soc: please add qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin and symlink
On Tuesday, 5 December 2023 18:30:39 CET Diederik de Haas wrote: > > Link: qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin -> > > LENOVO/21BX/audioreach-tplg.bin > > Added upstream in commit f9a35b3f0779844aa686b76506344db70a72820d and part > of upstream's 20230804 release. Link was added in 7d94e0fa84701f0c01877c21cf4857f94fd367ab, part of 20230919 signature.asc Description: This is a digitally signed message part.
Bug#1057040: firmware-qcom-soc: please add qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin and symlink
On Tuesday, 28 November 2023 14:29:28 CET Emanuele Rocca wrote: > Package: firmware-qcom-soc > Version: 20230515-3 > > The file qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin and its symlink > qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin are needed by the Lenovo > Thinkpad X13s. Please consider adding them to firmware-qcom-soc. > > File: qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin > Link: qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin -> > LENOVO/21BX/audioreach-tplg.bin Added upstream in commit f9a35b3f0779844aa686b76506344db70a72820d and part of upstream's 20230804 release. signature.asc Description: This is a digitally signed message part.
Bug#1029968: And some patches
Control: forwarded -1 https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/ https://lore.kernel.org/linux-media/cover.1701349092.git.hverkuil-ci...@xs4all.nl/ On Sunday, 3 December 2023 17:50:07 CET Dr. David Alan Gilbert wrote: > As well as the fixes in 6.6, A 6.6 kernel is now available in Experimental > we also need this patchup series here: > https://lore.kernel.org/linux-media/ZWibhE350L3BTRK8@gallifrey/T/#t > > These seem to make it pretty nicely. Excellent :) I saw they had "Fixes:" tags, which normally means they'll get backported to older kernel series like 6.6. signature.asc Description: This is a digitally signed message part.
Bug#1053503: Enable support for Renesas RZ/V2L, RZ/G2UL, and RZ/V2M
On Tuesday, 21 November 2023 17:58:55 CET John Vincent wrote: > Do you have any update on the Bug#1053503 please (Enable additional Renesas > platform like RZ/V2L). Is this change already got merged and available in > the daily Debian builds for testing? https://salsa.debian.org/kernel-team/linux/-/merge_requests/867 is the MR for it and it is merged and will be part of the next 6.6 kernel upload. It is not known when that will happen though. signature.asc Description: This is a digitally signed message part.
Re: ath10k_pci logs errors about missing pre-cal and cal firmware on a laptop
FTR: I do NOT speak on behalf of the Debian kernel team. On Tuesday, 14 November 2023 20:58:58 CET Paul Menzel wrote: > > Based upon the message: > > [ 14.401143] firmware_class: See https://wiki.debian.org/Firmware > > for information about missing firmware > > > > it seems you are not running a stock kernel. So perhaps Debian has > > modified the firmware loading such that it ignores the FW_OPT_NO_WARN > > flag and warns even when told not to do so? This does not appear to be > > an upstream kernel issue. > > Thank you very much for the analysis. It seems to be indeed a Debian > specific patch [1]. > > Dear Debian Linux kernel team, is my observation about the error log a > result of the patch and intended? > > [1]: > debian/patches/debian/firmware_class-refer-to-debian-wiki-firmware-page.patch There are a number of Debian patches wrt firmware and *I* think they should get a (serious) review. In https://bugs.debian.org/1040738 I requested a review of the firmware related patches and described one of the issues I encountered myself. I've also been involved in triaging Debian kernel bug issues and there I've encountered several more such cases. AFAIK quite a bit of work has happened upstream to make the firmware messages more appropriate and I think the Debian patches haven't been (properly) adjusted for those changes. So they are (very) likely caused by the Debian patches and thus expected, but I'm hesitant to call them intended ;-) signature.asc Description: This is a digitally signed message part.
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Control: found -1 6.1~rc3-1~exp1 Control: found -1 6.1.55-1 On Saturday, 4 November 2023 20:35:43 CET Jose M Calhariz wrote: > > Ok. Please test (when you have time) 6.1.55-1. > > Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux > > Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 > (2023-09-29) x86_64 GNU/Linux > > Done. I tested even the first 6.1 on Debian. Both of them failed. Thanks, updated metadata accordingly. So now we know it's indeed present in the whole 6.1 series. > > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and > > thus not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be > > useful. Please test with with 6.3.1-1~exp1 to make sure it was fixed then (too). Unfortunately, the commit list between 6.1 and 6.3.1 is quite large: me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1..v6.3.1 -- fs/xfs | wc -l 159 If that list was small, I could've suggested to try 'backporting' a couple of patches, but that avenue seems rather pointless in this case. It's probably also useful to verify whether it's also present in the whole 5.10 series, which should give (even) more data points. I think the next step should be to 'forward' this bug report to the upstream mailing list at linux-...@vger.kernel.org signature.asc Description: This is a digitally signed message part.
