[Bug 1706630] Re: aarch64: MSI is not supported by interrupt controller

@admcleod : Any updates on Pike testing with qemu2.10 mentioned in comm #9 ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1706630 Title: aarch64: MSI is not supported by interrupt controller To

[Bug 1709920] Re: criu is not built for arm64

@stgraber ; From comment #3, who's the right person/team to lead Xenial SRU, now that criu seems to have landed in Artful ? Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1709920 Title: criu

[Bug 1673564] Re: ThunderX: soft lockup on 4.8+ kernels when running qemu-efi with vhost=on

Backporting to the Xenial (Ubntu 16.04) kernel isn't feasible. 16.04 users are requested to use the hwe-z kernel as noted in the following Wiki page : https://wiki.ubuntu.com/HardwareSupport/Machines/Servers/Cavium/ThunderXCRB1S ** Changed in: linux (Ubuntu Xenial) Status: Confirmed => Fix

[Bug 1706735] Re: lmbench tcp lib backlog reservation too small, can cause hang.

** Tags added: cn99xx -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1706735 Title: lmbench tcp lib backlog reservation too small, can cause hang. To manage notifications about this bug go to:

[Bug 1709920] Re: criu is not built for arm64

** Tags added: arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1709920 Title: criu is not built for arm64 To manage notifications about this bug go to:

[Bug 1702979] Re: Deeply layered Docker image problems

Hi @Edward Vielmetti : Trying to follow up to see if you had a chance to test. Many thanks for the help! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702979 Title: Deeply layered Docker image

[Bug 1702979] Re: Deeply layered Docker image problems

Hi @Edward Vielmetti : Would it be possible for you to test the fix uploaded to PPA by mwhudson (comm # 4 ?) ? Thx! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702979 Title: Deeply layered

[Bug 1697610] Re: aarch64: logfile not supported in this QEMU binary

@James : Thanks for the new patch (comm #24)! Does this allow kernel boot messages to be also captured and address the limitation mentioned in comm #21 ? Thx -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1702979] Re: Deeply layered Docker image problems

A build with option #1 suggested in comment #2 is now available in a PPA (Many thanks to mwhudson!) and is ready for test. To install : $ sudo add-apt-repository ppa:mwhudson/devirt $ sudo apt-get update Then apt-get upgrade or apt-get install docker.io containerd runc should get the rebuilt

[Bug 1694221] Re: fix rxbuf size for netdev-dpdk

it appears that this patch is now ACKed upstream :https://patchwork.ozlabs.org/patch/774670/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694221 Title: fix rxbuf size for netdev-dpdk To manage

[Bug 1694506] Re: arm-smmu arm-smmu.2.auto: Unhandled context fault

** Tags added: acpi arm ** Tags removed: arm ** Tags added: arm64 hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694506 Title: arm-smmu arm-smmu.2.auto: Unhandled context fault To manage

[Bug 1673467] Re: [ocata] unsupported configuration: CPU mode 'host-model' for aarch64 kvm domain on aarch64 host is not supported by hypervisor

The plan is to implement an arch specific charm change to pass in the "host-passthrough" as CPU mode until a newer libvirt with functional "host-model" parameter is available in a future Ubuntu release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

It looks like so far we have the following data points. : ARM64 - 1) Xenial-Mitaka : Fail (comm#3) X86-64 - a) Trusty - Mitaka : Fail (Comm #4) b) Xenial-Mitaka : OK (Comm #7) In addition, Linaro had confirmed that https://bugs.linaro.org/show_bug.cgi?id=2462 (that trigerred the

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

@Ryan Beisner (1chb1n) : Oh, my apologies, I was only looking at the libvirt version (as the fix seems to be there) and went by the following statement in comm#13 : " But UCA-Newton has only Xenials libvirt that is on libvirt 1.3.1 and should not be affected at all either." Are there components

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

@paelzer : Many thanks for looking into this. Xenial-Mitaka test on comm#7 was actually done by Dimitrii (dmitriis).Thanks go out to him. Based on comm#13, your hypothesis seems to be that this should only occur on Yakkety. @dmitriis : Are you able to help with the tests #2-#5 on ServerStack or

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

This bug seems to have been addressed in upstream libvirt, per comm#18 of https://bugs.linaro.org/show_bug.cgi?id=2462 Per Gem Gomez (Linaro) : The upstream review, commit of the patch can be found on the libvirt upstream mailing :

[Bug 1673467] Re: [ocata] unsupported configuration: CPU mode 'host-model' for aarch64 kvm domain on aarch64 host is not supported by hypervisor

@Corey @Christian the xml in comm#12 from Jason is Xenial-Newton. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1673467 Title: [ocata] unsupported configuration: CPU mode 'host-model' for aarch64

[Bug 1630038] Re: thunder nic: avoid link delays due to RX_PACKET_DIS

Hi, Regarding comment#6, can you please help provide : 1) The model of the specific server in use ? 2) A console log that help determine the UEFI firmware version running on that model ? Thanks, Raghu -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

@Billy : Nevermind comment #11. mreed8855 mentioned that the benchmark comes with a "compare" option that can be used to compare results. Thx. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1664764

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

@Billy Olsen : Michael R helped run the benchmarks you pointed to on ARM64 and posted the results on comm #9. Do you happen to know how they can be interpreted/compared with other archs ? Thanks, Raghu -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

Billy Olsen (billy-olsen) wrote on 2017-02-13: If we think this is a python performance issue, it might be beneficial to get some data running the python performance suite - which is available here https://github.com/python/performance. Also, its likely we should target this at the Python Ubuntu

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

dann frazier (dannf) wrote on 2017-01-26: Re: [Bug 1652377] Re: API calls are very slow : On Wed, Jan 25, 2017 at 6:31 PM, Ryan Beisner <1652...@bugs.launchpad.net> wrote: > Without scientific data at this point, I can confirm that every CLI/API > call I make on a freshly-deployed Xenial-Mitaka

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

Ryan Beisner (1chb1n) wrote on 2017-01-26: For example, this should not take 19s on a cloud with no tenants, no instances, 1 image, and light system resource allocation per-node: `time glance image-list` +--++ | ID | Name |

[Bug 1664764] Re: ARM Opentack API/Dashboard calls are very slow

Ryan Beisner (1chb1n) wrote on 2017-01-26: Without scientific data at this point, I can confirm that every CLI/API call I make on a freshly-deployed Xenial-Mitaka arm64 cloud is noticeably sluggish compared with x86 deploys, where the x86 machines are 6 years old, have 75% of the RAM, and less

[Bug 1664764] [NEW] ARM Opentack API/Dashboard calls are very slow

Public bug reported: dann frazier (dannf) on 2016-12-23 : I'm using openstack-base deployed on an arm64-only MAAS (xenial/newton). Both the CLI and dashboard are very slow to respond. CLI commands (e.g. nova list) take about 15s to complete. Logging into the dashboard takes more than 30s. 'top'

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

>From Ryan Beisner (1chb1n) : Xenial-Mitaka I've confirmed that hot-plugging a cinder volume to a uefi arm64 nova instance doesn't work out of the box. After attaching the volume, it was necessary to reboot the instance in order to detect and use the new volume. $ openstack volume create

[Bug 1664737] [NEW] [ARM] : Unable to use Cinder volumes on ARM

Public bug reported: From: Dann Frazier (dannf) : I have an OpenStack setup built on an arm64-only MAAS using the openstack-base w/ default settings. From the cli, I am able to create and attach a volume to a running guest. However, that volume never appears in the guest - nothing new in dmesg,

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

Dmitrii Shcherbakov (dmitriis) wrote on 2017-02-02: @beisner Had issues with deployment - for some reason a couple of undercloud VMs got stuck (juju was waiting for a machine allocation while it already booted) after running juju-deployer. Had to manually remove affected units and 'juju

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

Ryan Beisner (1chb1n) wrote on 2017-02-02: @dmitrii Can you please independently exercise the following?: On ServerStack (x86_64): - Boot a new nova instance. - Create a cinder volume. - Attach the cinder volume to the running nova instance (with openstack cli). We are looking to confirm

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

Ryan Beisner (1chb1n) wrote on 2017-01-26: This does not appear to specific to arm64. On an x86 internal dev cloud, Trusty-Mitaka, I also have to reboot my nova instance after attaching ceph-backed cinder volumes before they are usable. Next steps: test again with vanilla cinder (not

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

From: Dann Frazier (dannf) : Note that the reason I went about testing this was because I ran across this one: https://bugs.linaro.org/show_bug.cgi?id=2462 The symptoms don't seem to be the same - OpenStack in that case generated an error on attach. In this case, there was no error, but the

[Bug 1664737] Re: [ARM] : Unable to use Cinder volumes on ARM

Dmitrii Shcherbakov (dmitriis) wrote on 2017-02-02: In general with a proper guest kernel support hot-plug of block devices should work both with virtio and virtio-scsi on any arch: http://www.linux-kvm.org/page/Hotadd_pci_devices#Add_a_disk Verified that using a xenial host and a xenial guest

[Bug 623464] Re: serial console installation did not result in correct serial console grub2 configuration

** Tags added: arm64 hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/623464 Title: serial console installation did not result in correct serial console grub2 configuration To manage

[Bug 1567807] Re: nova delete doesn't work with EFI booted VMs

** Tags added: arm64 hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1567807 Title: nova delete doesn't work with EFI booted VMs To manage notifications about this bug go to:

[Bug 1566564] Re: support query-gic-version QMP command

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566564 Title: support query-gic-version QMP command To manage notifications about this bug go to:

[Bug 1563990] [NEW] Need a GUI option to set per node kernel parameters

Public bug reported: In the near future, we'd expect to have a number of new ARM64 platforms ( Cavium, APM, Qualcomm, Broadcom etc) supported in Ubuntu 16.04 LTS. Some of these use UEFI + DTB as the default boot mechanism, whereas others are expected to use UEFI +ACPI as thedefault boot mode.

[Bug 1563990] [NEW] Need a GUI option to set per node kernel parameters

Public bug reported: In the near future, we'd expect to have a number of new ARM64 platforms ( Cavium, APM, Qualcomm, Broadcom etc) supported in Ubuntu 16.04 LTS. Some of these use UEFI + DTB as the default boot mechanism, whereas others are expected to use UEFI +ACPI as thedefault boot mode.

[Bug 1533009] Re: arm64: "unsupported RELA relocation"

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1533009 Title: arm64: "unsupported RELA relocation" To manage notifications about this bug go to:

[Bug 1512193] Re: arm64: report 'error: failure writing sector 0x19df788 to `hd0'' after a fresh install

** Also affects: santacruz Importance: Undecided Status: New ** No longer affects: santacruz ** Package changed: grub2 (Ubuntu) => santacruz ** Changed in: santacruz Milestone: None => 15.10-targets ** Tags added: merlin xgene2 ** Changed in: santacruz Importance: Undecided

[Bug 1496972] Re: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel

Re-assigning the bug to Andrew M based on comment #33 ** Changed in: juju-core Assignee: (unassigned) => Andrew McDermott (frobware) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1496972

[Bug 1496972] Re: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel

Hi Andrew, Dann attached a tested fix patch to comm#33. Can you please help test+merge this into appropriate juju releases soon ? This bug has been blocking us for sometime now.. Thanks, Raghu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Bug 1508893] [NEW] TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

Public bug reported: This issue was discovered with Ubuntu Wily (15.10) on a currently in development ARM64 HW. When loading kernel via tftp in grub on this hardware, the system stops receiving new packets (times out ) after receiving initial few tens of tftp data packets , which then causes

[Bug 1508893] Re: TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

Ming Lei has identified that this issue is fixed with the following upstream grub patch: commit 49426e9fd2e562c73a4f1206f32eff9e424a1a73 Author: Andrei Borzenkov Date: Thu May 7 20:37:17 2015 +0300 efinet: open Simple Network Protocol exclusively The next step is to

[Bug 1507653] Re: Wily kernel crashed when running ifconfig eth0 up/done test

** Tags added: arm64 hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1507653 Title: Wily kernel crashed when running ifconfig eth0 up/done test To manage notifications about this bug go to:

[Bug 1485086] Re: lshw does not display cpu information correctly on aarch64

Hi Chris, Manoj verfieid this for Trusty and Vivid (comms #4,#5). Please let us know if there is anything you need from us to complete this SRU. Thanks, Raghu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1472650] Re: [arm64] lxd crashes on startup

** Tags added: hs-arm64 ** Tags added: arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1472650 Title: [arm64] lxd crashes on startup To manage notifications about this bug go to:

[Bug 1471892] Re: [arm64][xgene] Kernel panic while running coreutils testsuite

** Tags added: hs-arm64 ** Tags added: arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1471892 Title: [arm64][xgene] Kernel panic while running coreutils testsuite To manage notifications

[Bug 1386490] Re: HP ProLiant m400 nic doesn't work after trusty

** No longer affects: santacruz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1386490 Title: HP ProLiant m400 nic doesn't work after trusty To manage notifications about this bug go to:

[Bug 1386490] Re: HP ProLiant m400 nic doesn't work after trusty

** Also affects: linux Importance: Undecided Status: New ** Also affects: santacruz Importance: Undecided Status: New ** Changed in: santacruz Milestone: None = 15.04-required -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1401575] Re: HP Moonshot/McDivitt: iSER compatibility issues between x86 OFED target and McDivitt ARM64 client

** Tags added: arm64 hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1401575 Title: HP Moonshot/McDivitt: iSER compatibility issues between x86 OFED target and McDivitt ARM64 client To

[Bug 1381967] Re: mongodb shell crash on arm64

I believe the only *ARM64* MongoDB version that is reasonably expected to work (i.e. without server side scripting and at demo grade quality) is out of a PPA : https://launchpad.net/~mongodb- arm64/+archive/ubuntu/ppa . The mongoDB charm was recently enhanced (By Charles Butler) to add an

[Bug 1381967] Re: mongodb shell crash on arm64

I believe the only *ARM64* MongoDB version that is reasonably expected to work (i.e. without server side scripting and at demo grade quality) is out of a PPA : https://launchpad.net/~mongodb- arm64/+archive/ubuntu/ppa . The mongoDB charm was recently enhanced (By Charles Butler) to add an

[Bug 1381084] Re: xgene-enet: add 10GbE support

** Tags added: arm64 hs-arm64 mustang -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1381084 Title: xgene-enet: add 10GbE support To manage notifications about this bug go to:

[Bug 1377308] Re: booting cloud image without initramfs broken

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1377308 Title: booting cloud image without initramfs broken To manage notifications about this bug go to:

[Bug 1377308] Re: booting cloud image without initramfs broken

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1377308 Title: booting cloud image without initramfs broken To manage notifications about this bug go to:

[Bug 1356569] Re: flash-kernel should not consider ignored kernels as latest

** Changed in: lomond Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1356569 Title: flash-kernel should not consider ignored kernels as latest To manage

[Bug 1350302] Re: Deploying node with di on armhf/keystone can't find BOOTIF

Thanks Colin. I just wanted to get your confirmation that testing done was sufficient prior to marking verficiation-done. Thanks for confirming and adding the tag :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1350302] Re: Deploying node with di on armhf/keystone can't find BOOTIF

Colin, HP successfully tested this fix along with the proposed installer from : http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main /installer-armhf/20101020ubuntu318.7/images/ They reported success via comments #24, #25 #26 of LP1370679. If this sufficient to mark this

[Bug 1350302] Re: Deploying node with di on armhf/keystone can't find BOOTIF

Hi Colin, Thanks for working on the Trusty SRU for this :). Just to elaborate on Ming's comment #12, this issue is currently blocking a Ubuntu factory image for HP's Moonshot platform. To unblock them, we'd first need this fix and then re-spin an installer, after which, HP needs some lead

[Bug 1366867] Re: PC is at ahci_enable_ahci+0x14/0x6c [libahci]

Specifically, the firmware in comment #4 that resolves it is APM's 1.13.28 BSP. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1366867 Title: PC is at ahci_enable_ahci+0x14/0x6c [libahci] To

[Bug 1301516] Re: apparmor prevents libvirt from running qemu-system-aarch64

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1301516 Title: apparmor prevents libvirt from running qemu-system-aarch64 To manage notifications about this bug go to:

[Bug 1288634] Re: Enable mongodb for arm64

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mongodb in Ubuntu. https://bugs.launchpad.net/bugs/1288634 Title: Enable mongodb for arm64 To manage notifications about this bug go to:

[Bug 1288634] Re: Enable mongodb for arm64

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288634 Title: Enable mongodb for arm64 To manage notifications about this bug go to:

[Bug 1261452] Re: juju-core is unavailable for arm64

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to juju-core in Ubuntu. https://bugs.launchpad.net/bugs/1261452 Title: juju-core is unavailable for arm64 To manage notifications about this bug go to:

[Bug 1243119] Re: php-wikidiff2: Incorrect PHP short open tag used in wikidiff2.php

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1243119 Title: php-wikidiff2: Incorrect PHP short open tag used in wikidiff2.php To manage notifications about this bug go to:

[Bug 1261452] Re: juju-core is unavailable for arm64

** Tags added: hs-arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261452 Title: juju-core is unavailable for arm64 To manage notifications about this bug go to:

[Bug 1239800] Re: Soft lockup when running bonnie++ only at 1600 mt/s

Added Tag ; Verification-done-saucy based on comment #17 ** Tags removed: verification-needed-saucy ** Tags added: verification-done-saucy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1239800

[Bug 1254899] Re: [ARMHF] No distribution upgrade path support for Calxeda specific cloud images

** Summary changed: - [ARMHF] Do we need to support distribution upgrade path for cloud images + [ARMHF] No distribution upgrade path support for Calxeda specific cloud images ** Description changed: This bug tracks support requirement for calxeda specific cloud image that will be hosted

[Bug 1254899] Re: [ARMHF] Do we need to support distribution upgrade path for cloud images

[Support Statement]: Canonical and Calxeda will support this custom 13.10 armhf image for select Calxeda armhf customers/ demos for the duration of the 13.10 life-cycle. However, users should be aware that when 14.04 LTS ships, users will need to use the new 14.04 based cloud image, since we do