[Kernel-packages] [Bug 2038105] Re: Intel Graphic driver crash ( Mosaic mode )
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2038105 Title: Intel Graphic driver crash ( Mosaic mode ) Status in linux package in Ubuntu: Expired Bug description: With pentium G7400 ( UHD Intel 710 ) several times per day the screen is corrupted , tested on several screen , the client has to reboot the machine ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.2.0-33-generic 6.2.0-33.33~22.04.1 ProcVersionSignature: Ubuntu 6.2.0-33.33~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-33-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass Date: Mon Oct 2 15:14:06 2023 InstallationDate: Installed on 2023-08-10 (53 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-hwe-6.2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038105/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Alright, I will do what I did, if it comes up again. I will try to
augment our tests to include an apt upgrade with -proposed. Thank you.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1 d8 84 c0 75 11 eb 56 48 8b 7b 08 e8 6b 5e c1 d8 84 c0 75 17 f3
90 <48> 8b 7b 08 48 8d b5 6c ff ff ff e8 f5 71 c1 d8 48 85 c0 74 dc 48
[ 28.134326] RSP: 0018:9b0c4064f9b8 EFLAGS: 0246
[ 28.134720] RAX: RBX: 89dfc0d13980 RCX:
0a20
[ 28.135252] RDX: RSI: 9b0c4064f9bc RDI:
89dfc7cc00c0
[ 28.135787] RBP: 9b0c4064fa50 R08: 0001 R09:
0003
[ 28.136316] R10: 0003 R11:
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
You can file a bug just like you did. If you happen to do a bit more
debugging, then making sure it gets assigned to the correct package
helps.
For the kernel, always just file a new bug, unless someone has the same
issue as you and you can find the bug via google or the all bugs
category on the kernel package on launchpad.
For server packages like systemd, bind9, etc, its best to file those
issues against the package itself. You can review the changelog to see
what changed lately, and say, if the latest change causes a regression,
you can write a comment to the launchpad bug for that change instead of
filing a new report.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Looking at Jason Wang's commits, it seems like it must work at least a
little with qemu (because he committed it) but either 1) not *that* well
or 2) someone else told him about trying to run firecracker or some
other VMM that more closely assumes the specification in this area,
since he modified it a couple of weeks later.
Indeed we could install the new kernel and give it a try, it's arguably
just a bit more complicated than "try this image URL" on a loop. We will
probably do something like that. What's the best way to file a bug if we
spot something doing that? Same way I did this one, or some other way? I
somehow was expecting to fill in a bit more optional structured metadata
when I filed (version, distro, etc)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170
[Kernel-packages] [Bug 2038998] Re: [amdgpu] Screen corruption, distorted geometry and misplaced triangles
> I might try to set the kernel parameter next. For clarification: I would add
> amdgpu.mcb=0 to
> GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and then run 'sudo
> update-grub' (or update-grub2?).
> Afterwards I can just reboot?
Yes that sounds correct other than a typo - it should be
"amdgpu.mcbp=0".
> BTW, just to rule other influences out: I do hibernate my system from time to
> time. This should not
> have any influence, or?
It might be a factor, if you can confirm it..?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2038998
Title:
[amdgpu] Screen corruption, distorted geometry and misplaced triangles
Status in GNOME Shell:
Fix Released
Status in linux package in Ubuntu:
Confirmed
Status in mesa package in Ubuntu:
Confirmed
Bug description:
Laptop is a Lenovo ThinkPad P14s Gen 2 AMD.
Ryzen 7 PRO 5850U
with Radeon (RX Vega 8?) integrated graphics
16 GB RAM
Running Ubuntu 23.10 (GNOME) from a clean install performed October 9,
2023 from a daily-live/current .iso generated on October 4, 2023.
Wayland
Kernel 6.5.0-9-generic
* * * * *
Installed a pre-release build of Ubuntu 23.10 to my ThinkPad the other
day, was going through setting up and testing the usual programs.
Installed Steam through apt from the 'mantic' repositories. Installed
Proton 8.0 and Steam Linux Runtime 3.0 (Sniper) alongside two
compatible titles.
Screen corruption (white and grey streaks) present in-game when GNOME
UI elements appeared on-screen (e.g., volume, brightness, and keyboard
backlight indicators) and omnipresent after closing either game.
Artifacts remain on screen until log-out or reboot. Artifacts were not
present beforehand.
Artifacts only appeared in Wayland session; not X11/Xorg.
I previously had been running the same games on Ubuntu 22.04 LTS
(GNOME, Wayland) and Kubuntu 22.04 LTS (Plasma, X11/Xorg) on this
computer without issue (kernel 6.2).
* * * * *
Please see subsequent posts for video/images.
Happy to provide any other information as needed. Thanks!
* * * * *
ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: unknown
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 11 01:17:43 2023
DistUpgraded: Fresh install
DistroCodename: mantic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon
Vega Mobile Series] [1002:1638] (rev d1) (prog-if 00 [VGA controller])
Subsystem: Lenovo Cezanne [Radeon Vega Series / Radeon Vega Mobile Series]
[17aa:509b]
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.5.0-9-generic
root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/15/2023
dmi.bios.release: 1.24
dmi.bios.vendor: LENOVO
dmi.bios.version: R1MET54W (1.24 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21A00068US
dmi.board.vendor: LENOVO
dmi.board.version: SDK0T76530 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.24
dmi.modalias:
dmi:bvnLENOVO:bvrR1MET54W(1.24):bd05/15/2023:br1.24:efr1.24:svnLENOVO:pn21A00068US:pvrThinkPadP14sGen2a:rvnLENOVO:rn21A00068US:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21A0_BU_Think_FM_ThinkPadP14sGen2a:
dmi.product.family: ThinkPad P14s Gen 2a
dmi.product.name: 21A00068US
dmi.product.sku: LENOVO_MT_21A0_BU_Think_FM_ThinkPad P14s Gen 2a
dmi.product.version: ThinkPad P14s Gen 2a
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.115-1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.2.1-1ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.7-3ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-3
version.xserver-xorg-video-intel: xserver-xorg-video-intel
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau
1:1.0.17-2build1
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/2038998/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to :
[Kernel-packages] [Bug 2045517] [NEW] Unify some HDA contoller PCIIDs and add new ID for Arrowlake-S
Public bug reported: >From kernel v6.6, HDA controller PCIIDs are sorted out and unified, and based >on it, added new PCIID and audio support for arrowlake-s, need to backport >them to oem-6.5, this is a preparation for supporting HP latest laptops: unified PCIIDs: PCI_DEVICE_ID_INTEL_HDA_ADL_N PCI_DEVICE_ID_INTEL_HDA_RPL_P_0 PCI_DEVICE_ID_INTEL_HDA_ADL_P PCI_DEVICE_ID_INTEL_HDA_RPL_S PCI_DEVICE_ID_INTEL_HDA_MTL new added PCIID: PCI_DEVICE_ID_INTEL_HDA_ARL_S ** Affects: linux (Ubuntu) Importance: High Assignee: Hui Wang (hui.wang) Status: New ** Affects: linux-oem-6.5 (Ubuntu) Importance: High Assignee: Hui Wang (hui.wang) Status: New ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: Invalid ** Affects: linux-oem-6.5 (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Affects: linux-oem-6.5 (Ubuntu Mantic) Importance: Undecided Status: Invalid ** Tags: oem-priority ** Also affects: linux-oem-6.5 (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-oem-6.5 (Ubuntu) Assignee: (unassigned) => Hui Wang (hui.wang) ** Changed in: linux-oem-6.5 (Ubuntu) Importance: Undecided => High ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-oem-6.5 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux-oem-6.5 (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux-oem-6.5 (Ubuntu Mantic) Status: New => Invalid ** Changed in: linux (Ubuntu Jammy) Status: New => Invalid ** Tags added: oem-priority ** Description changed: - From kernel v6.6, HDA controller PCIIDs are sorted out and unified, and based on it, added new PCIID and audio support for arrowlake-s, need to backport them to oem-6.5: + From kernel v6.6, HDA controller PCIIDs are sorted out and unified, and based on it, added new PCIID and audio support for arrowlake-s, need to backport them to oem-6.5, this is a preparation for supporting HP latest laptops: unified PCIIDs: PCI_DEVICE_ID_INTEL_HDA_ADL_N PCI_DEVICE_ID_INTEL_HDA_RPL_P_0 PCI_DEVICE_ID_INTEL_HDA_ADL_P PCI_DEVICE_ID_INTEL_HDA_RPL_S PCI_DEVICE_ID_INTEL_HDA_MTL new added PCIID: PCI_DEVICE_ID_INTEL_HDA_ARL_S -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2045517 Title: Unify some HDA contoller PCIIDs and add new ID for Arrowlake-S Status in linux package in Ubuntu: New Status in linux-oem-6.5 package in Ubuntu: New Status in linux source package in Jammy: Invalid Status in linux-oem-6.5 source package in Jammy: New Status in linux source package in Mantic: New Status in linux-oem-6.5 source package in Mantic: Invalid Bug description: From kernel v6.6, HDA controller PCIIDs are sorted out and unified, and based on it, added new PCIID and audio support for arrowlake-s, need to backport them to oem-6.5, this is a preparation for supporting HP latest laptops: unified PCIIDs: PCI_DEVICE_ID_INTEL_HDA_ADL_N PCI_DEVICE_ID_INTEL_HDA_RPL_P_0 PCI_DEVICE_ID_INTEL_HDA_ADL_P PCI_DEVICE_ID_INTEL_HDA_RPL_S PCI_DEVICE_ID_INTEL_HDA_MTL new added PCIID: PCI_DEVICE_ID_INTEL_HDA_ARL_S To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045517/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Great, so the fix works as intended. 5.15.0-91-generic should be
released to -updates this week hopefully.
I don't think the CPC team builds any cloud images with -proposed
enabled. I asked around, and I'll let you know if there does happen to
be some images built.
For the meantime you could launch a normal image and add a cloud-init
instruction to enable -proposed and do an apt upgrade, and then reboot,
and then you can run your tests from there.
The kernel team do a lot of validation every cycle, so I am kind of
surprised they didn't catch this bug.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1 d8 84 c0 75 11 eb 56 48 8b 7b 08 e8 6b 5e c1 d8 84 c0 75 17 f3
90 <48>
[Kernel-packages] [Bug 2044630] Re: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build
I've tested it and handed it off to Rick for him to look it over and test (second set of eyes)... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2044630 Title: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build Status in zfs-linux package in Ubuntu: Confirmed Bug description: On todays updates, zfs-dkms 2.1.5-1ubuntu6~22.04.2 failed to build kernel module. Genrated Crash report, but couldn't send it on it's own. Error it kept throwing was: >>> Setting up zfs-dkms (2.1.5-1ubuntu6~22.04.2) ... Loading new zfs-2.1.5 DKMS files... Building for 6.2.0-36-generic 6.2.0-37-generic Building initial module for 6.2.0-36-generic configure: error: *** None of the expected "iops->get_acl()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 *** Compatible Kernels: 3.10 - 5.19 ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/zfs-dkms.0.crash' Error! Bad return status for module build on kernel: 6.2.0-36-generic (x86_64) Consult /var/lib/dkms/zfs/2.1.5/build/make.log for more information. dpkg: error processing package zfs-dkms (--configure): installed zfs-dkms package post-installation script subprocess returned error exit status 10 >>> ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: zfs-dkms 2.1.5-1ubuntu6~22.04.2 ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-36-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sat Nov 25 21:00:27 2023 InstallationDate: Installed on 2021-09-23 (793 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: zfs-linux UpgradeStatus: Upgraded to jammy on 2022-08-17 (466 days ago) To recreate: - Install Ubuntu 22.04.3. - Update to current. - Install package 'zfs-dkms' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044630/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Indeed, it boots after following your instructions.
ubi@vm1fmdye:~$ uname -a
Linux vm1fmdye 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1 d8 84 c0 75 11 eb 56 48 8b 7b 08 e8 6b 5e c1 d8 84 c0 75 17 f3
90 <48> 8b 7b 08 48 8d b5 6c ff ff ff e8 f5 71 c1 d8 48 85 c0 74 dc 48
[ 28.134326] RSP: 0018:9b0c4064f9b8 EFLAGS: 0246
[ 28.134720] RAX: RBX: 89dfc0d13980 RCX:
0a20
[ 28.135252] RDX: RSI: 9b0c4064f9bc RDI:
89dfc7cc00c0
[ 28.135787] RBP: 9b0c4064fa50 R08: 0001 R09:
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
We can check it out, I have a question though, is there a way to get a
pre-captured image with -proposed in it? We could integrate this into a
CI system to do more monitoring.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1 d8 84 c0 75 11 eb 56 48 8b 7b 08 e8 6b 5e c1 d8 84 c0 75 17 f3
90 <48> 8b 7b 08 48 8d b5 6c ff ff ff e8 f5 71 c1 d8 48 85 c0 74 dc 48
[ 28.134326] RSP: 0018:9b0c4064f9b8 EFLAGS: 0246
[ 28.134720] RAX: RBX: 89dfc0d13980 RCX:
0a20
[ 28.135252] RDX: RSI: 9b0c4064f9bc RDI:
89dfc7cc00c0
[ 28.135787] RBP: 9b0c4064fa50 R08: 0001 R09:
0003
[
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Hi Daniel,
Thanks for reporting. I had a look into the followup commit you
mentioned:
~/Work/kernel/ubuntu-jammy$ git log --grep "virtio-net: set queues after
driver_ok" origin/master-next
commit c6c83b9055f44bcb2bc2fae32323c0a1510c7656
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
BugLink: https://bugs.launchpad.net/bugs/2038486
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
So, "virtio-net: set queues after driver_ok" is applied, and is tagged for:
~/Work/kernel/ubuntu-jammy$ git describe --contains
c6c83b9055f44bcb2bc2fae32323c0a1510c7656
Ubuntu-5.15.0-90.100~161
Looking at 5.15.0-91-generic, it seems to include all patches in
5.15.0-90-generic, with a single revert to fix a USB regression.
5.15.0-91-generic is currently in jammy -proposed, and I believe we are looking
at a release this coming week, as per https://kernel.ubuntu.com/.
If you would like to try it now and verify that it does fix the issue, start an
older cloud image that has an older kernel so it boots correctly, then enable
-proposed and install the 5.15.0-91-generic kernel:
Instructions to install (On a Jammy system):
1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release
-cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe
EOF
2) sudo apt update
3) sudo apt install linux-image-5.15.0-91-generic
linux-modules-5.15.0-91-generic linux-modules-extra-5.15.0-91-generic
linux-headers-5.15.0-91-generic
4) sudo reboot
5) uname -rv
5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023
The instance should reboot properly and be available to ssh into.
This should be fixed in a couple of days once 5.15.0-91-generic is released and
built into new cloud-images.
Thanks,
Matthew
** Tags added: seg
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** Changed in: linux (Ubuntu Jammy)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel crypto_simd cryptd virtio_net(+)
net_failover virtio_rng failover virtio_blk
[ 28.131396] CPU: 1 PID: 165 Comm: systemd-udevd Not tainted
5.15.0-89-generic https://github.com/ubicloud/ubicloud/pull/99-Ubuntu
[ 28.131997] Hardware name: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 28.132479] RIP: 0010:virtnet_send_command+0x10b/0x170 [virtio_net]
[ 28.132951] Code: 0b 83 c1 d8 85 c0 0f 88 d2 6e 00 00 48 8b 7b 08 e8
6a 72 c1 d8 84 c0 75 11 eb 56 48 8b 7b 08 e8 6b 5e c1 d8 84 c0 75 17 f3
90 <48> 8b 7b 08 48 8d b5 6c ff ff ff e8 f5 71 c1 d8 48 85 c0 74 dc 48
[ 28.134326] RSP: 0018:9b0c4064f9b8 EFLAGS: 0246
[ 28.134720] RAX: RBX: 89dfc0d13980 RCX:
0a20
[ 28.135252] RDX: RSI: 9b0c4064f9bc RDI:
89dfc7cc00c0
[ 28.135787] RBP: 9b0c4064fa50 R08:
[Kernel-packages] [Bug 2045512] [NEW] UBSAN: array-index-out-of-bounds in /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.c:4062:31
Public bug reported: [ 143.525500] [ 143.525913] UBSAN: array-index-out-of-bounds in /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.c:4062:31 [ 143.526327] index 1 is out of range for type 'SUPGIPCPU [1]' [ 143.526760] CPU: 0 PID: 1583 Comm: iprt-VBoxTscThr Tainted: G OE 6.5.0-13-generic #13-Ubuntu [ 143.526760] Hardware name: HP Victus by HP Laptop 16-e0xxx/88EB, BIOS F.15 08/10/2022 [ 143.526760] Call Trace: [ 143.526760] [ 143.526760] dump_stack_lvl+0x48/0x70 [ 143.526760] dump_stack+0x10/0x20 [ 143.526760] __ubsan_handle_out_of_bounds+0xc6/0x110 [ 143.526764] supdrvTscMeasureDeltaOne+0x66f/0x7e0 [vboxdrv] [ 143.526797] supdrvTscDeltaThread+0x4c1/0x7c0 [vboxdrv] [ 143.526828] ? srso_alias_return_thunk+0x5/0x7f [ 143.526832] ? __pfx_rtThreadNativeMain+0x10/0x10 [vboxdrv] [ 143.526863] rtThreadMain+0x37/0x80 [vboxdrv] [ 143.526895] rtThreadNativeMain+0x1b/0x30 [vboxdrv] [ 143.526926] kthread+0xf2/0x120 [ 143.526929] ? __pfx_kthread+0x10/0x10 [ 143.526933] ret_from_fork+0x47/0x70 [ 143.526936] ? __pfx_kthread+0x10/0x10 [ 143.526939] ret_from_fork_asm+0x1b/0x30 [ 143.526943] [ 143.526945] ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2045512 Title: UBSAN: array-index-out-of-bounds in /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.c:4062:31 Status in linux package in Ubuntu: New Bug description: [ 143.525500] [ 143.525913] UBSAN: array-index-out-of-bounds in /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.c:4062:31 [ 143.526327] index 1 is out of range for type 'SUPGIPCPU [1]' [ 143.526760] CPU: 0 PID: 1583 Comm: iprt-VBoxTscThr Tainted: G OE 6.5.0-13-generic #13-Ubuntu [ 143.526760] Hardware name: HP Victus by HP Laptop 16-e0xxx/88EB, BIOS F.15 08/10/2022 [ 143.526760] Call Trace: [ 143.526760] [ 143.526760] dump_stack_lvl+0x48/0x70 [ 143.526760] dump_stack+0x10/0x20 [ 143.526760] __ubsan_handle_out_of_bounds+0xc6/0x110 [ 143.526764] supdrvTscMeasureDeltaOne+0x66f/0x7e0 [vboxdrv] [ 143.526797] supdrvTscDeltaThread+0x4c1/0x7c0 [vboxdrv] [ 143.526828] ? srso_alias_return_thunk+0x5/0x7f [ 143.526832] ? __pfx_rtThreadNativeMain+0x10/0x10 [vboxdrv] [ 143.526863] rtThreadMain+0x37/0x80 [vboxdrv] [ 143.526895] rtThreadNativeMain+0x1b/0x30 [vboxdrv] [ 143.526926] kthread+0xf2/0x120 [ 143.526929] ? __pfx_kthread+0x10/0x10 [ 143.526933] ret_from_fork+0x47/0x70 [ 143.526936] ? __pfx_kthread+0x10/0x10 [ 143.526939] ret_from_fork_asm+0x1b/0x30 [ 143.526943] [ 143.526945] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045512/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044630] Re: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build
** Description changed: On todays updates, zfs-dkms 2.1.5-1ubuntu6~22.04.2 failed to build kernel module. Genrated Crash report, but couldn't send it on it's own. Error it kept throwing was: >>> Setting up zfs-dkms (2.1.5-1ubuntu6~22.04.2) ... Loading new zfs-2.1.5 DKMS files... Building for 6.2.0-36-generic 6.2.0-37-generic Building initial module for 6.2.0-36-generic - configure: error: - *** None of the expected "iops->get_acl()" interfaces were detected. - *** This may be because your kernel version is newer than what is - *** supported, or you are using a patched custom kernel with - *** incompatible modifications. - *** - *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 - *** Compatible Kernels: 3.10 - 5.19 - + configure: error: + *** None of the expected "iops->get_acl()" interfaces were detected. + *** This may be because your kernel version is newer than what is + *** supported, or you are using a patched custom kernel with + *** incompatible modifications. + *** + *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 + *** Compatible Kernels: 3.10 - 5.19 + ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/zfs-dkms.0.crash' Error! Bad return status for module build on kernel: 6.2.0-36-generic (x86_64) Consult /var/lib/dkms/zfs/2.1.5/build/make.log for more information. dpkg: error processing package zfs-dkms (--configure): - installed zfs-dkms package post-installation script subprocess returned error exit status 10 + installed zfs-dkms package post-installation script subprocess returned error exit status 10 >>> ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: zfs-dkms 2.1.5-1ubuntu6~22.04.2 ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-36-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sat Nov 25 21:00:27 2023 InstallationDate: Installed on 2021-09-23 (793 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: zfs-linux UpgradeStatus: Upgraded to jammy on 2022-08-17 (466 days ago) + + To recreate: + - Install Ubuntu 22.04.3. + - Update to current. + - Install package 'zfs-dkms' -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2044630 Title: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build Status in zfs-linux package in Ubuntu: Confirmed Bug description: On todays updates, zfs-dkms 2.1.5-1ubuntu6~22.04.2 failed to build kernel module. Genrated Crash report, but couldn't send it on it's own. Error it kept throwing was: >>> Setting up zfs-dkms (2.1.5-1ubuntu6~22.04.2) ... Loading new zfs-2.1.5 DKMS files... Building for 6.2.0-36-generic 6.2.0-37-generic Building initial module for 6.2.0-36-generic configure: error: *** None of the expected "iops->get_acl()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 *** Compatible Kernels: 3.10 - 5.19 ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/zfs-dkms.0.crash' Error! Bad return status for module build on kernel: 6.2.0-36-generic (x86_64) Consult /var/lib/dkms/zfs/2.1.5/build/make.log for more information. dpkg: error processing package zfs-dkms (--configure): installed zfs-dkms package post-installation script subprocess returned error exit status 10 >>> ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: zfs-dkms 2.1.5-1ubuntu6~22.04.2 ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-36-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sat Nov 25 21:00:27 2023 InstallationDate: Installed on 2021-09-23 (793 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: zfs-linux UpgradeStatus: Upgraded to jammy on 2022-08-17 (466 days ago) To recreate: - Install Ubuntu 22.04.3. - Update to current. - Install package 'zfs-dkms' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044630/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044630] Re: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build
<> Rick S and I have talked a lot today... trying to remember: I added a repo on my GitHub on: Open-ZFS-Admin > "How To Uninstall package 'zfs-dkms' And Survive" We had to remember: - Why we actually started using it. Ubuntu, in the past, did not rebuild the zfs module, so we needed zfs- dkms so that when kernels were updated, that the 'zfs' modules were built for the new kernel... - If it is actually needed anymore Not for normal users... I will explain that. I think sometime around 22.04.x, canonical started adding the zfs-modules in-kernel. Confirmed that, if you install Ubuntu 22.04.3 as ZFS-On_Root, and do updates, zfs- dkms is not an installed package, and the 'zfs' modules are built during a kernel update. So it is not actually needed any longer by normal users. - Why Rick S (1fallen) and I still need to use package 'zfs-dkms', if it is not required as a default package anymore... We do DEV testing and ZFS version (zfs-linux) testng/validations... We need it becaseu we often install and use kernels from the Ubuntu mainline repo. Which does not have the added Ubuntu mod's and additions. That, and (I hate to say this) sometimes Canonical forgets to add things, and has regression issues. This package has save our behinds sometimes. I am embarrassed at Launchpad's participation with this. i will take the baton and help them with that. When I get that done, and Rick and i get that tested, i will publish the link to that here. When I get those instructions -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2044630 Title: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build Status in zfs-linux package in Ubuntu: Confirmed Bug description: On todays updates, zfs-dkms 2.1.5-1ubuntu6~22.04.2 failed to build kernel module. Genrated Crash report, but couldn't send it on it's own. Error it kept throwing was: >>> Setting up zfs-dkms (2.1.5-1ubuntu6~22.04.2) ... Loading new zfs-2.1.5 DKMS files... Building for 6.2.0-36-generic 6.2.0-37-generic Building initial module for 6.2.0-36-generic configure: error: *** None of the expected "iops->get_acl()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 *** Compatible Kernels: 3.10 - 5.19 ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/zfs-dkms.0.crash' Error! Bad return status for module build on kernel: 6.2.0-36-generic (x86_64) Consult /var/lib/dkms/zfs/2.1.5/build/make.log for more information. dpkg: error processing package zfs-dkms (--configure): installed zfs-dkms package post-installation script subprocess returned error exit status 10 >>> ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: zfs-dkms 2.1.5-1ubuntu6~22.04.2 ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-36-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sat Nov 25 21:00:27 2023 InstallationDate: Installed on 2021-09-23 (793 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: zfs-linux UpgradeStatus: Upgraded to jammy on 2022-08-17 (466 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044630/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045443] Re: Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
It looks like the -proposed kernel has picked up that missing patch:
~/c/linux ((Ubuntu-5.15.0-91.101))> git log --grep='virtio-net: set queues
after driver_ok'
commit c6c83b9055f44bcb2bc2fae32323c0a1510c7656
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
BugLink: https://bugs.launchpad.net/bugs/2038486
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045443
Title:
Ubuntu-5.15.0-89.99 breaks virtio-net spec and doesn't boot
Status in linux package in Ubuntu:
New
Bug description:
I use a non-qemu VMM, cloud-hypervisor. It looks like a patch was
applied, that introduced a bug, a week later another patch got written
to fix that bug, and that second patch was not applied in Ubuntu's
release, but is seen in Greg KH's 5.15 branch.
The result of the bug is the kernel will not boot.
Cumulative diff:
```
> git diff Ubuntu-5.15.0-86.96 Ubuntu-5.15.0-89.99 drivers/net/virtio_net.c
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0351f86494f1..af335f8266c2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3319,6 +3319,8 @@ static int virtnet_probe(struct virtio_device *vdev)
}
}
+ _virtnet_set_queues(vi, vi->curr_queue_pairs);
+
/* serialize netdev register + virtio_device_ready() with ndo_open()
*/
rtnl_lock();
@@ -3339,8 +3341,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- virtnet_set_queues(vi, vi->curr_queue_pairs);
-
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
```
Blamed Commit:
```
commit 5e0545ef5682562ffef072138d9340ea36a2ebc9
Author: Jason Wang
Date: Tue Jul 25 03:20:49 2023 -0400
virtio-net: fix race between set queues and probe
BugLink: https://bugs.launchpad.net/bugs/2035400
commit 25266128fe16d5632d43ada34c847d7b8daba539 upstream.
A race were found where set_channels could be called after registering
but before virtnet_set_queues() in virtnet_probe(). Fixing this by
moving the virtnet_set_queues() before netdevice registering. While at
it, use _virtnet_set_queues() to avoid holding rtnl as the device is
not even registered at that time.
Cc: sta...@vger.kernel.org
Fixes: a220871be66f ("virtio-net: correctly enable multiqueue")
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Reviewed-by: Xuan Zhuo
Link:
https://lore.kernel.org/r/20230725072049.617289-1-jasow...@redhat.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
Signed-off-by: Stefan Bader
```
Investigation into Greg KH's 5.15 branch shows the (unapplied?)
followup as:
```
commit 431db3f48c286462ad7453ccdf284f590aafa949
Author: Jason Wang
Date: Wed Aug 9 23:12:56 2023 -0400
virtio-net: set queues after driver_ok
commit 51b813176f098ff61bd2833f627f5319ead098a5 upstream.
Commit 25266128fe16 ("virtio-net: fix race between set queues and
probe") tries to fix the race between set queues and probe by calling
_virtnet_set_queues() before DRIVER_OK is set. This violates virtio
spec. Fixing this by setting queues after virtio_device_ready().
Note that rtnl needs to be held for userspace requests to change the
number of queues. So we are serialized in this way.
Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe")
Reported-by: Dragos Tatulea
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
```
Boot stack trace:
```
[ 28.129660] watchdog: BUG: soft lockup - CPU#1 stuck for 26s!
[systemd-udevd:165]
[ 28.130265] Modules linked in: crct10dif_pclmul
[Kernel-packages] [Bug 2043203] Re: Kernel 5.15.0-86 causes LightDM to disappear after 1s
Can you boot completely with 'nomodeset'? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2043203 Title: Kernel 5.15.0-86 causes LightDM to disappear after 1s Status in linux package in Ubuntu: New Bug description: This is to report a critical bug introduced with Linux kernel 5.15.0-86-generic and newer. It does not occur with 5.15.0-84-generic and previous kernels. I am running Xubuntu LTS 22.04.03 on several desktops, but this bug only manifests on this specific system, which is a fairly popular HP t630 Thin Client featuring an AMD Embedded G-Series GX-420GI system on chip with Radeon R7E integrated graphics. Here is the neofetch output: :ydddy: OS: Xubuntu 22.04.3 LTS x86_64 -yhdddy- Host: HP t630 Thin Client odddyshdddh`+ydddo Kernel: 5.15.0-84-generic `yddhshdd- ydd+`ddh.:dy`Uptime: 1 day, 1 hour, 16 mins sddy /d. :dd-:dy`-dddsPackages: 3354 (dpkg), 22 (flatpak) :ddds/+ .dd`yy`:d: Shell: bash 5.1.16 s`..-:/+ssdyodds Resolution: 1600x900 y `:ohd DE: Xfce . + WM: Xfwm4 sddyydds WM Theme: Numix :dd+ .oddd: Theme: Greybird [GTK2/3] sdo ./ysIcons: Faenza-Darker [GTK2], elementary-xfce-darker [GTK3] `yd. `:ohddy`Terminal: xfce4-terminal oh/` `.:+shdo Terminal Font: DejaVu Sans Mono 12 -ydhyssyhdy- CPU: AMD Embedded G-Series GX-420GI Radeon R7E (4) @ 2.000GHz :yy: GPU: AMD ATI Radeon R5/R6/R7 Graphics .+yddy+. Memory: 2786MiB / 31044MiB Symptoms: The systems boots as usual, XFCE's LightDM Greeter appears for about one second, then the screen turns completely black and the keyboard becomes unresponsive. This implies that one cannot switch to a console screen using Ctrl+Alt+F1 etc. to resolve any problems. I was lucky to have SSH access from another system, to change GRUB settings and reboot with the older 5.15.0-84 kernel, otherwise this system could have been a loss. More importantly, this proofs the system did not crash. dmesg logs were compared between kernels using meld, but no noticeable differences were detected. However, both working (84) and non-working (86,88) kernel dmesg logs show similar ACPI errors; here for the 84 kernel, the 88 kernel dmesg log is attached to this bug report: [3.584496] acpi PNP0C14:01: duplicate WMI GUID 5FB7F034-2C63-45E9-BE91-3D44E2C707E4 (first instance was on PNP0C14:00) [3.584510] acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) ... [6.920766] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20210730/dsopcode-133) [6.921268] Initialized Local Variables for Method [HWMC]: [6.921272] Local0: 6835d165Integer 0004 [6.921293] Local1: 0d18c184Buffer(12) 00 00 00 00 00 00 00 00 [6.921317] Local5: a100fffdInteger [6.921332] Initialized Arguments for Method [HWMC]: (2 arguments defined for method invocation) [6.921335] Arg0: ca1a283dInteger 0002 [6.921346] Arg1: 7cb48472Buffer(144) 53 45 43 55 01 00 00 00 [6.921379] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20210730/psparse-529) [6.921491] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20210730/psparse-529) [6.992738] input: HP WMI hotkeys as /devices/virtual/input/input13 [7.012049] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20210730/dsopcode-133) [7.012149] Initialized Local Variables for Method [HWMC]: [7.012152] Local0: a6c78dffInteger 0004 [7.012167] Local1: 4991298cBuffer(12) 00 00 00 00 00 00 00 00 [7.012189] Local5: c8c4ed33Integer [7.012202] Initialized Arguments for Method [HWMC]: (2 arguments defined for method invocation) [7.012205] Arg0: ca1a283dInteger 0002 [7.012215] Arg1: be9a5486Buffer(144) 53 45 43 55 01 00 00 00 [7.012239] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20210730/psparse-529)
[Kernel-packages] [Bug 2041495] Re: Could not probe Samsung P44 30S3 PM9C1a SSD correctly: nvme nvme0: Device not ready: aborting installation, CSTS=0x0
The same with an Acer Predator SSD GM7 M.2 4TB I think the error is in the MaxIO MAP1602A controller and not in the brand. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2041495 Title: Could not probe Samsung P44 30S3 PM9C1a SSD correctly: nvme nvme0: Device not ready: aborting installation, CSTS=0x0 Status in HWE Next: New Status in linux package in Ubuntu: Fix Released Status in linux-oem-6.1 package in Ubuntu: Invalid Status in linux-oem-6.5 package in Ubuntu: Invalid Status in linux source package in Jammy: Invalid Status in linux-oem-6.1 source package in Jammy: Fix Released Status in linux-oem-6.5 source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux-oem-6.1 source package in Lunar: Invalid Status in linux-oem-6.5 source package in Lunar: Invalid Status in linux source package in Mantic: Fix Committed Status in linux-oem-6.1 source package in Mantic: Invalid Status in linux-oem-6.5 source package in Mantic: Invalid Bug description: [SRU Justification] BugLink: https://bugs.launchpad.net/bugs/2041495 [Impact] NVME module left unready, therefore not recognized by the installation process, and/or after installation with following error messages: ``` kernel: [ 1.754585] nvme nvme0: pci function 1:e1:00.0 kernel: [ 1.754595] pcieport 1:e0:06.0: can't derive routing for PCI INT A kernel: [ 1.754599] nvme 1:e1:00.0: PCI INT A: no GSI kernel: [ 1.756743] nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0 ``` [Fix] Proposed fix in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/nvme/host/core.c?h=v6.5=6cc834ba62998c65c42d0c63499bdd35067151ec "nvme: avoid bogus CRTO values", in Linus' tree v6.6 already, as well as stable kernels v6.1.55 and v6.5.5. [Test Case] Apply to kernel and boot with the nvme module installed. Now the device should be probed with success. ``` kernel: [1.731760] nvme nvme0: pci function 1:e1:00.0 kernel: [1.731778] pcieport 1:e0:06.0: can't derive routing for PCI INT A kernel: [1.731780] nvme 1:e1:00.0: PCI INT A: no GSI kernel: [1.731919] nvme nvme0: bad crto:0 cap:800203028033fff kernel: [1.735550] nvme nvme0: Shutdown timeout set to 10 seconds kernel: [1.753865] nvme nvme0: allocated 64 MiB host memory buffer. kernel: [1.794966] nvme nvme0: 16/0/0 default/read/poll queues kernel: [2.136735] nvme0n1: p1 p2 p3 ``` [Where problems could occur] This patch tries to set an appropriate CRTO (Controller Ready Timeouts) that may be reported incorrectly by some devices. There should be little (a bit longer CRTO) to no effect on devices performing normally before hands. [Other Info] While this has been in Linus' tree, Mantic/Lunar/oem-6.5 and oem-6.1 will be nominated. == original bug report == NVME module left unready, therefore not recognized by the installation process, and/or after installation with following error messages: kernel: [ 1.754585] nvme nvme0: pci function 1:e1:00.0 kernel: [ 1.754595] pcieport 1:e0:06.0: can't derive routing for PCI INT A kernel: [ 1.754599] nvme 1:e1:00.0: PCI INT A: no GSI kernel: [ 1.756743] nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0 To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2041495/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044630] Re: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build
A bit surprised that this isn't treated with more urgency. We're on an LTS ubuntu and we get broken updates, basically. Though so far I can't see it having a major impact in my case (can still use zfs and updating other packages seems to work) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2044630 Title: zfs-dkms 2.1.5-1ubuntu6~22.04.2- Kernel module failed to build Status in zfs-linux package in Ubuntu: Confirmed Bug description: On todays updates, zfs-dkms 2.1.5-1ubuntu6~22.04.2 failed to build kernel module. Genrated Crash report, but couldn't send it on it's own. Error it kept throwing was: >>> Setting up zfs-dkms (2.1.5-1ubuntu6~22.04.2) ... Loading new zfs-2.1.5 DKMS files... Building for 6.2.0-36-generic 6.2.0-37-generic Building initial module for 6.2.0-36-generic configure: error: *** None of the expected "iops->get_acl()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.1.5-1ubuntu6~22.04.2 *** Compatible Kernels: 3.10 - 5.19 ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/zfs-dkms.0.crash' Error! Bad return status for module build on kernel: 6.2.0-36-generic (x86_64) Consult /var/lib/dkms/zfs/2.1.5/build/make.log for more information. dpkg: error processing package zfs-dkms (--configure): installed zfs-dkms package post-installation script subprocess returned error exit status 10 >>> ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: zfs-dkms 2.1.5-1ubuntu6~22.04.2 ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-36-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sat Nov 25 21:00:27 2023 InstallationDate: Installed on 2021-09-23 (793 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: zfs-linux UpgradeStatus: Upgraded to jammy on 2022-08-17 (466 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044630/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045505] [NEW] Kernel cannot detect HDMI connection
Public bug reported: Hie, I have the same problem than https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144 with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04 and 23.10, xorg and wayland, same problem. I also tested openSuse 15.5 and there was the same issue. Screen and HDMI cable worked with the previous computer HP 17-p128nf, and work actually on Windows 11 (dualboot). Seems to be a Linux problem. Thank you for your help ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.2.0-37-generic 6.2.0-37.38~22.04.1 ProcVersionSignature: Ubuntu 6.2.0-37.38~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-37-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Dec 3 15:09:53 2023 InstallationDate: Installed on 2023-12-03 (0 days ago) InstallationMedia: Kubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.1) SourcePackage: linux-signed-hwe-6.2 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-signed-hwe-6.2 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ** Description changed: Hie, I have the same problem than https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144 with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04 and 23.10, xorg and wayland, same problem. I also tested openSuse 15.5 and there was the same issue. - Screen and HDMI cable worked with the previous computer, and work actually on Windows 11 (dualboot). + Screen and HDMI cable worked with the previous computer HP 17-p128nf, and work actually on Windows 11 (dualboot). Seems to be a Linux problem. Thank you for your help ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.2.0-37-generic 6.2.0-37.38~22.04.1 ProcVersionSignature: Ubuntu 6.2.0-37.38~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-37-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Dec 3 15:09:53 2023 InstallationDate: Installed on 2023-12-03 (0 days ago) InstallationMedia: Kubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.1) SourcePackage: linux-signed-hwe-6.2 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-6.2 in Ubuntu. https://bugs.launchpad.net/bugs/2045505 Title: Kernel cannot detect HDMI connection Status in linux-signed-hwe-6.2 package in Ubuntu: New Bug description: Hie, I have the same problem than https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144 with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04 and 23.10, xorg and wayland, same problem. I also tested openSuse 15.5 and there was the same issue. Screen and HDMI cable worked with the previous computer HP 17-p128nf, and work actually on Windows 11 (dualboot). Seems to be a Linux problem. Thank you for your help ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.2.0-37-generic 6.2.0-37.38~22.04.1 ProcVersionSignature: Ubuntu 6.2.0-37.38~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-37-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Dec 3 15:09:53 2023 InstallationDate: Installed on 2023-12-03 (0 days ago) InstallationMedia: Kubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.1) SourcePackage: linux-signed-hwe-6.2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.2/+bug/2045505/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1994144] Re: [i915] Kernel cannot detect HDMI connection
Hie, I have the same problem with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04 and 23.10, same problem. I also tested openSuse 15.5 ans there was the same issue. Screen and HDMI cable worked with the previous computer, and work actually on Windows 11 (dualboot). Seems to be a Linux problem. Tank you for your help -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1994144 Title: [i915] Kernel cannot detect HDMI connection Status in linux package in Ubuntu: Confirmed Bug description: xrandr lists four disconnected DPs (though my laptop has zero Display Ports) but does not list an HDMI, which is what I use to connect external monitor. Cable is sound b/c I have a dual boot setup and Windows recognizes the display without issue. Using Ubuntu 22.04.1 LTS I expected OS to recognize that I have a an HDMI port or alternatively that something is plugged into it OS does not seem to acknowledge same ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-52.58-generic 5.15.60 Uname: Linux 5.15.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Oct 25 08:45:56 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu DkmsStatus: rtl8821ce/5.5.2.1, 5.15.0-52-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] [8086:46a8] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:899b] InstallationDate: Installed on 2022-10-24 (0 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 004: ID 0bda:b00e Realtek Semiconductor Corp. Bluetooth Radio Bus 001 Device 002: ID 30c9:0064 Luxvisions Innotech Limited HP TrueVision HD Camera Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Laptop 17-cn2xxx ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-52-generic root=UUID=ec82dd33-2985-40cd-a295-49463eb8e698 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/02/2022 dmi.bios.release: 15.2 dmi.bios.vendor: AMI dmi.bios.version: F.02 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 899B dmi.board.vendor: HP dmi.board.version: 06.26 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 6.26 dmi.modalias: dmi:bvnAMI:bvrF.02:bd08/02/2022:br15.2:efr6.26:svnHP:pnHPLaptop17-cn2xxx:pvr:rvnHP:rn899B:rvr06.26:cvnHP:ct10:cvrChassisVersion:sku641G6UA#ABA: dmi.product.family: 103C_5335KV HP Notebook dmi.product.name: HP Laptop 17-cn2xxx dmi.product.sku: 641G6UA#ABA dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.5-0ubuntu0.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045503] [NEW] apply sched-ext patch set to linux-unstable
Public bug reported: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests are available in tools/sched_ext. [Fix] Apply this patch set as SAUCE: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ Soon there'll be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux- unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Summary changed: - apply sched-ext patch set to inux-unstable + apply sched-ext patch set to linux-unstable -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2045503 Title: apply sched-ext patch set to linux-unstable Status in linux package in Ubuntu: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests are available in tools/sched_ext. [Fix] Apply this patch set as SAUCE:
[Kernel-packages] [Bug 2045467] Re: qprint emits dos-style \r \n
The documentation on the source code (https://www.fourmilab.ch/webtools/qprint/#Download) says (p.4, #8) "Procedure output line break outputs the standard RFC 822 line break sequence of carriage-return, line-feed and resets the current output line length to zero." That's good for multi-line output, but not good for translating a single non-ascii email address. Perhaps an option might be provided for single-line output on *nix systems, to suppress the CR character. The man page says nothing about RFC 822 or about the CR inclusion ... And, just to be clear, my 'qprint' is downloaded from the Ubuntu repository. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2045467 Title: qprint emits dos-style \r \n Status in linux package in Ubuntu: New Bug description: $ echo r.fässlin...@somewhere.com | qprint -e | od -c 000 r . f = C 3 = A 4 s s l i n g e 020 r @ s o m e w h e r e . c o m \r 040 \n 041 The "\r" confuses any addition of prefix "<=?UTF-8?Q?" and suffix "=>" when creating a quoted-printable email encoding, so that the suffix appears at the start of the string. Piping to "tr -d '\r'" resolves the issue, but shouldn't be necessary. $ lsb_release -rd Description: Ubuntu 22.04.3 LTS Release: 22.04 $ qprint --version qprint 1.1 Last revised: 16th December 2014 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045467/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045492] [NEW] make lazy RCU a boot time option
Public bug reported: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't want to risk performance regressions. [Test case] In this context providing a single test case is not relevant. After applying the fix any performance benchmark can be used to evaluate if lazy RCU feature should be enabled at boot time or not (according to the specific context where the lowlatency kernel is going to be used/deployed). [Fix] Apply this patch to the *generic* kernel: https://lore.kernel.org/lkml/20231203011252.233748-1-qyou...@layalina.io/T/#u We want to apply this to the generic kernel, not just lowlatency, because in this way *all* derivatives will have the possibility to get this feature, in case some of them want to enable lazy RCUs (even generic itself). Then make sure that lowlatency (or any other kernel with CONFIG_RCU_LAZY=y) also has CONFIG_RCU_LAZY_DEFAULT_OFF not set (so that the previous behavior is not changed). [Regression potential] We may receive reports of small performance regressions vs power consumption regressions, depending on the rcutree.enable_rcu_lazy command line option that is used. In such case we should suggest the user to test both with lazy RCU disabled or enabled. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-lowlatency (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Affects: linux-lowlatency (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-lowlatency (Ubuntu Noble) Importance: Undecided Status: New ** Description changed: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't want to risk performance regressions. [Test case] In this context providing a single test case is not relevant. After applying the fix any performance benchmark can be used to evaluate if lazy RCU feature should be enabled at boot time or not (according to the specific context where the lowlatency kernel is going to be used/deployed). [Fix] Apply this patch to the *generic* kernel: https://lore.kernel.org/lkml/20231203011252.233748-1-qyou...@layalina.io/T/#u We want to apply this to the generic kernel, not just lowlatency, because in this way *all* derivatives will have the possibility to get this feature, in case some of them want to enable lazy RCUs (even generic itself). + Then make sure that lowlatency (or any other kernel with + CONFIG_RCU_LAZY=y) also has CONFIG_RCU_LAZY_DEFAULT_OFF not set (so that + the previous behavior is not changed). + [Regression potential] We may receive reports of small performance regressions vs power consumption regressions, depending on the rcutree.enable_rcu_lazy command line option that is used. In such case we should suggest the user to test both with lazy RCU disabled or enabled. ** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-lowlatency in Ubuntu. https://bugs.launchpad.net/bugs/2045492 Title: make lazy RCU a boot time option Status in linux package in Ubuntu: New Status in linux-lowlatency package in Ubuntu: New Status in linux source package in Noble: New Status in linux-lowlatency source package in Noble: New Bug description: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't
