[Kernel-packages] [Bug 2042564] Re: Performance regression in the 5.15 Ubuntu 20.04 kernel compared to 5.4 Ubuntu 20.04 kernel
Work is still ongoing on reproducing this issue in a more predictable environment. -- 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/2042564 Title: Performance regression in the 5.15 Ubuntu 20.04 kernel compared to 5.4 Ubuntu 20.04 kernel Status in linux package in Ubuntu: New Status in linux source package in Focal: New Bug description: We in the Canonical Public Cloud team have received report from our colleagues in Google regarding a potential performance regression with the 5.15 kernel vs the 5.4 kernel on ubuntu 20.04. Their test were performed using the linux-gkeop and linux-gkeop-5.15 kernels. I have verified with the generic Ubuntu 20.04 5.4 linux-generic and the Ubuntu 20.04 5.15 linux-generic-hwe-20.04 kernels. The tests were run using `fio` fio commands: * 4k initwrite: `fio --ioengine=libaio --blocksize=4k --readwrite=write --filesize=40G --end_fsync=1 --iodepth=128 --direct=1 --group_reporting --numjobs=8 --name=fiojob1 --filename=/dev/sdc` * 4k overwrite: `fio --ioengine=libaio --blocksize=4k --readwrite=write --filesize=40G --end_fsync=1 --iodepth=128 --direct=1 --group_reporting --numjobs=8 --name=fiojob1 --filename=/dev/sdc` My reproducer was to launch an Ubuntu 20.04 cloud image locally with qemu the results are below: Using 5.4 kernel ``` ubuntu@cloudimg:~$ uname --kernel-release 5.4.0-164-generic ubuntu@cloudimg:~$ sudo fio --ioengine=libaio --blocksize=4k --readwrite=write --filesize=40G --end_fsync=1 --iodepth=128 --direct=1 --group_reporting --numjobs=8 --name=fiojob1 --filename=/dev/sda fiojob1: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=128 ... fio-3.16 Starting 8 processes Jobs: 8 (f=8): [W(8)][99.6%][w=925MiB/s][w=237k IOPS][eta 00m:01s] fiojob1: (groupid=0, jobs=8): err= 0: pid=2443: Thu Nov 2 09:15:22 2023 write: IOPS=317k, BW=1237MiB/s (1297MB/s)(320GiB/264837msec); 0 zone resets slat (nsec): min=628, max=37820k, avg=7207.71, stdev=101058.61 clat (nsec): min=457, max=56099k, avg=340.45, stdev=1707823.38 lat (usec): min=23, max=56100, avg=3229.78, stdev=1705.80 clat percentiles (usec): | 1.00th=[ 775], 5.00th=[ 1352], 10.00th=[ 1647], 20.00th=[ 2024], | 30.00th=[ 2343], 40.00th=[ 2638], 50.00th=[ 2933], 60.00th=[ 3261], | 70.00th=[ 3654], 80.00th=[ 4146], 90.00th=[ 5014], 95.00th=[ 5932], | 99.00th=[ 8979], 99.50th=[10945], 99.90th=[18220], 99.95th=[22676], | 99.99th=[32113] bw ( MiB/s): min= 524, max= 1665, per=100.00%, avg=1237.72, stdev=20.42, samples=4232 iops: min=134308, max=426326, avg=316855.16, stdev=5227.36, samples=4232 lat (nsec) : 500=0.01%, 750=0.01%, 1000=0.01% lat (usec) : 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%, 100=0.01% lat (usec) : 250=0.05%, 500=0.54%, 750=0.37%, 1000=0.93% lat (msec) : 2=17.40%, 4=58.02%, 10=22.01%, 20=0.60%, 50=0.07% lat (msec) : 100=0.01% cpu : usr=3.29%, sys=7.45%, ctx=1262621, majf=0, minf=103 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1% issued rwts: total=0,83886080,0,8 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=128 Run status group 0 (all jobs): WRITE: bw=1237MiB/s (1297MB/s), 1237MiB/s-1237MiB/s (1297MB/s-1297MB/s), io=320GiB (344GB), run=264837-264837msec Disk stats (read/write): sda: ios=36/32868891, merge=0/50979424, ticks=5/27498602, in_queue=1183124, util=100.00% ``` After upgrading to linux-generic-hwe-20.04 kernel and rebooting ``` ubuntu@cloudimg:~$ uname --kernel-release 5.15.0-88-generic ubuntu@cloudimg:~$ sudo fio --ioengine=libaio --blocksize=4k --readwrite=write --filesize=40G --end_fsync=1 --iodepth=128 --direct=1 --group_reporting --numjobs=8 --name=fiojob1 --filename=/dev/sda fiojob1: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=128 ... fio-3.16 Starting 8 processes Jobs: 1 (f=1): [_(7),W(1)][100.0%][w=410MiB/s][w=105k IOPS][eta 00m:00s] fiojob1: (groupid=0, jobs=8): err= 0: pid=1438: Thu Nov 2 09:46:49 2023 write: IOPS=155k, BW=605MiB/s (634MB/s)(320GiB/541949msec); 0 zone resets slat (nsec): min=660, max=325426k, avg=10351.04, stdev=232438.50 clat (nsec): min=1100, max=782743k, avg=6595008.67, stdev=6290570.04 lat (usec): min=86, max=782748, avg=6606.08, stdev=6294.03 clat percentiles (usec): | 1.00th=[ 914], 5.00th=[ 2180], 10.00th=[ 2802], 20.00th=[ 3556], | 30.00th=[ 4178], 40.00th=[ 4817], 50.00th=[ 5538], 60.00th=[ 6259], |
[Kernel-packages] [Bug 1951289] Re: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3, 9, 11, 17, 19, 25 report incorrect sched domain for cpu#32
Updating kunpeng920 series to match corresponding linux package status. ** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released ** Changed in: kunpeng920/ubuntu-18.04-hwe Status: Fix Committed => Fix Released ** Changed in: kunpeng920/ubuntu-18.04 Status: In Progress => Fix Released ** Changed in: kunpeng920 Status: In Progress => Fix Released -- 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/1951289 Title: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3,9,11,17,19,25 report incorrect sched domain for cpu#32 Status in kunpeng920: Fix Released Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in ubuntu-kernel-tests: Invalid Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Hirsute: Won't Fix Bug description: [Impact] The LTP cpuset_sched_domains test, authored by Miao Xie, fails on a Kunpeng920 server that has 4 NUMA nodes: https://launchpad.net/bugs/1951289 This does appear to be a real bug. /proc/schedstat displays 4 domain levels for CPUs on 2 of the nodes, but only 3 levels for the others 2 (see below). I assume this means the scheduler is making suboptimal decisions about where to place/move processes. [Test Case] On a 128 core Kunpeng 920 system, observe that half the CPUs are missing a 3rd level scheduling domain: ubuntu@d06-4:~$ grep domain2 /proc/schedstat | wc -l 128 ubuntu@d06-4:~$ grep domain3 /proc/schedstat | wc -l 64 ubuntu@d06-4:~$ [What Could Go Wrong] This changes the code used for populating sched domains, so it could potentially break on other systems, leading to poor scheduling characteristics (higher latencies, lower overall throughput etc). To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1951289/+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 1933301] Re: [uacc-0623] hisi_sec2 fail to alloc uacce
** Changed in: kunpeng920/ubuntu-22.04 Status: Fix Committed => Fix Released ** Changed in: kunpeng920 Status: Fix Committed => Fix Released -- 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/1933301 Title: [uacc-0623] hisi_sec2 fail to alloc uacce Status in kunpeng920: Fix Released Status in kunpeng920 ubuntu-20.04-hwe series: Fix Released Status in kunpeng920 ubuntu-21.10 series: Fix Released Status in kunpeng920 ubuntu-22.04 series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Impish: Fix Released Status in linux source package in Jammy: Fix Released Bug description: SRU Justification = [Impact] * Users with HiSilicon Security Engine (SEC) version 2 controller fail to allocate Uacce. [Fix] * upstream 183b60e005975d3c84c22199ca64a9221e620fb6 crypto: hisilicon/qm - modify the uacce mode check [Test Plan] * Deploy Ubuntu Focal with HWE 5.13 kernel to a Kunpeng920 chip with HiSilicon Security Engine (SEC) version 2 controller * Boot the system * 'dmesg | grep "fail to alloc uacce"' and you will see complains from hisi_sec2. For example: [ 27.015484] hisi_sec2 :b6:00.0: fail to alloc uacce (-22) [Where problems could occur] * The regression can be considered as low, since it is HiSilicon crypto system specific == Original Bug Description == [Bug Description] ubuntu 20.04.2 boot system and fail to alloc uacce (-22) [Steps to Reproduce] 1) boot ubuntu 20.04.2 system 2) dmesg | grep fail [Actual Results] [ 27.86] cma: cma_alloc: alloc failed, req-size: 4 pages, ret: -12 [ 27.006515] hisi_sec2 :b6:00.0: Failed to enable PASID [ 27.012043] hisi_sec2 :b6:00.0: Adding to iommu group 45 [ 27.015484] hisi_sec2 :b6:00.0: fail to alloc uacce (-22) [Expected Results] no fail [Reproducibility] 100% [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] this following patches will solve this bug. commit f8408d2b79b834f79b6c578817e84f74a85d2190 Author: Kai Ye Date: Tue Jan 5 14:16:42 2021 +0800 crypto: hisilicon - add ZIP device using mode parameter Add 'uacce_mode' parameter for ZIP, which can be set as 0(default) or 1. '0' means ZIP is only registered to kernel crypto, and '1' means it's registered to both kernel crypto and UACCE. Signed-off-by: Kai Ye Reviewed-by: Zhou Wang Reviewed-by: Zaibo Xu Signed-off-by: Herbert Xu commit bedd04e4aa1434d2f0f038e15bb6c48ac36876e1 Author: Kai Ye Date: Tue Jan 5 14:16:43 2021 +0800 crypto: hisilicon/hpre - register HPRE device to uacce commit 34932a6033be3c0088935c334e4dc5ad43dcb0cc Author: Kai Ye Date: Tue Jan 5 14:16:44 2021 +0800 crypto: hisilicon/sec - register SEC device to uacce To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1933301/+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 1927076] Re: IPv6 TCP in reuseport_bpf_cpu from ubuntu_kernel_selftests/net crash P8 node entei (Oops: Exception in kernel mode, sig: 4 [#1])
Marking as "incomplete" while waiting for input from Power MMU experts. ** Changed in: ubuntu-power-systems Status: Confirmed => Incomplete -- 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/1927076 Title: IPv6 TCP in reuseport_bpf_cpu from ubuntu_kernel_selftests/net crash P8 node entei (Oops: Exception in kernel mode, sig: 4 [#1]) Status in ubuntu-kernel-tests: New Status in The Ubuntu-power-systems project: Incomplete Status in linux package in Ubuntu: Incomplete Status in linux source package in Focal: Confirmed Status in linux source package in Hirsute: Won't Fix Bug description: It looks like our P8 node "entei" tend to fail with the IPv6 TCP test from reuseport_bpf_cpu in ubuntu_kernel_selftests/net on 5.8 kernels: # send cpu 119, receive socket 119 # send cpu 121, receive socket 121 # send cpu 123, receive socket 123 # send cpu 125, receive socket 125 # send cpu 127, receive socket 127 # IPv6 TCP publish-job-status: using request.json It failed silently here, this can be 100% reproduced with Groovy 5.8 and Focal 5.8. This will cause the ubuntu_kernel_selftests being interrupted, the test result for other tests cannot be processed to our result page. Please find attachment for the complete "net" test result on this node with Groovy 5.8.0-52.59 Add the kqa-blocker tag as this might needs to be manually verified. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1927076/+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 1933301] Re: [uacc-0623] hisi_sec2 fail to alloc uacce
** Changed in: kunpeng920/ubuntu-21.10 Status: Fix Committed => Fix Released -- 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/1933301 Title: [uacc-0623] hisi_sec2 fail to alloc uacce Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-20.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-21.10 series: Fix Released Status in kunpeng920 ubuntu-22.04 series: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Impish: Fix Released Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification = [Impact] * Users with HiSilicon Security Engine (SEC) version 2 controller fail to allocate Uacce. [Fix] * upstream 183b60e005975d3c84c22199ca64a9221e620fb6 crypto: hisilicon/qm - modify the uacce mode check [Test Plan] * Deploy Ubuntu Focal with HWE 5.13 kernel to a Kunpeng920 chip with HiSilicon Security Engine (SEC) version 2 controller * Boot the system * 'dmesg | grep "fail to alloc uacce"' and you will see complains from hisi_sec2. For example: [ 27.015484] hisi_sec2 :b6:00.0: fail to alloc uacce (-22) [Where problems could occur] * The regression can be considered as low, since it is HiSilicon crypto system specific == Original Bug Description == [Bug Description] ubuntu 20.04.2 boot system and fail to alloc uacce (-22) [Steps to Reproduce] 1) boot ubuntu 20.04.2 system 2) dmesg | grep fail [Actual Results] [ 27.86] cma: cma_alloc: alloc failed, req-size: 4 pages, ret: -12 [ 27.006515] hisi_sec2 :b6:00.0: Failed to enable PASID [ 27.012043] hisi_sec2 :b6:00.0: Adding to iommu group 45 [ 27.015484] hisi_sec2 :b6:00.0: fail to alloc uacce (-22) [Expected Results] no fail [Reproducibility] 100% [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] this following patches will solve this bug. commit f8408d2b79b834f79b6c578817e84f74a85d2190 Author: Kai Ye Date: Tue Jan 5 14:16:42 2021 +0800 crypto: hisilicon - add ZIP device using mode parameter Add 'uacce_mode' parameter for ZIP, which can be set as 0(default) or 1. '0' means ZIP is only registered to kernel crypto, and '1' means it's registered to both kernel crypto and UACCE. Signed-off-by: Kai Ye Reviewed-by: Zhou Wang Reviewed-by: Zaibo Xu Signed-off-by: Herbert Xu commit bedd04e4aa1434d2f0f038e15bb6c48ac36876e1 Author: Kai Ye Date: Tue Jan 5 14:16:43 2021 +0800 crypto: hisilicon/hpre - register HPRE device to uacce commit 34932a6033be3c0088935c334e4dc5ad43dcb0cc Author: Kai Ye Date: Tue Jan 5 14:16:44 2021 +0800 crypto: hisilicon/sec - register SEC device to uacce To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1933301/+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 1951289] Re: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3, 9, 11, 17, 19, 25 report incorrect sched domain for cpu#32
** Changed in: kunpeng920 Importance: Undecided => Low ** Changed in: kunpeng920 Assignee: (unassigned) => dann frazier (dannf) -- 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/1951289 Title: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3,9,11,17,19,25 report incorrect sched domain for cpu#32 Status in kunpeng920: New Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Incomplete Status in linux source package in Focal: Incomplete Status in linux source package in Hirsute: Incomplete Bug description: On scobee-kernel(arm64) with hirsute:linux(5.11.0-41.45) for sru-20211108 there are several reports about the sched domain not covering the full range. The same does not happen on kuzzle. But 32 is a bit of a suspicious number. Running tests... cpuset_sched_domains 1 TINFO: CPUs are numbered continuously starting at 0 (0-127) cpuset_sched_domains 1 TINFO: Nodes are numbered continuously starting at 0 (0-3) cpuset_sched_domains 1 TINFO: root group load balance test cpuset_sched_domains 1 TINFO: sched load balance: 0 cpuset_sched_domains 1 TINFO: CPU hotplug: cpuset_check_domains1 TPASS : check_sched_domains passed cpuset_sched_domains 1 TPASS: partition sched domains succeeded. cpuset_sched_domains 3 TINFO: root group load balance test cpuset_sched_domains 3 TINFO: sched load balance: 1 cpuset_sched_domains 3 TINFO: CPU hotplug: cpuset_check_domains1 TFAIL : cpuset_sched_domains_check.c:110: cpu32's sched domain is wrong(Domain: 0-127, CPU's Sched Domain: 0-95). cpuset_sched_domains 3 TFAIL: partition sched domains failed. cpuset_sched_domains 5 TINFO: root group load balance test cpuset_sched_domains 5 TINFO: sched load balance: 0 cpuset_sched_domains 5 TINFO: CPU hotplug: cpuset_check_domains1 TPASS : check_sched_domains passed cpuset_sched_domains 5 TPASS: partition sched domains succeeded. cpuset_sched_domains 7 TINFO: root group load balance test cpuset_sched_domains 7 TINFO: sched load balance: 0 cpuset_sched_domains 7 TINFO: CPU hotplug: cpuset_check_domains1 TPASS : check_sched_domains passed cpuset_sched_domains 7 TPASS: partition sched domains succeeded. cpuset_sched_domains 9 TINFO: root group load balance test cpuset_sched_domains 9 TINFO: sched load balance: 1 cpuset_sched_domains 9 TINFO: CPU hotplug: cpuset_check_domains1 TFAIL : cpuset_sched_domains_check.c:110: cpu32's sched domain is wrong(Domain: 0-127, CPU's Sched Domain: 0-95). cpuset_sched_domains 9 TFAIL: partition sched domains failed. cpuset_sched_domains 11 TINFO: root group load balance test cpuset_sched_domains 11 TINFO: sched load balance: 1 cpuset_sched_domains 11 TINFO: CPU hotplug: cpuset_check_domains1 TFAIL : cpuset_sched_domains_check.c:110: cpu32's sched domain is wrong(Domain: 0-127, CPU's Sched Domain: 0-95). cpuset_sched_domains 11 TFAIL: partition sched domains failed. cpuset_sched_domains 13 TINFO: general group load balance test cpuset_sched_domains 13 TINFO: root group info: cpuset_sched_domains 13 TINFO: sched load balance: 0 cpuset_sched_domains 13 TINFO: general group info: cpuset_sched_domains 13 TINFO: cpus: - cpuset_sched_domains 13 TINFO: sched load balance: 1 cpuset_check_domains1 TPASS : check_sched_domains passed cpuset_sched_domains 13 TPASS: partition sched domains succeeded. cpuset_sched_domains 15 TINFO: general group load balance test cpuset_sched_domains 15 TINFO: root group info: cpuset_sched_domains 15 TINFO: sched load balance: 0 cpuset_sched_domains 15 TINFO: general group info: cpuset_sched_domains 15 TINFO: cpus: 1 cpuset_sched_domains 15 TINFO: sched load balance: 0 cpuset_check_domains1 TPASS : check_sched_domains passed cpuset_sched_domains 15 TPASS: partition sched domains succeeded. cpuset_sched_domains 17 TINFO: general group load balance test cpuset_sched_domains 17 TINFO: root group info: cpuset_sched_domains 17 TINFO: sched load balance: 1 cpuset_sched_domains 17 TINFO: general group info: cpuset_sched_domains 17 TINFO: cpus: - cpuset_sched_domains 17 TINFO: sched load balance: 1 cpuset_check_domains1 TFAIL : cpuset_sched_domains_check.c:110: cpu32's sched domain is wrong(Domain: 0-127, CPU's Sched Domain: 0-95). cpuset_sched_domains 17 TFAIL: partition sched domains failed. cpuset_sched_domains 19 TINFO: general group load balance test cpuset_sched_domains 19 TINFO: root group info: cpuset_sched_domains 19 TINFO: sched load balance: 1 cpuset_sched_domains 19 TINFO: general group
[Kernel-packages] [Bug 1953386] Re: hisi_sas driver may oops in prep_ssp_v3_hw()
** Changed in: kunpeng920/ubuntu-18.04 Status: Fix Committed => Fix Released ** Changed in: kunpeng920 Status: Fix Committed => Fix Released -- 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/1953386 Title: hisi_sas driver may oops in prep_ssp_v3_hw() Status in kunpeng920: Fix Released Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] The hisi_sas driver occasionally oopses on boot. [ 32.724666] Unable to handle kernel NULL pointer dereference at virtual address 0110 [ 32.732720] Mem abort info: [ 32.735504] ESR = 0x9604 [ 32.738546] Exception class = DABT (current EL), IL = 32 bits [ 32.70] SET = 0, FnV = 0 [ 32.747482] EA = 0, S1PTW = 0 [ 32.750612] Data abort info: [ 32.753478] ISV = 0, ISS = 0x0004 [ 32.757298] CM = 0, WnR = 0 [ 32.760256] user pgtable: 4k pages, 48-bit VAs, pgd = (ptrval) [ 32.766755] [0110] *pgd= [ 32.771700] Internal error: Oops: 9604 [#1] SMP [ 32.776557] Modules linked in: realtek hibmc_drm aes_ce_blk aes_ce_cipher ttm crct10dif_ce ghash_ce drm_kms_helper ixgbe(+) syscopyarea sha2_ce sysfillrect sysimgblt fb_sys_fops ptp sha256_arm64 sha1_ce hns3 hisi_sas_v3_hw(+) hinic pps_core hisi_sas_main drm hclge mdio libsas ahci hnae3 scsi_transport_sas libahci gpio_dwapb hid_generic usbhid hid aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 32.811755] Process kworker/u256:1 (pid: 1280, stack limit = 0x (ptrval)) [ 32.819118] CPU: 66 PID: 1280 Comm: kworker/u256:1 Not tainted 4.15.18+ #24 [ 32.826047] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B160.01 01/15/2020 [ 32.834884] Workqueue: :74:02.0_disco_q sas_discover_domain [libsas] [ 32.839182] hns3 :bd:00.0 enp189s0f0: renamed from eth8 [ 32.841558] pstate: a0c9 (NzCv daif +PAN +UAO) [ 32.851878] pc : prep_ssp_v3_hw+0x64/0x340 [hisi_sas_v3_hw] [ 32.857426] lr : hisi_sas_task_exec.constprop.0+0x304/0x640 [hisi_sas_main] [ 32.864354] sp : 21833a00 [ 32.867653] x29: 21833a00 x28: b790728621e0 [ 32.872940] x27: b790728607d8 x26: b79072861158 [ 32.878227] x25: d7b07b9340a0 x24: 0028 [ 32.883515] x23: d7906cd69400 x22: d7906cd69418 [ 32.02] x21: b79072aad3d0 x20: 21b33000 [ 32.894089] x19: b79072aad3d0 x18: 0030 [ 32.899376] x17: 9e710776 x16: 3efb16aabb00 [ 32.904663] x15: x14: 3efb976abcef [ 32.909950] x13: 0006 x12: b79072863480 [ 32.915237] x11: b79072aad3e0 x10: b79072861148 [ 32.920524] x9 : x8 : 24cc0fb0 [ 32.925812] x7 : x6 : 003f [ 32.931099] x5 : 0040 x4 : 20a0 [ 32.936386] x3 : d79071e2d400 x2 : 21833bb4 [ 32.941673] x1 : b79072863460 x0 : 28a0 [ 32.946960] Call trace: [ 32.949398] prep_ssp_v3_hw+0x64/0x340 [hisi_sas_v3_hw] [ 32.954600] hisi_sas_task_exec.constprop.0+0x304/0x640 [hisi_sas_main] [ 32.961184] hisi_sas_exec_internal_tmf_task+0xec/0x290 [hisi_sas_main] [ 32.967767] hisi_sas_init_device+0x84/0x100 [hisi_sas_main] [ 32.973401] hisi_sas_dev_found+0xa4/0x24c [hisi_sas_main] [ 32.978864] sas_notify_lldd_dev_found+0x44/0xc0 [libsas] [ 32.984239] sas_discover_end_dev+0x24/0x30 [libsas] [ 32.989182] sas_ex_discover_devices+0x950/0xbfc [libsas] [ 32.994557] sas_discover_root_expander+0x12c/0x150 [libsas] [ 33.000192] sas_discover_domain+0x340/0x664 [libsas] [ 33.005225] process_one_work+0x1bc/0x3ec [ 33.009217] worker_thread+0x58/0x4a0 [ 33.012863] kthread+0x13c/0x170 [ 33.016077] ret_from_fork+0x10/0x18 [ 33.019638] Code: 2a004820 2a04 f9400ed8 f9410061 (3943a319) [ 33.025705] ---[ end trace da9256b7aa3297ba ]--- [Test Case] Boot a hi1620-based server w/ root disk attached to hisi_sas v3 controller. [Fix] e1ba0b0b4451 scsi: hisi_sas: Fix to only call scsi_get_prot_op() for non-NULL scsi_cmnd [Where things could go wrong] We could potentially be trading one boot time crash for another that hasn't popped up in testing. To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1953386/+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 1930086] Re: [22.04 FEAT] gcc tunings for power9
** Changed in: gcc-defaults (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-power-systems Status: New => In Progress -- 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/1930086 Title: [22.04 FEAT] gcc tunings for power9 Status in The Ubuntu-power-systems project: In Progress Status in gcc-defaults package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Bug description: This is an Ubuntu-power-systems 22.04 LTS feature bug to track changing the gcc configure options from --with-cpu=power8 to --with- cpu=power9. Prerequisites for this bug include power9 builder hardware in Canonical datacenter. I'm still learning my way around Debian/Ubuntu source so go easy on me if this isn't the correct branch: https://salsa.debian.org/toolchain- team/gcc/-/blob/gcc-10-debian/debian/rules2#L394 But we'll want to add some logic around line 394 to add --with- cpu=power9 for 22.04 and possibly --with-tune=? but I'll reverse mirror this bug and verify with our IBM Power toolchain architect. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1930086/+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 1951470] Re: webkit javascript segmentation fault
** Also affects: ubuntu-z-systems 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/1951470 Title: webkit javascript segmentation fault Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: == Comment: #0 - Andreas Krebbel - 2021-11-15 09:29:44 == ---Problem Description--- Segmentation fault from WebKit Javascript engine Contact Information = andreas.kreb...@de.ibm.com ---uname output--- Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = IBM Z ---Debugger--- A debugger is not configured ---Steps to Reproduce--- index.html: min.js: var i = Math.max wkhtmltopdf index.html test.pdf QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Loading page (1/2) Segmentation fault (core dumped) ] 17% Userspace tool common name: wkhtmltopdf The userspace tool has the following bit modes: 64 Userspace rpm: libqt5webkit5 Userspace tool obtained from project website: na *Additional Instructions for andreas.kreb...@de.ibm.com: -Attach ltrace and strace of userspace application. == Comment: #1 - Andreas Krebbel - 2021-11-15 09:44:04 == In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes the property offset as pointer size (hence 64 bit) value: 2141: instructions[i + 6].u.pointer = reinterpret_cast(op.operand); while the same slot is accessed later by the jitted code as 32 bit integer: macro getProperty(slow) loadisFromInstruction(6, t1) This fails on big endian targets since the integer access takes the higher part of the 64 bit value. Changing: macro getProperty(slow) loadisFromInstruction(6, t1) to macro getProperty(slow) loadpFromInstruction(6, t1) in llint/LowLevelInterpreter64.asm fixes the problem for me. I could not reproduce the problem on Ubuntu 20.10. In upstream webkit the problem got fixed as a side effect of a larger change but in the end quite similar to the change I'm proposing. The value resides somewhere else now but it is accessed as 64 bit value in getProperty: macro getProperty() loadp OpGetFromScope::Metadata::m_operand[t5], t1 If you have the jsc binary from the webkit package available the problem can be reproduced with just 'jsc -e "i=Math.min"' == Comment: #2 - Andreas Krebbel - 2021-11-15 09:49:55 == To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+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 1935583] Re: Kernel panic on Bionic 5.4.0-47-generic
** Changed in: kunpeng920 Status: Incomplete => Invalid -- 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/1935583 Title: Kernel panic on Bionic 5.4.0-47-generic Status in kunpeng920: Invalid Status in linux package in Ubuntu: Expired Bug description: [Bug Description] Stack overflow in Kunpeng 920 32cores server, cause system reboot in production environment every month [Steps to Reproduce] 1)I cannot reproduce coz its a low-probability event [Actual Results] [1474521.296779] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.323300] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.349890] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.376451] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.411383] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.438042] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.455965] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.481140] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.508051] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.534519] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.561541] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.565243] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.596849] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.623516] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.659077] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.677128] Kernel panic - not syncing: corrupted stack end detected inside scheduler [1474521.685108] CPU: 7 PID: 5387 Comm: query_event Kdump: loaded Tainted: G OE 5.4.0-47-generic #51~18.04.1-Ubuntu [1474521.686201] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [1474521.689690] Unable to handle kernel paging request at virtual address 8027ce43b007 [1474521.689693] Mem abort info: [1474521.689695] ESR = 0x9605 [1474521.689698] EC = 0x25: DABT (current EL), IL = 32 bits [1474521.689700] SET = 0, FnV = 0 [1474521.689702] EA = 0, S1PTW = 0 [1474521.689703] Data abort info: [1474521.689705] ISV = 0, ISS = 0x0005 [1474521.689706] CM = 0, WnR = 0 [1474521.689710] swapper pgtable: 4k pages, 48-bit VAs, pgdp=014ac000 [1474521.689712] [8027ce43b007] pgd=2027f003, pud= [1474521.689719] Internal error: Oops: 9605 [#1] SMP [1474521.689722] Modules linked in: binfmt_misc xt_MASQUERADE iptable_nat nf_nat xt_tcpudp xt_multiport xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter rpcsec_gss_krb5 nfsv4 nfs fscache bonding nls_iso8859_1 ipmi_ssif joydev input_leds hns_roce_hw_v2 ib_uverbs ipmi_si spi_dw_mmio ipmi_devintf ipmi_msghandler spi_dw hisi_dma cppc_cpufreq sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear ses enclosure mlx5_ib(OE) hibmc_drm realtek drm_vram_helper ttm drm_kms_helper hid_generic crct10dif_ce syscopyarea sysfillrect ghash_ce mlx5_core(OE) sysimgblt hisi_sas_v3_hw sha2_ce hns3 hisi_sas_main sha256_arm64 fb_sys_fops mlx_compat(OE) sha1_ce hclge libsas usbhid tls drm hid hnae3 megaraid_sas ahci [1474521.689802] scsi_transport_sas mlxfw(OE) gpio_dwapb aes_neon_bs aes_neon_blk aes_ce_blk crypto_simd cryptd aes_ce_cipher [1474521.689814] CPU: 14 PID: 5899 Comm: tcp_upload Kdump: loaded Tainted: G OE 5.4.0-47-generic #51~18.04.1-Ubuntu [1474521.689816] Hardware name: [About Privacy Deleted], BIOS 1.39 06/11/2020 [1474521.689819] pstate: 0049 (nzcv daif +PAN -UAO) [1474521.689831] pc : kmem_cache_alloc+0x4c/0x220 [1474521.689835] lr : kmem_cache_alloc+0x44/0x220 [1474521.689836] sp : 800010073b90 [1474521.689838] x29: 800010073b90 x28: 0001 [1474521.689841] x27: 0027b78270c0 x26: 2027cc2b [1474521.689844] x25: 05ea x24: 0040 [1474521.689847] x23: 2027d3896000 x22: 800010c11a8c [1474521.689850] x21: 0a20 x20: 0007 [1474521.689852] x19: 2027d3896000 x18: 0014 [1474521.689856] x17: ea74f425 x16: 5fe3fcbf [1474521.689859] x15: f26bfafa x14: 683f9e854da8ab18 [1474521.689862] x13: e3274a9b1fac7e1b x12: 298175ef2f49b6e3 [1474521.689864] x11: 5ac56f1f37f55ef9 x10: 0040 [1474521.689867] x9 : 000a x8 : 0006 [1474521.689870] x7 : 800011b78908 x6 :
[Kernel-packages] [Bug 1909286] Re: ubuntu_kernel_selftest will be interrupted with the reuseport_bpf_cpu / reuseport_bpf_numa test in net (BUG: Unable to handle kernel instruction fetch (NULL pointer
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Status: New => Confirmed -- 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/1909286 Title: ubuntu_kernel_selftest will be interrupted with the reuseport_bpf_cpu / reuseport_bpf_numa test in net (BUG: Unable to handle kernel instruction fetch (NULL pointer?)) Status in ubuntu-kernel-tests: Confirmed Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in linux source package in Hirsute: Confirmed Bug description: Issue found with 5.4.0-59.65~18.04.1 P8 node entei and dryden It looks like the ubuntu_kernel_selftests will be interrupted when running the reuseport_bpf_cpu / reuseport_bpf_numa in net category. From the jenkins test log you will see the test didn't finish. For node entei: 07:37:44 DEBUG| [stdout] # selftests: net: reuseport_bpf_cpu 07:37:44 DEBUG| [stdout] # IPv4 UDP 07:37:44 DEBUG| [stdout] # send cpu 0, receive socket 0 07:37:44 DEBUG| [stdout] # send cpu 1, receive socket 1 07:37:44 DEBUG| [stdout] # send cpu 2, receive socket 2 ... 07:37:44 DEBUG| [stdout] # send cpu 123, receive socket 123 07:37:44 DEBUG| [stdout] # send cpu 125, receive socket 125 07:37:44 DEBUG| [stdout] # send cpu 127, receive socket 127 07:37:44 DEBUG| [stdout] # IPv6 UDP 07:37:44 DEBUG| [stdout] # send cpu 0, receive socket 0 07:37:44 DEBUG| [stdout] # send cpu 1, receive socket 1 07:37:44 DEBUG| [stdout] # send cpu 2, receive socket 2 07:37:44 DEBUG| [stdout] # send cpu 123, receive socket 123 07:37:44 DEBUG| [stdout] # send cpu 125, receive socket 125 07:37:44 DEBUG| [stdout] # send cpu 127, receive socket 127 07:37:44 DEBUG| [stdout] # IPv4 TCP + ARCHIVE=/var/lib/jenkins/jobs/sru-misc__B-hwe-5.4_ppc64el-generic__using_entei__for_kernel/builds/1/archive + scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -r ubuntu@entei:kernel-test-results /var/lib/jenkins/jobs/sru-misc__B-hwe-5.4_ppc64el-generic__using_entei__for_kernel/builds/1/archive For node dryden: 08:22:09 DEBUG| [stdout] ok 2 selftests: net: reuseport_bpf_cpu 08:22:09 DEBUG| [stdout] # selftests: net: reuseport_bpf_numa 08:22:09 DEBUG| [stdout] # IPv4 UDP + ARCHIVE=/var/lib/jenkins/jobs/sru-misc__B-hwe-5.4_ppc64el-generic__using_dryden__for_kernel/builds/2/archive + scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -r ubuntu@dryden:kernel-test-results /var/lib/jenkins/jobs/sru-misc__B-hwe-5.4_ppc64el-generic__using_dryden__for_kernel/builds/2/archive This issue does not exist in Focal 5.4 Trace back to older Bionic 5.4 kernel: * 5.4.0-58.64~18.04.1 - not tested * 5.4.0-57.63~18.04.1 - this issue does not exist as the bpf test build is blocking the build of net test * 5.4.0-56.62~18.04.1 - missing test result as node modoc is broken * 5.4.0-52.57~18.04.1 - no such issue with node modoc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1909286/+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 1936771] Re: disable “CONFIG_HISI_DMA” config for ubuntu version
** Changed in: kunpeng920/ubuntu-20.04 Status: In Progress => Fix Committed ** Changed in: kunpeng920/ubuntu-20.04-hwe Status: In Progress => Fix Committed ** Changed in: kunpeng920 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/1936771 Title: disable “CONFIG_HISI_DMA” config for ubuntu version Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 ubuntu-20.04-hwe series: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Committed Status in linux source package in Impish: In Progress Bug description: [Impact] Setup soft RAID5 on kunpeng920 machine and system will crash because of hisi_dma timeout. This issue can be reproduced with all Ubuntu kernel with hisi_dma. [Test Plan] Setup soft RAID5 and wait for few seconds. Kernel will crash. [Regression Risk] CONFIG_HISI_DMA only affects kunpeng920 platform. Minimal risk for other platform, and full regression test is needed on kunpeng920. === [Bug Description] disable “CONFIG_HISI_DMA” config for ubuntu version [Steps to Reproduce] 1) 2) 3) [Actual Results] this module cause some error [Expected Results] ok [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1936771/+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 1927076] Re: IPv6 TCP in reuseport_bpf_cpu from ubuntu_kernel_selftests/net crash P8 node entei on 5.8 kernel (Oops: Exception in kernel mode, sig: 4 [#1])
Since the groovy 5.8 kernel is now EOL, can this be reproduced with the 5.11 kernel? Or can we close this bug out? ** Changed in: ubuntu-power-systems Status: New => Incomplete -- 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/1927076 Title: IPv6 TCP in reuseport_bpf_cpu from ubuntu_kernel_selftests/net crash P8 node entei on 5.8 kernel (Oops: Exception in kernel mode, sig: 4 [#1]) Status in ubuntu-kernel-tests: New Status in The Ubuntu-power-systems project: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: It looks like our P8 node "entei" tend to fail with the IPv6 TCP test from reuseport_bpf_cpu in ubuntu_kernel_selftests/net on 5.8 kernels: # send cpu 119, receive socket 119 # send cpu 121, receive socket 121 # send cpu 123, receive socket 123 # send cpu 125, receive socket 125 # send cpu 127, receive socket 127 # IPv6 TCP publish-job-status: using request.json It failed silently here, this can be 100% reproduced with Groovy 5.8 and Focal 5.8. This will cause the ubuntu_kernel_selftests being interrupted, the test result for other tests cannot be processed to our result page. Please find attachment for the complete "net" test result on this node with Groovy 5.8.0-52.59 Add the kqa-blocker tag as this might needs to be manually verified. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1927076/+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 1939127] Re: ubuntu_kernel_selftests:powerpc:subpage_prot_anon: Failed with 3072 errors on Bionic 4.15 P9
I notice that both this issue and the one in lp:1813140 were both seen
on the same P9 system ("baltar"). Can this be reproduced on any other P9
systems?
Does it reliably fail, or does it only fail occasionally?
** Changed in: ubuntu-power-systems
Status: New => Incomplete
--
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/1939127
Title:
ubuntu_kernel_selftests:powerpc:subpage_prot_anon: Failed with 3072
errors on Bionic 4.15 P9
Status in ubuntu-kernel-tests:
New
Status in The Ubuntu-power-systems project:
Incomplete
Status in linux package in Ubuntu:
New
Status in linux source package in Bionic:
New
Bug description:
On host baltar with bionic:linux 4.15 for 2021.07.19 (but already same
in prev cycle):
...
[stdout] Failed at 0x72353a232000 (p=1023,sp=2,w=0), want=fault, got=pass !
[stdout] Failed at 0x72353a232000 (p=1023,sp=2,w=1), want=fault, got=pass !
[stdout] 3072 errors detected
[stdout] failure: subpage_prot_anon
[stdout] not ok 1..2 selftests: subpage_prot [FAIL]
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1939127/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
Adjusting priority to high while waiting for patches to test. ** Changed in: ubuntu-power-systems Importance: Critical => High -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1929921] Re: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High -- 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/1929921 Title: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- === IBM z15 with D41C Bundle S39a and z/VM 7.2.0 guest with crypto cards attached OS: Ubuntu 20.04.2 (focal fossa) with 5.4.0-73-generic and libica 3.6.1 installed Core dump when running the eddsa_test from libica Details === The available openSSL version is: OpenSSL 1.1.1f 31 Mar 2020 The ibmca engine was installed, but not defined into the openssl.cnf file, openssl engine displayed the default line: (dynamic) Dynamic engine loading support The segmentation fault was generated by `./eddsa_test'. Program terminated with signal SIGSEGV, Segmentation fault in openSSL (gdb) bt #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 #1 0x03ff898a26fa in ica_ed25519_ctx_del (ctx=0x3fff9b7e010) at ica_api.c:1897 #2 0x02aa28986f14 in ed25519_stress () at eddsa_test.c:441 #3 0x02aa289831bc in main (argc=0x1, argv=0x3fff9b7eaf8) at eddsa_test.c:66 See https://wiki.ubuntu.com/Debug%20Symbol%20Packages about how to define debug repositories apt install libica3-dbgsym #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 (gdb) bt # coredumpctl dump 158582 > eddsa.core PID: 158582 (eddsa_test) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Wed 2021-05-26 19:52:28 CEST (15h ago) Command Line: ./eddsa_test Executable: /root/crypto/libica-3.6.1/test/eddsa_test Control Group: /user.slice/user-0.slice/session-9.scope Unit: session-9.scope Slice: user-0.slice Session: 9 Owner UID: 0 (root) Boot ID: 6a7a23240f464a0d9f2d3fa3e82be73e Machine ID: c933ae494f9a4c6e8d82625c952945d5 Hostname: t3514002.lnxne.boe Storage: /var/lib/systemd/coredump/core.eddsa_test.0.6a7a23240f464a0d9f2d3fa3e82be73e.158582.1622051548.lz4 Message: Process 158582 (eddsa_test) of user 0 dumped core. Stack trace of thread 158582: #0 0x03ff896e50be OPENSSL_cleanse (libcrypto.so.1.1 + 0x1650be) ---uname output--- Linux system 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = Manufacturer: IBM Type: 8561 Model:703 T01 ---Debugger--- A debugger was configured, however the system did not enter into the debugger ---Steps to Reproduce--- 1.) install the github libica 3.6.1 package and build the test cases 2.) cd .../libica-3.6.1 3.) ./bootstrap.sh; configure --enable-coverage 4.) make coverage Watch the segmentation fault to happen Userspace tool common name: eddsa_test The userspace tool has the following bit modes: 64bit Userspace rpm: libica3 Userspace tool obtained from project website: na The problem could be reproduced with libica 3.6.1, however, it does not show up with libica 3.8.0. Looks like the problem was fixed by commit https://github.com/opencryptoki/libica/commit/b40d0d2ad4a2aac088cf47befbddd8b3b9fca1c5 After applying this fix on top of 3.6.1, the segfault does not occur anymore. It's sufficient to apply the 4 changes in eddsa_test.c. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929921/+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 1929923] Re: [UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic - rq_qos_wake_function
Is it possible to describe the steps required to reproduce this issue? And the environment in which it occurred? Thanks! ** Changed in: ubuntu-z-systems Importance: Undecided => Critical -- 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/1929923 Title: [UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic - rq_qos_wake_function Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- kernel panic rq_qos_wake_function ---uname output--- Linux version 5.4.0-71-generic Machine Type = s390x ---Debugger--- A debugger is not configured Stack trace output: May 15 20:21:04 data1 kernel: Call Trace: May 15 20:21:04 data1 kernel: ([<00234091e670>] 0x234091e670) May 15 20:21:04 data1 kernel: [<003e10047e3a>] rq_qos_wake_function+0x8a/0xa0 May 15 20:21:04 data1 kernel: [<003e0fbec482>] __wake_up_common+0xa2/0x1b0 May 15 20:21:04 data1 kernel: [<003e0fbec984>] __wake_up_common_lock+0x94/0xe0 May 15 20:21:04 data1 kernel: [<003e0fbec9fa>] __wake_up+0x2a/0x40 May 15 20:21:04 data1 kernel: [<003e1005ee70>] wbt_done+0x90/0xe0 May 15 20:21:04 data1 kernel: [<003e10047f42>] __rq_qos_done+0x42/0x60 May 15 20:21:04 data1 kernel: [<003e10033cb0>] blk_mq_free_request+0xe0/0x140 May 15 20:21:04 data1 kernel: [<003e101d46f0>] dm_softirq_done+0x140/0x230 May 15 20:21:04 data1 kernel: [<003e100326c0>] blk_done_softirq+0xc0/0xe0 May 15 20:21:04 data1 kernel: [<003e103fc084>] __do_softirq+0x104/0x360 May 15 20:21:04 data1 kernel: [<003e0fb9da1e>] irq_exit+0x9e/0xc0 May 15 20:21:04 data1 kernel: [<003e0fb28ae8>] do_IRQ+0x78/0xb0 May 15 20:21:04 data1 kernel: [<003e103fb588>] ext_int_handler+0x130/0x134 May 15 20:21:04 data1 kernel: [<003e101d4416>] dm_mq_queue_rq+0x36/0x1d0 May 15 20:21:04 data1 kernel: Last Breaking-Event-Address: May 15 20:21:04 data1 kernel: [<003e0fbce75e>] wake_up_process+0xe/0x20 May 15 20:21:04 data1 kernel: Kernel panic - not syncing: Fatal exception in interrupt Oops output: no System Dump Info: The system was configured to capture a dump, however a dump was not produced. -Attach sysctl -a output output to the bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929923/+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 1929923] Re: [UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic - rq_qos_wake_function
** Also affects: ubuntu-z-systems 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/1929923 Title: [UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic - rq_qos_wake_function Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- kernel panic rq_qos_wake_function ---uname output--- Linux version 5.4.0-71-generic Machine Type = s390x ---Debugger--- A debugger is not configured Stack trace output: May 15 20:21:04 data1 kernel: Call Trace: May 15 20:21:04 data1 kernel: ([<00234091e670>] 0x234091e670) May 15 20:21:04 data1 kernel: [<003e10047e3a>] rq_qos_wake_function+0x8a/0xa0 May 15 20:21:04 data1 kernel: [<003e0fbec482>] __wake_up_common+0xa2/0x1b0 May 15 20:21:04 data1 kernel: [<003e0fbec984>] __wake_up_common_lock+0x94/0xe0 May 15 20:21:04 data1 kernel: [<003e0fbec9fa>] __wake_up+0x2a/0x40 May 15 20:21:04 data1 kernel: [<003e1005ee70>] wbt_done+0x90/0xe0 May 15 20:21:04 data1 kernel: [<003e10047f42>] __rq_qos_done+0x42/0x60 May 15 20:21:04 data1 kernel: [<003e10033cb0>] blk_mq_free_request+0xe0/0x140 May 15 20:21:04 data1 kernel: [<003e101d46f0>] dm_softirq_done+0x140/0x230 May 15 20:21:04 data1 kernel: [<003e100326c0>] blk_done_softirq+0xc0/0xe0 May 15 20:21:04 data1 kernel: [<003e103fc084>] __do_softirq+0x104/0x360 May 15 20:21:04 data1 kernel: [<003e0fb9da1e>] irq_exit+0x9e/0xc0 May 15 20:21:04 data1 kernel: [<003e0fb28ae8>] do_IRQ+0x78/0xb0 May 15 20:21:04 data1 kernel: [<003e103fb588>] ext_int_handler+0x130/0x134 May 15 20:21:04 data1 kernel: [<003e101d4416>] dm_mq_queue_rq+0x36/0x1d0 May 15 20:21:04 data1 kernel: Last Breaking-Event-Address: May 15 20:21:04 data1 kernel: [<003e0fbce75e>] wake_up_process+0xe/0x20 May 15 20:21:04 data1 kernel: Kernel panic - not syncing: Fatal exception in interrupt Oops output: no System Dump Info: The system was configured to capture a dump, however a dump was not produced. -Attach sysctl -a output output to the bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929923/+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 1929825] Re: [Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified on the kernel cmdline for the installer
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Importance: Undecided => High
--
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/1929825
Title:
[Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified
on the kernel cmdline for the installer
Status in Ubuntu on IBM z Systems:
New
Status in linux package in Ubuntu:
New
Bug description:
The OSA Device doesn't get enabled if a vlan is specified on the
kernel cmdline for the installer.
with the cmdline
`ip=10.1.8.74::10.1.10.1:255.255.252.0::enc800.300:none nameserver=10.1.9.101
vlan=enc800.300:enc800
url=http://10.1.9.101:1002/iso/ubuntu-21.04-live-server-s390x.iso quiet ---`
the boot fails with this message and drops to a shell:
```
BusyBox v1.30.1 (Ubuntu 1:1.30.1-6ubuntu2) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) [6n
ip: SIOCGIFFLAGS: No such device
ip: can't find device 'enc800'
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
no search or nameservers found in /run/net-enc800.300.conf /run/net-*.conf
/run/
net6-*.conf
Connecting to 10.1.9.101:1002 (10.1.9.101:1002)
wget: can't connect to remote host (10.1.9.101): Network is unreachable
Unable to find a live file system on the network
```
It the zdev 800 doesn't get enabled.
```
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
(initramfs) [6n
lszdev | grep 0.0.0800
qeth 0.0.0800:0.0.0801:0.0.0802 no no
```
But I can enable it manually:
```
chzdev -e 800
QETH device 0.0.0800:0.0.0801:0.0.0802 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
- QETH device 0.0.0800:0.0.0801:0.0.0802
A manual update of the initial RAM-disk is required.
(initramfs) [6n
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enc800: mtu 1500 qdisc noop qlen 1000
link/ether f2:ae:7d:de:88:a0 brd ff:ff:ff:ff:ff:ff
```
The same cmdline (adjusted for the iso url) works on 20.04.
Between 20.04 and 21.04 the line 318 `echo "${VLAN}" | grep -q "${dev}" &&
continue` was added to /scripts/functions in the initrd.ubuntu. If I remove
this line and repack the ramdisk the network boot works as expected like on
ubuntu 20.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929825/+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 1929790] Re: Request to backport fix for endianness issue in TigerVNC vncviewer
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- 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/1929790 Title: Request to backport fix for endianness issue in TigerVNC vncviewer Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- TigerVNC 1.11.0 contains a regression that causes vncviewer to display incorrect colors when vncviewer and X11 server use different endianness (e.g., when using X11 forwarding via SSH between an x86-64 desktop and a Linux system on s390x). The regression was originally reported in github issue https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull request https://github.com/TigerVNC/tigervnc/pull/1084 The regression caused vncviewer to always use the system byte order for pixel values instead of the byte order required by the X11 display. With the fix, vncviewer queries the X11 display for the required byte order. As of now, the fix has not made it into a release yet. Please consider backporting the fix (upstream commit 7ab92639848). I confirmed that this commit cleanly applies on top of release 1.11.0 and fixes the regression. ---uname output--- Linux s390x Machine Type = x15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- See also https://github.com/TigerVNC/tigervnc/issues/1252 - From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding - Start a Xvnc session on that Linux system tigervncserver :0 -geometry 800x600 -depth 32 - Start vncviewer on the same Linux system xtigervncviewer :0 - On vncviewer's window on your origin X session, observe incorrect colors. - Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious - Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare Userspace tool common name: vncviewer The userspace tool has the following bit modes: 64-bit Userspace rpm: tigervnc-viewer Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929790/+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 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP50s3832 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition enP50s3832 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP53p0s0 is not for us
[Kernel-packages] [Bug 1857073] Re: Cavium ThunderX CN88XX Oops at smi_send.isra.4+0x80/0x158 [ipmi_msghandler]
I understand that there are no further f/w updates planned for these ThunderX boards. Marking as "won't fix". ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Bionic) Status: Confirmed => Invalid -- 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/1857073 Title: Cavium ThunderX CN88XX Oops at smi_send.isra.4+0x80/0x158 [ipmi_msghandler] Status in linux package in Ubuntu: Invalid Status in linux source package in Bionic: Invalid Bug description: Series: Bionic Kernel: 4.15.0-74.84 linux-generic The following crash was observed while testing the proposed kernel for the 2019.12.02 SRU Cycle. This kernel was built to include fixes for the following bugs: * [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX (LP: #1853326) - Revert "arm64: Use firmware to detect CPUs that are not affected by Spectre-v2" - Revert "arm64: Get rid of __smccc_workaround_1_hvc_*" * [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX2 and Kunpeng920 (LP: #1852723) - SAUCE: arm64: capabilities: Move setup_boot_cpu_capabilities() call to correct place The following crash appears to be a NEW bug. not related to the prior bugs listed above. system hostname: wright Possible Cause: wright's crash possibly is caused by faulty error handling in the ipmi driver (notice this in its dmesg: [ 52.150201] ipmi_ssif 0-0012: Unable to get the device id: -5) [ OK ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. [ OK ] FounBYZ-011FA0 efi. Mounting /boot/[ OK ] Mounted /boot/efi. [ OK ] Reached target Local File Systems. Starting Set console font and keymap... Starting Create Volatile Files and Directories... Starting ebtables ruleset management... Starting AppArmor initialization... Starting Tell Plymouth To Write Out Runtime Data... [ OK nsole font and keymap. [ OK ] Started Tell Plymouth To Write Out Runtime Data. [ OK ] Started Create Volatile Files and Directories. Starting Network Time Synchronization... Starting Update UTMP about Syst [ OK ] Started Update UTMP utdown. [ OK ] Started ebtables ruleset management. [ OK ] Starnization. [ OK ] Reached target System Time Synchronized. [ OK ] Started AppArmor initialization. [ 50.689136] cloud-init[1246]: Cloud-init v. 19.3-41-gc4735dd3-0ubuntu1~18.04.1 running 'init-local' at Thu, 19 Dec 20 50.28 seconds. [ 50.712486] cloud-init[1246]: 2019-12-19 22:40:37,893 - handlers.py[WARNING]: failed posting event: start: init-local/check-cache: attempting to read from cache [trust] [ 50.736307] cloud-init[1246]: 2019-12-19 22:40:37,941 - handlers.py[WARNING]: failed posting event: finish: init-local/check-cache: SUCCESS: restored from cache: DataSourceMAAS [http://10.229.32.21:5248/MAAS/metadata/] [ 51.244224] cloud-init[1246]: 2019-12-19 22:40:38,450 - handlers.py[WARNING]: failed posting event: finish: init-local: SUCCESS: searching for local datasources [ OK ] Started Initial cloud-init job (pre-networking). [ OK ] Reached target Network (Pre). Starting Network Service... [ OK ] Started Network Service. Starting Wait for Network to be Configured... Starting Network Name Resolution... [ 52.150201] ipmi_ssif 0-0012: Unable to get the device id: -5 [ 52.300309] Unable to handle kernel read fromvirtual address 0018 [ 52.311284] Mem abort info: [ 52.316895] 604 [ 52.322622] Exception class = DABT (current EL), IL = 32 bits [ 52.331061] SET = 0, FnV = 0 [ 52.336639] EA = 0, S1PTW = 0 [ 52.342311] Data abort info: [ 52.347731] ISV = 0, ISS = 0x0004 [ 52.354131] CM = 0, WnR = 0 [ 52.359739] user pgtable: 4k pages, 48-bit VAs, pgd = 44052f71 [ 52.368909] [0018] *pgd= [ 52.376522] Internal error: Oops: 9604 [#1] SMP [ 52.384039] Modules linked in: nls_iso8859_1 thunderx_edac thunderx_zip cavium_rng_vf shpchp cavium_rng gpio_keys uio_pdrv_genirq uio ipmi_ssif(+) ipmi_devintf ipmi_msghandler sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear nicvf nicpf ast i2c_algo_bit aes_ce_blk ttm aes_ce_cipher crc32_ce drm_kms_helper crct10dif_ce ghash_ce syscopyarea sha2_ce sysfillrect sysimgblt sha256_arm64 fb_sys_fops thunder_bgx sha1_ce drm ahci libahci thunder_xcv i2c_thunderx mdio_thunder thunderx_mmc mdio_cavium aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 52.473094]
[Kernel-packages] [Bug 1911376] Re: [ssbs-0118] backport SSBS bug (arm64: cpufeature: Detect SSBS and advertise to userspace)
** Changed in: kunpeng920/ubuntu-18.04
Status: Fix Committed => Fix Released
** Changed in: kunpeng920
Status: Fix Committed => Fix Released
--
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/1911376
Title:
[ssbs-0118] backport SSBS bug (arm64: cpufeature: Detect SSBS and
advertise to userspace)
Status in kunpeng920:
Fix Released
Status in kunpeng920 ubuntu-18.04 series:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Bionic:
Fix Released
Bug description:
[Impact]
The SSBS patch in 4.14 stable kernel, and mainline kernel adds snippet
into arm64_cpufeatures but in bionic kernel, it is landed into
arm64_elf_hwcaps.
[Fix]
Move SSBS snippet from arm64_elf_hwcaps back to arm64_features
[Test]
No known tool for SSB attack. Regression test only.
[Regression Potential]
Regression might be on all arm64 platforms. Regression test on all arm64
platform we have is recommended.
=
[Bug Description]
ubuntu 18.04.1 fail to enable this SSBS function, this sys log will call
trace as follow:
[0.662089] Call trace:
[0.662870] setup_elf_hwcaps+0xb8/0xd4
[0.664023] setup_cpu_features+0x60/0xf8
[0.665216] smp_cpus_done+0x34/0xa8
[0.666547] smp_init+0x120/0x138
[0.667555] kernel_init_freeable+0xf4/0x260
[0.668860] kernel_init+0x18/0x110
[0.670025] ret_from_fork+0x10/0x18
[Steps to Reproduce]
1) boot this system
2) uname -a
Ubuntu 4.15.0-99.100-generic 4.15.18
[Actual Results]
boot error:
[0.662089] Call trace:
[0.662870] setup_elf_hwcaps+0xb8/0xd4
[0.664023] setup_cpu_features+0x60/0xf8
[0.665216] smp_cpus_done+0x34/0xa8
[0.666547] smp_init+0x120/0x138
[0.667555] kernel_init_freeable+0xf4/0x260
[0.668860] kernel_init+0x18/0x110
[0.670025] ret_from_fork+0x10/0x18
[Expected Results]
no error
[Reproducibility]
NA
[Additional information]
(Firmware version, kernel version, affected hardware, etc. if required):
arm64: cpufeature: Detect SSBS and advertise to userspace
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71be2b6c0e19180b5f80a6d42039cc074a693a2
backport this following code into "static const struct
arm64_cpu_capabilities arm64_elf_hwcaps[]" which will be error.
1274 #ifdef CONFIG_ARM64_SSBD
1275 {
1276 .desc = "Speculative Store Bypassing Safe (SSBS)",
1277 .capability = ARM64_SSBS,
1278 .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
1279 .matches = has_cpuid_feature,
1280 .sys_reg = SYS_ID_AA64PFR1_EL1,
1281 .field_pos = ID_AA64PFR1_SSBS_SHIFT,
1282 .sign = FTR_UNSIGNED,
1283 .min_field_value = ID_AA64PFR1_SSBS_PSTATE_ONLY,
1284 .cpu_enable = cpu_enable_ssbs,
1285 },
[Resolution]
Can you backport aboving code into "static const struct
arm64_cpu_capabilities arm64_features[] = {"?
To manage notifications about this bug go to:
https://bugs.launchpad.net/kunpeng920/+bug/1911376/+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 1904906] Re: 5.10 kernel fails to boot with secure boot disabled
Waiting to close as "Fix Released" once the 5.10 kernel has landed in hirsute. 5.10 kernel is currently in hirsute -proposed. -- 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/1904906 Title: 5.10 kernel fails to boot with secure boot disabled Status in The Ubuntu-power-systems project: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Canonical requests to test the secure boot for the 5.10 kernel but kernel fails to boot with secure boot disabled. The 5.10 kernel can be found in: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap They can be installed by installing the linux-generic-wip package with this PPA enabled. As usual, they are only signed using a key specific to that PPA. This key can be retrieved from the signing tarballs for the kernels, e.g.: http://ppa.launchpad.net/canonical-kernel- team/bootstrap/ubuntu/dists/hirsute/main/signed/linux-5.10-ppc64el/5.10.0-2.3/signed.tar.gz Our tester installed the 5.10 kernel via aptitude. If booting directly from the bootmenu, it stucks at: "kexec_core: Starting new kernel" If booting recovery kernel for 5.10.0, it proceeds farther and after kexec_core, it failed at: " [0.029830] LSM: Security Framework initializing [0.029916] Yama: b " Two attempts with a different scenario; running with 5.8 kernel and boot via commandline for 5.10: kexec -l /boot/vmlinux-5.10.0-0-generic --initrd=/boot/initrd.img-5.10.0-0-generic --append="root=UUID=49d000cb-dba2-4d70-809e-38f2b31d0f09 ro quiet splash" kexec -e Both attempts also failed while rebooting, once with the same error as the error from booting with bootmenu; the other failure occurred a lot earlier. Wondering what new CONFIGs and/or features for the 5.10 kernel? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1904906/+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 1869763] Re: Huawei Kunpeng 920 arm64 machine KVM guest frequently crash
** Changed in: kunpeng920 Status: New => Incomplete -- 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/1869763 Title: Huawei Kunpeng 920 arm64 machine KVM guest frequently crash Status in kunpeng920: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: Hardware spec: 64 core 64 G ram arm64 OS & kernel version: Ubuntu 18.04.4 LTS, 4.15.0-91-generic `virt-host-validate qemu` output: QEMU: Checking if device /dev/kvm exists : PASS QEMU: Checking if device /dev/kvm is accessible : PASS QEMU: Checking if device /dev/vhost-net exists : PASS QEMU: Checking if device /dev/net/tun exists : PASS QEMU: Checking for cgroup 'memory' controller support : PASS QEMU: Checking for cgroup 'memory' controller mount-point : PASS QEMU: Checking for cgroup 'cpu' controller support : PASS QEMU: Checking for cgroup 'cpu' controller mount-point : PASS QEMU: Checking for cgroup 'cpuacct' controller support : PASS QEMU: Checking for cgroup 'cpuacct' controller mount-point : PASS QEMU: Checking for cgroup 'cpuset' controller support : PASS QEMU: Checking for cgroup 'cpuset' controller mount-point : PASS QEMU: Checking for cgroup 'devices' controller support : PASS QEMU: Checking for cgroup 'devices' controller mount-point : PASS QEMU: Checking for cgroup 'blkio' controller support : PASS QEMU: Checking for cgroup 'blkio' controller mount-point : PASS WARN (Unknown if this platform has IOMMU support) libvirt version: 4.0.0-1ubuntu8.14 qemu version: 1:2.11+dfsg-1ubuntu7.23arm64 guest vm kernel version: 4.15.0-64-generic aarch64 dmesg log: kvm [49132]: Unexpected L2 read permission error libvirt log: ubuntu libvirtd: 2020-03-20 03:04.474+: 42934: warning : qemuDomainObjTaint:5602 : Domain id=38 name='vm-157' uuid=3d447d79-c2a1-4351-b607-6698a2cd6c5f is tainted: host-cpu When "Unexpected L2 read permission error" this error occured, one of guest machines will become "paused" state, need to `virsh reset PAUSED_VM_NAME` to reset then start it. Those guest vm hang/crash occured very frequently, sometimes several times per hour. To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1869763/+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 1867591] Re: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/upstream-kernel Milestone: None => linux-v5.8 ** Changed in: kunpeng920/upstream-kernel Status: Incomplete => Fix Released ** Changed in: kunpeng920/ubuntu-20.04-hwe 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/1867591 Title: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch Status in kunpeng920: Incomplete Status in kunpeng920 ubuntu-18.04-hwe series: Incomplete Status in kunpeng920 ubuntu-20.04 series: Incomplete Status in kunpeng920 ubuntu-20.04-hwe series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: In Progress Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver crypto: hisilicon/sec2 - Update IV and MAC operation crypto: hisilicon/sec2 - Add iommu status check crypto: hisilicon/sec2 - Add workqueue for SEC driver. crypto: hisilicon - Use one workqueue per qm instead of per qp crypto: hisilicon - qm depends on UACCE crypto: hisilicon - remove redundant assignment of pointer ctx hisilicon - register zip engine to uacce hisilicon - Remove module_param uacce_mode uacce: add uacce driver uacce: Add documents for uacce crypto: hisilicon - Fix duplicate print when qm occur multiple errors crypto: hisilicon - Unify error detect process into qm crypto: hisilicon - Configure zip RAS error type crypto: hisilicon - Unify hardware error init/uninit into QM To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867591/+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 1904906] Re: 5.10 kernel fails to boot with secure boot disabled
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) -- 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/1904906 Title: 5.10 kernel fails to boot with secure boot disabled Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: Canonical requests to test the secure boot for the 5.10 kernel but kernel fails to boot with secure boot disabled. The 5.10 kernel can be found in: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap They can be installed by installing the linux-generic-wip package with this PPA enabled. As usual, they are only signed using a key specific to that PPA. This key can be retrieved from the signing tarballs for the kernels, e.g.: http://ppa.launchpad.net/canonical-kernel- team/bootstrap/ubuntu/dists/hirsute/main/signed/linux-5.10-ppc64el/5.10.0-2.3/signed.tar.gz Our tester installed the 5.10 kernel via aptitude. If booting directly from the bootmenu, it stucks at: "kexec_core: Starting new kernel" If booting recovery kernel for 5.10.0, it proceeds farther and after kexec_core, it failed at: " [0.029830] LSM: Security Framework initializing [0.029916] Yama: b " Two attempts with a different scenario; running with 5.8 kernel and boot via commandline for 5.10: kexec -l /boot/vmlinux-5.10.0-0-generic --initrd=/boot/initrd.img-5.10.0-0-generic --append="root=UUID=49d000cb-dba2-4d70-809e-38f2b31d0f09 ro quiet splash" kexec -e Both attempts also failed while rebooting, once with the same error as the error from booting with bootmenu; the other failure occurred a lot earlier. Wondering what new CONFIGs and/or features for the 5.10 kernel? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1904906/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
To confirm, this bug only requires that commit 61f879d97ce4
("powerpc/pseries: Detect secure and trusted boot state of the system.")
lands in hirsute. Is that correct, or are other patches also required?
** Changed in: ubuntu-power-systems
Status: Confirmed => Incomplete
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
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/1903288
Title:
Power guest secure boot with static keys: kernel portion
Status in The Ubuntu-power-systems project:
Incomplete
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #2 - Daniel John Axtens - 2020-11-05
20:15:10 ==
This is the kernel side of changes needed for LPAR/guest secure boot.
Because Ubuntu keeps its kernels so wonderfully up to date, I don't
think there are any extra patches you need to pick up. (I'll double-
check against the 21.04 tree once my git pulls finish!)
However, we potentially need some configuration changes to make sure
kexec-ing into a crashdump kernel still works.
Because Lockdown requires that kexec kernels are signed by a key
trusted by IMA, the public key for used for signing the kdump kernel
needs to be in the IMA keyring or the platform keyring. For host
secure boot (and in the UEFI case), it's loaded into the platform
keyring. But in the case of guest secure boot with static keys, it's
not loaded into the platform keyring so it needs to be loaded into the
IMA keyring.
This is easy enough to do. Firstly, load the Secure Boot CA into the
.primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS
property. We assume the key used to sign the kernel is signed by this
CA.
Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the
.primary_trusted_keys keyring to be loaded into the IMA keyring. Then set
IMA_X509_PATH to provide a path to the signing key on installed file system.
(It may also be possible to do this step in userspace, so long as the CA is
trusted by the kernel.)
Then that key will be loaded into the .ima keyring at boot and be used to
appraise the kexec kernel for crashdumps.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1893711] Re: [hns3-0901]add hns3_gro_complete for HW GRO process
** Changed in: kunpeng920/ubuntu-18.04 Status: In Progress => Fix Committed ** Changed in: kunpeng920 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/1893711 Title: [hns3-0901]add hns3_gro_complete for HW GRO process Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] kernel oops on hns3 driver when GRO is enabled. [Fix] Cherry-pick patches from upstream d474d88f8826 net: hns3: add hns3_gro_complete for HW GRO process a4d2cdcbb878 net: hns3: minor refactor for hns3_rx_checksum [Test] No known way to reproduce it in our lab. Regression test only. [Regression Potential] Patchset only affects hns3 driver. Minimal risk for other drivers and platform. Stress test on hns3 driver looks good and we also have positive feedback from different lab. Patches also in Ubuntu kernel since Eoan and no regression observed. [Bug Description] When a GRO packet is received by driver, the cwr field in the struct tcphdr needs to be checked to decide whether to set the SKB_GSO_TCP_ECN for skb_shinfo(skb)->gso_type. [Steps to Reproduce] 1.load PF driver 2.turn off GRO of stack, turn on HW GRO [Actual Results] [ 32.597752] bond-dcn: link status definitely up for interface enp189s0f0, 1 Mbps full duplex [1048422.589438] Unable to handle kernel paging request at virtual address 80605d0c [1048422.597506] Mem abort info: [1048422.600463] ESR = 0x9605 [1048422.603679] Exception class = DABT (current EL), IL = 32 bits [1048422.609747] SET = 0, FnV = 0 [1048422.612963] EA = 0, S1PTW = 0 [1048422.616265] Data abort info: [1048422.619309] ISV = 0, ISS = 0x0005 [1048422.623301] CM = 0, WnR = 0 [1048422.626431] swapper pgtable: 4k pages, 48-bit VAs, pgd = 96615bf4 [1048422.633360] [80605d0c] *pgd=205f6003, *pud= [1048422.640465] Internal error: Oops: 9605 [#1] SMP [1048422.645496] Modules linked in: bonding zfs(PO) zunicode(PO) zavl(PO) icp(PO) nls_iso8859_1 zcommon(PO) znvpair(PO) spl(O) joydev input_leds ipmi_ssif ipmi_si ipmi_devintf shpchp ipmi_msghandler cppc_cpufreq sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 xfs btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ses enclosure hibmc_drm aes_ce_blk aes_ce_cipher ttm realtek crc32_ce drm_kms_helper crct10dif_ce syscopyarea ghash_ce hisi_sas_v3_hw sysfillrect sha2_ce sysimgblt hns3 nvme hisi_sas_main sha256_arm64 fb_sys_fops sha1_ce drm hclge libsas nvme_core ahci megaraid_sas hnae3 scsi_transport_sas libahci gpio_dwapb hid_generic [1048422.715911] usbhid hid aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [1048422.723192] Process swapper/22 (pid: 0, stack limit = 0xdc9798e5) [1048422.730122] CPU: 22 PID: 0 Comm: swapper/22 Tainted: P O 4.15.0-96-generic #97-Ubuntu [1048422.739297] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 1.35 04/30/2020 [1048422.747695] pstate: 8049 (Nzcv daif +PAN -UAO) [1048422.752641] pc : tcp_gro_complete+0x4c/0x80 [1048422.756988] lr : hns3_clean_rx_ring+0x63c/0x6f0 [hns3] [1048422.762274] sp : 09893d00 [1048422.765746] x29: 09893d00 x28: a05de384d900 [1048422.771207] x27: a05dc660c6c0 x26: a05dc7a6c280 [1048422.776668] x25: 0040 x24: a05dc7a4e000 [1048422.782130] x23: 0002 x22: [1048422.787590] x21: x20: [1048422.793051] x19: a05de384d900 x18: a3bf2a70 [1048422.798512] x17: a3b68698 x16: 08307aa0 [1048422.803973] x15: 0d920112ac4e x14: 0c96b6405c2a0a08 [1048422.809435] x13: 01011cc0f601 x12: 188058b201fc85fd [1048422.814896] x11: cd979f72c04ce5db x10: 2087e1db2087679d [1048422.820358] x9 : 0640004090cff807 x8 : 00450008f034d971 [1048422.825820] x7 : 1502726647903506 x6 : 0002 [1048422.831281] x5 : a05dc7ad0480 x4 : 0002 [1048422.836743] x3 : 805f5d00 x2 : 0060 [1048422.842203] x1 : 805f5f00 x0 : 80605cff [1048422.847665] Call trace: [1048422.850276] tcp_gro_complete+0x4c/0x80 [1048422.854274] hns3_clean_rx_ring+0x63c/0x6f0 [hns3] [1048422.859217]
[Kernel-packages] [Bug 1892546] Re: Novalink (mkvterm command failure)
Updated tags to mark focal as verification-done. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1892546 Title: Novalink (mkvterm command failure) Status in The Ubuntu-power-systems project: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: In Progress Bug description: SRU Justification: [Impact] * drmgr command is failing while trying to open console for IBMi on PowerVM LPAR [Fix] * 63ffcbdad738 "tty: hvcs: Don't NULL tty->driver_data until hvcs_cleanup()" [Test Case] * Create a VM from PowerVC on a Novalink managed host. * Unmanage and manage the VM, this problem gets reproduced. * grep the logs for "drmgr" [Regression Potential] The regression can be considered as very low, since: * limited to the IBM Hypervisor Virtual Console Server. * patched kernel where shared and successfully tested by IBM. * the worse case, if the cleanup is broken a new opened connection might break. [Other] * The patch got upstream accepted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1892546/+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 1893897] Re: [Regression] Do not initiate shutdown for EPOW_SHUTDOWN_ON_UPS event
** Changed in: ubuntu-power-systems Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => Patricia Domingues (patriciasd) ** Changed in: ubuntu-power-systems Status: New => In Progress -- 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/1893897 Title: [Regression] Do not initiate shutdown for EPOW_SHUTDOWN_ON_UPS event Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: New Status in linux source package in Bionic: New Status in linux source package in Focal: New Status in linux source package in Groovy: Fix Released Bug description: == Comment: #0 - VASANT HEGDE - 2020-09-02 01:00:25 == --Problem Description--- Do not initiate shutdown for EPOW_SHUTDOWN_ON_UPS event. Instead wait for predefined time before initiating shtudown. Contact Information = Vasant hegde Date: Thu Aug 20 11:48:44 2020 +0530 powerpc/pseries: Do not initiate shutdown when system is running on UPS Note that I have requested this fix for upstream v4.4 stable tree. This will hit stable tree soon. This is impacting all kernel after v4.0. This is critical fix. Hence I'd like to request to backport to Ubuntu 16.04 LTS release. -Vasant To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1893897/+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 1859756] Re: [hns3-0115] add 8 BD limit for tx flow
** Changed in: kunpeng920/ubuntu-18.04 Status: Fix Committed => Fix Released ** Changed in: kunpeng920 Status: Fix Committed => Fix Released -- 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/1859756 Title: [hns3-0115] add 8 BD limit for tx flow Status in kunpeng920: Fix Released Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] We get reports that iscsi and spark tests fail on hns3 [Fix] Cherry-pick/backport patches from upstream. net: hns3: add 8 BD limit for tx flow net: hns3: avoid mult + div op in critical data path net: hns3: remove some ops in struct hns3_nic_ops net: hns3: fix for not calculating tx bd num correctly net: hns3: unify maybe_stop_tx for TSO and non-TSO case net: hns3: add check for max TX BD num for tso and non-tso case net: hns3: fix for TX queue not restarted problem net: hns3: fix a use after free problem in hns3_nic_maybe_stop_tx() [Test] No known way to reproduce it in our lab. Regression test only. [Regression Potential] Patchset only affects hns3 driver. Minimal risk for other drivers and platform. [Bug Description] A single transmit packet can span up to 8 descriptors, TSO transmit packet can be stored up to 63 descriptors and each segment within the TSO should be spanned up to 8 descriptors. If the packet needs more than 8 BD, and the total size of every 7 continuous frags more than MSS, HW does not support it, and it need driver makes SKB Linearized. [Actual Results] iscsi and bigdata spark test OK [Expected Results] iscsi and bigdata spark test OK [Reproducibility] Inevitably [Additional information] Hardware: D06 Firmware: NA Kernel: NA DTS2018091810050 [Resolution] SW use skb_copy to merge frag; 51e8439f3496 net: hns3: add 8 BD limit for tx flow 5f543a54eec0 net: hns3: fix for not calculating tx bd num correctly To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1859756/+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 1892546] Re: Novalink (mkvterm command failure)
Moving to "Incomplete" while waiting for the test results from the test kernel referenced in comment #5. ** Changed in: ubuntu-power-systems Status: In Progress => Incomplete ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1892546 Title: Novalink (mkvterm command failure) Status in The Ubuntu-power-systems project: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: -- Problem Description -- drmgr command is failing while trying to open console for IBMi. Log snap shot: Please make sure you have specified a valid locale (check your NLSPATH and LANG environment variables. Your application will use english as the default. 2 07/15/20 16:01:25.393.531 UTC DEBUG pvmutil[12687.70366696995648]: (common/util/HmclDrmgrHelper.cpp:1036) Command /usr/sbin/pvmdrmgr drmgr -c slot -s 'U9080.MHE.218BA37-V1-C8' -r -w 3 returned 255. Additional messages: /usr/sbin/pvmdrmgr drmgr -c slot -s 'U9080.MHE.218BA37-V1-C8' -r -w 3 Validating I/O DLPAR capability...yes. failed to open /sys/bus/pci/slots/U9080.MHE.218BA37-V1-C8/power: No such file or directory failed to disable hotplug children Isolation failed for 3008 with -9001 Valid outstanding translations exist. ---Steps to Reproduce--- Create a VM from PowerVC on a Novalink managed host. Unmanage and manage the VM, this problem gets reproduced == I've tested a proposed fix and it does fix both the -9001 isolation errors after DLPAR remove and vterm state is still open, as well as the /dev/hcvsX index changing after a DLPAR remove/add. I will get that patch sent out to the upstream mailing list for merging. Patch submitted upstream: https://lore.kernel.org/linuxppc- dev/20200820234643.70412-1-tyr...@linux.ibm.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1892546/+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 1892546] Re: Novalink (mkvterm command failure)
Is this issue associated with the Xenial GA (4.4) kernel or the Xenial HWE (4.15) kernel? ** Changed in: ubuntu-power-systems Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => Patricia Domingues (patriciasd) ** Changed in: ubuntu-power-systems Status: Triaged => In Progress -- 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/1892546 Title: Novalink (mkvterm command failure) Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: New Bug description: -- Problem Description -- drmgr command is failing while trying to open console for IBMi. Log snap shot: Please make sure you have specified a valid locale (check your NLSPATH and LANG environment variables. Your application will use english as the default. 2 07/15/20 16:01:25.393.531 UTC DEBUG pvmutil[12687.70366696995648]: (common/util/HmclDrmgrHelper.cpp:1036) Command /usr/sbin/pvmdrmgr drmgr -c slot -s 'U9080.MHE.218BA37-V1-C8' -r -w 3 returned 255. Additional messages: /usr/sbin/pvmdrmgr drmgr -c slot -s 'U9080.MHE.218BA37-V1-C8' -r -w 3 Validating I/O DLPAR capability...yes. failed to open /sys/bus/pci/slots/U9080.MHE.218BA37-V1-C8/power: No such file or directory failed to disable hotplug children Isolation failed for 3008 with -9001 Valid outstanding translations exist. ---Steps to Reproduce--- Create a VM from PowerVC on a Novalink managed host. Unmanage and manage the VM, this problem gets reproduced == I've tested a proposed fix and it does fix both the -9001 isolation errors after DLPAR remove and vterm state is still open, as well as the /dev/hcvsX index changing after a DLPAR remove/add. I will get that patch sent out to the upstream mailing list for merging. Patch submitted upstream: https://lore.kernel.org/linuxppc- dev/20200820234643.70412-1-tyr...@linux.ibm.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1892546/+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 1892849] Re: [UBUNTU 20.04] zPCI attach/detach issues with PF/VF linking support
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- 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/1892849 Title: [UBUNTU 20.04] zPCI attach/detach issues with PF/VF linking support Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: Problem description: When a NVMe drive is assigned/hotplugged to a Linux LPAR then a bug is hit in lib/list_debug.c. And the device is not accessible, there is no /dev/ file and lspci does not report it also. [ 1681.564462] list_add double add: new=eed0f808, prev=eed0f808, next=4070a300. [ 1681.564489] [ cut here ] [ 1681.564490] kernel BUG at lib/list_debug.c:31! [ 1681.564504] monitor event: 0040 ilc:2 [#1] SMP [ 1681.564507] Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter s390_trng ghash_s390 prng aes_s390 des_s390 libdes sha512_s390 vfio_ccw sha1_s390 vfio_mdev mdev chsc_sch vfio_iommu_type1 eadm_sch vfio ip_tables dm_service_time nvme crc32_vx_s390 sha256_s390 sha_common nvme_core qeth_l2 zfcp qeth scsi_transport_fc qdio ccwgroup dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt [ 1681.564534] CPU: 6 PID: 139 Comm: kmcheck Not tainted 5.8.0-rc1+ #2 [ 1681.564535] Hardware name: IBM 8561 T01 701 (LPAR) [ 1681.564536] Krnl PSW : 0704c0018000 3ffcadb8 (__list_add_valid+0x70/0xa8) [ 1681.564544]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 1681.564545] Krnl GPRS: 0040 0027 0058 0007 [ 1681.564546]3ffcadb4 03e0051a7ce0 [ 1681.564547]4070a300 eed0f808 eed0f808 4070a300 [ 1681.564548]f56a2000 40c2c788 3ffcadb4 03e0051a7bc8 [ 1681.564583] Krnl Code: 3ffcada8: c02000302b09larl %r2,405d03ba 3ffcadae: c0e5ffdd30b1brasl %r14,3fb70f10 #3ffcadb4: af00mc 0,0 >3ffcadb8: b9040054lgr %r5,%r4 3ffcadbc: c02000302aadlarl %r2,405d0316 3ffcadc2: b9040041lgr %r4,%r1 3ffcadc6: c0e5ffdd30a5brasl %r14,3fb70f10 3ffcadcc: af00mc 0,0 [ 1681.564592] Call Trace: [ 1681.564594] [<3ffcadb8>] __list_add_valid+0x70/0xa8 [ 1681.564596] ([<3ffcadb4>] __list_add_valid+0x6c/0xa8) [ 1681.564599] [<3faf2920>] zpci_create_device+0x60/0x1b0 [ 1681.564601] [<3faf704a>] zpci_event_availability+0x282/0x2f0 [ 1681.564605] [<40367848>] chsc_process_crw+0x2b8/0xa18 [ 1681.564607] [<4036f35c>] crw_collect_info+0x254/0x348 [ 1681.564610] [<3fb2a6ea>] kthread+0x14a/0x168 [ 1681.564613] [<403a55c0>] ret_from_fork+0x24/0x2c [ 1681.564614] Last Breaking-Event-Address: [ 1681.564618] [<3fb70f62>] printk+0x52/0x58 [ 1681.564620] ---[ end trace 7ea67c348aa67e14 ]--- uname: Linux t83lp49.lnxne.boe 5.8.0-rc1+ #2 SMP Thu Jun 18 12:38:02 CEST 2020 s390x s390x s390x GNU/Linux How to reproduce: 1. Unassign a NVMe drive in HMC from your LPAR 2. Reassign it to your LPAR again 3. dmesg == Solution The issue with VF attach/detach is with the fact that on IBM Z VFs can be enabled/disabled individually using echo 0 > /sys/bus/pci/slots//power If this was done with a VF linked to a parent PF the symlink in the parent (/sys/bus/pci/devices//virtfnX) would become stale while the VF is disabled and when turned back on the VF would not get linked to the PF again and so could not be used e.g. with QEMU which relies on the links. Similarly stale virtfn links could remain after removing VFs through. echo 0 > /sys/bus/pci/devices//sriov_numvfs Furthermore there was a missing pci_dev_put() when searching for the parent PF potentially resulting in a too high reference count of the parent PFs. This has been fixed upstream and in 5.8 stable with the following 3 upstream commits: 3cddb79afc60bcdb5fd9dd7a1c64a8d03bdd460f s390/pci: fix
[Kernel-packages] [Bug 1892347] Re: HiSilicon HNS3 ethernet broken
** Also affects: kunpeng920 Importance: Undecided Status: New ** Changed in: kunpeng920 Status: New => Incomplete -- 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/1892347 Title: HiSilicon HNS3 ethernet broken Status in kunpeng920: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: [Impact] The TM210 (verified) and TM280 (probably) driver hns3 is broken in Ubuntu 18.04.5 LTS kernel 4.15.0-112-generic. Server Huawei TM200-2280 with Kunpeng920 SOCs. Huawei provides binary distributed driver NIC-hisi_eth-Ubuntu18.04.1-hns3-1.0.2-aarch64.deb but it is only for kernel 4.15.0-29-generic. root@n012:~# uname -ar Linux n012 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:42:54 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux root@n012:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.5 LTS Release: 18.04 Codename: bionic root@n012:~# dmesg |grep hns3 [3.775711] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version [3.789796] hns3: Copyright (c) 2017 Huawei Corporation. [4.295868] hns3 :7d:00.0: The firmware version is 01092806 [4.395325] hns3 :7d:00.0 eth0: No phy led trigger registered for speed(-1) [4.498584] hns3 :7d:00.1: The firmware version is 01092806 [4.634770] hns3 :7d:00.1 eth1: No phy led trigger registered for speed(-1) [4.671546] hns3 :7d:00.2: The firmware version is 01092806 [4.791311] hns3 :7d:00.2 eth2: No phy led trigger registered for speed(-1) [4.813538] hns3 :7d:00.3: The firmware version is 01092806 [4.915305] hns3 :7d:00.3 eth3: No phy led trigger registered for speed(-1) [4.937256] hns3 :bd:00.0: The firmware version is 01092806 [4.994060] hns3 :bd:00.1: The firmware version is 01092806 [5.049951] hns3 :bd:00.2: The firmware version is 01092806 [5.107165] hns3 :bd:00.3: The firmware version is 01092806 [5.159285] hns3 :7d:00.0 enp125s0f0: renamed from eth0 [5.379348] hns3 :bd:00.2 enp189s0f2: renamed from eth6 [5.435880] hns3 :bd:00.1 enp189s0f1: renamed from eth5 [5.903915] hns3 :7d:00.3 enp125s0f3: renamed from eth3 [5.999350] hns3 :7d:00.1 enp125s0f1: renamed from eth1 [6.155353] hns3 :7d:00.2 enp125s0f2: renamed from eth2 [6.295332] hns3 :bd:00.0 enp189s0f0: renamed from eth4 [6.443835] hns3 :bd:00.3 enp189s0f3: renamed from eth7 [ 18.031167] hns3 :7d:00.0 enp125s0f0: link up [77661.965968] beegfs: enabling unsafe global rkey [7.642438] hns3 :7d:00.0: PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found [error status=0x1] [7.642466] hns3 :7d:00.0: PF Reset requested [7.642491] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.650298] hns3 :7d:00.0: inform reset to vf(1) failed -5! [7.650315] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.654571] hns3 :7d:00.0: inform reset to vf(2) failed -5! [7.654588] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.658807] hns3 :7d:00.0: inform reset to vf(3) failed -5! [7.689650] hns3 :7d:00.0 enp125s0f0: link down [7.797516] hns3 :7d:00.0: prepare wait ok [7.908488] hns3 :7d:00.0: The firmware version is 01092806 [7.915807] hns3 :7d:00.0: Reset done, hclge driver initialization finished. [7.945923] hns3 :7d:00.0: PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found [error status=0x1] [7.945976] hns3 :7d:00.0: PF Reset requested [7.946065] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.950200] hns3 :7d:00.0: inform reset to vf(1) failed -5! [7.950218] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.954274] hns3 :7d:00.0: inform reset to vf(2) failed -5! [7.954292] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [7.958067] hns3 :7d:00.0: inform reset to vf(3) failed -5! [8.093493] hns3 :7d:00.0: prepare wait ok [8.203854] hns3 :7d:00.0: The firmware version is 01092806 [8.210947] hns3 :7d:00.0: Reset done, hclge driver initialization finished. [80001.269514] hns3 :7d:00.0 enp125s0f0: link up [80001.269832] hns3 :7d:00.0: PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found [error status=0x1] [80001.269858] hns3 :7d:00.0: PF Reset requested [80001.269881] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [80001.273380] hns3 :7d:00.0: inform reset to vf(1) failed -5! [80001.273401] hns3 :7d:00.0: PF failed(=-5) to send mailbox message to VF [80001.276876] hns3 :7d:00.0: inform reset to vf(2) failed -5! [80001.276902] hns3 :7d:00.0:
[Kernel-packages] [Bug 1892367] Re: [UBUNTU 20.04] udev rule change did not get applied
Triaged to the subiquity project, as this issue appears to be related to a subiquity 20.04 installation. Please feel free to reclassify if that's inappropriate. ** Also affects: subiquity Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** No longer affects: subiquity ** Package changed: linux (Ubuntu) => subiquity ** Changed in: ubuntu-z-systems Importance: Undecided => Medium ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- 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/1892367 Title: [UBUNTU 20.04] udev rule change did not get applied Status in subiquity: New Status in Ubuntu on IBM z Systems: New Bug description: During the ubuntu installation in tessia, we do chzdev for both dasd and qeth devices, as below. 2020-08-20 09:54:45 | INFO | START subiquity/Early/run/command_1 : chzdev -e dasd 385c 2020-08-20 09:54:45 | INFO | SUCCESS subiquity/Early/run/command_1 : chzdev -e dasd 385c 2020-08-20 09:54:45 | INFO | START subiquity/Early/run/command_2 : chzdev -e qeth 0.0.bdf0 2020-08-20 09:54:47 | INFO | SUCCESS subiquity/Early/run/command_2 : chzdev -e qeth 0.0.bdf0 and we can see the below files in the /etc/udev/rules.d/ oot@m8360024:~# ls -l /etc/udev/rules.d/ total 76 -rw-r--r-- 1 root root 154 Aug 20 09:08 41-cio-ignore.rules -rw-r--r-- 1 root root 430 Aug 20 09:08 41-dasd-eckd-0.0.385c.rules -rw-r--r-- 1 root root 357 Aug 20 09:08 41-generic-ccw-0.0.0009.rules -rw-r--r-- 1 root root 1049 Aug 20 09:08 41-qeth-0.0.bdf0.rules -rw-r--r-- 1 root root 58549 Aug 20 09:10 70-snap.snapd.rules Now, lsinitramfs shows files as below, root@m8360024:~# lsinitramfs /boot/initrd.img-5.4.0-42-generic | grep 41 etc/udev/rules.d/41-cio-ignore-root.rules etc/udev/rules.d/41-dasd-eckd-0.0.385c.rules usr/lib/udev/rules.d/41-cio-ignore.rules usr/lib/udev/rules.d/41-dasd-eckd-0.0.385c.rules usr/lib/udev/rules.d/41-generic-ccw-0.0.0009.rules usr/lib/udev/rules.d/41-qeth-0.0.bdf0.rules Even though lsinitramfs shows the below files, they are overruled by the filesystem files. Next thing we did was to modify the 41-qeth-0.0.bdf0.rules and modified the buffer_count to 128 (As in the attached file). In ideal scenario, the value should we modified as mentioned in the bug. But, in our case, if we are not doing a zipl or update-initramfs -u, the value is not getting modified. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1892367/+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 1890867] Re: kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D05 arm64 arch
** Also affects: subiquity (Ubuntu) Importance: Undecided Status: New ** Tags added: enablement-18.04.5 -- 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/1890867 Title: kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D05 arm64 arch Status in linux package in Ubuntu: Confirmed Status in subiquity package in Ubuntu: New Bug description: image: 18.04.5 daily image (20200806.1) bionic-live-server-arm64.iso kernel: 4.15.0-112-generic #113-Ubuntu platform: Hisilicon D05 arm64 arch [Reproducing Steps] 1. setup pxe boot by following https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510 2. pxe boot the machine with the image [Expected Result] Boot to subiquity [Actual Result] Kernel trace happened during booting process. Reproducing rate: 2 out of 2. [6.643543] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-112-generic #113-Ubuntu [6.651271] Hardware name: Hisilicon D05/BC11SPCD, BIOS 1.50 06/01/2018 [6.657871] Call trace: [6.660308] dump_backtrace+0x0/0x198 [6.663957] show_stack+0x24/0x30 [6.667261] dump_stack+0x98/0xbc [6.670563] panic+0x128/0x2a4 [6.673606] mount_block_root+0x210/0x2e8 [6.677603] mount_root+0x7c/0x8c [6.680904] prepare_namespace+0x144/0x1dc [6.684987] kernel_init_freeable+0x218/0x23c [6.689331] kernel_init+0x18/0x110 [6.692806] ret_from_fork+0x10/0x18 [6.696428] SMP: stopping secondary CPUs [6.700345] Kernel Offset: disabled [6.703821] CPU features: 0x2008 [6.707382] Memory Limit: none [6.710438] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890867/+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 1890884] Re: kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D06 arm64 arch
** Tags added: enablement-18.04.5 -- 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/1890884 Title: kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D06 arm64 arch Status in subiquity: New Status in linux package in Ubuntu: Incomplete Bug description: image: 18.04.5 daily image (20200806.1) bionic-live-server-arm64.iso kernel: 4.15.0-112-generic #113-Ubuntu platform: Hisilicon D06 arm64 arch [Reproducing Steps] 1. setup pxe boot by following https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510 2. pxe boot the machine with the image [Expected Result] Boot to subiquity [Actual Result] Kernel trace happened during booting process. Reproducing rate: 2 out of 2. [8.375118] md: ... autorun DONE. [8.378478] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [8.385955] Please append a correct "root=" boot option; here are the available partitions: [8.394303] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [8.402554] CPU: 32 PID: 1 Comm: swapper/0 Not tainted 4.15.0-112-generic #113-Ubuntu [8.410369] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.20.01 04/26/2019 [8.418879] Call trace: [8.421316] dump_backtrace+0x0/0x198 [8.424965] show_stack+0x24/0x30 [8.428269] dump_stack+0x98/0xbc [8.431572] panic+0x128/0x2a4 [8.434615] mount_block_root+0x210/0x2e8 [8.438610] mount_root+0x7c/0x8c [8.441912] prepare_namespace+0x144/0x1dc [8.445995] kernel_init_freeable+0x218/0x23c [8.450341] kernel_init+0x18/0x110 [8.453817] ret_from_fork+0x10/0x18 [8.457486] SMP: stopping secondary CPUs [8.461836] Kernel Offset: disabled [8.465312] CPU features: 0x03200a38 [8.468873] Memory Limit: none [8.473291] Unable to handle kernel paging request at virtual address 09865034 [8.481192] Mem abort info: [8.483972] ESR = 0x9661 [8.487013] Exception class = DABT (current EL), IL = 32 bits [8.492918] SET = 0, FnV = 0 [8.495958] EA = 0, S1PTW = 0 [8.499086] Data abort info: [8.501953] ISV = 0, ISS = 0x0061 [8.505774] CM = 0, WnR = 1 [8.508729] swapper pgtable: 4k pages, 48-bit VAs, pgd = (ptrval) [8.515502] [09865034] *pgd=0a5fe003, *pud=0a5fd003, *pmd=0a5f7003, *pte=006894110703 [8.526445] Internal error: Oops: 9661 [#1] SMP [8.531310] Modules linked in: [8.534351] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [8.541039] CPU: 32 PID: 1 Comm: swapper/0 Not tainted 4.15.0-112-generic #113-Ubuntu [8.548854] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.20.01 04/26/2019 [8.557363] pstate: 60800089 (nZCv daIf -PAN +UAO) [8.562144] pc : acpi_os_write_memory+0xac/0x158 [8.566749] lr : apei_write+0xb0/0xc0 [8.570397] sp : 09afb900 [8.573698] x29: 09afb900 x28: fffe [8.578996] x27: x26: ffa5 [8.584294] x25: ffbe x24: 0080 [8.589592] x23: 0005 x22: 0008 [8.594890] x21: 0040 x20: 0010 [8.600188] x19: 94110034 x18: 0003 [8.605486] x17: x16: 0009 [8.610784] x15: 001f x14: 8205169d4225fc6e [8.616082] x13: 34650f577629d387 x12: 9c021ee3f3d0bcca [8.621380] x11: b1ae83ff50c19148 x10: b6b91ab42ae87562 [8.626678] x9 : f469cb78cb1add9d x8 : a16fcb806efa3dd5 [8.631976] x7 : 0001 x6 : 94110034 [8.637274] x5 : 9411003c x4 : 09639fb8 [8.642571] x3 : x2 : 0034 [8.647869] x1 : 0010 x0 : 09865034 [8.653167] Call trace: [8.655601] acpi_os_write_memory+0xac/0x158 [8.659858] apei_write+0xb0/0xc0 [8.663160] __apei_exec_write_register+0x88/0xb0 [8.667851] apei_exec_write_register_value+0x2c/0x38 [8.672888] __apei_exec_run+0xac/0x108 [8.676711] erst_write+0x154/0x268 [8.680186] erst_writer+0x26c/0x3b0 [8.683751] pstore_dump+0x1b4/0x330 [8.687313] kmsg_dump+0xd0/0x100 [8.690615] panic+0x164/0x2a4 [8.693656] mount_block_root+0x210/0x2e8 [8.697652] mount_root+0x7c/0x8c [8.700953] prepare_namespace+0x144/0x1dc [8.705035] kernel_init_freeable+0x218/0x23c [8.709380] kernel_init+0x18/0x110 [8.712855] ret_from_fork+0x10/0x18 [8.716418] Code: 54000380 710102bf 54000561 d5033e9f (f914) [8.722499] ---[ end trace 8cc2af9c56a59f43 ]--- [ 38.738914] WARNING: CPU: 32 PID: 9 at
[Kernel-packages] [Bug 1873961] Re: tc filter show tcp_flags wrong mask value
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/1873961 Title: tc filter show tcp_flags wrong mask value Status in The Ubuntu-power-systems project: Fix Released Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Fix Released Bug description: [SRU Justification] Impact: The tc command does not show the correct values for tcp_flags (and ip_tos) on filter rules. This might break other scripts parsing that output but at least confuses users. Fix: Backport of "tc: fix bugs for tcp_flags and ip_attr hex output" from upstream iproute2. Testcase: tc qdisc add dev lo ingress tc filter add dev lo parent : prio 3 proto ip flower ip_tos 0x8/32 tc filter add dev lo parent : prio 5 proto ip flower ip_proto tcp \ tcp_flags 0x909/f00 tc filter show dev lo parent : filter protocol ip pref 3 flower chain 0 filter protocol ip pref 3 flower chain 0 handle 0x1 eth_type ipv4 ip_tos a9606c10 <-- bad, should be 0x8/32 not_in_hw filter protocol ip pref 5 flower chain 0 filter protocol ip pref 5 flower chain 0 handle 0x1 eth_type ipv4 ip_proto tcp tcp_flags 909909 <-- bad, should be 0x909/f00 not_in_hw Note that the ip_tos value in the -j[son] output is correct, while the tcp_flags value is is incorrect in both cases. Risk of Regression: Low: Usually scripts would use the json output and that has at least the ip output correct. And the values shown in the bad case seem to be little useful. So it seems unlikely anybody relied on them. But cannot completely be ruled out. === Original description === ---Problem Description--- Problem Descriptions "tc" utility does not show correct TC rule's tcp_flags mask correctly in current "iproute2" package shipped on Genesis. # dpkg -l |grep iproute2 ii iproute2 4.15.0-2ubuntu1 ppc64el networking and traffic control tools ---Steps to Reproduce--- Steps to reproduce the problem: 1) Add a tc rule to the testing VF (i.e. p0v2_r): # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2 skip_sw action mirred egress redirect dev p0v0_r 2) Validate the added TC rule: # tc filter show dev p0v2_r root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 22 /* <--- Wrong */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen 3) If we add the tcp_flags using explicit mask 0x7: # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 skip_sw action mirred egress redirect dev p0v0_r After that, using "tc filter show dev p0v2_r root" to verify, we still see the same output (tcp_flags 22) as shown in 2) above, which is wrong. Userspace tool common name: tc The userspace tool has the following bit modes: 64-bit Userspace package: iproute2 == Fixes: There are 2 patches to fix the issue: patch 1: commit b85076cd74e77538918d35992b1a9cd17ff86af8 Author: Stephen Hemminger Date: Tue Sep 11 08:29:33 2018 -0700 lib: introduce print_nl Common pattern in iproute commands is to print a line seperator in non-json mode. Make that a simple function. /* This patch declares global variable "const char *_SL_ = "\n";" in lib/utils.c to be used by 2nd patch */ patch 2: commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc Author: Keara Leibovitz Date: Thu Jul 26 09:45:30 2018 -0400 tc: fix bugs for tcp_flags and ip_attr hex output Fix hex output for both the ip_attr and tcp_flags print functions. With the above 2 patches pull in, the new "tc" utility will show the correct tcp_flags mask: # tc filter show dev p0v2 root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 0x2/7 /* <--- Correct */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen This bug affects tc in Ubuntu 18.04.1 stock image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1873961/+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 1887124] Re: [UBUNTU 20.04] DIF and DIX support in zfcp (s390x) is broken and the kernel crashes unconditionally
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu) 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/1887124 Title: [UBUNTU 20.04] DIF and DIX support in zfcp (s390x) is broken and the kernel crashes unconditionally Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: SRU Justification: == [Impact] * DIF and DIX support in zfcp (s390x) is broken and the kernel crashes unconditionally, in case one activates either zfcp DIF (data integrity field) or DIX (data integrity extention) and attaches any LU. * zfcp used to allocate/add the shost object for a HBA, before knowing all the HBA's capabilities. But later the shost object got patched to make more of the capabilities known - including the protection capabilities. * Changes that are later made to the protection capabilities don't get reflected in the tag-set requests and are missing. * Now sending I/O, scsi_mod tries to access the protection payload data, that isn't there, and the kernel crashes. [Fix] * The SRU request was created as pull request, so please pull starting at 0b38938af911 to head / 9227405ee311 from https://code.launchpad.net/~fheimes/+git/lp1887124 [Test Case] * Have a IBM Z or LInuxONE system (ideally on LPAR) in place that is connected to a DS8xxx storage subsystem that supports, zfcp SCSI storage with DIF and DIX. * Have an Ubuntu Server 20.04 installed in such a LPAR system. * Now enable DIF (zfcp.dif=1) or DIX (zfcp.dix=1) and connect the system to a logical unit. * Monitor the system for any kernel crashes (/var/log/syslog and /var/log/kern.log) - look for kernel panic in scsi_queue_rq. [Regression Potential] * Even if the modifications are substantial, the regression potnetial can be considered as moderate. * This issue could be mainly tracked down to commit '737eb78e82d5' (made for v5.4) that made the problem more visible. * With the old blk queue DIF/DIX worked fine, but after scsi_mod switched to blk-mq (and because requests are now all allocated during allocation time of the blk-mq tag-set), it didn't worked anymore. * The solution is to allocate/add the shost object for a HBA after all of its base capabilities are known. * Since the situation is like this for quite a while, several places in the zfcp driver code (where it's assumed that the shost object was correctly allocated) needed to be touched. * This is finally the reason (as well as the fact that some parts depend on code that went upstream with the kernels 5.5 and 5.7) for this rather big patchset for fixing DIF and DIX support in zfcp. * On the other hand side this entire set is now upstream accepted and entirely included in 5.8 (and with that soon in groovy), and no 5.4-specific (hand-crafted) backports are needed. * Also notice that all modifications are in the zfcp driver layer, hence they are s390x specific, and with that limited to /drivers/s390/scsi/zfcp_* * Finally the patches were already tested with a patched focal kernel with DIF/DIX/NONE, with I/O, and local/remote cable pulls - switched and point-to-point connected. No regressions were identified. [Other] * Alternatively the patches can also be cherry-picked from linux master with: git cherry-pick 92953c6e0aa7~1..e76acc519426 git cherry-pick a3fd4bfe85fb git cherry-pick e05a10a05509~1..42cabdaf103b git cherry-pick cec9cbac5244 git cherry-pick 978857c7e367~1..d0dff2ac98dd * The following lists the individual commits - just for the reason of completeness: * 92953c6e0aa77d4febcca6dd691e8192910c8a28 92953c6e0aa77 "scsi: zfcp: signal incomplete or error for sync exchange config/port data" * 7e418833e68948cb9ed15262889173b7db2960cb 7e418833e6894 "scsi: zfcp: diagnostics buffer caching and use for exchange port data" * 088210233e6fc039fd2c0bfe44b06bb94328d09e 088210233e6fc "scsi: zfcp: add diagnostics buffer for exchange config data" * a10a61e807b0a226b78e2041843cbf0521bd0c35 a10a61e807b0a "scsi: zfcp: support retrieval of SFP Data via Exchange Port Data" * 6028f7c4cd87cac13481255d7e35dd2c9207ecae 6028f7c4cd87c "scsi: zfcp: introduce sysfs interface for diagnostics of local SFP transceiver" * 8155eb0785279728b6b2e29aba2ca52d16aa526f 8155eb0785279 "scsi: zfcp: implicitly refresh port-data diagnostics when reading sysfs" * 5a2876f0d1ef26b76755749f978d46e4666013dd 5a2876f0d1ef2 "scsi: zfcp: introduce sysfs interface to read the local B2B-Credit" * 8a72db70b5ca3c3feb3ca25519e8a9516cc60cfe 8a72db70b5ca3 "scsi: zfcp: implicitly refresh config-data diagnostics when reading
[Kernel-packages] [Bug 1889763] Re: [UBUNTU 20.04] kubernetes-core is not fully installed on s390x
** Also affects: charmed-kubernetes-bundles Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** No longer affects: ubuntu-z-systems ** Package changed: linux (Ubuntu) => ubuntu-z-systems ** Changed in: ubuntu-z-systems Assignee: Skipper Bug Screeners (skipper-screen-team) => CDK Leadership (cdk8s-leader) -- 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/1889763 Title: [UBUNTU 20.04] kubernetes-core is not fully installed on s390x Status in Charmed Kubernetes Bundles: New Status in Ubuntu on IBM z Systems: New Bug description: Steps to reproduce: LXD setup and juju installation are done following these instructions https://ubuntu.com/kubernetes/docs/install-local Kubernetes Core bundle is installed as described here https://jaas.ai/kubernetes-core with juju deploy cs:bundle/kubernetes-core-1069 Expected result - 1 master and 1 worker node. Actual result - just 1 node. # juju status Model Controller Cloud/Region Version SLA Timestamp k8slocalhost-localhost localhost/localhost 2.8.1unsupported 11:28:37+02:00 AppVersion Status Scale Charm Store Rev OS Notes containerd 1.3.3active 2 containerd jujucharms 80 ubuntu easyrsa3.0.1active 1 easyrsajujucharms 318 ubuntu etcd 3.3.19 active 1 etcd jujucharms 521 ubuntu flannel0.11.0 active 2 flanneljujucharms 492 ubuntu kubernetes-master 1.18.6 active 1 kubernetes-master jujucharms 850 ubuntu exposed kubernetes-worker 1.18.6 active 1 kubernetes-worker jujucharms 682 ubuntu exposed Unit Workload Agent Machine Public address Ports Message easyrsa/0*activeidle 0/lxd/0 10.123.107.225 Certificate Authority connected. etcd/0* activeidle 010.70.13.93 2379/tcp Healthy with 1 known peer kubernetes-master/0* activeidle 010.70.13.93 6443/tcp Kubernetes master running. containerd/1activeidle10.70.13.93 Container runtime available flannel/1 activeidle10.70.13.93 Flannel subnet 10.1.67.1/24 kubernetes-worker/0* activeidle 110.70.13.168 80/tcp,443/tcp Kubernetes worker running. containerd/0* activeidle10.70.13.168 Container runtime available flannel/0* activeidle10.70.13.168 Flannel subnet 10.1.99.1/24 Machine StateDNS Inst id Series AZ Message 0started 10.70.13.93 juju-62238e-0bionic Running 0/lxd/0 started 10.123.107.225 juju-62238e-0-lxd-0 bionic Container started 1started 10.70.13.168juju-62238e-1bionic Running # kubectl get nodes NAMESTATUS ROLESAGE VERSION juju-62238e-1 Ready 74m v1.18.6 Output about pods on the cluster # kubectl get pods No resources found in default namespace. root@m8360041:~# kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE ingress-nginx-kubernetes-worker default-http-backend-kubernetes-worker-6fc4c9975-2dwsc 1/1 Running 0 41m ingress-nginx-kubernetes-worker nginx-ingress-controller-kubernetes-worker-qmz2j 1/1 Running 0 41m kube-system coredns-7f748b899d-dc5hx 1/1 Running0 42m kube-system kube-state-metrics-69f474f8cb-9s85h 0/1 CrashLoopBackOff 26 42m kube-system metrics-server-v0.3.6-5c9f85bbd6-8mksp 2/2 Running0 42m kubernetes-dashboard dashboard-metrics-scraper-78d587b6b-2ggmz 0/1 CrashLoopBackOff 26 42m kubernetes-dashboard kubernetes-dashboard-76b6648555-x4fng 1/1 Running0 42m To manage notifications about this bug go to: https://bugs.launchpad.net/charmed-kubernetes-bundles/+bug/1889763/+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 1859756] Re: [hns3-0115] add 8 BD limit for tx flow
** Changed in: kunpeng920/ubuntu-18.04 Status: In Progress => Fix Committed ** Changed in: kunpeng920 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/1859756 Title: [hns3-0115] add 8 BD limit for tx flow Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] We get reports that iscsi and spark tests fail on hns3 [Fix] Cherry-pick/backport patches from upstream. net: hns3: add 8 BD limit for tx flow net: hns3: avoid mult + div op in critical data path net: hns3: remove some ops in struct hns3_nic_ops net: hns3: fix for not calculating tx bd num correctly net: hns3: unify maybe_stop_tx for TSO and non-TSO case net: hns3: add check for max TX BD num for tso and non-tso case net: hns3: fix for TX queue not restarted problem net: hns3: fix a use after free problem in hns3_nic_maybe_stop_tx() [Test] No known way to reproduce it in our lab. Regression test only. [Regression Potential] Patchset only affects hns3 driver. Minimal risk for other drivers and platform. [Bug Description] A single transmit packet can span up to 8 descriptors, TSO transmit packet can be stored up to 63 descriptors and each segment within the TSO should be spanned up to 8 descriptors. If the packet needs more than 8 BD, and the total size of every 7 continuous frags more than MSS, HW does not support it, and it need driver makes SKB Linearized. [Actual Results] iscsi and bigdata spark test OK [Expected Results] iscsi and bigdata spark test OK [Reproducibility] Inevitably [Additional information] Hardware: D06 Firmware: NA Kernel: NA DTS2018091810050 [Resolution] SW use skb_copy to merge frag; 51e8439f3496 net: hns3: add 8 BD limit for tx flow 5f543a54eec0 net: hns3: fix for not calculating tx bd num correctly To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1859756/+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 1887986] Re: Enable FUNCTION_PROFILER kernel config option for ppc64le
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: ubuntu-power-systems Importance: Undecided => Medium -- 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/1887986 Title: Enable FUNCTION_PROFILER kernel config option for ppc64le Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: Please enable CONFIG_FUNCTION_PROFILER config option for ppc64le kernel. This option enables the ftrace function profiling in the kernel, it helps in getting the function profiling information such as hit count, time spend and other profiling details. Enabling this kernel config option should not have any performance impact unless the function profiling is enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1887986/+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 1867900] Re: CPU stress test fails with focal kernel
** Changed in: kunpeng920 Status: Triaged => In Progress ** Changed in: kunpeng920/ubuntu-18.04-hwe Status: Triaged => In Progress ** Changed in: kunpeng920/ubuntu-20.04 Status: Triaged => In Progress -- 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/1867900 Title: CPU stress test fails with focal kernel Status in kunpeng920: In Progress Status in kunpeng920 ubuntu-18.04-hwe series: In Progress Status in kunpeng920 ubuntu-20.04 series: In Progress Status in kunpeng920 upstream-kernel series: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: In Progress Bug description: [Impact] We have several crypto accelerators for Hisilicon 1620 but unfortunately one of them is not mature and causes stress-ng tests failure. Disabling hisi_sec2 makes kernel to run crypto functions without accelerator. [Fix] Disable CONFIG_CRYPTO_DEV_HISI_SEC2 temporarily until we have proper driver. [Test] $ sudo stress-ng --aggressive --verify --timeout 330 --metrics-brief --tz --times --af-alg 0 $ echo $? [Regression Potential] This driver is only loaded on Hisilicon Hi1620 machines. Low risk for other platform. == [Bug Description] CPU stress test fails with focal kernel [Steps to Reproduce] 1) sudo apt-add-repository -y ppa:firmware-testing-team/ppa-fwts-stable 2) sudo apt-add-repository -y ppa:hardware-certification/public 3) sudo apt install -y canonical-certification-server 4) Install focal kernel debs from https://launchpad.net/ubuntu/+source/linux 5) Run CPU stress test with `sudo certify-advanced` [Actual Results] Failed with stress-ng: fail: [6118] stress-ng-af-alg: bind failed, errno=19 (No such device) [Expected Results] Passed [Reproducibility] 100% [Additional information] Same test with bionic-update kernel passed [Resolution] To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867900/+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 1874055] Re: [UBUNTU 20.04] s390x/pci: s390_pci_mmio_write/read fail when MIO instructions are available
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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/1874055 Title: [UBUNTU 20.04] s390x/pci: s390_pci_mmio_write/read fail when MIO instructions are available Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Released Bug description: SRU Justification: == [Impact] * Code that is using s390_pci_mmio_write/read system calls on a z15 (that comes with enhanced PCI load/store instructions), fails with "Unable to handle kernel pointer dereference in virtual kernel address space". * This issue happens if enablement for z15 PCI enhancements is in place and where customers run workloads which access PCI adapters from user space, like RoCE/RDMA. * To solve this, the system call implementation needs to be improved to execute the enhanced PCI load/store instructions on behalf of the user space application, making use of the mappings into its virtual address space. [Fix] * f058599e22d59e594e5aae1dc10560568d8f4a8b f058599e22d5 "s390/pci: Fix s390_mmio_read/write with MIO" [Test Case] * Setting up a z15 with at least one PCI card (like RoCE) using an operating system that includes support and enablement for z15 (line 20.04). * Install the rdma tools: sudo apt install ibverbs-providers ibverbs- utils * Verify you have some RDMA devices (requires ConnectX adapter) $ ibv_devices device node GUID -- mlx5_0 98039b0300c682b4 * Verify MIO instructions are enabled for the device $ cat /sys/bus/pci/devices/\:00\:00.0/mio_enabled 1 * Try to run an RDMA application from user space, e.g. ibv_rc_pingpong server side: ibv_rc_pingpong -d mlx5_0 -g 0 & client side: ibv_rc_pingpong -d mlx5_0 -g 0 localhost * Verify whether the kernel crashes or not. * Verification needs to be done by IBM on z15 hardware. [Regression Potential] * There is some regression potential with having code changes in the zPCI sub-system (zPCI is limited to s390x) * It could be that zPCI hardware get harmed, but zPCI hardware is not as wide-spread on s390x than ccw hardware components. * Only z15 hardware is affected - no other s390x hardware that is supported by Ubuntu. * However, the zPCI system is s390x only and the patch was accepted upstream with v5.7-rc7 and Linus commented: "And none of the fixes look like there's anything particularly scary going on. Most of it is very small, and the slightly larger patches aren't huge either and are well-contained (the two slightly larger patches are to s390 and rxrpc - and even those patches aren't really all _that_ big)" __ One of the PCI enhancements on Z15 are the enhanced PCI load/store instructions which can be executed directly from user space code. When these instructions are available and preexisting user space code still uses the old s390_pci_mmio_write/read system calls, the system calls fail with an "Unable to handle kernel pointer dereference in virtual kernel address space" in the kernel. This issue affects distributions which have the enablement for Z15 PCI enhancements and where customers run workloads which accesses PCI adapters from user space, e.g. RDMA applications. To solve this, the system call implementation needs to be enhanced to provide to execute enhanced PCI load/store instructions on behalf of the user space application making use of the mappings into its virtual address space To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874055/+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 1874056] Re: [UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter
Many thanks! Adjusting tags. -- 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/1874056 Title: [UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Bug description: SRU Justification: == [Impact] * Mellanox CX5 port multi-pathing is broken on s390x due to non- standard topology of PCI IDs (phys. and virtual) * The Mellanox Connect-X 5 PCI driver (mlx5) implements multi-path that can be used to combine multiple networking ports to improve performance and reliability. * For that purpose, the mlx5 driver combines PCI functions based on topology information (the function number) as determined by their PCI ID. * Currently the Linux on Z PCI bus does not reflect PCI topology information in the PCI ID. As a result, the mlx5 multi-path function is broken and cannot be activated. [Fix] * Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci- Improve-handling-of-unset-UID.patch * Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci- embedding-hotplug_slot-in-zdev.patch * Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci- Expose-new-port-attribute-for-PCIe-function.patch * Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci- adaptation-of-iommu-to-multifunction.patch * Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci- define-kernel-parameters-for-PCI-multifunct.patch * Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci- define-RID-and-RID-available.patch * Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci- create-zPCI-bus.patch * Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci- adapt-events-for-zbus.patch * Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci- Handling-multifunctions.patch * Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci- Do-not-disable-PF-when-VFs-exist.patch * Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci- Documentation-for-zPCI.patch * Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci- removes-wrong-PCI-multifunction-assignment.patch [Test Case] * Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters. * Assign the adapters (and it's virtual functions) to an LPAR. * Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...) [Regression Potential] * The regression potential can be considered as moderate, since: * It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too). * It largely affects zPCI, the s390x specific PCI code layer. * PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread. * The situation described above affects the RoCE adapters only (Mellanox based). * The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed. * However, the code is modified by several patches (12), hence there is a chance to break zPCI with them. * For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches. __ Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter. Layout of a PCI function address on Linux: :00:00.0 ::. On s390x, each function is presented as individual root complex today, e.g.: PCHID 0100 VF1 :00:00.0 PCHID 0100 VF23 0001:00:00.0 PCHID 0200 VF1 0002:00:00.0 OCHID 0100 VF17 0003:00:00.0 On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for ::. We need to use the same enumeration scheme to achieve this functionality on s390x. In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same : numbers with function/device numbers counting up. Required result (example with 4 VFs per PF): PCHID 0100 PF 0 :00:00.0 PCHID 0100 PF 1 :00:00.1 PCHID 0100 PF 0 VF 0 :00:00.2 PCHID 0100 PF 0 VF 1 :00:00.3 PCHID 0100 PF 0 VF 2 :00:00.4 PCHID 0100 PF 0 VF 3 :00:00.5 PCHID 0100 PF 1 VF 0 :00:00.6 PCHID 0100 PF 1 VF 1 :00:00.7 PCHID 0100 PF 1 VF 2
[Kernel-packages] [Bug 1874056] Re: [UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter
Many thanks! Adjust tags. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1874056 Title: [UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Bug description: SRU Justification: == [Impact] * Mellanox CX5 port multi-pathing is broken on s390x due to non- standard topology of PCI IDs (phys. and virtual) * The Mellanox Connect-X 5 PCI driver (mlx5) implements multi-path that can be used to combine multiple networking ports to improve performance and reliability. * For that purpose, the mlx5 driver combines PCI functions based on topology information (the function number) as determined by their PCI ID. * Currently the Linux on Z PCI bus does not reflect PCI topology information in the PCI ID. As a result, the mlx5 multi-path function is broken and cannot be activated. [Fix] * Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci- Improve-handling-of-unset-UID.patch * Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci- embedding-hotplug_slot-in-zdev.patch * Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci- Expose-new-port-attribute-for-PCIe-function.patch * Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci- adaptation-of-iommu-to-multifunction.patch * Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci- define-kernel-parameters-for-PCI-multifunct.patch * Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci- define-RID-and-RID-available.patch * Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci- create-zPCI-bus.patch * Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci- adapt-events-for-zbus.patch * Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci- Handling-multifunctions.patch * Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci- Do-not-disable-PF-when-VFs-exist.patch * Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci- Documentation-for-zPCI.patch * Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci- removes-wrong-PCI-multifunction-assignment.patch [Test Case] * Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters. * Assign the adapters (and it's virtual functions) to an LPAR. * Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...) [Regression Potential] * The regression potential can be considered as moderate, since: * It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too). * It largely affects zPCI, the s390x specific PCI code layer. * PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread. * The situation described above affects the RoCE adapters only (Mellanox based). * The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed. * However, the code is modified by several patches (12), hence there is a chance to break zPCI with them. * For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches. __ Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter. Layout of a PCI function address on Linux: :00:00.0 ::. On s390x, each function is presented as individual root complex today, e.g.: PCHID 0100 VF1 :00:00.0 PCHID 0100 VF23 0001:00:00.0 PCHID 0200 VF1 0002:00:00.0 OCHID 0100 VF17 0003:00:00.0 On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for ::. We need to use the same enumeration scheme to achieve this functionality on s390x. In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same : numbers with function/device numbers counting up. Required result (example with 4 VFs per PF): PCHID 0100 PF 0 :00:00.0 PCHID 0100 PF 1 :00:00.1 PCHID 0100 PF 0 VF 0 :00:00.2 PCHID 0100 PF 0 VF 1 :00:00.3 PCHID 0100 PF 0 VF 2 :00:00.4 PCHID 0100 PF 0 VF 3 :00:00.5 PCHID 0100 PF 1 VF 0
[Kernel-packages] [Bug 1874055] Re: [UBUNTU 20.04] s390x/pci: s390_pci_mmio_write/read fail when MIO instructions are available
Thanks Niklas! Adjusting tags accordingly. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1874055 Title: [UBUNTU 20.04] s390x/pci: s390_pci_mmio_write/read fail when MIO instructions are available Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Bug description: SRU Justification: == [Impact] * Code that is using s390_pci_mmio_write/read system calls on a z15 (that comes with enhanced PCI load/store instructions), fails with "Unable to handle kernel pointer dereference in virtual kernel address space". * This issue happens if enablement for z15 PCI enhancements is in place and where customers run workloads which access PCI adapters from user space, like RoCE/RDMA. * To solve this, the system call implementation needs to be improved to execute the enhanced PCI load/store instructions on behalf of the user space application, making use of the mappings into its virtual address space. [Fix] * f058599e22d59e594e5aae1dc10560568d8f4a8b f058599e22d5 "s390/pci: Fix s390_mmio_read/write with MIO" [Test Case] * Setting up a z15 with at least one PCI card (like RoCE) using an operating system that includes support and enablement for z15 (line 20.04). * Install the rdma tools: sudo apt install ibverbs-providers ibverbs- utils * Verify you have some RDMA devices (requires ConnectX adapter) $ ibv_devices device node GUID -- mlx5_0 98039b0300c682b4 * Verify MIO instructions are enabled for the device $ cat /sys/bus/pci/devices/\:00\:00.0/mio_enabled 1 * Try to run an RDMA application from user space, e.g. ibv_rc_pingpong server side: ibv_rc_pingpong -d mlx5_0 -g 0 & client side: ibv_rc_pingpong -d mlx5_0 -g 0 localhost * Verify whether the kernel crashes or not. * Verification needs to be done by IBM on z15 hardware. [Regression Potential] * There is some regression potential with having code changes in the zPCI sub-system (zPCI is limited to s390x) * It could be that zPCI hardware get harmed, but zPCI hardware is not as wide-spread on s390x than ccw hardware components. * Only z15 hardware is affected - no other s390x hardware that is supported by Ubuntu. * However, the zPCI system is s390x only and the patch was accepted upstream with v5.7-rc7 and Linus commented: "And none of the fixes look like there's anything particularly scary going on. Most of it is very small, and the slightly larger patches aren't huge either and are well-contained (the two slightly larger patches are to s390 and rxrpc - and even those patches aren't really all _that_ big)" __ One of the PCI enhancements on Z15 are the enhanced PCI load/store instructions which can be executed directly from user space code. When these instructions are available and preexisting user space code still uses the old s390_pci_mmio_write/read system calls, the system calls fail with an "Unable to handle kernel pointer dereference in virtual kernel address space" in the kernel. This issue affects distributions which have the enablement for Z15 PCI enhancements and where customers run workloads which accesses PCI adapters from user space, e.g. RDMA applications. To solve this, the system call implementation needs to be enhanced to provide to execute enhanced PCI load/store instructions on behalf of the user space application making use of the mappings into its virtual address space To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874055/+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 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Many thanks for verifying. Adjusting tags.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
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/1879704
Title:
[UBUNTU 20.04] s390x/pci: fix linking between PF and VF for
multifunction devices
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Groovy:
In Progress
Bug description:
SRU Justification:
==
[Impact]
* It's currently not possible on s390x to verify the relationships
between PFs and VFs of network interfaces (neither natively nor in
libvirt).
* So s390x currently behaves differently here compared to other
architectures, but shouldn't, since this is needed for proper
management.
* The creation of not only the sysfs, but also the in-kernel link
(struct pci_dev->physfn), solves this and on top allows the use of a
common code path for disabling/shutdown of PFs.
* This code path is right now fenced off by the struct
pci_dev->no_vf_scan flag of which s390x is currently the only user.
* This allows to gracefully and orderly shutdown VFs associated with a
PF as triggered by '/sys/bus/pci/devices//sriov_numvfs'
* Previously this could leave the card in an unresponsive error state.
[Fix]
* a1ceea67f2e5b73cebd456e7fb463b3052bc6344 a1ceea67f2e5 "PCI/IOV:
Introduce pci_iov_sysfs_link() function"
* e5794cf1a270d813a5b9373a6876487d4d154195 e5794cf1a270 "s390/pci:
create links between PFs and VFs"
[Test Case]
* Setup an s390x LPAR with at least one SR-IOV card and assign PF and
VFs to that system.
* Determine if a device is a virtual function: for other architectures
this is currently available in the file 'physfn' which is a link to
the parent PF's device.
* Determine virtual functions of a physical function: for other
architectures this is currently available as 'virtfn{index}' links
under the PF device's directory.
* Determine the physical function of a virtual function: on x86 this
is currently available in the file 'physfn' which is a link to the
parent PF.
* This verification needs to be done by IBM on a system with SR-IOV
(PCI-based) hardware.
[Regression Potential]
* There is a certain regression risk with having code changes in the PCI/IOV
space,
even is they are limited, especially is the patches touche common code.
* The changes in pci.h are very minimal, and the iov.c changes are
traceable, too. All other modifications are s390x specific.
* Nevertheless, it could be that PCI hardware get harmed, here
especially (SR-)IOV hardware.
* The patches got cross-company verified (IBM and Google).
* They were brought upstream and are currently tagged with 20200521,
and are planned to be included in 5.8.
* A patched kernel was created based on a LP PPA and successfully
tested by IBM.
[Other]
* Since the fix/patch is planned to be included in kernel v5.8, it
will later automatically land in groovy.
* But because groovy is not there yet (5.8 is not yet out), this SRU
got requested for focal and groovy.
* This SRU depends on the SRU from LP 1874056, and this has already two ACKs.
So LP 1874056 needs to be applied before this one!
__
As with other architectures, we must be able on s390x to verify the
following relationships between PFs and VFs for proper management
(including by libvirt) of network interfaces:
1. Determine if a device is a virtual function: for other architectures this
is currently available in the file `physfn` which is a link to the parent PF's
device.
2. Determine virtual functions of a physical function: for other
architectures this is currently available as `virtfn{index}` links under the PF
device's directory.
3. Determine the physical function of a virtual function: on x86 this is
currently available in the file `physfn` which is a link to the parent PF
More details for the already existing parameters mentioned above can
be found here: https://www.kernel.org/doc/Documentation/ABI/testing
/sysfs-bus-pci
Moreover creating not just the sysfs but also the in-kernel link
(struct pci_dev->physfn) also allows us to use the common code path
for disabling/shutdown of PFs.
This code path is currently fenced off by the
struct pci_dev->no_vf_scan flag of which s390 is currently the only user.
This in turn allows for a graceful and orderly shutdown of VFs
associated with a VF as triggered by:
echo 0 > /sys/bus/pci/devices//sriov_numvfs
Previously this could leave the card in an unresponsive error state.
The patches for this have been discussed and Acked-by the
responsible upstream maintainer here:
[RFC 0/2] Enable PF-VF linking with pdev->no_vf_scan
[Kernel-packages] [Bug 1867591] Re: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/upstream-kernel Milestone: linux-v5.7 => None ** Changed in: kunpeng920/upstream-kernel Status: Fix Committed => Incomplete -- 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/1867591 Title: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch Status in kunpeng920: Incomplete Status in kunpeng920 ubuntu-18.04-hwe series: Incomplete Status in kunpeng920 ubuntu-20.04 series: Incomplete Status in kunpeng920 upstream-kernel series: Incomplete Status in linux package in Ubuntu: In Progress Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver crypto: hisilicon/sec2 - Update IV and MAC operation crypto: hisilicon/sec2 - Add iommu status check crypto: hisilicon/sec2 - Add workqueue for SEC driver. crypto: hisilicon - Use one workqueue per qm instead of per qp crypto: hisilicon - qm depends on UACCE crypto: hisilicon - remove redundant assignment of pointer ctx hisilicon - register zip engine to uacce hisilicon - Remove module_param uacce_mode uacce: add uacce driver uacce: Add documents for uacce crypto: hisilicon - Fix duplicate print when qm occur multiple errors crypto: hisilicon - Unify error detect process into qm crypto: hisilicon - Configure zip RAS error type crypto: hisilicon - Unify hardware error init/uninit into QM To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867591/+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 1867900] Re: CPU stress test fails with focal kernel
Note that the kunpeng920 series reflects SRUing the patches described in comment #24. -- 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/1867900 Title: CPU stress test fails with focal kernel Status in kunpeng920: Triaged Status in kunpeng920 ubuntu-18.04-hwe series: Triaged Status in kunpeng920 ubuntu-20.04 series: Triaged Status in kunpeng920 upstream-kernel series: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: In Progress Bug description: [Impact] We have several crypto accelerators for Hisilicon 1620 but unfortunately one of them is not mature and causes stress-ng tests failure. Disabling hisi_sec2 makes kernel to run crypto functions without accelerator. [Fix] Disable CONFIG_CRYPTO_DEV_HISI_SEC2 temporarily until we have proper driver. [Test] $ sudo stress-ng --aggressive --verify --timeout 330 --metrics-brief --tz --times --af-alg 0 $ echo $? [Regression Potential] This driver is only loaded on Hisilicon Hi1620 machines. Low risk for other platform. == [Bug Description] CPU stress test fails with focal kernel [Steps to Reproduce] 1) sudo apt-add-repository -y ppa:firmware-testing-team/ppa-fwts-stable 2) sudo apt-add-repository -y ppa:hardware-certification/public 3) sudo apt install -y canonical-certification-server 4) Install focal kernel debs from https://launchpad.net/ubuntu/+source/linux 5) Run CPU stress test with `sudo certify-advanced` [Actual Results] Failed with stress-ng: fail: [6118] stress-ng-af-alg: bind failed, errno=19 (No such device) [Expected Results] Passed [Reproducibility] 100% [Additional information] Same test with bionic-update kernel passed [Resolution] To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867900/+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 1867591] Re: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch
Next step is to wait for the patch described in comment #17 to be integrated into the upstream kernel. -- 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/1867591 Title: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch Status in kunpeng920: Incomplete Status in kunpeng920 ubuntu-18.04-hwe series: Incomplete Status in kunpeng920 ubuntu-20.04 series: Incomplete Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: In Progress Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver crypto: hisilicon/sec2 - Update IV and MAC operation crypto: hisilicon/sec2 - Add iommu status check crypto: hisilicon/sec2 - Add workqueue for SEC driver. crypto: hisilicon - Use one workqueue per qm instead of per qp crypto: hisilicon - qm depends on UACCE crypto: hisilicon - remove redundant assignment of pointer ctx hisilicon - register zip engine to uacce hisilicon - Remove module_param uacce_mode uacce: add uacce driver uacce: Add documents for uacce crypto: hisilicon - Fix duplicate print when qm occur multiple errors crypto: hisilicon - Unify error detect process into qm crypto: hisilicon - Configure zip RAS error type crypto: hisilicon - Unify hardware error init/uninit into QM To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867591/+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 1873961] Re: tc filter show tcp_flags wrong mask value
** Changed in: ubuntu-power-systems Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/1873961 Title: tc filter show tcp_flags wrong mask value Status in The Ubuntu-power-systems project: Triaged Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Triaged Bug description: ---Problem Description--- Problem Descriptions "tc" utility does not show correct TC rule's tcp_flags mask correctly in current "iproute2" package shipped on Genesis. # dpkg -l |grep iproute2 ii iproute2 4.15.0-2ubuntu1 ppc64el networking and traffic control tools ---Steps to Reproduce--- Steps to reproduce the problem: 1) Add a tc rule to the testing VF (i.e. p0v2_r): # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2 skip_sw action mirred egress redirect dev p0v0_r 2) Validate the added TC rule: # tc filter show dev p0v2_r root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 22 /* <--- Wrong */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen 3) If we add the tcp_flags using explicit mask 0x7: # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 skip_sw action mirred egress redirect dev p0v0_r After that, using "tc filter show dev p0v2_r root" to verify, we still see the same output (tcp_flags 22) as shown in 2) above, which is wrong. Userspace tool common name: tc The userspace tool has the following bit modes: 64-bit Userspace package: iproute2 == Fixes: There are 2 patches to fix the issue: patch 1: commit b85076cd74e77538918d35992b1a9cd17ff86af8 Author: Stephen Hemminger Date: Tue Sep 11 08:29:33 2018 -0700 lib: introduce print_nl Common pattern in iproute commands is to print a line seperator in non-json mode. Make that a simple function. /* This patch declares global variable "const char *_SL_ = "\n";" in lib/utils.c to be used by 2nd patch */ patch 2: commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc Author: Keara Leibovitz Date: Thu Jul 26 09:45:30 2018 -0400 tc: fix bugs for tcp_flags and ip_attr hex output Fix hex output for both the ip_attr and tcp_flags print functions. With the above 2 patches pull in, the new "tc" utility will show the correct tcp_flags mask: # tc filter show dev p0v2 root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 0x2/7 /* <--- Correct */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen This bug affects tc in Ubuntu 18.04.1 stock image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1873961/+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 1867591] Re: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch
Xinwei has commented that this patchset may also fix bug# 1867900 -- 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/1867591 Title: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch Status in kunpeng920: Incomplete Status in kunpeng920 ubuntu-18.04-hwe series: Incomplete Status in kunpeng920 ubuntu-20.04 series: Incomplete Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: In Progress Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver crypto: hisilicon/sec2 - Update IV and MAC operation crypto: hisilicon/sec2 - Add iommu status check crypto: hisilicon/sec2 - Add workqueue for SEC driver. crypto: hisilicon - Use one workqueue per qm instead of per qp crypto: hisilicon - qm depends on UACCE crypto: hisilicon - remove redundant assignment of pointer ctx hisilicon - register zip engine to uacce hisilicon - Remove module_param uacce_mode uacce: add uacce driver uacce: Add documents for uacce crypto: hisilicon - Fix duplicate print when qm occur multiple errors crypto: hisilicon - Unify error detect process into qm crypto: hisilicon - Configure zip RAS error type crypto: hisilicon - Unify hardware error init/uninit into QM To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867591/+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 1877955] Re: Followon for Ubuntu Kernel Support for OpenPOWER NV Secure & Trusted Boot
** Also affects: ubuntu-power-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-power-systems
Importance: Undecided => Medium
** Changed in: ubuntu-power-systems
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
--
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/1877955
Title:
Followon for Ubuntu Kernel Support for OpenPOWER NV Secure & Trusted
Boot
Status in The Ubuntu-power-systems project:
New
Status in linux package in Ubuntu:
New
Bug description:
== Comment: #0 - Michael Ranweiler - 2020-04-22
14:44:31 ==
+++ This bug was initially created as a clone of Bug #184073 +++
This bug is a follow on to LP 1866909 to address a missing piece -
only half the following patch was included in 5.4.0-24.28.
The upstream patch has an additional fix but it?s not critical for GA.
It can get included as part of bug fixes. It also affects only power.
The patch("powerpc/ima: fix secure boot rules in ima arch policy") is
posted to linux-integrity and linuxppc-dev mailing list
(https://lore.kernel.org/linux-integrity/1586549618-6106-1-git-send-
email-na...@linux.ibm.com/T/#u)
If there are any issues identified during further testing, they will
get opened as separate issue to be addressed later.
Thanks & Regards,
- Nayna
== Comment: #4 - Michael Ranweiler - 2020-05-11
02:23:35 ==
Updated posting:
https://lore.kernel.org/linux-integrity/1588342612-14532-1-git-send-
email-na...@linux.ibm.com/T/#u
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1877955/+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 1876047] Re: [UBUNTU 20.04] Subiquity installation fail at "creating new user"
** Also affects: subiquity (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => Critical -- 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/1876047 Title: [UBUNTU 20.04] Subiquity installation fail at "creating new user" Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Status in subiquity package in Ubuntu: New Bug description: Installation stop at step "creating new user" ---uname output--- ilabg13.tuc.stglabs.ibm.com 5.4.0-28-generic #32-Ubuntu SMP Wed Apr 22 17:39:15 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = zvm7.1 lpar ---boot type--- Network boot ---bootloader--- grub ---Kernel cmdline used to launch install--- ilabg13.tuc.stglabs.ibm.com 5.4.0-28-generic #32-Ubuntu SMP Wed Apr 22 17:39:15 UTC 2020 s390x s390x s390x GNU/Linux ---Bootloader protocol--- tftp ---Install repository type--- CDROM ---Point of failure--- Other failure during installation (stage 1) qq An error has occurred k xinstalling system x x curtin command install x xpreparing for installation x xconfiguring storage x x running 'curtin block-meta simple' x xcurtin command block-meta x x removing previous storage devices x x subiquity/Error/1588222460.991070032.install_fail/add_info x x subiquity/Error/1588222460.991070032.install_fail/upload To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1876047/+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 1861976] Re: [acc-0205]sync mainline kernel 5.5rc6 acc patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1861976 Title: [acc-0205]sync mainline kernel 5.5rc6 acc patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] acc patchset have merged into mainline 5.5rc6 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon - fix spelling mistake "disgest" -> "digest" crypto: hisilicon - add branch prediction macro crypto: hisilicon - adjust hpre_crt_para_get crypto: hisilicon - Fixed some tiny bugs of HPRE crypto: hisilicon - Bugfixed tfm leak crypto: hisilicon - Add aead support on SEC2 crypto: hisilicon - redefine skcipher initiation crypto: hisilicon - Add branch prediction macro crypto: hisilicon - Add callback error check crypto: hisilicon - Adjust some inner logic crypto: hisilicon - Update QP resources of SEC V2 crypto: hisilicon - Update some names on SEC V2 crypto: hisilicon - fix print/comment of SEC V2 crypto: hisilicon - Update debugfs usage of SEC V2 To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1861976/+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 1867586] Re: [hns3-0316]sync mainline kernel 5.6rc4 hns3 patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1867586 Title: [hns3-0316]sync mainline kernel 5.6rc4 hns3 patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] hns3 patchset have merged into mainline 5.6rc1 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] net: hns3: clear port base VLAN when unload PF net: hns3: fix RMW issue for VLAN filter switch net: hns3: fix VF VLAN table entries inconsistent issue net: hns3: fix "tc qdisc del" failed issue net: hns3: reject unsupported coalescing params net: hns3: delete unnecessary logs after kzalloc fails net: hns3: synchronize some print relating to reset issue net: hns3: print out command code when dump fails in debugfs net: hns3: print out status register when VF receives unknown source interrupt net: hns3: add a check before PF inform VF to reset net: hns3: delete some reduandant code net: hns3: remove an unnecessary resetting check in hclge_handle_hw_ras_error() net: hns3: rename macro HCLGE_MAX_NCL_CONFIG_LENGTH net: hns3: fix some mixed type assignment net: hns3: fix a not link up issue when fibre port supports autoneg net: hns3: add missing help info for QS shaper in debugfs net: hns3: add support for dump MAC ID and loopback status in debugfs net: hns3: add enabled TC numbers and DWRR weight info in debugfs net: hns3: modify an unsuitable print when setting unknown duplex to fibre [Status] (Rejected) net: hns3: reject unsupported coalescing params (Fix committed) net: hns3: delete unnecessary logs after kzalloc fails (Fix committed) net: hns3: synchronize some print relating to reset issue (Fix committed) net: hns3: print out command code when dump fails in debugfs (Fix committed) net: hns3: print out status register when VF receives unknown source interrupt (Fix committed) net: hns3: add a check before PF inform VF to reset (Fix committed) net: hns3: delete some reduandant code (Fix committed) net: hns3: remove an unnecessary resetting check in hclge_handle_hw_ras_error() (Fix committed) net: hns3: rename macro HCLGE_MAX_NCL_CONFIG_LENGTH (Fix committed) net: hns3: fix some mixed type assignment (Fix committed) net: hns3: add missing help info for QS shaper in debugfs (Fix committed) net: hns3: add support for dump MAC ID and loopback status in debugfs (Fix committed) net: hns3: add enabled TC numbers and DWRR weight info in debugfs (Fix committed) net: hns3: modify an unsuitable print when setting unknown duplex to fibre (Fix committed) net: hns3: clear port base VLAN when unload PF (Fix committed) net: hns3: fix RMW issue for VLAN filter switch (Fix committed) net: hns3: fix VF VLAN table entries inconsistent issue (Fix committed) net: hns3: fix "tc qdisc del" failed issue (Fix committed) net: hns3: fix a not link up issue when fibre port supports autoneg To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867586/+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 1864950] Re: [roce-0227]sync mainline kernel 5.6rc3 roce patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1864950 Title: [roce-0227]sync mainline kernel 5.6rc3 roce patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] RDMA/hns: Optimize eqe buffer allocation flow RDMA/hns: Cleanups of magic numbers RDMA/hns: fix spelling mistake: "attatch" -> "attach" RDMA/hns: Delayed flush cqe process with workqueue RDMA/hns: Add the workqueue framework for flush cqe handler RDMA/hns: Initialize all fields of doorbells to zero RDMA/hns: Optimize qp doorbell allocation flow RDMA/hns: Optimize kernel qp wrid allocation flow RDMA/hns: Optimize qp param setup flow RDMA/hns: Optimize qp buffer allocation flow RDMA/hns: Optimize qp number assign flow RDMA/hns: Optimize qp context create and destroy flow RDMA/hns: Optimize qp destroy flow RDMA/hns: Stop doorbell update while qp state error RDMA/hns: Use flush framework for the case in aeq RDMA/hns: Treat revision HIP08_A as a special case https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=wip /jgg-for-next RDMA/hns: Treat revision HIP08_A as a special case https://www.spinics.net/lists/linux-rdma/msg89428.html RDMA/hns: Support to set mininum depth of qp to 0 https://patchwork.kernel.org/patch/11415067/ To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1864950/+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 1863575] Re: [hns3-0217]sync mainline kernel 5.6rc1 hns3 patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1863575 Title: [hns3-0217]sync mainline kernel 5.6rc1 hns3 patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] hns3 patchset have merged into mainline 5.6rc1 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] net: hns3: fix a copying IPv6 address error in hclge_fd_get_flow_tuples() net: hns3: fix VF bandwidth does not take effect in some case net: hns3: add management table after IMP reset [Status] (Fix committed) 47327c9315b2 net: hns3: fix a copying IPv6 address error in hclge_fd_get_flow_tuples() (Fix committed) 19eb1123b4e9 net: hns3: fix VF bandwidth does not take effect in some case (Fix committed) d0db7ed39751 net: hns3: add management table after IMP reset To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1863575/+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 1867587] Re: [sas-0316]sync mainline kernel 5.6rc1 sas patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1867587 Title: [sas-0316]sync mainline kernel 5.6rc1 sas patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] SAS patchset have merged into mainline 5.6rc1 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] scsi: hisi_sas: Rename hisi_sas_cq.pci_irq_mask scsi: hisi_sas: Add prints for v3 hw interrupt converge and automatic affinity scsi: hisi_sas: Modify the file permissions of trigger_dump to write only scsi: hisi_sas: Replace magic number when handle channel interrupt scsi: hisi_sas: replace spin_lock_irqsave/spin_unlock_restore with spin_lock/spin_unlock scsi: hisi_sas: use threaded irq to process CQ interrupts To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867587/+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 1861972] Re: [hns3-0205]sync mainline kernel 5.5rc7 hns3 patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1861972 Title: [hns3-0205]sync mainline kernel 5.5rc7 hns3 patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] hns3 patchset have merged into mainline 5.4rc7 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] (Fix committed) net: hns3: cleanup some coding style issue (Fix committed) net: hns3: remove redundant print on ENOMEM (Fix committed) net: hns3: delete unnecessary blank line and space for cleanup (Fix committed) net: hns3: rewrite a log in hclge_put_vector() (Fix committed) net: hns3: refine the input parameter 'size' for snprintf() (Fix committed) net: hns3: move duplicated macro definition into header (Fix committed) net: hns3: set VF's default reset_type to HNAE3_NONE_RESET (Fix committed) net: hns3: do not reuse pfmemalloc pages (Fix committed) net: hns3: limit the error logging in the hns3_clean_tx_ring() (Fix committed) net: hns3: replace snprintf with scnprintf in hns3_update_strings (Fix committed) net: hns3: replace snprintf with scnprintf in hns3_dbg_cmd_read (Fix committed) net: hns3: pad the short frame before sending to the hardware To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1861972/+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 1864442] Re: dmaengine: hisilicon: Add Kunpeng DMA engine support
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1864442 Title: dmaengine: hisilicon: Add Kunpeng DMA engine support Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] This patch adds a driver for HiSilicon Kunpeng DMA engine. This DMA engine which is an PCIe iEP offers 30 channels, each channel has a send queue, a complete queue and an interrupt to help to do tasks. This DMA engine can do memory copy between memory blocks or between memory and device buffer [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] e9f08b65250d dmaengine: hisilicon: Add Kunpeng DMA engine support https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma?h=v5.6-rc1=e9f08b65250d73ab70e79e194813f52b8d306784 To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1864442/+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 1867588] Re: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1867588 Title: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] SFC patchset have merged into mainline 5.7RC1rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override bits spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modes spi: Allow SPI controller override device buswidth To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867588/+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 1860401] Re: [sfc-0121]enable the HiSilicon v3xx SFC driver
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1860401 Title: [sfc-0121]enable the HiSilicon v3xx SFC driver Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] enable the HiSilicon v3xx SFC driver [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] MAINTAINERS: Add a maintainer for the HiSilicon v3xx SFC driver spi: Add HiSilicon v3xx SPI NOR flash controller driver mtd: spi-nor: Fix the writing of the Status Register on micron flashes To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1860401/+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 1853983] Re: [hns-1126]net: hns3: revert to old channel when setting new channel num fail
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853983 Title: [hns-1126]net: hns3: revert to old channel when setting new channel num fail Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] With specific ethtool commands, ethernet does not work [Test Case] run VF on VM with 3G memory and load VF driver ethtool -G eth0 tx 3 rx 3 ethtool -G eth0 tx 24 rx 24；ethtool -L eth0 combined 1 ethtool -G eth0 tx 32760 rx 32760 ethtool -L eth0 combined 32 ethernet shall still be functional after these commands [Fix] 3a5a5f06d4d2 net: hns3: revert to old channel when setting new channel num fail [Regression Risk] Patch restricted to hns3 driver. "[Bug Description] After setting new channel num, it needs free old ring memory and allocate new ring memory. If there is no enough memory and allocate new ring memory fail, the ring may initialize fail. To make sure the network interface can work normally, driver should revert the channel to the old configuration. [Steps to Reproduce] 1.run VF on VM with 3G memory 2.load VF driver 3.ethtool -G eth0 tx 3 rx 3 4.ethtool -G eth0 tx 24 rx 24；ethtool -L eth0 combined 1 5.ethtool -G eth0 tx 32760 rx 32760 6.ethtool -L eth0 combined 32 7.ping [Actual Results] netdevice can not work [Expected Results] ping ok [Reproducibility] Inevitably [Additional information] Hardware: D06 Firmware: NA Kernel: NA [Resolution] Revert the channel to the old configuration when allocate new ring memory fail." To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1853983/+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 1853992] Re: [sas-1126]scsi: hisi_sas: Fix out of bound at debug_I_T_nexus_reset()
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853992 Title: [sas-1126]scsi: hisi_sas: Fix out of bound at debug_I_T_nexus_reset() Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Potential NULL-pointer dereference. [Test Case] No known test case, but the issue is clear from code reading. [Fix] 445ee2de112a scsi: hisi_sas: Fix out of bound at debug_I_T_nexus_reset() [Regression Risk] Patch restricted to hisi_sas driver. [Bug Description] sas kasan test will produce this out bounds in sas module [Steps to Reproduce] 1) enbale this kasn 2) 3) [Actual Results] 30293.504016] sas: ata464: end_device-2:2:6: dev error handler [30293.504041] sas: ata465: end_device-2:2:7: dev error handler [30293.504059] sas: ata466: end_device-2:2:8: dev error handler [30293.538746] == [30293.550672] BUG: KASAN: slab-out-of-bounds in hisi_sas_debug_I_T_nexus_reset+0xcc/0x250 [30293.558642] Read of size 8 at addr b72e47233540 by task kworker/u193:3/79165 [30293.566004] [30293.567498] CPU: 14 PID: 79165 Comm: kworker/u193:3 Tainted: GB O 5.1.0-rc1-g7a3fab8-dirty #1 [30293.577196] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B010.01 06/21/2019 [30293.586037] Workqueue: events_unbound async_run_entry_fn [30293.591331] Call trace: [30293.593770] dump_backtrace+0x0/0x1f8 [30293.597419] show_stack+0x14/0x20 [30293.600726] dump_stack+0xc4/0xfc [30293.604032] print_address_description+0x60/0x258 [30293.608716] kasan_report+0x164/0x1b8 [30293.612366] __asan_load8+0x84/0xa8 [30293.615842] hisi_sas_debug_I_T_nexus_reset+0xcc/0x250 [30293.620961] hisi_sas_I_T_nexus_reset+0xc4/0x170 [30293.625562] sas_ata_hard_reset+0x88/0x178 [30293.629646] ata_do_reset.constprop.6+0x80/0x90 [30293.634160] ata_eh_reset+0x71c/0x10e8 [30293.637897] ata_eh_recover+0x3d0/0x1a80 [30293.641804] ata_do_eh+0x50/0xd0 [30293.645020] ata_std_error_handler+0x78/0xa8 [30293.649273] ata_scsi_port_error_handler+0x288/0x930 [30293.654216] async_sas_ata_eh+0x68/0x90 [30293.658040] async_run_entry_fn+0x7c/0x1c0 [30293.662121] process_one_work+0x3c0/0x878 [30293.666115] worker_thread+0x70/0x670 [30293.669762] kthread+0x1b0/0x1b8 [30293.672978] ret_from_fork+0x10/0x18 [30293.676541] [30293.678027] Allocated by task 16690: [30293.681593] __kasan_kmalloc.isra.0+0xd4/0x188 [30293.686018] kasan_kmalloc+0xc/0x18 [30293.689496] __kmalloc_node_track_caller+0x5c/0x98 [30293.694270] devm_kmalloc+0x44/0xb8 [30293.697746] hisi_sas_v3_probe+0x2ec/0x698 [30293.701828] local_pci_probe+0x74/0xf0 [30293.705562] work_for_cpu_fn+0x2c/0x48 [30293.709300] process_one_work+0x3c0/0x878 [30293.713294] worker_thread+0x400/0x670 [30293.717027] kthread+0x1b0/0x1b8 [30293.720241] ret_from_fork+0x10/0x18 [30293.723801] [30293.725287] Freed by task 16227: [30293.728503] __kasan_slab_free+0x108/0x210 [30293.732583] kasan_slab_free+0x10/0x18 [30293.736318] kfree+0x74/0x150 [30293.739276] devres_free+0x34/0x48 [30293.742665] devres_release+0x38/0x60 [30293.746313] devm_pinctrl_put+0x34/0x58 [30293.750136] pinctrl_bind_pins+0x164/0x248 [30293.754214] really_probe+0xc0/0x3b0 [30293.75] driver_probe_device+0x70/0x138 [30293.761944] __device_attach_driver+0xc0/0xe0 [30293.766285] bus_for_each_drv+0xcc/0x150 [30293.770194] __device_attach+0x154/0x1c0 [30293.774101] device_initial_probe+0x10/0x18 [30293.778270] bus_probe_device+0xec/0x100 [30293.782178] device_add+0x5f8/0x9b8 [30293.785658] scsi_sysfs_add_sdev+0xa4/0x310 [30293.789825] scsi_probe_and_add_lun+0xe60/0x1240 [30293.794425] __scsi_scan_target+0x1ac/0x780 [30293.798591] scsi_scan_target+0x134/0x140 [30293.802586] sas_rphy_add+0x1fc/0x2c8 [30293.806234] sas_probe_devices+0x10c/0x1e8 [30293.810313] sas_discover_domain+0x754/0x998 [30293.814567] process_one_work+0x3c0/0x878 [30293.818560] worker_thread+0x70/0x670 [30293.822207] kthread+0x1b0/0x1b8 [30293.825423] ret_from_fork+0x10/0x18
[Kernel-packages] [Bug 1853993] Re: [hns-1126]scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853993 Title: [hns-1126]scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Invalid Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Disks will be lost on SAS interface reset [Fix] scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device [Test] Resetting SAS interfaces shall not lose any disks [Regression Potential] Patch only for hisi_sas. Lowest risk for other platform/driver. "[Steps to Reproduce] 1. Close all the PHYS; 2. Inject error; 3. Open one PHY; [Actual Results] Some disk will be lost [Expected Results] No disk will be lost [Reproducibility] occasionally [Additional information] Hardware: D06 CS Firmware: NA Kernel: NA [Resolution] When init device for SAS disks, it will send TMF IO to clear disks. At that time TMF IO is broken by some operations such as injecting controller reset from HW RAs event, the TMF IO will be timeout, and at last device will be gone. Print is as followed: hisi_sas_v3_hw :74:02.0: dev[240:1] found ... hisi_sas_v3_hw :74:02.0: controller resetting... hisi_sas_v3_hw :74:02.0: phyup: phy7 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy0 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy1 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy2 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy3 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy6 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy5 link_rate=11 hisi_sas_v3_hw :74:02.0: phyup: phy4 link_rate=11 hisi_sas_v3_hw :74:02.0: controller reset complete hisi_sas_v3_hw :74:02.0: abort tmf: TMF task timeout and not done hisi_sas_v3_hw :74:02.0: dev[240:1] is gone sas: driver on host :74:02.0 cannot handle device 5000c500a75a860d, error:5 To improve the reliability, retry TMF IO max of 3 times for SAS disks which is the same as softreset does." scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1853993/+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 1853995] Re: [sas-1126]scsi: hisi_sas: Assign NCQ tag for all NCQ commands
** Changed in: kunpeng920/ubuntu-20.04
Status: Fix Committed => Fix Released
--
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/1853995
Title:
[sas-1126]scsi: hisi_sas: Assign NCQ tag for all NCQ commands
Status in kunpeng920:
Fix Committed
Status in kunpeng920 ubuntu-18.04 series:
Fix Released
Status in kunpeng920 ubuntu-18.04-hwe series:
Fix Released
Status in kunpeng920 ubuntu-19.04 series:
Fix Released
Status in kunpeng920 ubuntu-19.10 series:
Fix Released
Status in kunpeng920 ubuntu-20.04 series:
Fix Released
Status in kunpeng920 upstream-kernel series:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Disco:
Fix Released
Status in linux source package in Eoan:
Fix Released
Status in linux source package in Focal:
Fix Released
Bug description:
[Impact]
I/O error on blank Samsung SSD
[Test Case]
mkfs.ext4 on SSDs generates no I/O error
[Fix]
435a05cf8c00 scsi: hisi_sas: Assign NCQ tag for all NCQ commands
[Regression Risk]
Patch restricted to hisi_sas driver.
"[Steps to Reproduce]
mkfs.ext4 to the special SAMSUNG M27LH960, and some IO error
[Actual Results]
Io error when the first time of mkfs.ext4
[ 745.809462] hisi_sas_v3_hw :74:02.0: erroneous completion iptt=8
task=975f5cdf dev id=1 CQ hdr: 0x41d03 0x10008 0x1 0x446 Error
info: 0x0 0x0 0x1 0x0
[ 776.028794] sas: Enter sas_scsi_recover_host busy: 2 failed: 2
[ 776.034612] sas: trying to find task 0x9656953a
[ 776.034613] sas: sas_scsi_find_task: aborting task 0x9656953a
[ 776.042785] sas: sas_scsi_find_task: task 0x9656953a is done
[ 776.042786] sas: sas_eh_handle_sas_errors: task 0x9656953a is done
[ 776.049635] sas: trying to find task 0x975f5cdf
[ 776.049636] sas: sas_scsi_find_task: aborting task 0x975f5cdf
[ 776.056053] sas: sas_scsi_find_task: task 0x975f5cdf is done
[ 776.056054] sas: sas_eh_handle_sas_errors: task 0x975f5cdf is done
[ 776.062900] sas: ata5: end_device-4:0: cmd error handler
[ 776.062914] sas: ata5: end_device-4:0: dev error handler
[ 776.062918] sas: ata6: end_device-4:1: dev error handler
[ 776.062920] ata5.00: exception Emask 0x0 SAct 0xc000 SErr 0x0 action
0x6 frozen
[ 776.062924] sas: ata7: end_device-4:2: dev error handler
[ 776.062926] sas: ata8: end_device-4:3: dev error handler
[ 776.070548] ata5.00: failed command: SEND FPDMA QUEUED
[ 776.075669] ata5.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 30 ncq
dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 776.090638] ata5.00: status: { DRDY }
[ 776.094290] ata5.00: failed command: SEND FPDMA QUEUED
[ 776.099410] ata5.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 31 ncq
dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 776.114399] ata5.00: status: { DRDY }
[ 776.118051] ata5: hard resetting link
[ 776.123198] hisi_sas_v3_hw :74:02.0: phydown: phy0 phy_state=0xfe
[ 776.129609] hisi_sas_v3_hw :74:02.0: ignore flutter phy0 down
[ 776.282642] hisi_sas_v3_hw :74:02.0: phyup: phy0 link_rate=10(sata)
[ 776.289236] sas: sas_form_port: phy0 belongs to port0 already(1)!
[ 776.451784] ata5.00: configured for UDMA/133
[ 776.456043] ata5.00: device reported invalid CHS sector 0
[ 776.461423] ata5.00: device reported invalid CHS sector 0
[ 776.466807] ata5: EH complete
[ 776.469773] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 2 tries: 1
[ 776.498528] hisi_sas_v3_hw :74:02.0: erroneous completion iptt=15
task=9656953a dev id=1 CQ hdr: 0x41d03 0x1000f 0x1 0x446 Error
info: 0x0 0x0 0x1 0x0
[ 806.740789] sas: Enter sas_scsi_recover_host busy: 2 failed: 2
[ 806.746604] sas: trying to find task 0x975f5cdf
[ 806.746605] sas: sas_scsi_find_task: aborting task 0x975f5cdf
[ 806.754732] sas: sas_scsi_find_task: task 0x975f5cdf is done
[ 806.754733] sas: sas_eh_handle_sas_errors: task 0x975f5cdf is done
[ 806.761582] sas: trying to find task 0x9656953a
[ 806.761584] sas: sas_scsi_find_task: aborting task 0x9656953a
[ 806.768002] sas: sas_scsi_find_task: task 0x9656953a is done
[ 806.768003] sas: sas_eh_handle_sas_errors: task 0x9656953a is done
[ 806.774852] sas: ata5: end_device-4:0: cmd error handler
[ 806.774864] sas: ata5: end_device-4:0: dev error handler
[ 806.774868] sas: ata6: end_device-4:1: dev error handler
[ 806.774870] ata5.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6
frozen
[ 806.774873] ata5.00: failed command: SEND FPDMA QUEUED
[ 806.774875] sas: ata7: end_device-4:2: dev error handler
[
[Kernel-packages] [Bug 1853997] Re: [sas-1126]scsi: hisi_sas: Fix the conflict between device gone and host reset
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853997 Title: [sas-1126]scsi: hisi_sas: Fix the conflict between device gone and host reset Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Some SAS devices is gone when recovering [Test Case] No known test case, stress test on SAS deivce. [Fix] e74006edd0d4 scsi: hisi_sas: Fix the conflict between device gone and host reset [Regression Risk] Patch restricted to hisi_sas driver. "[Steps to Reproduce] 1. Close all the PHYS; 2. Inject error; 3. Open one PHY; [Actual Results] Some disk will be lost [Expected Results] No disk will be lost [Reproducibility] occasionally [Additional information] Hardware: D06 CS Firmware: NA+I59 Kernel: NA [Resolution] When init device for SAS disks, it will send TMF IO to clear disks. At that time TMF IO is broken by some operations such as injecting controller reset from HW RAs event, the TMF IO will be timeout, and at last device will be gone. Print is as followed: hisi_sas_v3_hw :74:02.0: dev[240:1] found ... hisi_sas_v3_hw :74:02.0: controller resetting... hisi_sas_v3_hw :74:02.0: phyup: phy7 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy0 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy1 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy2 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy3 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy6 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy5 link_rate=11 hisi_sas_v3_hw :74:02.0: phyup: phy4 link_rate=11 hisi_sas_v3_hw :74:02.0: controller reset complete hisi_sas_v3_hw :74:02.0: abort tmf: TMF task timeout and not done hisi_sas_v3_hw :74:02.0: dev[240:1] is gone sas: driver on host :74:02.0 cannot handle device 5000c500a75a860d, error:5 To improve the reliability, retry TMF IO max of 3 times for SAS disks which is the same as softreset does." scsi: hisi_sas: Fix the conflict between device gone and host reset To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1853997/+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 1850117] Re: [hpre-1017]sync mainline kernel 5.4rc3 hpre patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1850117 Title: [hpre-1017]sync mainline kernel 5.4rc3 hpre patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Eoan: Invalid Status in linux source package in Focal: Fix Released Bug description: [Bug Description] hpre patchset have merged into mainline 5.4rc3 kernel. Can use this hpre patchset to release UOSE basing this ubuntu 18.04.4 kernel branch, then merge into ubuntu 18.04.4 version. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon - add HiSilicon HPRE accelerator crypto: hisilicon - add SRIOV support for HPRE Documentation: Add debugfs doc for hisi_hpre crypto: hisilicon: Add debugfs for HPRE MAINTAINERS: Add maintainer for HiSilicon HPRE driver https://www.mail-archive.com/linux- cry...@vger.kernel.org/msg40969.html To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1850117/+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 1853984] Re: [hns-1126]net: hns3: fix port setting handle for fibre port
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853984 Title: [hns-1126]net: hns3: fix port setting handle for fibre port Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Invalid Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] For hardware doesn't support use specified speed and duplex to negotiate, it's unnecessary to check and modify the port speed and duplex for fibre port when autoneg is on. [Test Case] `sudo ethtool -s eno1 autoneg off speed 10 duplex full` `sudo ethtool -s eno1 autoneg on` commands shall return 0 [Fix] 24283ece5a0f net: hns3: fix port setting handle for fibre port [Regression Risk] Patch restricted to hns3 driver. "[Bug Description] For hardware doesn't support use specified speed and duplex to negotiate, it's unnecessary to check and modify the port speed and duplex for fibre port when autoneg is on. [Steps to Reproduce] 1.ethtool -s eth* autoneg off speed 10 duplex full 2.ethtool -s eth* autoneg on [Actual Results] set autoneg on fail [Expected Results] set autoneg on ok [Reproducibility] Inevitably [Additional information] Hardware: D06 Firmware: NA Kernel: NA [Resolution] Not check and modify the port speed and duplex for fibre port when autoneg on." net: hns3: fix port setting handle for fibre port To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1853984/+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 1853989] Re: [roce-1126]RDMA/hns: bugfix for slab-out-of-bounds when loading hip08 driver
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1853989 Title: [roce-1126]RDMA/hns: bugfix for slab-out-of-bounds when loading hip08 driver Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Bug description: [Impact] KASAN reports slab-out-of-bounds in RDMA/hns driver [Testcase] Enable KASAN and modprobe RDMA/hns driver [Regression Risk] Only RDMA/hns driver modified. lowest risk to other drivers/platforms [Bug Description] KASAN: slab-out-of-bounds in hns_roce_table_mhop_put+0x584/0x828 [hns_roce] Read of size 8 at addr 802185e08300 by task rmmod/270 Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xc4/0xfc print_address_description+0x60/0x270 __kasan_report+0x164/0x1b8 kasan_report+0xc/0x18 __asan_load8+0x84/0xa8 hns_roce_table_mhop_put+0x584/0x828 [hns_roce] hns_roce_table_put+0x174/0x1a0 [hns_roce] hns_roce_mr_free+0x124/0x210 [hns_roce] hns_roce_dereg_mr+0x90/0xb8 [hns_roce] ib_dealloc_pd_user+0x60/0xf0 ib_mad_port_close+0x128/0x1d8 ib_mad_remove_device+0x94/0x118 remove_client_context+0xa0/0xe0 disable_device+0xfc/0x1c0 __ib_unregister_device+0x60/0xe0 ib_unregister_device+0x24/0x38 hns_roce_exit+0x3c/0x138 [hns_roce] __hns_roce_hw_v2_uninit_instance.isra.30+0x28/0x50 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance+0x44/0x60 [hns_roce_hw_v2] hclge_uninit_client_instance+0x15c/0x238 [hclge] hnae3_uninit_client_instance+0x84/0xa8 [hnae3] hnae3_unregister_client+0x84/0x158 [hnae3] hns_roce_hw_v2_exit+0x14/0x20 [hns_roce_hw_v2] __arm64_sys_delete_module+0x20c/0x308 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Allocated by task 255: __kasan_kmalloc.isra.0+0xd0/0x180 kasan_kmalloc+0xc/0x18 __kmalloc+0x16c/0x328 hns_roce_init_hem_table+0x20c/0x428 [hns_roce] hns_roce_init+0x214/0xfe0 [hns_roce] __hns_roce_hw_v2_init_instance+0x284/0x330 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0xd0/0x1b8 [hns_roce_hw_v2] hclge_init_roce_client_instance+0x180/0x310 [hclge] hclge_init_client_instance+0xcc/0x508 [hclge] hnae3_init_client_instance.part.3+0x3c/0x80 [hnae3] hnae3_register_client+0x134/0x1a8 [hnae3] 0x29c00014 do_one_initcall+0x9c/0x3e0 do_init_module+0xd4/0x2d8 load_module+0x3284/0x3690 __se_sys_init_module+0x274/0x308 __arm64_sys_init_module+0x40/0x50 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Freed by task 0: (stack is not available) The buggy address belongs to the object at 802185e06300 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes to the right of 8192-byte region [802185e06300, 802185e08300) The buggy address belongs to the page: page:7fe008617800 refcount:1 mapcount:0 mapping:802340020e00 index:0x0 compound_mapcount: 0 flags: 0x5fffe0010200(slab|head) raw: 5fffe0010200 dead0100 dead0200 802340020e00 raw: 803e003e 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 802185e08200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 802185e08280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >802185e08300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 802185e08380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 802185e08400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == Disabling lock debugging due to kernel taint [Steps to Reproduce] Enable KASAN and configure PAGE_SIZE to 64K, insmod hns roce driver and then rmmod it. [Actual Results] Call trace because of slab-out-of-bound. [Expected Results] Success [Reproducibility] Inevitably [Additional information] Hardware: D06 CS Firmware: NA Kernel: NA [Resolution] Not configure eq->next when number of eq_buf is 1 in
[Kernel-packages] [Bug 1853964] Re: [hns-1126]net: hns3: make hclge_service use delayed workqueue
** Changed in: kunpeng920/ubuntu-20.04
Status: Fix Committed => Fix Released
--
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/1853964
Title:
[hns-1126]net: hns3: make hclge_service use delayed workqueue
Status in kunpeng920:
Fix Committed
Status in kunpeng920 ubuntu-18.04 series:
Won't Fix
Status in kunpeng920 ubuntu-18.04-hwe series:
Fix Released
Status in kunpeng920 ubuntu-19.10 series:
Fix Released
Status in kunpeng920 ubuntu-20.04 series:
Fix Released
Status in kunpeng920 upstream-kernel series:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Eoan:
Fix Released
Bug description:
[Impact]
System crashes when setting irq affinity and turning on/off on the interfaces
[Fix]
net: hns3: make hclge_service use delayed workqueue
[Test]
Writing smp_affinity_list and turning on/off in loop
[Regression Potential]
This patch only for hns3. Lowest risk for other platform/driver
"[Bug Description]
Currently, up/down port process may concurrently operate
timer(del_timer_sync/add_timer_on) with setting IRQ affinity, and cause system
breaking down.
[Steps to Reproduce]
set misc irp affinity of PF during up/down port by follow script:
while((1))
do
for i in {0..31}; do echo $i > /proc/irq/678/smp_affinity_list; done
done
while((1))
do
ifconfig eth4 down
ifconfig eth4 up
done
[Actual Results]
System break down.
kernel call trace
[Expected Results]
System run normally.
[Reproducibility]
Inevitably
[Additional information]
Hardware: D06
Firmware: NA
Kernel: NA
[Resolution]
This patch uses delayed work instead of using timers to trigger the
hclge_serive."
To manage notifications about this bug go to:
https://bugs.launchpad.net/kunpeng920/+bug/1853964/+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 1853999] Re: [sas-1126]scsi: hisi_sas: use wait_for_completion_timeout() when clearing ITCT
** Changed in: kunpeng920/ubuntu-20.04
Status: Fix Committed => Fix Released
--
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/1853999
Title:
[sas-1126]scsi: hisi_sas: use wait_for_completion_timeout() when
clearing ITCT
Status in kunpeng920:
Fix Committed
Status in kunpeng920 ubuntu-18.04 series:
Won't Fix
Status in kunpeng920 ubuntu-18.04-hwe series:
Fix Committed
Status in kunpeng920 ubuntu-19.04 series:
Won't Fix
Status in kunpeng920 ubuntu-19.10 series:
Won't Fix
Status in kunpeng920 ubuntu-20.04 series:
Fix Released
Status in kunpeng920 upstream-kernel series:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Bug description:
"[Steps to Reproduce]
1. Close all the PHYS;
2. Inject error;
3. Open one PHY;
[Actual Results]
System is suspended
HGC_DQE_POISON_INTR
[ 2511.679429] hisi_sas_v3_hw :74:02.0: phydown: phy0 phy_state=0xfe
[ 2511.685869] hisi_sas_v3_hw :74:02.0: phydown: phy1 phy_state=0x0
[ 2511.685953] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.692213] hisi_sas_v3_hw :74:02.0: phydown: phy2 phy_state=0x0
[ 2511.692218] hisi_sas_v3_hw :74:02.0: phydown: phy3 phy_state=0x0
[ 2511.697262] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.703594] hisi_sas_v3_hw :74:02.0: phydown: phy4 phy_state=0x0
[ 2511.703598] hisi_sas_v3_hw :74:02.0: phydown: phy5 phy_state=0x0
[ 2511.709940] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.717234] hisi_sas_v3_hw :74:02.0: phydown: phy6 phy_state=0x0
[ 2511.717239] hisi_sas_v3_hw :74:02.0: phydown: phy7 phy_state=0x0
[ 2511.740405] hisi_sas_v3_hw :74:02.0: phyup: phy6 link_rate=11
[ 2511.742338] sas: executing SMP task failed:-70
[ 2511.759194] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.764686] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.769731] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.777033] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.783033] sas: executing SMP task failed:-70
[ 2511.787467] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.792954] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.797997] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.805295] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.811291] sas: executing SMP task failed:-70
[ 2511.815727] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.821212] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.826256] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.833555] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.839553] sas: executing SMP task failed:-70
[ 2511.843986] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.849474] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.854518] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.861817] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.867814] sas: executing SMP task failed:-70
[ 2511.872248] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.877734] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.882780] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.890079] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.896076] sas: executing SMP task failed:-70
[ 2511.900510] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.905997] sas: REVALIDATING DOMAIN on port 0, pid:7
[ 2511.911042] hisi_sas_v3_hw :74:02.0: task prep: SAS port0 not attach
device
[ 2511.918341] hisi_sas_v3_hw :74:02.0: task exec: failed[-70]!
[ 2511.924338] sas: executing SMP task failed:-70
[ 2511.928771] sas: done REVALIDATING DOMAIN on port 0, pid:7
[ 2511.935668] hisi_sas_v3_hw :74:02.0: dev[29:1] is gone
[ 2511.941163] hisi_sas_v3_hw :74:02.0: DQE_AXI_R_ERR error (0x40800)
found!
[ 2511.941173] arm-smmu-v3 arm-smmu-v3.3.auto: event 0x10 received:
[ 2512.003017] {91}[Hardware Error]: Hardware error from APEI Generic
Hardware Error Source: 0
[ 2512.003019] {91}[Hardware Error]: event severity: recoverable
[ 2512.003021] {91}[Hardware Error]: Error 0, type: recoverable
[ 2512.003022] {91}[Hardware Error]: section type: unknown,
1f8161e1-55d6-41e6-bd10-7afd1dc5f7c5
[ 2512.003023] {91}[Hardware Error]: section length: 0x28
[ 2512.003026] {91}[Hardware Error]: : 03ff 0100 000f
[ 2512.003027] {91}[Hardware Error]: 0010: 0010 0004
[ 2512.003028] {91}[Hardware Error]: 0020:
[ 2512.005832] hisi_sas_v3_hw :74:02.0: read dqe poison error (0x40800)
found!
[ 2512.005837] hisi_sas_v3_hw :74:02.0: controller
[Kernel-packages] [Bug 1854547] Re: 【sas-1130】scsi: sd: define variable dif as unsigned int instead of bool
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1854547 Title: 【sas-1130】scsi: sd: define variable dif as unsigned int instead of bool Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Invalid Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Invalid Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Bug Description] DIF3 WILL not work when run fio test 【Steps to Reproduce] 1. Enable DIF/DIX for DIF3 disk 2. fio test [Actual Results] IO error when running IO; [ 781.032816] sd 5:0:0:0: [sdd] Disabling DIF Type 3 protection [ 781.112250] sd 5:0:0:0: [sdd] tag#72 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.112287] sd 5:0:0:0: [sdd] tag#72 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.112305] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.118429] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.204243] sd 5:0:0:0: [sdd] tag#77 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.204252] sd 5:0:0:0: [sdd] tag#77 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.204257] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.210365] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.296238] sd 5:0:0:0: [sdd] tag#82 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.296266] sd 5:0:0:0: [sdd] tag#82 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.296276] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.302384] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.309207] ldm_validate_partition_table(): Disk read failed. [ 781.392239] sd 5:0:0:0: [sdd] tag#87 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.392267] sd 5:0:0:0: [sdd] tag#87 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.392278] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.398386] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.484250] sd 5:0:0:0: [sdd] tag#92 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.484260] sd 5:0:0:0: [sdd] tag#92 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.484264] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.490371] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.576249] sd 5:0:0:0: [sdd] tag#97 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.576278] sd 5:0:0:0: [sdd] tag#97 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.576293] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.582399] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.668236] sd 5:0:0:0: [sdd] tag#102 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.668245] sd 5:0:0:0: [sdd] tag#102 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.668249] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.674354] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.681184] Dev sdd: unable to read RDB block 0 [ 781.764241] sd 5:0:0:0: [sdd] tag#121 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.764267] sd 5:0:0:0: [sdd] tag#121 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.764278] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.770386] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.856240] sd 5:0:0:0: [sdd] tag#126 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.856248] sd 5:0:0:0: [sdd] tag#126 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 781.856253] print_req_error: I/O error, dev sdd, sector 0 flags 0 [ 781.862362] Buffer I/O error on dev sdd, logical block 0, async page read [ 781.948238] sd 5:0:0:0: [sdd] tag#131 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 781.948264] sd 5:0:0:0: [sdd] tag#131 CDB: Read(10) 28 00 00 00 00 18 00 00 08 00 [ 781.948272] print_req_error: I/O error, dev sdd, sector 24 flags 0 [ 781.954467] Buffer I/O error on dev sdd, logical block 3, async page read [ 782.120252] sdd: unable to read partition table [Expected Results] IO running normally [Reproducibility] occasionally [Additional information] Hardware: D06 CS Firmware: NA+I59 Kernel: NA [Resolution] Variable dif in function sd_setup_read_write_cmnd() is the return value of function scsi_host_dif_capable() which returns dif capability of disks. If
[Kernel-packages] [Bug 1854548] Re: [sas-1130]enable sas DFX Function for 1620 soc
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1854548 Title: [sas-1130]enable sas DFX Function for 1620 soc Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] enable sas DFX Function for 1620 soc [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] scsi: hisi_sas: Record the phy down event in debugfs scsi: hisi_sas: Delete the debugfs folder of hisi_sas when the probe fails scsi: hisi_sas: Add ability to have multiple debugfs dumps scsi: hisi_sas: Add module parameter for debugfs dump count scsi: hisi_sas: Allocate memory for multiple dumps of debugfs scsi: hisi_sas: Add debugfs file structure for ITCT cache scsi: hisi_sas: Add debugfs file structure for IOST cache scsi: hisi_sas: Add debugfs file structure for ITCT scsi: hisi_sas: Add debugfs file structure for IOST scsi: hisi_sas: Add debugfs file structure for port scsi: hisi_sas: Add debugfs file structure for registers scsi: hisi_sas: Add debugfs file structure for DQ scsi: hisi_sas: Add debugfs file structure for CQ scsi: hisi_sas: Add timestamp for a debugfs dump scsi: hisi_sas: Relocate call to hisi_sas_debugfs_exit() scsi: hisi_sas: Fix pointer usage error in show debugfs IOST/ITCT scsi: hisi_sas: Snapshot HW cache of IOST and ITCT at debugfs scsi: hisi_sas: Snapshot AXI and RAS register at debugfs scsi: hisi_sas: add debugfs auto-trigger for internal abort time out scsi: hisi_sas: Add BIST support for phy loopback scsi: hisi_sas: Add hisi_sas_debugfs_alloc() to centralise allocation scsi: hisi_sas: Set the BIST init value before enabling BIST scsi: hisi_sas: Don't create debugfs dump folder twice UPDATE: Include the following patch, as it is also debugfs related: scsi: hisi_sas: Relocate call to hisi_sas_debugfs_exit() To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1854548/+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 1859269] Re: [roce-0111]sync mainline kernel 5.5rc6 roce patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1859269 Title: [roce-0111]sync mainline kernel 5.5rc6 roce patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] roce patchset have merged into mainline 5.5rc6 kernel. Pls backport ubuntu 18.04.5 kernel version [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] RDMA/hns: Delete unnecessary callback functions for cq RDMA/hns: Rename the functions used inside creating cq RDMA/hns: Redefine the member of hns_roce_cq struct RDMA/hns: Redefine interfaces used in creating cq IB/umem: remove the dmasync argument to ib_umem_get RDMA/hns: Modify appropriate printings RDMA/hns: Fix non-standard error codes RDMA/hns: Modify hns_roce_hw_v2_get_cfg to simplify the code RDMA/hns: Simplify doorbell initialization code RDMA/hns: Replace not intuitive function/macro names RDMA/hns: Modify fields of struct hns_roce_srq RDMA/hns: Delete unnecessary uar from hns_roce_cq RDMA/hns: Remove unnecessary structure hns_roce_sqp RDMA/hns: Delete unnecessary variable max_post RDMA/hns: Remove unsupported modify_port callback RDMA: Connect between the mmap entry and the umap_priv structure RDMA/hns: Fix build error again RDMA/hns: Fix memory leak on 'context' on error return path RDMA/hns: Bugfix for qpc/cqc timer configuration RDMA/hns: Fix to support 64K page for srq RDMA/hns: Delete BITS_PER_BYTE redefinition RDMA/hns: Prevent undefined behavior in hns_roce_set_user_sq_size() RDMA/hns: Release qp resources when failed to destroy qp RDMA/hns: Fix a spelling mistake in a macro RDMA/hns: Modify return value of restrack functions RDMA/hns: Modify variable/field name from vlan to vlan_id RDMA/hns: Fix wrong parameters when initial mtt of srq->idx_que RDMA/hns: remove a redundant le16_to_cpu RDMA/hns: Prevent memory leaks of eq->buf_list RDMA/hns: Correct the value of srq_desc_size RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN RDMA/hns: Add support for reporting wc as software mode RDMA/hns: Bugfix for posting a wqe with sge RDMA/hns: Fix coding style issues RDMA/hns: Replace custom macros HNS_ROCE_ALIGN_UP RDMA/hns: Remove redundant print information RDMA/hns: Delete unnessary parameters in hns_roce_v2_qp_modify() RDMA/hns: Update the value of qp type RDMA/hns: Remove unused function hns_roce_init_eq_table() RDMA/hns: Avoid printing address of mtt page RDMA/hns: Simplify the calculation and usage of wqe idx for post verbs update 01120 RDMA/hns: Get pf capabilities from firmware RDMA/hns: Add interfaces to get pf capabilities from firmware RDMA/hns: Remove some redundant variables related to capabilities RDMA/hns: Add support for extended atomic in userspace [Status] (Fix committed): RDMA/hns: Delete unnecessary callback functions for cq (Fix committed): RDMA/hns: Rename the functions used inside creating cq (Fix committed): RDMA/hns: Redefine the member of hns_roce_cq struct (Fix committed): RDMA/hns: Redefine interfaces used in creating cq (Fix committed): IB/umem: remove the dmasync argument to ib_umem_get (Fix committed): RDMA/hns: Modify appropriate printings (Fix committed): RDMA/hns: Fix non-standard error codes (Fix committed): RDMA/hns: Modify hns_roce_hw_v2_get_cfg to simplify the code (Fix committed): RDMA/hns: Simplify doorbell initialization code (Fix committed): RDMA/hns: Replace not intuitive function/macro names (Fix committed): RDMA/hns: Modify fields of struct hns_roce_srq (Fix committed): RDMA/hns: Delete unnecessary uar from hns_roce_cq (Fix committed): RDMA/hns: Remove unnecessary structure hns_roce_sqp (Fix committed): RDMA/hns: Delete unnecessary variable max_post (Fix committed): RDMA/hns: Remove unsupported modify_port callback (Fix committed): RDMA: Connect between the mmap entry and the umap_priv structure (Fix committed): RDMA/hns: Fix build error again (Fix committed): RDMA/hns: Fix memory leak on 'context' on error return path (Fix committed): RDMA/hns: Bugfix for qpc/cqc timer configuration (Fix committed): RDMA/hns: Fix to support 64K page for srq (Fix committed): RDMA/hns: Delete BITS_PER_BYTE redefinition (Fix committed): RDMA/hns: Prevent undefined behavior in hns_roce_set_user_sq_size() (Fix committed): RDMA/hns: Release qp resources when failed to
[Kernel-packages] [Bug 1855952] Re: scsi: hisi_sas: Check sas_port before using it
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1855952 Title: scsi: hisi_sas: Check sas_port before using it Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Potential NULL-pointer dereference. [Test Case] No known test case, but the issue is clear from code reading. [Fix] 8c39673d5474b scsi: hisi_sas: Check sas_port before using it [Regression Risk] Patch restricted to hisi_sas driver. To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1855952/+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 1859261] Re: [hns3-0111]sync mainline kernel 5.5rc6 hns3 patchset into ubuntu HWE kernel branch Edit
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1859261 Title: [hns3-0111]sync mainline kernel 5.5rc6 hns3 patchset into ubuntu HWE kernel branch Edit Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] hns3 patchset have merged into mainline 5.4rc5 kernel. Pls backport ubuntu 18.04.5 kernel version [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] net: hns3: support tx-scatter-gather-fraglist feature net: hns3: add support for configuring VF MAC from the host net: hns3: add support for configuring bandwidth of VF on the host net: hns3: add support for setting VF trust net: hns3: add support for spoof check setting net: hns3: add support for setting VF link status on the host net: hns3: make array tick_array static, makes object smaller net: hns3: fix a wrong reset interrupt status mask net: hns3: cleanup of stray struct hns3_link_mode_mapping net: hns3: fix ETS bandwidth validation bug net: hns3: reallocate SSU' buffer size when pfc_en changes net: hns3: add compatible handling for MAC VLAN switch parameter configuration net: hns3: add compatible handling for command HCLGE_OPC_PF_RST_DONE net: hns3: remove unused macros net: hns3: Use the correct style for SPDX License Identifier net: hns3: cleanup byte order issues when printed net: hns3: cleanup some print format warning net: hns3: add or modify some comments net: hns3: optimize local variable initialization net: hns3: cleanup a format-truncation warning net: hns3: cleanup some coding style issues net: hns3: cleanup some magic numbers net: hns3: add struct netdev_queue debug info for TX timeout net: hns3: dump some debug information when reset fail treewide: Use sizeof_member() macro net: hns3: log and clear hardware error after reset complete net: hns3: do not allocate linear data for fraglist skb net: hns3: minor cleanup for hns3_handle_rx_bd() net: hns3: make struct hns3_enet_ring cacheline aligned net: hns3: introduce ring_to_netdev() in enet module net: hns3: minor optimization for barrier in IO path net: hns3: optimized MAC address in management table. net: hns3: remove struct hns3_nic_ring_data in hns3_enet module net: hns3: fix mis-counting IRQ vector numbers issue net: hns3: fix VF ID issue for setting VF VLAN net: hns3: fix a use after free problem in hns3_nic_maybe_stop_tx() net: hns3: fix for TX queue not restarted problem net: hns3: only print misc interrupt status when handling fails net: hns3: add a log for getting chain failure in hns3_nic_uninit_vector_data() net: hns3: add some VF VLAN information for command "ip link show" net: hns3: implement ndo_features_check ops for hns3 driver net: hns3: get FD rules location before dump in debugfs net: hns3: optimization for CMDQ uninitialization net: hns3: remove useless mutex vport_cfg_mutex in the struct hclge_dev net: hns3: check FE bit before calling hns3_add_frag() net: hns3: do not schedule the periodic task when reset fail net: hns3: allocate WQ with WQ_MEM_RECLAIM flag net: hns3: remove unnecessary work in hclgevf_main net: hns3: remove mailbox and reset work in hclge_main net: hns3: schedule hclgevf_service by using delayed workqueue net: hns3: refactor the notification scheme of PF reset net: hns3: refactor the procedure of VF FLR net: hns3: modify hclge_func_reset_sync_vf()'s return type to void net: hns3: enlarge HCLGE_RESET_WAIT_CNT net: hns3: refactor the precedure of PF FLR net: hns3: split hclgevf_reset() into preparing and rebuilding part net: hns3: split hclge_reset() into preparing and rebuilding part net: hns3: modify an unsuitable reset level for hardware error net: hns3: replace an unsuitable variable type in hclge_inform_reset_assert_to_vf() net: hns3: add protection when get SFP speed as 0 net: hns3: modify the IRQ name of misc vectors net: hns3: modify an unsuitable log in hclge_map_ring_to_vector() net: hns3: modify the IRQ name of TQP vector net: hns3: re-organize vector handle net: hns3: add trace event support for HNS3 driver update 0120 net: hns3: pad the short frame before sending to the hardware [Status] (Fix committed): net: hns3: support tx-scatter-gather-fraglist feature (Fix committed): net: hns3: add support for configuring VF MAC from the host (Fix committed): net: hns3: add support for
[Kernel-packages] [Bug 1855958] Re: scsi: hisi_sas: Return directly if init hardware failed
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1855958 Title: scsi: hisi_sas: Return directly if init hardware failed Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Invalid Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Invalid Status in kunpeng920 ubuntu-19.10 series: Invalid Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Impact] The 5.4 introduced a regression that could potentially lead to a crash during resume. [Test Case] Regression tested only. [Fix] 547fde8b5a192 scsi: hisi_sas: Return directly if init hardware failed [Regression Risk] Code change is restricted to the hisi_sas driver. To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1855958/+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 1854000] Re: [sas-1126]scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec()
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1854000 Title: [sas-1126]scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec() Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: "[Steps to Reproduce] 1. run fio 2“echo 1 > /sys/kernel/debug/hisi_sas/\:74\:02.0/trigger_dump” [Actual Results] [ 448.405504] CPU: 27 PID: 13560 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 [ 448.405506] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405507] Call trace: [ 448.405512] dump_backtrace+0x0/0x150 [ 448.405513] show_stack+0x24/0x30 [ 448.405516] dump_stack+0xa0/0xc4 [ 448.405518] __schedule_bug+0x68/0x88 [ 448.405520] __schedule+0x4b8/0x548 [ 448.405521] schedule+0x40/0xd0 [ 448.405523] schedule_timeout+0x200/0x378 [ 448.405524] __down+0x78/0xc8 [ 448.405526] down+0x54/0x70 [ 448.405533] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] f=11): [M(11)][1[ 448.405535] hisi_sas_queue_command+0x28/0x38 [hisi_sas_main] [ 448.405541] sas_queuecommand+0x168/0x1b0 [libsas] [ 448.405544] scsi_queue_rq+0x2ac/0x980 [ 448.405547] blk_mq_dispatch_rq_list+0xb0/0x550 [ 448.405548] blk_mq_do_dispatch_sched+0x6c/0x110 [ 448.405550] blk_mq_sched_dispatch_requests+0x114/0x1d8 [ 448.405551] __blk_mq_run_hw_queue+0xb8/0x130 [ 448.405552] __blk_mq_delay_run_hw_queue+0x1c0/0x220 [ 448.405553] blk_mq_run_hw_queue+0xb0/0x128 [ 448.405554] blk_mq_sched_insert_requests+0xdc/0x208 [ 448.40] blk_mq_flush_plug_list+0x1b4/0x3a0 [ 448.405557] blk_flush_plug_list+0xdc/0x110 [ 448.405558] blk_finish_plug+0x3c/0x50 [ 448.405560] blkdev_write_iter+0xc0/0x130 [ 448.405562] aio_write+0xec/0x1a0 [ 448.405563] io_submit_one+0x4f4/0x8d8 [ 448.405564] __arm64_sys_io_submit+0xdc/0x280 [ 448.405566] el0_svc_common.constprop.0+0xe0/0x1e0 [ 448.405567] el0_svc_handler+0x34/0x90 [ 448.405569] el0_svc+0x10/0x14 [ 448.405571] CPU: 26 PID: 13559 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 [ 448.405572] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405572] Call trace: [ 448.405574] dump_backtrace+0x0/0x150 [ 448.405575] show_stack+0x24/0x30 [ 448.405577] dump_stack+0xa0/0xc4 [ 448.405578] __schedule_bug+0x68/0x88 [ 448.405580] __schedule+0x4b8/0x548 [ 448.405581] schedule+0x40/0xd0 [ 448.405582] schedule_timeout+0x200/0x378 [ 448.405583] __down+0x78/0xc8 [ 448.405584] down+0x54/0x70 [ 448.405587] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] [ 448.405590] hisi_sas_queue_command+0x28/0x38 [hisi_sas_main] [ 448.405594] sas_queuecommand+0x168/0x1b0 [libsas] [ 448.405595] scsi_queue_rq+0x2ac/0x980 [ 448.405596] blk_mq_dispatch_rq_list+0xb0/0x550 [ 448.405598] blk_mq_do_dispatch_sched+0x6c/0x110 [ 448.405599] blk_mq_sched_dispatch_requests+0x114/0x1d8 [ 448.405600] __blk_mq_run_hw_queue+0xb8/0x130 [ 448.405601] __blk_mq_delay_run_hw_queue+0x1c0/0x220 [ 448.405602] blk_mq_run_hw_queue+0xb0/0x128 [ 448.405603] blk_mq_sched_insert_requests+0xdc/0x208 [ 448.405605] blk_mq_flush_plug_list+0x1b4/0x3a0 [ 448.405606] blk_flush_plug_list+0xdc/0x110 [ 448.405607] blk_finish_plug+0x3c/0x50 [ 448.405608] blkdev_write_iter+0xc0/0x130 [ 448.405610] aio_write+0xec/0x1a0 [ 448.405611] io_submit_one+0x4f4/0x8d8 [ 448.405612] __arm64_sys_io_submit+0xdc/0x280 [ 448.405614] el0_svc_common.constprop.0+0xe0/0x1e0 [ 448.405615] el0_svc_handler+0x34/0x90 [ 448.405616] el0_svc+0x10/0x14 [ 448.405620] CPU: 86 PID: 13534 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 1.7%][r=1163MiB/[ 448.405621] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405622] Call trace: [ 448.405625] dump_backtrace+0x0/0x150 [ 448.405626] show_stack+0x24/0x30 [ 448.405631] dump_stack+0xa0/0xc4 [ 448.405635] __schedule_bug+0x68/0x88 [ 448.405636] __schedule+0x4b8/0x548 [ 448.405637] schedule+0x40/0xd0 [ 448.405639] schedule_timeout+0x200/0x378 [ 448.405640] __down+0x78/0xc8 [ 448.405642] down+0x54/0x70 [ 448.405646] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] [ 448.405649]
[Kernel-packages] [Bug 1854549] Re: [acc-1130]sync mainline kernel 5.5rc1 acc patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1854549 Title: [acc-1130]sync mainline kernel 5.5rc1 acc patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] enable 1620 acc function for kunpeng 920 [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] MAINTAINERS: Add maintainer for HiSilicon trng V2 driver hw_random: add HiSilicon TRNG driver support MAINTAINERS: Add maintainer for HiSilicon SEC V2 driver crypto: hisilicon - add DebugFS for HiSilicon SEC Documentation: add DebugFS doc for HiSilicon SEC crypto: hisilicon - add SRIOV for HiSilicon SEC crypto: hisilicon - add HiSilicon SEC V2 driver crypto: hisilicon - use sgl API to get sgl dma addr and len crypto: hisilicon - replace #ifdef with IS_ENABLED for CONFIG_NUMA crypto: hisilicon - no need to check return value of debugfs_create functions crypto: hisilicon - fix to return sub-optimal device when best device has no qps crypto: hisilicon - add vfs_num module param for zip crypto: hisilicon - fix endianness verification problem of QM crypto: hisilicon - fix param should be static when not external. crypto: hisilicon - Fix using plain integer as NULL pointer crypto: hisilicon - tiny fix about QM/ZIP error callback print crypto: hisilicon: Fix misuse of GENMASK macro crypto: hisilicon - select NEED_SG_DMA_LENGTH in qm Kconfig crypto: hisilicon - misc fix about sgl crypto: hisilicon - fix large sgl memory allocation problem when disable smmu crypto: hisilicon - add sgl_sge_nr module param for zip crypto: hisilicon - merge sgl support to hisi_qm module crypto: hisilicon - allow compile-testing on x86 crypto: hisilicon - select CRYPTO_LIB_DES while compiling SEC driver To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1854549/+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 1854550] Re: [scsi-1130]scsi: scsi_transport_sas: Fix memory leak when removing devices
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1854550 Title: [scsi-1130]scsi: scsi_transport_sas: Fix memory leak when removing devices Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Invalid Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: [Impact] kmemleak detects potential leaks and this is the fix [Test Case] Not known case, regression test on system with SAS host is needed. [Fix] 82ea3e0e12 scsi: scsi_transport_sas: Fix memory leak when removing devices [Regression Risk] Patch is simple and reviewed on upstream. Since modification is for scsi subsystem not on a single driver, applying on focal gives us enough time for test. "[Steps to reproduce] Enable memleak, and do as follows: root@(none)$ echo 0 > /sys/devices/platform/HISI0162:01/host0/port-0:0/expander-0:0/port-0:0:10/phy-0:0:10/sas_phy/phy-0:0:10/enable [ 79.857888] hisi_sas_v2_hw HISI0162:01: dev[7:1] is gone root@(none)$ echo scan > /sys/kernel/debug/kmemleak [ 131.656603] kmemleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak) root@(none)$ more /sys/kernel/debug/kmemleak unreferenced object 0x041da5c66000 (size 256): comm ""kworker/u128:1"", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 5e c6 a5 1d 04 ff ff 01 00 00 00 00 00 00 00 .^.. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<(ptrval)>] kmem_cache_alloc+0x188/0x260 [<(ptrval)>] bsg_setup_queue+0x48/0x1a8 [<(ptrval)>] sas_rphy_add+0x108/0x2d0 [<(ptrval)>] sas_probe_devices+0x168/0x208 [<(ptrval)>] sas_discover_domain+0x660/0x9c8 [<(ptrval)>] process_one_work+0x3f8/0x690 [<(ptrval)>] worker_thread+0x70/0x6a0 [<(ptrval)>] kthread+0x1b8/0x1c0 [<(ptrval)>] ret_from_fork+0x10/0x18 unreferenced object 0x041d8c075400 (size 128): comm ""kworker/u128:1"", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 40 25 97 1d 00 ff ff 00 00 00 00 00 00 00 00 .@%. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<(ptrval)>] __kmalloc_node+0x1a8/0x2c8 [<(ptrval)>] blk_mq_realloc_tag_set_tags.part.70+0x48/0xd8 [<(ptrval)>] blk_mq_alloc_tag_set+0x1dc/0x530 [<(ptrval)>] bsg_setup_queue+0xe8/0x1a8 [<(ptrval)>] sas_rphy_add+0x108/0x2d0 [<(ptrval)>] sas_probe_devices+0x168/0x208 [<(ptrval)>] sas_discover_domain+0x660/0x9c8 [<(ptrval)>] process_one_work+0x3f8/0x690 [<(ptrval)>] worker_thread+0x70/0x6a0 [<(ptrval)>] kthread+0x1b8/0x1c0 [<(ptrval)>] ret_from_fork+0x10/0x18 unreferenced object 0x041da5c65e00 (size 256): comm ""kworker/u128:1"", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<(ptrval)>] __kmalloc_node+0x1a8/0x2c8 [<(ptrval)>] blk_mq_alloc_tag_set+0x254/0x530 [<(ptrval)>] bsg_setup_queue+0xe8/0x1a8 [<(ptrval)>] sas_rphy_add+0x108/0x2d0 [<(ptrval)>] sas_probe_devices+0x168/0x208 [<(ptrval)>] sas_discover_domain+0x660/0x9c8 [<(ptrval)>] process_one_work+0x3f8/0x690 [<(ptrval)>] worker_thread+0x70/0x6a0 [<(ptrval)>] kthread+0x1b8/0x1c0 [<(ptrval)>] ret_from_fork+0x10/0x18 root@(none)$ [solution] Fix by doing the queue removal in one place - in sas_rphy_remove() - instead of unregistering the queue in sas_rphy_remove() and finally cleaning up the queue in calling blk_cleanup_queue() from sas_end_device_release() or sas_expander_release(). Function bsg_remove_queue() can handle a NULL pointer q, so remove the precheck in sas_rphy_remove(). " scsi: scsi_transport_sas: Fix memory leak when removing devices To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1854550/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help :
[Kernel-packages] [Bug 1859743] Re: [tpm-0115]EFI/stub: tpm: enable tpm eventlog function for ARM64 platform
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1859743 Title: [tpm-0115]EFI/stub: tpm: enable tpm eventlog function for ARM64 platform Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] No TPM eventlog information in sysfs [Fix] d99c1ba6a73b EFI/stub: tpm: enable tpm eventlog function for ARM64 platform [Test] ls -l /sys/kernel/security/tpm0/binary_bios_measurements [Regression Potential] Only affect arm64 system with TPM. Lowest risk for other platform. [Bug Description] this patch gets tpm eventlog information such as device boot status,event guid and so on, which will be from bios stage. it use "efi_retrieve_tpm2_eventlog" functions to get it for ARM64 platorm. [Steps to Reproduce] 1) ls -l /sys/kernel/security/tpm0/binary_bios_measurements 2) 3) [Actual Results] '/sys/kernel/security/tpm0/binary_bios_measurements' no such file or directory [Expected Results] ok [Reproducibility] 100% [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] d99c1ba6a73b EFI/stub: tpm: enable tpm eventlog function for ARM64 platform To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1859743/+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 1859569] Re: [hns3-0114]net: hns3: fix ETS bandwidth validation bug
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1859569 Title: [hns3-0114]net: hns3: fix ETS bandwidth validation bug Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Fix Released Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: When a TC's PFC is disabled or enabled, the RX private buffer for this TC need to be changed too, otherwise this may cause packet dropped problem. [Impact] The corresponding ethernet interface could not be up again. [Fix] cherry picked from commit c2d56897819338eb0ba8b93184f7d10329b36653 net: hns3: fix ETS bandwidth validation bug [Test Case] 1.lldpad -d 2.lldptool -L -i eth0 adminStatus=rxtx 3.lldptool -T -i eth0 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:0,2:1,3:1,4:2,5:2,6:3,7:3 tcbw=25,25,50,0,0,0,0,0 4.down device 5.up [Regression Risk] Low, the patch is only specific to the hns3 driver. == Original Bug Description == [Bug Description] When a TC's PFC is disabled or enabled, the RX private buffer for this TC need to be changed too, otherwise this may cause packet dropped problem. [Steps to Reproduce] 1.lldpad -d 2.lldptool -L -i eth0 adminStatus=rxtx 3.lldptool -T -i eth0 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:0,2:1,3:1,4:2,5:2,6:3,7:3 tcbw=25,25,50,0,0,0,0,0 4.down device 5.up [Actual Results] up fail [Expected Results] up ok [Reproducibility] Inevitably [Additional information] Hardware: D06 Firmware: NA Kernel: NA [Resolution] This patch fixes it by calling hclge_buffer_alloc to reallocate buffer when pfc_en changes. c2d568978193 net: hns3: fix ETS bandwidth validation bug To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1859569/+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 1859744] Re: [spi-0115]spi: dw: use "smp_mb()" to avoid sending spi data error
** Changed in: kunpeng920/ubuntu-20.04 Status: Fix Committed => Fix Released -- 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/1859744 Title: [spi-0115]spi: dw: use "smp_mb()" to avoid sending spi data error Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Released Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Sometimes, TPM fails because SPI data error [Fix] bfda044533b2 spi: dw: use "smp_mb()" to avoid sending spi data error [Test] Reboot system few times and no TPM error message [Regression Potential] Only on SPI function. Already tested on focal kernel [Bug Description] Because of out-of-order execution about some CPU architecture, In this debug stage we find Completing spi interrupt enable -> prodrucing TXEI interrupt -> running "interrupt_transfer" function will prior to set "dw->rx and dws->rx_end" data, so this patch add memory barrier to enable dw->rx and dw->rx_end to be visible and solve to send SPI data error. eg: it will fix to this following low possibility error in testing environment which using SPI control to connect TPM Modules kernel: tpm tpm0: Operation Timed out kernel: tpm tpm0: tpm_relinquish_locality: : error -1 [Steps to Reproduce] 1) enable ima and tpm 2)reboot this system 3) [Actual Results] kernel: tpm tpm0: Operation Timed out kernel: tpm tpm0: tpm_relinquish_locality: : error -1 [Expected Results] ok [Reproducibility] low probabilities [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] bfda044533b2 spi: dw: use "smp_mb()" to avoid sending spi data error To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1859744/+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 1874057] Re: [UBUNTU 20.04] s390x/pci: do not allow to create more pci functions than configured via CONFIG_PCI_NR_FUNCTIONS
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
** Changed in: linux (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
--
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/1874057
Title:
[UBUNTU 20.04] s390x/pci: do not allow to create more pci functions
than configured via CONFIG_PCI_NR_FUNCTIONS
Status in Ubuntu on IBM z Systems:
New
Status in linux package in Ubuntu:
New
Bug description:
PCI Functions with UIDs >128 are currently not accounted correctly in
the s390x/pci code. Furthermore, the code allows that more than
CONFIG_PCI_NR_FUNCTIONS are created. This can lead to issues with data
structures which were only allocated for CONFIG_PCI_NR_FUNCTIONS.
This has been fixed in the following upstream commit:
969ae01bab2fe938b4c8324836038b5ac1c78fac
("s390/pci: Fix zpci_alloc_domain() over allocation")
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874057/+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 1864950] Re: [roce-0227]sync mainline kernel 5.6rc3 roce patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/upstream-kernel Milestone: None => linux-v5.7 -- 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/1864950 Title: [roce-0227]sync mainline kernel 5.6rc3 roce patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] RDMA/hns: Optimize eqe buffer allocation flow RDMA/hns: Cleanups of magic numbers RDMA/hns: fix spelling mistake: "attatch" -> "attach" RDMA/hns: Delayed flush cqe process with workqueue RDMA/hns: Add the workqueue framework for flush cqe handler RDMA/hns: Initialize all fields of doorbells to zero RDMA/hns: Optimize qp doorbell allocation flow RDMA/hns: Optimize kernel qp wrid allocation flow RDMA/hns: Optimize qp param setup flow RDMA/hns: Optimize qp buffer allocation flow RDMA/hns: Optimize qp number assign flow RDMA/hns: Optimize qp context create and destroy flow RDMA/hns: Optimize qp destroy flow RDMA/hns: Stop doorbell update while qp state error RDMA/hns: Use flush framework for the case in aeq RDMA/hns: Treat revision HIP08_A as a special case https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=wip /jgg-for-next RDMA/hns: Treat revision HIP08_A as a special case https://www.spinics.net/lists/linux-rdma/msg89428.html RDMA/hns: Support to set mininum depth of qp to 0 https://patchwork.kernel.org/patch/11415067/ To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1864950/+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 1867586] Re: [hns3-0316]sync mainline kernel 5.6rc4 hns3 patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/upstream-kernel Milestone: None => linux-v5.7 -- 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/1867586 Title: [hns3-0316]sync mainline kernel 5.6rc4 hns3 patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Released Bug description: [Bug Description] hns3 patchset have merged into mainline 5.6rc1 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] net: hns3: clear port base VLAN when unload PF net: hns3: fix RMW issue for VLAN filter switch net: hns3: fix VF VLAN table entries inconsistent issue net: hns3: fix "tc qdisc del" failed issue net: hns3: reject unsupported coalescing params net: hns3: delete unnecessary logs after kzalloc fails net: hns3: synchronize some print relating to reset issue net: hns3: print out command code when dump fails in debugfs net: hns3: print out status register when VF receives unknown source interrupt net: hns3: add a check before PF inform VF to reset net: hns3: delete some reduandant code net: hns3: remove an unnecessary resetting check in hclge_handle_hw_ras_error() net: hns3: rename macro HCLGE_MAX_NCL_CONFIG_LENGTH net: hns3: fix some mixed type assignment net: hns3: fix a not link up issue when fibre port supports autoneg net: hns3: add missing help info for QS shaper in debugfs net: hns3: add support for dump MAC ID and loopback status in debugfs net: hns3: add enabled TC numbers and DWRR weight info in debugfs net: hns3: modify an unsuitable print when setting unknown duplex to fibre [Status] (Rejected) net: hns3: reject unsupported coalescing params (Fix committed) net: hns3: delete unnecessary logs after kzalloc fails (Fix committed) net: hns3: synchronize some print relating to reset issue (Fix committed) net: hns3: print out command code when dump fails in debugfs (Fix committed) net: hns3: print out status register when VF receives unknown source interrupt (Fix committed) net: hns3: add a check before PF inform VF to reset (Fix committed) net: hns3: delete some reduandant code (Fix committed) net: hns3: remove an unnecessary resetting check in hclge_handle_hw_ras_error() (Fix committed) net: hns3: rename macro HCLGE_MAX_NCL_CONFIG_LENGTH (Fix committed) net: hns3: fix some mixed type assignment (Fix committed) net: hns3: add missing help info for QS shaper in debugfs (Fix committed) net: hns3: add support for dump MAC ID and loopback status in debugfs (Fix committed) net: hns3: add enabled TC numbers and DWRR weight info in debugfs (Fix committed) net: hns3: modify an unsuitable print when setting unknown duplex to fibre (Fix committed) net: hns3: clear port base VLAN when unload PF (Fix committed) net: hns3: fix RMW issue for VLAN filter switch (Fix committed) net: hns3: fix VF VLAN table entries inconsistent issue (Fix committed) net: hns3: fix "tc qdisc del" failed issue (Fix committed) net: hns3: fix a not link up issue when fibre port supports autoneg To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867586/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
Note that the virt-manager package is in the "universe" archive. ** Changed in: ubuntu-z-systems Status: New => Triaged -- 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in virt-manager package in Ubuntu: New Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1872941/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Server Team (canonical-server) ** Changed in: ubuntu-z-systems Importance: Undecided => Critical ** Also affects: virt-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Invalid -- 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: Invalid Status in virt-manager package in Ubuntu: New Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1872941/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
** Also affects: ubuntu-z-systems 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1872941/+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 1867591] Re: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch
Marking as incomplete while waiting for a test case for the uacce driver module from HiSilicon. ** Changed in: kunpeng920/upstream-kernel Milestone: None => linux-v5.7 ** Changed in: kunpeng920 Status: In Progress => Incomplete ** Changed in: kunpeng920/ubuntu-18.04-hwe Status: In Progress => Incomplete ** Changed in: kunpeng920/ubuntu-20.04 Status: In Progress => Incomplete -- 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/1867591 Title: [ACC-0316]sync mainline kernel 5.6rc6 ACC patchset into ubuntu HWE kernel branch Status in kunpeng920: Incomplete Status in kunpeng920 ubuntu-18.04-hwe series: Incomplete Status in kunpeng920 ubuntu-20.04 series: Incomplete Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: In Progress Bug description: [Bug Description] roce patchset have merged into mainline 5.6rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver crypto: hisilicon/sec2 - Update IV and MAC operation crypto: hisilicon/sec2 - Add iommu status check crypto: hisilicon/sec2 - Add workqueue for SEC driver. crypto: hisilicon - Use one workqueue per qm instead of per qp crypto: hisilicon - qm depends on UACCE crypto: hisilicon - remove redundant assignment of pointer ctx hisilicon - register zip engine to uacce hisilicon - Remove module_param uacce_mode uacce: add uacce driver uacce: Add documents for uacce crypto: hisilicon - Fix duplicate print when qm occur multiple errors crypto: hisilicon - Unify error detect process into qm crypto: hisilicon - Configure zip RAS error type crypto: hisilicon - Unify hardware error init/uninit into QM To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867591/+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 1867588] Re: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Milestone: None => ubuntu-20.04-ga -- 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/1867588 Title: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: [Bug Description] SFC patchset have merged into mainline 5.7RC1rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override bits spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modes spi: Allow SPI controller override device buswidth To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867588/+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 1867588] Re: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/upstream-kernel Milestone: None => linux-v5.7 -- 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/1867588 Title: [SFC-0316]sync mainline kernel 5.7rc1 SFC patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: [Bug Description] SFC patchset have merged into mainline 5.7RC1rc2 kernel. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override bits spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modes spi: Allow SPI controller override device buswidth To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1867588/+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 1853993] Re: [hns-1126]scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device
** Changed in: kunpeng920/ubuntu-18.04-hwe Status: Fix Committed => Fix Released -- 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/1853993 Title: [hns-1126]scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Released Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Fix Released Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Invalid Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: [Impact] Disks will be lost on SAS interface reset [Fix] scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device [Test] Resetting SAS interfaces shall not lose any disks [Regression Potential] Patch only for hisi_sas. Lowest risk for other platform/driver. "[Steps to Reproduce] 1. Close all the PHYS; 2. Inject error; 3. Open one PHY; [Actual Results] Some disk will be lost [Expected Results] No disk will be lost [Reproducibility] occasionally [Additional information] Hardware: D06 CS Firmware: NA Kernel: NA [Resolution] When init device for SAS disks, it will send TMF IO to clear disks. At that time TMF IO is broken by some operations such as injecting controller reset from HW RAs event, the TMF IO will be timeout, and at last device will be gone. Print is as followed: hisi_sas_v3_hw :74:02.0: dev[240:1] found ... hisi_sas_v3_hw :74:02.0: controller resetting... hisi_sas_v3_hw :74:02.0: phyup: phy7 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy0 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy1 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy2 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy3 link_rate=9(sata) hisi_sas_v3_hw :74:02.0: phyup: phy6 link_rate=10(sata) hisi_sas_v3_hw :74:02.0: phyup: phy5 link_rate=11 hisi_sas_v3_hw :74:02.0: phyup: phy4 link_rate=11 hisi_sas_v3_hw :74:02.0: controller reset complete hisi_sas_v3_hw :74:02.0: abort tmf: TMF task timeout and not done hisi_sas_v3_hw :74:02.0: dev[240:1] is gone sas: driver on host :74:02.0 cannot handle device 5000c500a75a860d, error:5 To improve the reliability, retry TMF IO max of 3 times for SAS disks which is the same as softreset does." scsi: hisi_sas: Retry 3 times TMF IO for SAS disks when init device To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1853993/+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 1850117] Re: [hpre-1017]sync mainline kernel 5.4rc3 hpre patchset into ubuntu HWE kernel branch
** Changed in: kunpeng920/ubuntu-20.04 Milestone: None => ubuntu-20.04-ga -- 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/1850117 Title: [hpre-1017]sync mainline kernel 5.4rc3 hpre patchset into ubuntu HWE kernel branch Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Eoan: Invalid Status in linux source package in Focal: Fix Released Bug description: [Bug Description] hpre patchset have merged into mainline 5.4rc3 kernel. Can use this hpre patchset to release UOSE basing this ubuntu 18.04.4 kernel branch, then merge into ubuntu 18.04.4 version. [Steps to Reproduce] 1) 2) 3) [Actual Results] [Expected Results] [Reproducibility] [Additional information] (Firmware version, kernel version, affected hardware, etc. if required): [Resolution] crypto: hisilicon - add HiSilicon HPRE accelerator crypto: hisilicon - add SRIOV support for HPRE Documentation: Add debugfs doc for hisi_hpre crypto: hisilicon: Add debugfs for HPRE MAINTAINERS: Add maintainer for HiSilicon HPRE driver https://www.mail-archive.com/linux- cry...@vger.kernel.org/msg40969.html To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1850117/+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 1854000] Re: [sas-1126]scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec()
** Changed in: linux (Ubuntu) Status: Fix Committed => Fix Released -- 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/1854000 Title: [sas-1126]scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec() Status in kunpeng920: Fix Committed Status in kunpeng920 ubuntu-18.04 series: Won't Fix Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-19.04 series: Won't Fix Status in kunpeng920 ubuntu-19.10 series: Won't Fix Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: "[Steps to Reproduce] 1. run fio 2“echo 1 > /sys/kernel/debug/hisi_sas/\:74\:02.0/trigger_dump” [Actual Results] [ 448.405504] CPU: 27 PID: 13560 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 [ 448.405506] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405507] Call trace: [ 448.405512] dump_backtrace+0x0/0x150 [ 448.405513] show_stack+0x24/0x30 [ 448.405516] dump_stack+0xa0/0xc4 [ 448.405518] __schedule_bug+0x68/0x88 [ 448.405520] __schedule+0x4b8/0x548 [ 448.405521] schedule+0x40/0xd0 [ 448.405523] schedule_timeout+0x200/0x378 [ 448.405524] __down+0x78/0xc8 [ 448.405526] down+0x54/0x70 [ 448.405533] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] f=11): [M(11)][1[ 448.405535] hisi_sas_queue_command+0x28/0x38 [hisi_sas_main] [ 448.405541] sas_queuecommand+0x168/0x1b0 [libsas] [ 448.405544] scsi_queue_rq+0x2ac/0x980 [ 448.405547] blk_mq_dispatch_rq_list+0xb0/0x550 [ 448.405548] blk_mq_do_dispatch_sched+0x6c/0x110 [ 448.405550] blk_mq_sched_dispatch_requests+0x114/0x1d8 [ 448.405551] __blk_mq_run_hw_queue+0xb8/0x130 [ 448.405552] __blk_mq_delay_run_hw_queue+0x1c0/0x220 [ 448.405553] blk_mq_run_hw_queue+0xb0/0x128 [ 448.405554] blk_mq_sched_insert_requests+0xdc/0x208 [ 448.40] blk_mq_flush_plug_list+0x1b4/0x3a0 [ 448.405557] blk_flush_plug_list+0xdc/0x110 [ 448.405558] blk_finish_plug+0x3c/0x50 [ 448.405560] blkdev_write_iter+0xc0/0x130 [ 448.405562] aio_write+0xec/0x1a0 [ 448.405563] io_submit_one+0x4f4/0x8d8 [ 448.405564] __arm64_sys_io_submit+0xdc/0x280 [ 448.405566] el0_svc_common.constprop.0+0xe0/0x1e0 [ 448.405567] el0_svc_handler+0x34/0x90 [ 448.405569] el0_svc+0x10/0x14 [ 448.405571] CPU: 26 PID: 13559 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 [ 448.405572] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405572] Call trace: [ 448.405574] dump_backtrace+0x0/0x150 [ 448.405575] show_stack+0x24/0x30 [ 448.405577] dump_stack+0xa0/0xc4 [ 448.405578] __schedule_bug+0x68/0x88 [ 448.405580] __schedule+0x4b8/0x548 [ 448.405581] schedule+0x40/0xd0 [ 448.405582] schedule_timeout+0x200/0x378 [ 448.405583] __down+0x78/0xc8 [ 448.405584] down+0x54/0x70 [ 448.405587] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] [ 448.405590] hisi_sas_queue_command+0x28/0x38 [hisi_sas_main] [ 448.405594] sas_queuecommand+0x168/0x1b0 [libsas] [ 448.405595] scsi_queue_rq+0x2ac/0x980 [ 448.405596] blk_mq_dispatch_rq_list+0xb0/0x550 [ 448.405598] blk_mq_do_dispatch_sched+0x6c/0x110 [ 448.405599] blk_mq_sched_dispatch_requests+0x114/0x1d8 [ 448.405600] __blk_mq_run_hw_queue+0xb8/0x130 [ 448.405601] __blk_mq_delay_run_hw_queue+0x1c0/0x220 [ 448.405602] blk_mq_run_hw_queue+0xb0/0x128 [ 448.405603] blk_mq_sched_insert_requests+0xdc/0x208 [ 448.405605] blk_mq_flush_plug_list+0x1b4/0x3a0 [ 448.405606] blk_flush_plug_list+0xdc/0x110 [ 448.405607] blk_finish_plug+0x3c/0x50 [ 448.405608] blkdev_write_iter+0xc0/0x130 [ 448.405610] aio_write+0xec/0x1a0 [ 448.405611] io_submit_one+0x4f4/0x8d8 [ 448.405612] __arm64_sys_io_submit+0xdc/0x280 [ 448.405614] el0_svc_common.constprop.0+0xe0/0x1e0 [ 448.405615] el0_svc_handler+0x34/0x90 [ 448.405616] el0_svc+0x10/0x14 [ 448.405620] CPU: 86 PID: 13534 Comm: fio Tainted: GW 5.3.0-rc4-gae89c9a3-dirty #1 1.7%][r=1163MiB/[ 448.405621] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B080.01 09/19/2019 [ 448.405622] Call trace: [ 448.405625] dump_backtrace+0x0/0x150 [ 448.405626] show_stack+0x24/0x30 [ 448.405631] dump_stack+0xa0/0xc4 [ 448.405635] __schedule_bug+0x68/0x88 [ 448.405636] __schedule+0x4b8/0x548 [ 448.405637] schedule+0x40/0xd0 [ 448.405639] schedule_timeout+0x200/0x378 [ 448.405640] __down+0x78/0xc8 [ 448.405642] down+0x54/0x70 [ 448.405646] hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] [ 448.405649]
