Bug#1022806: [SOLVED UPSTREAM?] linux-image-5.10.0-19-amd64: amggpu unbootable problem persists
Control: tags -1 + confirmed pending Hi Cosimo, On Fri, Nov 04, 2022 at 01:32:32AM +0100, Cosimo Agati wrote: > I experienced this problem on a machine with the following > hardware: > > CPU: AMD FX-8350 (8) @ 4.000GHz > GPU: AMD ATI Radeon R7 370 / R9 270/370 OEM > > After bisecting from the 5.10.149 sources, I found that the commit > responsible for this bug was > 867b2b2b6802fb3995a0065fc39e0e7e20d8004d, corresponding to > upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820. > > This commit was reverted already on the 5.10 tree: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=357db159e965efa6a0b7b6f9efa1c34bf876db2d > > Indeed, vanilla Linux 5.10.153, which contains this revert and > which is the currently latest release in the 5.10 branch, seems to > boot properly with the amdgpu driver. > > The Debian package linux-image-5.10.0-19-amd64 is built from > sources corresponding to the upstream release 5.10.149, which did > NOT contain the fix. This seems to explain why many people with > AMD GPUs, myself included, were experiencing problems during boot. > > Since this problem seems to have been fixed upstream, I don’t > think there is anything to do on the Debian side... except of > course packaging the next linux-image package with a Linux source > tree containing these fixes. > > I’m happy to provide more information about this if anyone deems > it necessary. Thanks for doing the bisec and confirming. The revert you mention landed in 5.10.150. The fix will be in the next upload. Regards, Salvatore
Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless
Hi Diederik!
On Thu, Nov 03, 2022 at 12:37:19PM +0100, Diederik de Haas wrote:
> Control: found -1 6.0.5-1
> Control: fixed -1 6.0.6-2
> Control: fixed -1 6.1~rc3-1~exp1
> Control: severity -1 grave
> Control: tag -1 -moreinfo
> Control: tag -1 upstream fixed-upstream
> Control: retitle -1 RPi 0-3 fail to boot on kernel 5.19+ without HDMI
> connected
> Control: forwarded -1
> https://lore.kernel.org/all/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e9622...@cerno.tech/
>
> On Monday, 31 October 2022 00:37:54 CET Diederik de Haas wrote:
> > Control: found -1 5.19.6-1
> > Control: severity -1 important
> > Control: tag -1 moreinfo
> >
> > On 30 Oct 2022 13:24:55 +0100 Jan Huijsmans
> > wrote:
> > > Package: linux-image-5.19.0-1-arm64
> > > Severity: critical
> > > Justification: breaks the whole system
> >
> > Only affecting RPi3 in certain conditions, thus lowering severity.
>
> I was able to reproduce this on a RPi 1, found that is was reported upstream
> here:
> https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak...@pengutronix.de/
>
> and found the patches that were applied upstream in 6.1-rc2 where there were
> 2 commits and saw that 1 commit was backported to the linux-6.0 branch, but
> that seemed sufficient as installing kernel 6.0.6-2 from unstable, fixed the
> issue.
>From the cover letter in the series:
> The first patch will fix this, and the second will make sure we avoid that
> situation entirely in the future. This has been tested with 5.19.12. Earlier
> versions might need a backport of 88110a9f6209 ("clk: bcm2835: fix
> bcm2835_clock_choose_div").
So I think it is safe to consider it fixed in all those versions where
the first patch was applied.
Regards,
Salvatore
Bug#1023329: fix unexpected wakeups with WCN6855
Control: tags -1 + pending Hi Marco, On Wed, Nov 02, 2022 at 02:14:44PM +0100, Marco d'Itri wrote: > Package: src:linux > Version: 6.0.5-1 > Severity: normal > Tags: upstream patch > > As reported on > https://forums.lenovo.com/t5/Other-Linux-Discussions/T14s-G3-AMD-Linux-Sleep/m-p/5172287?page=4, > this patch from ath-next fixes unexpected wakeups on Lenovo hardware > using the Qualcomm Wi-Fi card like my T14s Gen3: > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath11k?h=ath-next=d99884ad9e3673a12879bc2830f6e5a66cccbd78 > > Can you include it in the next 6.0 upload please? I picked the commit for the next upload to unstable (probably for 6.0.7-1 and making an ABI bump so we can resolve the FTBFS on arm64 and armhf currently present). Regards, Salvatore
Bug#1023298: linux: FTBFS on arm64 and armhf (ABI changes)
Source: linux Version: 6.0.6-2 Severity: serious Justification: FTBFS X-Debbugs-Cc: car...@debian.org Documenting the build failures on arm64 and armhf due to ABI changes: https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=6.0.6-2=1667324068=0 https://buildd.debian.org/status/fetch.php?pkg=linux=armhf=6.0.6-2=1667316319=0 Regards, Salvatore
Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)
Hi Vincent, On Tue, Nov 01, 2022 at 02:24:44AM +0100, Vincent Lefevre wrote: > Hi Salvatore, > > On 2022-10-31 22:27:15 +0100, Salvatore Bonaccorso wrote: > > There were no Bluetooth related changes in the relatively small 6.0.3 > > to 6.0.5 update and I cannot reproduce the issue. Can you provide the > > full boot and kernel logs? (ideally from both runs). > > I've attached the journalctl output for the boot: > * journal-6.0.5-1 > * journal-6.0.3-1 after downgrading the kernel. What happens if you downgrade firmware-iwlwifi to 20210818-1? (While the one which your HW needs to load is still present in the binary package there was the removal of old unsupported 3160/7260/7265/8000/8265 firmware which might have an influence). Regards, Salvatore
Uploading linux (6.0.6-1)
Hi I would like to upload linux version 6.0.6-1 to unstable. The update just consits of further importing 6.0.6 upstream. No ABI bump is required. Regards, Salvatore signature.asc Description: PGP signature
Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)
Control: severity -1 important Control: tags -1 + moreinfo Hi Vincent, On Mon, Oct 31, 2022 at 01:09:31PM +0100, Vincent Lefevre wrote: > Package: src:linux > Version: 6.0.5-1 > Severity: grave > Justification: renders package unusable > > (Setting to grave because Bluetooth is a major component.) > > Bluetooth no longer works at all. > > zira:~> journalctl -b -g bluetooth > Oct 31 12:55:16 zira kernel: Bluetooth: Core ver 2.22 > Oct 31 12:55:16 zira kernel: NET: Registered PF_BLUETOOTH protocol family > Oct 31 12:55:16 zira kernel: Bluetooth: HCI device and connection manager > initialized > Oct 31 12:55:16 zira kernel: Bluetooth: HCI socket layer initialized > Oct 31 12:55:16 zira kernel: Bluetooth: L2CAP socket layer initialized > Oct 31 12:55:16 zira kernel: Bluetooth: SCO socket layer initialized > Oct 31 12:55:17 zira systemd[1]: Starting Bluetooth service... > Oct 31 12:55:17 zira systemd[795]: ConfigurationDirectory 'bluetooth' already > exists but the mode is different. (File system: 755 > ConfigurationDirectoryMode: 555) > Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth daemon 5.65 > Oct 31 12:55:17 zira systemd[1]: Started Bluetooth service. > Oct 31 12:55:17 zira systemd[1]: Reached target Bluetooth Support. > Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth management interface 1.22 > initialized > Oct 31 12:55:17 zira dbus-daemon[801]: [system] Activating via systemd: > service name='org.freedesktop.hostname1' > unit='dbus-org.freedesktop.hostname1.service' requested by ':1.2' (uid=0 > pid=795 comm="/usr/libexec/bluetooth/bluetoothd") > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP filters: protocol multicast > Oct 31 12:55:17 zira kernel: Bluetooth: BNEP socket layer initialized > Oct 31 12:55:17 zira NetworkManager[950]: [1667217317.6273] Loaded > device plugin: NMBluezManager > (/usr/lib/x86_64-linux-gnu/NetworkManager/1.40.2/libnm-device-plugin-bluetooth.so) > Oct 31 12:55:19 zira kernel: Bluetooth: hci0: Reading Intel version command > failed (-110) > Oct 31 12:55:19 zira kernel: Bluetooth: hci0: command 0xfc05 tx timeout > > With the 6.0.3-1 kernel version, I got: > > Oct 31 11:17:59 zira kernel: Bluetooth: Core ver 2.22 > Oct 31 11:17:59 zira kernel: NET: Registered PF_BLUETOOTH protocol family > Oct 31 11:17:59 zira kernel: Bluetooth: HCI device and connection manager > initialized > Oct 31 11:17:59 zira kernel: Bluetooth: HCI socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: L2CAP socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: SCO socket layer initialized > Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Legacy ROM 2.5 revision 8.0 > build 2 week 3 2013 > Oct 31 11:17:59 zira kernel: bluetooth hci0: firmware: direct-loading > firmware intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq > Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Intel Bluetooth firmware file: > intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq > Oct 31 11:17:59 zira systemd[1]: Starting Bluetooth service... > [...] > > So it appears that the 6.0.5-1 kernel version can't load the firmware. There were no Bluetooth related changes in the relatively small 6.0.3 to 6.0.5 update and I cannot reproduce the issue. Can you provide the full boot and kernel logs? (ideally from both runs). Regards, Salvatore
Bug#1023103: linux-image-5.10.0-14-amd64: Wrong power value on APU2 with bullseye
Hi Alexis, On Sun, Oct 30, 2022 at 10:41:12AM +0100, Alexis Domjan wrote: > Hi Salvatore, > > Le 30.10.22 à 10:21, Salvatore Bonaccorso a écrit : > > Control: tags -1 + moreinfo > > Since 5.10.113-1 is already superseeded by several uploads, can you > > confirm the issue you are seeing is still present in the most current > > uploaded version? (5.10.149-2). > > Sorry, indeed, I didn't noticed it wasn't the latest available version of the > kernel. > > After the update, however, the issue is still present with the same symptoms. > > Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux > > Do you need more information ? Thank you for testing. And before 5.10.113 can you pin point to a version in which showed sensible versions? If so you have a starting point to bisect where the problem is introduced which would be very helpfull to determine the pontential issue. Does the issue persist with a more recent kernel (either from backports or from unstable)? Regards, Salvatore
Bug#1023103: linux-image-5.10.0-14-amd64: Wrong power value on APU2 with bullseye
Control: tags -1 + moreinfo Hi Alexis, On Sun, Oct 30, 2022 at 09:47:03AM +0100, Alexis Domjan wrote: > Package: src:linux > Version: 5.10.113-1 > Severity: normal > > Dear Maintainer, > > With bullseye, /sys/class/hwmon/hwmon0/power1_average is wrong > when the system is idle (80-120W on a system whose max is probably > 10); it is correct when the CPU is used. The bug is not present in > buster. With or without amd64 microcode, no change either. Since 5.10.113-1 is already superseeded by several uploads, can you confirm the issue you are seeing is still present in the most current uploaded version? (5.10.149-2). Regards, Salvatore
Bug#1013211: problem is gone
Control: tags -1 + moreinfo On Sun, Oct 30, 2022 at 03:55:46AM +, Douglas Silva wrote: > I can no longer reproduce this. Currently running Ubuntu 22.10 with > kernel 5.19.0-23-generic. C-states enabled in the BIOS. But what about Debian's kernels? Are you able to reproduce your issue still with most recent kernel in unstable? (6.0.5-1). Regards, Salvatore
Re: Bug#1005400: closed by Diederik de Haas (Re: Bug#1005400: firmware-nonfree: Please package AMD SEV firmware.)
Hi, On Sat, Oct 29, 2022 at 10:37:11AM +0200, Diederik de Haas wrote: > On Saturday, 29 October 2022 09:01:49 CEST Salvatore Bonaccorso wrote: > > > They are part of the above version, thus closing. > > > > Actually they are shipped with amd64-microcode instead: > > Indeed. How come it 'still' shows up in firmware-nonfree's build log? > https://buildd.debian.org/status/fetch.php?pkg=firmware-nonfree=all=20220913-1=1666990396=0 > > It was based on that log that I did most/all my recent bug closing. The files are present in the source and copied to debian/build/install . But they are then not installed in any of the produced binary packages in the later install steps for the various binary packages. (see debian/config/*/defines). Does this help? Regards, Salvatore
Re: Proposed changes to linux package
Hi Bastian, On Sun, Oct 23, 2022 at 03:27:24PM +0200, Bastian Blank wrote: > On Sat, Oct 22, 2022 at 11:15:05AM +0200, Bastian Blank wrote: > > On Sat, Oct 22, 2022 at 10:59:30AM +0200, Bastian Blank wrote: > > > I would like to do some last minute changes to the linux package > > # Drop special case use of rcX as abi name > > > > While having the ability to distiguish between different RC, it changes > > the package names every time. > > Or should we just go for 0? This would also remove the ordering > weirdness a lot of people experienced. So instead of having linux-image-6.1.0-rc2-amd64 (for version 6.1~rc2-1~exp1) that would have been linux-image-6.1.0-0-amd64 and so sorting before linux-image-6.1.0-1-amd64 once we go to an unstable upload with ABI 1, correct? Your suggestion sounds like a sensible idea. The distinguishing about the rc releases would be easier if we retain the former variant, but I assume concerns for those experimental targeting uploads is less of an issue. Ben, opinions on it? Regards, Salvatore
Bug#1006500: marked as done (Missing bnx2x firmware 7.13.21.0 renders NIC unusable with Linux 5.16)
Hi, On Sat, Oct 29, 2022 at 12:31:18AM +0200, Christoph Anton Mitterer wrote: > Hey Bastian. > > Thanks for fixing. > > Is this going to be backported to bullseye? We do similar with intel-microcode updates, so maybe this is something we should consider to. But I think it's to early to think about a potential 20220913-1~deb11u1 via a bullseye point release. (just my personal opinion though). Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Hi Christoph, On Sat, Oct 29, 2022 at 12:36:01AM +0200, Christoph Anton Mitterer wrote: > Hey Salvatore. > > On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote: > > I did decide to still do so, so we can have the CVE fix migrate > > finally to testing (which took some time as well given there was the > > perl transition ongoing). > > Fine for me... I think it would be nice if there was a better mechanism > to have bugs shown in apt-listbugs out of the box, while still not > preventing migration to testing. There is one, involving the release team that they can force a specific version. In fact I was offlist in contact with Sebastian Ramacher from the release team who could have done so. In the end the src:linux was able to migrate on the next run, so downgrading the bug severity was the quickest action without need to let a release team emmber intervene. In the end, yes, the cleanest solution, assuming kernel-team considered the bug a RC bug, it would have been the right solution to just ask the release team to force the migration despite of the RC bug. > Oh and another off-topic thing: > > Right now the kernel image meta-packages depend on the (secure boot) > signed version of that... and it seems that these take always longer to > be available than the unsigned ones. > > However, if people want the nice service to have linux-image-amd64 > installed and pull in just the current package, they need to wait for > the signed one to become available - even if they don't use secure boot > at all. > > So question is,.. would it make sense to request that linux-image-amd64 > depends on the signed | unsigned version? No unfortunately we cannot do that. The reason is similar to what lead to https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 or caused bugs like #916927. In meanwhile furthermore linux-image-amd64 is anyway not anymore from a separate metapackage but built from linux-signed-amd64. The signed packages need always longer as this needs action of signing them trough a seprate manual process of ftp-masters. > > I did import already 6.0.5 and will upload next so we get the btrfs > > fix. And I have made the bug now as well again back RC severity. > > Thanks as always for your continued efforts. Thank you for those encouraging words! Salvatore
Bug#1014451: firmware-brcm80211: brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.txt on a Raspberry Pi 4
Hi, On Sat, Oct 29, 2022 at 12:18:16AM +0200, Diederik de Haas wrote: > Control: fixed -1 20220913-1 > > On Wednesday, 6 July 2022 12:46:16 CEST Enrique wrote: > > Package: firmware-brcm80211 > > Version: 20210315-3 > > > > I have installed pure Debian on a Raspberry Pi 4 and the kernel shows > > this error messages at boot: > > > > jul 06 11:57:25 alcatraz kernel: brcmfmac mmc0:0001:1: firmware: failed to > > load brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model > > B.txt (-2) > > This should be resolved with the above mentioned version, uploaded to > unstable. As the bug reported seems to only use Stable, I'm not marking it as > 'done' (yet). I'll leave that up to the maintainer. As a though on it: As the BTS can track multiple versions and mark a bug done in multiple versions in the sense of housekeeping cleanup the bugs it would rather close it (it can be closed a second time if the bug get fixed as well in stable with a respective backported version). Regards, Salvatore
Bug#1005400: closed by Diederik de Haas (Re: Bug#1005400: firmware-nonfree: Please package AMD SEV firmware.)
Hi, > Version: 20220913-1 > > On Saturday, 12 February 2022 21:40:30 CEST Sebastian Andrzej Siewior wrote: > > Version: 20210818-1 > > > > The orig contains already the AMD SEV firmware in the amd folder: > > | $ ls -lh amd > > | 33K Aug 18 13:08 amd_sev_fam17h_model0xh.sbin > > | 43K Aug 18 13:08 amd_sev_fam17h_model3xh.sbin > > > > Could this be please package? I have an AMD box asking for this. > > They are part of the above version, thus closing. Actually they are shipped with amd64-microcode instead: amd64-microcode (3.20220411.1) unstable; urgency=medium * Update package data from linux-firmware 20220411: * New microcode updates from AMD upstream (20220408) (closes: #1006444, #1009333) + New Microcode patches: sig 0x00830f10, patch id 0x08301055, 2022-02-15 sig 0x00a00f10, patch id 0x0a001058, 2022-02-10 sig 0x00a00f11, patch id 0x0a001173, 2022-01-31 sig 0x00a00f12, patch id 0x0a001229, 2022-02-10 + Updated Microcode patches: sig 0x00800f12, patch id 0x0800126e, 2021/11/11 * New AMD-SEV firmware from AMD upstream (20220308) Fixes: CVE-2019-9836 (closes: #970395) + New SEV firmware: Family 17h models 00h-0fh: version 0.17 build 48 Family 17h models 30h-3fh: version 0.24 build 15 Family 19h models 00h-0fh: version 1.51 build 3 * README: update for new release * debian: ship AMD-SEV firmware. Upstream license is the same license used for amd-ucode -- Henrique de Moraes Holschuh Fri, 15 Apr 2022 18:27:36 -0300 and amd64-microcode: /lib/firmware/amd/amd_sev_fam17h_model0xh.sbin amd64-microcode: /lib/firmware/amd/amd_sev_fam17h_model3xh.sbin Regards, Salvatore
Bug#1022823: nfs-kernel-server: /etc/default/nfs-kernel-server needs RPCNFSDOPTS
Source: nfs-common Source-Version: 1:2.6.1-1 Hi Alfredo, On Wed, Oct 26, 2022 at 01:48:58PM +, Alfredo Sola wrote: > Package: nfs-kernel-server > Version: 1:1.3.4-6 > Severity: wishlist > > Dear Maintainer, > > I needed a way to have rpc.nfsd bind to a specific IP address. > > The man page for rpc.nfsd documents a parameter exactly for this, plus some > others. > > At first signt, it seems that there is no Debian way to pass parameters to > rpc.nfsd. > > But there is; RPCNFSDOPTS can be set on /etc/default/nfs-kernel-server. It > will then > be sourced from /usr/lib/systemd/scripts/nfs-utils_env.sh, which sends its > variables > to /run/sysconfig/nfs-utils, from where they are read by nfs-server.service. > > Setting RPCNFSDOPTS solves this issue, so I am suggesting that it be added > (empty) > to /etc/default/nfs-kernel-server, along with a commentary pointing to the > rpc.nfsd > man page for information on parameters. Sincd version 1:2.6.1-1 /etc/nfs.conf settings can be done, or in dropins in /etc/nfs.conf.d/ so closing this bug with that version. Starting there you can set the host= and other parameters in the configuration file in the [nfsd] stanza. Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 serious Hi Christoph, Thanks for the quick feedback! On Thu, Oct 27, 2022 at 09:10:53PM +0200, Christoph Anton Mitterer wrote: > Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso > : > >According to your references there is the workaround of mounting with > >clear_cache,space_cache=v2 and convert the filesystem. > > > >What would one prevent doing so? > > v2 space cache is still rather new and had only recently some bug > that could have caused catastrophic data corruption... so not > everyone might want to switch. > > Similarly, people may want to have these filesystems mounted with > older kernels, whose v2 support isn't that good yet. Thanks, this is very important input. > >I'm downgrading the severity to important as it does not make the > >kernel unbootable or unstable on common hardware or all systems that a > >flavour is supposed to support. > > But now it a) migrates to testing an possibly leaves even more > systems with an unbootable system... b) with severity important, > people using e.g. apr-listbugs won't see it. > > OTOH, fixing the CVE is of course important, too. I did decide to still do so, so we can have the CVE fix migrate finally to testing (which took some time as well given there was the perl transition ongoing). I did import already 6.0.5 and will upload next so we get the btrfs fix. And I have made the bug now as well again back RC severity. Thank you! Regards, Salvatore
Bug#1022806: linux-image-5.10.0-19-amd64: amggpu unbootable problem persists
Hi Alexis, [Cc'ing Alex Deucher who addressed the previous regressions as well] On Wed, Oct 26, 2022 at 12:43:02PM +0200, Alexis Huxley wrote: > Package: src:linux > Version: 5.10.149-2 > Severity: serious > Justification: 1022025, 1022051, 1022062, 1022070, 1022097, 1022147 marked > serious so this marked serious too > > Dear Maintainer, > > Following other reports of post-grub kernel hangs on systems with > amdgpu, I waited for new release of linux-image-5.10.0-19-amd64, > which came quickly, but it did not solve the problem for me. > > Symptoms are: grub loads kernel and a few seconds into the > scrolling messages from the kernel the system hangs. The screen > is blank. The system is not accessible over the network. > > I reverted to linux-image-5.10.0-18-amd64 and all is okay again. > > The crash happens pretty early on: I believe X has not yet tried > to start. Both /var/log/syslog and /var/log/messages contain > no entries pertaining to the hanging boot (only messages from > where the earlier shutdown of 18 and the later start of 18). > > Output from lscpu is below. > > Automatically included output (e.g. kernel version) pertains > to linux-image-5.10.0-18-amd64, as I am unable to boot > linux-image-5.10.0-19-amd64. I don't remove it in case it contains > other pertinent information. > > I'm happy to test with other kernels or provide any requested > files/output. Would you be able to start own kenel builds, confirming it does not happen with 5.10.140 upstream but with 5.10.149, and isolate the breaking change? (Are you able to boot the kernel from bullseye-backports?) Regards, Salvatore
Bug#1022806: Bug#1022025: fixed in linux 5.10.149-2
Hi, On Thu, Oct 27, 2022 at 07:12:43PM +, inasprecali wrote: > On Thu, 27 Oct 2022 21:01:15 +0200 Salvatore Bonaccorso > wrote: > > Can you please fill a new bug for your issue, which would still > > be > > present in the 5.10.149-2 release? There are two users which > > report > > that they still have problems with the amdgpu driver still in > > 5.10.149-2. > > I think bug 1022806 is a recent one referring to 5.10.149-2 > specifically, which is about this same issue. I don't think there > is a need to report yet another bug about it. Yes this is indeed enough. Regards, Salvatore
Bug#1022025: fixed in linux 5.10.149-2
Hi On Thu, Oct 27, 2022 at 05:21:32PM +, inasprecali wrote: > On Thu, 27 Oct 2022 06:17:10 + Debian FTP Masters > wrote: > > Source: linux > > Source-Version: 5.10.149-2 > > Done: Salvatore Bonaccorso > > > > We believe that the bug you reported is fixed in the latest > version of > > linux, which is due to be installed in the Debian FTP archive. > > I'm sorry, but your belief seems to be mistaken, since we have > multiple reports o 5.10.149-2 still not booting with the amdgpu > driver. Can you please fill a new bug for your issue, which would still be present in the 5.10.149-2 release? There are two users which report that they still have problems with the amdgpu driver still in 5.10.149-2. Thanks already, let's folloup there with some questions. Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 important Hi, On Wed, Oct 26, 2022 at 10:23:35PM +0200, Christoph Anton Mitterer wrote: > Source: linux > Version: 5.19.6-1 > Severity: critical > Justification: breaks the whole system > > > Hi. > > 6.0.3 introduced a commit that causes (permanent) CPU soft lockups > for some people with btrfs filesystems, effectively breaking the > system, e.g. when booting. According to your references there is the workaround of mounting with clear_cache,space_cache=v2 and convert the filesystem. What would one prevent doing so? I'm downgrading the severity to important as it does not make the kernel unbootable or unstable on common hardware or all systems that a flavour is supposed to support. While I agree it is important to fix, this issue should not block the migration of the current kernel to address CVE-2022-2602. I will work next on importing the newer 6.0.y versions which include a fix for this issue as well. Regards, Salvatore
Bug#1022202: linux: rebuild upgrades of running kernel breaks module loading
Control: forcemerge 1003210 -1 Hi Christian, On Fri, Oct 21, 2022 at 10:40:22PM +0200, Christian Göttsche wrote: > source: linux > version: 6.0.2-1+b1 > severity: important > > Upgrading the package of the currently running kernel, e.g. for > rebuilds like 6.0.2-1+b1, breaks module loading until the next reboot. > Trying to load modules by applications, e.g. qemu, will fail: > > Oct 21 22:23:23 debianHome kernel: BPF: type_id=1457 bits_offset=0 > Oct 21 22:23:23 debianHome kernel: BPF: > Oct 21 22:23:23 debianHome kernel: BPF: Invalid name > Oct 21 22:23:23 debianHome kernel: BPF: > Oct 21 22:23:23 debianHome kernel: failed to validate module [tun] BTF: -22 > > Maybe this is hard to fix, due to signature changes, so maybe the > postinst should print a strong reboot recommendation? I'm going to merge this with the related #1003210 . Regards, Salvatore
Uploading linux (6.0.3-1)
Hi I would like to upload linux version 6.0.3-1 to unstable. The update consist of importing the latest 6.0.3 stable version (a bigger one covering 852 commits). The update includes CVE fixes for CVE-2022-2602, CVE-2022-3535, CVE-2022-3541, CVE-2022-3542, CVE-2022-3543, CVE-2022-3565 and CVE-2022-3594. I'm including an ABI bump and not trying to resolve/ignore those with this big update. One additional packaging change is included: * [arm64] disable CONFIG_ARM_CPUIDLE, it's arm only Regards, Salvatore signature.asc Description: PGP signature
Bug#1022025: two reverts required, submitted to stable review list
Hi,
On Fri, Oct 21, 2022 at 12:55:09PM +, Dan Coleman wrote:
> Hey,
>
> > On Thursday, 20 October 2022 22:10:27 CEST Salvatore Bonaccorso wrote:
>
> > > So there are two patches who need to be reverted:
> > >
> > >
> https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
> > >
> https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/
>
>
> How do I apply these patches to see if they work for me? Thus far in
> this bug, I've just seen .patch files.
Here are those as patches.
If you trust unsigned binary packages build I would put somehwere I
can provide you those with those two applied. But again, after testing
make sure you reinstall the meta package and go back to the -18
version.
Regards,
Salvatore
From: Alex Deucher
Date: Thu, 20 Oct 2022 11:38:56 -0400
Subject: Revert "drm/amdgpu: move nbio sdma_doorbell_range() into sdma code
for vega"
Origin: https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
Bug-Debian: https://bugs.debian.org/1022025
This reverts commit 9f55f36f749a7608eeef57d7d72991a9bd557341.
This patch was backported incorrectly when Sasha backported it and
the patch that caused the regression that this patch set fixed
was reverted in commit 412b844143e3 ("Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()"").
This isn't necessary and causes a regression so drop it.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2216
Cc: Shuah Khan
Cc: Sasha Levin
Signed-off-by: Alex Deucher
Cc: # 5.10
Tested-By: Diederik de Haas
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/soc15.c | 25 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index a1a8e026b9fa..1f2e2460e121 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1475,11 +1475,6 @@ static int sdma_v4_0_start(struct amdgpu_device *adev)
WREG32_SDMA(i, mmSDMA0_CNTL, temp);
if (!amdgpu_sriov_vf(adev)) {
- ring = >sdma.instance[i].ring;
- adev->nbio.funcs->sdma_doorbell_range(adev, i,
-ring->use_doorbell, ring->doorbell_index,
-adev->doorbell_index.sdma_doorbell_range);
-
/* unhalt engine */
temp = RREG32_SDMA(i, mmSDMA0_F32_CNTL);
temp = REG_SET_FIELD(temp, SDMA0_F32_CNTL, HALT, 0);
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c
index abd649285a22..7212b9900e0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1332,6 +1332,25 @@ static int soc15_common_sw_fini(void *handle)
return 0;
}
+static void soc15_doorbell_range_init(struct amdgpu_device *adev)
+{
+ int i;
+ struct amdgpu_ring *ring;
+
+ /* sdma/ih doorbell range are programed by hypervisor */
+ if (!amdgpu_sriov_vf(adev)) {
+ for (i = 0; i < adev->sdma.num_instances; i++) {
+ ring = >sdma.instance[i].ring;
+ adev->nbio.funcs->sdma_doorbell_range(adev, i,
+ring->use_doorbell, ring->doorbell_index,
+adev->doorbell_index.sdma_doorbell_range);
+ }
+
+ adev->nbio.funcs->ih_doorbell_range(adev, adev->irq.ih.use_doorbell,
+ adev->irq.ih.doorbell_index);
+ }
+}
+
static int soc15_common_hw_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1351,6 +1370,12 @@ static int soc15_common_hw_init(void *handle)
/* enable the doorbell aperture */
soc15_enable_doorbell_aperture(adev, true);
+ /* HW doorbell routing policy: doorbell writing not
+ * in SDMA/IH/MM/ACV range will be routed to CP. So
+ * we need to init SDMA/IH/MM/ACV doorbell range prior
+ * to CP ip block init and ring test.
+ */
+ soc15_doorbell_range_init(adev);
return 0;
}
--
2.37.2
From: Alex Deucher
Date: Thu, 20 Oct 2022 11:38:57 -0400
Subject: Revert "drm/amdgpu: make sure to init common IP before gmc"
Origin: https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/
Bug-Debian: https://bugs.debian.org/1022025
This reverts commit 7b0db849ea030a70b8fb9c9afec67c81f955482e.
The patches that this patch depends on were not backported properly
and the patch that caused the regression that this patch set fixed
was reverted in commit 412b844143e3 ("Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()"").
This isn't necessary and causes a regression so drop it.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2216
Cc: Shuah Khan
Cc: Sasha Levin
Signed-off-by: Alex Deucher
Cc: # 5.10
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
Bug#1022025: two reverts required, submitted to stable review list
Hi all, On Thu, Oct 20, 2022 at 07:41:51PM +, Doublychargedhiggs wrote: > Did the same as Dan, i.e built the kernel (apt-get install source) with the > upstream proposed patch > 0001-drm-amdgpu-fix-sdma-doorbell-init-ordering-on-APUs.patch > using the mentioned test-patches script. The kernel really builds, is even > installable, but then hangs > as before at boot, as Dan reported before. > > However, i'm even less experienced kernel builder than Dan (my 1st kernel > build ever)... So there are two patches who need to be reverted: https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/ https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/ Salvatore
Bug#1022025: fails to boot on machines with AMD integrated graphics
# raising severity for now
Control: severity -1 serious
Hi,
On Wed, Oct 19, 2022 at 10:01:58PM +, Dan Coleman wrote:
> I tried again, same result. Either the patches aren't working OR I
> don't adequately know how to install test kernels. In no uncertain
> terms, it could very well be my lack of knowledge and ability in
> this regard.
On the https://gitlab.freedesktop.org/drm/amd/-/issues/2216 Alex
Deucher is claiming the issue should be fixed by
https://gitlab.freedesktop.org/drm/amd/-/issues/2216#note_1599805 .
So can you (or someone else affected) try next the attached patch?
(interestingly though the mentioned commit which uncovers the issue
was first applied in 5.10.137, then reverted in 5.10.141, so it's
unclear why the issue would still manifest).
Else if anyone with affected hardware is able to bisect between
5.10.140 and 5.10.149 that would be great.
Regards,
Salvatore
>From 62fda3a8cbc93d50974bb320c0e95e2b6308f4b9 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Oct 2022 16:57:42 -0400
Subject: [PATCH] drm/amdgpu: fix sdma doorbell init ordering on APUs
Commit 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
uncovered a bug in amdgpu that required a reordering of the driver
init sequence to avoid accessing a special register on the GPU
before it was properly set up leading to an PCI AER error. This
reordering uncovered a different hw programming ordering dependency
in some APUs where the SDMA doorbells need to be programmed before
the GFX doorbells. To fix this, move the SDMA doorbell programming
back into the soc15 common code, but use the actual doorbell range
values directly rather than the values stored in the ring structure
since those will not be initialized at this point.
This is a partial revert, but with the doorbell assignment
fixed so the proper doorbell index is set before it's used.
Fixes: e3163bc8ffdfdb ("drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega")
Signed-off-by: Alex Deucher
Cc: sk...@linuxfoundation.org
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/soc15.c | 21 +
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 298fa11702e7..1122bd4eae98 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1417,11 +1417,6 @@ static int sdma_v4_0_start(struct amdgpu_device *adev)
WREG32_SDMA(i, mmSDMA0_CNTL, temp);
if (!amdgpu_sriov_vf(adev)) {
- ring = >sdma.instance[i].ring;
- adev->nbio.funcs->sdma_doorbell_range(adev, i,
-ring->use_doorbell, ring->doorbell_index,
-adev->doorbell_index.sdma_doorbell_range);
-
/* unhalt engine */
temp = RREG32_SDMA(i, mmSDMA0_F32_CNTL);
temp = REG_SET_FIELD(temp, SDMA0_F32_CNTL, HALT, 0);
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 183024d7c184..e3b2b6b4f1a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1211,6 +1211,20 @@ static int soc15_common_sw_fini(void *handle)
return 0;
}
+static void soc15_sdma_doorbell_range_init(struct amdgpu_device *adev)
+{
+ int i;
+
+ /* sdma doorbell range is programed by hypervisor */
+ if (!amdgpu_sriov_vf(adev)) {
+ for (i = 0; i < adev->sdma.num_instances; i++) {
+ adev->nbio.funcs->sdma_doorbell_range(adev, i,
+true, adev->doorbell_index.sdma_engine[i] << 1,
+adev->doorbell_index.sdma_doorbell_range);
+ }
+ }
+}
+
static int soc15_common_hw_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1230,6 +1244,13 @@ static int soc15_common_hw_init(void *handle)
/* enable the doorbell aperture */
soc15_enable_doorbell_aperture(adev, true);
+ /* HW doorbell routing policy: doorbell writing not
+ * in SDMA/IH/MM/ACV range will be routed to CP. So
+ * we need to init SDMA doorbell range prior
+ * to CP ip block init and ring test. IH already
+ * happens before CP.
+ */
+ soc15_sdma_doorbell_range_init(adev);
return 0;
}
--
2.37.3
Bug#1022025: fails to boot on machines with AMD integrated graphics
Hi Dan, hi Diederik On Wed, Oct 19, 2022 at 05:09:01PM +0200, Diederik de Haas wrote: > On Wednesday, 19 October 2022 16:34:49 CEST Dan Coleman wrote: > > $ sudo dpkg -i > > ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb dpkg: > > considering removing linux-image-5.10.0-19-amd64 in favour of > > linux-image-5.10.0-19-amd64-unsigned ... dpkg: no, cannot proceed with > > removal of linux-image-5.10.0-19-amd64 (--auto-deconfigure will help): > > linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1) > > linux-image-5.10.0-19-amd64 is to be removed. > > AFAICT, the last line indicates the problem. > I do know how I would resolve it on my system and if my initial attempt fails > how to fix that, but I don't feel comfortable suggesting that to you. > > So, I'll let Salvatore take over as he's (WAY) more experienced then I am. You need to have (temporarily at least) removed the signed package indeed, as they are conflicting. If you do it with apt-get install ./path/to/local/package.deb all the surronding work should be done as well. (And you have the 18 ABI kernel still installed to which you can go back if th test package does no work). After testing, make sure to reinstall the linux-image-amd64 package again. Regards, Salvatore
Re: Problem Kernelupdate 5.10.0-19 on AMD Hardware
Hi Marcus, On Wed, Oct 19, 2022 at 02:57:40PM +0200, PC-vor-Ort, Marcus Orthbandt wrote: > Hello Kernel-Team, > > the latest Update for 5.10.0-19 (149-1) prevent Boot of Linux on > AMD-Machines. > > do you know these Bug currently? Can you have a look if the following matches your issue: https://bugs.debian.org/1022025 Regards, Salvatore
Bug#1022025: fails to boot on machines with AMD integrated graphics
Hi Dan, On Wed, Oct 19, 2022 at 12:55:16PM +, Dan Coleman wrote: > Hi, > > I would love to, but I'm afraid I don't know how. If you or anyone on the > chain is willing to show me what commands to enter (I tried following this > https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html > but got as far as 4.2.2 and couldn't find a debian directory in the source > that I unpacked by following the prior instructions), I would be grateful. > > That said, I understand time and resources are limited, so no worries if > that's not possible! When you do fetch the source package the output will look like: # apt-get source linux Reading package lists... Done NOTICE: 'linux' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/kernel-team/linux.git Please use: git clone https://salsa.debian.org/kernel-team/linux.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 124 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye-security/main linux 5.10.149-1 (dsc) [197 kB] Get:2 http://security.debian.org/debian-security bullseye-security/main linux 5.10.149-1 (tar) [122 MB] Get:3 http://security.debian.org/debian-security bullseye-security/main linux 5.10.149-1 (diff) [1549 kB] Fetched 124 MB in 1s (95.7 MB/s) dpkg-source: info: extracting linux in linux-5.10.149 dpkg-source: info: unpacking linux_5.10.149.orig.tar.xz dpkg-source: info: unpacking linux_5.10.149-1.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying debian/gitignore.patch dpkg-source: info: applying debian/dfsg/arch-powerpc-platforms-8xx-ucode-disable.patch [...] dpkg-source: info: applying bugfix/all/tools-perf-pmu-events-fix-reproducibility.patch dpkg-source: info: applying bugfix/all/bpftool-fix-version-string-in-recursive-builds.patch dpkg-source: info: applying debian/overlayfs-permit-mounts-in-userns.patch Now you have in the current working directory the linux-5.10.149 directory. Did you process went that far? If so change into that directory where the debian/ directory which will include the debian/bin/test-patches to test-apply the patches we would like to test. If that will not help I will try to respin a build so anyone affected can test Hope this helps already, Regards, Salvatore
Bug#1022025: fails to boot on machines with AMD integrated graphics
Control: tags -1 + moreinfo Hi, On Wed, Oct 19, 2022 at 06:22:05AM +, Doublychargedhiggs wrote: > Same problem here. Kernel version 5.10.149-1 (linux-image-5.10.0-19-amd64) > hangs on initialisation of amdgpu > driver, while version 5.10.140-1 (linux-image-5.10.0-18-amd64) boots without > any problem. > > According to the changelogs on kernel.org there were several changes to > amdgpu in versions > 5.10.141, 5.10.143, 5.10.144 5.10.146 and 5.10.148. > > Some extract from my /var/log/messages just in case it is of any help: > > Oct 19 07:05:24 omikron kernel: [0.00] Linux version 5.10.0-19-amd64 > (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, > GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-1 (2022-10-17) > Oct 19 07:05:24 omikron kernel: [0.00] Command line: > BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-amd64 > root=UUID=28af0276-7bd6-468f-b9c9-c743233a9468 ro quiet mem_encrypt=off > snd_hda_intel.power_save=0 > ... > Oct 19 07:05:24 omikron kernel: [2.325914] [drm] amdgpu kernel > modesetting enabled. > Oct 19 07:05:24 omikron kernel: [2.327288] amdgpu: Topology: Add APU node > [0x0:0x0] > Oct 19 07:05:24 omikron kernel: [2.327398] fb0: switching to amdgpudrmfb > from EFI VGA > Oct 19 07:05:24 omikron kernel: [2.328120] Console: switching to colour > dummy device 80x25 > Oct 19 07:05:24 omikron kernel: [2.328366] amdgpu :05:00.0: vgaarb: > deactivate vga console > Oct 19 07:05:24 omikron kernel: [2.328431] amdgpu :05:00.0: enabling > device (0006 -> 0007) > Oct 19 07:05:24 omikron kernel: [2.328516] [drm] initializing kernel > modesetting (RAVEN 0x1002:0x15DD 0x1002:0x15DD 0x83). > Oct 19 07:05:24 omikron kernel: [2.328519] amdgpu :05:00.0: amdgpu: > Trusted Memory Zone (TMZ) feature disabled as experimental (default) > Oct 19 07:05:24 omikron kernel: [2.328536] [drm] register mmio base: > 0xFE60 > Oct 19 07:05:24 omikron kernel: [2.328537] [drm] register mmio size: > 524288 > Oct 19 07:05:24 omikron kernel: [2.328559] [drm] add ip block number 0 > > Oct 19 07:05:24 omikron kernel: [2.328561] [drm] add ip block number 1 > > Oct 19 07:05:24 omikron kernel: [2.328562] [drm] add ip block number 2 > > Oct 19 07:05:24 omikron kernel: [2.328564] [drm] add ip block number 3 > > Oct 19 07:05:24 omikron kernel: [2.328565] [drm] add ip block number 4 > > Oct 19 07:05:24 omikron kernel: [2.328567] [drm] add ip block number 5 > > Oct 19 07:05:24 omikron kernel: [2.328568] [drm] add ip block number 6 > > Oct 19 07:05:24 omikron kernel: [2.328570] [drm] add ip block number 7 > > Oct 19 07:05:24 omikron kernel: [2.328571] [drm] add ip block number 8 > > Oct 19 07:05:24 omikron kernel: [2.333054] input: HD-Audio Generic > HDMI/DP,pcm=3 as > /devices/pci:00/:00:08.1/:05:00.1/sound/card0/input6 > Oct 19 07:05:24 omikron kernel: [2.334135] amdgpu :05:00.0: firmware: > direct-loading firmware amdgpu/raven_gpu_info.bin > Oct 19 07:05:24 omikron kernel: [2.334155] amdgpu :05:00.0: amdgpu: > Fetched VBIOS from VFCT > Oct 19 07:05:24 omikron kernel: [2.334157] amdgpu: ATOM BIOS: > 113-RAVEN-113 > Oct 19 07:05:24 omikron kernel: [2.334462] amdgpu :05:00.0: firmware: > direct-loading firmware amdgpu/raven_sdma.bin > Oct 19 07:05:24 omikron kernel: [2.334469] [drm] VCN decode is enabled in > VM mode > Oct 19 07:05:24 omikron kernel: [2.334470] [drm] VCN encode is enabled in > VM mode > Oct 19 07:05:24 omikron kernel: [2.334471] [drm] JPEG decode is enabled > in VM mode > Oct 19 07:05:24 omikron kernel: [2.334527] [drm] vm size is 262144 GB, 4 > levels, block size is 9-bit, fragment size is 9-bit > Oct 19 07:05:24 omikron kernel: [2.334539] amdgpu :05:00.0: amdgpu: > VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) > Oct 19 07:05:24 omikron kernel: [2.334541] amdgpu :05:00.0: amdgpu: > GART: 1024M 0x - 0x3FFF > Oct 19 07:05:24 omikron kernel: [2.334543] amdgpu :05:00.0: amdgpu: > AGP: 267419648M 0x00F8 - 0x > Oct 19 07:05:24 omikron kernel: [2.334551] [drm] Detected VRAM RAM=2048M, > BAR=2048M > Oct 19 07:05:24 omikron kernel: [2.334552] [drm] RAM width 128bits DDR4 > Oct 19 07:05:24 omikron kernel: [2.334618] [TTM] Zone kernel: Available > graphics memory: 15381802 KiB > Oct 19 07:05:24 omikron kernel: [2.334620] [TTM] Zone dma32: Available > graphics memory: 2097152 KiB > Oct 19 07:05:24 omikron kernel: [2.334621] [TTM] Initializing pool > allocator > Oct 19 07:05:24 omikron kernel: [2.334626] [TTM] Initializing DMA pool > allocator > Oct 19 07:05:24 omikron kernel: [2.334738] [drm] amdgpu: 2048M of VRAM > memory ready > Oct 19 07:05:24 omikron kernel: [2.334741] [drm] amdgpu: 3072M of GTT > memory ready. > Oct 19 07:05:24 omikron
Bug#989705: closing 989705
Hi, On Tue, Oct 04, 2022 at 07:39:23PM +0200, Computer Enthusiastic wrote: > Hello Salvatore, > > Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso > ha scritto: > > > > Hi, > [..] > > > > > > What could be done to make the patch land in the current Debian Stable > > > (Bullseye) kernel release ? > > > > It should land in the 5.10.y stable series which we will then pick up > > automatically on next rebases. But what is puzzling is that the commit > > has been marked for stable only v5.15+. If you were able to confirm it > > is actually present in 5.10.y as well then it needs a followup to be > > picked as well for the 5.10.y stable series. > > > > Regards, > > Salvatore > > Yes, the patch is marked as only v5.15+, but the issue is still there > in kernel 5.10, too. > > As you suggested, I have tested the vanilla kernel 5.10.145 with and > without kernel patches, as reported here [0]. Seen that, and thanks for having taken the time to test the case with and without patch with newest 5.10.y version. This will hopefully help to get the patch applied to 5.10.y as well so we can pick it up. Regards, Salvatore
Bug#1016092: please enable CONFIG_SENSORS_SHT3x
Hi Marco, On Fri, Sep 30, 2022 at 05:36:08PM +0200, Marco d'Itri wrote: > Hello kernel team, can I get some feedback? > Are there major reasons why it is not right to build more drivers? Enabled both CONFIG_SENSORS_SHT3x and CONFIG_SENSORS_SHT4x for the next upload to experimental, but though I have not touched the drivers/iio/chemical yet. We have not any enabled there afaics and I think this needs some discussion/input from Ben in particular. Enabling more drivers makes build time and size bigger so we have to take extra care on what is of actual benefit or what are cornercases. Hope this helps already, Regards, Salvatore
Uploading linux (5.19.11-1)
Hi I would like to upload linux version 5.19.11-1 to unstable. The update consists of rebasing to the latest 5.19.11 upstream stable version in the 5.19.y series. An ABI bump is included. Some additional packaging changes are included: * [armhf] sound/soc/rockchip: Enable SND_SOC_RK3288_HDMI_ANALOG as module (Closes: #1019143) * [x86] drivers/edac: Enable EDAC_I10NM as module (Closes: #1019248) * d/b/check-patches.sh: Use grep -(E|F) instead of deprecated (e|f)grep * d/templates/image.bug/include-model: Use grep -E instead of deprecated egrep * Bump ABI to 2 * Refresh "Export symbols needed by Android drivers" * Revert "[hppa/parisc64] Drop explicit setting of 64BIT" * debian/bin/genpatch-rt: Change argument parsing to use argparse * debian/bin/genpatch-rt: Add option to disable signature verification * linux-headers: Skip exact compiler version comparison (Closes: #1019749) * [arm64] Add support for misalignment fixups for multiword loads from next branch. Enable COMPAT_ALIGNMENT_FIXUPS Regards, Salvatore signature.asc Description: PGP signature
Bug#1020548: nfs-kernel-server causes kernel panic
Hi Klemens, On Fri, Sep 23, 2022 at 08:47:19AM +0200, Klemens Kittan wrote: > Package: nfs-kernel-server > Version: 1:1.3.4-2.5+deb10u1 > Severity: important > > I am using Debian GNU/Linux 10.13, kernel 5.10.0-0.deb10.16-amd64 and libc6 > 2.28-10+deb10u1. > > As soon as the NFS server is accessed, I get a kernel panic and have to > restart the server. With the kernel 5.10.0-0.bpo.15-amd64 the problem does > not exist. As a workaround I have pinned the kernel. > > Sep 19 11:42:14 fs1 kernel: [9.923891] NFSD: Using UMH upcall client > tracking operations. > Sep 19 11:42:14 fs1 kernel: [9.923897] NFSD: starting 90-second grace > period (net f098) > Sep 19 11:42:20 fs1 kernel: [ 15.969957] [ cut here > ] > Sep 19 11:42:20 fs1 kernel: [ 15.970015] WARNING: CPU: 1 PID: 959 at > fs/nfsd/nfs4state.c:4998 nfsd4_process_open2+0x1305/0x1510 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.970017] Modules linked in: cbc cts > rpcsec_gss_krb5 binfmt_misc vsock_loopback > vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock > xt_multiport xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 > nf_defrag_ipv4 libcrc32c xt_comment iptable_filter quota_v2 quota_tree > intel_rapl_msr intel_rapl_common crc32_pclmul vmwgfx nls_ascii nls_cp437 > vfat ttm ghash_clmulni_intel fat drm_kms_helper aesni_intel libaes > crypto_simd cec cryptd glue_helper vmw_balloon rapl drm vmw_vmci joydev > evdev efi_pstore pcspkr serio_raw sg ac button nfsd nfs_acl lockd usbhid > auth_rpcgss grace hid usbcore dm_mod sunrpc usb_common efivarfs ip_tables > x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sr_mod cdrom sd_mod > ata_generic t10_pi crc_t10dif crct10dif_generic ata_piix crct10dif_pclmul > crct10dif_common libata psmouse crc32c_intel vmw_pvscsi vmxnet3 scsi_mod > i2c_piix4 > Sep 19 11:42:20 fs1 kernel: [ 15.970119] CPU: 1 PID: 959 Comm: nfsd Not > tainted 5.10.0-0.deb10.16-amd64 #1 Debian 5.10.127-2~bpo10+1 > Sep 19 11:42:20 fs1 kernel: [ 15.970120] Hardware name: VMware, Inc. > VMware7,1/440BX Desktop Reference Platform, BIOS > VMW71.00V.16707776.B64.2008070230 08/07/2020 > Sep 19 11:42:20 fs1 kernel: [ 15.970160] RIP: > 0010:nfsd4_process_open2+0x1305/0x1510 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.970164] Code: ba 85 3f 89 c0 48 0f a3 05 > 38 4a eb c8 73 d9 48 8b 05 2f 08 04 00 48 85 c0 74 0d 48 8b 78 08 49 8d 75 > 1c e8 5d fe fc ff eb be <0f> 0b e9 0d f4 ff ff 0f 0b e9 8c f5 ff ff 48 c7 > 44 24 48 00 00 00 > Sep 19 11:42:20 fs1 kernel: [ 15.970166] RSP: 0018:9f0b406cfce0 > EFLAGS: 00010246 > Sep 19 11:42:20 fs1 kernel: [ 15.970168] RAX: RBX: > 8ce4ddc011e0 RCX: 8ce4ca9946e0 > Sep 19 11:42:20 fs1 kernel: [ 15.970169] RDX: 0001 RSI: > 8ce4cb2337f8 RDI: 8ce4cb2337a4 > Sep 19 11:42:20 fs1 kernel: [ 15.970170] RBP: 9f0b406cfdc0 R08: > 8ce4cb2337a8 R09: 8ce4c45550c0 > Sep 19 11:42:20 fs1 kernel: [ 15.970171] R10: R11: > R12: 8ce4cb2337a0 > Sep 19 11:42:20 fs1 kernel: [ 15.970172] R13: R14: > 8ce4cb2337a0 R15: 8ce4ddd99730 > Sep 19 11:42:20 fs1 kernel: [ 15.970173] FS: () > GS:8ce5f7c8() knlGS: > Sep 19 11:42:20 fs1 kernel: [ 15.970174] CS: 0010 DS: ES: CR0: > 80050033 > Sep 19 11:42:20 fs1 kernel: [ 15.970175] CR2: 7fc1e1e7f710 CR3: > 000184a0a003 CR4: 000606e0 > Sep 19 11:42:20 fs1 kernel: [ 15.970230] Call Trace: > Sep 19 11:42:20 fs1 kernel: [ 15.970248] ? nfsd_permission+0x63/0xe0 > [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.970260] ? fh_verify+0x17a/0x6a0 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.970358] ? > write_bytes_to_xdr_buf+0xbc/0xe0 [sunrpc] > Sep 19 11:42:20 fs1 kernel: [ 15.971051] nfsd4_open+0x3a1/0x720 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971142] nfsd4_proc_compound+0x355/0x680 > [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971155] nfsd_dispatch+0xd4/0x180 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971179] svc_process_common+0x392/0x6c0 > [sunrpc] > Sep 19 11:42:20 fs1 kernel: [ 15.971203] ? svc_recv+0x3c4/0x8a0 [sunrpc] > Sep 19 11:42:20 fs1 kernel: [ 15.971214] ? nfsd_svc+0x300/0x300 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971225] ? nfsd_destroy+0x60/0x60 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971246] svc_process+0xb7/0xf0 [sunrpc] > Sep 19 11:42:20 fs1 kernel: [ 15.971257] nfsd+0xe8/0x140 [nfsd] > Sep 19 11:42:20 fs1 kernel: [ 15.971262] kthread+0x116/0x130 > Sep 19 11:42:20 fs1 kernel: [ 15.971265] ? > __kthread_cancel_work+0x40/0x40 > Sep 19 11:42:20 fs1 kernel: [ 15.971269] ret_from_fork+0x22/0x30 > Sep 19 11:42:20 fs1 kernel: [ 15.971272] ---[ end trace 4468d10badfc4017 > ]--- I suspect this might be the same as #1014793. As you are using buster, which is LTS, please instead of using the bpo kernel if you need the 5.10.y series, switch to the src:linux-5.10 provided packages:
Bug#1020441: linux: autopkgtest needs update for new version of gcc-11
Hi, On Wed, Sep 21, 2022 at 09:23:59PM +0200, Paul Gevers wrote: > Source: linux > Version: 5.19.6-1 > Severity: serious > X-Debbugs-CC: gcc...@packages.debian.org > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:gcc-11 > > Dear maintainer(s), > > With a recent upload of gcc-11 the autopkgtest of linux fails in testing > when that autopkgtest is run with the binary packages of gcc-11 from > unstable. It passes when run with only packages from testing (it also fails > in testing). In tabular form: > >passfail > gcc-11 from testing11.3.0-6 > linux from testing5.19.6-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of gcc-11 to testing > [1]. Of course, gcc-11 shouldn't just break your autopkgtest (or even worse, > your package), but it seems to me that the test "only" fails on "Unexpected > warning" and your package needs to update to the new situation. > > If this is a real problem in your package (and not only in your > autopkgtest), the right binary package(s) from gcc-11 should really add a > versioned Breaks on the unfixed version of (one of your) package(s). Note: > the Breaks is nice even if the issue is only in the autopkgtest as it helps > the migration software to figure out the right versions to combine in the > tests. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=gcc-11 > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/26272813/log.gz > > I: Found quick flavour cloud-amd64 > I: Build for 5.19.0-1-cloud-amd64 > make: Entering directory '/usr/src/linux-headers-5.19.0-1-cloud-amd64' > test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( > \ > echo >&2; \ > echo >&2 " ERROR: Kernel configuration is invalid."; \ > echo >&2 " include/generated/autoconf.h or include/config/auto.conf > are missing.";\ > echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix > it."; \ > echo >&2 ;\ > /bin/false) > warning: the compiler differs from the one used to build the kernel > The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0 > You are using: gcc-11 (Debian 11.3.0-6) 11.3.0 > make -f /usr/src/linux-headers-5.19.0-1-common/scripts/Makefile.build > obj=/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo \ > single-build= \ > need-builtin=1 need-modorder=1 >gcc-11 > -Wp,-MMD,/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/.foo.o.d > -nostdinc -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include > -I./arch/x86/include/generated > -I/usr/src/linux-headers-5.19.0-1-common/include -I./include > -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include/uapi > -I./arch/x86/include/generated/uapi > -I/usr/src/linux-headers-5.19.0-1-common/include/uapi > -I./include/generated/uapi -include > /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler-version.h > -include /usr/src/linux-headers-5.19.0-1-common/include/linux/kconfig.h > -include > /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler_types.h > -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.19.0-1-common/= > -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing > -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration > -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 > -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 > -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 > -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone > -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables > -mindirect-branch=thunk-extern -mindirect-branch-register > -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables > -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address > -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member > -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 > -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-main > -Wno-unused-but-set-variable -Wno-unused-const-variable > -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY > -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type > -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict > -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow > -fno-stack-check -fconserve-stack -Werror=date-time > -Werror=incompatible-pointer-types -Werror=designated-init >
Bug#989705: closing 989705
Hi, On Tue, Sep 20, 2022 at 11:37:34AM +0200, Computer Enthusiastic wrote: > Hello, > > Il giorno mar 20 set 2022 alle ore 09:33 Salvatore Bonaccorso > ha scritto: > > > > close 989705 5.19.6-1 > > thanks > > What could be done to make the patch land in the current Debian Stable > (Bullseye) kernel release ? It should land in the 5.10.y stable series which we will then pick up automatically on next rebases. But what is puzzling is that the commit has been marked for stable only v5.15+. If you were able to confirm it is actually present in 5.10.y as well then it needs a followup to be picked as well for the 5.10.y stable series. Regards, Salvatore
Bug#1017915: btrfs: space cache corruption and potential double allocations
Hi, On Thu, Sep 01, 2022 at 06:23:21PM +0200, Christoph Anton Mitterer wrote: > On Thu, 2022-09-01 at 16:40 +0200, Salvatore Bonaccorso wrote: > > 5.19.6-1 has been uploaded earlier today. > > Ah,... okay... I had only seen the UNRELEASED commit in salsa. Was probably then a race between finalizing the update and this message :) Almost all builds are done, but the signed packages need to be triggered yet. Regards, Salvatore
Bug#1017425: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1017425: fixed in linux 5.19.6-1)
Hi, On Thu, Sep 01, 2022 at 06:03:41PM +0300, Martin-Éric Racine wrote: > This bug was reported against Stable. It cannot be considered as > closed for as long as a new 5.10 kernel including the fix hasn't been > published. it very well can. The BTS can close a bug in multiple versions which will be done here. A second time with the version for 5.10.y when it hits stable. Regards, Salvatore
Uploading linux (5.19.6-1)
Hi
I would like to upload linux version 5.19.6-1 to unstable.
An ABI bump is included. It is a new upstream version and furthermore
we rotate certs to use the "Debian Secure Boot Signer 2022 - linux"
certificate (Cf. #1018752).
Apart the new upstream imports the additional pending changes are:
* d/tests/kbuild: Fix default-flavour lookup for arches with no featuresets
* d/tests/kbuild: Make flavour lookup verbose
* d/lib/python/debian_linux, d/templates: Use variable for binary package
name
* lintian: Update overrides in linux-image-*-dbg for lintian 2.115
* d/{signing_templates/,}rules.real: Run dh_lintian for all packages
* [hppa,mips,mipsel,powerpc] lintian: Override error for 64-bit kernels
* [mips64el,mipsel,ppc64el] lintian: Override error for unstripped vmlinux
* [arm64] lintian: Override errors for vdso32.so in linux-image-*-dbg
* android: Remove CONFIG_ANDROID:
- Drop "wireguard: Clear keys after suspend despite CONFIG_ANDROID=y"
- pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
- remove CONFIG_ANDROID
- Enable/disable ANDROID_BINDER_IPC to match previous configuration
* [x86] drivers/hwmon: Enable SENSORS_ASUS_WMI and SENSORS_ASUS_EC as
modules
* [x86] drivers/platform/x86: Enable NVIDIA_WMI_EC_BACKLIGHT as module
(Closes: #1017972)
* [arm64] drivers/spi: Enable SPI_GPIO and SPI_SUN6I as modules
(Closes: #1016807)
* [arm64] drivers/gpu/drm/rockchip: Explicitly enable ROCKCHIP_VOP
* [hppa] Drop CONFIG_PATA_LEGACY for hppa architecture
* [rt] Refresh "rcutorture: Also force sched priority to timersd on boosting
test."
* Drop setting of CRYPTO_BLAKE2S
crypto: blake2s shash module was removed upstream.
* [arm] arch/arm/crypto: Enable CRYPTO_BLAKE2S_ARM
* certs: Rotate to use the "Debian Secure Boot Signer 2022 - linux"
certificate (Closes: #1018752)
* Set ABI to 1
Regards,
Salvatore
signature.asc
Description: PGP signature
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
Hi Martin, On Tue, Aug 30, 2022 at 03:18:51PM +0300, Martin-??ric Racine wrote: > On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra wrote: > > On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-??ric Racine wrote: > > > On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra > > > wrote: > > > > > > > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote: > > > > > > > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and > > > > > we can't have nested alternatives. That's unfortunate. > > > > > > > > Well, both alternatives end with the LFENCE instruction, so I could pull > > > > it out and do two consequtive ALTs, but unrolling the loop for i386 is > > > > a better solution in that the sequence, while larger, removes the need > > > > for the LFENCE. > > > > > > Have we reached a definitive conclusion on to how to fix this? > > > > https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5 > > Thanks. > > Ben: When can we expect an updated kernel to security-updates at Debian? When the update is ready to go. Likely the update for the next point release for bullseye will contain the fix for this issue. Regards, Salvatore
Bug#1016317: linux-image-5.10.0-16-armmp: insecure W+X mapping
Control: tags -1 + moreinfo
On Fri, Jul 29, 2022 at 08:04:56PM +0200, Rainer Dorsch wrote:
> Package: src:linux
> Version: 5.10.127-2
> Severity: normal
>
> Dear Maintainer,
>
> I just noticed after booting into the kernel 5.10.0-16-armmp #1 SMP Debian
> 5.10.127-2 (2022-07-23) armv7l GNU/Linux (on a SolidRun Cubox-i with an NXP
> iMX6) that I get an
>
> insecure W+X mapping at address 0xf0879000
>
> on a serial console and a backtrace during the boot process:
>
> [5.377591] Registering SWP/SWPB emulation handler
> [5.382640] registered taskstats version 1
> [5.386784] Loading compiled-in X.509 certificates
> [5.787454] Loaded X.509 cert 'Debian Secure Boot CA:
> 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
> [5.796311] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux:
> 4b6ef5abca669825178e052c84667ccbc0531f8c'
> [5.806849] zswap: loaded using pool lzo/zbud
> [5.812253] Key type ._fscrypt registered
> [5.816352] Key type .fscrypt registered
> [5.820314] Key type fscrypt-provisioning registered
> [5.825722] AppArmor: AppArmor sha1 policy hashing enabled
> [5.865627] vcc_3v3: supplied by v_5v0
> [5.895845] Freeing unused kernel memory: 2048K
> [5.913843] [ cut here ]
> [5.918527] WARNING: CPU: 0 PID: 1 at arch/arm/mm/dump.c:248
> note_page+0x3d0/0x3dc
> [5.926143] arm/mm: Found insecure W+X mapping at address 0xf0879000
> [5.932529] Modules linked in:
> [5.935629] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-16-armmp #1
> Debian 5.10.127-2
> [5.943912] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [5.950457] Backtrace:
> [5.952938] [] (dump_backtrace) from []
> (show_stack+0x20/0x24)
> [5.960532] r7:00f8 r6:6013 r5: r4:c14cdda8
> [5.966215] [] (show_stack) from []
> (dump_stack+0xc8/0xdc)
> [5.973469] [] (dump_stack) from [] (__warn+0xfc/0x158)
> [5.980449] r7:00f8 r6:0009 r5:c031fa38 r4:c0fbe5c8
> [5.986130] [] (__warn) from []
> (warn_slowpath_fmt+0xa4/0xe4)
> [5.993633] r7:c031fa38 r6:00f8 r5:c0fbe5c8 r4:c0fbe594
> [5.999311] [] (warn_slowpath_fmt) from []
> (note_page+0x3d0/0x3dc)
> [6.007251] r8: r7: r6:0005 r5:c140c4e0 r4:c197ff28
> [6.013971] [] (note_page) from []
> (walk_pmd+0xe8/0x1a4)
> [6.021042] r10:c197ff28 r9:c0207c20 r8:c1900800 r7: r6:c0fbe610
> r5:f087b000
> [6.02] r4:c19001ec
> [6.031437] [] (walk_pmd) from []
> (ptdump_check_wx+0x88/0x104)
> [6.039030] r10: r9: r8: r7: r6:c0208000
> r5:f080
> [6.046878] r4:c0207c28
> [6.049435] [] (ptdump_check_wx) from []
> (mark_rodata_ro+0x3c/0x40)
> [6.057459] r6: r5:c0d092cc r4:
> [6.062103] [] (mark_rodata_ro) from []
> (kernel_init+0x44/0x130)
> [6.069873] [] (kernel_init) from []
> (ret_from_fork+0x14/0x2c)
> [6.077459] Exception stack(0xc197ffb0 to 0xc197fff8)
> [6.082528] ffa0:
>
> [6.090726] ffc0:
>
> [6.098924] ffe0: 0013
> [6.105553] r5:c0d092cc r4:
> [6.109187] ---[ end trace 36d095f56a800b3c ]---
> [6.114076] Checked W+X mappings: FAILED, 1 W+X pages found
> [6.119751] Run /init as init process
> [6.847313] gpio_mxc: module verification failed: signature and/or
> required
> key missing - tainting kernel
> [6.859257] vdd1p1: supplied by regulator-dummy
> [6.871900] v_usb2: supplied by v_5v0
> [6.876972] vdd3p0: supplied by regulator-dummy
> [6.882630] vdd2p5: supplied by regulator-dummy
> [6.887949] vddarm: supplied by regulator-dummy
> [6.893661] vddpu: supplied by regulator-dummy
> [6.898847] vddsoc: supplied by regulator-dummy
>
> I do not observe any functional issue so far though.
>
> Since I have not checked the output of the serial console for a while, I
> cannot tell when
> the issue started to appear.
>
> There is a similar report for the same hardware platform, but is reported on
> a 5.13 kernel:
> https://lore.kernel.org/all/yun2qpc5ibaiv...@shell.armlinux.org.uk/T/
>
> I am not sure if it was already present in 5.10, if it got backported or if
> it is
> entirely unrelated.
>
> Many thanks for the great support of many hardware platforms
Would it be possible that you try to cherry-pick upstream 4aede550f104
("ARM: imx6: mark OCRAM mapping read-only") to see if it solves the
issue?
Can you alternatively test the package from bullseye-backports which
would have the fix included and see if the issue goes away?
Regards,
Salvatore
Bug#1015295: linux-image-5.10.0-16-arm64: Unbootable system due to F2FS sanity_check_inode errors after upgrading kernel
Control: tags -1 + moreinfo On Tue, Jul 19, 2022 at 05:50:13AM +0200, Lukasz K. wrote: > Package: linux-image-5.10.0-16-arm64 > Severity: critical > Justification: breaks the whole system > X-Debbugs-Cc: mov...@cryptolab.net > > Dear Maintainer, > > After upgrading kernel from linux-image-5.10.0-14-arm64 to > linux-image-5.10.0-16-arm64 my system became unbootable due to F2FS > sanity_check_inode errors. > > Going back to previous kernel fixed the issue. > > This does not appear to be limited only to Debian, as could be seen in this > thread: > https://github.com/raspberrypi/linux/issues/5068 > > Error messages are (aside from different device) the same as in the linked > thread above: > [ 10.395372] F2FS-fs (mmcblk0p2): sanity_check_inode: inode (ino=85f5, > mode=33188) should not have inline_data, run fsck to fix > [...] > > I am using F2FS for my root partition with zstd compression enabled. > > Partition was created with: > mkfs.f2fs -f -O > extra_attr,inode_checksum,sb_checksum,compression,quota,encrypt DEVICE > > And is mounted with: > flush_merge,data_flush,compress_algorithm=zstd > > Compression was explicitly enabled for entire root partition during > installation > with: > mount -t f2fs -o flush_merge,data_flush,compress_algorithm=zstd DEVICE /target > chattr -R -V +c /target > > Linked thread also mentions that this was fixed upstream. The referenced commit seems to have actually landed in 5.10.127 upstream. So this probably needs more investigation. Can you for your device test upstrema kernels and test if 5.10.136 upstream fixes the issue? Can you bisect the breaking commit upstream between the two versions working in Debian and breaking? Regards, Salvatore
Bug#1015167: CPU stall while running fwupdmgr
Control: tags -1 + moreinfo Hi Marco, On Sun, Jul 17, 2022 at 01:49:12AM +0200, Marco d'Itri wrote: > On Jul 17, Diederik de Haas wrote: > > > On Sunday, 17 July 2022 01:34:08 CEST Marco d'Itri wrote: > > > Source: linux > > > Version: 5.10.127-1 > > > Severity: normal > ... > > > Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) > > > > Why is this bug filed against kernel version 5.10.127-1 and not 5.18.5-1? > I wondered myself, but I do not know why reportbug choose the version of > the stable package. > > ii linux-image-5.18.0-2-amd64 5.18.5-1 amd64Linux 5.18 for > 64-bit > > > 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64 > GNU/Linux Do you still experience this problem with the latest kernel in unstable or experimental? Regards, Salvatore
Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Hi Arne,
On Fri, Jul 22, 2022 at 10:18:56AM +0200, Arne Nordmark wrote:
> Den 2022-07-15 kl. 21:58, skrev Salvatore Bonaccorso:
> > I would be interested to either pinpoint the regressing commit
> > upstream beween 5.10.120 and 5.10.127 or conversely the fixing commit
> > beween 5.10.127 upstream and 5.10.130 where you are not able anymore
> > to reproduce the error. What I can say, I have already imported
> > 5.10.130 for furture upload (cf.
> > https://salsa.debian.org/kernel-team/linux/-/merge_requests/506).
>
> Bisection for the regression proved too hard.
>
> Bisection for the fix went better, I can get a crash with 5.10.128-00010 but
> not yet with 5.10.128-00011. This indicates that the fixing commit was
> probably:
>
> commit 6a0b9512a6aa7b7835d8138f5ffdcb4789c093d4
> Author: Chuck Lever
> Date: Thu Jun 30 16:48:18 2022 -0400
>
> SUNRPC: Fix READ_PLUS crasher
>
> which indeed seems to touch code involved in NFS service.
>
> Consequently, the breaking commit was probably:
>
> 6c254bf3b637 ("SUNRPC: Fix the calculation of xdr->end in
> xdr_get_next_encode_buffer()")
Thank you and apologies for the delay! The next upload for
bullseye(-security) will contain that fix and will close the bug with
that upload.
Thanks a lot for your investigtive work and bisection to the fix!
Regards,
Salvatore
Uploading linux (5.18.16-1)
Hi I would like to upload linux version 5.18.16-1 to unstable. It catches up with the last stable series updates from 5.18.15 and 5.18.16. An ABI bump is included. Additionally there are the following packaging changes done: * d/tests: kbuild test case depends on python3 * d/tests: Run kbuild test with default flavour if quick flavour not defined * d/lib/python/debian_linux/debian.py: Add Architecture field to TestsControl * d/tests: Restrict kbuild tests to architectures with default or quick flavour * security: Add landlock and bpf to enabled LSM list (Closes: #999551) Regards, Salvatore signature.asc Description: PGP signature
Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Hi Arne, Thanks a lot for your time into debugging the issue. On Fri, Jul 15, 2022 at 10:28:17AM +0200, Arne Nordmark wrote: > Sorry for the late reply. > > Den 2022-07-13 kl. 12:07, skrev Salvatore Bonaccorso: > > Control: tags -1 + moreinfo > > > > Hello Arne, > > > > ... > > > > > As you seem to reliably reproduce the issue, do you have the > > possiblity (on the nonproduction instance) to try to bisect down the > > problem? Additionally to the bisect, on a testinstance were the issue > > is reproducible, can you run a selfcompiled 5.10.130 upstream to see > > if the problem is still present? > > I have now set up a test environment, and been able to reproduce NFS crashes > with the Debian linux-image-5.10.0-16-amd64 and self-compiled upstream > v5.10.127 kernels. Thats great. I have not reached yet the point to replicate it myself. But it's good you have now a base test environment where it's safe to experiment. > I have not been able to get a self-compiled upstream v5.10.130 to crash. That are good news. > As for bisection, I am not entirely clear what is expected from me. Do you > mean bisect the upstream kernels? Between which points? v5.10.120 to > v5.10.127? I would be interested to either pinpoint the regressing commit upstream beween 5.10.120 and 5.10.127 or conversely the fixing commit beween 5.10.127 upstream and 5.10.130 where you are not able anymore to reproduce the error. What I can say, I have already imported 5.10.130 for furture upload (cf. https://salsa.debian.org/kernel-team/linux/-/merge_requests/506). > Bisection would be a new experience for me, even compiling the kernel seem > like ages ago ... (using Debian since 0.93R6). Would the following help? https://wiki.debian.org/DebianKernel/GitBisect Do you need any more specifc help to get it rolling? Regards, Salvatore
Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Control: tags -1 + moreinfo Hello Arne, On Tue, Jul 12, 2022 at 08:14:22AM +0200, Arne Nordmark wrote: > > Package: src:linux > Version: 5.10.127-1 > Severity: normal > > Dear Maintainer, > > The new kernel in Debian 11.4 seems unstable and crashes when serving NFS. > On two different computers, these lockups happens within minutes, typically > when a client runs firefox on an NFS-mounted home directory. Typically the > servers lock up without any printout, but on one occasion, the following was > logged: > > jul 10 08:35:13 ano4 kernel: general protection fault, probably for > non-canonical address 0x2f48514544455145: [#1] SMP PTI > jul 10 08:35:13 ano4 kernel: CPU: 2 PID: 1244 Comm: nfsd Not tainted > 5.10.0-16-amd64 #1 Debian 5.10.127-1 > jul 10 08:35:13 ano4 kernel: Hardware name: System manufacturer System > Product Name/P5Q DELUXE, BIOS 220105/21/2009 > jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570 > jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 01 48 > 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 f1 41 85 > c1 74 4f <49> 8b 3f 48 8b 07 48 85 c0 0f 84 0a 01 00 00 48 8d 7c 24 38 44 89 > jul 10 08:35:13 ano4 kernel: RSP: 0018:abe901fa3bc8 EFLAGS: 00010202 > jul 10 08:35:13 ano4 kernel: RAX: bab6aebe RBX: 0001 > RCX: 0004 > jul 10 08:35:13 ano4 kernel: RDX: 00035a00 RSI: 0001 > RDI: 2f48514544455145 > jul 10 08:35:13 ano4 kernel: RBP: abe901fa3c20 R08: 0001 > R09: 0002 > jul 10 08:35:13 ano4 kernel: R10: 0002 R11: 0002 > R12: 0002 > jul 10 08:35:13 ano4 kernel: R13: 45495141 R14: 424d6757 > R15: 2f48514544455145 > jul 10 08:35:13 ano4 kernel: FS: () > GS:939527d0() knlGS: > jul 10 08:35:13 ano4 kernel: CS: 0010 DS: ES: CR0: > 80050033 > jul 10 08:35:13 ano4 kernel: CR2: 560b8cee4000 CR3: 0001034da000 > CR4: 000406e0 > jul 10 08:35:13 ano4 kernel: Call Trace: > jul 10 08:35:13 ano4 kernel: __fsnotify_parent+0xe7/0x2d0 > jul 10 08:35:13 ano4 kernel: ? ext4_buffered_write_iter+0xce/0x160 [ext4] > jul 10 08:35:13 ano4 kernel: ? do_iter_readv_writev+0x152/0x1b0 > jul 10 08:35:13 ano4 kernel: do_iter_write+0xc8/0x1b0 > jul 10 08:35:13 ano4 kernel: nfsd_vfs_write+0x175/0x510 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd4_write+0x135/0x1b0 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd4_proc_compound+0x40d/0x680 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd_dispatch+0xd3/0x180 [nfsd] > jul 10 08:35:13 ano4 kernel: svc_process_common+0x3d4/0x6d0 [sunrpc] > jul 10 08:35:13 ano4 kernel: ? nfsd_svc+0x320/0x320 [nfsd] > jul 10 08:35:13 ano4 kernel: svc_process+0xb7/0xf0 [sunrpc] > jul 10 08:35:13 ano4 kernel: nfsd+0xe8/0x140 [nfsd] > jul 10 08:35:13 ano4 kernel: ? nfsd_destroy+0x60/0x60 [nfsd] > jul 10 08:35:13 ano4 kernel: kthread+0x11b/0x140 > jul 10 08:35:13 ano4 kernel: ? __kthread_bind_mask+0x60/0x60 > jul 10 08:35:13 ano4 kernel: ret_from_fork+0x22/0x30 > jul 10 08:35:13 ano4 kernel: Modules linked in: dm_snapshot dm_bufio tun > cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_userspace > aes_generic libaes crypto_simd cryptd glue_helper cbc cts rpcsec_gss_krb5 > sit tunnel4 ip_tunnel nft_nat sch_fq_codel rc_pinnacl > e_pctv_hd em28xx_rc rc_core si2157 si2168 i2c_mux em28xx_dvb dvb_core > snd_hda_codec_analog snd_hda_codec_generic ledtrig_audio ivtv_alsa > tuner_simple tuner_types snd_hda_codec_hdmi wm8775 snd_hda_intel tda9887 > tda8290 snd_intel_dspcfg tea5767 soundwire_intel tuner > soundwire_generic_allocation snd_soc_core snd > _compress soundwire_cadence cx25840 snd_hda_codec ivtv snd_hda_core > snd_hwdep soundwire_bus em28xx kvm_intel radeon tveeprom snd_pcm cx2341x kvm > ttm videodev snd_timer snd irqbypass soundcore drm_kms_helper mc serio_raw > evdev cec i2c_algo_bit iTCO_wdt intel_pmc_bxt iTCO_vendor_support pcspkr > watchdog sg acpi_ > cpufreq asus_atk0110 button nft_chain_nat nf_nat nft_reject_inet > nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_counter nft_ct > jul 10 08:35:13 ano4 kernel: nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > coretemp firewire_sbp2 nf_tables nfnetlink loop nfsd parport_pc ppdev > nfs_acl lockd lp auth_rpcgss parport grace drm fuse sunrpc configfs > ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid4 > 56 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq > libcrc32c crc32c_generic raid0 multipath linear dm_mod raid1 md_mod sd_mod > hid_generic t10_pi ata_generic crc_t10dif crct10dif_generic st > crct10dif_common usbhid pata_marvell hid ahci libahci mpt3sas firewire_ohci > firewire_core aic7xxx > crc_itu_t libata skge ehci_pci uhci_hcd scsi_transport_spi lpc_ich i2c_i801 > sky2 ehci_hcd psmouse i2c_smbus raid_class scsi_transport_sas usbcore > scsi_mod usb_common floppy > jul 10 08:35:13 ano4 kernel: ---[ end trace
Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory
Hi Michael, On Tue, Jul 12, 2022 at 05:57:41PM +0200, Michael Biebl wrote: > On Sat, 9 Jul 2022 21:02:50 +0200 Salvatore Bonaccorso > wrote: > > On Thu, Jul 07, 2022 at 01:37:53PM +0200, Michael Biebl wrote: > > > It would thus be great to have the patch in [2] applied and uploaded > > > soon. I > > > can offer to NMU if available time is an issue. > > > > With that patch MR filled: > > > > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/64 > > > Thanks for the patch, Sven and thanks for the MR, Salvatore! > > Since we haven't received any feedback so far, I've uploaded an NMU with the > patch to DELAYED/5 (debdiff attached) > > Ben, please holler if you have any objections and you want me to cancel the > NMU. personally i would prefer if we can do it a regular kernel-team upload, there were some other changes pending. Will ping Ben on IRC to ask. Otherwise I guess the NMU is fine. Regards, Salvatore
Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory
Hi, On Thu, Jul 07, 2022 at 01:37:53PM +0200, Michael Biebl wrote: > > Control: severity -1 important > > On Mon, 04 Jul 2022 15:01:13 +1000 Konomi Kitten > wrote: > > Package: initramfs-tools > > Version: 0.141 > > Severity: minor > > X-Debbugs-Cc: konomikit...@gmail.com > > > > When update-initramfs runs I receive the following message: > > > > depmod: WARNING: could not open modules.builtin.modinfo at > > /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or > > directory > > > Unfortunately this is not a minor issue, as it breaks the autopkgtest suite > of initramfs-tools and thus prevents kmod from entering testing (and > dependent packages like systemd [1] as well). > > It would thus be great to have the patch in [2] applied and uploaded soon. I > can offer to NMU if available time is an issue. With that patch MR filled: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/64 Salvatore
Bug#1014272: src:linux: sign-file: correct error handling
Hi Ansgar, On Sun, Jul 03, 2022 at 11:47:51AM +0200, Ansgar wrote: > Source: linux > Version: 5.18.5-1 > Severity: normal > Tags: upstream > Control: found -1 4.19.208-1 5.10.84-1 > > The functions CMS_final, i2d_CMS_bio_stream, i2d_PKCS7_bio and > BIO_free all return 1 for success or 0 for failure. The old check > for a value less than 0 would never catch an error. > > I tried signing a kernel module with the patched sign-file and that > still worked. Can you forward your patch to upstream? Regards, Salvatore
Bug#1013728: mount: exfat filesystem mtime's are wrong
Control: tags -1 + moreinfo Hi, On Fri, Jun 24, 2022 at 04:56:12PM -0700, David Christensen wrote: > Package: src:linux > Version: 5.10.113-1 > Severity: normal > X-Debbugs-Cc: dpchr...@holgerdanske.com > > Dear Maintainer, > > Please see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001306 Thanks for the report. ideally you fill in all the detail in the bugreport without that we have to jump from one to the other ;-) That said, I assume you use the exfat driver from the kernel. For that see the recently commited: https://git.kernel.org/linus/9b002894b4c252169abc26720452bf3746114b20 Is this applying to you? That is until you can ue sys_tz option with 5.19-rc1 and later, setting time_offset can help. Regards, Salvatore
Uploading linux (5.18.5-1)
Hi I would like to upload linux version 5.18.5 to unstable. An ABI bump is included. The update includes stable imports from the previous version 5.18.2 up to the 5.18.5 version. Pending changes in the packaging are: * d/rules: Fix maintainerclean rule to not remove linux-perf files * d/watch: Fix typo in gitmode option * [arm64] drivers/gpu/drm/sun4i: Enable DRM_SUN6I_DSI as module (Closes: #1012288) * sound/pci/hda: Enable SND_HDA_SCODEC_CS35L41_I2C and SND_HDA_SCODEC_CS35L41_SPI as modules (Closes: #1012794) * Bump ABI to 2 * Drop "sign-file: Convert API usage to support OpenSSL v3" The last one is dropped until a solution is commited upstream. Regards, Salvatore signature.asc Description: PGP signature
Handing of debian/changelog on stable version imports
Hi Kernel team comaintainers, Usually when we do import stable updates targeting unstable, stable or oldstable and older we do some substantial work on cleaning up the debian/changelog. One part is adding references like CVE ids or bug closer, but the other part is as well filtering out things not relevant to Debian, unsupported architectures, or doing archtecture. We document it as - If you have time, please delete irrelevant changes such as: + Fixes for architectures not supported by the package + Fixes for drivers that aren't enabled in any of our configurations + Build fixes for configurations that we don't use + Fixes for lockdep false positives in debian/README.source. I believe this is a good thing and in fact helps a lot in triaging retrospectivel issues for instances. On the other hand for instance the 5.18.3 was so substantial with 800 commits upstream that it feels waste of free time for volunteers to gothrough and cleanup. So for the last update prepared I ignored e.g. the cleanup of irrelevant changes and the archtecture prefixes. How other feel about that? I would suggest/propose: whenever wer really ahve time, and as indicated in the README.source, but if time is scarse then stick with just importing the full changelog, but at a very minimum add known CVE identifers (helps the security team) and bug closer and wrap the line lenghts (debmutate can help). Does that sound fine for others? Regards, Salvatore
Bug#1012655: upstream bug and fix
Hi, On Wed, Jun 15, 2022 at 07:59:27PM +0200, Diederik de Haas wrote: > On Wednesday, 15 June 2022 17:40:45 CEST Stephan Verbücheln wrote: > > Kernel 5.18.4 got the patch. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/driver > > s/input/mouse/bcm5974.c?id=v5.18.4=v5.18.3 > > Excellent, thanks for mentioning that :-) > > > I will just use 5.17 or external mouse until the fix lands in Sid. > > My guess is that the next upload to Sid should have it then. This assumption is correct :) Regards, Salvatore
Uploading linux (5.18.2-1)
Hi I would like to upload linux version 5.18.2 to unstable. This is a new upstream version and therefore involves an ABI bump. Some CVE/security fixes are included, in particular CVE-2022-1966, CVE-2022-1972, CVE-2022-1852 and ZDI-CAN-17291. The pending changes in the package are apart the new upstream imports * [arm64,armel.marvell] Remove duplicate MTD_SPI_NOR config option * [arm64] Remove duplicate CAN_MCP251X config option * [x86] drivers/platform/x86: Enable SIEMENS_SIMATIC_IPC as module * [x86] drivers/leds: Enable LEDS_SIEMENS_SIMATIC_IPC as module * [x86] drivers/wdt: Enable SIEMENS_SIMATIC_IPC_WDT as module * [x86] Enable X86_ANDROID_TABLETS as a module * [arm64] Enable Xilinx PHY driver and SI5341 clock driver * [arm64] Enable COMMON_CLK_PWM which is needed for some Amlogic SBCs * [arm64] Enable Khadas MCU and fan * [arm64] cpufreq: Enable SCPI cpufreq driver * [arm64] cpuidle: Enable CONFIG_ARM_PSCI_CPUIDLE * drivers/firmware: Build ISCSI_IBFT as module on all architectures with ACPI. Thanks to Eric Mackay. (Closes: #1008933). * intel-iommu: Correct matching of the "intgpu_off" option value. Thanks to Markus Kolb. * random: Enable RANDOM_TRUST_BOOTLOADER. This can be reverted using the kernel parameter: random.trust_bootloader=off * [amd64] Enable X86_SGX. * block, loop: support partitions without scanning (Closes: #1012298) and from previous experimental uploads: * Rewrite "module: Avoid ABI changes when debug info is disabled" for 5.18 * In "firmware: Remove redundant log messages from drivers", adjust some filenames * In "x86: Make x32 syscall support conditional on a kernel parameter", update dependency from X86_X32 to X86_X32_ABI * Drop "bpftool: Fix version string in recursive builds" as redundant * bpftool: Prepend program version to the package version * [s390x] Enable MARCH_Z10 instead of MARCH_Z900, since support for z9 has been removed upstream * d/config: Update with the help of kconfigeditor2 * udeb: Move crc64 to crc-modules and make scsi-core-modules depend on that * libcpupower1: Update symbols file for 5.18 * d/copyright: Update filename of extract-cert.c * lintian: Add lintian-override to linux-perf for non-issue * d/bin/gencontrol.py, d/templates: Stop using templates for linux-perf * [rt] Update to 5.18-rt10 Regards, Salvatore signature.asc Description: PGP signature
Bug#1011168: linux-image-5.17.0-2-amd64: rebooting KVM guest crashes kernel
Hi, On Thu, Jun 02, 2022 at 08:56:48PM -0400, Jon wrote: > I did 5 reboots of the guest followed by 5 complete shutdown/startup > cycles of the guest. No kernel panics occurred. > > Based on how frequent the crashes were before, I would say thats a > succesful test. Many thanks for the confirmation. Regards, Salvatore
Bug#1011168: linux-image-5.17.0-2-amd64: rebooting KVM guest crashes kernel
Control: tags -1 + moreinfo On Sat, May 28, 2022 at 05:26:24PM -0400, Jon wrote: > I found a matching issue on the Arch Linux forum: > > https://bbs.archlinux.org/viewtopic.php?id=276648 > > Which ultimately links to this discussion on one of the kernel mailing > lists: > > https://lore.kernel.org/kvm/ynhalvjww6e94...@google.com/ > https://lore.kernel.org/kvm/20220504001219.983513-1-sea...@google.com/ > > And this commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d187ba5312307d51818beafaad87d28a7d939adf > > I haven't tested a custom build with the patch applied but I can confirm > that the server that I have crashing is an older box with an Intel Xeon > E5645 CPU that lacks XSAVE. > > And now that bug 1010916 has an updated backtrace attached its clear > that it is the same issue as this one. Can you try a custom build with the patch applied to report back if it fixes your issue? Cf. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 Regards, Salvatore
Uploading linux (5.17.11-1)
Hi I would like to upload linux version 5.17.11-1 to unstable. Since openssl transition is ongoing I'm as well explicity CC'ing Sebastian Andrzej Siewior. It imports new stable versions up to 5.17.11, including fixes for CVE-2022-1012, CVE-2022-1729, CVE-2022-1734 and CVE-2022-21499. An ABI bump is included. Additional packaging changes are: * [x86] sound/soc/amd: Enable SND_SOC_AMD_ACP5x, SND_SOC_AMD_VANGOGH_MACH, SND_SOC_AMD_ACP6x and SND_SOC_AMD_YC_MACH as modules (Closes: #1010580) * [ppc64*] crypto: Enable CRYPTO_CRC32C_VPMSUM as module (Closes: #1010293) * drivers/net/wwan: Enable MHI_WWAN_MBIM as module (Closes: #1011395) * Bump ABI to 3 * sign-file: Convert API usage to support OpenSSL v3 Regards, Salvatore signature.asc Description: PGP signature
Bug#1011295: linux: Add support for Areca ARC-1886 series RAID controllers
Source: linux Version: 4.19.235-1 Severity: normal Tags: buster X-Debbugs-Cc: car...@debian.org In 4.19.y in buster systems with Areca ARC-1886 series RAID controllers cannot be supported. Please consider backporting the required support as well back to buster. The commits adding support up to upstream https://git.kernel.org/linus/ae897ae28f9a1da2e04779a16f0a1112804a58fb are conained already in buster (inclusive a followup commit https://git.kernel.org/linus/d9a231226f28261a787535e08d0c78669e1ad010 which got backported to 5.10.52 as well from 5.14-rc1). Merge request for review (a second pair of eyes is needed): https://salsa.debian.org/kernel-team/linux/-/merge_requests/478 Regards, Salvatore
Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Source: linux Source-Version: 5.17.6-1 On Fri, May 13, 2022 at 09:38:37AM +0200, Petra R.-P. wrote: > Hello Diederik, > > Thanks for the good news: > > On Fri 13 May 2022 at 02:19:44 +0200 Diederik de Haas > wrote: > > [...] > > > Francesco reported that the issue was fixed for him in 5.17.0-2-686 which > > corresponds to 5.17.6 upstream kernel. > > Petra & Axel: can you verify whether it is also fixed for you? > > I downloaded > http://ftp.de.debian.org/debian/pool/main/l/linux-signed-i386/linux-image-5.17.0-2-686_5.17.6-1_i386.deb > and installed it with "dpkg -i" on both T41 Thinkpads, and they > both rebooted (and are now working) flawlessly :-)) > > Thanks to all who have contributed to this solution! Awesome, thanksfor confirming! Regards, Salvatore
Bug#1010733: linux-image-5.10.0-13-amd64: see Bug 215079 no sound after dist-upgrade - Thinkpad specific
Control: tags -1 + moreinfo Hi On Sun, May 08, 2022 at 01:39:13PM -0400, william wrote: > Package: src:linux > Version: 5.10.106-1 > Severity: important > X-Debbugs-Cc: piob...@mindspring.com > > Dear Maintainer, > > > >* What led up to the situation? > did an "apt-get dist-upgrade" from Buster to Bullseye >* What exactly did you do (or not do) that was effective (or > ineffective)? > pavucontrol does not report any input or output devices > audacity successfully records from an external (USB) microphone > Rebooted the machine. At bootup, scrolled down to boot from Buster instead of > Bullseye > Booting from Buster provided sound output. Note: The Thinkpad internal > microphone has never worked with Debian. Audacity reports that it is there, > but fails to record. > lspci reports "00:1f.3 Audio device: Intel Corporation Cannon Point-LP High > Definition Audio Controller (rev 11)" >* What outcome did you expect instead? > Expected the OS to recognize the internal microphone and speaker > *** End of the template - remove these template lines *** Please be a bit more specific next time about "Bug 215079" ;-). I suspect you mean https://bugzilla.kernel.org/show_bug.cgi?id=215079 ? Regards, Salvatore
Bug#998627: linux: please enable the new NTFS3 driver in 5.15
Hi, On Sun, Mar 20, 2022 at 10:25:23PM +0100, Ben Hutchings wrote: > On Fri, 2022-03-18 at 20:58 +0100, lenni_na1 wrote: > > Hi, > > > > are there any news on this? > > > > We are now at kernel 5.16 in testing and as far as I can tell the ntfs3 > > driver still hasn't been enabled. > > The recent traffic on the ntfs3 list seems to consist of bug reports > and small fixes, none of them being addressed by the supposed > maintainer of the filesystem (who last posted at the end of November). > > I think that we would be doing our users a disservice by enabling ntfs3 > in this state. In meanwhile the current state of NTFS3 driver has been discussed upstream starting in https://lore.kernel.org/lkml/da20d32b-5185-f40b-48b8-2986922d8...@stargateuniverse.net/ . Regards, Salvatore
Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Hi,
On Thu, Apr 28, 2022 at 12:04:50AM +0200, Francesco C wrote:
> Hi ,
>
> 5.16 series is EOL so I've just continued to do tests with vanilla
> linux-5.17.4 and linux-5.17.5 : both do not boot and stop at the same
> point as indicated in the messages above _but_ ... something strange
> is happening also with longterm 5.15 series since version 5.15.35 and
> 5.15.36 do not boot too.
Now this gives us probably a good hint!
https://bugzilla.kernel.org/show_bug.cgi?id=215909
d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state")
and a followup commit bfe55a1f7fd6 ("ACPI: processor: idle: fix lockup
regression on 32-bit ThinkPad T40") were both applied to 5.15.35. I
suspect the former is the one so which causes the regression as well
for you.
If someone can can check if reverting the commit d6b88ce2eb9d helps,
this might need a similar solution for your problem as it was done for
the ThinkPad T40.
Regards,
Salvatore
Bug#1010146: modprobe: ERROR: could not insert 'amd_pstate': No such device
Hi, On Tue, Apr 26, 2022 at 03:50:21PM +0200, Vincent Blut wrote: > Package: src:linux > Followup-For: Bug #1010146 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi Tobias, > > The AMD P-State driver has been enabled in linux 5.17.3-1 available in > testing/unstable. The kernel you are using does not include it. Additionally I think at this early stage at least, not all AMD CPUs are actually supporting it. IIRC, the initial commit talked only about some of the Zen3 based ones. Cf. https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html Regards, Salvatore
Bug#1009320: FW issue
On Sun, Apr 24, 2022 at 11:37:04AM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Sun, Apr 24, 2022 at 11:27:25AM +0200, Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > > > Hi, > > > > On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote: > > > It seems 5.17.x has problems with the respective FW (no problems with > > > prior kernels) > > > > > > dmesg output after trying to load list of broadcasters > > > * > > > [ 6801.250773] si2168 2-0064: downloading firmware from file > > > 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware > > > version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs > > > Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue > > > without a firmware. > > > ** > > > > Can you please verify it again with the current version in unstable > > (5.17.3-1). > > Actually, can you please try the attached patch? > > See > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > for instructions. amd64 builds with that patch applied (but note not signed!) can be found at: https://people.debian.org/~carnil/tmp/linux/5.17.3-1a~test/ if this can help testing. Offlist I got a reply that 5.17.4 seem to address the issue, so that would confirm possibly further the issue. Regards, Salvatore
Bug#1009320: FW issue
Hi,
On Sun, Apr 24, 2022 at 11:27:25AM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote:
> > It seems 5.17.x has problems with the respective FW (no problems with
> > prior kernels)
> >
> > dmesg output after trying to load list of broadcasters
> > *
> > [ 6801.250773] si2168 2-0064: downloading firmware from file
> > 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware
> > version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs
> > Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue
> > without a firmware.
> > **
>
> Can you please verify it again with the current version in unstable
> (5.17.3-1).
Actually, can you please try the attached patch?
See
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
for instructions.
Regards,
Salvatore
>From 8c0dbed07b388e7d97cecc184099caf80067a7bc Mon Sep 17 00:00:00 2001
From: Piotr Chmura
Date: Thu, 31 Mar 2022 17:55:50 +0200
Subject: [PATCH] media: si2157: unknown chip version Si2147-A30 ROM 0x50
commit 3ae87d2f25c0e998da2721ce332e2b80d3d53c39 upstream.
Fix firmware file names assignment in si2157 tuner, allow for running
devices without firmware files needed.
modprobe gives error: unknown chip version Si2147-A30 ROM 0x50
Device initialization is interrupted.
Caused by:
1. table si2157_tuners has swapped fields rom_id and required vs struct
si2157_tuner_info.
2. both firmware file names can be null for devices with
required == false - device uses build-in firmware in this case
Tested on this device:
m07ca:1871 AVerMedia Technologies, Inc. TD310 DVB-T/T2/C dongle
[mchehab: fix mangled patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215726
Link: https://lore.kernel.org/lkml/5f660108-8812-383c-83e4-29ee0558d...@leemhuis.info/
Link: https://lore.kernel.org/linux-media/c4bcaff8-fbad-969e-ad47-e2c487ac0...@gmail.com
Fixes: 1c35ba3bf972 ("media: si2157: use a different namespace for firmware")
Cc: sta...@vger.kernel.org # 5.17.x
Signed-off-by: Piotr Chmura
Tested-by: Robert Schlabbach
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/tuners/si2157.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 47029746b89e..0de587b412d4 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -77,16 +77,16 @@ static int si2157_cmd_execute(struct i2c_client *client, struct si2157_cmd *cmd)
}
static const struct si2157_tuner_info si2157_tuners[] = {
- { SI2141, false, 0x60, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
- { SI2141, false, 0x61, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
- { SI2146, false, 0x11, SI2146_11_FIRMWARE, NULL },
- { SI2147, false, 0x50, SI2147_50_FIRMWARE, NULL },
- { SI2148, true, 0x32, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2148, true, 0x33, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2157, false, 0x50, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
- { SI2158, false, 0x50, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2158, false, 0x51, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2177, false, 0x50, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
+ { SI2141, 0x60, false, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
+ { SI2141, 0x61, false, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
+ { SI2146, 0x11, false, SI2146_11_FIRMWARE, NULL },
+ { SI2147, 0x50, false, SI2147_50_FIRMWARE, NULL },
+ { SI2148, 0x32, true, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2148, 0x33, true, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2157, 0x50, false, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
+ { SI2158, 0x50, false, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2158, 0x51, false, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2177, 0x50, false, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
};
static int si2157_load_firmware(struct dvb_frontend *fe,
@@ -178,7 +178,7 @@ static int si2157_find_and_load_firmware(struct dvb_frontend *fe)
}
}
- if (!fw_name && !fw_alt_name) {
+ if (required && !fw_name && !fw_alt_name) {
dev_err(>dev,
"unknown chip version Si21%d-%c%c%c ROM 0x%02x\n",
part_id, cmd.args[1], cmd.args[3], cmd.args[4], rom_id);
--
2.36.0
Bug#1009320: FW issue
Control: tags -1 + moreinfo Hi, On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote: > It seems 5.17.x has problems with the respective FW (no problems with > prior kernels) > > dmesg output after trying to load list of broadcasters > * > [ 6801.250773] si2168 2-0064: downloading firmware from file > 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware > version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs > Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue > without a firmware. > ** Can you please verify it again with the current version in unstable (5.17.3-1). Regards, Salvatore
Bug#1008585: linux-image-5.10.0-13-amd64: "clocksource:" log spam after 5.10.103-1 update
Control: tags -1 + moreinfo On Tue, Apr 12, 2022 at 08:49:38PM +0300, Vincas Dargis wrote: > It seems that this might be fixed in ~5.17, based on this [0] message in > thread that speaks about problem seemingly similar to mine: > > > Yes, I expect to submit it into the next merge window (not the current > > v5.16 merge window, but v5.17). However, if your situation is urgent, and > > if it works for you, I could submit it as a fix for an earlier regression. > > Although all that thread is beyond me to understand... > > [0] > https://lore.kernel.org/all/2021000414.GH641268@paulmck-ThinkPad-P17-Gen-1/ Would you be able to test the current kernel from unstable so we can confirm it's fixed in 5.17.3-1? Regards, Salvatore
Uploading linux (5.17.3-1)
Hi I would like to upload linux version 5.17.3-1 to unstable. This is a new upstream version and therefore involves an ABI bump. The pending changes in the package are apart the new upstream imports (some items dropped): * linux-kbuild: Include scripts/pahole-flags.sh (Closes: #1008501) * [x86] drivers/cpufreq: Enable X86_AMD_PSTATE as module (Closes: #1009302) * [rt] Update to 5.17.1-rt17 * Set ABI to 1 * tools: install perf python bindings (Closes: #860957) * d/bin/gencontrol_signed.py: Add support for pkg.linux.quick profile * lintian: Add lintian-overrides to linux-signed-* for non-issues * d/salsa-ci.yml: Don't disable signed code * d/certs: Add certificate and key to enable test signing in CI * d/salsa-ci.yml: Add jobs to build and test the signed packages * [arm64] Add nvmem-rockchip-efuse and phy-rockchip-inno-hdmi to fb-modules udeb. * [arm64] Enable HyperV support. (closes: #1007023) * Replace FB_HYPERV with DRM_HYPERV. * Allow disabling debug info by build profile. * [arm64] Make sure hyperv-daemons are actually build. * Add pkg.linux.nokerneldbg build profile that excludes kernel debug packages. * linux-kbuild: Build extract-cert in certs/ instead of scripts/ * d/rules.real: Pass C compiler options to user-space build in HOSTCFLAGS too * [riscv64] Add basic support for StarFive JH7100 RISC-V SoC: enable I2C_DESIGNWARE_PLATFORM, MFD_TPS65086, REGULATOR_TPS65086, SERIAL_8250_DW, SOC_STARFIVE Regards, Salvatore signature.asc Description: PGP signature
Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs
Control; tags -1 + moreinfo On Thu, Mar 04, 2021 at 10:43:23AM +0900, Ryutaroh Matsumoto wrote: > Package: src:linux > Version: 5.10.19-1 > Followup-For: Bug #977647 > Control: retitle -1 5.10.19 Debian kernel has mysterious tpm error in dmesg > Control: severity -1 minor > > Dear Maintainer, > > The boot failure problem originally reported as #977647 somehow gets fixed > in Debian kernel 5.10.19. > > The severity seems now minor. > It has still the mysterious dmesg error on tpm as follows. > The full dmesg log is attached. Do you still have the issues? Otherwise let's close this bug. Regards, Salvatore
Bug#1008299: linux-image-5.10.0-12-amd64: Last update of linux-image-5.10.0-12-amd64 break encrypted network on docker
Control: tags -1 + confirmed pending On Sat, Mar 26, 2022 at 10:54:39AM +, Ulrich Vandenhekke wrote: > Package: src:linux > Version: 5.10.103-1 > Severity: important > X-Debbugs-Cc: ulrich@gmail.com > > Dear Maintainer, > > After upgrading the last version of linux-image-5.10.0-12-amd64, my docker > swarm network stop working. After some research i found > related bug on : > * https://github.com/moby/moby/issues/30727 > * https://github.com/moby/moby/issues/43359 > > This is related to a fix of kernel: > * > https://lore.kernel.org/netdev/20220307082245.ga1791...@gauss3.secunet.de/T/ > > My production server is blocked to old kernel image or break state. Could you > please include this patch on a new image to resolve issue on the stable > version of debian. Thanks. This is now pending for the next upload and it was included in 5.10.107 upstream. Regards, Salvatore
Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Hi, On Sat, Mar 26, 2022 at 05:19:03PM +0100, Petra Rübe-Pugliese wrote: > On Sat 12 Mar 2022 at 21:31:38 +0100 Petra R.-P. > wrote: > > On Sat 05 Mar 2022 at 17:59:51 +0100 Petra R.-P. > > wrote: > > [...] > > > > The error persists also in linux-image-5.16.0-4-686 (5.16.12-1) . > > ... and in linux-image-5.16.0-5-686 (5.16.14-1) ... Thanks for constantly testing the new versions (there is 5.16.18-1 upcoming btw, or 5.17.1 in experiemntal). Do we have a report upstream already about this issue? Regards, Salvatore
Uploading linux (5.16.18-1)
Hi I would like to upload linux version 5.16.18-1 later today. It imports stable versions up to 5.16.18 and covers a set of CVE fixes: CVE-2022-0854, CVE-2022-0995, CVE-2022-1011, CVE-2022-1015, CVE-2022-1016, CVE-2022-1048, CVE-2022-26490, CVE-2022-27666. An ABI bump is included. One additional packaging change is included: * sound/pci/hda: Enable SND_HDA_CODEC_CS8409 as module (Closes: #1008122) Regards, Salvatore signature.asc Description: PGP signature
Bug#1006346: cloud.debian.org: bullseye AMIs don't boot on Amazon EC2 Xen instances with Enhanced Networking
Hi Noah, On Thu, Mar 17, 2022 at 09:54:30AM -0700, Noah Meyerhans wrote: > >From the upstream discussion on the linux-pci mailing list [*]: > > > Yes. My understanding is that the issue is because AWS is using older > > versions of Xen. They are in the process of updating their fleet to a > > newer version of Xen so the change introduced with Stefan's commit > > isn't an issue any longer. > > > > I think the changes are scheduled to be completed in the next 10-12 > > weeks. For now we are carrying a revert in the Fedora Kernel. > > > > You can follow this Fedora CoreOS issue if you'd like to know more > > about when the change lands in their backend. We work closely with one > > of their partner engineers and he keeps us updated. > > https://github.com/coreos/fedora-coreos-tracker/issues/1066 > > Ideally we can revert the upstream commit from the stable kernels, since > otherwise Debian users on AWS Xen instance types may be stuck using > older, unsafe kernels. Especially if we have time to include the change > in the upcoming bullseye and buster point releases. If the kernel > updates for those stable updates have already been built, though, it > might be too late to matter. By the time we publish our next kernel > builds, the AWS Xen update may be complete. Wehere one can track the update status for their Xen version directly or is following the above the only reference? How frequent is this particular combination of hardware/software? We have the change already applied for a while in bullseye, buster would be impacted new since the last update done for security fixes Are there workarounds for the affected users of this combination? I see some options listed in https://wiki.debian.org/Cloud/AmazonEC2Image/Bullseye If we revert the commit it reverts a fix for a bug with Marvell NVME devices. But we cannot just revert the commit for the cloud images. If we know something about the release schedule from Amazon to update their Xen instances (which is the way to move forward, since upstream won't revert the commit) then we should leave the status as it is for bullseye (and now for buster). For bullseye there is there is CVE-2022-0847 fixes they would need to pick up. Regards, Salvatore
Bug#1007725: linux-image-5.16.0-4-amd64: Intel Alder Lake-P audio device not detected correctly
Hi On Wed, Mar 16, 2022 at 10:19:41AM +, Sean Clarke wrote: > updated to kernel 5.17rc8 (needed for another bug I raised) and downloaded > version 1.9.3 of intel-signed sof-adl.ri from the SOF Project ( > https://github.com/thesofproject). > > The sound is now recognised, I can hear audio - when "test right" is played > no audio is observed, when "tet left" is selected both speaks appear to > work - so its working, but not quite. > > Who is responsible for packaging the firmware-sof-signed package? looks > like it needs updating. So this would be fixed in the 2.0 version as uploaded https://tracker.debian.org/news/1301129/accepted-firmware-sof-20-1-source-into-unstable/ ? Unfortunately there seems to have been a problem with that upload, as the arch:all packages are missing. Regards, Salvatore
Bug#1007144: linux-image-cloud-amd64: Network doesn't come up on AWS Xen-based EC2 instances (ex c4.large)
Control: tags -1 + moreinfo Hi, On Sat, Mar 12, 2022 at 01:21:23AM +, Reilly Brogan wrote: > Package: linux-image-cloud-amd64 > Severity: important > > Dear Maintainer, > > We recently noticed that instances using linux-image-5.10.0-11-amd64 and > newer and using Xen-based EC2 instances (such as m4.large, c4.large etc) > wouldn't join our Kubernetes clusters. We eventually figured out that > this was a kernel-related issue as older AMIs using an older kernel were > able to join the cluster. > > When this issue occurs the AWS console log for the instance doesn't show > any errors except that it's noticeable that the instance doesn't get an > IP address and is therefore not able to bootstrap itself. > > I bisected this issue and it was introduced in kernel 5.10.88 as commit > e5949933f313c9e2c30ba05b977a047148b5e38c "PCI/MSI: Mask MSI-X vectors > only on success", thus present in linux-image-5.10.0-11-amd64 which uses > the 5.10.92 kernel (and all newer versions of the package). > > I recommend reverting this commit in Bullseye and Buster (the > aforementioned commit is also in the 4.19 tree) and working with > upstream to get it fixed. > > How to reproduce: > 1. Start any recent AMD64 AMI (such as one from > https://wiki.debian.org/Cloud/AmazonEC2Image/Bullseye) on a c4.large > instance > 2. Attempt to SSH to the instance (which will hang) > 3. Observe in the AWS console logs that the instance did not receive an > IP address) Can you report this issue to upstream? Regards, Salvatore
Uploading linux (5.16.14-1)
Hi I would like to upload linux version 5.16.14-1 to unstable tomorrow. It imports 5.16.13, 5.16.14 including several CVE fixes (CVE-2022-0742, CVE-2022-23036, CVE-2022-23037, CVE-2022-23038, CVE-2022-23039, CVE-2022-23040, CVE-2022-23041, CVE-2022-23042, CVE-2022-23960, CVE-2022-24958). An ABI bump is included. One packaging change is included: * [arm64] Enable hyperv-daemons package. Regards, Salvatore signature.asc Description: PGP signature
Re: checking on bookworm freeze dates proposal
Hi Paul, On Tue, Mar 01, 2022 at 12:03:51PM +0100, Paul Gevers wrote: > Dear colleagues, > > The Release Team would like to propose a bookworm freeze timeline. Don't > worry, the timeline is a plan, if serious (timing) issues come up we will > adapt. However, before making the plan public in a wider audience, we'd like > to know from you if you already foresee clashes in timing from the kernel, > gcc, binutils and glibc that we should take into account. Does the following > timeline seem reasonable to you considering plans of your upstream? > > (the bullseye schedule + 2 years): > 2023-01-12 - Milestone 1 - Transition and Toolchain freeze > 2023-02-12 - Milestone 2 - Soft Freeze > 2023-03-12 - Milestone 3 - Hard Freeze > TBA- Milestone 4 - Full Freeze For the kernel-team: We need to pick for the bookworm release again a longterm maintenance release. This means the following: Greg will usually pick the "last" released kernel of the year to be the LTS one. It is thus not that important how many stable released already happened for that particular brnach as it will the longterm maintained. But we defintively need to pick the correct one on this regard. Regards, Salvatore
Bug#801067: nfs-common: Remove or updated README.Debian.nfsv4
Source: nfs-utils Source-Version: 1:2.6.1-1 On Mon, Oct 05, 2015 at 09:32:39PM +0100, Reuben Thomas wrote: > Package: nfs-common > Version: 1:1.2.8-6ubuntu1.1 > Severity: normal > > The README.Debian.nfsv4 file is now rather old; is NFSv4 really still > considered experimental? > > Parts of this file may be worth keeping (I???m not an expert!), but at least > that claim should be removed, and mention of kernel versions and patch sets. We have removed the outdated README.Debian.nfsv4 in the 1:2.6.1-1 upload. Regards, Salvatore
Bug#1006500: Missing bnx2x firmware 7.13.21.0 renders NIC unusable with Linux 5.16
Hi, On Sat, Feb 26, 2022 at 12:37:55PM +, Etienne Dechamps wrote: > Package: firmware-bnx2x > Version: 20210818-1 > Severity: grave > > On Linux 5.16, the bnx2x module requests firmware 7.13.21.0: > > # modinfo bnx2x > filename: > /lib/modules/5.16.0-2-amd64/kernel/drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko > firmware: bnx2x/bnx2x-e2-7.13.21.0.fw > firmware: bnx2x/bnx2x-e1h-7.13.21.0.fw > firmware: bnx2x/bnx2x-e1-7.13.21.0.fw > > This firmware is not present in the firmware-bnx2x package. > > Now, my understanding is that the bnx2x module can fall back to an > earlier version (7.13.15.0) as needed, but in practice that might not > actually help, because update-initramfs only looks for the firmware > version from the module information and doesn't include any other > version: > > # update-initramfs -u > W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e2-7.13.21.0.fw > for module bnx2x > W: Possible missing firmware > /lib/firmware/bnx2x/bnx2x-e1h-7.13.21.0.fw for module bnx2x > W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e1-7.13.21.0.fw > for module bnx2x > > Since no firmware is included in the initramfs, the bnx2x module > unsurprisingly fails to initialize on boot: > > kernel: bnx2x :02:00.1: firmware: failed to load > bnx2x/bnx2x-e2-7.13.21.0.fw (-2) > kernel: bnx2x :02:00.1: Direct firmware load for > bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2 > kernel: bnx2x :02:00.1: firmware: failed to load > bnx2x/bnx2x-e2-7.13.15.0.fw (-2) > kernel: bnx2x :02:00.1: Direct firmware load for > bnx2x/bnx2x-e2-7.13.15.0.fw failed with error -2 > > Adding insult to injury, it doesn't look like it's possible to recover > from this state - as far as I could tell, once bnx2x fails to > initialize, it's game over until the next reboot, even if the module > is unloaded and reloaded, and even if the PCI device is removed and > rescanned. > > This basically means that, when booting current Debian Unstable with > Linux 5.16, bnx2x NICs become *permanently unusable*, potentially > locking users and admins out of the system. > > My suggested short-term fix would be to update the firmware-bnx2x > package to include the 7.13.21.0 firmware version. There's also a > discussion to be had with regard to update-initramfs, which should > perhaps try harder to find potentially compatible firmware versions - > indeed, if update-initramfs had included 7.13.15.0, I believe this > issue would have been avoided. > > For those affected, here's the workaround I used: > > 1. Manually download the 7.13.21.0 firmware files from > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/bnx2x > 2. Put the files in /lib/firmware/bnx2x > 3. Run update-initramfs -u > 4. Reboot Unless mistaken, there is the kernel side of this issue upstream https://bugzilla.kernel.org/show_bug.cgi?id=215627 which was fixed in 5.17-rc6[1], and got backported as well to 5.16.12 (and so in the next unstable upload). [1]: https://git.kernel.org/linus/e13ad1443684f7afaff24cf207e85e97885256bd Regards, Salvatore
Bug#1002537: linux-image-5.15.0-2-rt-amd64: RT kernel does not support touchpad/trackpoint on Thinkpad L15
Source: linux Source-Version: 5.17~rc6-1~exp1 Hi, On Fri, Mar 04, 2022 at 06:40:43PM +0100, Sebastian Andrzej Siewior wrote: > control: tags -1 - moreinfo > control: fixed -1 5.17~rc6-1~exp1 > > On 2022-01-16 17:04:57 [+0100], Salvatore Bonaccorso wrote: > > Hi Michael, > Hi Salvatore, > > > Where you by chance already able to test this? > > Just some updates: > - The issue is going to be addressed by >https://lore.kernel.org/all/20220211181500.1856198-1-bige...@linutronix.de > > - The series will hit v5.18 > > - The series is part of v5.17-rc5-rt9, was backported to v5.15.25-rt33 > and will also make into to the other maintained trees. > > I guess this closes the case. I did internationally not close the bug. Thanks, I indeed forgot about to close the bug. Let's do that to keep BTS later on sensible state. Regards, Salvatore
Bug#1006689: does not purge cleanly
Control: tags -1 + moreinfo unreproducible Hi Marc, Thanks for your report. On Wed, Mar 02, 2022 at 02:19:32PM +0100, Marc Haber wrote: > Package: nfs-kernel-server > Version: 1:2.6.1-1 > Severity: normal > > Hi, > > I noticed that nfs-blkmap.service keeps failing on my notebook. Since > I'm not using NFS anyway, I found out that this service belongs to > nfs-kernel-server and tried to purge the package. This should be possible > since I dont have dependencies installed, but it fails: > > [4/4996]mh@drop:~ $ sudo apt purge nfs-kernel-server > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages will be REMOVED: > nfs-kernel-server* > 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. > After this operation, 650 kB disk space will be freed. > Do you want to continue? [Y/n] > (Reading database ... 492241 files and directories currently installed.) > Removing nfs-kernel-server (1:2.6.1-1) ... > Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not > loaded. > invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. > dpkg: error processing package nfs-kernel-server (--remove): > installed nfs-kernel-server package pre-removal script subprocess returned > error exit status 5 > dpkg: too many errors, stopping > nfs-mountd.service is a disabled or a static unit not running, not starting > it. > nfs-server.service is a disabled or a static unit not running, not starting > it. > nfsdcld.service is a disabled or a static unit not running, not starting it. > Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. > Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service > failed to load properly, please adjust/correct and reload service manager: > File exists > See system logs and 'systemctl status nfs-kernel-server.service' for details. > invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. > ○ nfs-kernel-server.service > Loaded: error (Reason: Unit nfs-kernel-server.service failed to load > properly, please adjust/correct and reload service manager: File exists) > Active: inactive (dead) > Warning: The unit file, source configuration file or drop-ins of > nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to > reload units. > Failed to restart nfs-kernel-server, ignoring. > Errors were encountered while processing: > nfs-kernel-server > Processing was halted because there were too many errors. > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) > 100 [5/4997]mh@drop:~ $ sudo apt purge nfs-kernel-server > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages will be REMOVED: > nfs-kernel-server* > 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. > After this operation, 650 kB disk space will be freed. > Do you want to continue? [Y/n] > (Reading database ... 492241 files and directories currently installed.) > Removing nfs-kernel-server (1:2.6.1-1) ... > Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not > loaded. > invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. > dpkg: error processing package nfs-kernel-server (--remove): > installed nfs-kernel-server package pre-removal script subprocess returned > error exit status 5 > dpkg: too many errors, stopping > nfs-mountd.service is a disabled or a static unit not running, not starting > it. > nfs-server.service is a disabled or a static unit not running, not starting > it. > nfsdcld.service is a disabled or a static unit not running, not starting it. > Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. > Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service > failed to load properly, please adjust/correct and reload service manager: > File exists > See system logs and 'systemctl status nfs-kernel-server.service' for details. > invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. > ○ nfs-kernel-server.service > Loaded: error (Reason: Unit nfs-kernel-server.service failed to load > properly, please adjust/correct and reload service manager: File exists) > Active: inactive (dead) > Warning: The unit file, source configuration file or drop-ins of > nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to > reload units. > Failed to restart nfs-kernel-server, ignoring. > Errors were encountered while processing: > nfs-kernel-server > Processing was halted because there were too many errors. > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) > 100 [6/4997]mh@drop:~ $ > > I was able to get rid of the package by emptying out the prerm > script, but that should be easier. I was not able to reproduce this behaviour and
Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted
Control: tags -1 + moreinfo Hi Josh, On Mon, Feb 21, 2022 at 04:31:39PM -0800, Josh Triplett wrote: > Package: src:linux > Version: 5.16.7-2 > Severity: normal > X-Debbugs-Cc: j...@joshtriplett.org > > I have an external ThinkPad USB keyboard: > > $ lsusb | grep -i keyboard > Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with > TrackPoint > > The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard: > > $ cat > /sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock > 1 > > However, this attribute appears inverted for this particular keyboard: > it seems to be 1 when FnLock is *disabled* and 0 when FnLock is > *enabled*. If you can reproduce this with either 5.16.10-1 (or later today 5.16.11-1) or the current version in experimental (5.17~rc4-1~exp1) would it be possible you report it upstream and keep us updated on the progress? Regards, Salvatore
Uploading linux (5.16.11-1)
Hi I would like to upload linux version 5.16.11-1 to unstable later today. It does import the 5.16.11 stable version update. It additionally closes #1005884, where the fix is included in 5.16.11. An ABI bump is included. One packaging change is included: * drivers/hid: Enable HID_NINTENDO as module and NINTENDO_FF as built-in (Closes: #1006275) Regards, Salvatore signature.asc Description: PGP signature
Bug#1006157: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko: [sparc64+ext4] reads see zeros w/ simultaneous write
Control: tags -1 + upstream Control: forwarded -1 https://marc.info/?l=linux-sparc=164539269632667=2 Hi Noah, On Tue, Feb 22, 2022 at 07:12:14PM -0800, Noah Misch wrote: > On Sun, Feb 20, 2022 at 03:31:27PM +0100, Salvatore Bonaccorso wrote: > > Unless mistaken this looks like to be an upstream issue, think would > > be better suited to directly report it upstream. Can you do so and > > keep us in the loop? > > https://marc.info/?t=16453926991 has my upstream report. Anatoly Pugachev > confirmed the behavior on sparc64 5.17.0-rc5, so I'm assuming this is not > Debian-specific. I will update this bug with any major news. Many thanks. Regards, Salvatore
Bug#1005884: iwlwifi bug fix
Hi Bernhard, On Tue, Feb 22, 2022 at 07:34:17AM +, Bernhard wrote: > Hello Holger > Hello Salvatore > > This bugfix also closes my installation report #1005693. > Do you think, you can release 5.16.10-2 with this bugfix in the next > days? > Without this bugfix, installation of sid with iwlwifi card present in > the system is not possible. Not sure yet. While I have already cherry-picked the respective commit (cf. https://salsa.debian.org/kernel-team/linux/-/commit/ec0760c7cc4bbaccc913df3e22fd3e296c519936) for the next upload, I'm actually pondering to move on the next stable import (5.16.11, to be released tomorrow). Regards, Salvatore
Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Control: tags -1 + moreinfo Hi On Sat, Feb 19, 2022 at 10:04:14PM +0100, Petra R.-P. wrote: > Package: src:linux > Version: 5.16.7-2 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > This new kernel version does not boot on two fairly similar > old IBM T41 Thinkpads. > > What reproducibly happens is as follows: > > After the lines > >Loading Linux 5.16.0-1-686 ... >Loading initial ramdisk ... > > the screen gets flushed, and I see: > >[ 4.xx] ata1.00: Read log 0x00 page 0x00 failed Emask 0x1 > > > The "xx" vary for every try. > > Then nothing else happens. > Ctrl-Alt-Del has no effect. > I have to reset the computer by pressing the button. > > On an old PC running the same kernel the same message "ata1.00: Read log ..." > appears, but then the boot process continues normally. > > linux-image-5.15.0-3-686, which I am using to write this > message, runs fine. Are you booting in quite mode? if yes, can you remote if from the kernel command line and see if you get more information on the screen? Got off-bug a report from someone with similar Hardware with similar symptoms. >From the failed boot, can you extract the kernel logs produced? Regards, Salvatore
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
Hi Dominique [dropping almost all recipients for this reply] On Sun, Feb 20, 2022 at 04:48:43PM +0100, Dominique Dumont wrote: > On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote: > > Does the system actually suspend? > > Not really. The screens looks like it's going to suspend, but it does come > back after 10s or so. The light mounted in the middle of the power button > does > not switch off. > > > Is this system S0i3 or regular S3? > > I'm not sure how to check that. After a bit of reading on the Internet [1], I > hope that the following information answers that question. Please get back to > me if that's not the case. > > Looks like my system supports both Soi3 and S3 > > $ cat /sys/power/state > freeze mem disk > > I get the same result running these 2 commands as root: > # echo freeze > /sys/power/state > # echo mem > /sys/power/state > > > Does this patch help by any chance? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i > > d=e55a3aea418269266d84f426b3bd70794d3389c8 > > yes, with this patch: > - the suspend issue is solved > - kernel logs no longer show messages like "failed to send message" or > "*ERROR* suspend of IP block failed" while suspending Okay great :). This commit landed in 5.16.8 for the 5.16.y series. I did upload 5.16.10-1 (but the signed packages are yet missing). Can you test this one to confirm the issue is fixed? Regards, Salvatore
Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot
Hi, On Sun, Feb 20, 2022 at 01:10:30AM +0100, Richard B. Kreckel wrote: > Hi Salvatore, > > On 19.02.22 20:31, Salvatore Bonaccorso wrote: > > Alright thank you for confirming that. Would it be possible that you > > as well build the kernel with > > https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94 > > applied on top to see if this resolved the issue? > > Yes that patch fixes it. Thanks for confirming, I will cherry-pick the commit for the next upload. Regards, Salvatore
Bug#1006157: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko: [sparc64+ext4] reads see zeros w/ simultaneous write
Control: tags -1 + moreinfo Hi Noah, On Sat, Feb 19, 2022 at 05:53:52PM -0800, Noah Misch wrote: > Package: src:linux > Version: 5.16.7-2 > Severity: normal > File: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko > > Dear Maintainer, > >* What led up to the situation? > > The context is an ext4 filesystem on a sparc64 host. I've observed > this with each of the three sparc64 kernels that I've tested. Those > kernels were 5.16.0-1-sparc64-smp (this report), 5.15.0-2-sparc64-smp, > and 4.9.0-13-sparc64-smp. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > See the included file for a minimal test program. It creates two > processes, each of which loops indefinitely. One opens a file, writes > 0x1 to a 256-byte region, and closes the file. The other process > opens the same file, reads the same region, and prints a message if > any byte is not 0x1. > > This thread has more discussion and a more-configurable test program: > https://postgr.es/m/flat/20220116071210.ga735...@rfd.leadboat.com > >* What was the outcome of this action? > > The program prints messages, at least ten per second. The mismatch > always appears at an offset divisible by eight. Some offsets are more > common than others. Here's output from 300s of runtime, filtered > through "sort -nk3 | uniq -c": > >1729 mismatch at 8: got 0, want 1 >1878 mismatch at 16: got 0, want 1 >1030 mismatch at 24: got 0, want 1 > 41 mismatch at 40: got 0, want 1 > 373 mismatch at 48: got 0, want 1 > 24 mismatch at 56: got 0, want 1 > 349 mismatch at 64: got 0, want 1 > 13525 mismatch at 72: got 0, want 1 > 401 mismatch at 80: got 0, want 1 > 365 mismatch at 88: got 0, want 1 > 1 mismatch at 96: got 0, want 1 > 32 mismatch at 104: got 0, want 1 > 34 mismatch at 112: got 0, want 1 > 19 mismatch at 120: got 0, want 1 > 34 mismatch at 128: got 0, want 1 > 253 mismatch at 136: got 0, want 1 > 149 mismatch at 144: got 0, want 1 > 138 mismatch at 152: got 0, want 1 > 1 mismatch at 160: got 0, want 1 > 4 mismatch at 168: got 0, want 1 > 7 mismatch at 176: got 0, want 1 > 4 mismatch at 184: got 0, want 1 > 1 mismatch at 192: got 0, want 1 > 83 mismatch at 200: got 0, want 1 > 58 mismatch at 208: got 0, want 1 >3301 mismatch at 216: got 0, want 1 > 2 mismatch at 232: got 0, want 1 > 1 mismatch at 248: got 0, want 1 > > If I run the program atop an xfs filesystem (still with sparc64), it > prints nothing. If I run it with x86_64 or powerpc64 (atop ext4), it > prints nothing. > >* What outcome did you expect instead? > > I expected the program to print nothing, indicating that the reader > process observes only 0x1 bytes. That is how x86_64+ext4 behaves. > > POSIX is stricter, requiring read() and write() implementations such > that "each call shall either see all of the specified effects of the > other call, or none of them" > (https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07). > ext4 does not conform, which may be pragmatic. However, with x86_64 > and powerpc64, readers see each byte as either its before-write value > or its after-write value. They don't see a zero in an offset that > will have been nonzero both before and after the ongoing write(). Unless mistaken this looks like to be an upstream issue, think would be better suited to directly report it upstream. Can you do so and keep us in the loop? Regards, Salvatore
reassign 1006166 to src:linux, bug 1006166 is forwarded to 1006166, tagging 1006166, closing 1006166 ...
reassign 1006166 src:linux 5.16.7-1 forwarded 1006166 https://gitlab.freedesktop.org/drm/intel/-/issues/4762 tags 1006166 + upstream fixed-upstream close 1006166 5.17~rc4-1~exp1 close 1006166 5.16.10-1 thanks
Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot
Hi Richard, On Sat, Feb 19, 2022 at 07:40:42PM +0100, Richard B. Kreckel wrote: > Hi, > > I'm running a AMD Ryzen 3 4300U with Radeon Graphics system and found > myself suddenly unable to boot linux-image-5.16.0-1-amd64 until a point > where I could log in. (linux-image-5.15.0-3-amd64 and previous versions > all had worked fine.) > > After reading your link > https://lore.kernel.org/stable/05b11936073c8d6b7a28c07cc...@stwm.de/, I > just removed the iwlwifi.ko module and it boots just fine now. Alright thank you for confirming that. Would it be possible that you as well build the kernel with https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94 applied on top to see if this resolved the issue? https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 gives the simple patching and building guide. Regards, Salvatore
Bug#1006127: wireless-regdb stable policy
Hi, On Sat, Feb 19, 2022 at 04:30:35PM +, Jiaxun Yang wrote: > > > 在 2022/2/19 16:27, Salvatore Bonaccorso 写道: > > Hi, > > > > On Sat, Feb 19, 2022 at 02:49:32PM +, Jiaxun Yang wrote: > > > Package: wireless-regdb > > > Version: 2021.08.28-1 > > > Severity: grave > > > > > > Dear Maintainer > > > > > > wireless-regdb stores regulation information for various regions. It's > > > importatnt to keep > > > it updated on every system to ensure legal compliance on user's system. > > > > > > For example, China resctrcted transmission power for 5150 - 5350 MHz to 20 > > > dBm, while > > > the version in stable is still using the old 23 dBm limitation. System > > > running stable can > > > be accused violation of laws. > > > > > > Thus this package needs to be a part of security update to all stable > > > release to prevent > > > legal issues for users. > > In avoidance of doubts, no this is not material to be shipped via a > > security update, but it can in fact be updated in stable through the > > stable point releases (and when needed updated earlier through the > > updates suites). > Hi, > > I see tzdata updates is shipping through security in strectch, I think > wireless-regdb is in similiar situation. You are mentioning stretch, which is supported by the LTS project. In fact this is true there, because for the LTS suite there is no point release approach. You will notice that tzdata for stable is released at point releases times, and when needed earlier through the updates suite, see for example https://lists.debian.org/debian-stable-announce/2021/10/msg2.html . Anyway, the point is it can be updated for stable, but the channel would be another one. It first should be updated in unstable and testing, and then the other suites can follow via the mentioned approach. HTH, Regards, Salvatore
Bug#1006127: wireless-regdb stable policy
Hi, On Sat, Feb 19, 2022 at 02:49:32PM +, Jiaxun Yang wrote: > Package: wireless-regdb > Version: 2021.08.28-1 > Severity: grave > > Dear Maintainer > > wireless-regdb stores regulation information for various regions. It's > importatnt to keep > it updated on every system to ensure legal compliance on user's system. > > For example, China resctrcted transmission power for 5150 - 5350 MHz to 20 > dBm, while > the version in stable is still using the old 23 dBm limitation. System > running stable can > be accused violation of laws. > > Thus this package needs to be a part of security update to all stable > release to prevent > legal issues for users. In avoidance of doubts, no this is not material to be shipped via a security update, but it can in fact be updated in stable through the stable point releases (and when needed updated earlier through the updates suites). Regards, Salvatore
Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot
Control: tags -1 + moreinfo Hi, On Wed, Feb 16, 2022 at 05:31:08PM +0100, Martin Dickopp wrote: > Package: src:linux > Version: 5.16.7-2 > Severity: important > > The following kernel oops is logged during system boot: > > Feb 16 16:50:11 feynman kernel: BUG: unable to handle page fault for address: > da732108 > Feb 16 16:50:11 feynman kernel: #PF: supervisor read access in kernel mode > Feb 16 16:50:11 feynman kernel: #PF: error_code(0x) - not-present page > Feb 16 16:50:11 feynman kernel: PGD 0 P4D 0 > Feb 16 16:50:11 feynman kernel: Oops: [#1] PREEMPT SMP NOPTI > Feb 16 16:50:11 feynman kernel: CPU: 13 PID: 158 Comm: kworker/13:1 Not > tainted 5.16.0-1-amd64 #1 Debian 5.16.7-2 > Feb 16 16:50:11 feynman kernel: Hardware name: Micro-Star International Co., > Ltd. MS-7B50/MPG Z390M GAMING EDGE AC (MS-7B50), BIOS 1.50 03/22/2019 > Feb 16 16:50:11 feynman kernel: Workqueue: events request_firmware_work_func > > (See complete log below for more context.) > > After that, the system does not boot to a point where login is possible. > Usually, the last systemd message is "Starting Disk Manager...", but it has > also stopped at different messages during multiple attempts. Attempts to > reboot cleanly also fail at this point. > > This issue does not occur with the previous kernel (Linux feynman > 5.15.0-3-amd64 #1 SMP Debian 5.15.15-2 (2022-01-30) x86_64 GNU/Linux). > > > -- Package-specific info: > ** Boot log > Feb 16 16:50:10 feynman kernel: microcode: microcode updated early to > revision 0xea, date = 2021-01-05 > Feb 16 16:50:10 feynman kernel: Linux version 5.16.0-1-amd64 > (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.2.0-16) 11.2.0, GNU ld > (GNU Binutils for Debian) 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 > (2022-02-09) > Feb 16 16:50:10 feynman kernel: Command line: > BOOT_IMAGE=/vmlinuz-5.16.0-1-amd64 root=/dev/mapper/vg-root ro kaslr > resume=UUID=42dbf7e1-3f03-4f21-bd60-dea41f596041 > Feb 16 16:50:10 feynman kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 > floating point registers' > Feb 16 16:50:10 feynman kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE > registers' > Feb 16 16:50:10 feynman kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX > registers' > Feb 16 16:50:10 feynman kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX > bounds registers' > Feb 16 16:50:10 feynman kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX > CSR' > Feb 16 16:50:10 feynman kernel: x86/fpu: xstate_offset[2]: 576, > xstate_sizes[2]: 256 > Feb 16 16:50:10 feynman kernel: x86/fpu: xstate_offset[3]: 832, > xstate_sizes[3]: 64 > Feb 16 16:50:10 feynman kernel: x86/fpu: xstate_offset[4]: 896, > xstate_sizes[4]: 64 > Feb 16 16:50:10 feynman kernel: x86/fpu: Enabled xstate features 0x1f, > context size is 960 bytes, using 'compacted' format. > Feb 16 16:50:10 feynman kernel: signal: max sigframe size: 2032 > Feb 16 16:50:10 feynman kernel: BIOS-provided physical RAM map: > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x-0x0009efff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x0009f000-0x000f] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x0010-0x3fff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x4000-0x403f] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x4040-0x7c6a6fff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x7c6a7000-0x7c6a7fff] ACPI NVS > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x7c6a8000-0x7c6a8fff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x7c6a9000-0x8e108fff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8e109000-0x8e58bfff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8e58c000-0x8e9ebfff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8e9ec000-0x8eb1dfff] ACPI NVS > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8eb1e000-0x8f61dfff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8f61e000-0x8f6fdfff] type 20 > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8f6fe000-0x8f6fefff] usable > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0x8f6ff000-0x8fff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0xe000-0xefff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0xfe00-0xfe010fff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0xfec0-0xfec00fff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0xfee0-0xfee00fff] reserved > Feb 16 16:50:10 feynman kernel: BIOS-e820: [mem > 0xff00-0x]
Bug#1006115: linux-image-amd64: System does not boot with 5.16
Control: severity -1 important Control: tags -1 + moreinfo On Sat, Feb 19, 2022 at 12:27:11PM +, Julien-Benjamin wrote: > Package: linux-image-amd64 > Version: 5.16.7-2 > Severity: critical > Justification: breaks the whole system > > After upgrading from 5.15 to 5.16 (testing branch), the system does > not boot anymore. > > I could not see any obvious reason as to why ; a quick and dirty > workaround is to boot with the 5.15 version via GRUB. >From the boot log you attached, it looks it goes far enough. Can you elaborate on the does not boot anymore? Where does it get stuck for you? Is it reacting on the console, and can you login? Can you login remotely? It might be similar to #1005884. What happens if you do not load the nvidia module tainting the kernel? Would it be possible that you test the kernel in unstable, as uploaded 5.16.10-1? (Note the signed packages are not yet available though). Regards, Salvatore
Uploading linux (5.16.10-1)
Hi I would like to upload linux version 5.16.10-1 to unstable, ideally later today. t does consist of imports of several 5.16.y stable versions released since the last upload. Fixes for CVE-2022-0435, CVE-2022-0487 and CVE-2022-0516 are included. An ABI bump is included. Additionally the following configuration has been enabled: * drivers/watchdog: enable CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT Regards, Salvatore signature.asc Description: PGP signature
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
Hi Alex, hi all In Debian we got a regression report from Dominique Dumont, CC'ed in https://bugs.debian.org/1005005 that afer an update to 5.15.15 based kernel, his machine noe longer suspends correctly, after screen going black as usual it comes back. The Debian bug above contians a trace. Dominique confirmed that this issue persisted after updating to 5.16.7 furthermore he bisected the issue and found 3c196f0510912645c7c5d9107706003f67c3 is the first bad commit commit 3c196f0510912645c7c5d9107706003f67c3 Author: Alex Deucher Date: Fri Nov 12 11:25:30 2021 -0500 drm/amdgpu: always reset the asic in suspend (v2) [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ] If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by: Luben Tuikov Acked-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) to be the first bad commit, see https://bugs.debian.org/1005005#34 . Does this ring any bell? Any idea on the problem? Regards, Salvatore
Bug#993091: linux: kernel oops on Olimex A20-OLinuXino-LIME2, Allwinner sun7i (A20)
Control: tags -1 + moreinfo Hi Andi, On Fri, Aug 27, 2021 at 01:14:23PM +0200, Andreas B. Mundt wrote: > Source: linux > Version: 5.10.46-4 > Severity: normal > X-Debbugs-Cc: a...@debian.org > > Dear Maintainer, hi all, > > after upgrading a A20-OLinuXino-LIME2 board to bullseye, I had problems with > the > network interface which could be solved by preparing a tweaked u-boot (c.f. > [1]). > However, a few hours later, a kernel oops happended and the board could not > be > reached from the LAN again: > > Aug 27 01:35:13 blackbox kernel: 8<--- cut here -!- > Aug 27 01:35:13 blackbox kernel: Unable to handle kernel paging request at > virtual address 800071e0 > Aug 27 01:35:13 blackbox kernel: pgd = e54385ff > Aug 27 01:35:13 blackbox kernel: [800071e0] *pgd=437cf003, *pmd= > Aug 27 01:35:13 blackbox kernel: Internal error: Oops: 8206 [#1] SMP ARM > Aug 27 01:35:13 blackbox kernel: Modules linked in: nft_counter(E) > ipt_REJECT(E) xt_set(E) xt_multiport(E) nft_compat(E) ip_set_hash_ip(E) > nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) > nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) > nf_nat(E) nf_conntrack(E> > Aug 27 01:35:13 blackbox kernel: libaes(E) xts(E) dm_crypt(E) dm_mod(E) > ledtrig_heartbeat(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) > crct10dif_common(E) pinctrl_axp209(E) axp20x_regulator(E) realtek(E) > dwmac_sunxi(E) stmmac_platform(E) stmmac(E) pcs_xpcs(E) phylink(E) ptp(E) > ahci_sunxi(E) libahci_plat> > Aug 27 01:35:13 blackbox kernel: CPU: 1 PID: 6862 Comm: fw_packets Tainted: G > C E 5.10.0-8-armmp-lpae #1 Debian 5.10.46-4 > Aug 27 01:35:13 blackbox kernel: Hardware name: Allwinner sun7i (A20) Family > Aug 27 01:35:13 blackbox kernel: PC is at 0x800071e0 > Aug 27 01:35:13 blackbox kernel: LR is at symbol_string+0xc0/0x104 > Aug 27 01:35:13 blackbox kernel: pc : [<800071e0>]lr : [] > psr: 600f0093 > Aug 27 01:35:13 blackbox kernel: sp : d331dcb0 ip : fp : d331dcf4 > Aug 27 01:35:13 blackbox kernel: r10: d331dd14 r9 : c17a7dc0 r8 : c11c9675 > Aug 27 01:35:13 blackbox kernel: r7 : d331dd90 r6 : r5 : c17a7dc0 > r4 : c17a79ef > Aug 27 01:35:13 blackbox kernel: r3 : r2 : r1 : 000c > r0 : c17a79fb > Aug 27 01:35:13 blackbox kernel: Flags: nZCv IRQs off FIQs on Mode SVC_32 > ISA ARM Segment user > Aug 27 01:35:13 blackbox kernel: Control: 30c5387d Table: 46bcb5c0 DAC: > feff7ef6 > Aug 27 01:35:13 blackbox kernel: Process fw_packets (pid: 6862, stack limit = > 0xb93a5a89) > Aug 27 01:35:13 blackbox kernel: Stack: (0xd331dcb0 to 0xd331e000) > Aug 27 01:35:13 blackbox kernel: dca0: > 0a00 c11c9675 d331dd04 > Aug 27 01:35:13 blackbox kernel: dcc0: d331dcf4 d331dcd0 c0483820 c04835c0 > c1c14d80 c17a79ef c11c9673 0002 > Aug 27 01:35:13 blackbox kernel: dce0: d331dd90 c11c9675 d331dd4c d331dcf8 > c08e79f4 c08e72b8 ff05 0a00 > Aug 27 01:35:13 blackbox kernel: dd00: c17a9500 c105ac9c 0400 c17a79c0 > d331dd2c ff05 0a00 09458db8 > Aug 27 01:35:13 blackbox kernel: dd20: c2ad496c 0400 c11c9644 > d35ce548 d35ce540 d331c000 00c5 > Aug 27 01:35:13 blackbox kernel: dd40: d331dd64 d331dd50 c08e7be0 c08e77cc > c17a7990 d331dd84 d331dd68 > Aug 27 01:35:13 blackbox kernel: dd60: c0e156e4 c08e7bd8 d331dd8c 09458db8 > d35ce548 d331dda4 d331dd98 > Aug 27 01:35:13 blackbox kernel: dd80: c0e23b84 c0e1562c c11c9644 c07cfa48 > 09458db8 d331de94 d331dda8 > Aug 27 01:35:13 blackbox kernel: dda0: c07cfa48 c0e23b74 d331ddec d331ddb8 > c0501b0c c0c03e38 0b7b90f2 00ff > Aug 27 01:35:13 blackbox kernel: ddc0: c0484678 c17e576c > > Aug 27 01:35:13 blackbox kernel: dde0: 0400 > c18f5550 c70c5880 > Aug 27 01:35:13 blackbox kernel: de00: > > Aug 27 01:35:13 blackbox kernel: de20: c000 > > Aug 27 01:35:13 blackbox kernel: de40: > > Aug 27 01:35:13 blackbox kernel: de60: > d331dee8 > Aug 27 01:35:13 blackbox kernel: de80: d35ce548 d35ce540 d331dea4 d331de98 > c07d3f78 c07cf878 d331debc d331dea8 > Aug 27 01:35:13 blackbox kernel: dea0: c0799650 c07d3f60 beb08418 d35ce540 > d331dee4 d331dec0 c06b5128 c0799610 > Aug 27 01:35:13 blackbox kernel: dec0: beb08418 b6f042e4 00c5 > c04002c4 d331c000 d331df94 d331dee8 > Aug 27 01:35:13 blackbox kernel: dee0: c06b5208 c06b5100 00400100 c3bc26c0 > d331c000 d331dfb0 > Aug 27 01:35:13 blackbox kernel: df00: d331c000 fe30 d331df2c d331df18 > c0e266f4 c0e25c94 e000
