Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
On Tue, 24 Aug 2021 17:02:06 +0100 Roger Lynn wrote: > Package: src:linux > Version: 5.10.46-4 > Severity: normal > File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko > > I've just upgraded this machine to Bullseye and it seems unable to load the > ethernet driver: > > [6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM > control > [6.566607] libphy: r8169: probed > [6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID > 0xc1071002, maybe realtek.ko needs to be added to initramfs? > [6.590372] r8169: probe of :02:00.0 failed with error -49 > [6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM > control > [6.592984] libphy: r8169: probed > [6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID > 0xc1071002, maybe realtek.ko needs to be added to initramfs? > [6.626342] r8169: probe of :03:00.0 failed with error -49 > > This is long after the filesystem has been mounted, so the initramfs should be > irrelevant, but I tried adding the realtek and r8169 modules to the initramfs > and the only difference was that the error was earlier in the boot sequence. > > The machine is 12 years old and has worked with every stable Debian release in > that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye > reports: > > [ 10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM > control > [ 10.616071] libphy: r8169: probed > [ 10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, > XID 281000c0, IRQ 25 > [ 10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, > tx checksumming: ko] > [ 10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM > control > [ 10.619251] libphy: r8169: probed > [ 10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, > XID 281000c0, IRQ 26 > [ 10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, > tx checksumming: ko] > ... > [ 17.134036] r8169 :02:00.0: firmware: direct-loading firmware > rtl_nic/rtl8168d-1.fw > [ 17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] > (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) > [ 17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] > (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) > [ 17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready > [ 20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow > control rx/tx > [ 20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > Thanks, > > Roger > A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in the PHY reporting an invalid PHY ID. Realtek / Gigabyte don't release errata information, therefore there's not much that can be done. In bugzilla.kernel.org you can find workarounds that helped for some users, else use the r8168 driver.
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On 8/24/2021 1:12 PM, Ben Hutchings wrote: On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote: On 5/24/2021 3:30 AM, Michael Biebl wrote: Hi Phillip Am 24.05.2021 um 06:19 schrieb Cyril Brulebois: trigger to cold plug all devices. Both scripts are set -e. The Xen Virtual Keyboard driver and at least one other driver have always failed to trigger due to having absurdly long modalias, but the error used to be ignored. The kernel now returns the error to udevadm So this is a change in behaviour in the kernel? What happens if you boot the installed system? Does udevadm trigger fail there as well? I feel a bit uneasy changing the udev start script this late in the release cycle (especially when it appears like covering up an issue someplace else). I'll let Marco make the judgement on this though, as he has the most experience with those udev udeb start scripts as the original author. Michael After reviewing Philip's message at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43 which seems to point to the root cause of this bug, I can add: On my Xen HVM DomU I see the absurdly long modalias for the Xen Virtual keyboard that seems to be causing this crash in sysfs at /sys/devices/virtual/input/input2/modalias But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would probably not result in an error in the udev script if this was also written as the modalias at /sys/devices/virtual/input/input2/modalias So the Xen virtual keyboard appears more than once in sysfs, and modalias is not the same in the different places. This seems to be a problem. They are two different devices, and they should have different modaliases. Linux has code for discovering devices on each kind of bus, including virtual buses, and that code creates "bus devices" such as vkbd-0. At this point the kernel doesn't know what the device is capable of. The modalias for a bus device carries some identifying information that can be used to select a driver module for it. The driver does know what the device is capable of, and how to use it. It will normally create one or more "class devices" that support a particular set of operations; in this case input device operations. Class devices typically don't have modaliases, since they don't need another layer of drivers on top. However, for input devices the modalias carries information about the device's capabilities. These may trigger loading of the evdev or joydev module. I understand the correct way to fix this bug is by modifying the Xxen virtual keyboard (and any other devices that might cause this crash) and not the start-udev script on the netinst installation media, which is so far the only available workaround. Hopefully Xen will accept a fix if we can come up with a fix. [...] I think a proper fix would be one of: a. If the Xen virtual keyboard driver is advertising capabilities it doesn't have, stop it doing that. b. Change the implementation of modalias attributes to allow longer values. It's not clear to me whether the Xen driver is advertising correctly or not. If it is, then the solution should be b, but that may be too disruptive a change to the kernel. So a reasonable workaround might be: c. Change the input subsystem to limit the length of the capabilities part of the modalias. Ben. So workaround c would not involve disruptions to the kernel or systemd? Workaround c seems too disruptive for stable to me, but maybe could go into unstable and eventually into testing. A problem with the approach of fixing this bug in the Xen keyboard driver is that the fix must be implemented in the underlying Dom0 system, which could be almost anything - another Linux distro or Debian stable or oldstable. Any fix upstream would probably get into a bullseye Dom0, but not oldstable Dom0, but perhaps it could be provided as a backport for anyone who is still on oldstable for their Xen Dom0. Anyway, I will look into the Xen virtual keyboard capabilities. The only capability I can think of that would be useful in this context is that it supports live migration of a VM through some sort of hot-swapping capability. If it has that capability, a workaround to support it would be good. But if it does not have that capability or if such a capability is not needed for a keyboard, then it should probably stop advertising itself as being able or needing to do that. Ultimately, it is up to Xen to decide if they are going to make changes to its virtual keyboard. Chuck
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote: > > Ben Hutchings writes: > > > I think a proper fix would be one of: > > > > a. If the Xen virtual keyboard driver is advertising capabilities it > >doesn't have, stop it doing that. > > b. Change the implementation of modalias attributes to allow longer > >values. > > > > It's not clear to me whether the Xen driver is advertising correctly or > > not. If it is, then the solution should be b, but that may be too > > disruptive a change to the kernel. So a reasonable workaround might > > be: > > > > c. Change the input subsystem to limit the length of the > >capabilities part of the modalias. > > The problem with a) is that the Xen keyboard is not a physical keyboard > and so it has no way of knowing what keys it actually has. It is a fake > input device designed to pass through whatever input the Xen hypervisor > sends down. As such, any key could come in. If it doesn't advertise > that it has all of these keys, then they would not be accepted by > libinput when the hypervisor sends them down. Right, that's what I feared. xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC, KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654 keys and 2362 bytes in the modalias. > This seems to be the heart of the problem: libinput was designed > assuming that all keyboards can and must report what keys are actually > present, and then libinput tries to cram that information into the > modalias rather than some other sysfs attribute as it should ( or not at > all... I still don't see how this information is actually supposed to be > useful to userspace ). I think modaliases aren't intended to be interpreted by user-space, other than processing wildcards when matching to modules. For input devices, the same information is available through other variables in the uevent, in a more compact form. The information *is* useful for user-space; e.g. in initramfs-tools we recognise keyboard devices and add their drivers to the initramfs but ignore other input devices. > As for b), the problem isn't with the modalias attribute itself, but > when the kernel tries to copy it into the environment block for the udev > callout. The environment block is only a single page, and so limited to > 4 KB. And that's for everything else that goes into the environment, > not just the modalias. Text-based sysfs attributes are limited to a page, but udev receives uevents through netlink, not sysfs. The current limit on the environment of a uevent appears to be 2 KB (UEVENT_BUFFER_SIZE defined in ). That seems like it *might* be easier to change, so long as user-space doesn't have a similar limit. I looked into systemd/udev, and it seems to use an 8 KB buffer for receiving uevents: https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 But as a first step I think increasing the kernel buffer size to 4 KB would be enough. Perhaps someone could test whether this patch to the domU kernel makes udev happier: --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ #define UEVENT_HELPER_PATH_LEN 256 #define UEVENT_NUM_ENVP64 /* number of env pointers */ -#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */ +#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */ #ifdef CONFIG_UEVENT_HELPER /* path to the userspace helper executed on an event */ --- END --- ? Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: PGP signature
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
Ben Hutchings writes: > I think a proper fix would be one of: > > a. If the Xen virtual keyboard driver is advertising capabilities it >doesn't have, stop it doing that. > b. Change the implementation of modalias attributes to allow longer >values. > > It's not clear to me whether the Xen driver is advertising correctly or > not. If it is, then the solution should be b, but that may be too > disruptive a change to the kernel. So a reasonable workaround might > be: > > c. Change the input subsystem to limit the length of the >capabilities part of the modalias. The problem with a) is that the Xen keyboard is not a physical keyboard and so it has no way of knowing what keys it actually has. It is a fake input device designed to pass through whatever input the Xen hypervisor sends down. As such, any key could come in. If it doesn't advertise that it has all of these keys, then they would not be accepted by libinput when the hypervisor sends them down. This seems to be the heart of the problem: libinput was designed assuming that all keyboards can and must report what keys are actually present, and then libinput tries to cram that information into the modalias rather than some other sysfs attribute as it should ( or not at all... I still don't see how this information is actually supposed to be useful to userspace ). As for b), the problem isn't with the modalias attribute itself, but when the kernel tries to copy it into the environment block for the udev callout. The environment block is only a single page, and so limited to 4 KB. And that's for everything else that goes into the environment, not just the modalias.
Bug#983357: Netinst crashes xen domU when loading kernel
On 5/24/2021 3:30 AM, Michael Biebl wrote: Hi Phillip Am 24.05.2021 um 06:19 schrieb Cyril Brulebois: trigger to cold plug all devices. Both scripts are set -e. The Xen Virtual Keyboard driver and at least one other driver have always failed to trigger due to having absurdly long modalias, but the error used to be ignored. The kernel now returns the error to udevadm So this is a change in behaviour in the kernel? What happens if you boot the installed system? Does udevadm trigger fail there as well? I feel a bit uneasy changing the udev start script this late in the release cycle (especially when it appears like covering up an issue someplace else). I'll let Marco make the judgement on this though, as he has the most experience with those udev udeb start scripts as the original author. Michael After reviewing Philip's message at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43 which seems to point to the root cause of this bug, I can add: On my Xen HVM DomU I see the absurdly long modalias for the Xen Virtual keyboard that seems to be causing this crash in sysfs at /sys/devices/virtual/input/input2/modalias But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would probably not result in an error in the udev script if this was also written as the modalias at /sys/devices/virtual/input/input2/modalias So the Xen virtual keyboard appears more than once in sysfs, and modalias is not the same in the different places. This seems to be a problem. I understand the correct way to fix this bug is by modifying the Xxen virtual keyboard (and any other devices that might cause this crash) and not the start-udev script on the netinst installation media, which is so far the only available workaround. Hopefully Xen will accept a fix if we can come up with a fix. I am willing to try to debug this by testing patches to the Xen virtual keyboard, and anyone who has any tips on how udev works would be helpful. Is there documentation in udev for device developers somewhere to consult that explains how to update old device drivers so they are compatible with the modern version? Does the Xen virtual keyboard need to be managed by udev? Is there a simple way to disable incompatible devices so udev ignores them? Chuck Zmudzinski
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote: > On 5/24/2021 3:30 AM, Michael Biebl wrote: > > Hi Phillip > > > > Am 24.05.2021 um 06:19 schrieb Cyril Brulebois: > > > > trigger to cold plug all devices. Both scripts are set -e. The Xen > > > > Virtual Keyboard driver and at least one other driver have always > > > > failed > > > > to trigger due to having absurdly long modalias, but the error used to > > > > be ignored. The kernel now returns the error to udevadm > > > > So this is a change in behaviour in the kernel? > > What happens if you boot the installed system? Does udevadm trigger > > fail there as well? > > > > I feel a bit uneasy changing the udev start script this late in the > > release cycle (especially when it appears like covering up an issue > > someplace else). > > > > I'll let Marco make the judgement on this though, as he has the most > > experience with those udev udeb start scripts as the original author. > > > > Michael > > > > After reviewing Philip's message at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43 > > which seems to point to the root cause of this bug, I can add: > > On my Xen HVM DomU I see the absurdly long modalias for the Xen > Virtual keyboard that seems to be causing this crash in sysfs at > > /sys/devices/virtual/input/input2/modalias > > But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would > probably not result in an error in the udev script if this was also > written as the modalias at /sys/devices/virtual/input/input2/modalias > > So the Xen virtual keyboard appears more than once in sysfs, and > modalias is not the same in the different places. This seems > to be a problem. They are two different devices, and they should have different modaliases. Linux has code for discovering devices on each kind of bus, including virtual buses, and that code creates "bus devices" such as vkbd-0. At this point the kernel doesn't know what the device is capable of. The modalias for a bus device carries some identifying information that can be used to select a driver module for it. The driver does know what the device is capable of, and how to use it. It will normally create one or more "class devices" that support a particular set of operations; in this case input device operations. Class devices typically don't have modaliases, since they don't need another layer of drivers on top. However, for input devices the modalias carries information about the device's capabilities. These may trigger loading of the evdev or joydev module. > I understand the correct way to fix this bug is by modifying the > Xxen virtual keyboard (and any other devices that might cause > this crash) and not the start-udev script on the netinst > installation media, which is so far the only available workaround. > Hopefully Xen will accept a fix if we can come up with a fix. [...] I think a proper fix would be one of: a. If the Xen virtual keyboard driver is advertising capabilities it doesn't have, stop it doing that. b. Change the implementation of modalias attributes to allow longer values. It's not clear to me whether the Xen driver is advertising correctly or not. If it is, then the solution should be b, but that may be too disruptive a change to the kernel. So a reasonable workaround might be: c. Change the input subsystem to limit the length of the capabilities part of the modalias. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
firmware-nonfree_20210818-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 24 Aug 2021 17:46:21 +0200 Source: firmware-nonfree Architecture: source Version: 20210818-1 Distribution: unstable Urgency: medium Maintainer: Debian Kernel Team Changed-By: maximilian attems Closes: 992551 Changes: firmware-nonfree (20210818-1) unstable; urgency=medium . * New upstream version: - iwlwifi: add ty firmware from Core63-43 - qca: Add firmware files for BT chip WCN6750. - i915: Add v2.12 DMC for TGL - i915: Add v2.03 DMC for RKL - QCA : Updated firmware files for WCN3991 - linux-firmware: add firmware for MT7922 - linux-firmware: update frimware for mediatek bluetooth chip (MT7921) - linux-firmware: Update firmware file for Intel Bluetooth AX210 - amdgpu: update arcturus firmware from 21.30 - amdgpu: update green sardine firmware from 21.30 - amdgpu: update navi10 firmware from 21.30 - amdgpu: update navi12 firmware from 21.30 - amdgpu: update navi14 firmware from 21.30 - amdgpu: update sienna cichlid firmware from 21.30 - amdgpu: update navy flounder firmware from 21.30 - amdgpu: update dimgrey cavefish firmware from 21.30 - amdgpu: update picasso firmware from 21.30 - amdgpu: update polaris12 firmware from 21.30 - amdgpu: update raven firmware from 21.30 - amdgpu: update raven2 firmware from 21.30 - amdgpu: update renoir firmware from 21.30 - amdgpu: update vega10 firmware from 21.30 - amdgpu: update vega12 firmware from 21.30 - amdgpu: update vega20 firmware from 21.30 - amdgpu: add initial vangogh support - amdgpu: revert back to older picasso sdma firmware - amdgpu: revert back to older raven sdma firmware (closes: #992551) - amdgpu: revert back to older raven2 sdma firmware - ice: update package file to 1.3.26.0 Checksums-Sha1: 9d10ee6a9557c22aada27c0b3798ffb90fac33c5 3940 firmware-nonfree_20210818-1.dsc 85f5e5be04c3cab1a51f112154efd9e07bdbb6d2 129015316 firmware-nonfree_20210818.orig.tar.xz 4c3b7dbfb873e434c9b9a69e283f00205df56e00 821664 firmware-nonfree_20210818-1.debian.tar.xz 70d9f26c87dacf6f0d42ae5b0ac7a9b38d367ae5 12857 firmware-nonfree_20210818-1_amd64.buildinfo Checksums-Sha256: e89036c4808df034274d46e17d6cc4fa3f95995795173a09c5e014be8c90266b 3940 firmware-nonfree_20210818-1.dsc fccbdcf7c015d9dc7cbb01c90ee58d7b88b7460b2f29316987402715f82590a9 129015316 firmware-nonfree_20210818.orig.tar.xz fd8257d0358e97e5596959ca0d98a858632b00dbaed0be77453d88f052714a22 821664 firmware-nonfree_20210818-1.debian.tar.xz 71b79102d1d9cce86123b733bf40a4f07f7abbd84161bb6bc21c0c7fd7856928 12857 firmware-nonfree_20210818-1_amd64.buildinfo Files: 6f36e6e13f7147093ea5233c2a238486 3940 non-free/kernel optional firmware-nonfree_20210818-1.dsc 7b85a2be0b02479dd634df94cfdf 129015316 non-free/kernel optional firmware-nonfree_20210818.orig.tar.xz 14618c81707e64f6578914b642dbfa82 821664 non-free/kernel optional firmware-nonfree_20210818-1.debian.tar.xz 12c4b189f5a19a3111d382fc8aa3b5d3 12857 non-free/kernel optional firmware-nonfree_20210818-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEtitdpKMURvAU+NZkECUuZTqR5ScFAmElFgQACgkQECUuZTqR 5SeC4g//RQLe7GtDXT3ZNrHQXFbhkEYUh2WvHW3rVX4tDNzjFVDkJ+vmKgpeej4e qq6nKR0T1q0jtwCcUqgSQ+SAlt4zmiBYn1tRX2orZieCaCHgczoV+5BaFIojeFvt 4Elk3dx3eecQFAovM47FZtVS3nzaLtyGC0PgUgCUAsAQ2yPU83kdOH98RoF1BK1j nh6ZBvnRq5jKBLBgRRRxDjMFk94WxL0IS9JTh6GnFf0VGu+UqrkSpJtGenIC3N7B XAIiYFK/dd8rrvH4Ht+p+DmvEcNZAi/KN9PMgXlFyJnh6iz4dCaXoYjEYnC1jyJy +5ymXvU/e6IAhddJxcWij/K3PIxb39Cl/kKzkfEDkSTfcwIo2+75y+gfz8cSuSUF SrMzS9gIH+EcDX0nrDAwcfwp3uZQWP5UAXRZaboDWvmHhOC9a+AMO00kJFeXq21N G6ODu9N7PLSRoxPMCXncx3SGx6BM3AAwvLDWjLwTU2B3LdoGXg/W/mZN8bnO5hLq EBFcZNbcWymUIBDeBM+MQfBC6+oWDWD2LXMJdhWfnsiOyObOQ4biVuq6CaRyMvdT Dlm3FkouGB0dTXreQPrKWNA/C8RvnCb8TaTfsYLA8RT9mbbx95dYLKEtgNrd1qze rGAFwSl+uZeG5Y/HG+ddDS/67QRr9xMuD5kReRkF4aIGf+DNEWQ= =6Fw/ -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of firmware-nonfree_20210818-1_source.changes
firmware-nonfree_20210818-1_source.changes uploaded successfully to localhost along with the files: firmware-nonfree_20210818-1.dsc firmware-nonfree_20210818.orig.tar.xz firmware-nonfree_20210818-1.debian.tar.xz firmware-nonfree_20210818-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
Package: src:linux Version: 5.10.46-4 Severity: normal File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko I've just upgraded this machine to Bullseye and it seems unable to load the ethernet driver: [6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [6.566607] libphy: r8169: probed [6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.590372] r8169: probe of :02:00.0 failed with error -49 [6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [6.592984] libphy: r8169: probed [6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.626342] r8169: probe of :03:00.0 failed with error -49 This is long after the filesystem has been mounted, so the initramfs should be irrelevant, but I tried adding the realtek and r8169 modules to the initramfs and the only difference was that the error was earlier in the boot sequence. The machine is 12 years old and has worked with every stable Debian release in that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye reports: [ 10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.616071] libphy: r8169: probed [ 10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, XID 281000c0, IRQ 25 [ 10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.619251] libphy: r8169: probed [ 10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, XID 281000c0, IRQ 26 [ 10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] ... [ 17.134036] r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168d-1.fw [ 17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) [ 17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) [ 17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Thanks, Roger -- Package-specific info: ** Version: Linux version 5.10.0-8-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.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=cc5ea548-3370-40b7-b244-7fb88e5b310e ro radeon.dpm=1 quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: GA-MA790FXT-UD5P product_version: chassis_vendor: Gigabyte Technology Co., Ltd. chassis_version: bios_vendor: Award Software International, Inc. bios_version: F8n board_vendor: Gigabyte Technology Co., Ltd. board_name: GA-MA790FXT-UD5P board_version: ** Loaded modules: udp_diag tcp_diag inet_diag cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_ondemand uinput it87 hwmon_vid loop msr i2c_dev snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ax88179_178a usbnet snd_hda_codec_hdmi mii snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core edac_mce_amd snd_compress soundwire_cadence kvm_amd snd_hda_codec ccp r8169 rng_core snd_hda_core kvm firewire_ohci firewire_core snd_hwdep wmi_bmof realtek soundwire_bus mdio_devres libphy sr_mod crc_itu_t irqbypass snd_pcm snd_timer cdrom pcspkr ohci_pci ohci_hcd ata_generic snd sg ehci_pci ehci_hcd sp5100_tco watchdog pata_atiixp usbcore acpi_cpufreq soundcore button usb_common wmi i2c_piix4 k10temp ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common radeon i2c_algo_bit drm_kms_helper cec ahci ttm libahci libata drm evdev psmouse scsi_mod serio_raw ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 192.168.0.3 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.2 allow-hotplug eth1 iface eth1 inet static address 192.168.2.1 netmask 255.255.255.0 ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forev
linux-signed-i386_5.13.12+1~exp1_source.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 Aug 2021 22:39:29 +0200 Source: linux-signed-i386 Architecture: source Version: 5.13.12+1~exp1 Distribution: experimental Urgency: medium Maintainer: Debian Kernel Team Changed-By: Bastian Blank Changes: linux-signed-i386 (5.13.12+1~exp1) experimental; urgency=medium . * Sign kernel from linux 5.13.12-1~exp1 . * New upstream stable update: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.10 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.11 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.12 . [ Salvatore Bonaccorso ] * net: Enable MPTCP (Closes: #987815) . [ Bastian Blank ] * [mips*] Increase RELOCATION_TABLE_SIZE to 0x1c. * Enable SECURITY_LANDLOCK, SECURITY_PATH. * Fix external modules build. (closes: #992219) * Force more compressions modules into main installer package. (closes: #992221) * Drop redundant patch for overlay in user namespace. . [ Uwe Kleine-König ] * [x86] Enable X86_PLATFORM_DRIVERS_DELL which is needed to keep some Dell specific drivers. (Closes: #992251) Checksums-Sha1: 2fe14a789decbef3a802a396d707fe08943dea8c 14616 linux-signed-i386_5.13.12+1~exp1.dsc d457346a93df42d40da3eb84e0eef5d199245a91 2504188 linux-signed-i386_5.13.12+1~exp1.tar.xz Checksums-Sha256: 1862c7d1c253c1ae042eac8c5d866ce7d1e42ae0499f4b28976e778434404a33 14616 linux-signed-i386_5.13.12+1~exp1.dsc a9c3caead4a4f91c0268edb7a109e46e3fea481e1250f47f69f59138ab7a2a22 2504188 linux-signed-i386_5.13.12+1~exp1.tar.xz Files: cd715feea871f1a6f27d0de22e18e4ac 14616 kernel optional linux-signed-i386_5.13.12+1~exp1.dsc 4378bbbc92f6632162b76199558a1ba9 2504188 kernel optional linux-signed-i386_5.13.12+1~exp1.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmEk8JIACgkQi0FRiLdO NzZtOg/9FHYXbhJ8S/gsV9Z56KScXKhRdjvTlIXsqR7OLwuS55jW5pWHxbRGyZvE BzR/QeY+HGC6RmgsWxKzoaAx4BWWt8ZlKwJwNrzgR8QHPneGbh7MmX3Vx0KaKVAo M8+0vEYd8G6IqNYdQkVJLbsoHk++WyXJS50kLhTmHLDGZ7TJMy8zAIBm6ezhUlkk bTTLvFH/wsuU0rJSQn5LcnrypH3DauVpm5srq+8NI2QD7Zr2JsB4ymJbqvXD+0am Vb5MohKbk3gAa6MhheYYld6rtU1k3E0s7+M+IV216S9U9vEe3b2YLuRZMUdrjK22 VhVarNWFbXEJ/GmftWNVfntMuSV+q+yiSRwAVXaXb8xWeWSsfLAv2+p4nT1pVz1X 4R+fIg/z+Sxe31K3XKaR3xpIwktESrIJsSmkXfjFVrM3rkQAW1gjH6AR3JhrIo4D q572zg3l3kmausEmJUpC8b3U1rCH8gho9ItqR2nbUsYbbgpQ+rKjVnzRrenYhlqL zCbMsDyA3T+gBRe2c/2KLyBYyUuMgCnKEdnshVsWviydPp8O3nba64st/IVYtvwT 3c3GbBWFEpPB3Eq9K4Ky6i91+oi6qs0UFBSNfN/uhlDiEOZv3Ezxi36qgAso/ZfS xabxprj5b6o7E6DC/Y38mMDP0w/kbbtKk9Bcbzj3bporGmELWKk= =Ih5f -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of linux-signed-i386_5.13.12+1~exp1_source.changes
linux-signed-i386_5.13.12+1~exp1_source.changes uploaded successfully to localhost along with the files: linux-signed-i386_5.13.12+1~exp1.dsc linux-signed-i386_5.13.12+1~exp1.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#992866: Problem with mounting nfs shares after sudden poweroutage, fstab mount procedure jumbles nfs mounts
Package: linux-image-5.10.0-8-amd64 Version: 5.10 I am already experiencing this for the second time and i feel that this is a strange issue: I have an AMD Ryzen desktop PC with Debian Bullseye (before Buster) and a JBOD disk tower with four fully occupied slots. On my desktop i mount the 4 disks with ext4 file system as NFS shares via /etc/fstab, which used to work nicely before the most recent sudden power outage. After that the drives had to be checked and the inodes repaired. The file system of one disk in use was destroyed and restored through backup by copying the backup on the repaired disk. I also changed the file permissions and ownership after the copy procedure after a reboot. After that the mount procedure during system startup happening in /etc/fstab did not mount anymore my nfs shares correctly. The kernel mount procedure is waiting for 2 drives to mount and then jumbles the nfs mounts somehow. My /etc/fstab has this four entries related to the nfs shares: 10.10.10.2:/mnt/WD01 /mnt/WD01 nfs rw,auto,nofail 0 0 10.10.10.2:/mnt/WD02 /mnt/WD02 nfs rw,auto,nofail 0 0 10.10.10.2:/mnt/WD03 /mnt/WD03 nfs rw,auto,nofail 0 0 10.10.10.2:/mnt/WD04 /mnt/WD04 nfs rw,auto,nofail 0 0 and the actual mount in /proc/mounts lists like this 10.10.10.2:/mnt/WD04 /mnt/WD04 nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2 0 0 10.10.10.2:/mnt/WD03 /mnt/WD03 nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2 0 0 10.10.10.2:/mnt/WD02 /mnt/WD02 nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2 0 0 10.10.10.2:/mnt/WD03 /mnt/WD01 nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2 0 0 One can see that /mnt/WD03 gets mounted under /mnt/WD01 and there is no mount entry for /mnt/WD01. The content of the two mounts seems to be that of /mnt/WD01 (WD01 is a hand-maintained mirror of /mnt/WD02). What is wrong here? Reboot does not change anything. This strange constellation is carried over from reboot to reboot and i don't know where i can find the run state or similar file that is jumbled up and that is transferring the wrong mount information from reboot to reboot. I looked in /var/run, /tmp aso. for files related to the kernel mount procedure and fstab. The mount procedure is waiting for 1,5 minutes for mounting WD01 and WD03 and then jumbles the mounts. The drives itself are okay on my Raspberry Pi 4 (Vanilla Debian Bullseye arm64 via image-specs script some days ago) nfs server 10.10.10.2 and exportfs also lists ok (10.10.10.1 exports are rw, others ro, other export options are sync and no_root_squash for all exports): /mnt/WD01 10.10.10.1 /mnt/WD02 10.10.10.1 /mnt/WD03 10.10.10.1 /mnt/WD04 10.10.10.1 /mnt/WD01 192.168.0.0/24 /mnt/WD01 192.168.1.0/24 /mnt/WD01 10.10.10.0/24 WD01 is exported into multiple IP adress spaces for my different router and network switch configurations. It was working nicely till yesterday before the sudden power outage and disk recovery. Exactly this problem happened to me with my old Debian Buster desktop installation and led to the same problem, when i had to replace a harddisk and after a power outage. It seems to be a recurring problem over the last decade of years as well as the famous pulseaudio sequencer problem. Greetings, Thomas Korimort.
linux-signed-arm64_5.13.12+1~exp1_source.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 Aug 2021 22:39:29 +0200 Source: linux-signed-arm64 Architecture: source Version: 5.13.12+1~exp1 Distribution: experimental Urgency: medium Maintainer: Debian Kernel Team Changed-By: Bastian Blank Changes: linux-signed-arm64 (5.13.12+1~exp1) experimental; urgency=medium . * Sign kernel from linux 5.13.12-1~exp1 . * New upstream stable update: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.10 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.11 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.12 . [ Salvatore Bonaccorso ] * net: Enable MPTCP (Closes: #987815) . [ Bastian Blank ] * [mips*] Increase RELOCATION_TABLE_SIZE to 0x1c. * Enable SECURITY_LANDLOCK, SECURITY_PATH. * Fix external modules build. (closes: #992219) * Force more compressions modules into main installer package. (closes: #992221) * Drop redundant patch for overlay in user namespace. . [ Uwe Kleine-König ] * [x86] Enable X86_PLATFORM_DRIVERS_DELL which is needed to keep some Dell specific drivers. (Closes: #992251) Checksums-Sha1: 0d596eff1da178f27a6a923c9f163533a62b385c 7322 linux-signed-arm64_5.13.12+1~exp1.dsc 4f20e9ce834714192e1429828ddff98e5089c3af 1470052 linux-signed-arm64_5.13.12+1~exp1.tar.xz Checksums-Sha256: 6facec01798b9c2dbd979221c33c229058afeb5d929484e561b0ceffc8e2fe5c 7322 linux-signed-arm64_5.13.12+1~exp1.dsc e50330ed9d1a188c8012658cdbe9a02f31002390b26ba81d875a8627d1cac67b 1470052 linux-signed-arm64_5.13.12+1~exp1.tar.xz Files: 0e839cb1c6bd36aa8feb9e6ce476bfb5 7322 kernel optional linux-signed-arm64_5.13.12+1~exp1.dsc 7e77f9f69d95781d7edfc3b0d7170829 1470052 kernel optional linux-signed-arm64_5.13.12+1~exp1.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmEk1cUACgkQi0FRiLdO NzZQWw/6AsFYHI1oKpEQcgTUl0od8IprTLo+yf7QOrmaak1E0x5OyxXiSy/d7zSz 9MeszdgMYCy6uO8sAYf7D6CAkhefOB6HB4BRnYwk6Ak0Pe1zN400f+27sBYjp32z vLAkBPmDaoujEygWPnVo2lgMJ8t+VI9cUzvpg3Gcnh110b4w5SX+Pys8gzRhcE7a +uSGvIJxrKt0KCYd5pbsik6EJrvOEOzw/GbA11OIU7xY7ZpL+j9Js5vetM+Ni2G0 VIdSkMG9XcfVBCosZIDGZ9WTFgP1GZquBbmLvQAMbX2lWY4X57JwoPonlL4Jqd4g uJeGvoP7VV2Xmc8ACAwPKXbAso3WNZIubMAt5wKHw3a2NKmjOV78qXEXIcK6B4hh hKXuFFhewh/hePZBwJ+3muJQDR3XL4hERyZICEALb0Ht2L0jCyauUY9fNK0E0UqJ XcCLn+BfGYVhj8Cge6/p7sjQgsAAExGqFlfQSqPgd8nBeZJdpIVHbtH89AmRSBUR 3MOiMyq5rlnJPFJhDMSDkj3XkouBNKbnKZao5B4M54BLZbG/ydFSl7VF2NB2zkDn +Q/UOjIzkWnpDmX8OFbAVDa4BMpg/tYuqkQkSfgxcRflUGd+sNXRIW/aoZnOMhLy 4zM++XfIErCBJFa5/zQ8u2jdhS5PM0SzDvHXQGmwiPBqaSbx8Qs= =xUmX -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of linux-signed-arm64_5.13.12+1~exp1_source.changes
linux-signed-arm64_5.13.12+1~exp1_source.changes uploaded successfully to localhost along with the files: linux-signed-arm64_5.13.12+1~exp1.dsc linux-signed-arm64_5.13.12+1~exp1.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Processed: Re: Processed: Re: Bug#992855: upgrade-reports: buster to bullseye, nvme logs make ttys messy.
Processing commands for cont...@bugs.debian.org: > # crap > reassign 992855 src:linux Bug #992855 [kernel] upgrade-reports: buster to bullseye, nvme logs make ttys messy. Warning: Unknown package 'kernel' Bug reassigned from package 'kernel' to 'src:linux'. Ignoring request to alter found versions of bug #992855 to the same values previously set Ignoring request to alter fixed versions of bug #992855 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 992855: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992855 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#992855: upgrade-reports: buster to bullseye, nvme logs make ttys messy.
Control: reassign -1 kernel
Hi,
Although as you said, it may be something else, as it's the kernel
logging this, I reassign to the kernel package, in the hope they are
more able to pinpoint where the problem lies.
Paul
On 24-08-2021 10:53, hox...@noramail.jp wrote:
> Package: upgrade-reports
> Severity: normal
>
> Dear maintainers,
>
> I've upgraded one of my buster 10.10 into bullseye 11.
>
> * Upgrading was mostly successfull.
>
> * As "buster" GNOME desktop it had almost no problem,
> and upgraded "bullseye" GNOME session seems fine for now.
>
> However, after rebooting the issue below stared on ttys.
>
> The machine has one NVMe and one SATA SSD (separated /home).
> The Entire system installed into LUKS2 encrypted LVM volumes.
> Mostly "main" packages except Intel microcode ("non-free").
>
> NVMe continual syslog messsage on terminal
> ==
>
> 1. kernel reports nvme RxErr related messages.
> 2. on any tty (even in rescue.target).
> 3. almost always (I/O access on NVMe seems to be a trigger).
>
> AFAIK, the reported device (WD BLACK NVMe) works fine
> and "nvme smartlog" have not reported any error in years.
>
> After bullseye upgrading kernel started this reporting on ttys.
>
> At the same time, "smartd" seems to have a minor systemd unit problem,
> and it also seems to start tracking NVMe just like below syslog sample
> (at the smartd starting log section).
> "smartd" in buster only monitored SATA SSD.
>
> I can not tell what actual package and/or whether that device caused this,
> posting this bug report to "upgrade-reports".
>
> Actual syslog (partially modified; DATETIME/HOSTNAME/SERIAL_NUMBER)
> -
>
> 1. Cold booted.
> 2. systemctl shows no error.
> 3. target was shifted during this log sampling (graphical, rescue, multiuser,
> graphical).
>
> syslog and my comments follow:
>
> Aug 23 19:50:27 hostname kernel: [0.289634] pci :01:00.0: [15b7:5002]
> type 00 class 0x010802
> Aug 23 19:50:27 hostname kernel: [0.289657] pci :01:00.0: reg 0x10:
> [mem 0xdf00-0xdf003fff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.289691] pci :01:00.0: reg 0x20:
> [mem 0xdf004000-0xdf0040ff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.718254] pci :01:00.0: Adding to
> iommu group 11
> Aug 23 19:50:27 hostname kernel: [1.020213] nvme nvme0: pci function
> :01:00.0
> Aug 23 19:50:27 hostname kernel: [1.029047] nvme nvme0: 4/0/0
> default/read/poll queues
> Aug 23 19:50:27 hostname kernel: [1.031074] nvme0n1: p1 p2 p3
>
> This NVMe contains EFI, /boot, and LUKS root filesystem except /home (in SATA
> SSD).
>
> Aug 23 19:50:27 hostname kernel: [ 15.626412] input: HDA Intel PCH
> HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input18
> Aug 23 19:50:27 hostname kernel: [ 15.626483] input: HDA Intel PCH
> HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input19
> Aug 23 19:50:27 hostname kernel: [ 15.626548] input: HDA Intel PCH
> HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input20
>
> The first NVMe RxErr reporting starts after the kernel dmesg (after sound
> subsystem).
>
> Aug 23 19:50:27 hostname kernel: [ 17.365057] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:50:27 hostname kernel: [ 17.365089] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:50:27 hostname kernel: [ 17.365117] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:50:27 hostname kernel: [ 17.365142] nvme :01:00.0:[ 0]
> RxErr
>
> Then, on any tty (regardless the login status),
> it keep showing that messages like this.
> DATETIME was modified but kernel timing is the real log.
>
> Aug 23 19:51:16 hostname kernel: [ 70.416916] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:51:16 hostname kernel: [ 70.417029] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:16 hostname kernel: [ 70.417145] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:16 hostname kernel: [ 70.417268] nvme :01:00.0:[ 0]
> RxErr
> Aug 23 19:51:17 hostname kernel: [ 71.693968] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:51:17 hostname kernel: [ 71.699967] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:17 hostname kernel: [ 71.701511] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:17 hostname kernel: [ 71.703040] nvme :01:00.0:[ 0]
> RxErr
> Aug 23 19:51:19 hostname kernel: [ 73.739331] pcieport :00:1b.0: AER:
> Corrected e
linux-signed-amd64_5.13.12+1~exp1_source.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 Aug 2021 22:39:29 +0200 Source: linux-signed-amd64 Architecture: source Version: 5.13.12+1~exp1 Distribution: experimental Urgency: medium Maintainer: Debian Kernel Team Changed-By: Bastian Blank Changes: linux-signed-amd64 (5.13.12+1~exp1) experimental; urgency=medium . * Sign kernel from linux 5.13.12-1~exp1 . * New upstream stable update: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.10 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.11 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.12 . [ Salvatore Bonaccorso ] * net: Enable MPTCP (Closes: #987815) . [ Bastian Blank ] * [mips*] Increase RELOCATION_TABLE_SIZE to 0x1c. * Enable SECURITY_LANDLOCK, SECURITY_PATH. * Fix external modules build. (closes: #992219) * Force more compressions modules into main installer package. (closes: #992221) * Drop redundant patch for overlay in user namespace. . [ Uwe Kleine-König ] * [x86] Enable X86_PLATFORM_DRIVERS_DELL which is needed to keep some Dell specific drivers. (Closes: #992251) Checksums-Sha1: a4532ce381ff386558e1619fc7ee2101fb337517 8657 linux-signed-amd64_5.13.12+1~exp1.dsc 44100fcf8b4b80797114e2905d6a2f552ec6f613 1619840 linux-signed-amd64_5.13.12+1~exp1.tar.xz Checksums-Sha256: e3ab693b8122bfee0e98c64ede0cb6bc13e5f0ee3ba84f32d10093a323c320ae 8657 linux-signed-amd64_5.13.12+1~exp1.dsc e1897c02fcc82f565fc5b25421ad32853533285005719cdbdd7b8de402a6b530 1619840 linux-signed-amd64_5.13.12+1~exp1.tar.xz Files: d6982eb47e8d1dba251d06aec393bf5a 8657 kernel optional linux-signed-amd64_5.13.12+1~exp1.dsc 99bb923afe5699ffd96325f7e661c52f 1619840 kernel optional linux-signed-amd64_5.13.12+1~exp1.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmEkxz8ACgkQi0FRiLdO NzaA5w/+KN/dSdoA4WU8re7C2w5tLw8q37XuRIzwIdpLWfhwD8LFiy+uwEJhd5uI s0/K1OKPMEwlryIlet47oRYr15qTMJg9s+UOrdTwnsG9iGGXKPkK7zs5u38Qxfbk Ax1spMmbI0ewCC+LnRLZiRHRZBxpaDr4XQZ8CFOUBkZ9h53glihu4IAzgqwZUeEm Ed6j+eoHZ+sy2oTJTV8d6xDyqxssk8Y84ViYVvsnGGyjeQjBGJzqLY1fd9tOJncE ZWz7vfCMRnQWsI+0+Hae5HSowlPCL45eURuwdar4Pyqx/YcED4xlHi6Om/hINjPx 2FVN1KGuhq19Cb5ZtClQ/kiTt2SqCI3YUc9EYrinyq2ilvcURyXRLf+Gddjl9eS7 eCTe7+lg+sB81kfYonUr51XFb/rsmSzwa8H8M+0JlSFQne+OInlXXbuD6FdtmLmb 83GvfbsEMxRuMYxucJPY6rxo2xjU2vp2mZ9fNnmPnOl6jbyTTK2SoPje842AyUH+ MuYr7Yh9wYzzKWo2J4ZR48q/HySihJoh10xzEe/mbJUX4v7rj+ua4+YuNqc91/wj 0wmrUFD24TT1bAN0unvWtHeSFJdgEUx74hswNG4FEwA6eEEUonTI2mCzvVJ7j+Ya YDvzvyct6xhFAN+TxaNNlMSphikSzHzLtb0rtKIEJjt4/fRBEx8= =EBNq -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of linux-signed-amd64_5.13.12+1~exp1_source.changes
linux-signed-amd64_5.13.12+1~exp1_source.changes uploaded successfully to localhost along with the files: linux-signed-amd64_5.13.12+1~exp1.dsc linux-signed-amd64_5.13.12+1~exp1.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#983357: Netinst crashes xen domU when loading kernel
On 5/25/2021 2:38 PM, Phillip Susi wrote: Michael Biebl writes: So this is a change in behaviour in the kernel? Yes, this commit fixed the kernel to report the error instead of silently failing: commit df44b479654f62b478c18ee4d8bc4e9f897a9844 Author: Peter Rajnoha Date: Wed Dec 5 12:27:44 2018 +0100 kobject: return error code if writing /sys/.../uevent fails Propagate error code back to userspace if writing the /sys/.../uevent file fails. Before, the write operation always returned with success, even if we failed to recognize the input string or if we failed to generate the uevent itself. With the error codes properly propagated back to userspace, we are able to react in userspace accordingly by not assuming and awaiting a uevent that is not delivered. Signed-off-by: Peter Rajnoha Signed-off-by: Greg Kroah-Hartman What happens if you boot the installed system? Does udevadm trigger fail there as well? Yes, it does; that is how I was able to track down the problem. I feel a bit uneasy changing the udev start script this late in the release cycle (especially when it appears like covering up an issue someplace else). I'll let Marco make the judgement on this though, as he has the most experience with those udev udeb start scripts as the original author. So far I have been removing the -e from the shbang line in the start-udev script and remastering the iso so I can get it to boot. It would probably be a better idea to just add a || true to the udevadm trigger call. I feel fairly certain that no matter what the cause of the coldplug failure, the user is going to be better off ignoring it and trying to proceed than a kernel panic. Hello, This bug was noticed on the debian-user list recently and I have been testing various workarounds and instead of removing -e from the shbang line I came up with prepending the udevadm trigger call in the start-udev script with dmesg | grep DMI: | grep 'Xen HVM domU' || This causes the offending udevadm trigger call to never be invoked when running in a Xen HVM DomU. On all other systems, the call should be invoked like normal. With this hack, I was able to create a modified ISO and run the bullseye installer from it in a Xen HVM DomU and complete an install without the crash and reboot. I also can confirm that I always see the coldplug failure on the installed system in a Xen HVM DomU, but in that case the failure does not cause a crash and the system boots normally after reporting the failure. I also do not see the problem in a Xen PV DomU, which I think is what the /install.amd/xen folder on the installation media is for. Chuck Zmudzinski
Bug#992832: linux-image-5.10.0-8-amd64: please enable CONFIG_AMD_PMC
Package: linux-image-5.10.0-8-amd64 Version: 5.10.46-4 Hi, amd-pmc is needed on recent AMD Ryzen laptops in order to properly enter s2Idle. Another module apparently relevant on recent Ryzen laptops is CONFIG_AMD_SFH_HID, although this PCI device is not present on my laptop. Thanks, Gedalya
