Hello bugproxy, or anyone else affected, Accepted s390-tools-signed into plucky-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/s390-tools- signed/2.37.0-0ubuntu2.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- plucky to verification-done-plucky. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-plucky. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: s390-tools-signed (Ubuntu Noble) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Debcrafters packages, which is subscribed to s390-tools in Ubuntu. https://bugs.launchpad.net/bugs/2078347 Title: [UBUNTU 24.04] Udev/rules: Missing rules causes newly added CPUs to stay offline Status in Ubuntu on IBM z Systems: In Progress Status in s390-tools package in Ubuntu: Fix Released Status in s390-tools-signed package in Ubuntu: Fix Released Status in s390-tools source package in Noble: Fix Committed Status in s390-tools-signed source package in Noble: Fix Committed Status in s390-tools source package in Plucky: Fix Committed Status in s390-tools-signed source package in Plucky: Fix Committed Status in s390-tools source package in Questing: Fix Released Status in s390-tools-signed source package in Questing: Fix Released Bug description: SRU Justification: [ Impact ] * Newly (online) CPUs that are hotpluggable and that are added to a live system, are not immediately used and stay offline. * They only become online after a reboot. But the reason to add CPUs is usually an immediate need for more capacity, so that a reboot with downtime is not wanted. * This can be addressed by a udev rule in /etc/udev/rules.d/ like: SUBSYSTEM=="cpu", ACTION=="add", CONST{arch}=="s390*", \ ATTR{configure}=="1", TEST=="online", ATTR{online}!="1", ATTR{online}="1" that automatically hotplugs any (new) CPUs added to the system to configured state. [ Fix ] * 8dc06d14d769 ("udev: Introduce a rule to set newly hotplugged CPUs online") https://github.com/ibm-s390-linux/s390-tools/commit/\ 8dc06d14d76940b3059cd6063fc7d8e7f0150271 [ Test Plan ] * Adding CPU to a system in online and configured state is possible in LPARs, z/VM guests or KVM virtual machines. It's easiest to test this with the help of KVM. * Setup an Ubuntu Server 24.04 LPAR with KVM vrt-stack. * Define a KVM guest with hotpluggable and non-hotpluggable CPUs whereas the amount of used (current) CPUs is lower than the overall amount (let's say 6 out of 8): virsh dumpxml vm <domain type='kvm' id='106'> ... <vcpu placement='static' current='6'>8</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> <vcpu id='6' enabled='no' hotpluggable='yes'/> <vcpu id='7' enabled='no' hotpluggable='yes'/> </vcpus> * Now attempt to add CPUs to the guest in a live "running" state. $ virsh setvcpus vm 8 --live * The KVM guest XML is updated : ... <vcpu placement='static'>8</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/> <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/> </vcpus> * But the CPUs inside of the guest still stay offline: $ lscpu -e CPU NODE DRAWER BOOK SOCKET CORE L1d:L1i:L2 ONLINE CONFIGURED POLARIZATION ADDRESS 0 0 0 0 0 0 0:0:0 yes yes horizontal 0 1 0 0 0 1 1 1:1:1 yes yes horizontal 1 2 0 0 0 2 2 2:2:2 yes yes horizontal 2 3 0 0 0 3 3 3:3:3 yes yes horizontal 3 4 0 0 0 4 4 4:4:4 yes yes horizontal 4 5 0 0 0 5 5 5:5:5 yes yes horizontal 5 6 - - - - - - no yes horizontal 6 7 - - - - - - no yes horizontal 7 * The desired result, achieved with the help of the new udev rule is like this: $ lscpu -e CPU NODE DRAWER BOOK SOCKET CORE L1d:L1i:L2 ONLINE CONFIGURED POLARIZATION ADDRESS 0 0 0 0 0 0 0:0:0 yes yes horizontal 0 1 0 0 0 1 1 1:1:1 yes yes horizontal 1 2 0 0 0 2 2 2:2:2 yes yes horizontal 2 3 0 0 0 3 3 3:3:3 yes yes horizontal 3 4 0 0 0 4 4 4:4:4 yes yes horizontal 4 5 0 0 0 5 5 5:5:5 yes yes horizontal 5 6 0 0 0 6 6 6:6:6 yes yes horizontal 6 7 0 0 0 7 7 7:7:7 yes yes horizontal 7 * Without the udev rule, this can only be achieved with a reboot. But it's not desired, since in cases where immediately new CPU capacity is needed, a downtime (caused by a reboot) is counterproductive. [ Where problems could occur ] * This is only a configuration change and not a code change. However, things could still go wrong: - No or not desired functionality in case the udev rules is installed in a wrong folder. - The udev rule itself could be wrong. - wrong subsystem would lead to listen to a wrong event - wrong action would lead to wrong behavior - wrong architecture would run the rule not on s390x (as architecture constant "s390*" is used here, which covers s390x and s390, but Ubuntu supports s390x (64-bit) only, but since it's upstream like this it should be kept) - wrong attribute would lead to wrong behavior, action or status. * Since the architecture constant is s390(x), this affects IBM Z and LinuxONE only, and has no impact on other architectures. [ Other Info ] * Since this is the same for all Linux distros, this udev rule was added to the s390-tools in general. (The s390-tools package already ships udev rules for other purposes.) * It's already included in questing, with the updated s390-tools version 2.38.0 (as part of LP: #2115416). __________ ---Problem Description---------------------------------------------------------------------------------- Adding a configured CPU to a system (LPAR, ZVM or KVM) leaves that CPU configured but hotplugged off. # lscpu -e CPU NODE DRAWER BOOK SOCKET CORE L1d:L1i:L2 ONLINE CONFIGURED POLARIZATION ADDRESS 0 0 0 0 0 0 0:0:0 yes yes horizontal 0 1 0 0 0 1 1 1:1:1 yes yes horizontal 1 2 0 0 0 2 2 2:2:2 yes yes horizontal 2 3 0 0 0 3 3 3:3:3 yes yes horizontal 3 4 0 0 0 4 4 4:4:4 yes yes horizontal 4 5 0 0 0 5 5 5:5:5 yes yes horizontal 5 6 - - - - - - no yes horizontal 6 7 - - - - - - no yes horizontal 7 ---Debugger--- A debugger is not configured Machine Type = z/VM, LPAR ---uname output--- 6.8.0-41-generic #41-Ubuntu SMP Fri Aug 2 19:51:49 UTC 2024 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- Easiest way to reproduce is using a KVM guest to add new CPUs. 1. Before adding CPUs: $ virsh dumpxml vm <domain type='kvm' id='106'> ... <vcpu placement='static' current='6'>8</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> <vcpu id='6' enabled='no' hotpluggable='yes'/> <vcpu id='7' enabled='no' hotpluggable='yes'/> 2. Attempt to add CPUs to the guest in a "running" state. $ virsh setvcpus vm 8 --live 3. The guest XML is updated : ... <vcpu placement='static'>8</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/> <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/> </vcpus> 4. But inside the guest, the CPUs are in offline state: $ lscpu -e CPU NODE DRAWER BOOK SOCKET CORE L1d:L1i:L2 ONLINE CONFIGURED POLARIZATION ADDRESS 0 0 0 0 0 0 0:0:0 yes yes horizontal 0 1 0 0 0 1 1 1:1:1 yes yes horizontal 1 2 0 0 0 2 2 2:2:2 yes yes horizontal 2 3 0 0 0 3 3 3:3:3 yes yes horizontal 3 4 0 0 0 4 4 4:4:4 yes yes horizontal 4 5 0 0 0 5 5 5:5:5 yes yes horizontal 5 6 - - - - - - no yes horizontal 6 7 - - - - - - no yes horizontal 7 5. Post rebooting the guest, the CPUs are online: $ virsh reboot vm Inside the guest: $ lscpu -e CPU NODE DRAWER BOOK SOCKET CORE L1d:L1i:L2 ONLINE CONFIGURED POLARIZATION ADDRESS 0 0 0 0 0 0 0:0:0 yes yes horizontal 0 1 0 0 0 1 1 1:1:1 yes yes horizontal 1 2 0 0 0 2 2 2:2:2 yes yes horizontal 2 3 0 0 0 3 3 3:3:3 yes yes horizontal 3 4 0 0 0 4 4 4:4:4 yes yes horizontal 4 5 0 0 0 5 5 5:5:5 yes yes horizontal 5 6 0 0 0 6 6 6:6:6 yes yes horizontal 6 7 0 0 0 7 7 7:7:7 yes yes horizontal 7 The CPUs should be online after adding them to the system. Other distros already have a udev rule to circumvent this under; /etc/udev/rules.d/ The rule does a check if a newly added CPUs are configured but not online, then hotplugs it to make it online. If CPUs are NOT configured then they should stay offline. Contact Information = [email protected] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2078347/+subscriptions -- Mailing list: https://launchpad.net/~debcrafters-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~debcrafters-packages More help : https://help.launchpad.net/ListHelp
