[Kernel-packages] [Bug 1830815] [NEW] Hi1620 driver updates from upstream 5.2 merge window

2019-05-28 Thread dann frazier
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

2019-05-24 Thread dann frazier
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

2019-05-24 Thread dann frazier
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

2019-05-23 Thread dann frazier
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

2019-05-23 Thread dann frazier
** 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

2019-05-22 Thread dann frazier
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

2019-05-22 Thread dann frazier
** 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

2019-05-22 Thread dann frazier
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

2019-05-21 Thread dann frazier
** 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

2019-05-21 Thread dann frazier
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

2019-05-17 Thread dann frazier
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

2019-05-17 Thread dann frazier
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

2019-05-16 Thread dann frazier
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

2019-05-16 Thread dann frazier
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

2019-05-16 Thread dann frazier
** 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

2019-05-15 Thread dann frazier
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

2019-05-14 Thread dann frazier
@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

2019-05-14 Thread dann frazier
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

2019-05-13 Thread dann frazier
** 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

2019-05-13 Thread dann frazier
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

2019-05-10 Thread dann frazier
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

2019-05-10 Thread dann frazier
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

2019-05-09 Thread dann frazier
** 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

2019-05-07 Thread dann frazier
** 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

2019-05-07 Thread dann frazier
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

2019-05-07 Thread dann frazier
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

2019-05-07 Thread dann frazier
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

2019-05-06 Thread dann frazier
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

2019-05-06 Thread dann frazier
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

2019-05-06 Thread dann frazier
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

2019-05-03 Thread dann frazier
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

2019-05-02 Thread dann frazier
** 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

2019-05-02 Thread dann frazier
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

2019-04-30 Thread dann frazier
** 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

2019-04-30 Thread dann frazier
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

2019-04-29 Thread dann frazier
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

2019-04-26 Thread dann frazier
** 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

2019-04-24 Thread dann frazier
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

2019-04-17 Thread dann frazier
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

2019-04-16 Thread dann frazier
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

2019-04-16 Thread dann frazier
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

2019-04-16 Thread dann frazier
@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

2019-04-15 Thread dann frazier
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

2019-04-10 Thread dann frazier
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

2019-04-10 Thread dann frazier
** 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]

2019-04-10 Thread dann frazier
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

2019-04-09 Thread dann frazier
[   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

2019-04-09 Thread dann frazier
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

2019-04-09 Thread dann frazier
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

2019-04-09 Thread dann frazier
** 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

2019-04-09 Thread dann frazier
** 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

2019-04-09 Thread dann frazier
** 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

2019-04-09 Thread dann frazier
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

2019-04-09 Thread dann frazier
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

2019-04-08 Thread dann frazier
** 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

2019-04-08 Thread dann frazier
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

2019-04-08 Thread dann frazier
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

2019-04-08 Thread dann frazier
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

2019-04-08 Thread dann frazier
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()

2019-04-04 Thread dann frazier
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

2019-04-04 Thread dann frazier
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

2019-04-04 Thread dann frazier
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

2019-04-02 Thread dann frazier
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

2019-04-02 Thread dann frazier
** 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

2019-04-02 Thread dann frazier
** 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

2019-04-02 Thread dann frazier
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

2019-04-02 Thread dann frazier
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

2019-04-01 Thread dann frazier
** 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

2019-04-01 Thread dann frazier
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

2019-03-29 Thread dann frazier
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

2019-03-28 Thread dann frazier
** 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

2019-03-28 Thread dann frazier
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

2019-03-27 Thread dann frazier
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

2019-03-27 Thread dann frazier
** 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

2019-03-27 Thread dann frazier
** 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

2019-03-25 Thread dann frazier
** 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

2019-03-25 Thread dann frazier
** 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

2019-03-25 Thread dann frazier
** 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

2019-03-25 Thread dann frazier
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

2019-03-22 Thread dann frazier
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

2019-03-22 Thread dann frazier
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

2019-03-20 Thread dann frazier
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

2019-03-20 Thread dann frazier
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()

2019-03-20 Thread dann frazier
** 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()

2019-03-20 Thread dann frazier
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

2019-03-20 Thread dann frazier
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

2019-03-19 Thread dann frazier
= 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

2019-03-19 Thread dann frazier
** 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

2019-03-19 Thread dann frazier
** 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

2019-03-19 Thread dann frazier
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

2019-03-19 Thread dann frazier
= 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

2019-03-18 Thread dann frazier
** 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

2019-03-18 Thread dann frazier
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

2019-03-11 Thread dann frazier
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

2019-03-11 Thread dann frazier
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

2019-03-11 Thread dann frazier
** 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

2019-03-11 Thread dann frazier
** 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

2019-03-11 Thread dann frazier
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

2019-03-08 Thread dann frazier
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

2019-03-08 Thread dann frazier
** 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

<    2   3   4   5   6   7   8   9   10   11   >