Bug#1029816: wifi: mt76: mt7612u/mt7610u - 6.1.x hard locking systems

[Stuart Read]

Source: linux
Version: 6.1.4-1
Severity: important

Dear Maintainer,

My Netgear A6210 (Mediatek MT7612U) hard locks the system on login. If I 
instead log in via console,
the first network access (such as ping) results in a kernel panic.

I found this upstream bug report: 
http://lists.infradead.org/pipermail/linux-mediatek/2022-December/054010.html

However it is unclear to me if or when the fix will be applied to the kernel.

Best,
Stuart

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Moving firmware packages from non-free to non-free-firmware

[Cyril Brulebois]

Hi,

Here's an update regarding firmware packages vs. non-free-firmware. I'm
extending the list of recipients a little; feel free to let me know if
you spot packages/teams that I would have missed!

Cyril Brulebois  (2023-01-17):
> For this first round, I've checked on amd64/unstable which packages
> ship files under /lib/firmware, then excluded some of them, and worked
> on the rest. (I'll need to check other archs for possible arch-specific
> firmware packages, but I must confess our current thinking is making
> the random joe/jane user experience on x86 systems as easy as possible,
> then care about less obvious targets later.)

Different approach: downloading all non-free/binary-/Packages,
grepping for “firmware” or “microcode” in the package name, without
filtering on package contents.

 - nvidia-tesla-470-kernel-support disappears, as it doesn't match the
   package name pattern I selected, even if it ships /lib/firmware/;
 - ixp4xx-microcode shows up, armel-only;
 - midisport-firmware shows up, as it matches the package name pattern,
   and didn't before because /usr/share/usb/maudio/ is where firmware
   files are shipped.

To dot my i's and cross my t's, I iterated on non-free/Contents-,
looked for lib/firmware, and I found no other packages.

With some packages having moved to non-free-firmware migrating to testing,
users or developers have started noticing packages seemingly disappearing
from the archive. Thinking about the documentation aspect, I suppose it
would make sense to have *all* firmware packages move to non-free-firmware
which would be the place to find non-free firmware, regardless of the
list of packages that we determined to be interesting for the installer
(my initial mail).

Efforts to do that aren't much bigger than what's going on already:
 - for debian-installer and debian-cd, that should only mean maintaining
   a little list of packages that we want to allow/block on installation
   images;
 - ixp4xx-microcode could probably be removed entirely (#1029814);
 - midisport-firmware now has a trivial MR:

https://salsa.debian.org/multimedia-team/midisport-firmware/-/merge_requests/1

> So far I've excluded:
>  - libfishcamp1 and libsbig4 since those are library packages that
>also happen to ship some hexdumps; I don't think they would qualify
>for non-free-firmware (maybe if the hexdumps would be split out in
>their own packages, but I'm not sure that's worth it).

As long as library and firmware are shipped together, keeping packages
in non-free is probably best.

>  - firmware-nvidia-gsp, firmware-nvidia-tesla-gsp, and
>nvidia-tesla-470-kernel-support, from nvidia-graphics-drivers*
>source packages; it's been a while since my X days, but I don't
>think firmware packages would be useful on their own, one would
>need to install/build X drivers from non-free as well?

Regardless of the discussion below my initial mail, those packages can
move to non-free-firmware just like all the others.

Current state for the initial list of packages:
>  - amd64-microcode
>  - intel-microcode (and iucode-tool)

No changes. Those are not a blocker for the next d-i release though. See
#1029804 for a discussion about whether to install them automatically once
we have them there.

>  - atmel-firmware
>  - firmware-ast
>  - firmware-sof
>  - rtl8723bt-firmware

Moved to non-free-firmware, and migrated to testing.

Thank you, maintainers!

>  - bluez-firmware
>  - dahdi-firmware
>  - firmware-nonfree

I've uploaded those a few hours ago, currently in NEW. firmware-nonfree
is a blocker for the next d-i release.

>  - zd1211-firmware

This one looks like a weird state, I've added some comments in the MR:
  https://salsa.debian.org/debian/zd1211-firmware/-/merge_requests/1

I don't plan on uploading it without learning more about it; I won't
consider it a blocker for the next d-i release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Request to cherry picking a patch to fix bug #989705 for kernels 5.10.y

[Diederik de Haas]

On Friday, 27 January 2023 21:05:47 CET Computer Enthusiastic wrote:
> This patch [2] applies to kernel version 5.10.y, too. I used it with a
> custom built kernel since it was published .
> 
> The author of the patch acknowledged that the patch applies to kernel
> version 5.10.y asking me to send it out to the stable mailing list. I
> did it, but I did not receive an answer. I tried to peek upstream, but
> again no answer.

I noticed in [2] this: "Cc: sta...@vger.kernel.org # v5.15+"

The post on marc.info (try to use lore.kernel.org links as that works easier 
for most people) seems to be posted to the 'linux-kernel' list, which I 
*think* is not the same as 'sta...@vger.kernel.org'.

So I would suggest to try again by sending it to stable.vger.k.o with explicit 
mention of kernel 5.10.
GKH is a busy man so I recommend to take your time to construct an email which 
is as short as possible, but still contains all the info needed to evaluate 
the request.

I would recommend to mention the following things:

Commit ID in 5.15 = 3640cdccbe75b8922e5bfc0191dd37e3aaa24833

Link to post in which the patch author said they'd ACK it for 5.10:
https://lore.kernel.org/all/caco55tv0jo2tmuwcwfiauqb-__dzvwhv7wnn9mfgmxv053g...@mail.gmail.com/

In your mail make sure the link doesn't break over 2 lines like it does above.

HTH,
  Diederik
> ---
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h
> =v6.0-rc5=6b04ce966a738ecdd9294c9593e48513c0dc90aa



signature.asc
Description: This is a digitally signed message part.

Bug#1029755: "sh: 1: xed: not found" when listing samples with assembler

[Salvatore Bonaccorso]

Hi Philipp,

On Fri, Jan 27, 2023 at 08:31:02AM +0100, Philipp Marek wrote:
> Package: linux-perf
> Version: 6.1.7-1
> Severity: minor
> File: /usr/bin/perf
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> I've written a trace with "perf record"; when viewing via "perf report"
> it I zoom into a function and choose
> Show individual samples with assembler
> 
> But that gives me just an error message:
> 
> sh: 1: xed: not found
> (END)
> 
> Sadly https://packages.debian.org/search?searchon=contents=xed
> doesn't show any package with a binary of that name...

xed is not packaged in Debian indeed, and there is no ITP or RFP. But
see the description in
https://manpages.debian.org/unstable/linux-perf/perf-intel-pt.1.en.html#XED

Not sure if this really should be kept open as bug for linux-perf.

Regards,
Salvatore

Bug#1029709: linux-image-6.1.0-1-amd64: failed to start Load Kernel Modules

[Salvatore Bonaccorso]

Hi,

On Thu, Jan 26, 2023 at 02:41:02PM -0500, Rex Abert wrote:
> Might be the same issue.  I simply did an upgrade in bookworm, kernel was
> upgraded from 6.0 ->6.1.  On reboot, nvidia driver was not working.  Noticed
> the message during boot:
> 
> failed to start Load Kernel Modules

Might you be still be able to access the installation/upgrade log from
apt, to get more information? Have a look at /var/log/apt/term.log*
files for the respective date of the update.

Thanks already, this will help us pin point the issue further.

Regards,
Salvatore

Request to cherry picking a patch to fix bug #989705 for kernels 5.10.y

[Computer Enthusiastic]

Hello,

The bug #989705 [1] is currently closed. It was solved for kernels 
version 5.15+ using the patch [2] from upstream.


This patch [2] applies to kernel version 5.10.y, too. I used it with a 
custom built kernel since it was published .


The author of the patch acknowledged that the patch applies to kernel 
version 5.10.y asking me to send it out to the stable mailing list. I 
did it, but I did not receive an answer. I tried to peek upstream, but 
again no answer.


Therefore, I'm sending this post to ask the debian-kernel mailing list 
if it is possibile to cherry pick the patch [1] to make it land in the 
next release of Debian Kernel 5.10.y.


Let me know if I can help in any way. I cannot update bug #989705 
because it is currently closed.


Thanks in advance for your attention.

---
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc5=6b04ce966a738ecdd9294c9593e48513c0dc90aa

firmware-nonfree_20221214-5_amd64.changes is NEW

[Debian FTP Masters]

binary:firmware-amd-graphics is NEW.
binary:firmware-atheros is NEW.
binary:firmware-bnx2 is NEW.
binary:firmware-bnx2x is NEW.
binary:firmware-brcm80211 is NEW.
binary:firmware-cavium is NEW.
binary:firmware-intel-sound is NEW.
binary:firmware-ipw2x00 is NEW.
binary:firmware-ivtv is NEW.
binary:firmware-iwlwifi is NEW.
binary:firmware-libertas is NEW.
binary:firmware-linux is NEW.
binary:firmware-linux-nonfree is NEW.
binary:firmware-misc-nonfree is NEW.
binary:firmware-myricom is NEW.
binary:firmware-netronome is NEW.
binary:firmware-netxen is NEW.
binary:firmware-qcom-media is NEW.
binary:firmware-qcom-soc is NEW.
binary:firmware-qlogic is NEW.
binary:firmware-realtek is NEW.
binary:firmware-samsung is NEW.
binary:firmware-siano is NEW.
binary:firmware-ti-connectivity is NEW.
binary:firmware-amd-graphics is NEW.
binary:firmware-atheros is NEW.
binary:firmware-bnx2 is NEW.
binary:firmware-bnx2x is NEW.
binary:firmware-brcm80211 is NEW.
binary:firmware-cavium is NEW.
binary:firmware-intel-sound is NEW.
binary:firmware-ipw2x00 is NEW.
binary:firmware-ivtv is NEW.
binary:firmware-iwlwifi is NEW.
binary:firmware-libertas is NEW.
binary:firmware-linux-nonfree is NEW.
binary:firmware-linux is NEW.
binary:firmware-misc-nonfree is NEW.
binary:firmware-myricom is NEW.
binary:firmware-netronome is NEW.
binary:firmware-netxen is NEW.
binary:firmware-qcom-media is NEW.
binary:firmware-qcom-soc is NEW.
binary:firmware-qlogic is NEW.
binary:firmware-realtek is NEW.
binary:firmware-samsung is NEW.
binary:firmware-siano is NEW.
binary:firmware-ti-connectivity is NEW.
source:firmware-nonfree is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

Re: Processing of firmware-nonfree_20221214-5_amd64.changes

[Cyril Brulebois]

Debian FTP Masters  (2023-01-27):
> firmware-nonfree_20221214-5_amd64.changes uploaded successfully to localhost
> along with the files:
>   firmware-nonfree_20221214-5.dsc
>   firmware-nonfree_20221214-5.debian.tar.xz
>   firmware-amd-graphics_20221214-5_all.deb
>   firmware-atheros_20221214-5_all.deb
>   firmware-bnx2_20221214-5_all.deb
>   firmware-bnx2x_20221214-5_all.deb
>   firmware-brcm80211_20221214-5_all.deb
>   firmware-cavium_20221214-5_all.deb
>   firmware-intel-sound_20221214-5_all.deb
>   firmware-ipw2x00_20221214-5_all.deb
>   firmware-ivtv_20221214-5_all.deb
>   firmware-iwlwifi_20221214-5_all.deb
>   firmware-libertas_20221214-5_all.deb
>   firmware-linux-nonfree_20221214-5_all.deb
>   firmware-linux_20221214-5_all.deb
>   firmware-misc-nonfree_20221214-5_all.deb
>   firmware-myricom_20221214-5_all.deb
>   firmware-netronome_20221214-5_all.deb
>   firmware-netxen_20221214-5_all.deb
>   firmware-nonfree_20221214-5_amd64.buildinfo
>   firmware-qcom-media_20221214-5_all.deb
>   firmware-qcom-soc_20221214-5_all.deb
>   firmware-qlogic_20221214-5_all.deb
>   firmware-realtek_20221214-5_all.deb
>   firmware-samsung_20221214-5_all.deb
>   firmware-siano_20221214-5_all.deb
>   firmware-ti-connectivity_20221214-5_all.deb

ACKed by waldi on IRC, master and debian/20221214-5 tag available from:
  https://salsa.debian.org/kibi/firmware-nonfree/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processing of firmware-nonfree_20221214-5_amd64.changes

[Debian FTP Masters]

firmware-nonfree_20221214-5_amd64.changes uploaded successfully to localhost
along with the files:
  firmware-nonfree_20221214-5.dsc
  firmware-nonfree_20221214-5.debian.tar.xz
  firmware-amd-graphics_20221214-5_all.deb
  firmware-atheros_20221214-5_all.deb
  firmware-bnx2_20221214-5_all.deb
  firmware-bnx2x_20221214-5_all.deb
  firmware-brcm80211_20221214-5_all.deb
  firmware-cavium_20221214-5_all.deb
  firmware-intel-sound_20221214-5_all.deb
  firmware-ipw2x00_20221214-5_all.deb
  firmware-ivtv_20221214-5_all.deb
  firmware-iwlwifi_20221214-5_all.deb
  firmware-libertas_20221214-5_all.deb
  firmware-linux-nonfree_20221214-5_all.deb
  firmware-linux_20221214-5_all.deb
  firmware-misc-nonfree_20221214-5_all.deb
  firmware-myricom_20221214-5_all.deb
  firmware-netronome_20221214-5_all.deb
  firmware-netxen_20221214-5_all.deb
  firmware-nonfree_20221214-5_amd64.buildinfo
  firmware-qcom-media_20221214-5_all.deb
  firmware-qcom-soc_20221214-5_all.deb
  firmware-qlogic_20221214-5_all.deb
  firmware-realtek_20221214-5_all.deb
  firmware-samsung_20221214-5_all.deb
  firmware-siano_20221214-5_all.deb
  firmware-ti-connectivity_20221214-5_all.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found

[Mark Brown]

On Fri, Jan 27, 2023 at 12:37:35PM -0600, Rob Herring wrote:

> Looks to me like we are leaking 'r' with this change.

Oh, probably now that you mention it.  Usually the OF code keeps
track of more things than I expect...

> Wouldn't this change work:

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index c34ac33b7338..f43311f01c32 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -968,6 +968,11 @@ int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map)
> for_each_of_range(, )
> num_ranges++;
> 
> +   if (!num_ranges) {
> +   ret = -EINVAL;
> +   goto out;
> +   }
> +

Not as-is, there is a range counted by that first loop but it's
then rejected by the check in the second loop for cpu_addr ==
OF_BAD_ADDR.  We'd need to add a similar check in the first loop.
It should work otherwise though and avoids doing the allocation
in this case.


signature.asc
Description: PGP signature

Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found

[Rob Herring]

On Thu, Jan 26, 2023 at 10:27 AM Mark Brown  wrote:
>
> Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
> converted the parsing of dma-range properties to use code shared with the
> PCI range parser. The intent was to introduce no functional changes however
> in the case where we fail to translate the first resource instead of
> returning -EINVAL the new code we return 0. Restore the previous behaviour
> by returning an error if we find no valid ranges, the original code only
> handled the first range but subsequently support for parsing all supplied
> ranges was added.
>
> This avoids confusing code using the parsed ranges which doesn't expect to
> successfully parse ranges but have only a list terminator returned, this
> fixes breakage with so far as I can tell all DMA for on SoC devices on the
> Socionext Synquacer platform which has a firmware supplied DT. A bisect
> identified the original conversion as triggering the issues there.

Looks like maybe it was fixed by Colin in commit f49c7faf776f
("of/address: check for invalid range.cpu_addr") as that commit refers
to Synquacer. But then was it possibly reintroduced by commit
e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting
dma_pfn_offset")?

> Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
> Signed-off-by: Mark Brown 
> Cc: Luca Di Stefano 
> Cc: 993...@bugs.debian.org
> Cc: sta...@kernel.org
> ---
>  drivers/of/address.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index c34ac33b7338..21342223b8e5 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -975,10 +975,12 @@ int of_dma_get_range(struct device_node *np, const 
> struct bus_dma_region **map)
> }
>
> /*
> -* Record all info in the generic DMA ranges array for struct device.
> +* Record all info in the generic DMA ranges array for struct device,
> +* returning an error if we don't find any parsable ranges.
>  */
> *map = r;
> of_dma_range_parser_init(, node);
> +   ret = -EINVAL;

Looks to me like we are leaking 'r' with this change.

Wouldn't this change work:

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..f43311f01c32 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -968,6 +968,11 @@ int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
for_each_of_range(, )
num_ranges++;

+   if (!num_ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
+
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
ret = -ENOMEM;

Processed: Re: Bug#1024831: Acknowledgement (xorg: xserver fails to resume after suspend-to-disk)

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #1024831 [src:linux] xorg: xserver fails to resume after suspend-to-disk
Added tag(s) moreinfo.

-- 
1024831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024831
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1024831: Acknowledgement (xorg: xserver fails to resume after suspend-to-disk)

[Diederik de Haas]

Control: tag -1 moreinfo

On 26 Nov 2022 20:31:25 +0100 Klaus Singvogel  wrote:
> This issue only happens only with linux-image-6.0.0-0.deb11.2-amd64
> After I booted the old linux-image-5.19.0-0.deb11.2-amd64, the issue does
> not occur.

Does this issue still occur with version 6.0.12-1~bpo11+1 which I guess is 
linux-image-6.0.0-0.deb11.6-amd64?

signature.asc
Description: This is a digitally signed message part.

Processed: Submitter says this was caused by a kernel upgrade

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1024831 src:linux 6.0.3-1
Bug #1024831 [xorg] xorg: xserver fails to resume after suspend-to-disk
Bug reassigned from package 'xorg' to 'src:linux'.
No longer marked as found in versions xorg/1:7.7+22.
Ignoring request to alter fixed versions of bug #1024831 to the same values 
previously set
Bug #1024831 [src:linux] xorg: xserver fails to resume after suspend-to-disk
Marked as found in versions linux/6.0.3-1.
> affects 1024831 linux-image-6.0.0-0.deb11.2-amd64 xserver-xorg-core xorg
Bug #1024831 [src:linux] xorg: xserver fails to resume after suspend-to-disk
Added indication that 1024831 affects linux-image-6.0.0-0.deb11.2-amd64, 
xserver-xorg-core, and xorg
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1024831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024831
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems