[Kernel-packages] [Bug 1980730] Re: OVS internal port Hardware Offload implementation is missing in Jammy kernel
Hey Itai, The PR I filed for the feature inclusion above has been approved and will ship with the kernel released in the SRU cycle that just started today. The cycle should be done around 9/19. -Zack -- 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/1980730 Title: OVS internal port Hardware Offload implementation is missing in Jammy kernel Status in linux package in Ubuntu: Incomplete Status in linux source package in Jammy: In Progress Bug description: Platform: OpenStack Yoga, Ubuntu 22.04 Jammy, Kernel 5.15.0-37-generic When deploying Charmed Openstack deployment with HW Offload over Jammy series, some of the traffic workloads (mainly those related to Floating IP and NAT) will not be properly offloaded. In order to solve it, "OVS internal port offload" feature was introduced and pushed to upstream kernel. These are the main base patches for the feature we call "OVS internal port offload": b16eb3c81fe27978afdb2c111908d4d627a88d99 net/mlx5: Support internal port as decap route device 5e9942721749fc96b9df4b0545474153316c0571 net/mlx5e: Term table handling of internal port rules 166f431ec6beaf472bc2e116a202a127b64779e4 net/mlx5e: Add indirect tc offload of ovs internal port 100ad4e2d75837c9b42f49b3814b4b42ec9ebe46 net/mlx5e: Offload internal port as encap route device 27484f7170edabbda7b53650cd24d38295cffe60 net/mlx5e: Offload tc rules that redirect to ovs internal port dbac71f22954276633e525f958994f84a7bd303f net/mlx5e: Accept action skbedit in the tc actions list 4f4edcc2b84fecec66748ecbb90a84b981ecdaae net/mlx5: E-Switch, Add ovs internal port mapping to metadata support 189ce08ebf876df2b51f625877731055475352df net/mlx5e: Use generic name for the forwarding dev pointer 28e7606fa8f106cdc0355e0548396c037443e063 net/mlx5e: Refactor rx handler of represetor device Please make sure to take as well all patches the came later on top of those base patches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980730/+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 1980750] Re: pwr-mlxbf.c: Improve driver dependencies and fix zero allocating memory size
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1980750 Title: pwr-mlxbf.c: Improve driver dependencies and fix zero allocating memory size Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] Improve the driver dependency on the gpio driver. Move that dependency to the probe as instructed by maintainers. Flush if there is remaining work while the driver is removed. fix size for zero allocating memory. [Fix] * Instead of using SOFTDEP, return -EPROBE_DEFER if the gpio-mlxbf2.c driver is not loaded yet. * Flush work when driver is removed. * fix size for zero allocating memory. * Upgrade the driver version to 1.1 due to all above changes [Test Case] * Test case only valid on Board with BMC on it: * Make sure driver is loaded and no errors in dmesg. * issue a power reset from the BMC via IPMI. [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1980750/+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 1982980] Re: store the last executed chain also for clsact egress
** Changed in: linux-bluefield (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/1982980
Title:
store the last executed chain also for clsact egress
Status in linux-bluefield package in Ubuntu:
Fix Committed
Bug description:
* Explain the bug(s)
Misses on multi chain tc egress rules that are offloaded from ovs datapath
rules (ct rules on ovs' internal port devices)
will restart from recirc_id(0) again in OvS dp, instead of recirc_id that
matches where we left off
in tc (ovs recirc_id should be equal tc chain).
* brief explanation of fixes
Set the tc skb extension that stores the last executed tc chain which ovs
reads on misses to
set the starting recirc_id from.
* How to test
Setup ovs with ovs offload enabled, and add ip to internal port, example
with veth device:
function config_veth() {
local ns=$1
local ip=$2
local peer=${ns}_peer
local veth=${ns}_veth
echo "Create namespace $ns, veths: hv $veth <-> ns $peer ($ip)"
ip netns add $ns
ip link del $veth &>/dev/null
ip link add $veth type veth peer name $peer
ip link set $veth up
ip link set $peer netns $ns
ip netns exec $ns ifconfig $peer $ip/24 mtu 1400 up
}
IP1="7.7.7.1"
IP2="7.7.7.2"
config_veth ns0 $IP1
ifconfig ovs-br $IP2
ovs-vsctl add-br ovs-br
ovs-vsctl add-port ovs-br ns0_veth
ovs-vsctl add-port ovs-br ns1_veth
Add openflow rules and check if packets arriving to table=0 (default table
that corrosponds to recirc_id(0))
have ct mark that was only set if a later table was executed. Add a
unsupported offload action (in this case group), so we
will have miss from offloaded tc rules to ovs dp:
ovs-ofctl del-flows ovs-br
ovs-ofctl -O OpenFlow12 add-group ovs-br
'group_id=2,type=select,bucket=ct(commit,zone=1,table=2)'
ovs-ofctl add-flow ovs-br "table=0, arp, action=normal"
ovs-ofctl add-flow ovs-br "table=0, ip, +trk, actions=drop"
#bad flow
ovs-ofctl add-flow ovs-br "table=0, ip, -trk, actions=ct(commit,table=1)"
#good flow
ovs-ofctl add-flow ovs-br "table=1, in_port=1, actions=group:2"
ovs-ofctl add-flow ovs-br "table=2, ip, actions=normal"
run udp/tcp traffic from default ns 7.7.7.1 to ns1 7.7.7.2 and
check ovs-appctl dpctl/dump-flows
if bug occurs there should be a drop rule, because we got to recirc_id(0)
after missing in tc, and tc
already did the -trk ct(commit...) rule, so packet should be tracked
(+trk) when missed to ovs.
* What it could break.
Running the wrong datapath rules in OvS datapath.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1982980/+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 1981105] Re: i2c-mlxbf.c: support lock mechanism
** Changed in: linux-bluefield (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1981105 Title: i2c-mlxbf.c: support lock mechanism Status in linux-bluefield package in Ubuntu: Fix Committed Bug description: SRU Justification: [Impact] Support the I2C lock mechanism, otherwise there could be unexpected behavior when an i2c bus is accessed by several entities like the linux driver, ATF driver and UEFI driver. Make sure to pick up the ATF/UEFI image to accompany this change because at boot time ATF will ensure that the lock is released. [Fix] * Support lock and unlock * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. Make sure you load the latest ATF/UEFI image to accompany this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1981105/+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 1982357] Re: i2c-mlxbf.c: fix wrong variable name
** Changed in: linux-bluefield (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1982357 Title: i2c-mlxbf.c: fix wrong variable name Status in linux-bluefield package in Ubuntu: Fix Committed Bug description: SRU Justification: [Impact] We are using the wrong variable name priv->smbus->io instead of priv->mst_cause->io. This could result in unexpected i2c behavior. [Fix] * replace priv->smbus->io with priv->mst_cause->io [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1982357/+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 1982225] Re: i2c-mlxbf.c: replace ioremap_cache with ioremap
** Changed in: linux-bluefield (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1982225 Title: i2c-mlxbf.c: replace ioremap_cache with ioremap Status in linux-bluefield package in Ubuntu: Fix Committed Bug description: SRU Justification: [Impact] On later version of linux, ioremap_cache is deprecated so replace ioremap_cache with ioremap since it is deprecated in later kernels. [Fix] * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1982225/+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 1983498] [NEW] Jammy: Add OVS Internal Port HW Offload to mlx5 driver
Public bug reported: SRU Justification [Impact] A request has been made, originating from https://bugs.launchpad.net/bugs/1980730, to add support for OVS internal port offload for the mlx5 driver. This feature takes care of certain traffic workloads that are not currently being offloaded to the hardware. [Test Case] Tested by the requester. [Where things could go wrong] These changes could potentially introduce regressions in behavior of the mlx5 driver. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: Incomplete ** Also affects: linux (Ubuntu Jammy) 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/1983498 Title: Jammy: Add OVS Internal Port HW Offload to mlx5 driver Status in linux package in Ubuntu: Incomplete Status in linux source package in Jammy: Incomplete Bug description: SRU Justification [Impact] A request has been made, originating from https://bugs.launchpad.net/bugs/1980730, to add support for OVS internal port offload for the mlx5 driver. This feature takes care of certain traffic workloads that are not currently being offloaded to the hardware. [Test Case] Tested by the requester. [Where things could go wrong] These changes could potentially introduce regressions in behavior of the mlx5 driver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1983498/+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 1980730] Re: OVS internal port Hardware Offload implementation is missing in Jammy kernel
Hey Itai, That's great! When you were testing this, did you happen to do any other generic testing, or would the tests you did here be considered suitable for testing of the mlx5 driver to ensure there are no potential regressions? -Zack -- 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/1980730 Title: OVS internal port Hardware Offload implementation is missing in Jammy kernel Status in linux package in Ubuntu: Incomplete Bug description: Platform: OpenStack Yoga, Ubuntu 22.04 Jammy, Kernel 5.15.0-37-generic When deploying Charmed Openstack deployment with HW Offload over Jammy series, some of the traffic workloads (mainly those related to Floating IP and NAT) will not be properly offloaded. In order to solve it, "OVS internal port offload" feature was introduced and pushed to upstream kernel. These are the main base patches for the feature we call "OVS internal port offload": b16eb3c81fe27978afdb2c111908d4d627a88d99 net/mlx5: Support internal port as decap route device 5e9942721749fc96b9df4b0545474153316c0571 net/mlx5e: Term table handling of internal port rules 166f431ec6beaf472bc2e116a202a127b64779e4 net/mlx5e: Add indirect tc offload of ovs internal port 100ad4e2d75837c9b42f49b3814b4b42ec9ebe46 net/mlx5e: Offload internal port as encap route device 27484f7170edabbda7b53650cd24d38295cffe60 net/mlx5e: Offload tc rules that redirect to ovs internal port dbac71f22954276633e525f958994f84a7bd303f net/mlx5e: Accept action skbedit in the tc actions list 4f4edcc2b84fecec66748ecbb90a84b981ecdaae net/mlx5: E-Switch, Add ovs internal port mapping to metadata support 189ce08ebf876df2b51f625877731055475352df net/mlx5e: Use generic name for the forwarding dev pointer 28e7606fa8f106cdc0355e0548396c037443e063 net/mlx5e: Refactor rx handler of represetor device Please make sure to take as well all patches the came later on top of those base patches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980730/+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 1980774] Re: pwr-mlxbf.c: make hids local variables
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1980774 Title: pwr-mlxbf.c: make hids local variables Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] Both rst_pwr_hid and low_pwr_hid are only used in a single function so they should be local variables. [Fix] * Move rst_pwr_hid and low_pwr_hid to pwr_mlxbf_irq [Test Case] * build without warnings * pwr-mlxbf.c is loaded successfully * reset via BMC GPIO is successful [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1980774/+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 1980537] Re: ipmb_host.c: rename structs to be driver specific
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1980537 Title: ipmb_host.c: rename structs to be driver specific Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Fix] * In later kernels, "struct request" is already declared in a common linux include file: ./include/linux/blkdev.h * So rename the structs to ipmb_host_request and ipmb_host_response so that they are specific to the ipmb_host driver and don't cause compile errors in the future. [Test Case] * check that ipmb_host.c driver is loaded at boot time and with no errors * lsmod * check that the /dev/ipmi0 device file is created successfully * send ipmi commands from the BF DPU to the BMC and make sure the response is as expected. [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1980537/+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 1979264] Re: mlx-trio module license update
** Changed in: linux-bluefield (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1979264 Title: mlx-trio module license update Status in linux-bluefield package in Ubuntu: Fix Committed Bug description: SRU Justification: [Impact] mlx-trio module license info is currently only GPL and needs to be updated similar to other Mellanox platform drivers [Fix] Change module license from GPL to Dual BSD/GPL [Test Case] modinfo prints the updated license info [Regression Potential] Can be considered minimal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1979264/+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 1979045] Re: misleading error prints from mlx-trio
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1979045 Title: misleading error prints from mlx-trio Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] TRIO IRQs are triggered during normal operation and non-error events such as mlxfwreset and the prints from the handler are misleading to users in such instances. [Fix] Replace the dev_err calls with pr_debug. This will ensure that users do not see extraneous error messages from the driver. [Test Case] Running mlxfwreset with the trio driver loaded will see a lot of error prints and this patch will fix the same. [Regression Potential] Can be considered minimal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1979045/+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 1980525] Re: ipmb_dev_int.c: sync up with upstream
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1980525 Title: ipmb_dev_int.c: sync up with upstream Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] Sync up the ipmb_dev_int.c with the latest version available in the upstream master branch. [Fix] * cherry-pick fc26067c7417e7fafed7bcc97bda155d91988734 ipmi: remove open coded version of SMBus block write * backport ipmb_dev_int.c related change from commit 0924c5a0cbed5831a2a0ff2f9a19692265f1ab92 The above commit makes modifications to 3 files: ipmb_dev_int.c, ipmi_ipmb.c and ipmi_ssif.c ipmi_ipmb.c doesn't exist on 5.4, so we just pull the change targeting ipmb_dev_int.c [Test Case] * check ipmb_dev_int is loaded without failure (check dmesg and lsmod) * verify that /dev/ipmb-2 is created * run ipmi command from bmc to send requests to BF DPU and verify that the response is as expected [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1980525/+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 1980730] Re: OVS internal port Hardware Offload implementation is missing in Jammy kernel
I took a look at the kernel config and its identical to what this kernel was derived from (i.e., 5.15.0-37.39). Maybe something got confused and its not getting the raid config? Are you able to confirm that? I would assume this would need to live in the initrd so its probably missing from the one generated for this kernel. -Zack -- 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/1980730 Title: OVS internal port Hardware Offload implementation is missing in Jammy kernel Status in linux package in Ubuntu: Incomplete Bug description: Platform: OpenStack Yoga, Ubuntu 22.04 Jammy, Kernel 5.15.0-37-generic When deploying Charmed Openstack deployment with HW Offload over Jammy series, some of the traffic workloads (mainly those related to Floating IP and NAT) will not be properly offloaded. In order to solve it, "OVS internal port offload" feature was introduced and pushed to upstream kernel. These are the main base patches for the feature we call "OVS internal port offload": b16eb3c81fe27978afdb2c111908d4d627a88d99 net/mlx5: Support internal port as decap route device 5e9942721749fc96b9df4b0545474153316c0571 net/mlx5e: Term table handling of internal port rules 166f431ec6beaf472bc2e116a202a127b64779e4 net/mlx5e: Add indirect tc offload of ovs internal port 100ad4e2d75837c9b42f49b3814b4b42ec9ebe46 net/mlx5e: Offload internal port as encap route device 27484f7170edabbda7b53650cd24d38295cffe60 net/mlx5e: Offload tc rules that redirect to ovs internal port dbac71f22954276633e525f958994f84a7bd303f net/mlx5e: Accept action skbedit in the tc actions list 4f4edcc2b84fecec66748ecbb90a84b981ecdaae net/mlx5: E-Switch, Add ovs internal port mapping to metadata support 189ce08ebf876df2b51f625877731055475352df net/mlx5e: Use generic name for the forwarding dev pointer 28e7606fa8f106cdc0355e0548396c037443e063 net/mlx5e: Refactor rx handler of represetor device Please make sure to take as well all patches the came later on top of those base patches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980730/+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 1980730] Re: OVS internal port Hardware Offload implementation is missing in Jammy kernel
A kernel built with the above changes, plus later changes around OVS internal port can be found here: https://launchpad.net/~ztahenakos/+archive/ubuntu/zt-test-kernels/+sourcepub/13816612/+listing-archive-extra Please give this kernel a try and let us know if this has the hardware offload implementation correctly applied. -Zack -- 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/1980730 Title: OVS internal port Hardware Offload implementation is missing in Jammy kernel Status in linux package in Ubuntu: Incomplete Bug description: Platform: OpenStack Yoga, Ubuntu 22.04 Jammy, Kernel 5.15.0-37-generic When deploying Charmed Openstack deployment with HW Offload over Jammy series, some of the traffic workloads (mainly those related to Floating IP and NAT) will not be properly offloaded. In order to solve it, "OVS internal port offload" feature was introduced and pushed to upstream kernel. These are the main base patches for the feature we call "OVS internal port offload": b16eb3c81fe27978afdb2c111908d4d627a88d99 net/mlx5: Support internal port as decap route device 5e9942721749fc96b9df4b0545474153316c0571 net/mlx5e: Term table handling of internal port rules 166f431ec6beaf472bc2e116a202a127b64779e4 net/mlx5e: Add indirect tc offload of ovs internal port 100ad4e2d75837c9b42f49b3814b4b42ec9ebe46 net/mlx5e: Offload internal port as encap route device 27484f7170edabbda7b53650cd24d38295cffe60 net/mlx5e: Offload tc rules that redirect to ovs internal port dbac71f22954276633e525f958994f84a7bd303f net/mlx5e: Accept action skbedit in the tc actions list 4f4edcc2b84fecec66748ecbb90a84b981ecdaae net/mlx5: E-Switch, Add ovs internal port mapping to metadata support 189ce08ebf876df2b51f625877731055475352df net/mlx5e: Use generic name for the forwarding dev pointer 28e7606fa8f106cdc0355e0548396c037443e063 net/mlx5e: Refactor rx handler of represetor device Please make sure to take as well all patches the came later on top of those base patches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980730/+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 1976511] Re: kernel taint ( warning ) caused by smpboot.c: on 5.4.0
The Intel Xeon Platinum 8380 is an IceLake chip (see https://www.intel.com/content/www/us/en/products/sku/212287/intel-xeon- platinum-8380-processor-60m-cache-2-30-ghz/specifications.html). The change referenced by Zhanglei only addresses chips that are Skylake-X. There is a change in the upstream kernel that changes how this SNC detection works to now default it on except for COD (Cluster-on-Die, SNC is a newer implementation of this tech it seems): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc1=2c88d45edbb89029c1190bb3b136d2602f057c98 The hwe-5.13 kernel has this change, but the 5.4 kernel does not. -- 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/1976511 Title: kernel taint ( warning ) caused by smpboot.c: on 5.4.0 Status in linux package in Ubuntu: Confirmed Bug description: Apr 6 02:33:31 G292-280 kernel: [0.007531] [ cut here ] Apr 6 02:33:31 G292-280 kernel: [0.007531] sched: CPU #20's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Apr 6 02:33:31 G292-280 kernel: [0.007531] WARNING: CPU: 20 PID: 0 at /build/linux-hwe-5.4-9Mb2g5/linux-hwe-5.4-5.4.0/arch/x86/kernel/smpboot.c:426 topology_sane.isra.9+0x6c/0x70 Apr 6 02:33:31 G292-280 kernel: [0.007531] Modules linked in: Apr 6 02:33:31 G292-280 kernel: [0.007531] CPU: 20 PID: 0 Comm: swapper/20 Not tainted 5.4.0-107-generic #121~18.04.1-Ubuntu Apr 6 02:33:31 G292-280 kernel: [0.007531] Hardware name: GIGABYTE G292-280-00/MG52-G20-00, BIOS F02 10/28/2021 Apr 6 02:33:31 G292-280 kernel: [0.007531] RIP: 0010:topology_sane.isra.9+0x6c/0x70 Apr 6 02:33:31 G292-280 kernel: [0.007531] Code: 41 5c 5d c3 80 3d 1e 75 ba 01 00 75 ec 89 f1 41 89 d9 89 fe 45 89 e0 48 c7 c7 b8 00 b4 a6 c6 05 04 75 ba 01 01 e8 b4 c7 03 00 <0f> 0b eb cb 0f 1f 44 00 00 55 0f b6 05 a3 8d f0 01 c6 05 9c 8d f0 Apr 6 02:33:31 G292-280 kernel: [0.007531] RSP: :b76b58e17eb8 EFLAGS: 00010086 Apr 6 02:33:31 G292-280 kernel: [0.007531] RAX: RBX: RCX: a7264e88 Apr 6 02:33:31 G292-280 kernel: [0.007531] RDX: a7264e88 RSI: 0096 RDI: 0046 Apr 6 02:33:31 G292-280 kernel: [0.007531] RBP: b76b58e17ec8 R08: R09: 0002f680 Apr 6 02:33:31 G292-280 kernel: [0.007531] R10: 8b69bf80 R11: 02c0 R12: 0001 Apr 6 02:33:31 G292-280 kernel: [0.007531] R13: 0014 R14: 0014 R15: 0002 Apr 6 02:33:31 G292-280 kernel: [0.007531] FS: () GS:8b69bf80() knlGS: Apr 6 02:33:31 G292-280 kernel: [0.007531] CS: 0010 DS: ES: CR0: 80050033 Apr 6 02:33:31 G292-280 kernel: [0.007531] CR2: CR3: 007ee1a0a001 CR4: 00760ee0 Apr 6 02:33:31 G292-280 kernel: [0.007531] DR0: DR1: DR2: Apr 6 02:33:31 G292-280 kernel: [0.007531] DR3: DR6: fffe0ff0 DR7: 0400 Apr 6 02:33:31 G292-280 kernel: [0.007531] PKRU: Apr 6 02:33:31 G292-280 kernel: [0.007531] Call Trace: Apr 6 02:33:31 G292-280 kernel: [0.007531] set_cpu_sibling_map+0x14f/0x600 Apr 6 02:33:31 G292-280 kernel: [0.007531] start_secondary+0x6e/0x1c0 Apr 6 02:33:31 G292-280 kernel: [0.007531] secondary_startup_64+0xa4/0xb0 Apr 6 02:33:31 G292-280 kernel: [0.007531] ---[ end trace 789d1f3abd3d96d4 ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1976511/+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 1974246] Re: mlxbf_gige: increase MDIO polling rate
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1974246 Title: mlxbf_gige: increase MDIO polling rate Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] There is MDIO logic within the mlxbf_gige driver that currently polls for completed transactions every 100us. This has been reviewed and tested in the lab and found to be inefficient. [Fix] The fix is to modify the driver logic to increase the MDIO polling rate to 5us. With this change the amount of time spent waiting for the MDIO BUSY signal to de-assert drops from ~100us to ~27us for each operation. [Test Case] The driver should function as before, specifically: * driver probes successfully * oob_net0 link comes up, as seen with "ifconfig -a" * reset and power cycle testing toggle PHY hardware, and oob_net0 link still comes up [Regression Potential] This change affects all MDIO transactions to the board-level PHY device, and as such, could cause a regression with PHY communications. However, this change has been heavily tested. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1974246/+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 1974241] Re: mlxbf_gige: revert "add interrupt counts" commit
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1974241 Title: mlxbf_gige: revert "add interrupt counts" commit Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] There is a mlxbf_gige driver commit (ed0dd97e64a5) which pertains to "UBUNTU: SAUCE: mlxbf_gige: add interrupt counts to "ethtool -S". This logic is modified in upstream Linux, so this SAUCE commit will need to be reverted. [Fix] The fix is to revert this driver commit. [Test Case] With this commit reverted the driver should function as before (e.g. probe succeeds, oob_net0 link up, etc) EXCEPT that the output of "ethtool -S" will no longer show the interrupt counts. [Regression Potential] The amount of driver logic being reverted is quite small, so no potential for creating a regression. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1974241/+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 1974096] Re: cls_flower: Fix inability to match GRE/IPIP packets
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1974096 Title: cls_flower: Fix inability to match GRE/IPIP packets Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug When a packet of a new flow arrives in openvswitch kernel module, it dissects the packet and passes the extracted flow key to ovs-vswtichd daemon. If hw- offload configuration is enabled, the daemon creates a new TC flower entry to bypass openvswitch kernel module for the flow (TC flower can also offload flows to NICs but this time that does not matter). In this processing flow, I found the following issue in cases of GRE/IPIP packets. When ovs_flow_key_extract() in openvswitch module parses a packet of a new GRE (or IPIP) flow received on non-tunneling vports, it extracts information of the outer IP header for ip_proto/src_ip/dst_ip match keys. This means ovs-vswitchd creates a TC flower entry with IP protocol/addresses match keys whose values are those of the outer IP header. OTOH, TC flower, which uses flow_dissector (different parser from openvswitch module), extracts information of the inner IP header. * How to test The following flow is an example to describe the issue in more detail. <--- Outer IP -> <-- Inner IP --> +--+--+--+--+--+--+ | ip_proto | src_ip | dst_ip | ip_proto | src_ip | dst_ip | | 47 (GRE) | 192.168.10.1 | 192.168.10.2 | 6 (TCP) | 10.0.0.1 | 10.0.0.2 | +--+--+--+--+--+--+ In this case, TC flower entry and extracted information are shown as below: - ovs-vswitchd creates TC flower entry with: - ip_proto: 47 - src_ip: 192.168.10.1 - dst_ip: 192.168.10.2 - TC flower extracts below for IP header matches: - ip_proto: 6 - src_ip: 10.0.0.1 - dst_ip: 10.0.0.2 Thus, GRE or IPIP packets never match the TC flower entry, as each dissector behaves differently. IMHO, the behavior of TC flower (flow dissector) does not look correct, as ip_proto/src_ip/dst_ip in TC flower match means the outermost IP header information except for GRE/IPIP cases. This patch adds a new flow_dissector flag FLOW_DISSECTOR_F_STOP_BEFORE_ENCAP which skips dissection of the encapsulated inner GRE/IPIP header in TC flower classifier. * What it could break. N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1974096/+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 1971418] Re: network-manager/1.36.4-2ubuntu1 ADT test failure with linux/5.15.0-28.29
To reproduce this issue, the following can be done: 1. Create a jammy autopkgtest image via: autopkgtest-buildvm-cloud-ubuntu -r jammy 2. Install the 5.15.0-27-29+rfkill2 headers, modules, and unsigned image from https://launchpad.net/~ztahenakos/+archive/ubuntu/zt-test-kernels/+build/23733020 into the image. 3. Run the network-manager autopkgtest The kernel in step 2 is Jammy linux 5.15.0-27.28 with upstream 54f586a9153201 (rfkill: make new event layout opt-in) added on top. Based on comments in include/uapi/linux/rfkill.h, userspace changes may be necessary in order for correct communication with rfkill to work, otherwise we may start to see more failures in rfkill based tests or usage. -- 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/1971418 Title: network-manager/1.36.4-2ubuntu1 ADT test failure with linux/5.15.0-28.29 Status in linux package in Ubuntu: Invalid Status in network-manager package in Ubuntu: Invalid Status in urfkill package in Ubuntu: New Status in linux source package in Jammy: Fix Committed Status in network-manager source package in Jammy: Invalid Status in urfkill source package in Jammy: New Bug description: This is a scripted bug report about ADT failures while running network-manager tests for linux/5.15.0-28.29 on jammy. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/n/network-manager/20220503_090742_432dd@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/n/network-manager/20220429_062345_345a3@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/ppc64el/n/network-manager/20220429_060513_fc2a9@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971418/+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 1971418] Re: network-manager/1.36.4-2ubuntu1 ADT test failure with linux/5.15.0-28.29
** Also affects: urfkill Importance: Undecided Status: New ** No longer affects: urfkill ** Also affects: urfkill (Ubuntu) Importance: Undecided Status: New ** Attachment added: "urfkill.log" https://bugs.launchpad.net/ubuntu/+source/urfkill/+bug/1971418/+attachment/5588509/+files/urfkill.log -- 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/1971418 Title: network-manager/1.36.4-2ubuntu1 ADT test failure with linux/5.15.0-28.29 Status in linux package in Ubuntu: Invalid Status in network-manager package in Ubuntu: Invalid Status in urfkill package in Ubuntu: New Status in linux source package in Jammy: Fix Committed Status in network-manager source package in Jammy: Invalid Status in urfkill source package in Jammy: New Bug description: This is a scripted bug report about ADT failures while running network-manager tests for linux/5.15.0-28.29 on jammy. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/n/network-manager/20220503_090742_432dd@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/n/network-manager/20220429_062345_345a3@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/ppc64el/n/network-manager/20220429_060513_fc2a9@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971418/+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 1969374] Re: linux-bluefield: Fix build failure in mlxbf_gige
** Also affects: linux-bluefield (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-bluefield (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Zachary Tahenakos (ztahenakos) ** Changed in: linux-bluefield (Ubuntu Focal) Assignee: (unassigned) => Zachary Tahenakos (ztahenakos) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1969374 Title: linux-bluefield: Fix build failure in mlxbf_gige Status in linux-bluefield package in Ubuntu: Fix Committed Status in linux-bluefield source package in Focal: Fix Committed Bug description: SRU Justification [Impact] The latest PR to fix a certification issue has introduced a build failure. Specifically: net: mellanox: mlxbf_gige: Replace non-standard interrupt handling A build of the kernel fails with the following error: drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_main.c:380:12: error: implicit declaration of function 'acpi_dev_gpio_irq_get_by'; did you mean 'acpi_dev_gpio_irq_get'? [-Werror=implicit-function-declaration] [Fix] Cherry-picking: 809390219fb9c gpiolib: acpi: Allow to find GpioInt() resource by name and index The above commit reworks GpioInt() to allow finding the resource via name and index while preserving previous functionality. [Test Case] Beyond ensuring build still works, no testing of drivers using the reworked acpi_dev_gpio_irq_get function will be done, but it should still work as previously designed when NULL is passed for name. [Where problems could occur] Chance of regression should be very low with this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1969374/+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 1969374] Re: linux-bluefield: Fix build failure in mlxbf_gige
** Changed in: linux-bluefield (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1969374 Title: linux-bluefield: Fix build failure in mlxbf_gige Status in linux-bluefield package in Ubuntu: Fix Committed Bug description: SRU Justification [Impact] The latest PR to fix a certification issue has introduced a build failure. Specifically: net: mellanox: mlxbf_gige: Replace non-standard interrupt handling A build of the kernel fails with the following error: drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_main.c:380:12: error: implicit declaration of function 'acpi_dev_gpio_irq_get_by'; did you mean 'acpi_dev_gpio_irq_get'? [-Werror=implicit-function-declaration] [Fix] Cherry-picking: 809390219fb9c gpiolib: acpi: Allow to find GpioInt() resource by name and index The above commit reworks GpioInt() to allow finding the resource via name and index while preserving previous functionality. [Test Case] Beyond ensuring build still works, no testing of drivers using the reworked acpi_dev_gpio_irq_get function will be done, but it should still work as previously designed when NULL is passed for name. [Where problems could occur] Chance of regression should be very low with this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1969374/+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 1969374] [NEW] linux-bluefield: Fix build failure in mlxbf_gige
Public bug reported: SRU Justification [Impact] The latest PR to fix a certification issue has introduced a build failure. Specifically: net: mellanox: mlxbf_gige: Replace non-standard interrupt handling A build of the kernel fails with the following error: drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_main.c:380:12: error: implicit declaration of function 'acpi_dev_gpio_irq_get_by'; did you mean 'acpi_dev_gpio_irq_get'? [-Werror=implicit-function-declaration] [Fix] Cherry-picking: 809390219fb9c gpiolib: acpi: Allow to find GpioInt() resource by name and index The above commit reworks GpioInt() to allow finding the resource via name and index while preserving previous functionality. [Test Case] Beyond ensuring build still works, no testing of drivers using the reworked acpi_dev_gpio_irq_get function will be done, but it should still work as previously designed when NULL is passed for name. [Where problems could occur] Chance of regression should be very low with this change. ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1969374 Title: linux-bluefield: Fix build failure in mlxbf_gige Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification [Impact] The latest PR to fix a certification issue has introduced a build failure. Specifically: net: mellanox: mlxbf_gige: Replace non-standard interrupt handling A build of the kernel fails with the following error: drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_main.c:380:12: error: implicit declaration of function 'acpi_dev_gpio_irq_get_by'; did you mean 'acpi_dev_gpio_irq_get'? [-Werror=implicit-function-declaration] [Fix] Cherry-picking: 809390219fb9c gpiolib: acpi: Allow to find GpioInt() resource by name and index The above commit reworks GpioInt() to allow finding the resource via name and index while preserving previous functionality. [Test Case] Beyond ensuring build still works, no testing of drivers using the reworked acpi_dev_gpio_irq_get function will be done, but it should still work as previously designed when NULL is passed for name. [Where problems could occur] Chance of regression should be very low with this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1969374/+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 1968340] Re: ip6gre driver does not hold device reference
** Changed in: linux (Ubuntu Bionic) Status: In Progress => 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/1968340 Title: ip6gre driver does not hold device reference Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] When creating ip6gre interfaces in network namespaces, device references are not held, preventing further network namespaces from being created. [Test case] sudo modprobe ip6_gre unshare -Urn true unshare -Urn true The second unshare won't work and there will be "unregister_netdevice: waiting for ip6gre0 to become free. Usage count = -1" messages on kernel log. [Potential regression] ip6gre users can observe regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1968340/+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 1967292] Re: net/mlx5e: Fix page DMA map/unmap attributes
** Changed in: linux (Ubuntu Focal) Status: In Progress => 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/1967292 Title: net/mlx5e: Fix page DMA map/unmap attributes Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Fix Committed Status in linux source package in Impish: Fix Released Status in linux source package in Jammy: Fix Released Bug description: SRU Justification [Impact] Upstream commit 0b7cfa4082fbf550595bc0e40f05614bd83bf0cd is a fix to the Mellanox mlx5 driver that we would like to have you pick up. It fixes a bug that was introduced in the 4.7 kernel, so it should be applicable to pretty much every Linux distribution. The bug causes a Linux panic when a Mellanox CX-4 VF is present in the VM (for AccelNet) and swiotlb=force used on the kernel boot line. swiotlb=force would not normally be used, which is why we haven’t seen the problem reported previously, but it cropped up during some internal testing. We are trying to head off a potential problem in a future scenario for Confidential VMs. Primarily we want to ensure that any CVMs images have this fix, as we don’t want CVM images to exist in the wild that would fail in the future when CVMs with AccelNet are offered. Business Impact This scenario could also exist in non-Azure instances. [Test Case] Microsoft tested. [Where problems could appear] Weird DMA and data corruption issues might crop up. [Other Info] SF: #00328938 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967292/+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 1966803] Re: xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename()
** Changed in: linux (Ubuntu Focal) Status: In Progress => 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/1966803 Title: xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename() Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Bug description: SRU Justification: [Impact] * The xfs filesystem suffers from a deadlock issue in kernels < 5.5. This hangs IO to/from the affected filesystem. Sample backtraces added as a comment. [Fix] * 93597ae8dac0149b5c00b787cba6bf7ba213e666 93597ae8dac0 "xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename()" * This is from the upstream 5.5 kernel. [Test Plan] * Set up an Ubuntu Bionic/Focal installation using kernel 5.4. * Create and mount an XFS filesystem on a block device. * Exercise the filesystem to verify that IO does not hang. [Where problems could occur] * This patch could cause locking issues on XFS filesystems, requiring a system restart to correct. [Other Info] * Bug is difficult to reproduce, a test kernel on affected systems with the above patch prevented the issue. * Backports to earlier (4.15 and earlier) kernels have been omitted as the upstream patch does not apply cleanly and the issue has not been reproduced on them. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966803/+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 1917471] Re: [SRU][Regression] Revert "PM: ACPI: reboot: Use S5 for reboot" which causes Bus Fatal Error when rebooting system with BCM5720 NIC
** Changed in: linux (Ubuntu Focal)
Status: In Progress => 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/1917471
Title:
[SRU][Regression] Revert "PM: ACPI: reboot: Use S5 for reboot" which
causes Bus Fatal Error when rebooting system with BCM5720 NIC
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Impish:
Fix Released
Status in linux source package in Jammy:
Fix Released
Bug description:
SRU Justification:
[IMPACT]
This is being reported by a hardware partner as it is being noticed a
lot both in their internal testing teams and also being reported with
some frequency by customers who are seeing these messages in their
logs and thus it is generating an unusualy high volume of support
calls from the field.
In 5.4, commit d60cd06331a3566d3305b3c7b566e79edf4e2095 was introduced
upstream and pulled into Ubuntu between 5.4.0-58.64 and 5.4.0-59.65.
Upstream, these errors were discovered and that patch was reverted
(see Fix Below). We carry the revert commit in all subsequent Focal
HWE kernels starting at 5.12, but the fix was never pulled back into
Focal 5.4.
according to the hardware partner:
the following error messages are observed when rebooting a machine
that uses the BCM5720 chipset, which is a widely used 1GbE controller
found on LOMs and OCP NICs as well as many PCIe NIC models.
[ 146.429212] shutdown[1]: Rebooting.
[ 146.435151] kvm: exiting hardware virtualization
[ 146.575319] megaraid_sas :67:00.0: megasas_disable_intr_fusion is
called outbound_intr_mask:0x4009
[ 148.088133] [qede_unload:2236(eno12409)]Link is down
[ 148.183618] qede :31:00.1: Ending qede_remove successfully
[ 148.518541] [qede_unload:2236(eno12399)]Link is down
[ 148.625066] qede :31:00.0: Ending qede_remove successfully
[ 148.762067] ACPI: Preparing to enter system sleep state S5
[ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware
Error Source: 5
[ 148.803731] {1}[Hardware Error]: event severity: recoverable
[ 148.810191] {1}[Hardware Error]: Error 0, type: fatal
[ 148.816088] {1}[Hardware Error]: section_type: PCIe error
[ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point
[ 148.829026] {1}[Hardware Error]: version: 3.0
[ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010
[ 148.841140] {1}[Hardware Error]: device_id: :04:00.0
[ 148.847309] {1}[Hardware Error]: slot: 0
[ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00
[ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f
[ 148.865145] {1}[Hardware Error]: class_code: 02
[ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x0010,
aer_uncor_mask: 0x0001
[ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030
[ 148.886575] {1}[Hardware Error]: TLP Header: 4001 030f 90028090
[ 148.894823] tg3 :04:00.0: AER: aer_status: 0x0010, aer_mask:
0x0001
[ 148.902795] tg3 :04:00.0: AER:[20] UnsupReq (First)
[ 148.910234] tg3 :04:00.0: AER: aer_layer=Transaction Layer,
aer_agent=Requester ID
[ 148.918806] tg3 :04:00.0: AER: aer_uncor_severity: 0x000ef030
[ 148.925558] tg3 :04:00.0: AER: TLP Header: 4001 030f
90028090
[ 148.933984] reboot: Restarting system
[ 148.938319] reboot: machine restart
The hardware partner did some bisection and observed the following:
Kernel version Fatal Error
5.4.0-42.46 No
5.4.0-45.49 No
5.4.0-47.51 No
5.4.0-48.52 No
5.4.0-51.56 No
5.4.0-52.57 No
5.4.0-53.59 No
5.4.0-54.60 No
5.4.0-58.64 No
5.4.0-59.65 yes
5.4.0-60.67 yes
[FIX]
The fix is to apply this patch from upstream:
commit 9d3fcb28f9b9750b474811a2964ce022df56336e
Author: Josef Bacik
Date: Tue Mar 16 22:17:48 2021 -0400
Revert "PM: ACPI: reboot: Use S5 for reboot"
This reverts commit d60cd06331a3566d3305b3c7b566e79edf4e2095.
This patch causes a panic when rebooting my Dell Poweredge r440. I do
not have the full panic log as it's lost at that stage of the reboot and
I do not have a serial console. Reverting this patch makes my system
able to reboot again.
Example:
https://code.launchpad.net/~bladernr/ubuntu/+source/linux/+git/focal/+ref/1917471
The hardware partner has preemptively pulled our 5.4 tree, applied the
fix and tested it in their labs and determined that this does resolve
the issue.
[TEST CASE]
Install the patched kernel on a machine that uses a BCM5720 LOM and reboot
the machine and see that the errors no longer appear.
To manage notifications about this bug go to:
[Kernel-packages] [Bug 1965160] [NEW] linux: Fix failure in ubuntu_boot:log_check test
Public bug reported: SRU Justification [Impact] On systems with a broken BIOS that fail to program the APICID_TAG_MAP for DCA, the dmaengine will print a warning, with stack trace, to the kernel log, which just adds extra noise to the log and impacts testing on some platforms, mostly on the older side that will most likely not receive an update to their BIOS. [Fix] A patch from upstream linux changes the call of WARN_TAINT_ONCE() to pr_warn_once() and add_taint(). pr_warn_once() will not invoke a warning in the kernel and instead just print the associated message. [Test Case] The ubuntu_boot log_check test on an affected node, such as fili:amd64. [Where problems could occur] Chance of regression is very low to minimal with this change. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Xenial) Importance: Undecided Assignee: Zachary Tahenakos (ztahenakos) Status: Incomplete ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Zachary Tahenakos (ztahenakos) -- 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/1965160 Title: linux: Fix failure in ubuntu_boot:log_check test Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Incomplete Bug description: SRU Justification [Impact] On systems with a broken BIOS that fail to program the APICID_TAG_MAP for DCA, the dmaengine will print a warning, with stack trace, to the kernel log, which just adds extra noise to the log and impacts testing on some platforms, mostly on the older side that will most likely not receive an update to their BIOS. [Fix] A patch from upstream linux changes the call of WARN_TAINT_ONCE() to pr_warn_once() and add_taint(). pr_warn_once() will not invoke a warning in the kernel and instead just print the associated message. [Test Case] The ubuntu_boot log_check test on an affected node, such as fili:amd64. [Where problems could occur] Chance of regression is very low to minimal with this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1965160/+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 1912316] Re: log_check / kernel_tainted test from ubuntu_boot failed on Intel Cloud node grumman (failed with flag 2048)
Found with xenial/fips:4.4.0-1072.78 on node fili. ** Tags added: sru-20220221 -- 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/1912316 Title: log_check / kernel_tainted test from ubuntu_boot failed on Intel Cloud node grumman (failed with flag 2048) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Focal: Confirmed Status in linux source package in Groovy: Won't Fix Bug description: Issue found on node grumman, this is not a regression. The kernel_tainted check reports a non-zero flag 2048, this means "workaround for bug in platform firmware applied" log_check reports WARNINGs found in the dmesg: 10. 01/06 09:46:51 INFO |ubuntu_boo:0030| kernel: [ 7.852005] WARNING: CPU: 0 PID: 179 at /build/linux-0dlxvs/linux-4.4.0/drivers/dma/ioat/dca.c:342 ioat_dca_init+0x17c/0x1a0 [ioatdma]() 11. 01/06 09:46:51 INFO |ubuntu_boo:0030| kernel: [ 5.387292] WARNING: CPU: 0 PID: 181 at /build/linux-7Nk88i/linux-4.4.0/drivers/dma/ioat/dca.c:342 ioat_dca_init+0x17c/0x1a0 [ioatdma]() 12. 01/06 09:46:51 INFO |ubuntu_boo:0030| kernel: [ 6.039705] WARNING: CPU: 0 PID: 4 at /build/linux-7Nk88i/linux-4.4.0/drivers/dma/ioat/dca.c:342 ioat_dca_init+0x17c/0x1a0 [ioatdma]() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1912316/+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 1961566] Re: 5.15 kernel selftest srv6_end_dt6_l3vpn_test.sh failure
This issue is due to missing functionality in iproute2. Upstream commit 69629b4e43c4 from the iproute2 git repo adds the requisite functionality to fix this. -- 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/1961566 Title: 5.15 kernel selftest srv6_end_dt6_l3vpn_test.sh failure Status in linux package in Ubuntu: Incomplete Bug description: Kernel selftest srv6_end_dt6_l3vpn_test.sh fails on s2lp4.s390x: # selftests: net: srv6_end_dt6_l3vpn_test.sh # Error: either "to" is duplicate, or "vrftable" is a garbage. # Error: either "to" is duplicate, or "vrftable" is a garbage. # Error: either "to" is duplicate, or "vrftable" is a garbage. # Error: either "to" is duplicate, or "vrftable" is a garbage. ... # # TEST SECTION: SRv6 VPN connectivity test among hosts in the same tenant # # # TEST: Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [FAIL] # # TEST: Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [FAIL] # # TEST: Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [FAIL] # # TEST: Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [FAIL] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1961566/+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 1928890] Re: vrf_route_leaking.sh in net from ubuntu_kernel_selftests linux ADT test failure with linux/5.11.0-18.19 (Ping received ICMP Packet too big)
Doing some more research and testing, looking at the upstream commit
that added the test (1a01727676a8), this is in the bottom of the
message:
[ The IPv6 MTU test still fails with the symmetric routing setup. It
appears to be caused by source address selection picking ::1. Fixing
this is beyond the scope of this series. ]
Running the test in the failing state, we are indeed getting a Packet
too big message but we never seem to get it.
Now, within the create_vrf function, if we change the address added from ::1 to
::3
(ip -netns "${ns}" -6 addr add ::3 dev "${vrf}" nodad), it will start to work.
I wonder if its getting confused since in the failing case, the src is ::1 and
the dest is 2001:db8:16:1:1 so maybe the packet is going around in a loop or
something.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-5.10 in Ubuntu.
https://bugs.launchpad.net/bugs/1928890
Title:
vrf_route_leaking.sh in net from ubuntu_kernel_selftests linux ADT
test failure with linux/5.11.0-18.19 (Ping received ICMP Packet too
big)
Status in ubuntu-kernel-tests:
New
Status in linux package in Ubuntu:
Incomplete
Status in linux-oem-5.10 package in Ubuntu:
Confirmed
Status in linux source package in Hirsute:
Confirmed
Status in linux-oem-5.10 source package in Hirsute:
Confirmed
Bug description:
This is a scripted bug report about ADT failures while running linux
tests for linux/5.11.0-18.19 on hirsute. Whether this is caused by the
dep8 tests of the tested source or the kernel has yet to be
determined.
Not a regression. Found to occur previously on hirsute/linux
5.11.0-14.15
Testing failed on:
amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/l/linux/20210515_005957_75e5a@/log.gz
arm64:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/arm64/l/linux/20210513_203508_96fd3@/log.gz
ppc64el:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/ppc64el/l/linux/20210513_163708_c0203@/log.gz
s390x:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/s390x/l/linux/20210513_144454_54b04@/log.gz
00:09:30 DEBUG| [stdout] # selftests: net: vrf_route_leaking.sh
00:09:30 DEBUG| [stdout] #
00:09:30 DEBUG| [stdout] #
###
00:09:30 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP ttl error route lookup
ping
00:09:30 DEBUG| [stdout] #
###
00:09:30 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:32 DEBUG| [stdout] # TEST: Ping received ICMP ttl exceeded
[ OK ]
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP error route lookup
traceroute
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] # SKIP: Could not run IPV4 test without traceroute
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP fragmentation error
route lookup ping
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] #
00:09:34 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:34 DEBUG| [stdout] # TEST: Ping received ICMP Frag needed
[ OK ]
00:09:34 DEBUG| [stdout] #
00:09:34 DEBUG| [stdout] #
###
00:09:34 DEBUG| [stdout] # IPv4 (asym route): VRF ICMP ttl error route lookup
ping
00:09:34 DEBUG| [stdout] #
###
00:09:34 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:36 DEBUG| [stdout] # TEST: Ping received ICMP ttl exceeded
[ OK ]
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] #
###
00:09:36 DEBUG| [stdout] # IPv4 (asym route): VRF ICMP error route lookup
traceroute
00:09:36 DEBUG| [stdout] #
###
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] # SKIP: Could not run IPV4 test without traceroute
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] #
[Kernel-packages] [Bug 1928890] Re: vrf_route_leaking.sh in net from ubuntu_kernel_selftests linux ADT test failure with linux/5.11.0-18.19 (Ping received ICMP Packet too big)
Running this test on jammy 5.15, it passes if the vrf module is missing,
the ping will come back with the expected response of Packet too big.
With the vrf module loaded, we won't get the message back. Looking at
the strace of the command working vs failing, this is a difference
spotted:
vrf loaded:
recvmsg(3, {msg_namelen=128}, 0)= -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=128}, 0)= -1 EINTR (Interrupted system call)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
vrf missing:
recvmsg(3, {msg_namelen=128}, 0)= -1 EMSGSIZE (Message too long)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-5.10 in Ubuntu.
https://bugs.launchpad.net/bugs/1928890
Title:
vrf_route_leaking.sh in net from ubuntu_kernel_selftests linux ADT
test failure with linux/5.11.0-18.19 (Ping received ICMP Packet too
big)
Status in ubuntu-kernel-tests:
New
Status in linux package in Ubuntu:
Incomplete
Status in linux-oem-5.10 package in Ubuntu:
Confirmed
Status in linux source package in Hirsute:
Confirmed
Status in linux-oem-5.10 source package in Hirsute:
Confirmed
Bug description:
This is a scripted bug report about ADT failures while running linux
tests for linux/5.11.0-18.19 on hirsute. Whether this is caused by the
dep8 tests of the tested source or the kernel has yet to be
determined.
Not a regression. Found to occur previously on hirsute/linux
5.11.0-14.15
Testing failed on:
amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/l/linux/20210515_005957_75e5a@/log.gz
arm64:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/arm64/l/linux/20210513_203508_96fd3@/log.gz
ppc64el:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/ppc64el/l/linux/20210513_163708_c0203@/log.gz
s390x:
https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/s390x/l/linux/20210513_144454_54b04@/log.gz
00:09:30 DEBUG| [stdout] # selftests: net: vrf_route_leaking.sh
00:09:30 DEBUG| [stdout] #
00:09:30 DEBUG| [stdout] #
###
00:09:30 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP ttl error route lookup
ping
00:09:30 DEBUG| [stdout] #
###
00:09:30 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:32 DEBUG| [stdout] # TEST: Ping received ICMP ttl exceeded
[ OK ]
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP error route lookup
traceroute
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] # SKIP: Could not run IPV4 test without traceroute
00:09:32 DEBUG| [stdout] #
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] # IPv4 (sym route): VRF ICMP fragmentation error
route lookup ping
00:09:32 DEBUG| [stdout] #
###
00:09:32 DEBUG| [stdout] #
00:09:34 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:34 DEBUG| [stdout] # TEST: Ping received ICMP Frag needed
[ OK ]
00:09:34 DEBUG| [stdout] #
00:09:34 DEBUG| [stdout] #
###
00:09:34 DEBUG| [stdout] # IPv4 (asym route): VRF ICMP ttl error route lookup
ping
00:09:34 DEBUG| [stdout] #
###
00:09:34 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] # TEST: Basic IPv4 connectivity
[ OK ]
00:09:36 DEBUG| [stdout] # TEST: Ping received ICMP ttl exceeded
[ OK ]
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] #
###
00:09:36 DEBUG| [stdout] # IPv4 (asym route): VRF ICMP error route lookup
traceroute
00:09:36 DEBUG| [stdout] #
###
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] # SKIP: Could not run IPV4 test without traceroute
00:09:36 DEBUG| [stdout] #
00:09:36 DEBUG| [stdout] #
###
00:09:36 DEBUG| [stdout] # IPv6 (sym route): VRF ICMP ttl error route lookup
ping
00:09:36 DEBUG| [stdout] #
[Kernel-packages] [Bug 1953354] [NEW] glibc/2.33-0ubuntu5 ADT test failure with linux-kvm/5.11.0-1021.23
Public bug reported: This is a scripted bug report about ADT failures while running glibc tests for linux-kvm/5.11.0-1021.23 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/g/glibc/20211203_232031_b8a9a@/log.gz glibc encounters a timeout during testing: autopkgtest [22:42:14]: ERROR: timed out on command "su -s /bin/bash ubuntu -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest.Rcv9bW/build.fYR/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest.Rcv9bW/rebuild-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest.Rcv9bW/rebuild-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest.Rcv9bW/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest.Rcv9bW/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export 'ADT_TEST_TRIGGERS=linux-meta-kvm/5.11.0.1021.22 linux-kvm/5.11.0-1021.23 linux-signed-kvm/5.11.0-1021.23'; chmod +x /tmp/autopkgtest.Rcv9bW/build.fYR/src/debian/tests/rebuild; touch /tmp/autopkgtest.Rcv9bW/rebuild-stdout /tmp/autopkgtest.Rcv9bW/rebuild-stderr; /tmp/autopkgtest.Rcv9bW/build.fYR/src/debian/tests/rebuild 2> >(tee -a /tmp/autopkgtest.Rcv9bW/rebuild-stderr >&2) > >(tee -a /tmp/autopkgtest.Rcv9bW/rebuild-stdout);" (kind: test) autopkgtest [22:42:14]: test rebuild: ---] autopkgtest [22:42:20]: test rebuild: - - - - - - - - - - results - - - - - - - - - - rebuild FAIL timed out autopkgtest [22:42:20]: summary rebuild FAIL timed out ** Affects: glibc (Ubuntu) Importance: Undecided Status: New ** Affects: linux-kvm (Ubuntu) Importance: Undecided Status: New ** Tags: 5.11 hirsute kernel-adt-failure sru-20211129 ** Tags added: kernel-adt-failure ** Description changed: This is a scripted bug report about ADT failures while running glibc tests for linux-kvm/5.11.0-1021.23 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: - amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/g/glibc/20211203_232031_b8a9a@/log.gz + amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/g/glibc/20211203_232031_b8a9a@/log.gz + + glibc encounters a timeout during testing: + autopkgtest [22:42:14]: ERROR: timed out on command "su -s /bin/bash ubuntu -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest.Rcv9bW/build.fYR/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest.Rcv9bW/rebuild-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest.Rcv9bW/rebuild-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest.Rcv9bW/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest.Rcv9bW/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export 'ADT_TEST_TRIGGERS=linux-meta-kvm/5.11.0.1021.22 linux-kvm/5.11.0-1021.23 linux-signed-kvm/5.11.0-1021.23'; chmod +x /tmp/autopkgtest.Rcv9bW/build.fYR/src/debian/tests/rebuild; touch /tmp/autopkgtest.Rcv9bW/rebuild-stdout /tmp/autopkgtest.Rcv9bW/rebuild-stderr; /tmp/autopkgtest.Rcv9bW/build.fYR/src/debian/tests/rebuild 2> >(tee -a /tmp/autopkgtest.Rcv9bW/rebuild-stderr >&2) > >(tee -a /tmp/autopkgtest.Rcv9bW/rebuild-stdout);" (kind: test) + autopkgtest [22:42:14]: test rebuild: ---] + autopkgtest [22:42:20]: test rebuild: - - - - - - - - - - results - - - - - - - - - - + rebuild FAIL timed out + autopkgtest [22:42:20]: summary + rebuild FAIL timed out ** Tags added: 5.11 hirsute sru-20211129 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1953354 Title:
[Kernel-packages] [Bug 1953353] [NEW] glibc/2.33-0ubuntu5 ADT test failure with linux-kvm/5.11.0-1021.23
Public bug reported: This is a scripted bug report about ADT failures while running glibc tests for linux-kvm/5.11.0-1021.23 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/g/glibc/20211203_232031_b8a9a@/log.gz ** Affects: glibc (Ubuntu) Importance: Undecided Status: New ** Affects: linux-kvm (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-adt-failure ** Tags added: kernel-adt-failure -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1953353 Title: glibc/2.33-0ubuntu5 ADT test failure with linux-kvm/5.11.0-1021.23 Status in glibc package in Ubuntu: New Status in linux-kvm package in Ubuntu: New Bug description: This is a scripted bug report about ADT failures while running glibc tests for linux-kvm/5.11.0-1021.23 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/g/glibc/20211203_232031_b8a9a@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1953353/+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
