Bug#984909: linux-image-5.10.0-0.bpo.3-amd64: Kernel 5.10 have regression which breaks Kodi play from NFS share
Package: src:linux Version: 5.10.13-1~bpo10+1 Severity: normal Dear Maintainer, Please include this fix to new package version: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.15=8e081627f3a7f733a4955ee40b385c972f010f05 Wihout this Kodi on RPi cannot play media shared ovre NFS Regards Dan Smolik -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: Z170-D3H product_version: To be filled by O.E.M. chassis_vendor: To Be Filled By O.E.M. chassis_version: To Be Filled By O.E.M. bios_vendor: American Megatrends Inc. bios_version: F2 board_vendor: Gigabyte Technology Co., Ltd. board_name: Z170-D3H-CF board_version: x.x ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.3.13 netmask 255.255.255.0 gateway 192.168.3.1 dns-nameservers 192.168.3.1 iface eth0:1 inet static address 192.168.0.100 netmask 255.255.255.0 iface eth0:2 inet static address 192.168.1.100 netmask 255.255.255.0 iface eth0:3 inet static address 192.168.150.10 netmask 255.255.255.0 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:191f] (rev 07) Subsystem: Gigabyte Technology Co., Ltd Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [1458:5000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI]) Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [1458:5007] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-H Thermal subsystem [8086:a131] (rev 31) Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series Chipset Family Thermal Subsystem [1458:] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME HECI #1 [8086:a13a] (rev 31) Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series Chipset Family MEI Controller [1458:1c3a] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] [8086:a102] (rev 31) (prog-if 01 [AHCI 1.0]) Subsystem: Gigabyte Technology Co., Ltd Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] [1458:b005] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ahci Kernel modules: ahci 00:1b.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Root Port #17 [8086:a167] (rev f1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1b.2 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Root Port #19 [8086:a169] (rev f1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF-
Re: please consider disabling obsolete crypto in 5.10 and later
On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel wrote: > > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso wrote: > > > > Hi Ard, > > > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote: > > > Hi Ard, > > > > > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > > > L.S., > > > > > > > > This is a request to consider disabling obsolete crypto in 5.10 and > > > > later Debian builds of the Linux kernel on any architecture. > > > > > > > > We are all familiar with the rigid rules when it comes to not breaking > > > > userspace by making changes to the kernel, but this rule only takes > > > > effect when anybody notices, and so I am proposing disabling some code > > > > downstream before removing it entirely. > > > > > > > > 5.10 introduces a new Kconfig symbol > > > > > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE > > > > > > > > which is enabled by default, but depends on support for the AF_ALG > > > > socket API being enabled. In turn, block ciphers that are obsolete and > > > > unlikely to be used anywhere have been made to depend on this new > > > > symbol. > > > > > > > > This means that these obsolete block ciphers will disappear entirely > > > > when the AF_ALG socket API is omitted, but we can get rid of these > > > > block ciphers explicitly too, by not setting the new symbol. I.e., > > > > adding > > > > > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set > > > > > > > > to the kernel configs. Note that Fedora have already done so in release > > > > 33 [0] > > > > > > > > The block ciphers in question are RC4, Khazad, SEED, and > > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known > > > > to be used via the socket API (although a change was applied to > > > > iwd/libell recently to get rid of an occurrence of RC4 - this change > > > > has already been pulled into bullseye afaik) > > > > > > > > Note that this is not a statement on whether these algorithms are > > > > secure or not -there is simply no point in carrying and shipping code > > > > that nobody uses or audits, but which can be autoloaded and exercised > > > > via an unprivileged interface. > > > > > > FTR (posteriori), we tried that in > > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737 > > > (and is in the 5.10.12-1 upload to unstable). > > > > There were two reports which might be in the end related to that > > change: > > > > https://bugs.debian.org/979764 > > https://bugs.debian.org/983508 > > > > We have long that nfs-utils need to be updated, but the version was so > > outdated, that progress on updating to a newer version stalled, and > > could not be done in time for bulleye. Once bullseye is released I > > guess this really needs to be prioritzed in some way. > > > > Ard, have you any insight in the above, so, should we revert the above > > change for bullseye again? > > > > Hello Salvatore, > > I think the issue is the patch below. Having something that requires > RC4 and MD5 for security is an absolute joke in 2021, so I won't > recommend you reverting it. Instead, you should really fix nfs-utils > with priority. > Any updates on this?
nfs-utils_1.3.4-5_sourceonly.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 09 Mar 2021 17:17:42 +0100 Source: nfs-utils Architecture: source Version: 1:1.3.4-5 Distribution: unstable Urgency: medium Maintainer: Debian kernel team Changed-By: Salvatore Bonaccorso Closes: 846950 Changes: nfs-utils (1:1.3.4-5) unstable; urgency=medium . [ Felix Lechner ] * Propagate $RPCGSSDOPTS from /etc/default/nfs-common to the system service script for rpc-gssd. (Closes: #846950) Checksums-Sha1: 5012ccad3266ffcdc4a55d99e0075f98ac3828d5 2448 nfs-utils_1.3.4-5.dsc 7f770a1d345686bd1b71eb52372c431d48b983ef 51176 nfs-utils_1.3.4-5.debian.tar.xz Checksums-Sha256: 110e095f85f6dfcb61141faf944db9ddcff42ff611f3eb8b05e948d17c1acbbe 2448 nfs-utils_1.3.4-5.dsc 48112dfde4aab0dfff65cb307575b1d5b97fc532edc495c64d37dcec5eccac81 51176 nfs-utils_1.3.4-5.debian.tar.xz Files: 1d0f7c85991d36d78c0505074a785d16 2448 net optional nfs-utils_1.3.4-5.dsc c41d41072d62e477a565f72cf237f53f 51176 net optional nfs-utils_1.3.4-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmBHoLZfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk ZWJpYW4ub3JnAAoJEAVMuPMTQ89EB08P/3tWvAgzWw4htSGi6mlgiXsCAQ/IRvrX ZnNvwXQCu6s9QQ20tJHLE3Pq9BGKyup4q6riL+eUgO8tJw3EUkvB33SaeUsHCnBO 0hBdRC5og+S5Acn2R/+exabpBPMjxiNkTfiZsvCwaf+MW6uTgvxq6AToi/KP2dau W1wCYJ4eFgM711O2Aaw7EiEXK1/qBpueXZJMV+y67BJpn1uZwXUo48PLSLQ92Piw L3zQ8781gfGXKenkKoHRIm+LbUdtWDHty9SW9muNS4l10OAYABMAWIUsyOyr70dZ vgcpfsxpDQhS5EcLAO23aDPsuttXJpG3KRrDdO9G94RmS/LB0hVwQhBZ3bRtE+Cu NyBUeOJYhoTpk01I2dC72QSwcB4WVTvcTGp5Q6JyxBJFNSGSEZCd2LbPf1Xjqk2l sLYysxyyfyiEE75JCTmQAHKgZW3gVv5Ukm+xZx+bIqO+LFIhAbDSH4EiRFDmwC3q +fkoOmxQKC7seVTeKqLQJ2UoV7Bd0XcfIa4dOUqQx3kBnRRvIxsEoEOXX4lX/ycd OdcOlqoy1yP8WYMoYqnxFCU3iFvMuOetQu7OEOKT5gb/CGyd/VXsb5iPf/dhWsEp fkTJyKRXGWOM0UJeDoNItkyPttSh6QW8t+CgKWWyOaUPUwNOr2BsyUJ7W6RqVFtm 1bSrPy/Y0TXs =Ym4E -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of nfs-utils_1.3.4-5_sourceonly.changes
nfs-utils_1.3.4-5_sourceonly.changes uploaded successfully to localhost along with the files: nfs-utils_1.3.4-5.dsc nfs-utils_1.3.4-5.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#846950: marked as done (nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils)
Your message dated Tue, 09 Mar 2021 16:33:25 +
with message-id
and subject line Bug#846950: fixed in nfs-utils 1:1.3.4-5
has caused the Debian Bug report #846950,
regarding nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
846950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846950
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-common
Version: 1:1.2.8-9.2
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
even though RPCGSSDOPTS is not documented or explicitly exposed in
/etc/default/nfs-common, it’s used by the init script and I have been
relying on it for a while. After switching to nfs-common -9.2 with the
supplied systemd unit files I found RPCGSSDOPTS from rpc.gssd’s command
line, since it’s not replicated by
/usr/lib/systemd/scripts/nfs-utils_env.sh to /run/sysconfig/nfs-utils.
Would it possible to add
echo RPCGSSDARGS=\"${RPCGSSDOPTS:-}\"
to the nfs-utils_env.sh script?
Thanks!
Sebastian
- -- Package-specific info:
- -- rpcinfo --
program vers proto port service
104 tcp111 portmapper
103 tcp111 portmapper
102 tcp111 portmapper
104 udp111 portmapper
103 udp111 portmapper
102 udp111 portmapper
- -- /etc/default/nfs-common --
If you do not set values for the NEED_ options, they will be attempted
NEED_STATD=no
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes
RPCGSSDOPTS="-vvv"
- -- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = yath.de
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
- -- /etc/fstab --
fate.yath.de:/data /fate nfs
noauto,x-systemd.automount,x-systemd.idle-timeout=600,x-systemd.device-timeout=10,_netdev,user,vers=4,sec=krb5p,nofail
- -- /proc/mounts --
- -- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.4+ (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages nfs-common depends on:
ii adduser 3.115
ii init-system-helpers 1.45
ii keyutils 1.5.9-9
ii libc62.24-5
ii libcap2 1:2.25-1
ii libcomerr2 1.43.3-1
ii libdevmapper1.02.1 2:1.02.133-1
ii libevent-2.0-5 2.0.21-stable-2.1
ii libgssapi-krb5-2 1.15~beta1-1
ii libk5crypto3 1.15~beta1-1
ii libkeyutils1 1.5.9-9
ii libkrb5-31.15~beta1-1
ii libmount12.28.2-1
ii libnfsidmap2 0.25-5
ii libtirpc10.2.5-1
ii libwrap0 7.6.q-25
ii lsb-base 9.20161101
ii rpcbind 0.2.3-0.5
ii ucf 3.0036
Versions of packages nfs-common recommends:
ii python 2.7.11-2
Versions of packages nfs-common suggests:
ii open-iscsi 2.0.874-1
pn watchdog
- -- Configuration Files:
/etc/default/nfs-common changed [not included]
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQIcBAEBCAAGBQJYRDCbAAoJEPhx3EthBlqje+cP/2TJvoZZizZ0MsOsIvYA9A0L
GoE46tm4TN8w08BSWhgDt4mH7fT8GGLIuc3qNB7Ue3+4f9ytsp/22xFaBPDF5585
9vRtrlghRgYbHKxBmzonf1LTYzoJCeRTV/njIT/AXnHponKWihZF9drcfr5TLDJR
vqbE1jvx4cvo/O/6hL+JAlPDP+tjVhlz1pW6Y5KufW9PAYgCsSUXAvEc38gwJ86R
Gmp+fub210NeWOQNUOuAVtoKBNfpBUtoFs5wW7pxe7hPoz3icEqX1ZyyB0Fxky2L
LcjfbBY1WpdgbcTHUxYmt/QJxfDUKZgfJrCdLe/qtVjnvdXk2eWqGTNk8cyL0Mwq
2NfLpdQaVP61imunKgGUZ56t5hevqbdyagY/DxIGR9dRtGb4ZjV5PJKP6MsckLdL
hAyTM7wPv5EFGucq1EbNzeG3VXFqyFKSBT8MS+zwi0TuVKSkx3QqZH8XvPAwOXeZ
+IzcQgf60L2148JqShGSenxZoBLpirFvmkFGnzDJSmFmluMGCVuci1F2spGZU2JR
fdWRuFJWvd7rOpcftDgHfxn2ojE9RuAE80Yqz1tJX45SI0rGm0ShgQvkQSYmfh7X
ac9UM1bm4RQTvr6SCmUkwKZ+g07T3+lenAG1gcbIO8snJpnx5BOGcFajY7vdMN/U
ohVaW/Idw4AlRvZ2giec
=VlIm
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Source: nfs-utils
Source-Version: 1:1.3.4-5
Done: Salvatore Bonaccorso
We believe that the bug you reported is fixed in the latest version of
nfs-utils, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 846...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian
Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)
On dinsdag 9 maart 2021 15:17:01 CET Jan Huijsmans wrote: > Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64 > resulted in a non-booting system due to missing/incorrect USB support > for the RPi4 8GB. (system has / on USB SSD) > > Only method to get the system booting again is to change config.txt to > boot the available 5.9.0-4 kernel. System came up as expected. > > With the 5.10 kernels I tested (-3 and -4 packages) the boot halted > after detecting the partitions on mmcblk1 , on 5.9.0-4 it continues > to detect the storange via USB and boots from it. This is possibly a duplicate of bug #977694 and a possible solution can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694#67 Could you try whether that fixes it for you too? signature.asc Description: This is a digitally signed message part.
Bug#984874: Upgrading via apt-get results in module amdgpu 'possible missing firmware' errors
Package: firmware-amd-graphics Version: 20210208-3 Severity: minor Upgrading the system via apt-get upgrade results in 'missing firmware' errors linked to the module amdgpu. There is no obvious impact on performance of the machine / graphics on my system. GPU is AMD Radeon 540X. I am using Debian Bullseye, kernel 5.10.0-3-amd64. Output from apt below: update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64 W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_sos.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_asd.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_sdma.bin for module amdgpu 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 W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_smc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_dmcub.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_dmcub.bin for module amdgpu
Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")
On 3/9/21 5:31 PM, maximilian attems wrote: > >> the display stopped updating as soon as amdgpu took over, and it never came >> back. >> The firmware is needed of course, and as a side note, it could be nice if >> the kernel could fail more gracefully, somehow bringing the display back (it >> works fine with amdgpu blacklisted, just no acceleration) such that it takes >> me less than two days to figure it all out. > this is a linux bug, you might want to submit it upstream to AMD guys. Yea, I actually wasn't sure if this would be regarded as such, thanks for the encouragement. I'll look that up. >> The relevant files are amdgpu/green_sardine_* > right, they only got pushed upstream in linux-firmware git on 11/2/2021 > after the latest 20210208 release, hence unfortunately they miss out the > next debian release > https://release.debian.org/bullseye/freeze_policy.html > > They will land in the next upstream release upload of 202103XX to > experimental, backports and then after bullseye release to unstable > (plus next testing). > I sure hope it would also end up in some point release? Or maybe a freeze exception could be made? It would be unfortunate if a new computer won't be usable (without backports) on stable Debian which is to be finally released presumably several months after the computer hit the market, for want of a rather minor fix.
Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)
Package: src:linux Version: 5.10.19-1 Severity: critical Justification: breaks the whole system Dear Maintainer, Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64 resulted in a non-booting system due to missing/incorrect USB support for the RPi4 8GB. (system has / on USB SSD) Only method to get the system booting again is to change config.txt to boot the available 5.9.0-4 kernel. System came up as expected. With the 5.10 kernels I tested (-3 and -4 packages) the boot halted after detecting the partitions on mmcblk1 , on 5.9.0-4 it continues to detect the storange via USB and boots from it. Regards, Jan Huijsmans -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information Device Tree model: Raspberry Pi 4 Model B Rev 1.4 ** PCI devices: not available ** USB devices: Bus 002 Device 002: ID 0578:0578 Intrinsix Corp. KingSpec Z3-128 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 413c:2003 Dell Computer Corp. Keyboard SK-8115 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (1001, 'testing'), (100, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.9.0-4-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.ISO8859-15, LC_CTYPE=en_US.ISO8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO8859-15), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-4-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.139 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-4-arm64 recommends: ii apparmor 2.13.6-9 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-4-arm64 suggests: pn debian-kernel-handbook pn linux-doc-5.10 Versions of packages linux-image-5.10.0-4-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120210208-3 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")
On dinsdag 9 maart 2021 10:31:33 CET maximilian attems wrote: > > I've received my new laptop with a Ryzen R7 5800U ... > > The relevant files are amdgpu/green_sardine_* > > right, they only got pushed upstream in linux-firmware git on 11/2/2021 > after the latest 20210208 release, hence unfortunately they miss out the > next debian release > https://release.debian.org/bullseye/freeze_policy.html I realize that kernel and firmware are not the (exact) same thing, but the impression I got wrt freeze is: - new features: NO - new hardware support: YES It looks to me that this falls in the latter category. The update should only contain the amdgpu/green_sardine_* firmware files and nothing else. A manual unblock is needed ofc, but that can be requested. Maybe the Release Team could clarify this? signature.asc Description: This is a digitally signed message part.
Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")
Package: firmware-amd-graphics Version: 20210208-3 Hi, I've received my new laptop with a Ryzen R7 5800U and the display stopped updating as soon as amdgpu took over, and it never came back. The firmware is needed of course, and as a side note, it could be nice if the kernel could fail more gracefully, somehow bringing the display back (it works fine with amdgpu blacklisted, just no acceleration) such that it takes me less than two days to figure it all out. The relevant files are amdgpu/green_sardine_* Thanks!
Processed: Re: Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")
Processing commands for cont...@bugs.debian.org:
> severity 984852 important
Bug #984852 [firmware-amd-graphics] firmware-amd-graphics: Please add cezanne
("green sardine")
Severity set to 'important' from 'normal'
> tags 984852 pending
Bug #984852 [firmware-amd-graphics] firmware-amd-graphics: Please add cezanne
("green sardine")
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
984852: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984852
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")
severity 984852 important tags 984852 pending thanks > Package: firmware-amd-graphics > Version: 20210208-3 > > I've received my new laptop with a Ryzen R7 5800U and the display stopped > updating as soon as amdgpu took over, and it never came back. > The firmware is needed of course, and as a side note, it could be nice if the > kernel could fail more gracefully, somehow bringing the display back (it > works fine with amdgpu blacklisted, just no acceleration) such that it takes > me less than two days to figure it all out. this is a linux bug, you might want to submit it upstream to AMD guys. > The relevant files are amdgpu/green_sardine_* right, they only got pushed upstream in linux-firmware git on 11/2/2021 after the latest 20210208 release, hence unfortunately they miss out the next debian release https://release.debian.org/bullseye/freeze_policy.html They will land in the next upstream release upload of 202103XX to experimental, backports and then after bullseye release to unstable (plus next testing). Thank you for your report! -- maks signature.asc Description: PGP signature
