[Kernel-packages] [Bug 1830815] [NEW] Hi1620 driver updates from upstream 5.2 merge window
Public bug reported: [Impact] TBD [Test Case] TBD [Fix] TBD [Regression Risk] TBD ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Disco) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Eoan) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1830815 Title: Hi1620 driver updates from upstream 5.2 merge window Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: [Impact] TBD [Test Case] TBD [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830815/+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 1823753] Re: arm64: cma_alloc errors at boot
I forgot to enable CMA_DEBUGFS in those builds, so I've uploaded another (cma.3) -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1830435] [NEW] phy linkrate persists after deactivation
Public bug reported: [Impact] sysfs continues to expose a valid phy linkrate even after the phy has been disabled. [Test Case] Using hisi_sas, a libsas-based driver: (initramfs) cd /sys/class/sas_phy/phy-0\:0\:20 (initramfs) cat negotiated_linkrate 12.0 Gbit (initramfs) echo 0 > enable [ 59.172411] hisi_sas_v3_hw :74:02.0: phydown: phy0 phy_state=0xfe [ 59.178851] hisi_sas_v3_hw :74:02.0: erroneous completion iptt=4028 task=bb3ab63f dev id=1 CQ hdr: 0x1103 0x10fbc 0x0 0x2 Error info: 0x0 0x400 0x0 0x0 [ 59.194139] sas: smp_execute_task_sg: task to dev 500e004aaa1f response: 0x0 status 0x2 (initramfs) cat negotiated_linkrate 12.0 Gbit [Regression Risk] Impact is limited to drivers built on top of libsas. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: 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/1830435 Title: phy linkrate persists after deactivation Status in linux package in Ubuntu: In Progress Bug description: [Impact] sysfs continues to expose a valid phy linkrate even after the phy has been disabled. [Test Case] Using hisi_sas, a libsas-based driver: (initramfs) cd /sys/class/sas_phy/phy-0\:0\:20 (initramfs) cat negotiated_linkrate 12.0 Gbit (initramfs) echo 0 > enable [ 59.172411] hisi_sas_v3_hw :74:02.0: phydown: phy0 phy_state=0xfe [ 59.178851] hisi_sas_v3_hw :74:02.0: erroneous completion iptt=4028 task=bb3ab63f dev id=1 CQ hdr: 0x1103 0x10fbc 0x0 0x2 Error info: 0x0 0x400 0x0 0x0 [ 59.194139] sas: smp_execute_task_sg: task to dev 500e004aaa1f response: 0x0 status 0x2 (initramfs) cat negotiated_linkrate 12.0 Gbit [Regression Risk] Impact is limited to drivers built on top of libsas. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830435/+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
Re: [Kernel-packages] [Bug 1823753] Re: arm64: cma_alloc errors at boot
On Thu, May 23, 2019 at 8:31 AM Paolo Pisati <1823...@bugs.launchpad.net> wrote: > > Yes, i have all the hardware to do some testing, prepare some kernels > and we can take it from there. Thanks Paolo. I pushed a test build to ppa:dannf/cma. This bumps cma to 32M, but would also be good to know the results w/ cma=64M on the cmdline. -dann -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1829942] Re: Address performance issue w/ GICv4-based guests
** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Cosmic) 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/1829942 Title: Address performance issue w/ GICv4-based guests Status in linux package in Ubuntu: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: [Impact] Performance is degraded when a guest is booted w/ vgic v4 support enabled. [Test Case] I used a HiSilicon D06 system w/ an Intel 82599 10Gbps NIC. I passed through a VF to a guest, and ran "netperf -H " against a 10Gbps-capable target. With vgic v4 support, I'm only seeing 5-6Gbps. With vgic v3 support, this was in the 9Gbps spectrum. And, after applying the upstream fix, I'm also seeing >9Gbps w/ vgic v4 enabled. Note: to enable vgic v4 support, pass "kvm-arm.vgic_v4_enable=1" on the host kernel cmdline. [Fix] ca71228b42a96 arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled [Regression Risk] The fix is restricted to the ARM/KVM subsystem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829942/+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 1829652] Re: Kernel panic upon resetting ixgbe SR-IOV VFIO virtual function using 5.0 kernel
Patch submitted upstream: https://www.spinics.net/lists/netdev/msg571753.html -- 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/1829652 Title: Kernel panic upon resetting ixgbe SR-IOV VFIO virtual function using 5.0 kernel Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: Hi, I've recently upgraded my system to ubuntu 19.04, and kernel consistently panics when I boot a virtual machine using an SR-IOV VFIO virtual function. Could reproduce with 5.0.0-13-generic and 5.0.0-15-generic, doesn't happen with 4.18.0-20-generic. I'm using libvirt and VM is using KVM, XML snippet to delegate virtual function to VM is: As soon as I start the VM using "virsh start vm", kernel panics. I'm using X550T intel NIC (lspci output: Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01)) on a Supermicro X11SSH-CTF motherboard, with up to date bios and 4 virtual functions (class/net/em1/device/sriov_numvfs = 4). Given panic stack trace (see attachment), I've narrowed down the bug to ixgbe_ipsec_vf_clear function in upstream ixgbe driver: https://github.com/torvalds/linux/blob/72cf0b07418a9c8349aa9137194b1ccba6e54a9d/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c#L840 When I comment its usage (https://github.com/torvalds/linux/blob/72cf0b07418a9c8349aa9137194b1ccba6e54a9d/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c#L734), everything works as expected (I'm not using any ipsec feature). Didn't try to fix the ixgbe_ipsec_vf_clear function though. Please find attached a stack trace collected using IPMI serial-over- lan. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829652/+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 1829652] Re: Kernel panic upon resetting ixgbe SR-IOV VFIO virtual function using 5.0 kernel
** Changed in: linux (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Assignee: dann frazier (dannf) Status: Confirmed ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Eoan) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Disco) 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/1829652 Title: Kernel panic upon resetting ixgbe SR-IOV VFIO virtual function using 5.0 kernel Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: Hi, I've recently upgraded my system to ubuntu 19.04, and kernel consistently panics when I boot a virtual machine using an SR-IOV VFIO virtual function. Could reproduce with 5.0.0-13-generic and 5.0.0-15-generic, doesn't happen with 4.18.0-20-generic. I'm using libvirt and VM is using KVM, XML snippet to delegate virtual function to VM is: As soon as I start the VM using "virsh start vm", kernel panics. I'm using X550T intel NIC (lspci output: Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01)) on a Supermicro X11SSH-CTF motherboard, with up to date bios and 4 virtual functions (class/net/em1/device/sriov_numvfs = 4). Given panic stack trace (see attachment), I've narrowed down the bug to ixgbe_ipsec_vf_clear function in upstream ixgbe driver: https://github.com/torvalds/linux/blob/72cf0b07418a9c8349aa9137194b1ccba6e54a9d/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c#L840 When I comment its usage (https://github.com/torvalds/linux/blob/72cf0b07418a9c8349aa9137194b1ccba6e54a9d/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c#L734), everything works as expected (I'm not using any ipsec feature). Didn't try to fix the ixgbe_ipsec_vf_clear function though. Please find attached a stack trace collected using IPMI serial-over- lan. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829652/+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
Re: [Kernel-packages] [Bug 1823753] Re: arm64: cma_alloc errors at boot
On Wed, May 22, 2019 at 8:41 AM Paolo Pisati <1823...@bugs.launchpad.net> wrote: > > I realize this is just a workaround (and the above 31M cma memory > fragmentation is ugly), but we should definitely bump CMA allocation > space: definitely 32M (since that's what upstream default to) but if 64M > solves a problem you have at the moment (until we sort out the driver > issue), i'm not opposing to such a change - Unfortunately, without other mitigations, we blow past 64M as well. Ignoring fragmentation, we're using ~108M of CMA (summing up the totals in comment #11). I think including the dma-contiguous patches are key. They would alleviate the pain of the single page allocations (~46M), and unblock driver optimizations from doing the same (hisi_sas driver could move 33M of allocs out of CMA). Those would impact archs that have CONFIG_DMA_CMA, which are arm64 and armhf-generic: debian.master/config/annotations:CONFIG_DMA_CMA policy<{'amd64': 'n', 'arm64': 'y', 'armhf-generic': 'y', 'armhf-generic-lpae': 'n', 'i386': 'n', 's390x': 'n'}> I don't have any real armhf-generic hw anymore - if I prepared PPA kernels, would you happen to have kit for regression testing? > after all, you are the main > consumer of generic/arm64 (all other boards are either armhf or have > their own topic kernel) so if there's a workaround we can apply to make > your life easier, i don't see why we shouldn't do it. My biggest concern w/ bumping up CMA is that we do appear to have users of the arm64/generic kernel on platforms I don't have. For instance, the reason we got into this CMA issue at all was by turning on DMA_CMA on arm64 for the RPi3 (bug 1803206) - so I'd at least like to get some regression testing on that platform. And, obviously such relatively lowmem platforms make me want to be rather conservative about bumping up CMA sizes. -dann -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1829942] Re: Address performance issue w/ GICv4-based guests
** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: Incomplete ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Eoan) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu Eoan) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1829942 Title: Address performance issue w/ GICv4-based guests Status in linux package in Ubuntu: In Progress Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: [Impact] Performance is degraded when a guest is booted w/ vgic v4 support enabled. [Test Case] I used a HiSilicon D06 system w/ an Intel 82599 10Gbps NIC. I passed through a VF to a guest, and ran "netperf -H " against a 10Gbps-capable target. With vgic v4 support, I'm only seeing 5-6Gbps. With vgic v3 support, this was in the 9Gbps spectrum. And, after applying the upstream fix, I'm also seeing >9Gbps w/ vgic v4 enabled. Note: to enable vgic v4 support, pass "kvm-arm.vgic_v4_enable=1" on the host kernel cmdline. [Fix] ca71228b42a96 arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled [Regression Risk] The fix is restricted to the ARM/KVM subsystem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829942/+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 1829942] [NEW] Address performance issue w/ GICv4-based guests
Public bug reported: [Impact] Performance is degraded when a guest is booted w/ vgic v4 support enabled. [Test Case] I used a HiSilicon D06 system w/ an Intel 82599 10Gbps NIC. I passed through a VF to a guest, and ran "netperf -H " against a 10Gbps-capable target. With vgic v4 support, I'm only seeing 5-6Gbps. With vgic v3 support, this was in the 9Gbps spectrum. And, after applying the upstream fix, I'm also seeing >9Gbps w/ vgic v4 enabled. Note: to enable vgic v4 support, pass "kvm-arm.vgic_v4_enable=1" on the host kernel cmdline. [Fix] ca71228b42a96 arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled [Regression Risk] The fix is restricted to the ARM/KVM subsystem. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1829942 Title: Address performance issue w/ GICv4-based guests Status in linux package in Ubuntu: New Bug description: [Impact] Performance is degraded when a guest is booted w/ vgic v4 support enabled. [Test Case] I used a HiSilicon D06 system w/ an Intel 82599 10Gbps NIC. I passed through a VF to a guest, and ran "netperf -H " against a 10Gbps-capable target. With vgic v4 support, I'm only seeing 5-6Gbps. With vgic v3 support, this was in the 9Gbps spectrum. And, after applying the upstream fix, I'm also seeing >9Gbps w/ vgic v4 enabled. Note: to enable vgic v4 support, pass "kvm-arm.vgic_v4_enable=1" on the host kernel cmdline. [Fix] ca71228b42a96 arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled [Regression Risk] The fix is restricted to the ARM/KVM subsystem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829942/+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 1828092] Re: ratelimit cma_alloc messages
disco verification: ubuntu@d06-4:~$ cat /proc/version Linux version 5.0.0-16-generic (buildd@bos02-arm64-013) (gcc version 8.3.0 (Ubuntu/Linaro 8.3.0-6ubuntu1)) #17-Ubuntu SMP Wed May 15 10:54:19 UTC 2019 ubuntu@d06-4:~$ dmesg | grep cma [0.00] cma: Reserved 16 MiB at 0x7f00 [0.00] Memory: 180830576K/184545152K available (11836K kernel code, 1694K rwdata, 5060K rodata, 5504K init, 1158K bss, 3698192K reserved, 16384K cma-reserved) [ 18.211364] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.217896] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.254209] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.308352] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.328708] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.350072] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.350081] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.350089] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.350097] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 18.350106] cma: cma_alloc: alloc failed, req-size: 33 pages, ret: -12 [ 27.962013] cma_alloc: 358 callbacks suppressed [ 27.962014] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 27.968453] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 27.974915] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 27.981347] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 27.987779] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 27.994211] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 28.000647] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 28.000649] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 28.013539] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 [ 28.019974] cma: cma_alloc: alloc failed, req-size: 1 pages, ret: -12 ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- 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/1828092 Title: ratelimit cma_alloc messages Status in linux package in Ubuntu: Incomplete Status in linux source package in Disco: Fix Committed Bug description: [Impact] As described in bug 1823753, failures to allocate DMA out of CMA space can result in ~10K cma_alloc() error messages. While non-fatal (the code falls back to allocating memory out of non-CMA space), the error messages themselves can be a problem - esp. for systems w/ slow consoles like the HP m400 (9600 baud). It slows down boot so much that MAAS deploys fail due to timeout. [Test Case] Boot the disco kernel on an HP m400 or a HiSilicon D06 w/ the SMMU disabled in the BIOS. [Fix] Ratelimit the messages. [Regression Risk] Minimal - we're just attempting to quiescing log spew. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828092/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
disco verification: ubuntu@d06-4:~$ cat /proc/version Linux version 5.0.0-16-generic (buildd@bos02-arm64-013) (gcc version 8.3.0 (Ubuntu/Linaro 8.3.0-6ubuntu1)) #17-Ubuntu SMP Wed May 15 10:54:19 UTC 2019 ubuntu@d06-4:~$ sudo dmesg -c > /dev/null ubuntu@d06-4:~$ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer function ubuntu@d06-4:~$ dmesg ubuntu@d06-4:~$ ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: Fix Committed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] 4e69ecf4da1ee arm64/module: ftrace: deal with place relative nature of PLTs 5a3ae7b314a22 arm64/ftrace: fix inadvertent BUG() in trampoline check [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/u
[Kernel-packages] [Bug 1827437] Re: potential memory corruption on arm64 on dev release
Bionic verification: (initramfs) cat /proc/version Linux version 4.15.0-51-generic (buildd@bos02-arm64-037) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #55-Ubuntu SMP Wed May 15 14:27:56 UTC 2019 (initramfs) modprobe -r hisi_sas_v3_hw [ 217.311945] systemd-udevd[1224]: passed device to netlink monitor 0xc0e362f0 [ 217.312494] systemd-udevd[1225]: passed device to netlink monitor 0xc0de37d0 [ 217.313119] systemd-udevd[842]: passed 182 byte device to netlink monitor 0xc0dc2b40 [ 217.313218] systemd-udevd[1225]: passed device to netlink monitor 0xc0de37d0 [ 217.313317] systemd-udevd[1226]: passed device to netlink monitor 0xc0dbd710 [ 217.313521] systemd-udevd[1227]: passed device to netlink monitor 0xc0dbab80 [ 217.313844] systemd-udevd[842]: passed 182 byte device to netlink monitor 0xc0dc2b40 [ 217.313884] systemd-udevd[842]: passed 182 byte device to netlink monitor 0xc0dc2b40 [ 217.313939] systemd-udevd[1227]: passed device to netlink monitor 0xc0dbab80 [ 217.313951] systemd-udevd[1225]: passed device to netlink monitor 0xc0de37d0 (initramfs) modprobe hisis_sas_v3_hw (initramfs) ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1827437 Title: potential memory corruption on arm64 on dev release Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] Potential memory corruption. [Test Case] I've not seen a failure in practice (well, it's easy to crash 5.0 but, as the commit message notes, that's because it includes an additional patch that happens to "tickle" this. But to regression test, I boot a HiSilicon D06 to a ramdisk and remove the hisi_sas_v3_hw module, which allocates memory as described in the commit message. [Fix] 376991db4b646 driver core: Postpone DMA tear-down until after devres release [Regression Risk] From the stable tree, so in theory would be applied eventually anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827437/+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 1826911] Re: hns: fix socket accounting
Verification: ubuntu@d06-2:~$ cat /proc/version Linux version 4.15.0-51-generic (buildd@bos02-arm64-037) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #55-Ubuntu SMP Wed May 15 14:27:56 UTC 2019 ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1826911 Title: hns: fix socket accounting Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] It is possible for a socket to use more memory than permitted on systems using the hns network driver. [Fix] b1ccd4c0ab6ef net: hns: fix skb->truesize underestimation [Test Case] Regression tested only. [Regression Risk] Trivial fix local to a single driver only used on ARM servers based on the Hi1616 SoC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826911/+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 1829306] Re: ethtool identify command doesn't blink LED on Hi1620 NICs
** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Cosmic) 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/1829306 Title: ethtool identify command doesn't blink LED on Hi1620 NICs Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: [Impact] Users cannot use the ethtool --identify command to help them identify a NIC's physical port. [Test Case] sudo ethtool --identify [Fix] a93f7fe134543 net: phy: marvell: add new default led configure for m88e151x [Regression Risk] The fix is restricted to the Hi1620 device and other users of the marvell phy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829306/+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 1829306] [NEW] ethtool identify command doesn't blink LED on Hi1620 NICs
Public bug reported: [Impact] Users cannot use the ethtool --identify command to help them identify a NIC's physical port. [Test Case] sudo ethtool --identify [Fix] a93f7fe134543 net: phy: marvell: add new default led configure for m88e151x [Regression Risk] The fix is restricted to the Hi1620 device and other users of the marvell phy. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: 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/1829306 Title: ethtool identify command doesn't blink LED on Hi1620 NICs Status in linux package in Ubuntu: In Progress Bug description: [Impact] Users cannot use the ethtool --identify command to help them identify a NIC's physical port. [Test Case] sudo ethtool --identify [Fix] a93f7fe134543 net: phy: marvell: add new default led configure for m88e151x [Regression Risk] The fix is restricted to the Hi1620 device and other users of the marvell phy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829306/+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 1775732] Re: arm64 soft lock crashes on nova-compute charm running
@Ryan: Is this still a problem w/ 4.15? Do you need a full OpenStack setup to reproduce it, or is just a single node nova model enough? -- 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/1775732 Title: arm64 soft lock crashes on nova-compute charm running Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Bug description: Discovered on bionic, arm64 (Moonshot, verified on multiple swirlix cartridges), 4.15.0-22-generic. After deploying the nova-compute Juju charm, on subsequent reboots, within a few seconds after complete boot, everything will freeze and eventually display on the serial console (just these, no traces): [ 188.010510] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [juju-log:2272] [ 216.010292] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [juju-log:2272] (From here on, "lock up" refers to that sequence: boot a kernel, it completes boot to login prompt, then everything freezes a few seconds later, then BUGs.) It's usually but not always juju-log, sometimes a relation-ids or similar. I was able to briefly notice that it was in its startup config-changed hook. I've separated out and tested nearly everything it does during its startup config-changed (sets up bridging, writes some config files, restarts libvirtd/nova-compute/etc) without being able to trigger the bug, but I suspect proximity to boot is a factor. If I disable jujud- unit-nova-compute startup, boot, log in, re-enable and start (by which time over a minute or so has elapsed from boot finish), it will not lock up. Similarly, if I wrap the jujud startup in a `strace -Ff -o /var/log/strace.log` (which slows it down massively), it will not lock up. Watched pot syndrome. I've tried kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ . I noticed most of the recent arm64 mainline kernels had failed builds, notified the kernel team channel and apw fixed the issue and started some rebuilds. What I've discovered (after many dead ends and a futile bisection) is that mainline builds before the rebuilds lock up, but fixed mainline builds initiated by apw DO NOT lock up. e.g. 4.16.3-041603.201804190730 locks up, but 4.16.6-041606.201806042022 does not lock up. (4.16.4 and 4.16.5 appear to have never been rebuilt and don't have arm64 debs, and that period is what I tried to bisect after figuring a fix must be in there.) But when I try to compile any of these recent kernels myself, they lock up when booted. Same kernel configs, tried on both bionic and in a cosmic chroot, tried both native arm64 compile and cross-compile from amd64. e.g. 4.16.6-041606.201806042022 from k.u.c does not lock up, but when I build it myself, it does. TBC, I've verified lock ups on the following kernels (all assume kernel configs from their respective Ubuntu or k.u.c mainline builds): - 4.15.0-22-generic from bionic (both Ubuntu-provided and my own recompile) - v4.16 (and all point releases) - v4.17 As I write this, my compiled v4.10 DOES NOT appear to lock up. I will attempt to bisect at a macro level from 4.10..4.15 and dig deeper. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-image-4.15.0-22-generic 4.15.0-22.24 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic aarch64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jun 2 04:22 seq crw-rw 1 root audio 116, 33 Jun 2 04:22 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.9-0ubuntu7.2 Architecture: arm64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Date: Fri Jun 8 00:13:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: console=ttyS0,9600n8r ro RelatedPackageVersions: linux-restricted-modules-4.15.0-22-generic N/A linux-backports-modules-4.15.0-22-generic N/A linux-firmware 1.173.1 RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1775732/+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/L
[Kernel-packages] [Bug 1823753] Re: arm64: cma_alloc errors at boot
The hisi_sas maintainer is experimenting with a patch that will change the driver's 33 page allocations to single page allocations. If there is no significant performance impact, that could be a way forward to deal with the fragmentation issue costing us up to 31M of CMA. In addition, there is DMA/CMA optimization making its way upstream, that uses non-CMA memory for single page requests: https://lkml.org/lkml/2019/5/6/1219 This avoids the impact of the CMA memory usage increase in the RDMA/hns driver (see comment #11) and - with the aforementioned hisi_sas patch - those allocations as well. After those optimizations, I am able to fulfill all cma allocation requests from our D06 CS board[*] with cma=64M. However, Ubuntu ships with only 16M of CMA. Note that upstream's defconfig allocates 32M of CMA, which is apparently required for the RPi VC4: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebf089248dab2ef569e5e26a607f0977a71182b7 So there maybe other reasons we want to bump to at least 32M - I'm not sure that we'd want to go all the way to 64M for general purpose kernel though. [*] Keeping in mind that this is just tuning for a specific system/config. Throw in a bunch of mlx5 cards, and I suspect we'll still see cma_alloc log spew on this platform. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1828868] Re: crashdump fails on HiSilicon D06
** Description changed: [Impact] The crashdump kernel fails to boot on HiSilicon D06, and likely other SMMUv3 ARM systems. [Test Case] sudo apt install linux-crashdump Adjust crashkernel= parameter in /etc/default/grub.d/kdump-tools.cfg as appropriate (for D06, crashkernel=512M) sudo reboot (needed to add crashkernel= param) echo 1 | sudo tee /proc/sys/kernel/sysrq echo c | sudo tee /proc/sysrq-trigger [Fix] 3f54c447df34f iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel [Regression Risk] + Restricted to SMMUv3 arm64-based systems. -- 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/1828868 Title: crashdump fails on HiSilicon D06 Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Bug description: [Impact] The crashdump kernel fails to boot on HiSilicon D06, and likely other SMMUv3 ARM systems. [Test Case] sudo apt install linux-crashdump Adjust crashkernel= parameter in /etc/default/grub.d/kdump-tools.cfg as appropriate (for D06, crashkernel=512M) sudo reboot (needed to add crashkernel= param) echo 1 | sudo tee /proc/sys/kernel/sysrq echo c | sudo tee /proc/sysrq-trigger [Fix] 3f54c447df34f iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel [Regression Risk] Restricted to SMMUv3 arm64-based systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828868/+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 1828868] [NEW] crashdump fails on HiSilicon D06
Public bug reported: [Impact] The crashdump kernel fails to boot on HiSilicon D06, and likely other SMMUv3 ARM systems. [Test Case] sudo apt install linux-crashdump Adjust crashkernel= parameter in /etc/default/grub.d/kdump-tools.cfg as appropriate (for D06, crashkernel=512M) sudo reboot (needed to add crashkernel= param) echo 1 | sudo tee /proc/sys/kernel/sysrq echo c | sudo tee /proc/sysrq-trigger [Fix] 3f54c447df34f iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel [Regression Risk] Restricted to SMMUv3 arm64-based systems. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Disco) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1828868 Title: crashdump fails on HiSilicon D06 Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Bug description: [Impact] The crashdump kernel fails to boot on HiSilicon D06, and likely other SMMUv3 ARM systems. [Test Case] sudo apt install linux-crashdump Adjust crashkernel= parameter in /etc/default/grub.d/kdump-tools.cfg as appropriate (for D06, crashkernel=512M) sudo reboot (needed to add crashkernel= param) echo 1 | sudo tee /proc/sys/kernel/sysrq echo c | sudo tee /proc/sysrq-trigger [Fix] 3f54c447df34f iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel [Regression Risk] Restricted to SMMUv3 arm64-based systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828868/+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 1804481] Re: SecureBoot support for arm64
Marking critical, as this prevents X-Gene/uboot systems from booting ** Changed in: linux-signed-hwe-edge (Ubuntu Bionic) 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/1804481 Title: SecureBoot support for arm64 Status in linux package in Ubuntu: Fix Released Status in linux-meta package in Ubuntu: In Progress Status in linux-signed package in Ubuntu: Fix Released Status in linux-signed-hwe-edge package in Ubuntu: New Status in shim package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in linux source package in Bionic: Triaged Status in linux-meta source package in Bionic: Triaged Status in linux-signed source package in Bionic: Triaged Status in linux-signed-hwe-edge source package in Bionic: In Progress Status in shim source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Triaged Status in linux source package in Cosmic: Triaged Status in linux-meta source package in Cosmic: Triaged Status in linux-signed source package in Cosmic: Triaged Status in linux-signed-hwe-edge source package in Cosmic: Invalid Status in shim source package in Cosmic: Fix Released Status in shim-signed source package in Cosmic: Triaged Status in linux source package in Disco: Fix Released Status in linux-meta source package in Disco: In Progress Status in linux-signed source package in Disco: Fix Released Status in linux-signed-hwe-edge source package in Disco: Invalid Status in shim source package in Disco: Fix Released Status in shim-signed source package in Disco: Fix Released Bug description: [Impact] Ubuntu does not currently support SecureBoot for UEFI systems on arm64 platforms. [Test Case] See: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing [Fix] - Introduce shim-signed for arm64 - Introduce grub-signed for arm64 - Produce signed linux kernels [Regression Risk] We're enabling new signed packages - regressions would most likely fall into packaging issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804481/+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 1804481] Re: SecureBoot support for arm64
Marking critical, as this prevents X-Gene/uboot systems from booting ** Changed in: linux-signed-hwe-edge (Ubuntu Bionic) 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/1804481 Title: SecureBoot support for arm64 Status in linux package in Ubuntu: Fix Released Status in linux-meta package in Ubuntu: In Progress Status in linux-signed package in Ubuntu: Fix Released Status in linux-signed-hwe-edge package in Ubuntu: New Status in shim package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in linux source package in Bionic: Triaged Status in linux-meta source package in Bionic: Triaged Status in linux-signed source package in Bionic: Triaged Status in linux-signed-hwe-edge source package in Bionic: In Progress Status in shim source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Triaged Status in linux source package in Cosmic: Triaged Status in linux-meta source package in Cosmic: Triaged Status in linux-signed source package in Cosmic: Triaged Status in linux-signed-hwe-edge source package in Cosmic: Invalid Status in shim source package in Cosmic: Fix Released Status in shim-signed source package in Cosmic: Triaged Status in linux source package in Disco: Fix Released Status in linux-meta source package in Disco: In Progress Status in linux-signed source package in Disco: Fix Released Status in linux-signed-hwe-edge source package in Disco: Invalid Status in shim source package in Disco: Fix Released Status in shim-signed source package in Disco: Fix Released Bug description: [Impact] Ubuntu does not currently support SecureBoot for UEFI systems on arm64 platforms. [Test Case] See: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing [Fix] - Introduce shim-signed for arm64 - Introduce grub-signed for arm64 - Produce signed linux kernels [Regression Risk] We're enabling new signed packages - regressions would most likely fall into packaging issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804481/+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 1804481] Re: SecureBoot support for arm64
** Also affects: linux-signed-hwe-edge (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-signed-hwe-edge (Ubuntu Cosmic) Status: New => Invalid ** Changed in: linux-signed-hwe-edge (Ubuntu Disco) Status: New => Invalid ** Changed in: linux-signed-hwe-edge (Ubuntu Bionic) 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/1804481 Title: SecureBoot support for arm64 Status in linux package in Ubuntu: Fix Released Status in linux-meta package in Ubuntu: In Progress Status in linux-signed package in Ubuntu: Fix Released Status in linux-signed-hwe-edge package in Ubuntu: New Status in shim package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in linux source package in Bionic: Triaged Status in linux-meta source package in Bionic: Triaged Status in linux-signed source package in Bionic: Triaged Status in linux-signed-hwe-edge source package in Bionic: In Progress Status in shim source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Triaged Status in linux source package in Cosmic: Triaged Status in linux-meta source package in Cosmic: Triaged Status in linux-signed source package in Cosmic: Triaged Status in linux-signed-hwe-edge source package in Cosmic: Invalid Status in shim source package in Cosmic: Fix Released Status in shim-signed source package in Cosmic: Triaged Status in linux source package in Disco: Fix Released Status in linux-meta source package in Disco: In Progress Status in linux-signed source package in Disco: Fix Released Status in linux-signed-hwe-edge source package in Disco: Invalid Status in shim source package in Disco: Fix Released Status in shim-signed source package in Disco: Fix Released Bug description: [Impact] Ubuntu does not currently support SecureBoot for UEFI systems on arm64 platforms. [Test Case] See: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing [Fix] - Introduce shim-signed for arm64 - Introduce grub-signed for arm64 - Produce signed linux kernels [Regression Risk] We're enabling new signed packages - regressions would most likely fall into packaging issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804481/+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 1828092] Re: ratelimit cma_alloc messages
** Changed in: linux (Ubuntu Disco) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu Disco) 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/1828092 Title: ratelimit cma_alloc messages Status in linux package in Ubuntu: Incomplete Status in linux source package in Disco: In Progress Bug description: [Impact] As described in bug 1823753, failures to allocate DMA out of CMA space can result in ~10K cma_alloc() error messages. While non-fatal (the code falls back to allocating memory out of non-CMA space), the error messages themselves can be a problem - esp. for systems w/ slow consoles like the HP m400 (9600 baud). It slows down boot so much that MAAS deploys fail due to timeout. [Test Case] Boot the disco kernel on an HP m400 or a HiSilicon D06 w/ the SMMU disabled in the BIOS. [Fix] Ratelimit the messages. [Regression Risk] Minimal - we're just attempting to quiescing log spew. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828092/+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 1823753] Re: arm64: cma_alloc errors at boot
I've split the ratelimiting topic out to bug 1828092 so to keep this one open while we continue to try and solve the underlying cause of the messages. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1828092] [NEW] ratelimit cma_alloc messages
Public bug reported: [Impact] As described in bug 1823753, failures to allocate DMA out of CMA space can result in ~10K cma_alloc() error messages. While non-fatal (the code falls back to allocating memory out of non-CMA space), the error messages themselves can be a problem - esp. for systems w/ slow consoles like the HP m400 (9600 baud). It slows down boot so much that MAAS deploys fail due to timeout. [Test Case] Boot the disco kernel on an HP m400 or a HiSilicon D06 w/ the SMMU disabled in the BIOS. [Fix] Ratelimit the messages. [Regression Risk] Minimal - we're just attempting to quiescing log spew. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Disco) Importance: Undecided Status: Incomplete ** Also affects: linux (Ubuntu Disco) 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/1828092 Title: ratelimit cma_alloc messages Status in linux package in Ubuntu: Incomplete Status in linux source package in Disco: Incomplete Bug description: [Impact] As described in bug 1823753, failures to allocate DMA out of CMA space can result in ~10K cma_alloc() error messages. While non-fatal (the code falls back to allocating memory out of non-CMA space), the error messages themselves can be a problem - esp. for systems w/ slow consoles like the HP m400 (9600 baud). It slows down boot so much that MAAS deploys fail due to timeout. [Test Case] Boot the disco kernel on an HP m400 or a HiSilicon D06 w/ the SMMU disabled in the BIOS. [Fix] Ratelimit the messages. [Regression Risk] Minimal - we're just attempting to quiescing log spew. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828092/+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 1823753] Re: arm64: cma_alloc errors at boot
Why would it fail to init? If CMA allocation fails, the kernel will fulfill the request using alloc_pages_node(): struct page *__dma_direct_alloc_pages(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) { [...] /* CMA can be used only in the context which permits sleeping */ if (gfpflags_allow_blocking(gfp)) { page = dma_alloc_from_contiguous(dev, count, page_order, gfp & __GFP_NOWARN); if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) { dma_release_from_contiguous(dev, page, count); page = NULL; } } if (!page) page = alloc_pages_node(dev_to_node(dev), gfp, page_order); [...] } -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
As per Seth's suggestion, I tried ratelimiting the cma_alloc messages: diff --git a/mm/cma.c b/mm/cma.c index c7b39dd3b4f6..56d2a046f689 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -477,7 +477,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align, page_kasan_tag_reset(page + i); } - if (ret && !no_warn) { + if (ret && !no_warn && printk_ratelimit()) { pr_err("%s: alloc failed, req-size: %zu pages, ret: %d\n", __func__, count, ret); cma_debug_show_areas(cma); This drops the cma_alloc error message count down from 10758 to 21. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
Note that in current disco things have gotten worse - our single page allocations have blown up to 11753: $ cat cma.disco.dmesg | grep "cma: cma_alloc(cma" | sed -r 's/.*count ([0-9]+)\,.*/\1/' | sort -n | uniq -c 11753 1 3 2 3 4 234 8 32 16 2 24 4 32 256 33 39 64 2 128 2 1024 I bisected this down to a backport of the following commit: 3e394f9413ec RDMA/hns: Modify qp&cq&pd specification according to UM Reverting that gets us down to 3029 single page allocations, freeing up about 34M. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
The culprit for the 256 33 page allocations (that causes the fragmentation mentioned in comment #8) is the hisi_sas_v3_hw driver: [ 21.220867] Call trace: [ 21.223301] dump_backtrace+0x0/0x1b0 [ 21.226948] show_stack+0x24/0x30 [ 21.230251] dump_stack+0x90/0xb4 [ 21.233554] cma_alloc+0x3f4/0x430 [ 21.236942] dma_alloc_from_contiguous+0x70/0x80 [ 21.241544] __dma_direct_alloc_pages+0x14c/0x228 [ 21.246234] dma_direct_alloc_pages+0x48/0xc0 [ 21.250576] dma_direct_alloc+0x50/0x80 [ 21.254397] dma_alloc_attrs+0x94/0x128 [ 21.258218] dmam_alloc_attrs+0x68/0xb8 [ 21.262043] hisi_sas_alloc+0x360/0x538 [hisi_sas_main] [ 21.267257] hisi_sas_shost_alloc_pci+0xfc/0x170 [hisi_sas_v3_hw] [ 21.273337] hisi_sas_v3_probe+0xd8/0x360 [hisi_sas_v3_hw] [ 21.278810] local_pci_probe+0x44/0xa8 [ 21.282544] work_for_cpu_fn+0x20/0x30 [ 21.286279] process_one_work+0x1f0/0x430 [ 21.290274] worker_thread+0x248/0x488 [ 21.294009] kthread+0x134/0x138 [ 21.297223] ret_from_fork+0x10/0x18 I wonder if it'd be possible to adjust this allocation somehow. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
To try to understand how the CMA is allocated - and what the problem might be - I booted a HiSilicon D06 w/ plenty of cma cushion (cma=128M), and looked at cma debugfs. In the upstream thread, Robin asked if this was potentially an issue with lots of 1 page allocations - something for which patches have been proposed. Here's a histogram of allocation sizes: $ dmesg | grep "cma: cma_alloc(cma" | sed -r 's/.*count ([0-9]+)\,.*/\1/' | sort -n | uniq -c 2062 1 32 2 266 8 2 24 4 32 256 33 7 64 2 128 2 1024 So, there are 2062 1 page allocations. While that's the largest # of allocations by page size, that's only really 13% of the allocated pages, just over 8M. That would get us down to 53M. But we know that total allocation size isn't the only problem - fragmentation must be playing a role, as we're using ~61M, but still seeing errors w/ cma=64M. To understand the fragmentation impact, I looked at the debugfs cma bitmap. I converted that map to binary, coalescing repeated lines, and got this: x309 \__ x252 1 / 0 x48 0 x412 I don't see any signs of fragmentation w/ the single page allocations. What is concerning is the 252 33 page allocations (a subset of the 256 in the histogram). They are getting allocated on 64M boundaries, which ends up leaving 31 free pages per allocation. 256 * 31 * 4K = 31M of potentially wasted space. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1827437] Re: potential memory corruption on arm64 on dev release
** Changed in: linux (Ubuntu) Status: Incomplete => Fix Released ** Changed in: linux (Ubuntu Bionic) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu Cosmic) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Cosmic) 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/1827437 Title: potential memory corruption on arm64 on dev release Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: [Impact] Potential memory corruption. [Test Case] I've not seen a failure in practice (well, it's easy to crash 5.0 but, as the commit message notes, that's because it includes an additional patch that happens to "tickle" this. But to regression test, I boot a HiSilicon D06 to a ramdisk and remove the hisi_sas_v3_hw module, which allocates memory as described in the commit message. [Fix] 376991db4b646 driver core: Postpone DMA tear-down until after devres release [Regression Risk] From the stable tree, so in theory would be applied eventually anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827437/+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 1827437] [NEW] potential memory corruption on arm64 on dev release
Public bug reported: [Impact] Potential memory corruption. [Test Case] I've not seen a failure in practice (well, it's easy to crash 5.0 but, as the commit message notes, that's because it includes an additional patch that happens to "tickle" this. But to regression test, I boot a HiSilicon D06 to a ramdisk and remove the hisi_sas_v3_hw module, which allocates memory as described in the commit message. [Fix] 376991db4b646 driver core: Postpone DMA tear-down until after devres release [Regression Risk] >From the stable tree, so in theory would be applied eventually anyway. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Cosmic) Importance: Undecided Status: Incomplete ** Description changed: [Impact] Potential memory corruption. [Test Case] I've not seen a failure in practice (well, it's easy to crash 5.0 but, as the commit message notes, that's because it includes an additional patch that happens to "tickle" this. But to regression test, I boot a HiSilicon D06 to a ramdisk and remove the hisi_sas_v3_hw module, which allocates memory as described in the commit message. [Fix] 376991db4b646 driver core: Postpone DMA tear-down until after devres release [Regression Risk] + From the stable tree, so in theory would be applied eventually anyway. ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) 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/1827437 Title: potential memory corruption on arm64 on dev release Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: [Impact] Potential memory corruption. [Test Case] I've not seen a failure in practice (well, it's easy to crash 5.0 but, as the commit message notes, that's because it includes an additional patch that happens to "tickle" this. But to regression test, I boot a HiSilicon D06 to a ramdisk and remove the hisi_sas_v3_hw module, which allocates memory as described in the commit message. [Fix] 376991db4b646 driver core: Postpone DMA tear-down until after devres release [Regression Risk] From the stable tree, so in theory would be applied eventually anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827437/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: In Progress Status in linux source package in Disco: In Progress Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] 4e69ecf4da1ee arm64/module: ftrace: deal with place relative nature of PLTs 5a3ae7b314a22 arm64/ftrace: fix inadvertent BUG() in trampoline check [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages Mor
[Kernel-packages] [Bug 1803206] Re: Please enable CONFIG_DMA_CMA=y on arm64
Just to add a tag back, this fix is causing regressions on some server platforms in bug 1823753 -- 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/1803206 Title: Please enable CONFIG_DMA_CMA=y on arm64 Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Released Bug description: Using the generic arm64 kernel on my raspberry pi 3 it seems impossible to use any apps that require 3D graphics. The X session crashes and a reboot is needed to make it bootable again. Inspecting dmesg, there are a lot of "failed to allocate CMA" messages. Adding cma=256M to the kernel command line has no effect. Dropping resolution allows firefox to start, but 3D apps still fail. I believe the vc4 driver needs CONFIG_DMA_CMA=y, which currently the generic kernel does not set. The raspi2 kernel has this and 3D graphics works. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803206/+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 1826911] [NEW] hns: fix socket accounting
Public bug reported: [Impact] It is possible for a socket to use more memory than permitted on systems using the hns network driver. [Fix] b1ccd4c0ab6ef net: hns: fix skb->truesize underestimation [Test Case] Regression tested only. [Regression Risk] Trivial fix local to a single driver only used on ARM servers based on the Hi1616 SoC. ** Affects: linux (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: linux (Ubuntu Bionic) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Fix Released ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) 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/1826911 Title: hns: fix socket accounting Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] It is possible for a socket to use more memory than permitted on systems using the hns network driver. [Fix] b1ccd4c0ab6ef net: hns: fix skb->truesize underestimation [Test Case] Regression tested only. [Regression Risk] Trivial fix local to a single driver only used on ARM servers based on the Hi1616 SoC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826911/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
** Description changed: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] - TBD + 4e69ecf4da1ee arm64/module: ftrace: deal with place relative nature of PLTs + 5a3ae7b314a22 arm64/ftrace: fix inadvertent BUG() in trampoline check [Regression Risk] TBD ** Changed in: linux (Ubuntu) Status: Confirmed => 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: In Progress Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error:
[Kernel-packages] [Bug 1823753] Re: arm64: cma_alloc errors at boot
Note that this appears to be a regression introduced by bug 1803206. Disabling DMA_CMA avoids it - but obviously would regress bug 1803206. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
Upstream thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-April/647345.html -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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
Re: [Kernel-packages] [Bug 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45
On Tue, Apr 16, 2019 at 1:26 PM Jo Shields wrote: > > I'm an idiot and should have been trying the version from -proposed, of > course. Working on it Whups, yeah - so was I :) I thought for sure I had enabled -proposed on my D05 Anyway, I was also an idiot and didn't realize I could just check our weekly scheduled tests and see that the (correct) -proposed kernels had both booted fine on D05, so I didn't need to do that test manually. -- 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/1818294 Title: HiSilicon HNS ethernet broken in 4.15.0-45 Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.") While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load. [Test Case] dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" (With enahisic2i2 properly wired up) [Fix] This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. [Regression Risk] Restricted to the hns driver, which is only used by certain HiSilicon SOCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818294/+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
Re: [Kernel-packages] [Bug 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45
On Tue, Apr 16, 2019 at 1:50 PM Jo Shields wrote: > > OK, yes, confirmed I have ethernet with 4.15.0-48.51 Awesome, thanks! -- 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/1818294 Title: HiSilicon HNS ethernet broken in 4.15.0-45 Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.") While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load. [Test Case] dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" (With enahisic2i2 properly wired up) [Fix] This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. [Regression Risk] Restricted to the hns driver, which is only used by certain HiSilicon SOCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818294/+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 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45
@directhex: Are you able to test this on your XR320? I've regression tested on a HiSilicon D05 which uses the same driver (it worked before, still works now). ubuntu@d05-5:~$ cat /proc/version Linux version 4.15.0-47-generic (buildd@bos02-arm64-022) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #50-Ubuntu SMP Wed Mar 13 10:42:02 UTC 2019 ubuntu@d05-5:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enahisic2i0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:8c:f8:62:5b:58 brd ff:ff:ff:ff:ff:ff inet 10.228.68.94/24 brd 10.228.68.255 scope global enahisic2i0 valid_lft forever preferred_lft forever inet6 fe80::a28c:f8ff:fe62:5b58/64 scope link valid_lft forever preferred_lft forever 3: enahisic2i1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:59 brd ff:ff:ff:ff:ff:ff 4: enahisic2i2: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:5a brd ff:ff:ff:ff:ff:ff 5: enahisic2i3: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:5b brd ff:ff:ff:ff:ff:ff 6: enP10p17s0f0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ec:0d:9a:2f:d0:12 brd ff:ff:ff:ff:ff:ff 7: enP10p17s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ec:0d:9a:2f:d0:13 brd ff:ff:ff:ff:ff:ff ubuntu@d05-5:~$ cat /proc/version Linux version 4.18.0-17-generic (buildd@bos02-arm64-075) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:57 UTC 2019 ubuntu@d05-5:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enahisic2i0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:8c:f8:62:5b:58 brd ff:ff:ff:ff:ff:ff inet 10.228.68.94/24 brd 10.228.68.255 scope global enahisic2i0 valid_lft forever preferred_lft forever inet6 fe80::a28c:f8ff:fe62:5b58/64 scope link valid_lft forever preferred_lft forever 3: enahisic2i1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:59 brd ff:ff:ff:ff:ff:ff 4: enahisic2i2: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:5a brd ff:ff:ff:ff:ff:ff 5: enahisic2i3: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:8c:f8:62:5b:5b brd ff:ff:ff:ff:ff:ff 6: enP10p17s0f0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ec:0d:9a:2f:d0:12 brd ff:ff:ff:ff:ff:ff 7: enP10p17s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ec:0d:9a:2f:d0:13 brd ff:ff:ff:ff:ff:ff ** Tags removed: verification-needed-bionic verification-needed-cosmic ** Tags added: verification-done-bionic verification-done-cosmic -- 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/1818294 Title: HiSilicon HNS ethernet broken in 4.15.0-45 Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.") While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load. [Test Case] dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" (With enahisic2i2 properly wired up) [Fix] This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. [Regression Risk] Restricted to the hns driver, which is only used by certain HiSilicon SOCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818294/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
This patch resolves the problem for me, thx Ard! https://patchwork.kernel.org/patch/10899313/ -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+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
Re: [Kernel-packages] [Bug 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
On Wed, Apr 10, 2019 at 11:01 AM Ard Biesheuvel wrote: > > On Tue, 9 Apr 2019 at 16:30, dann frazier wrote: > > > > Yeah, no crash anymore - thanks Ard! > > > > ubuntu@d06-4:~$ echo function | sudo tee > > /sys/kernel/debug/tracing/current_tracer > > function > > [ 72.778123] ftrace: far branches to multiple entry points unsupported > > inside a single module > > > > ^ I assume this is expected > > > > Uhm, not really. :( > You don't have any out of tree live patching code in your kernel, right? I see the same behavior w/ just-this-patch on top of upstream: [ 431.876690] ftrace: far branches to multiple entry points unsupported inside a single module [ 431.885157] WARNING: CPU: 21 PID: 3388 at kernel/trace/ftrace.c:2008 ftrace_bug+0xb0/0x2b0 [ 431.885158] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds hns_roce_hw_v2 hns_roce ipmi_si ib_uverbs tpm_tis_spi ipmi_devintf ipmi_msghandler spi_dw_mmio spi_dw 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 ses enclosure 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 marvell aes_ce_blk aes_ce_cipher hid_generic hibmc_drm crct10dif_ce ttm ghash_ce drm_kms_helper sha2_ce syscopyarea sha256_arm64 sysfillrect sha1_ce hisi_sas_v3_hw sysimgblt ixgbe usbhid hns3 fb_sys_fops hisi_sas_main igb drm hclge libsas i2c_algo_bit hid xfrm_algo ahci mdio hnae3 scsi_transport_sas libahci hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 431.885213] CPU: 21 PID: 3388 Comm: tee Not tainted 5.1.0-rc4+ #79 [ 431.885215] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.17.01 03/30/2019 [ 431.885217] pstate: 6049 (nZCv daif +PAN -UAO) [ 431.885219] pc : ftrace_bug+0xb0/0x2b0 [ 431.885221] lr : ftrace_replace_code+0xa8/0xc0 [ 431.885222] sp : 20d6bb20 [ 431.885223] x29: 20d6bb20 x28: 97b7828e1d80 [ 431.885225] x27: x26: [ 431.885227] x25: e3d7c228 x24: 20d6bd13 [ 431.885229] x23: 0002 x22: 0001 [ 431.885231] x21: 3ed411993928 x20: 97b7c5810010 [ 431.885232] x19: 97b7c5810010 x18: [ 431.885234] x17: x16: 3ed4ff397168 [ 431.885236] x15: 3ed50005c708 x14: 7320612065646973 [ 431.885237] x13: 6e6920646574726f x12: 707075736e752073 [ 431.885239] x11: 746e696f70207972 x10: 746e6520656c7069 [ 431.885241] x9 : 3ed50005d168 x8 : 3ed4ff141588 [ 431.885243] x7 : 0945 x6 : 3ed500095308 [ 431.885244] x5 : 97b7cfaef150 x4 : 3ed4feba7480 [ 431.885246] x3 : x2 : 12122b60e4976500 [ 431.885248] x1 : 97b7c5810010 x0 : ffea [ 431.885250] Call trace: [ 431.885252] ftrace_bug+0xb0/0x2b0 [ 431.885254] ftrace_replace_code+0xa8/0xc0 [ 431.885256] ftrace_modify_all_code+0xc8/0x160 [ 431.885262] arch_ftrace_update_code+0x10/0x18 [ 431.885264] ftrace_run_update_code+0x20/0x70 [ 431.885266] ftrace_startup_enable+0x4c/0x58 [ 431.885268] ftrace_startup+0xa4/0x140 [ 431.885270] register_ftrace_function+0x64/0x80 [ 431.885272] function_trace_init+0x50/0x98 [ 431.885275] tracing_set_tracer+0x124/0x200 [ 431.885277] tracing_set_trace_write+0x10c/0x168 [ 431.885280] __vfs_write+0x48/0x80 [ 431.885281] vfs_write+0xac/0x1b8 [ 431.885283] ksys_write+0x74/0xf0 [ 431.885284] __arm64_sys_write+0x24/0x30 [ 431.885286] el0_svc_common+0x74/0x118 [ 431.885288] el0_svc_handler+0x38/0x78 [ 431.885290] el0_svc+0x8/0xc [ 431.885292] ---[ end trace d418734dc3074a2a ]--- [ 431.885294] ftrace failed to modify [ 431.885297] [] aes_decrypt+0x20/0x50 [aes_arm64] [ 431.885298] actual: 1f:20:03:d5 [ 431.885302] Setting ftrace call site to call ftrace function [ 431.885303] ftrace record flags: 8001 [ 431.885304] (1) expected tramp: 3ed4fea40c24 ** Attachment added: ".config" https://bugs.launchpad.net/bugs/1822871/+attachment/5254769/+files/.config -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:
[Kernel-packages] [Bug 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
** Changed in: linux (Ubuntu) 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+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 1824194] [NEW] hns3: PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found [error status=0x1]
Public bug reported: [Impact] Transmit errors may occur under load, resulting in device reset and an unusable NIC. [Test Case] Server: ethtool -K enp129s0f0 rx off ethtool -K enp129s0f0 gro off ifconfig enp129s0f0 mtu 1501 iperf -s Client: ethtool -K enp129s0f0 tx off ethtool -K enp129s0f0 gso off ifconfig enp129s0f0 mtu 1501 iperf -c -l 64K -t 3 [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Fix is restricted to a driver only used in Hi1620 SoC-based systems. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: 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/1824194 Title: hns3: PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found [error status=0x1] Status in linux package in Ubuntu: In Progress Bug description: [Impact] Transmit errors may occur under load, resulting in device reset and an unusable NIC. [Test Case] Server: ethtool -K enp129s0f0 rx off ethtool -K enp129s0f0 gro off ifconfig enp129s0f0 mtu 1501 iperf -s Client: ethtool -K enp129s0f0 tx off ethtool -K enp129s0f0 gso off ifconfig enp129s0f0 mtu 1501 iperf -c -l 64K -t 3 [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Fix is restricted to a driver only used in Hi1620 SoC-based systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824194/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
[ 72.778123] ftrace: far branches to multiple entry points unsupported inside a single module [ 72.786657] WARNING: CPU: 121 PID: 3299 at /home/ubuntu/linux-5.0.0/kernel/trace/ftrace.c:2008 ftrace_bug+0xb0/0x2b0 [ 72.786662] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio spi_dw ipmi_si ipmi_devintf 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 ses enclosure 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce syscopyarea sha2_ce sysfillrect sha256_arm64 ixgbe hisi_sas_v3_hw hns3 sysimgblt igb sha1_ce usbhid hisi_sas_main fb_sys_fops xfrm_algo drm hclge i2c_algo_bit hid libsas mdio hnae3 hinic ahci scsi_transport_sas gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 72.786826] CPU: 121 PID: 3299 Comm: tee Not tainted 5.0.0-9-generic #10 [ 72.786830] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.17.01 03/30/2019 [ 72.786836] pstate: 6049 (nZCv daif +PAN -UAO) [ 72.786843] pc : ftrace_bug+0xb0/0x2b0 [ 72.786850] lr : ftrace_replace_code+0xa8/0xc0 [ 72.786853] sp : 2874bb20 [ 72.786857] x29: 2874bb20 x28: f244374049c0 [ 72.786864] x27: x26: [ 72.786870] x25: cad06548 x24: 40c2c5c23000 [ 72.786876] x23: 0002 x22: 0001 [ 72.786882] x21: 40c234f5b928 x20: d23456ea0010 [ 72.786887] x19: d23456ea0010 x18: [ 72.786893] x17: x16: 40c2c4f1f810 [ 72.786898] x15: 40c2c5bec708 x14: 6c676e6973206120 [ 72.786904] x13: 656469736e692064 x12: 6574726f70707573 [ 72.786910] x11: 6e752073746e696f x10: 40c2c5bed168 [ 72.786915] x9 : 40c2c5806018 x8 : 40c2c4cc4f80 [ 72.786921] x7 : 6e61726220726166 x6 : 40c2c5c23f58 [ 72.786926] x5 : f2444db53210 x4 : 40c2c471fce8 [ 72.786932] x3 : x2 : b80552eea843d900 [ 72.786937] x1 : d23456ea0010 x0 : ffea [ 72.786944] Call trace: [ 72.786951] ftrace_bug+0xb0/0x2b0 [ 72.786957] ftrace_replace_code+0xa8/0xc0 [ 72.786964] ftrace_modify_all_code+0xb0/0x148 [ 72.786973] arch_ftrace_update_code+0x10/0x18 [ 72.786979] ftrace_run_update_code+0x20/0x70 [ 72.786986] ftrace_startup_enable+0x4c/0x58 [ 72.786992] ftrace_startup+0xa4/0x140 [ 72.786999] register_ftrace_function+0x64/0x80 [ 72.787007] function_trace_init+0x50/0x98 [ 72.787013] tracing_set_tracer+0xf4/0x1c0 [ 72.787019] tracing_set_trace_write+0x10c/0x168 [ 72.787028] __vfs_write+0x48/0x80 [ 72.787033] vfs_write+0xac/0x1b8 [ 72.787037] ksys_write+0x6c/0xd8 [ 72.787042] __arm64_sys_write+0x24/0x30 [ 72.787048] el0_svc_common+0x78/0x120 [ 72.787054] el0_svc_handler+0x38/0x78 [ 72.787061] el0_svc+0x8/0xc [ 72.787065] ---[ end trace a7f7a5b79f61f1f2 ]--- [ 72.787070] ftrace failed to modify [ 72.787079] [] aes_decrypt+0x20/0x50 [aes_arm64] [ 72.787083] actual: 1f:20:03:d5 [ 72.787094] Setting ftrace call site to call ftrace function [ 72.787097] ftrace record flags: 8001 [ 72.787101] (1) expected tramp: 40c2c45bdeb4 -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt us
[Kernel-packages] [Bug 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
Yeah, no crash anymore - thanks Ard! ubuntu@d06-4:~$ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer function [ 72.778123] ftrace: far branches to multiple entry points unsupported inside a single module ^ I assume this is expected -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+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 1823994] Re: arm64: not able to install linux-generic-hwe-18.04-edge/bionic-proposed
I have a fix staged for this, but it relies on published signed binaries that aren't present. dannf, ok the signing component appears in rejected ... will try and get to the bottom of why that happened So assigning to apw for now... ** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Andy Whitcroft (apw) ** Changed in: linux (Ubuntu) Status: In Progress => 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/1823994 Title: arm64: not able to install linux-generic-hwe-18.04-edge/bionic- proposed Status in linux package in Ubuntu: Confirmed Bug description: 1. linux-generic-hwe-18.04-edge from bionic-updates is installed: `linux-generic-hwe-18.04-edge/bionic-updates,bionic-security,now 4.18.0.16.65 arm64 [installed]` ``` $ dpkg -l |grep linux-generic ii linux-generic-hwe-18.04-edge 4.18.0.16.65 arm64Complete Generic Linux kernel and headers ``` 2. enable -proposed archive and update: ``` $ sudo add-apt-repository "deb http://ports.ubuntu.com/ubuntu-ports/ $(lsb_release -sc)-proposed main restricted" $ sudo apt update ``` 3. shows it is upgradable: ``` $ apt search --names-only linux-generic linux-generic-hwe-18.04-edge/bionic-proposed 5.0.0.8.66 arm64 [upgradable from: 4.18.0.16.65] Complete Generic Linux kernel and headers ``` 4. try to install it, but: ``` $ sudo apt install linux-generic-hwe-18.04-edge Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-generic-hwe-18.04-edge : Depends: linux-image-generic-hwe-18.04-edge (= 5.0.0.8.66) but 4.18.0.16.65 is to be installed E: Unable to correct problems, you have held broken packages. ``` 5. same happens trying to install `linux-image-generic-hwe-18.04-edge`: ``` $ sudo apt install linux-image-generic-hwe-18.04-edge Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-image-generic-hwe-18.04-edge : Depends: linux-image-5.0.0-8-generic but it is not installable E: Unable to correct problems, you have held broken packages. ``` 6. also not able to install `linux-image-5.0.0-8-generic`: ``` $ sudo apt install linux-image-5.0.0-8-generic Reading package lists... Done Building dependency tree Reading state information... Done Package linux-image-5.0.0-8-generic is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'linux-image-5.0.0-8-generic' has no installation candidate ``` more info: ~$ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 ~$ apt-cache policy linux-generic-hwe-18.04-edge linux-generic-hwe-18.04-edge: Installed: 4.18.0.16.65 Candidate: 5.0.0.8.66 Version table: 5.0.0.8.66 500 500 http://ports.ubuntu.com/ubuntu-ports bionic-proposed/main arm64 Packages *** 4.18.0.16.65 500 500 http://ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 Packages 500 http://ports.ubuntu.com/ubuntu-ports bionic-security/main arm64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823994/+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 1824016] Re: Built-Using incorrect
** Changed in: linux-signed-hwe (Ubuntu Cosmic) Status: New => Invalid ** Changed in: linux-signed-hwe (Ubuntu Disco) Status: New => Invalid ** Changed in: linux-signed-hwe-edge (Ubuntu Disco) Status: New => Invalid ** Changed in: linux-signed-hwe-edge (Ubuntu Cosmic) Status: New => Invalid ** Changed in: linux-signed (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux-signed (Ubuntu Xenial) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux-signed (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux-signed (Ubuntu Cosmic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed (Ubuntu Disco) Status: New => In Progress ** Changed in: linux-signed (Ubuntu Disco) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed-hwe (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux-signed-hwe (Ubuntu Xenial) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed-hwe (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux-signed-hwe (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed-hwe-edge (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux-signed-hwe-edge (Ubuntu Xenial) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux-signed-hwe-edge (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux-signed-hwe-edge (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Description changed: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] + Hm.. maybe if something gets added using the PACKAGE keyword in control.stub that isn't intended to be replaced gets accidentally replaced, screwing up some other control field? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1824016 Title: Built-Using incorrect Status in linux-signed package in Ubuntu: In Progress Status in linux-signed-hwe package in Ubuntu: Invalid Status in linux-signed-hwe-edge package in Ubuntu: Invalid Status in linux-signed source package in Xenial: In Progress Status in linux-signed-hwe source package in Xenial: In Progress Status in linux-signed-hwe-edge source package in Xenial: In Progress Status in linux-signed source package in Bionic: In Progress Status in linux-signed-hwe source package in Bionic: In Progress Status in linux-signed-hwe-edge source package in Bionic: In Progress Status in linux-signed source package in Cosmic: In Progress Status in linux-signed-hwe source package in Cosmic: Invalid Status in linux-signed-hwe-edge source package in Cosmic: Invalid Status in linux-signed source package in Disco: In Progress Status in linux-signed-hwe source package in Disco: Invalid Status in linux-signed-hwe-edge source package in Disco: Invalid Bug description: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] Hm.. maybe if something gets added using the PACKAGE keyword in control.stub that isn't intended to be replaced gets accidentally replaced, screwing up some other control field? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1824016/+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 1824016] Re: Built-Using incorrect
** Summary changed: - Build-Using incorrect + Built-Using incorrect -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1824016 Title: Built-Using incorrect Status in linux-signed package in Ubuntu: New Status in linux-signed-hwe package in Ubuntu: New Status in linux-signed-hwe-edge package in Ubuntu: New Status in linux-signed source package in Xenial: New Status in linux-signed-hwe source package in Xenial: New Status in linux-signed-hwe-edge source package in Xenial: New Status in linux-signed source package in Bionic: New Status in linux-signed-hwe source package in Bionic: New Status in linux-signed-hwe-edge source package in Bionic: New Status in linux-signed source package in Cosmic: New Status in linux-signed-hwe source package in Cosmic: New Status in linux-signed-hwe-edge source package in Cosmic: New Status in linux-signed source package in Disco: New Status in linux-signed-hwe source package in Disco: New Status in linux-signed-hwe-edge source package in Disco: New Bug description: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1824016/+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 1824016] Re: Build-Using incorrect
** Also affects: linux-signed (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux-signed-hwe-edge (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux-signed-hwe (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux-signed (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux-signed-hwe-edge (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux-signed-hwe (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux-signed (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux-signed-hwe-edge (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux-signed-hwe (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux-signed (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux-signed-hwe-edge (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux-signed-hwe (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1824016 Title: Build-Using incorrect Status in linux-signed package in Ubuntu: New Status in linux-signed-hwe package in Ubuntu: New Status in linux-signed-hwe-edge package in Ubuntu: New Status in linux-signed source package in Xenial: New Status in linux-signed-hwe source package in Xenial: New Status in linux-signed-hwe-edge source package in Xenial: New Status in linux-signed source package in Bionic: New Status in linux-signed-hwe source package in Bionic: New Status in linux-signed-hwe-edge source package in Bionic: New Status in linux-signed source package in Cosmic: New Status in linux-signed-hwe source package in Cosmic: New Status in linux-signed-hwe-edge source package in Cosmic: New Status in linux-signed source package in Disco: New Status in linux-signed-hwe source package in Disco: New Status in linux-signed-hwe-edge source package in Disco: New Bug description: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1824016/+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 1824016] [NEW] Build-Using incorrect
Public bug reported: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] ** Affects: linux-signed (Ubuntu) Importance: Undecided Status: New ** Affects: linux-signed-hwe (Ubuntu) Importance: Undecided Status: New ** Affects: linux-signed-hwe-edge (Ubuntu) Importance: Undecided Status: New ** Also affects: linux-meta-hwe (Ubuntu) Importance: Undecided Status: New ** Also affects: linux-signed-hwe-edge (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux-meta-hwe-edge (Ubuntu) ** No longer affects: linux-meta-hwe (Ubuntu) ** Also affects: linux-signed-hwe (Ubuntu) Importance: Undecided Status: New ** Also affects: linux-signed (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1824016 Title: Build-Using incorrect Status in linux-signed package in Ubuntu: New Status in linux-signed-hwe package in Ubuntu: New Status in linux-signed-hwe-edge package in Ubuntu: New Bug description: [Impact] The Build-Using control file field is incorrect for linux-signed-hwe & linux-signed-hwe-edge. They claim they were built against the "linux" package, but should be linux-hwe/linux-hwe-edge respectively. [Test Case] Look at the Packages file. [Fix] Detect and insert the correct package name at build time. [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1824016/+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 1823994] Re: not able to install linux-generic-hwe-18.04-edge/bionic-proposed
It appears that linux-signed-hwe-edge does not yet have the arm64 support we added to linux-signed. ** Summary changed: - not able to install linux-generic-hwe-18.04-edge/bionic-proposed + arm64: not able to install linux-generic-hwe-18.04-edge/bionic-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/1823994 Title: arm64: not able to install linux-generic-hwe-18.04-edge/bionic- proposed Status in linux package in Ubuntu: New Bug description: 1. linux-generic-hwe-18.04-edge from bionic-updates is installed: `linux-generic-hwe-18.04-edge/bionic-updates,bionic-security,now 4.18.0.16.65 arm64 [installed]` ``` $ dpkg -l |grep linux-generic ii linux-generic-hwe-18.04-edge 4.18.0.16.65 arm64Complete Generic Linux kernel and headers ``` 2. enable -proposed archive and update: ``` $ sudo add-apt-repository "deb http://ports.ubuntu.com/ubuntu-ports/ $(lsb_release -sc)-proposed main restricted" $ sudo apt update ``` 3. shows it is upgradable: ``` $ apt search --names-only linux-generic linux-generic-hwe-18.04-edge/bionic-proposed 5.0.0.8.66 arm64 [upgradable from: 4.18.0.16.65] Complete Generic Linux kernel and headers ``` 4. try to install it, but: ``` $ sudo apt install linux-generic-hwe-18.04-edge Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-generic-hwe-18.04-edge : Depends: linux-image-generic-hwe-18.04-edge (= 5.0.0.8.66) but 4.18.0.16.65 is to be installed E: Unable to correct problems, you have held broken packages. ``` 5. same happens trying to install `linux-image-generic-hwe-18.04-edge`: ``` $ sudo apt install linux-image-generic-hwe-18.04-edge Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-image-generic-hwe-18.04-edge : Depends: linux-image-5.0.0-8-generic but it is not installable E: Unable to correct problems, you have held broken packages. ``` 6. also not able to install `linux-image-5.0.0-8-generic`: ``` $ sudo apt install linux-image-5.0.0-8-generic Reading package lists... Done Building dependency tree Reading state information... Done Package linux-image-5.0.0-8-generic is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'linux-image-5.0.0-8-generic' has no installation candidate ``` more info: ~$ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 ~$ apt-cache policy linux-generic-hwe-18.04-edge linux-generic-hwe-18.04-edge: Installed: 4.18.0.16.65 Candidate: 5.0.0.8.66 Version table: 5.0.0.8.66 500 500 http://ports.ubuntu.com/ubuntu-ports bionic-proposed/main arm64 Packages *** 4.18.0.16.65 500 500 http://ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 Packages 500 http://ports.ubuntu.com/ubuntu-ports bionic-security/main arm64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823994/+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 1823753] Re: arm64: cma_alloc errors at boot
** Changed in: linux (Ubuntu) Status: Incomplete => 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Confirmed Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
I enabled CMA_DEBUG & CMA_DEBUGFS and booted w/ cma=128M so that we can see the CMA state when no allocations fail. root@d06-4:/sys/kernel/debug/cma/cma-reserved# cat count 32768 root@d06-4:/sys/kernel/debug/cma/cma-reserved# cat used 15630 Looks like we're actually using ~61M - and perhaps the alignment requirements are pushing us over the 64M barrier (cma=64M still results in some cma_alloc failures). ** Attachment added: "dmesg w/ CMA_DEBUG=y" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+attachment/5254279/+files/dmesg-cma-debug.txt -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Incomplete Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
This was not an issue prior to v4.20. Bisection identified the following commit: 886643b766321 arm64: use the generic swiotlb_dma_ops -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Incomplete Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] Re: arm64: cma_alloc errors at boot
The disco kernel uses CONFIG_CMA_SIZE_MBYTES=16, while the arm64 defconfig sets it to 32. I tried bumping up this setting by powers of 2 until the messages went away, and it finally did at 128, which seems extreme. Need to figure out what is attempting these allocations, and why they are failing. -- 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Incomplete Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1823753] [NEW] arm64: cma_alloc errors at boot
Public bug reported: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. ** Affects: linux (Ubuntu) Importance: Undecided Status: 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/1823753 Title: arm64: cma_alloc errors at boot Status in linux package in Ubuntu: Incomplete Bug description: On some arm64 systems[*] we are seeing a spew of messages on the console: [ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 [ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12 [ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12 This appears to be non-fatal - impacted systems all eventually boot. But, at least in the case of the HP m400, it slows down boot enough that MAAS' default timeout will expire before completing deployment. [*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well as an HP m400 (APM X-Gene) cartridge - although, not on another one that - in theory - should be identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+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 1821064] Re: hns3: fix oops in hns3_clean_rx_ring()
Verification: Ran netperf between 2 D06 hosts, one running the bionic- proposed kernel, the other the cosmic-proposed kernel, w/o error. ** Tags removed: verification-needed-bionic verification-needed-cosmic ** Tags added: verification-done-bionic verification-done-cosmic -- 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/1821064 Title: hns3: fix oops in hns3_clean_rx_ring() Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] kernel oops [Test Case] Run netperf between two hosts. Doesn't 100% cause a crash, but works as a regression test. [Fix] d394d33bee224 net: hns3: add dma_rmb() for rx description [Regression Risk] Restricted to a driver specific to the hi1620 SoC. Since this adds a new read barrier, there is a potential performance regression risk. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821064/+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 1819546] Re: Avoid potential memory corruption on HiSilicon SoCs
Verified - boot tested both cosmic & bionic proposed kernels on a D06 system. ** Tags removed: verification-needed-bionic verification-needed-cosmic ** Tags added: verification-don-bionic verification-done-cosmic ** Tags removed: verification-don-bionic ** Tags added: verification-done-bionic -- 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/1819546 Title: Avoid potential memory corruption on HiSilicon SoCs Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] There is a potential for memory corruption in MSI payloads. For reasons mentioned in the commit message, this happens to not be triggerable today, but is fragile, and could rear it's ugly head if a struct layout changes due to other backports in the future. [Test Case] Regression-only. [Fix] 84a9a75774961 iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads [Regression Risk] The fix is to add some explicit padding into an internal structure. This padding is already implicit today. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819546/+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 1820187] Re: Huawei Hi1822 NIC has poor performance
Marking "In Progress" for disco, as a patch was submitted: https://lists.ubuntu.com/archives/kernel-team/2019-March/099315.html ** Changed in: linux (Ubuntu Disco) Status: Incomplete => 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/1820187 Title: Huawei Hi1822 NIC has poor performance Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: [Impact] Connect Hi1822 NIC with 10G switch but the performance is only 1-2Gb/s $ iperf -c 10.228.68.133 Client connecting to 10.228.68.133, TCP port 5001 TCP window size: 85.0 KByte (default) [ 3] local 10.228.68.116 port 56810 connected with 10.228.68.133 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.53 GBytes 1.32 Gbits/sec [Test Case] iperf -c [Fix] Backporting all patches from mainline for drivers/net/ethernet/huawei solves this issue. [Regression Risk] Only modify codes in drivers/net/ethernet/huawei. Lowest risk to other devices and platform without it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820187/+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 1822897] [NEW] RDMA/hns updates for disco
Public bug reported: [Impact] A number of changes for the RDMA/hns driver landed upstream post-5.0, including a number of bug fixes, corrections for consistency w/ the hip08 SoC spec, as well as a couple new features and cleanup. I recommend we sync up the changes for disco so that we have an established base for future changes. [Test Case] Regression tested w/ perftest: = server = sudo ib_send_bw -d hns_2 -i 1 -a -F --report_gbits = client = sudo ib_send_bw -d hns_2 -i 1 -a -F --report_gbits [Fixes] 9c6ccc035c209dda07685e8dba829a203ba17499 RDMA/hns: Fix the bug with updating rq head pointer when flush cqe 4d103905eb1e4f14cb62fcf962c9d35da7005dea RDMA/hns: Bugfix for the scene without receiver queue 44754b95dd35ee07c462b5425ae9c4cde8c7e7c8 RDMA/hns: Add constraint on the setting of local ACK timeout 91fb4d83b88a7b544ce564c44167aad29d4154f0 RDMA/hns: Modify the pbl ba page size for hip08 de77503a59403e7045c18c6bb0a10c245a99b648 RDMA/hns: RDMA/hns: Assign rq head pointer when enable rq record db 2b9acb9a97fe9b4101ca020643760c4a090b4cb4 RDMA/hns: Add the process of AEQ overflow for hip08 6a157f7d1b14eb88d89fbd396cfea15ac4bded2d RDMA/hns: Add SCC context allocation support for hip08 aa84fa18741b83daf0f8f160c46ae92f4d6f1343 RDMA/hns: Add SCC context clr support for hip08 0e40dc2f70cda099e13392a26bd37aed24bcd25d RDMA/hns: Add timer allocation support for hip08 da91ddfdc7212e6e716be55a5cf2305ce84a422f RDMA/hns: Remove set but not used variable 'rst' c3c668e742397dfc107e44c09606cc68b37df30d RDMA/hns: Make some function static d061effc36f7bd38a12912977a37a50ac9140d11 RDMA/hns: Fix the Oops during rmmod or insmod ko when reset occurs 6a04aed6afaefd5fd396f23da184298135f31e37 RDMA/hns: Fix the chip hanging caused by sending mailbox&CMQ during reset d3743fa94ccd177917783726faf54632439ddb54 RDMA/hns: Fix the chip hanging caused by sending doorbell during reset 3856ec55270099494afa0cabba020365a38430a2 RDMA/hns: Use for_each_sg_dma_page iterator on umem SGL 704e0e613a6d584fde1c80ead0329e918b4f8671 RDMA/hns: Limit minimum ROCE CQ depth to 64 ab22bf05216a6bb4812448f3a8609489047cf311 RDMA/hns: Fix the state of rereg mr f7f27a5f03cc9f47cc14f75a5be25f0f26b1b5ff RDMA/hns: Set allocated memory to zero for wrid e95c716c7faa0d0eede5eabb6fea2504709e25b6 RDMA/hns: Delete useful prints for aeq subtype event dad1f9802ecee3a21143293b2505e1b57b1ae525 RDMA/hns: Configure capacity of hns device 3e394f9413ecba2779b6a1d77095f4d8611a52d2 RDMA/hns: Modify qp&cq&pd specification according to UM 6ac16e403900a98f9b330daa5f0d89f76a24c6eb RDMA/hns: Bugfix for set hem of SCC 4e69cf1fe2c52d189acdd06c1fd99cc258aba61f RDMA/hns: Use GFP_ATOMIC in hns_roce_v2_modify_qp [Regression Risk] Driver is only for HNS nics on HiSilicon SoCs ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) 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/1822897 Title: RDMA/hns updates for disco Status in linux package in Ubuntu: In Progress Bug description: [Impact] A number of changes for the RDMA/hns driver landed upstream post-5.0, including a number of bug fixes, corrections for consistency w/ the hip08 SoC spec, as well as a couple new features and cleanup. I recommend we sync up the changes for disco so that we have an established base for future changes. [Test Case] Regression tested w/ perftest: = server = sudo ib_send_bw -d hns_2 -i 1 -a -F --report_gbits = client = sudo ib_send_bw -d hns_2 -i 1 -a -F --report_gbits [Fixes] 9c6ccc035c209dda07685e8dba829a203ba17499 RDMA/hns: Fix the bug with updating rq head pointer when flush cqe 4d103905eb1e4f14cb62fcf962c9d35da7005dea RDMA/hns: Bugfix for the scene without receiver queue 44754b95dd35ee07c462b5425ae9c4cde8c7e7c8 RDMA/hns: Add constraint on the setting of local ACK timeout 91fb4d83b88a7b544ce564c44167aad29d4154f0 RDMA/hns: Modify the pbl ba page size for hip08 de77503a59403e7045c18c6bb0a10c245a99b648 RDMA/hns: RDMA/hns: Assign rq head pointer when enable rq record db 2b9acb9a97fe9b4101ca020643760c4a090b4cb4 RDMA/hns: Add the process of AEQ overflow for hip08 6a157f7d1b14eb88d89fbd396cfea15ac4bded2d RDMA/hns: Add SCC context allocation support for hip08 aa84fa18741b83daf0f8f160c46ae92f4d6f1343 RDMA/hns: Add SCC context clr support for hip08 0e40dc2f70cda099e13392a26bd37aed24bcd25d RDMA/hns: Add timer allocation support for hip08 da91ddfdc7212e6e716be55a5cf2305ce84a422f RDMA/hns: Remove set but not used variable 'rst' c3c668e742397dfc107e44c09606cc68b37df30d RDMA/hns: Make some function static d061effc36f7bd38a12912977a37a50ac9140d11 RDMA/hns: Fix the Oops during
[Kernel-packages] [Bug 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
** Changed in: linux (Ubuntu) Status: Incomplete => 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+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 1822871] Re: enabling ftrace on Hi1620 CS causes an Oops
** Summary changed: - enabling ftrace on Hi1620 causes an Oops + enabling ftrace on Hi1620 CS causes an Oops ** Description changed: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). + + This is 100% reproducible on D06 CS systems, but not reproducible on D06 + ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD -- 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/1822871 Title: enabling ftrace on Hi1620 CS causes an Oops Status in linux package in Ubuntu: Incomplete Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). This is 100% reproducible on D06 CS systems, but not reproducible on D06 ES systems (the previous silicon rev). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_s
[Kernel-packages] [Bug 1822871] Re: enabling ftrace on Hi1620 causes an Oops
Bisection led to the following commit: # first bad commit: [bdb85cd1d20669dfae813555dddb745ad09323ba] arm64/module: switch to ADRP/ADD sequences for PLT entries -- 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/1822871 Title: enabling ftrace on Hi1620 causes an Oops Status in linux package in Ubuntu: Incomplete Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822871/+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 1822871] [NEW] enabling ftrace on Hi1620 causes an Oops
Public bug reported: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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 marvell aes_ce_blk aes_ce_cipher hibmc_drm hid_generic ttm crct10dif_ce drm_kms_helper ghash_ce sha2_ce syscopyarea sha256_arm64 sysfillrect ixgbe igb sha1_ce hns3 sysimgblt usbhid fb_sys_fops hisi_sas_v3_hw hclge i2c_algo_bit xfrm_algo hisi_sas_main mdio hid drm hnae3 libsas ahci scsi_transport_sas hinic gpio_dwapb aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 3125.736544] CPU: 124 PID: 3306 Comm: tee Not tainted 5.0.0-rc4+ #12 [ 3125.742802] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.16.01 03/16/2019 [ 3125.752099] pstate: 0049 (nzcv daif +PAN -UAO) [ 3125.756893] pc : aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.762111] lr : plt_entries_equal.part.3+0x40/0x80 [ 3125.766979] sp : 2837b9f0 [ 3125.770286] x29: 2837b9f0 x28: bef4fd20d880 [ 3125.775591] x27: x26: [ 3125.780896] x25: dea2a7e8 x24: 3dceb8413000 [ 3125.786200] x23: 0002 x22: 3dce9d2289a4 [ 3125.791504] x21: 2837ba8c x20: 2837b000 [ 3125.796808] x19: 3dce9d228000 x18: [ 3125.802112] x17: x16: 3dceb7742780 [ 3125.807416] x15: 3dceb7ce7c38 x14: 0001 [ 3125.812720] x13: bef50bb9e188 x12: [ 3125.818023] x11: 7efba3e79608 x10: 0a70 [ 3125.823327] x9 : 3dceb6deeacc x8 : [ 3125.828631] x7 : 0005 x6 : 3dceb8413f10 [ 3125.833935] x5 : 002b3000 x4 : 3dceb6f4f4b8 [ 3125.839239] x3 : x2 : 9000 [ 3125.844543] x1 : x0 : [ 3125.849850] Process tee (pid: 3306, stack limit = 0x262bb476) [ 3125.856281] Call trace: [ 3125.858723] aarch64_insn_adrp_get_offset+0x34/0x38 [ 3125.863593] plt_entries_equal.part.3+0x40/0x80 [ 3125.868115] plt_entries_equal+0x5c/0x70 [ 3125.872031] ftrace_make_call+0xf0/0x150 [ 3125.875950] __ftrace_replace_code+0xe8/0xf8 [ 3125.880212] ftrace_replace_code+0x64/0xc0 [ 3125.884301] ftrace_modify_all_code+0xb0/0x148 [ 3125.888738] arch_ftrace_update_code+0x10/0x18 [ 3125.893174] ftrace_run_update_code+0x20/0x70 [ 3125.897524] ftrace_startup_enable+0x4c/0x58 [ 3125.901788] ftrace_startup+0xa4/0x140 [ 3125.905531] register_ftrace_function+0x64/0x80 [ 3125.910059] function_trace_init+0x50/0x98 [ 3125.914149] tracing_set_tracer+0xf4/0x1c0 [ 3125.918238] tracing_set_trace_write+0x10c/0x168 [ 3125.922852] __vfs_write+0x60/0x1a8 [ 3125.926333] vfs_write+0xac/0x1b8 [ 3125.929641] ksys_write+0x6c/0xd8 [ 3125.932949] __arm64_sys_write+0x24/0x30 [ 3125.936866] el0_svc_common+0x78/0x120 [ 3125.940608] el0_svc_handler+0x38/0x78 [ 3125.944349] el0_svc+0x8/0xc [ 3125.947224] Code: 97fffb33 53144c00 a8c17bfd d65f03c0 (d421) [ 3125.953312] ---[ end trace 0872d3e5933385e2 ]--- [Fix] TBD [Regression Risk] TBD ** Affects: linux (Ubuntu) Importance: Undecided Status: 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/1822871 Title: enabling ftrace on Hi1620 causes an Oops Status in linux package in Ubuntu: Incomplete Bug description: [Impact] Attempting to enable the function tracer causes an Oops. This impacts the current disco kernel, as well as latest upstream (@5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539). [Test Case] $ echo function | sudo tee /sys/kernel/debug/tracing/current_tracer [ 3125.651453] kernel BUG at arch/arm64/kernel/insn.c:1325! [ 3125.656766] Internal error: Oops - BUG: 0 [#1] SMP [ 3125.661551] Modules linked in: nls_iso8859_1 ipmi_ssif joydev input_leds tpm_tis_spi hns_roce_hw_v2 hns_roce ib_uverbs spi_dw_mmio ipmi_si spi_dw ipmi_devintf 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 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
[Kernel-packages] [Bug 1822208] Re: hns3: fix tx error w/ single byte frags
** Description changed: [Impact] - Driver will report TX errors + [Test Case] + [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Restricted to hns3 driver, only used for HiSilicon ARM SoCs. -- 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/1822208 Title: hns3: fix tx error w/ single byte frags Status in linux package in Ubuntu: In Progress Bug description: [Impact] [Test Case] [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Restricted to hns3 driver, only used for HiSilicon ARM SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822208/+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 1822680] [NEW] Detect SMP PHY control command errors
Public bug reported: [Impact] Errors from SMP PHY control commands (e.g. enabling, disabling, resetting phy links) are currently ignored. This is likely to escalate into problems later in driver initialization - mostly around reset paths. By logging a message and returning an error, it should be easier to root cause failures, as well as avoiding continued use of a phy that has failed to reset. [Test Case] Regression testing only on a system that uses a libsas-based driver (hisi_sas) [Fix] 01929a65dfa13 scsi: libsas: Check SMP PHY control function result [Regression Risk] Restricted to systems w/ libsas-based drivers (mvsas, hisi_sas, aic94xx). A possible risk is that a system was previously functioning normally even though SMP PHY control commands were failing, and now we'd be logging an error an aborting the operation. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) 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/1822680 Title: Detect SMP PHY control command errors Status in linux package in Ubuntu: In Progress Bug description: [Impact] Errors from SMP PHY control commands (e.g. enabling, disabling, resetting phy links) are currently ignored. This is likely to escalate into problems later in driver initialization - mostly around reset paths. By logging a message and returning an error, it should be easier to root cause failures, as well as avoiding continued use of a phy that has failed to reset. [Test Case] Regression testing only on a system that uses a libsas-based driver (hisi_sas) [Fix] 01929a65dfa13 scsi: libsas: Check SMP PHY control function result [Regression Risk] Restricted to systems w/ libsas-based drivers (mvsas, hisi_sas, aic94xx). A possible risk is that a system was previously functioning normally even though SMP PHY control commands were failing, and now we'd be logging an error an aborting the operation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822680/+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 1822385] [NEW] hisi_sas updates for disco
Public bug reported: A number of changes for the hisi_sas driver landed upstream post-5.0 (see below). Most of these are fixes for bugs, with a few "tidy" patches intermixed. I recommend we sync up the changes for disco so that we have an established base for future changes. 0716752a7ee1d scsi: hisi_sas: Add softreset in hisi_sas_I_T_nexus_reset() 567e0d481f8a3 scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink 782c2c01aaa07 scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port 3713f7e96cedf scsi: hisi_sas: Set PHY linkrate when disconnected 667236dc259e6 scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw 87b8498eb092d scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO 3271fc647898a scsi: hisi_sas: Change return variable type in phy_up_v3_hw() 00ad4b01191cc scsi: hisi_sas: Do some more tidy-up b0086632e64a0 scsi: hisi_sas: Use pci_irq_get_affinity() for v3 hw as experimental 34f56e847589b scsi: hisi_sas: Issue internal abort on all relevant queues 3d3c109d9d548 scsi: hisi_sas: change queue depth from 512 to 4096 19866cc0d12b6 scsi: hisi_sas: Add manual trigger for debugfs dump dab1bf2064600 scsi: hisi_sas: Add support for DIX feature for v3 hw f00a9ea36d566 scsi: hisi_sas: Add missing seq_printf() call in hisi_sas_show_row_32() bf34bf475233e scsi: hisi_sas: Fix to only call scsi_get_prot_op() for non-NULL scsi_cmnd 9c362dce84885 scsi: hisi_sas: Some misc tidy-up 975006dbbc543 scsi: hisi_sas: Correct memory allocation size for DQ debugfs b6e355afa007d scsi: hisi_sas: Fix losing directly attached disk when hot-plug af3e4db3d1691 scsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G 51f3b8abee279 scsi: hisi_sas: Remove unused parameter of function hisi_sas_alloc() 7e612893d2ae9 scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset() 571f1a2632c45 scsi: hisi_sas: shutdown axi bus to avoid exception CQ returned 06c6267f0ea1d scsi: hisi_sas: send primitive NOTIFY to SSP situation only ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) 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/1822385 Title: hisi_sas updates for disco Status in linux package in Ubuntu: In Progress Bug description: A number of changes for the hisi_sas driver landed upstream post-5.0 (see below). Most of these are fixes for bugs, with a few "tidy" patches intermixed. I recommend we sync up the changes for disco so that we have an established base for future changes. 0716752a7ee1d scsi: hisi_sas: Add softreset in hisi_sas_I_T_nexus_reset() 567e0d481f8a3 scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink 782c2c01aaa07 scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port 3713f7e96cedf scsi: hisi_sas: Set PHY linkrate when disconnected 667236dc259e6 scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw 87b8498eb092d scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO 3271fc647898a scsi: hisi_sas: Change return variable type in phy_up_v3_hw() 00ad4b01191cc scsi: hisi_sas: Do some more tidy-up b0086632e64a0 scsi: hisi_sas: Use pci_irq_get_affinity() for v3 hw as experimental 34f56e847589b scsi: hisi_sas: Issue internal abort on all relevant queues 3d3c109d9d548 scsi: hisi_sas: change queue depth from 512 to 4096 19866cc0d12b6 scsi: hisi_sas: Add manual trigger for debugfs dump dab1bf2064600 scsi: hisi_sas: Add support for DIX feature for v3 hw f00a9ea36d566 scsi: hisi_sas: Add missing seq_printf() call in hisi_sas_show_row_32() bf34bf475233e scsi: hisi_sas: Fix to only call scsi_get_prot_op() for non-NULL scsi_cmnd 9c362dce84885 scsi: hisi_sas: Some misc tidy-up 975006dbbc543 scsi: hisi_sas: Correct memory allocation size for DQ debugfs b6e355afa007d scsi: hisi_sas: Fix losing directly attached disk when hot-plug af3e4db3d1691 scsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G 51f3b8abee279 scsi: hisi_sas: Remove unused parameter of function hisi_sas_alloc() 7e612893d2ae9 scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset() 571f1a2632c45 scsi: hisi_sas: shutdown axi bus to avoid exception CQ returned 06c6267f0ea1d scsi: hisi_sas: send primitive NOTIFY to SSP situation only To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822385/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More hel
[Kernel-packages] [Bug 1822208] Re: hns3: fix tx error w/ single byte frags
** Description changed: [Impact] + Driver will report TX errors + [Test Case] + [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly + [Regression Risk] + Restricted to hns3 driver, only used for HiSilicon ARM SoCs. -- 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/1822208 Title: hns3: fix tx error w/ single byte frags Status in linux package in Ubuntu: In Progress Bug description: [Impact] Driver will report TX errors [Test Case] [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Restricted to hns3 driver, only used for HiSilicon ARM SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822208/+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 1822208] [NEW] hns3: fix tx error w/ single byte frags
Public bug reported: [Impact] Driver will report TX errors [Test Case] [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Restricted to hns3 driver, only used for HiSilicon ARM SoCs. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) 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/1822208 Title: hns3: fix tx error w/ single byte frags Status in linux package in Ubuntu: In Progress Bug description: [Impact] Driver will report TX errors [Test Case] [Fix] 5f543a54eec08 net: hns3: fix for not calculating tx bd num correctly [Regression Risk] Restricted to hns3 driver, only used for HiSilicon ARM SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822208/+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 1822005] [NEW] ARM: Add support for the SDEI interface
Public bug reported: ARM defines a Software Delegated Exception Interface (SDEI) that has various uses, including an NMI-like mechanism for firmware to interrupt the OS w/ RAS (ACPI APEI) events. Support for this has landed upstream in the 5.1 merge window. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) 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/1822005 Title: ARM: Add support for the SDEI interface Status in linux package in Ubuntu: In Progress Bug description: ARM defines a Software Delegated Exception Interface (SDEI) that has various uses, including an NMI-like mechanism for firmware to interrupt the OS w/ RAS (ACPI APEI) events. Support for this has landed upstream in the 5.1 merge window. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822005/+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 1821620] Re: Add HiSilicon SoC quirk for cpufreq
** Changed in: linux (Ubuntu Cosmic) Status: New => Invalid ** Changed in: linux (Ubuntu Bionic) 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/1821620 Title: Add HiSilicon SoC quirk for cpufreq Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Invalid Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: Fix Committed Bug description: [Impact] Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. [Test Case] Examine the exposed frequency under idle and load and make sure it looks sane: sudo cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq Note: On my test system, it happens to look sane w/o this quirk as well. This is because the undefined reads all happen to return 0x1 today, and that puts us into the avoid-divide-by-zero code path that happens to do the same thing as this quirk (report desired perf instead of actual). [Fix] 6c8d750f9784c cpufreq / cppc: Work around for Hisilicon CPPC cpufreq 1757d05f3112a ACPI / CPPC: Add a helper to get desired performance [Regression Risk] The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821620/+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 1821408] Re: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
** Changed in: linux (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: linux (Ubuntu Cosmic) Status: In Progress => Won't Fix ** Changed in: linux (Ubuntu Xenial) Status: New => Won't Fix ** Description changed: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander + This is unlikely to occur in any production environment, but has + occurred in early silicon testing. Fixing this would be helpful in those + environments. + [Test Case] See conditions in "Impact" Can be simulated with: for f in /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do - echo "3.0 Gbit" | sudo tee $f + echo "3.0 Gbit" | sudo tee $f done [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. -- 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/1821408 Title: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Won't Fix Status in linux source package in Bionic: Won't Fix Status in linux source package in Cosmic: Won't Fix Status in linux source package in Disco: In Progress Bug description: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander This is unlikely to occur in any production environment, but has occurred in early silicon testing. Fixing this would be helpful in those environments. [Test Case] See conditions in "Impact" Can be simulated with: for f in /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do echo "3.0 Gbit" | sudo tee $f done [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1821408] Re: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Bionic) 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/1821408 Title: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: New Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: In Progress Bug description: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" Can be simulated with: for f in /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do echo "3.0 Gbit" | sudo tee $f done [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1821408] Re: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
** Description changed: [Impact] SATA disks may be unusable will not be usable when: - - The disk is connected through a SAS expander - - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - - link rate between expander & disk is greater than link between controller and expander + - The disk is connected through a SAS expander + - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) + - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" + + Can be simulated with: + for f in /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do + echo "3.0 Gbit" | sudo tee $f + done [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. -- 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/1821408 Title: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: New Status in linux source package in Bionic: New Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Bug description: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" Can be simulated with: for f in /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do echo "3.0 Gbit" | sudo tee $f done [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1821620] Re: Add HiSilicon SoC quirk for cpufreq
** Description changed: [Impact] - Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. + Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. [Test Case] + Examine the exposed frequency under idle and load and make sure it looks sane: + sudo cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq + + Note: On my test system, it happens to look sane w/o this quirk as well. + This is because the undefined reads all happen to return 0x1 today, and + that puts us into the avoid-divide-by-zero code path that happens to do + the same thing as this quirk (report desired perf instead of actual). [Fix] + 6c8d750f9784c cpufreq / cppc: Work around for Hisilicon CPPC cpufreq + 1757d05f3112a ACPI / CPPC: Add a helper to get desired performance [Regression Risk] The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. -- 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/1821620 Title: Add HiSilicon SoC quirk for cpufreq Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: New Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Bug description: [Impact] Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. [Test Case] Examine the exposed frequency under idle and load and make sure it looks sane: sudo cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq Note: On my test system, it happens to look sane w/o this quirk as well. This is because the undefined reads all happen to return 0x1 today, and that puts us into the avoid-divide-by-zero code path that happens to do the same thing as this quirk (report desired perf instead of actual). [Fix] 6c8d750f9784c cpufreq / cppc: Work around for Hisilicon CPPC cpufreq 1757d05f3112a ACPI / CPPC: Add a helper to get desired performance [Regression Risk] The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821620/+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 1821620] [NEW] Add HiSilicon SoC quirk for cpufreq
Public bug reported: [Impact] Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. [Test Case] [Fix] [Regression Risk] The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Affects: linux (Ubuntu Disco) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1821620 Title: Add HiSilicon SoC quirk for cpufreq Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: New Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Bug description: [Impact] Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs. [Test Case] [Fix] [Regression Risk] The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821620/+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 1821408] Re: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
This change should qualify for an SRU. However, Canonical does not have the described hardware. We will need help from Huawei to test the SRU. Can Huawei commit to the following steps? 1) Test a PPA build with this fix (both 4.15 and 4.18) by 2019-03-27. Canonical can prepare this PPA. 2) After official Ubuntu kernel build, re-test both kernels to verify the fix. During the week of 2019-04-08. -- 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/1821408 Title: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: New Status in linux source package in Bionic: New Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Bug description: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1821408] [NEW] scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
Public bug reported: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Affects: linux (Ubuntu Disco) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Disco) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) 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/1821408 Title: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: New Status in linux source package in Bionic: New Status in linux source package in Cosmic: New Status in linux source package in Disco: In Progress Bug description: [Impact] SATA disks may be unusable will not be usable when: - The disk is connected through a SAS expander - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas) - link rate between expander & disk is greater than link between controller and expander [Test Case] See conditions in "Impact" [Fix] cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [Regression Risk] Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas. Code change is all within an "if" statement that meets these restrictions. A bug in this code could possibly reduce the speed of an otherwise working disk connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1817969] Re: hns3 nic speed may not match optical port speed
Sorry, previous one was bionic. This is cosmic: ubuntu@d06-2:~$ cat /proc/version Linux version 4.18.0-17-generic (buildd@bos02-arm64-075) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:57 UTC 2019 ubuntu@d06-2:~$ sudo ethtool enp125s0f1 Settings for enp125s0f1: Supported ports: [ FIBRE ] Supported link modes: 25000baseSR/Full 1000baseX/Full 1baseSR/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: off Link detected: yes ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1817969 Title: hns3 nic speed may not match optical port speed Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The onboard optical NICs on HiSilicon D06 systems do not adjust to match the actual optical module speed. [Test Case] Verify that linked speed of interface matches the optical port speed. [Fix] 5d497936756fa net: hns3: Config NIC port speed same as that of optical module [Regression Risk] Fix is restricted to a driver that is only used for the Hi1620 SoC. Note: for pre-GA hardware, this does require a firmware fix as well. Without it, users will see messages like this on the console: [ 769.833818] hns3 :bd:00.0: get sfp speed failed -5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817969/+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 1817969] Re: hns3 nic speed may not match optical port speed
cosmic verification: ubuntu@d06-2:~$ cat /proc/version Linux version 4.15.0-47-generic (buildd@bos02-arm64-022) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #50-Ubuntu SMP Wed Mar 13 10:42:02 UTC 2019 ubuntu@d06-2:~$ sudo ethtool enp125s0f1 Settings for enp125s0f1: Supported ports: [ FIBRE ] Supported link modes: 25000baseSR/Full 1000baseX/Full 1baseSR/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: off Link detected: yes ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1817969 Title: hns3 nic speed may not match optical port speed Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The onboard optical NICs on HiSilicon D06 systems do not adjust to match the actual optical module speed. [Test Case] Verify that linked speed of interface matches the optical port speed. [Fix] 5d497936756fa net: hns3: Config NIC port speed same as that of optical module [Regression Risk] Fix is restricted to a driver that is only used for the Hi1620 SoC. Note: for pre-GA hardware, this does require a firmware fix as well. Without it, users will see messages like this on the console: [ 769.833818] hns3 :bd:00.0: get sfp speed failed -5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817969/+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 1821064] Re: hns3: fix oops in hns3_clean_rx_ring()
** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => High ** Changed in: linux (Ubuntu Cosmic) 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/1821064 Title: hns3: fix oops in hns3_clean_rx_ring() Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: [Impact] kernel oops [Test Case] Run netperf between two hosts. Doesn't 100% cause a crash, but works as a regression test. [Fix] d394d33bee224 net: hns3: add dma_rmb() for rx description [Regression Risk] Restricted to a driver specific to the hi1620 SoC. Since this adds a new read barrier, there is a potential performance regression risk. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821064/+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 1821064] [NEW] hns3: fix oops in hns3_clean_rx_ring()
Public bug reported: [Impact] kernel oops [Test Case] Run netperf between two hosts. Doesn't 100% cause a crash, but works as a regression test. [Fix] d394d33bee224 net: hns3: add dma_rmb() for rx description [Regression Risk] Restricted to a driver specific to the hi1620 SoC. Since this adds a new read barrier, there is a potential performance regression risk. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: Fix Released ** Affects: linux (Ubuntu Bionic) Importance: High Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Bionic) 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/1821064 Title: hns3: fix oops in hns3_clean_rx_ring() Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] kernel oops [Test Case] Run netperf between two hosts. Doesn't 100% cause a crash, but works as a regression test. [Fix] d394d33bee224 net: hns3: add dma_rmb() for rx description [Regression Risk] Restricted to a driver specific to the hi1620 SoC. Since this adds a new read barrier, there is a potential performance regression risk. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821064/+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 1817784] Re: libsas disks can have non-unique by-path names
Sorry, I'm unable to verify this for xenial. I submitted it as an SRU back to 4.4 because it had already landed in the stable queue for 4.4, and is a trivial change[*]. I think we'd need a system that either uses mvsas or aix94xx to actually exercise this libsas code on 4.4. I do have a system that uses the hisi_sas driver, which also uses libsas. That driver did not exist in 4.4. I gave backporting that driver a go, but it was coded w/ the pci_irq_vector API that came later. [*] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable- queue.git/tree/queue-4.4/scsi-libsas-fix-rphy-phy_identifier-for-phys- with-end-devices-attached.patch -- 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/1817784 Title: libsas disks can have non-unique by-path names Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: [Impact] Multiple disks in a system can end up having the same BY_PATH name, making the corresponding symlinks in /dev/disk/by-path non-unique. This can result in a user performing an operation on the wrong disk, possibly resulting in data loss. [Test Case] $ ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part3 -> ../../sdc3 Notice that there is no symlink for /dev/sdc. [Fix] ffeafdd2bf0b2 scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached [Regression Risk] This may change the by-path symlinks for disks on the system. While the new name would be the correct one - users maybe relying on the incorrect version. This could result in an unbootable system, requiring manual intervention to repair. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817784/+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 1818162] Re: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout
= cosmic verification = After running cert: ubuntu@d06-4:~$ cat /proc/version Linux version 4.18.0-17-generic (buildd@bos02-arm64-075) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:57 UTC 2019 ubuntu@d06-4:~$ dmesg | grep CMD_SYNC ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1818162 Title: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] During heavy load, the following message may appear on the console of a HiSilicon D06 system: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout This is due to a bug that can also impact system performance, as the CPU is blocked until the timeout occurs. [Test Case] The Ubuntu server certification test suite hits this pretty reliably during the stress-ng tests, although I haven't narrowed it down to exactly which test yet. [Fix] 0f02477d16980 iommu/arm-smmu-v3: Fix unexpected CMD_SYNC timeout [Regression Risk] Limited to arm64 systems. This change has been upstream since 4.20 w/o any noticed regressions (based on lack of Fixes: commits). Regressions could manifest as a performance hit. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818162/+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 1818747] Re: Crash in nvme_irq_check() when using threaded interrupts
** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1818747 Title: Crash in nvme_irq_check() when using threaded interrupts Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] kernel crashes under load w/ nvme.use_threaded_interrupts=1 [Test Case] Boot w/ nvme.use_threaded_interrupts=1 sudo fio -name=randread -numjobs=8 -filename=/dev/nvme0n1 -rw=randread -ioengine=libaio -direct=1 -iodepth=64 -sync=0 -norandommap -group_reporting -runtime=300 -time_based -bs=4k [ 284.756476] CPU: 0 PID: 1047 Comm: irq/97-nvme0q1 Not tainted 4.18.0-15-generic #16~18.04.1-Ubuntu [ 284.765420] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.13.01 02/14/2019 [ 284.773930] pstate: 00400089 (nzcv daIf +PAN -UAO) [ 284.778711] pc : nvme_irq_check+0x30/0x48 [nvme] [ 284.783319] lr : __handle_irq_event_percpu+0x68/0x228 [ 284.788356] sp : 08003e70 [Fix] dcca166272722 nvme-pci: fix out of bounds access in nvme_cqe_pending [Regression Risk] Restricted to systems w/ NVMe. There are no upstream patches marked as Fixing the upstream change, which suggests it is not yet know to introduce regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818747/+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 1818747] Re: Crash in nvme_irq_check() when using threaded interrupts
** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1818747 Title: Crash in nvme_irq_check() when using threaded interrupts Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] kernel crashes under load w/ nvme.use_threaded_interrupts=1 [Test Case] Boot w/ nvme.use_threaded_interrupts=1 sudo fio -name=randread -numjobs=8 -filename=/dev/nvme0n1 -rw=randread -ioengine=libaio -direct=1 -iodepth=64 -sync=0 -norandommap -group_reporting -runtime=300 -time_based -bs=4k [ 284.756476] CPU: 0 PID: 1047 Comm: irq/97-nvme0q1 Not tainted 4.18.0-15-generic #16~18.04.1-Ubuntu [ 284.765420] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.13.01 02/14/2019 [ 284.773930] pstate: 00400089 (nzcv daIf +PAN -UAO) [ 284.778711] pc : nvme_irq_check+0x30/0x48 [nvme] [ 284.783319] lr : __handle_irq_event_percpu+0x68/0x228 [ 284.788356] sp : 08003e70 [Fix] dcca166272722 nvme-pci: fix out of bounds access in nvme_cqe_pending [Regression Risk] Restricted to systems w/ NVMe. There are no upstream patches marked as Fixing the upstream change, which suggests it is not yet know to introduce regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818747/+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 1817784] Re: libsas disks can have non-unique by-path names
cosmic verification: ubuntu@d06-1:~$ cat /proc/version Linux version 4.18.0-17-generic (buildd@bos02-arm64-075) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:57 UTC 2019 ubuntu@d06-1:~$ ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 9 Mar 19 18:09 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0 -> ../../sdb lrwxrwxrwx 1 root root 10 Mar 19 18:09 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Mar 19 18:11 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 9 Mar 19 18:09 pci-:74:02.0-sas-exp0x500e004aaa1f-phy8-lun-0 -> ../../sdc lrwxrwxrwx 1 root root 9 Mar 19 18:09 pci-:7a:01.0-usb-0:1.3:1.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx 1 root root 10 Mar 19 18:09 pci-:7a:01.0-usb-0:1.3:1.0-scsi-0:0:0:0-part1 -> ../../sda1 bionic verification: ubuntu@d06-1:~$ cat /proc/version Linux version 4.15.0-47-generic (buildd@bos02-arm64-022) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #50-Ubuntu SMP Wed Mar 13 10:42:02 UTC 2019 ubuntu@d06-1:~$ ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 9 Mar 19 18:39 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0 -> ../../sda lrwxrwxrwx 1 root root 10 Mar 19 18:39 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Mar 19 18:41 pci-:74:02.0-sas-exp0x500e004aaa1f-phy5-lun-0-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Mar 19 18:39 pci-:74:02.0-sas-exp0x500e004aaa1f-phy8-lun-0 -> ../../sdb lrwxrwxrwx 1 root root 9 Mar 19 18:39 pci-:7a:01.0-usb-0:1.3:1.0-scsi-0:0:0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Mar 19 18:39 pci-:7a:01.0-usb-0:1.3:1.0-scsi-0:0:0:0-part1 -> ../../sdc1 ** Tags removed: verification-needed-bionic verification-needed-cosmic ** Tags added: verification-done-bionic verification-done-cosmic -- 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/1817784 Title: libsas disks can have non-unique by-path names Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: [Impact] Multiple disks in a system can end up having the same BY_PATH name, making the corresponding symlinks in /dev/disk/by-path non-unique. This can result in a user performing an operation on the wrong disk, possibly resulting in data loss. [Test Case] $ ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part3 -> ../../sdc3 Notice that there is no symlink for /dev/sdc. [Fix] ffeafdd2bf0b2 scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached [Regression Risk] This may change the by-path symlinks for disks on the system. While the new name would be the correct one - users maybe relying on the incorrect version. This could result in an unbootable system, requiring manual intervention to repair. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817784/+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 1818162] Re: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout
= bionic verification = After running cert: ubuntu@d06-4:~$ cat /proc/version Linux version 4.15.0-47-generic (buildd@bos02-arm64-022) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #50-Ubuntu SMP Wed Mar 13 10:42:02 UTC 2019 ubuntu@d06-4:~$ dmesg | grep CMD_SYNC ubuntu@d06-4:~$ ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1818162 Title: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] During heavy load, the following message may appear on the console of a HiSilicon D06 system: arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout This is due to a bug that can also impact system performance, as the CPU is blocked until the timeout occurs. [Test Case] The Ubuntu server certification test suite hits this pretty reliably during the stress-ng tests, although I haven't narrowed it down to exactly which test yet. [Fix] 0f02477d16980 iommu/arm-smmu-v3: Fix unexpected CMD_SYNC timeout [Regression Risk] Limited to arm64 systems. This change has been upstream since 4.20 w/o any noticed regressions (based on lack of Fixes: commits). Regressions could manifest as a performance hit. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818162/+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 1817969] Re: hns3 nic speed may not match optical port speed
** Changed in: linux (Ubuntu Disco) 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/1817969 Title: hns3 nic speed may not match optical port speed Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: [Impact] The onboard optical NICs on HiSilicon D06 systems do not adjust to match the actual optical module speed. [Test Case] Verify that linked speed of interface matches the optical port speed. [Fix] 5d497936756fa net: hns3: Config NIC port speed same as that of optical module [Regression Risk] Fix is restricted to a driver that is only used for the Hi1620 SoC. Note: for pre-GA hardware, this does require a firmware fix as well. Without it, users will see messages like this on the console: [ 769.833818] hns3 :bd:00.0: get sfp speed failed -5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817969/+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 1816425] Re: Use memblock quirk instead of delayed allocation for GICv3 LPI tables
Verified - I was able to successfully crash dump a cosmic system. ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1816425 Title: Use memblock quirk instead of delayed allocation for GICv3 LPI tables Status in linux package in Ubuntu: Fix Committed Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: [Impact] The fix for LP: #1806766 has the issue that the persistent memory reservations for the GICv3 LPI tables may have been allocated an overwritten by the time we get to reserving them. This can continue to break kdump in certain conditions. [Test Case] sudo apt install linux-crashdump echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=512M"' | \ sudo tee /etc/default/grub.d/kdump-tools.cfg sudo update-grub sudo reboot echo 1 | sudo tee /proc/sys/kernel/sysrq echo c | sudo tee /proc/sysrq-trigger [Fix] 582a32e708823 efi/arm: Revert "Defer persistent reservations until after paging_init()" 8a5b403d71aff arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table [Regression Risk] The change in reserved regions only impacts arm64. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1816425/+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 1819546] [NEW] Avoid potential memory corruption on HiSilicon SoCs
Public bug reported: [Impact] There is a potential for memory corruption in MSI payloads. For reasons mentioned in the commit message, this happens to not be triggerable today, but is fragile, and could rear it's ugly head if a struct layout changes due to other backports in the future. [Test Case] Regression-only. [Fix] 84a9a75774961 iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads [Regression Risk] The fix is to add some explicit padding into an internal structure. This padding is already implicit today. ** Affects: linux (Ubuntu) Importance: Medium Status: Fix Released ** Affects: linux (Ubuntu Bionic) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Cosmic) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Affects: linux (Ubuntu Disco) Importance: Medium Status: Fix Released ** Also affects: linux (Ubuntu Disco) Importance: Medium Assignee: dann frazier (dannf) Status: Fix Released ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Disco) Assignee: dann frazier (dannf) => (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/1819546 Title: Avoid potential memory corruption on HiSilicon SoCs Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: Fix Released Bug description: [Impact] There is a potential for memory corruption in MSI payloads. For reasons mentioned in the commit message, this happens to not be triggerable today, but is fragile, and could rear it's ugly head if a struct layout changes due to other backports in the future. [Test Case] Regression-only. [Fix] 84a9a75774961 iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads [Regression Risk] The fix is to add some explicit padding into an internal structure. This padding is already implicit today. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819546/+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 1819535] [NEW] [disco] hns driver updates from 5.1 merge window
Public bug reported: Sync up the hns drivers with the 5.1 merge window. (Cut & paste from bug 1810457) Drivers for the HiSilicon Hi1616 and Hi1620 SoCs continue to be under active development, including both hardware enablement and bug fix patches. With the amount of flux involved, identifying and cherry-picking individual patches would be more error prone then re-syncing with current upstream. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: 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/1819535 Title: [disco] hns driver updates from 5.1 merge window Status in linux package in Ubuntu: In Progress Bug description: Sync up the hns drivers with the 5.1 merge window. (Cut & paste from bug 1810457) Drivers for the HiSilicon Hi1616 and Hi1620 SoCs continue to be under active development, including both hardware enablement and bug fix patches. With the amount of flux involved, identifying and cherry-picking individual patches would be more error prone then re-syncing with current upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819535/+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 1819500] Re: hisi_sas: add debugfs support
** Description changed: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] - echo "options hisi_sas_main hisi_sas_debugfs_enable=1" | \ - sudo tee /etc/modprobe.d/hisi-sas-debugfs.conf + echo "options hisi_sas_main debugfs_enable=1" | \ + sudo tee /etc/modprobe.d/hisi-sas-debugfs.conf sudo mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r) sudo reboot [...] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. -- 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/1819500 Title: hisi_sas: add debugfs support Status in linux package in Ubuntu: In Progress Bug description: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] echo "options hisi_sas_main debugfs_enable=1" | \ sudo tee /etc/modprobe.d/hisi-sas-debugfs.conf sudo mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r) sudo reboot [...] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819500/+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 1819500] Re: hisi_sas: add debugfs support
** Description changed: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] + echo "options hisi_sas_main hisi_sas_debugfs_enable=1" | \ + sudo tee /etc/modprobe.d/hisi-sas-debugfs.conf + sudo mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r) + sudo reboot + [...] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. -- 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/1819500 Title: hisi_sas: add debugfs support Status in linux package in Ubuntu: In Progress Bug description: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] echo "options hisi_sas_main debugfs_enable=1" | \ sudo tee /etc/modprobe.d/hisi-sas-debugfs.conf sudo mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r) sudo reboot [...] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819500/+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 1819500] [NEW] hisi_sas: add debugfs support
Public bug reported: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: 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/1819500 Title: hisi_sas: add debugfs support Status in linux package in Ubuntu: In Progress Bug description: [Impact] Per https://patchwork.kernel.org/cover/10737541/ : "Every controller HW version has had bugs. These bugs have been very painful to debug. One useful tool to debug these is being able to capture and export HW registers and driver control structures at point of failure." [Test Case] test -d /sys/kernel/debug/hisi_sas [Fix] 5979f33b982dc scsi: hisi_sas: Add debugfs ITCT file and add file operations 5b0eeac4bed4b scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code c2c7e74057715 scsi: hisi_sas: No need to check return value of debugfs_create functions 1afb4b8524797 scsi: hisi_sas: Add debugfs IOST file and add file operations 148e379f60c5c scsi: hisi_sas: Add debugfs DQ file and add file operations 971afae7cf4f7 scsi: hisi_sas: Add debugfs CQ file and add file operations 61a6ebf3f5842 scsi: hisi_sas: Add debugfs for port registers caefac1996764 scsi: hisi_sas: Debugfs global register create file and add file operations 49159a5e4175f scsi: hisi_sas: Take debugfs snapshot for all regs eb1c2b72b7694 scsi: hisi_sas: Alloc debugfs snapshot buffer memory for all registers ef63464bcf8fe scsi: hisi_sas: Create root and device debugfs directories [Regression Risk] Code changes are restricted to the on-chip SAS controller on hi1620 SoCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819500/+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
Re: [Kernel-packages] [Bug 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45
On Fri, Mar 8, 2019 at 2:00 PM Jo Shields wrote: > > This'll filter through to the HWE kernel in Xenial without needing to be > individually tracked in this bug (or a new one), right? That is correct. -- 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/1818294 Title: HiSilicon HNS ethernet broken in 4.15.0-45 Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: Fix Released Bug description: [Impact] The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.") While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load. [Test Case] dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" (With enahisic2i2 properly wired up) [Fix] This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. [Regression Risk] Restricted to the hns driver, which is only used by certain HiSilicon SOCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818294/+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 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45
** Description changed: - A number of HiSilicon patches were backported in - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810457 from - 5.0rc1. + [Impact] + The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: - Subsequently, I lost networking on my Huawei TaiShan XR320 boards. + 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko + after rmmod.") - There are 6 commits to drivers/net/ethernet/hisilicon/hns between 5.0rc1 - and (current) 5.0rc8 - and I know my networking works fine with a 5.0rc8 - mainline build. + While that fixed an issue with phys after reloading the driver, it + caused an issue with some phys on initial load. - Can we do another update run for the next 4.15.0 kernel service release, - to include HiSilicon changes from 5.0rc8? + [Test Case] + dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" + (With enahisic2i2 properly wired up) - CC @dannf - --- - AlsaDevices: - total 0 - crw-rw+ 1 root audio 116, 1 Mar 6 10:17 seq - crw-rw+ 1 root audio 116, 33 Mar 6 10:17 timer - AplayDevices: Error: [Errno 2] No such file or directory - ApportVersion: 2.20.1-0ubuntu2.18 - Architecture: arm64 - ArecordDevices: Error: [Errno 2] No such file or directory - AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: - DistroRelease: Ubuntu 16.04 - HibernationDevice: RESUME=UUID=1422a627-9a9e-4928-ae58-8c33759cd27f - IwConfig: Error: [Errno 2] No such file or directory - MachineType: Huawei XR320 - Package: linux (not installed) - PciMultimedia: - - ProcEnviron: - TERM=linux - PATH=(custom, no user) - LANG=en_US.UTF-8 - SHELL=/bin/bash - ProcFB: 0 hibmcdrmfb - ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-43-generic root=UUID=55387aff-49ec-4252-80e0-c77e039d342f ro - ProcVersionSignature: Ubuntu 4.15.0-43.46~16.04.1-generic 4.15.18 - RelatedPackageVersions: - linux-restricted-modules-4.15.0-43-generic N/A - linux-backports-modules-4.15.0-43-generic N/A - linux-firmware 1.157.21 - RfKill: Error: [Errno 2] No such file or directory - Tags: xenial xenial xenial xenial - Uname: Linux 4.15.0-43-generic aarch64 - UpgradeStatus: No upgrade log present (probably fresh install) - UserGroups: - - _MarkForUpload: True - dmi.bios.date: 08/07/2018 - dmi.bios.vendor: Huawei - dmi.bios.version: 1.54 - dmi.board.asset.tag: To be filled by O.E.M. - dmi.board.name: BC81HPNA - dmi.board.vendor: Huawei - dmi.board.version: VER.A - dmi.chassis.asset.tag: To be filled by O.E.M. - dmi.chassis.type: 17 - dmi.chassis.vendor: Huawei - dmi.chassis.version: To be filled by O.E.M. - dmi.modalias: dmi:bvnHuawei:bvr1.54:bd08/07/2018:svnHuawei:pnXR320:pvrV100R001C00:rvnHuawei:rnBC81HPNA:rvrVER.A:cvnHuawei:ct17:cvrTobefilledbyO.E.M.: - dmi.product.family: To be filled by O.E.M. - dmi.product.name: XR320 - dmi.product.version: V100R001C00 - dmi.sys.vendor: Huawei + [Fix] + This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. + + [Regression Risk] + Restricted to the hns driver, which is only used by certain HiSilicon SOCs. -- 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/1818294 Title: HiSilicon HNS ethernet broken in 4.15.0-45 Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: Fix Released Bug description: [Impact] The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by: 308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.") While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load. [Test Case] dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up" (With enahisic2i2 properly wired up) [Fix] This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue. [Regression Risk] Restricted to the hns driver, which is only used by certain HiSilicon SOCs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818294/+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/ListH