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

[Manoj Iyer]

I can verify that I was unable to reproduce this bug with the latest
proposed kernel on a highbank.

ubuntu@hb07-15:~$ cat /etc/issue
Ubuntu 13.10 \n \l

ubuntu@hb07-15:~$ uname -a 
Linux hb07-15 3.11.0-15-generic #22-Ubuntu SMP Mon Dec 2 23:36:39 UTC 2013 
armv7l armv7l armv7l GNU/Linux
ubuntu@hb07-15:~$

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1239800

Title:
  Soft lockup when running bonnie++ only at 1600 mt/s

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  SRU Justification:

  Impact: running a test like bonnie++ makes the system instable and
  prone to hangs.

  Fix: apply the attached patches and recompile a kernel.

  Test case: leave bonnie running in a loop for 24hrs.

  --

  When bonnie++ was run in a loop, the system exhibits a hang behavior with
  rcu_sched: self-detected stall on CPU
  The time to error can be inconsistent.  One time it took 7 hours and the next 
time more than 2 days.

  Commands to reproduce the failure:
  $ sudo apt-get install bonnie++
  $ mkdir bonnie
  $ while true; do bonnie++ -d bonnie; done bonnie0.log 

  Stack trace:
  [237019.072290] INFO: rcu_sched self-detected stall on CPU { 1} (t=19305216 
jiffies g=580389 c=580388 q=84)
  [237019.080901] CPU: 1 PID: 44 Comm: kswapd0 Tainted: GF 
3.11.0-6-generic-lpae #12-Ubuntu
  [237019.088879] [c002bc00] (unwind_backtrace+0x0/0x138) from [c0026f1c] 
(show_stack+0x10/0x14)
  [237019.096700] [c0026f1c] (show_stack+0x10/0x14) from [c05cbe50] 
(dump_stack+0x74/0x90)
  [237019.104051] [c05cbe50] (dump_stack+0x74/0x90) from [c00bf37c] 
(rcu_check_callbacks+0x31c/0x798)
  [237019.112262] [c00bf37c] (rcu_check_callbacks+0x31c/0x798) from 
[c00492a0] (update_process_times+0x38/0x64)
  [237019.121254] [c00492a0] (update_process_times+0x38/0x64) from 
[c008cdbc] (tick_sched_handle+0x54/0x60)
  [237019.129933] [c008cdbc] (tick_sched_handle+0x54/0x60) from [c008d00c] 
(tick_sched_timer+0x44/0x74)
  [237019.138300] [c008d00c] (tick_sched_timer+0x44/0x74) from [c005db50] 
(__run_hrtimer+0x74/0x1d4)
  [237019.146433] [c005db50] (__run_hrtimer+0x74/0x1d4) from [c005e6f8] 
(hrtimer_interrupt+0x10c/0x2c0)
  [237019.154800] [c005e6f8] (hrtimer_interrupt+0x10c/0x2c0) from 
[c0492e44] (arch_timer_handler_phys+0x28/0x30)
  [237019.163871] [c0492e44] (arch_timer_handler_phys+0x28/0x30) from 
[c00b8c2c] (handle_percpu_devid_irq+0x6c/0x104)
  [237019.173332] [c00b8c2c] (handle_percpu_devid_irq+0x6c/0x104) from 
[c00b54ec] (generic_handle_irq+0x20/0x30)
  [237019.182402] [c00b54ec] (generic_handle_irq+0x20/0x30) from [c0023ff4] 
(handle_IRQ+0x38/0x94)
  [237019.190378] [c0023ff4] (handle_IRQ+0x38/0x94) from [c0008508] 
(gic_handle_irq+0x28/0x5c)
  [237019.198041] [c0008508] (gic_handle_irq+0x28/0x5c) from [c05d1c00] 
(__irq_svc+0x40/0x50)
  [237019.205624] Exception stack(0xee2c1c18 to 0xee2c1c60)
  [237019.210238] 1c00: 0004 0004
  [237019.217666] 1c20: 0008 0001 ee2c1c8c ca208700 ca208700 0996b000 
ca208708 0001
  [237019.225093] 1c40: 0002 edb31300 0003 ee2c1c60 c02f54fc c00923c8 
200f0013 
  [237019.232523] [c05d1c00] (__irq_svc+0x40/0x50) from [c00923c8] 
(generic_exec_single+0x6c/0x94)
  [237019.240500] [c00923c8] (generic_exec_single+0x6c/0x94) from 
[c00924f4] (smp_call_function_single+0x104/0x198)
  [237019.249805] [c00924f4] (smp_call_function_single+0x104/0x198) from 
[c0029920] (broadcast_tlb_mm_a15_erratum+0x7c/0x84)
  [237019.259812] [c0029920] (broadcast_tlb_mm_a15_erratum+0x7c/0x84) from 
[c0029adc] (flush_tlb_page+0x74/0xa8)
  [237019.268882] [c0029adc] (flush_tlb_page+0x74/0xa8) from [c011fc8c] 
(ptep_clear_flush_young+0x6c/0xd0)
  [237019.277484] [c011fc8c] (ptep_clear_flush_young+0x6c/0xd0) from 
[c011a60c] (page_referenced_one+0x64/0x1fc)
  [237019.286554] [c011a60c] (page_referenced_one+0x64/0x1fc) from 
[c011c034] (page_referenced+0xf4/0x2e4)
  [237019.295155] [c011c034] (page_referenced+0xf4/0x2e4) from [c00fc410] 
(shrink_active_list+0x1f0/0x35c)
  [237019.303756] [c00fc410] (shrink_active_list+0x1f0/0x35c) from 
[c00fdadc] (shrink_lruvec+0x32c/0x598)
  [237019.312279] [c00fdadc] (shrink_lruvec+0x32c/0x598) from [c00fddb0] 
(shrink_zone+0x68/0x180)
  [237019.320176] [c00fddb0] (shrink_zone+0x68/0x180) from [c00fe430] 
(kswapd+0x568/0x9d4)
  [237019.327527] [c00fe430] (kswapd+0x568/0x9d4) from [c005aae0] 
(kthread+0xa4/0xb0)
  [237019.334487] [c005aae0] (kthread+0xa4/0xb0) from [c0023198] 
(ret_from_fork+0x14/0x3c)

  Setup details:
  Quad-core A15 server nodes on Calxeda Midway hardware.
  The failure has been seen two times with DDR setting of DDR3@1600mt/s

  cat /proc/version_signature
  Ubuntu 3.11.0-12.18-generic-lpae 3.11.3
  The issue was first seen on Ubuntu 3.11.0-6.12-generic-lpae

  cat /etc/issue
  Ubuntu 13.04 \n \l

  Additional debug information attached
  ---
  Architecture: armhf
  DistroRelease: Ubuntu 13.04
  MarkForUpload: True
  

[Kernel-packages] [Bug 1248233] Re: [saucy][armhf] No early printk because there's no defined device tree binding for earlyprintk UART

[Manoj Iyer]

I can verify that the patch fixes the bug above, with this patch I am
able to see messages at boot...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.11.0-15-generic-lpae (buildd@kishi02) (gcc 
version 4.7.3 (Ubuntu/Linaro 4.7.3-7ubuntu3) ) #22-Ubuntu SMP Tue Dec 3 
01:16:52 UTC 2013 (Ubuntu 3.11.0-15.22-generic-lpae 3.11.10)
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=30c7387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine: Dummy Virtual Machine, model: linux,dummy-virt
[0.00] cma: CMA: reserved 16 MiB at 3680
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] psci: probing function IDs from device-tree
[0.00] PERCPU: Embedded 9 pages/cpu @c11f5000 s14400 r8192 d14272 u36864
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260624

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1248233

Title:
  [saucy][armhf] No early printk because there's no defined device tree
  binding for earlyprintk UART

Status in “linux” package in Ubuntu:
  Confirmed

Bug description:
  SRU Justification:

  Impact: earlyprintk doesn't work in mach-virt (qemu guest target for
  kvm on arm) because at boot time, the clock necessary to make pl011
  serial port running is not added via device tree (and thus the serial
  console is not probed) - also see https://lists.gnu.org/archive/html
  /qemu-devel/2013-10/msg02427.html.

  Fix: apply the attached patches and recompile a kernel.

  Test case: try booting a patched (and an unpatched kernel) in kvm
  guest passing earlyprintk and NO console, and see if it emits any
  output.

  --

  There is no earlyprintk via the PL011 because there's no defined
  device tree binding for earlyprintk UART to get the PL011 to work
  you'll need to tweak the kernel a bit. kernel doesn't ever add the
  clock to its list, and then it refuses to probe for the PL011. This is
  a temporary fix, ideally the call should be done in some generic
  location rather than in every machine's init function.) The
  alternative would be for the kernel to be fixed to follow its own
  device tree binding documentation and not require clocks/clock-names
  properties on the pl011 node.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248233/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1248233] Re: [saucy][armhf] No early printk because there's no defined device tree binding for earlyprintk UART

[Manoj Iyer]

This patch is a temporary fix.


** Patch added: Patch to enable earlyprintk via the PL011.
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248233/+attachment/3900688/+files/0001-Patch-to-enable-earlyprintk-via-the-PL011.-Because-t.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/1248233

Title:
  [saucy][armhf] No early printk because there's no defined device tree
  binding for earlyprintk UART

Status in “linux” package in Ubuntu:
  New

Bug description:
  There is no earlyprintk via the PL011 because there's no defined
  device tree binding for earlyprintk UART to get the PL011 to work
  you'll need to tweak the kernel a bit. kernel doesn't ever add the
  clock to its list, and then it refuses to probe for the PL011. This is
  a temporary fix, ideally the call should be done in some generic
  location rather than in every machine's init function.) The
  alternative would be for the kernel to be fixed to follow its own
  device tree binding documentation and not require clocks/clock-names
  properties on the pl011 node.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248233/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1248233] [NEW] [saucy][armhf] No early printk because there's no defined device tree binding for earlyprintk UART

[Manoj Iyer]

Public bug reported:

There is no earlyprintk via the PL011 because there's no defined device
tree binding for earlyprintk UART to get the PL011 to work you'll need
to tweak the kernel a bit. kernel doesn't ever add the clock to its
list, and then it refuses to probe for the PL011. This is a temporary
fix, ideally the call should be done in some generic location rather
than in every machine's init function.) The alternative would be for the
kernel to be fixed to follow its own device tree binding documentation
and not require clocks/clock-names properties on the pl011 node.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Paolo Pisati (p-pisati)
 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/1248233

Title:
  [saucy][armhf] No early printk because there's no defined device tree
  binding for earlyprintk UART

Status in “linux” package in Ubuntu:
  New

Bug description:
  There is no earlyprintk via the PL011 because there's no defined
  device tree binding for earlyprintk UART to get the PL011 to work
  you'll need to tweak the kernel a bit. kernel doesn't ever add the
  clock to its list, and then it refuses to probe for the PL011. This is
  a temporary fix, ideally the call should be done in some generic
  location rather than in every machine's init function.) The
  alternative would be for the kernel to be fixed to follow its own
  device tree binding documentation and not require clocks/clock-names
  properties on the pl011 node.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248233/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1248233] Re: [saucy][armhf] No early printk because there's no defined device tree binding for earlyprintk UART

[Manoj Iyer]

due to the nature of the issue encountered log files that will aid in
diagnosing the problem might be missing.

** 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/1248233

Title:
  [saucy][armhf] No early printk because there's no defined device tree
  binding for earlyprintk UART

Status in “linux” package in Ubuntu:
  Confirmed

Bug description:
  SRU Justification:

  Impact: earlyprintk doesn't work in mach-virt (qemu guest target for
  kvm on arm) because at boot time, the clock necessary to make pl011
  serial port running is not added via device tree (and thus the serial
  console is not probed) - also see https://lists.gnu.org/archive/html
  /qemu-devel/2013-10/msg02427.html.

  Fix: apply the attached patches and recompile a kernel.

  Test case: try booting a patched (and an unpatched kernel) in kvm
  guest passing earlyprintk and NO console, and see if it emits any
  output.

  --

  There is no earlyprintk via the PL011 because there's no defined
  device tree binding for earlyprintk UART to get the PL011 to work
  you'll need to tweak the kernel a bit. kernel doesn't ever add the
  clock to its list, and then it refuses to probe for the PL011. This is
  a temporary fix, ideally the call should be done in some generic
  location rather than in every machine's init function.) The
  alternative would be for the kernel to be fixed to follow its own
  device tree binding documentation and not require clocks/clock-names
  properties on the pl011 node.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248233/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1599347] [NEW] [yakkety] d-i does not support (ehci_msm) Qualcomm On-Chip EHCI Host Controller

[Manoj Iyer]

Public bug reported:

D-I does not detect USB devices on servers that have On-Chip EHCI Host
Controller (ehci_msm), as a results install to USB devices fail. Adding
ehci-msm to d-i/modules/usb-modules fixes this issue.

** 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/1599347

Title:
  [yakkety] d-i does not support (ehci_msm) Qualcomm  On-Chip EHCI Host
  Controller

Status in linux package in Ubuntu:
  New

Bug description:
  D-I does not detect USB devices on servers that have On-Chip EHCI Host
  Controller (ehci_msm), as a results install to USB devices fail.
  Adding ehci-msm to d-i/modules/usb-modules fixes this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599347/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1599347] Re: [yakkety] d-i does not support (ehci_msm) Qualcomm On-Chip EHCI Host Controller

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

** Changed in: linux (Ubuntu)
   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/1599347

Title:
  [yakkety] d-i does not support (ehci_msm) Qualcomm  On-Chip EHCI Host
  Controller

Status in linux package in Ubuntu:
  In Progress

Bug description:
  D-I does not detect USB devices on servers that have On-Chip EHCI Host
  Controller (ehci_msm), as a results install to USB devices fail.
  Adding ehci-msm to d-i/modules/usb-modules fixes this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599347/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1661363] Re: Fails to load compressed kernels on arm64

[Manoj Iyer]

ARM64 builds needs build dependency on libz-dev inorder to support
compressed kernels. The attached patch adds that support. Note. amd64
and i386 do not have this dependency, I tested the current zesty version
of the kexec-tools on amd64 and i386 and it works. The patch only apply
to ARM64 build.

[TEST]
== Before Patch ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.9.0-15-generic 
--initrd=/boot/initrd.img-4.9.0-15-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
Cannot determine the file type of /boot/vmlinuz-4.9.0-15-generic
ubuntu@test:~$

== After Patch ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.9.0-15-generic 
--initrd=/boot/initrd.img-4.9.0-15-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
ubuntu@test:~$ sudo kexec -e

Ubuntu Zesty Zapus (development branch) test ttyAMA0

test login: [ 7616.705779] kexec_core: Starting new kernel
[ 0.00] Booting Linux on physical CPU 0x0
[ 0.00] Linux version 4.9.0-15-generic (buildd@bos01-arm64-009) (gcc 
version 6.3.0 20161229 (Ubuntu/Linaro 6.3.0-2ubuntu1) ) #16-Ubuntu SMP Fri Jan 
20 15:29:58 UTC 2017 (Ubuntu 4.9.0-15.16-generic 4.9.5)
[ 0.00] Boot CPU: AArch64 Processor [510f8000]
[ 0.00] efi: Getting EFI parameters from FDT:
[ 0.00] efi: EFI v2.50 by EDK II
[ 0.00] efi: SMBIOS=0x5bdb SMBIOS 3.0=0x5866 PROP=0x5f714518 
ACPI=0x5869 ACPI 2.0=0x58690014
[ 0.00] NUMA: No NUMA configuration found
[ 0.00] NUMA: Faking a node at [mem 0x-0x5

** Patch added: "[Zesty] Enable compressed kernel support for ARM64"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1661363/+attachment/4812742/+files/zesty-enable-compressed-kernel-arm64.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1661363

Title:
  Fails to load compressed kernels on arm64

Status in kexec-tools package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  kexec-tools will not load a compressed kernel on arm64. Ubuntu ships 
compressed kernel images on arm64 starting with 16.10 (and hwe kernels for 
16.04). A workaround is to manually decompress the kernel before loading it, 
but this is not supported by the use-kexec-for-reboot-by-default feature of the 
kexec-tools package.

  [Test Case]
  ubuntu@ubuntu:~$ sudo file /boot/vmlinuz-4.9.0-15-generic
  /boot/vmlinuz-4.9.0-15-generic: gzip compressed data, max compression, from 
Unix
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.9.0-15-generic -t Image
  arch_process_options:141: command_line: (null)
  arch_process_options:143: initrd: (null)
  arch_process_options:144: dtb: (null)
  kernel: 0x8ff61010 kernel_size: 0x6ee18b
  get_memory_ranges_iomem_cb: 4000 - bfff : System RAM
  get_memory_ranges_iomem_cb: 0001 - 00013858 : System RAM
  get_memory_ranges_iomem_cb: 00013875 - 00013bc1 : System RAM
  get_memory_ranges_iomem_cb: 00013c00 - 00013fff : System RAM
  image_arm64_probe: Bad arm64 image header.
  elf_arm64_probe: Not an ELF executable.
  image_arm64_probe: Bad arm64 image header.
  Cannot determine the file type of /boot/vmlinuz-4.9.0-15-generic

  [Regression Risk]
  kexec-tools did not support arm64 until zesty so, assuming the fix is 
localized to arm64 code, regression risk is negligible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1661363/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1661363] Re: Fails to load compressed kernels on arm64

[Manoj Iyer]

ARM64 builds needs build dependency on libz-dev inorder to support
compressed kernels. The attached patch adds that support. Note. amd64
and i386 do not have this dependency, I tested the current zesty version
of the kexec-tools on amd64 and i386 and it works. The patch only apply
to ARM64 build.

[TEST]
== Before Patch ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.9.0-15-generic 
--initrd=/boot/initrd.img-4.9.0-15-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
Cannot determine the file type of /boot/vmlinuz-4.9.0-15-generic
ubuntu@test:~$ 

== After Patch ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.9.0-15-generic 
--initrd=/boot/initrd.img-4.9.0-15-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
ubuntu@test:~$ sudo kexec -e

Ubuntu Zesty Zapus (development branch) test ttyAMA0

test login:  [ 7616.705779] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.0-15-generic (buildd@bos01-arm64-009) (gcc 
version 6.3.0 20161229 (Ubuntu/Linaro 6.3.0-2ubuntu1) ) #16-Ubuntu SMP Fri Jan 
20 15:29:58 UTC 2017 (Ubuntu 4.9.0-15.16-generic 4.9.5)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by EDK II
[0.00] efi:  SMBIOS=0x5bdb  SMBIOS 3.0=0x5866  PROP=0x5f714518  
ACPI=0x5869  ACPI 2.0=0x58690014 
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 0x-0x5fff

** Patch added: "[Zesty] Enable compressed kernel support for ARM64"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1661363/+attachment/4812741/+files/zesty-enable-compressed-kernel-arm64.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1661363

Title:
  Fails to load compressed kernels on arm64

Status in kexec-tools package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  kexec-tools will not load a compressed kernel on arm64. Ubuntu ships 
compressed kernel images on arm64 starting with 16.10 (and hwe kernels for 
16.04). A workaround is to manually decompress the kernel before loading it, 
but this is not supported by the use-kexec-for-reboot-by-default feature of the 
kexec-tools package.

  [Test Case]
  ubuntu@ubuntu:~$ sudo file /boot/vmlinuz-4.9.0-15-generic
  /boot/vmlinuz-4.9.0-15-generic: gzip compressed data, max compression, from 
Unix
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.9.0-15-generic -t Image
  arch_process_options:141: command_line: (null)
  arch_process_options:143: initrd: (null)
  arch_process_options:144: dtb: (null)
  kernel: 0x8ff61010 kernel_size: 0x6ee18b
  get_memory_ranges_iomem_cb: 4000 - bfff : System RAM
  get_memory_ranges_iomem_cb: 0001 - 00013858 : System RAM
  get_memory_ranges_iomem_cb: 00013875 - 00013bc1 : System RAM
  get_memory_ranges_iomem_cb: 00013c00 - 00013fff : System RAM
  image_arm64_probe: Bad arm64 image header.
  elf_arm64_probe: Not an ELF executable.
  image_arm64_probe: Bad arm64 image header.
  Cannot determine the file type of /boot/vmlinuz-4.9.0-15-generic

  [Regression Risk]
  kexec-tools did not support arm64 until zesty so, assuming the fix is 
localized to arm64 code, regression risk is negligible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1661363/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1661363] Re: Fails to load compressed kernels on arm64

[Manoj Iyer]

The debian/control file lists gnu-efi and libz-dev only for ia64, since
amd64, and arm64 (may be other archs) also need these dependencies for
it to support compressed kernel we need something like the following
change for it to work on those archs.

-Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, gnu-efi (>=3.0a-4)[ia64], 
libz-dev[ia64], po-debconf
+Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, gnu-efi (>=3.0a-4)[amd64 
arm64 ia64], libz-dev[amd64 arm64 ia64], po-debconf

I will upload a patch to zesty shortly.

** Changed in: kexec-tools (Ubuntu)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1661363

Title:
  Fails to load compressed kernels on arm64

Status in kexec-tools package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  kexec-tools will not load a compressed kernel on arm64. Ubuntu ships 
compressed kernel images on arm64 starting with 16.10 (and hwe kernels for 
16.04). A workaround is to manually decompress the kernel before loading it, 
but this is not supported by the use-kexec-for-reboot-by-default feature of the 
kexec-tools package.

  [Test Case]
  ubuntu@ubuntu:~$ sudo file /boot/vmlinuz-4.9.0-15-generic
  /boot/vmlinuz-4.9.0-15-generic: gzip compressed data, max compression, from 
Unix
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.9.0-15-generic -t Image
  arch_process_options:141: command_line: (null)
  arch_process_options:143: initrd: (null)
  arch_process_options:144: dtb: (null)
  kernel: 0x8ff61010 kernel_size: 0x6ee18b
  get_memory_ranges_iomem_cb: 4000 - bfff : System RAM
  get_memory_ranges_iomem_cb: 0001 - 00013858 : System RAM
  get_memory_ranges_iomem_cb: 00013875 - 00013bc1 : System RAM
  get_memory_ranges_iomem_cb: 00013c00 - 00013fff : System RAM
  image_arm64_probe: Bad arm64 image header.
  elf_arm64_probe: Not an ELF executable.
  image_arm64_probe: Bad arm64 image header.
  Cannot determine the file type of /boot/vmlinuz-4.9.0-15-generic

  [Regression Risk]
  kexec-tools did not support arm64 until zesty so, assuming the fix is 
localized to arm64 code, regression risk is negligible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1661363/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[Testing on VM]
== Default kernel on Yakkety ==
ubuntu@test:~$ uname -a
Linux test 4.8.0-37-generic #39-Ubuntu SMP Thu Jan 26 02:26:41 UTC 2017 aarch64 
aarch64 aarch64 GNU/Linux
ubuntu@test:~$

== No kexec-tools for ARM64 ==
ubuntu@test:~$ sudo apt-get install kexec-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package kexec-tools 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 'kexec-tools' has no installation candidate
ubuntu@test:~$

== kexec-tools for yakkety with ARM64 support ==
ubuntu@test:~$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-2ubuntu1.1  
arm64tools to support fast kexec reboots
ubuntu@test:~$

== Kernel with kexec support ==
SRU pending: https://bugs.launchpad.net/bugs/1662554

ubuntu@test:~$ sudo file /boot/vmlinuz-4.8.0-38-generic
/boot/vmlinuz-4.8.0-38-generic: gzip compressed data, max compression, from Unix
ubuntu@test:~$

== Load kexec kernel on cmd line ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.8.0-38-generic 
--initrd=/boot/initrd.img-4.8.0-38-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
ubuntu@test:~$

== Kernel live boots successfully ==
test login: [   66.553187] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-38-generic (manjo@tangerine) (gcc version 
6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #40ubuntu1 SMP Mon Feb 6 21:55:35 UTC 
2017 (Ubuntu 4.8.0-38.40ubuntu1-generic 4.8.17)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by EDK II
[0.00] efi:  SMBIOS=0x5bdb  SMBIOS 3.0=0x5866  PROP=0x5f714518  
ACPI=0x5869  ACPI 2.0=0x58690014

** Patch added: "Yakkety kexec-tools arm64 support"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4814820/+files/yakkety-kexec-tools-enable-arm64-support.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1662554] Re: [Yakkety SRU] Enable KEXEC support in ARM64 kernel

[Manoj Iyer]

** Description changed:

  [Impact]
-  * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
-  * Our partners/customers have requested this feature.
+  * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
+  * Our partners/customers have requested this feature.
  
  [Test Case]
-  * Install a version of kexec-tools that supports ARM64
-  * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
-  * You should see the message:  kexec_load failed: Function not implemented
+  * Install a version of kexec-tools that supports ARM64
+  * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
+  * You should see the message:  kexec_load failed: Function not implemented
  
  [Regression Potential]
-  * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.
-  
+  * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.
+ 
  [Other Info]
-  * Please note that kexec-tools currently is not built for ARM64
-  * I have an SRU to enable that bugs.launchpad.net/bugs/1659618
-  * I am working with dannf to get kexec-tools to support ARM64 in yakkety.
+  * Please note that kexec-tools currently is not built for ARM64
+  * I have an SRU to enable that https://bugs.launchpad.net/bugs/1659618
+  * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1662554

Title:
  [Yakkety SRU] Enable KEXEC support in ARM64 kernel

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [Impact]
   * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
   * Our partners/customers have requested this feature.

  [Test Case]
   * Install a version of kexec-tools that supports ARM64
   * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
   * You should see the message:  kexec_load failed: Function not implemented

  [Regression Potential]
   * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.

  [Other Info]
   * Please note that kexec-tools currently is not built for ARM64
   * I have an SRU to enable that https://bugs.launchpad.net/bugs/1659618
   * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662554/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[AMD64 regression testing]
[Testing with stock Yakkety kernel & kexec-tools]

ubuntu@test:~$ sudo file /boot/vmlinuz-4.8.0-30-generic 
/boot/vmlinuz-4.8.0-30-generic: Linux kernel x86 boot executable bzImage, 
version 4.8.0-30-generic (buildd@lcy01-08) #32-Ubuntu SMP Fri Dec 2 03:, 
RO-rootFS, swap_dev 0x7, Normal VGA
ubuntu@test:~$ 

ubuntu@test:~$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-2ubuntu1
 amd64tools to support fast kexec reboots
ubuntu@test:~$ 

ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.8.0-30-generic 
--initrd=/boot/initrd.img-4.8.0-30-generic --append="root=LABEL=cloudimg-rootfs 
console=ttyS0"
ubuntu@test:~$ sudo kexec -e 

test login: [  212.930357] kexec_core: Starting new kernel
[0.00] Linux version 4.8.0-30-generic (buildd@lcy01-08) (gcc version 
6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #32-Ubuntu SMP Fri Dec 2 03:43:27 UTC 
2016 (Ubuntu 4.8.0-30.32-generic 4.8.6)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-30-generic 
root=LABEL=cloudimg-rootfs console=ttyS0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:

[Testing with patched kexec-tools]

== Build & Install patched kexec-tools ==
ubuntu@test:~/kexec$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-2ubuntu1.1  
 amd64tools to support fast kexec reboots
ubuntu@test:~/kexec$ 

ubuntu@test:~/kexec$ sudo file /boot/vmlinuz-4.8.0-30-generic 
/boot/vmlinuz-4.8.0-30-generic: Linux kernel x86 boot executable bzImage, 
version 4.8.0-30-generic (buildd@lcy01-08) #32-Ubuntu SMP Fri Dec 2 03:, 
RO-rootFS, swap_dev 0x7, Normal VGA
ubuntu@test:~/kexec$

ubuntu@test:~/kexec$ sudo kexec -l /boot/vmlinuz-4.8.0-30-generic 
--initrd=/boot/initrd.img-4.8.0-30-generic --append="root=LABEL=cloudimg-rootfs 
console=ttyS0"
ubuntu@test:~/kexec$ sudo kexec -e 

== Kernel live boots successfully ==
Ubuntu 16.10 test ttyS0

test login: [  377.524693] kexec_core: Starting new kernel
[0.00] Linux version 4.8.0-30-generic (buildd@lcy01-08) (gcc version 
6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #32-Ubuntu SMP Fri Dec 2 03:43:27 UTC 
2016 (Ubuntu 4.8.0-30.32-generic 4.8.6)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-30-generic 
root=LABEL=cloudimg-rootfs console=ttyS0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 

[Kernel-packages] [Bug 1662554] [NEW] [Yakkety] Enable KEXEC support in ARM64 kernel

[Manoj Iyer]

Public bug reported:

[Impact]
 * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
 * Our partners/customers have requested this feature.

[Test Case]
 * Install a version of kexec-tools that supports ARM64
 * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
 * You should see the message:  kexec_load failed: Function not implemented

[Regression Potential]
 * The proposed config changes are limited to ARM64 architecture, overall risk 
of regression is low.
 
[Other Info]
 * Please note that kexec-tools currently is not built for ARM64
 * I have an SRU to enable that bugs.launchpad.net/bugs/1659618
 * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Manoj Iyer (manjo)
 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/1662554

Title:
  [Yakkety] Enable KEXEC support in ARM64 kernel

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [Impact]
   * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
   * Our partners/customers have requested this feature.

  [Test Case]
   * Install a version of kexec-tools that supports ARM64
   * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
   * You should see the message:  kexec_load failed: Function not implemented

  [Regression Potential]
   * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.
   
  [Other Info]
   * Please note that kexec-tools currently is not built for ARM64
   * I have an SRU to enable that bugs.launchpad.net/bugs/1659618
   * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662554/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1662554] Re: [Yakkety] Enable KEXEC support in ARM64

[Manoj Iyer]

[Testing]

== Build & Install kernel and kexec-tools ==
Built kexec-tools with patches needed for ARM64 support, and built a 4.8.0-38 
Yakkety kernel with CONFIG_KEXEC and CONFIG_KEXEC_CORE set to Y.

ubuntu@test:~$ cat /etc/issue
Ubuntu 16.10 \n \l
ubuntu@test:~$

ubuntu@test:~$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-2ubuntu1.1  
arm64tools to support fast kexec reboots
ubuntu@test:~$

ubuntu@test:~$ sudo file /boot/vmlinuz-4.8.0-38-generic
/boot/vmlinuz-4.8.0-38-generic: gzip compressed data, max compression, from Unix
ubuntu@test:~$

== Load kexec kernel ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.8.0-38-generic 
--initrd=/boot/initrd.img-4.8.0-38-generic --append="root=LABEL=cloudimg-rootfs 
vt.handoff=7"
ubuntu@test:~$

== Initiate kexec ==
ubuntu@test:~$ sudo kexec -e 
ubuntu@test:~$

== Successful boot ==
test login: [   66.553187] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-38-generic (manjo@tangerine) (gcc version 
6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #40ubuntu1 SMP Mon Feb 6 21:55:35 UTC 
2017 (Ubuntu 4.8.0-38.40ubuntu1-generic 4.8.17)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by EDK II
[0.00] efi:  SMBIOS=0x5bdb  SMBIOS 3.0=0x5866  PROP=0x5f714518  
ACPI=0x5869  ACPI 2.0=0x58690014


** Summary changed:

- [Yakkety] Enable KEXEC support in ARM64
+ [Yakkety] Enable KEXEC support in ARM64 kernel

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1662554

Title:
  [Yakkety] Enable KEXEC support in ARM64 kernel

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [Impact]
   * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
   * Our partners/customers have requested this feature.

  [Test Case]
   * Install a version of kexec-tools that supports ARM64
   * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
   * You should see the message:  kexec_load failed: Function not implemented

  [Regression Potential]
   * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.
   
  [Other Info]
   * Please note that kexec-tools currently is not built for ARM64
   * I have an SRU to enable that bugs.launchpad.net/bugs/1659618
   * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662554/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1662554] Re: [Yakkety SRU] Enable KEXEC support in ARM64 kernel

[Manoj Iyer]

** Summary changed:

- [Yakkety] Enable KEXEC support in ARM64 kernel
+ [Yakkety SRU] Enable KEXEC support in ARM64 kernel

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1662554

Title:
  [Yakkety SRU] Enable KEXEC support in ARM64 kernel

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [Impact]
   * If the kernel is not built with CONFIG_KEXEC support, kexec-tools will not 
be able to live boot a new kernel over the running one.
   * Our partners/customers have requested this feature.

  [Test Case]
   * Install a version of kexec-tools that supports ARM64
   * Run the command: sudo kexec -l /boot/ --initrd=/boot/ 
--append="
   * You should see the message:  kexec_load failed: Function not implemented

  [Regression Potential]
   * The proposed config changes are limited to ARM64 architecture, overall 
risk of regression is low.
   
  [Other Info]
   * Please note that kexec-tools currently is not built for ARM64
   * I have an SRU to enable that bugs.launchpad.net/bugs/1659618
   * I am working with dannf to get kexec-tools to support ARM64 in yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662554/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

** Patch added: "Yakkety kexec-tools arm64 support V4"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4814952/+files/yakkety-kexec-tools-enable-arm64-support-V4.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

Please ignore my previous comment, I introduced an err in the changelog.
Please use this cleaned up version of the patch.

** Patch added: "Yakkety kexec-tools arm64 support V3"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4814950/+files/yakkety-kexec-tools-enable-arm64-support-V3.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

Please note that the previous debdiff patch I attached introduced some
spurious changes by accident. Here is a cleaner version of the debdiff
patch for Yakkety. I applied this patch to Yakkety kexec-tools and I was
able to build and test.

Please consider this patch for SRU to kexec-tools in yakkety.

** Patch added: "Yakkety kexec-tools arm64 support V2"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4814949/+files/yakkety-kexec-tools-enable-arm64-support-V2.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

I was able to apply this patch and build kexec-tools on Xenial. Please
see this link for details: https://pastebin.ubuntu.com/23950298/

[TESTING]

== Y kernel for X series with kexec support ==
I had to build a Yakkety kernel for Xenial series with KEXEC enabled.
ubuntu@test:~$ uname -a
Linux test 4.8.0-38-generic #40ubuntu1 SMP Tue Feb 7 21:26:52 UTC 2017 aarch64 
aarch64 aarch64 GNU/Linux

== kexec-tools with patches to enable ARM64 support ==

ubuntu@test:~$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-1ubuntu2.1arm64 
   tools to support fast kexec reboots
ubuntu@test:~$ 

== Load kexec kernel and initiate kexec ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.8.0-38-generic 
--initrd=/boot/initrd.img-4.8.0-38-generic 
--append="root=UUID=6ef62239-dad9-409b-a3ab-1847e44aa779 ro vt.handoff=7"
ubuntu@test:~$ sudo kexec -e

== Successful live boot of kexec kernel ==
Ubuntu 16.04.1 LTS test ttyAMA0

test login: [   85.371808] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-38-generic (manjo@tangerine) (gcc version 
5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #40ubuntu1 SMP Tue Feb 7 
21:26:52 UTC 2017 (Ubuntu 4.8.0-38.40ubuntu1-generic 4.8.17)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by EDK II
[0.00] efi:  SMBIOS=0x5bdb  SMBIOS 3.0=0x5866  PROP=0x5f714518  
ACPI=0x5869  ACPI 2.0=0x58690014
[0.00] No NUMA configuration found

** Patch added: "Xenial  kexec-tools arm64 support"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4814982/+files/xenial-kexec-tools-enable-arm64-support.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[Regression testing on Xenial AMD64]
AMD64 kernel already has kexec support on Xenial. The attached patch applies 
cleanly and builds on AMD64: https://pastebin.ubuntu.com/23950437/

== Installed kexec-tools built with ARM64 enablement patches ==
ubuntu@test:~$ dpkg -l | grep kexec-tools
ii  kexec-tools  1:2.0.10-1ubuntu2.1amd64   
 tools to support fast kexec reboots
ubuntu@test:~$ 

== Load kexec kernel and initiate kexec ==
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.4.0-62-generic 
--initrd=/boot/initrd.img-4.4.0-62-generic --append="root=LABEL=cloudimg-rootfs 
ro console=ttyS0"
ubuntu@test:~$ sudo kexec -e

== Successfully live booted kernel ==
Ubuntu 16.04.1 LTS test ttyS0

test login: [   18.860792] kexec_core: Starting new kernel
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-62-generic (buildd@lcy01-30) (gcc version 
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #83-Ubuntu SMP Wed Jan 18 
14:10:15 UTC 2017 (Ubuntu 4.4.0-62.83-generic 4.4.40)
[0.00] Command line: root=LABEL=cloudimg-rootfs ro console=ttyS0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] [NEW] [SRU] [Xenial] Enable ARM64 support in kexec-tools

[Manoj Iyer]

Public bug reported:

[IMPACT]
 * kexec-tools in Xenial (16.04) currently does not support ARM64
   architecture.
 * Backport support for ARM64 arch from upstream
   https://github.com/horms/kexec-tools
 * Majority of the patches are contained in kexec/arch/arm64/ except for
   one patch that impacts purgatory and common device tree routines.

[TEST CASE]
 * I built kexec-tools for ARM64 and tested it on HW using the following
   testcase:
   $ sudo kexec -l /boot/vmlinuz--generic
 --initrd=/boot/initrd.img--generic
 --command-line="root=UUID= ro vt.handoff=7"
   $ sudo kexec -e
 * I was able to kexec the new kernel successfully.
 * [ 6702.357899] kexec_core: Starting new kernel
   [0.00] Booting Linux on physical CPU 0x200
   [0.00] Linux version -generic (buildd@bos01-arm64-008)
   (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
   [0.00] Boot CPU: AArch64 Processor [510f8000]

[REGRESSION POTENTIAL]
 * Since patches are confined to arm[64] there is a low overall risk of
   regression.

[OTHER INFO]
 * You can find a Xenial kexec-tools package built for AMD64, i386 and
   ARM64 in my PPA
   https://launchpad.net/~manjo/+archive/ubuntu/devtools/
 * This package is built using the Xenial source package for kexec-tools
   with ARM64 enablement patches applied.
 * Please pull the changes from my PPA package and integrate into Ubuntu
   Xenial kexec-tools after review.

** Affects: kexec-tools (Ubuntu)
 Importance: High
 Assignee: Louis Bouchard (louis-bouchard)
 Status: New

** Package changed: ubuntu => kexec-tools (Ubuntu)

** Changed in: kexec-tools (Ubuntu)
   Importance: Undecided => High

** Description changed:

  [IMPACT]
-  * kexec-tools in Xenial (16.04) currently does not support ARM64 
architecture.
-  * Backport support for ARM64 arch from upstream 
https://github.com/horms/kexec-tools
-  * Majority of the patches are contained in kexec/arch/arm64/ except for one 
patch that impacts
-purgatory and common device tree routines. 
+  * kexec-tools in Xenial (16.04) currently does not support ARM64 
architecture.
+  * Backport support for ARM64 arch from upstream
+https://github.com/horms/kexec-tools
+  * Majority of the patches are contained in kexec/arch/arm64/ except for  
+one patch that impacts purgatory and common device tree routines.
  
  [TEST CASE]
-  * I built kexec-tools for ARM64 and tested it on HW using the following 
testcase:
-$ sudo kexec -l /boot/vmlinuz--generic 
--initrd=/boot/initrd.img--generic
-  --command-line="root=UUID= ro vt.handoff=7"
-$ sudo kexec -e
-  * I was able to kexec the new kernel successfully. 
-  * [ 6702.357899] kexec_core: Starting new kernel
-[0.00] Booting Linux on physical CPU 0x200
-[0.00] Linux version -generic (buildd@bos01-arm64-008) 
(gcc version 5.4.0   
-20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
-[0.00] Boot CPU: AArch64 Processor [510f8000]
-
+  * I built kexec-tools for ARM64 and tested it on HW using the following 
+testcase:
+    $ sudo kexec -l /boot/vmlinuz--generic 
+  --initrd=/boot/initrd.img--generic
+  --command-line="root=UUID= ro vt.handoff=7"
+    $ sudo kexec -e
+  * I was able to kexec the new kernel successfully.
+  * [ 6702.357899] kexec_core: Starting new kernel
+    [0.00] Booting Linux on physical CPU 0x200
+    [0.00] Linux version -generic (buildd@bos01-arm64-008) 
(gcc version 5.4.0
+    20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
+    [0.00] Boot CPU: AArch64 Processor [510f8000]
+ 
  [REGRESSION POTENTIAL]
-  * Since patches are confined to arm[64] there is a low overall risk of 
regression.
+  * Since patches are confined to arm[64] there is a low overall risk of  
+regression.
  
  [OTHER INFO]
-  * You can find a Xenial kexec-tools package built for AMD64, i386 and ARM64 
in my PPA
- https://launchpad.net/~manjo/+archive/ubuntu/devtools/
-  * This package is built using the Xenial source package for kexec-tools with 
ARM64 enablement 
-patches applied.
-  * Please pull the changes from my PPA package and integrate into Ubuntu 
Xenial kexec-tools after
-review.
+  * You can find a Xenial kexec-tools package built for AMD64, i386 and 
+ARM64 in my PPA
+    https://launchpad.net/~manjo/+archive/ubuntu/devtools/
+  * This package is built using the Xenial source package for kexec-tools 
+with ARM64 enablement patches applied.
+  * Please pull the changes from my PPA package and integrate into Ubuntu 
+Xenial kexec-tools after review.

** Description changed:

  [IMPACT]
-  * kexec-tools in Xenial (16.04) currently does not support ARM64 
architecture.
-  * Backport support for ARM64 arch from upstream
-https://github.com/horms/kexec-tools
-  * Majority of the patches are contained in kexec/arch/arm64/ except for  
-one patch that impacts purgatory and common device tree routines.
+  * 

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

** Description changed:

  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.
  
  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
-    [0.00] Linux version -generic (buildd@bos01-arm64-008)
-(gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
+    [0.00] Linux version -generic (buildd@bos01-arm64-008)
+    (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]
  
  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.
  
  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
-    https://launchpad.net/~manjo/+archive/ubuntu/devtools/
+    https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[TESTING ON ARM64 HARDWARE]

$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

$ sudo apt-add-repository ppa:manjo/kexec-tools
$ sudo apt update 
$ sudo apt install kexec-tools
$ kexec --version
kexec-tools 2.0.10 released 26 January 2017

$ ls /boot  
abi-4.7.0-2-generic grubSystem.map-4.7.0-2-generic
config-4.7.0-2-generic  initrd.img  vmlinuz
efi initrd.img-4.7.0-2-generic  vmlinuz-4.7.0-2-generic

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.7.0-2-generic 
root=UUID=4f520e6e-6b21-460e-9c2b-332b188e393b ro splash quiet vt.handoff=7

$ sudo kexec -l /boot/vmlinuz-4.7.0-2-generic
--initrd=/boot/initrd.img-4.7.0-2-generic --command-line="root=UUID
=4f520e6e-6b21-460e-9c2b-332b188e393b ro vt.handoff=7"

$ sudo kexec -e 
[  76.658975] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x200
[0.00] Linux version 4.7.0-2-generic (buildd@bos01-arm64-008) (gcc 
version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) 
#5~pdaw1.1+.2-Ubuntu SMP Fri Jan 13 18:38:31 UTC 2017 (Ubuntu 
4.7.0-2.5~pdaw1.1+.2-generic 4.7.0)
[0.00] Boot CPU: AArch64 Processor [510f8000]

$ uname -a 
Linux pdaw1 4.7.0-2-generic #5~pdaw1.1+.2-Ubuntu SMP Fri Jan 13 
18:38:31 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux

$ cat /proc/cmdline 
root=UUID=4f520e6e-6b21-460e-9c2b-332b188e393b ro vt.handoff=7

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

The above test was that of the kexec-tools package that includes review
comments from dannf.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659111] Re: UbuntuKVM guest crashed while running I/O stress test with Ubuntu kernel 4.4.0-47-generic

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Taco Screen team (taco-screen-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1659111

Title:
  UbuntuKVM guest crashed while running I/O stress test with Ubuntu
  kernel  4.4.0-47-generic

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Attn. Canonical: For your awareness only at this time.

  == Comment: #0 - LEKSHMI C. PILLAI  - 2016-11-22 03:49:38 ==

  Machine INFO

  KVM HOST: luckyv1

  Guest :lucky05

  lucky05 crashed while running the I/O stress test for SAN disks.

  Installed lucky05 and enabled the xmon on that.After that started the
  RAW disk test on around 50 disks.After 6-7 hours after running,Now
  machine dropped into xmon.

  Logs:
  [25023.224182] Unable to handle kernel paging request for data at address 
0x
  [25023.224257] Faulting instruction address: 0xc0324c60
  cpu 0x3: Vector: 300 (Data Access) at [c000fffc3620]
  pc: c0324c60: locked_inode_to_wb_and_lock_list+0x50/0x290
  lr: c032831c: writeback_sb_inodes+0x30c/0x590
  sp: c000fffc38a0
 msr: 80019033
 dar: 0
   dsisr: 4000
current = 0xc000ff99e470
paca= 0xcfb41c80   softe: 0irq_happened: 0x01
  pid   = 14736, comm = kworker/u16:8
  enter ? for help
  [c000fffc3900] c032831c writeback_sb_inodes+0x30c/0x590
  [c000fffc3a10] c0328684 __writeback_inodes_wb+0xe4/0x150
  [c000fffc3a70] c0328aec wb_writeback+0x30c/0x450
  [c000fffc3b40] c03296b4 wb_workfn+0x264/0x570
  [c000fffc3c50] c00dd930 process_one_work+0x1e0/0x5a0
  [c000fffc3ce0] c00dde84 worker_thread+0x194/0x680
  [c000fffc3d80] c00e6980 kthread+0x110/0x130
  [c000fffc3e30] c0009538 ret_from_kernel_thread+0x5c/0xa4
  3:mon> f
  3:mon> th
  [c000fffc3900] c032831c writeback_sb_inodes+0x30c/0x590
  [c000fffc3a10] c0328684 __writeback_inodes_wb+0xe4/0x150
  [c000fffc3a70] c0328aec wb_writeback+0x30c/0x450
  [c000fffc3b40] c03296b4 wb_workfn+0x264/0x570
  [c000fffc3c50] c00dd930 process_one_work+0x1e0/0x5a0
  [c000fffc3ce0] c00dde84 worker_thread+0x194/0x680
  [c000fffc3d80] c00e6980 kthread+0x110/0x130
  [c000fffc3e30] c0009538 ret_from_kernel_thread+0x5c/0xa4 
  3:mon> sh
  [27384.651055] INFO: rcu_sched detected stalls on CPUs/tasks:
  [27384.651220]  (detected by 4, t=40598 jiffies, g=2849830, c=2849829, q=992)
  [27384.651286] All QSes seen, last rcu_sched kthread activity 40596 
(4301188714-4301148118), jiffies_till_next_fqs=1, root ->qsmask 0x0
  [27384.651501] rcu_sched kthread starved for 40596 jiffies! g2849830 c2849829 
f0x2 s3 ->state=0x0
  [27384.651747] INFO: rcu_sched detected stalls on CPUs/tasks:
  [27384.651905]  (detected by 4, t=590354 jiffies, g=2849830, c=2849829, 
q=1285)
  [27384.652012] All QSes seen, last rcu_sched kthread activity 590352 
(4301738470-4301148118), jiffies_till_next_fqs=1, root ->qsmask 0x0
  [27384.652191] rcu_sched kthread starved for 590352 jiffies! g2849830 
c2849829 f0x2 s3 ->state=0x0
  [27384.730645] Unable to handle kernel paging request for data at address 
0xffd8
  [27384.730781] Faulting instruction address: 0xc00e7258
  cpu 0x3: Vector: 300 (Data Access) at [c000fffc3000]
  pc: c00e7258: kthread_data+0x28/0x40
  lr: c00de940: wq_worker_sleeping+0x30/0x110
  sp: c000fffc3280
 msr: 80019033
 dar: ffd8
   dsisr: 4000
current = 0xc000ff99e470
paca= 0xcfb41c80   softe: 0irq_happened: 0x01
  pid   = 14736, comm = kworker/u16:8
  enter ? for help

  == Comment: #1 - LEKSHMI C. PILLAI - 2016-11-22 04:05:41 ==
  3:mon> th
  [c000fffc32b0] c00de940 wq_worker_sleeping+0x30/0x110
  [c000fffc32f0] c0af31bc __schedule+0x6ec/0x990
  [c000fffc33c0] c0af34a8 schedule+0x48/0xc0
  [c000fffc33f0] c00bd3d0 do_exit+0x760/0xc30
  [c000fffc34b0] c0020bf4 die+0x314/0x470
  [c000fffc3540] c0050d98 bad_page_fault+0xd8/0x150
  [c000fffc35b0] c0008680 handle_page_fault+0x2c/0x30
  --- Exception: 300 (Data Access) at c0324c60 
locked_inode_to_wb_and_lock_list+0x50/0x290
  [c000fffc3900] c032831c writeback_sb_inodes+0x30c/0x590
  [c000fffc3a10] c0328684 __writeback_inodes_wb+0xe4/0x150
  [c000fffc3a70] c0328aec wb_writeback+0x30c/0x450
  [c000fffc3b40] c03296b4 wb_workfn+0x264/0x570
  [c000fffc3c50] c00dd930 process_one_work+0x1e0/0x5a0
  [c000fffc3ce0] c00dde84 worker_thread+0x194/0x680
  [c000fffc3d80] c00e6980 kthread+0x110/0x130
  

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

Updated changelog to refer to LP: #1659618

new debdiff attached.

** Patch added: "updated debdiff - changelog referring to LP# 1659618"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4809480/+files/updated-debdiff-withLP%23.diff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1656112] Re: Power S822LC (8335-GTB) failes KVM guest cert test with kvm_init_vcpu failed: Invalid argument

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

** Changed in: qemu (Ubuntu)
 Assignee: (unassigned) => Jon Grimm (jgrimm)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1656112

Title:
  Power S822LC (8335-GTB) failes KVM guest cert test with kvm_init_vcpu
  failed: Invalid argument

Status in linux package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  New
Status in linux source package in Xenial:
  Confirmed
Status in qemu source package in Xenial:
  New

Bug description:
  Upon running the virtualization test from the certification test
  suite, the kvm guest test fails with the following error:

  kvm_init_vcpu failed: Invalid argument

  This same test works on multiple other IBM Power 8 and Openpower
  servers. kvm-ok tells us that kvm virtualization is supported. I have
  tried with SMT enabled and disabled. I have tried the latest cloud
  image as well as previous onces we had saved. I have tried running the
  qemu-system-ppc64 command found below manually with the same error.

  
  The full output from the test is as follows:

  Executing KVM Test
  DEBUG:root:Starting KVM Test
  DEBUG:root:Cloud image location specified: 
http://10.1.10.2/cloud/xenial-server-cloudimg-ppc64el-disk1.img.
  DEBUG:root:Downloading xenial-server-cloudimg-ppc64el-disk1.img, from 
http://10.1.10.2
  DEBUG:root:Creating cloud user-data
  DEBUG:root:Creating cloud meta-data
  I: -input-charset not specified, using utf-8 (detected in locale settings)
  Total translation table size: 0
  Total rockridge attributes bytes: 331
  Total directory bytes: 0
  Path table size(bytes): 10
  Max brk space used 0
  183 extents written (0 MB)
  DEBUG:root:Attempting boot for:xenial-server-cloudimg-ppc64el-disk1.img
  DEBUG:root:Attaching Cloud config disk
  DEBUG:root:Using params:qemu-system-ppc64 -m 1024 -display none -nographic 
-net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::-:22 
-enable-kvm -machine pseries,usb=off -cpu POWER8 -drive 
file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive 
file=seed.iso,if=virtio
  INFO:root:Storing VM console output in 
/home/ubuntu/.cache/plainbox/sessions/canonical-certification-server-2017-01-12T22.19.34.session/CHECKBOX_DATA/virt_debug

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-59-generic 4.4.0-59.80
  ProcVersionSignature: Ubuntu 4.4.0-59.80-generic 4.4.35
  Uname: Linux 4.4.0-59-generic ppc64le
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Jan 12 22:18 seq
   crw-rw 1 root audio 116, 33 Jan 12 22:18 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.1-0ubuntu2.4
  Architecture: ppc64el
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  Date: Thu Jan 12 22:45:34 2017
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 002 Device 002: ID 125f:312b A-DATA Technology Co., Ltd. Superior S102 
Pro
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 002: ID 046b:ff01 American Megatrends, Inc. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 astdrmfb
  ProcKernelCmdLine: root=UUID=a7ce18b4-4614-485f-9346-b19b0415db3a ro fips=1
  ProcLoadAvg: 0.03 0.02 0.08 1/1288 11017
  ProcLocks:
   1: POSIX  ADVISORY  WRITE 3709 00:14:665 0 EOF
   2: POSIX  ADVISORY  WRITE 3593 00:14:655 0 EOF
   3: POSIX  ADVISORY  WRITE 1658 00:14:376 0 EOF
   4: FLOCK  ADVISORY  WRITE 3560 00:14:637 0 EOF
   5: POSIX  ADVISORY  WRITE 3571 00:14:640 0 EOF
  ProcSwaps:
   Filename TypeSizeUsedPriority
   /swap.img   file 8388544 0   -1
  ProcVersion: Linux version 4.4.0-59-generic (buildd@bos01-ppc64el-029) (gcc 
version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #80-Ubuntu SMP Fri 
Jan 6 17:35:59 UTC 2017
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-59-generic N/A
   linux-backports-modules-4.4.0-59-generic  N/A
   linux-firmware1.157.6
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  cpu_cores: Number of cores present = 20
  cpu_coreson: Number of cores online = 20
  cpu_dscr: DSCR is 0
  cpu_freq:
   min: 3.959 GHz (cpu 79)
   max: 3.988 GHz (cpu 81)
   avg: 3.974 GHz
  cpu_runmode:
   Could not retrieve current diagnostics mode,
   No kernel interface 

[Kernel-packages] [Bug 1665447] Re: kernel ppa is building amd64 files inside mainline ppc64el package

[Manoj Iyer]

[ Fixing fixdep - from x86_64 to ppc64el ]

After you install the debs for kernel and headers do the following:

root@lazy:/# updatedb
root@lazy:/# locate fixdep
/usr/src/linux-headers-4.10.0-041000/scripts/basic/fixdep.c
/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic/.fixdep.cmd
/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic/fixdep
/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic/fixdep.c
/usr/src/linux-headers-4.9.0-15/scripts/basic/fixdep.c
/usr/src/linux-headers-4.9.0-15-generic/scripts/basic/.fixdep.cmd
/usr/src/linux-headers-4.9.0-15-generic/scripts/basic/fixdep
/usr/src/linux-headers-4.9.0-15-generic/scripts/basic/fixdep.c
root@lazy:/#


root@lazy:/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic# ls
bin2c  bin2c.c  fixdep  fixdep.c  Makefile
root@lazy:/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic# file 
fixdep
fixdep: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=438d1c0255e4943c4af1b9568a4cbe83d9034737, not stripped

root@lazy:/usr/src/linux-headers-4.10.0-041000-generics# apt update; apt
install -y make gcc

root@lazy:/usr/src/linux-headers-4.10.0-041000-generic# make scripts_basic
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --silentoldconfig Kconfig
root@lazy:/usr/src/linux-headers-4.10.0-041000-generic#

root@lazy:/usr/src/linux-headers-4.10.0-041000-generic# file 
/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic/fixdep
/usr/src/linux-headers-4.10.0-041000-generic/scripts/basic/fixdep: ELF 64-bit 
LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically 
linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=497f0dbcfa70be01e7057cfd674e361ccd6d035d, not stripped
root@lazy:/usr/src/linux-headers-4.10.0-041000-generic#

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1665447

Title:
  kernel ppa is building amd64 files inside mainline ppc64el package

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Kernel PPA contains a files that are compiled against amd64 instead of
  ppc64el. This makes this kernel unusable:

  Example:

  PPA: http://kernel.ubuntu.com/~kernel-ppa/mainline/

  Kernel: http://kernel.ubuntu.com/\~kernel-ppa/mainline/v4.10-rc8
  /linux-
  headers-4.10.0-041000rc8-generic_4.10.0-041000rc8.201702121731_ppc64el.deb

  ➜  ppa dpkg-deb -x linux-
  headers-4.10.0-041000rc8-generic_4.10.0-041000rc8.201702121731_ppc64el.deb
  .

  ➜  ppa find . -name fixdep 
  ./usr/src/linux-headers-4.10.0-041000rc8-generic/scripts/basic/fixdep

  ➜  ppa file 
./usr/src/linux-headers-4.10.0-041000rc8-generic/scripts/basic/fixdep
  ./usr/src/linux-headers-4.10.0-041000rc8-generic/scripts/basic/fixdep: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=438d1c0255e4943c4af1b9568a4cbe83d9034737, not stripped

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1665447/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1665447] Re: kernel ppa is building amd64 files inside mainline ppc64el package

[Manoj Iyer]

[ Installing debs on ppc64el works ]

root@lazy:/# wget 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb
--2017-02-23 21:16:49--  
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb
Resolving kernel.ubuntu.com (kernel.ubuntu.com)... 91.189.94.216
Connecting to kernel.ubuntu.com (kernel.ubuntu.com)|91.189.94.216|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 59612954 (57M) [application/x-debian-package]
Saving to: 
‘linux-image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb’

linux-image-4.10.0- 100%[===>]  56.85M  2.23MB/sin
39s

2017-02-23 21:17:29 (1.45 MB/s) - ‘linux-
image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb’
saved [59612954/59612954]

root@lazy:/# dpkg -i 
linux-image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb
Selecting previously unselected package linux-image-4.10.0-041000-generic.
(Reading database ... 54943 files and directories currently installed.)
Preparing to unpack 
linux-image-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb ...
Done.
Unpacking linux-image-4.10.0-041000-generic (4.10.0-041000.201702191831) ...
Setting up linux-image-4.10.0-041000-generic (4.10.0-041000.201702191831) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 
4.10.0-041000-generic /boot/vmlinux-4.10.0-041000-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 
4.10.0-041000-generic /boot/vmlinux-4.10.0-041000-generic
update-initramfs: Generating /boot/initrd.img-4.10.0-041000-generic
Unsupported ioctl: cmd=0x5331
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 
4.10.0-041000-generic /boot/vmlinux-4.10.0-041000-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 
4.10.0-041000-generic /boot/vmlinux-4.10.0-041000-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 
4.10.0-041000-generic /boot/vmlinux-4.10.0-041000-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinux-4.10.0-041000-generic
Found initrd image: /boot/initrd.img-4.10.0-041000-generic
Found linux image: /boot/vmlinux-4.9.0-15-generic
Found initrd image: /boot/initrd.img-4.9.0-15-generic
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  Found Ubuntu Zesty Zapus (development branch) (17.04) on /dev/sda2
  Adding boot menu entry for EFI firmware configuration
  done
root@lazy:/#

root@lazy:/# wget 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-headers-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb
--2017-02-23 21:25:36--  
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-headers-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb
Resolving kernel.ubuntu.com (kernel.ubuntu.com)... 91.189.94.216
Connecting to kernel.ubuntu.com (kernel.ubuntu.com)|91.189.94.216|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 923282 (902K) [application/x-debian-package]
Saving to: 
‘linux-headers-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb’

linux-headers-4.10. 100%[===>] 901.64K   862KB/sin
1.0s

2017-02-23 21:25:37 (862 KB/s) - ‘linux-
headers-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb’
saved [923282/923282]


root@lazy:/# wget 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-headers-4.10.0-041000_4.10.0-041000.201702191831_all.deb
--2017-02-23 21:26:22--  
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/linux-headers-4.10.0-041000_4.10.0-041000.201702191831_all.deb
Resolving kernel.ubuntu.com (kernel.ubuntu.com)... 91.189.94.216
Connecting to kernel.ubuntu.com (kernel.ubuntu.com)|91.189.94.216|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 10340044 (9.9M) [application/x-debian-package]
Saving to: ‘linux-headers-4.10.0-041000_4.10.0-041000.201702191831_all.deb’

linux-headers-4.10. 100%[===>]   9.86M  2.64MB/sin
4.6s

2017-02-23 21:26:26 (2.16 MB/s) - ‘linux-
headers-4.10.0-041000_4.10.0-041000.201702191831_all.deb’ saved
[10340044/10340044]

root@lazy:/# dpkg -i linux-headers-4.10.0-041000*.deb
Selecting previously unselected package linux-headers-4.10.0-041000.
(Reading database ... 69913 files and directories currently installed.)
Preparing to unpack 
linux-headers-4.10.0-041000_4.10.0-041000.201702191831_all.deb ...
Unpacking linux-headers-4.10.0-041000 (4.10.0-041000.201702191831) ...
Preparing to unpack 
linux-headers-4.10.0-041000-generic_4.10.0-041000.201702191831_ppc64el.deb ...
Unpacking linux-headers-4.10.0-041000-generic (4.10.0-041000.201702191831) over 
(4.10.0-041000.201702191831) ...
Setting up linux-headers-4.10.0-041000 

[Kernel-packages] [Bug 1667599] Re: CAPI:Ubuntu: Kernel panic while rebooting

[Manoj Iyer]

Please file bugs with bug description and process to recreate.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1667599

Title:
  CAPI:Ubuntu: Kernel panic while rebooting

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  default desc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1667599/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1664708] Re: LTPstress :- genload: page allocation stalls on Ubuntu 17.04 , Power NV system

[Manoj Iyer]

** Changed in: linux (Ubuntu)
   Status: New => Won't Fix

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1664708

Title:
  LTPstress :- genload: page allocation stalls on Ubuntu 17.04 , Power
  NV system

Status in linux package in Ubuntu:
  Won't Fix

Bug description:
  == Comment: #0 - Shriya R. Kulkarni  - 2017-02-10 
06:24:36 ==
  Problem Description :
  ==
  Executed ./ltpstress.sh from ltp testsuite on Bare metal and suddenly system 
hangs up for few minutes. I see call traces in dmesg as genload : page 
allocation stalls.

  Test : 
  -
  Execution of ltpstress (LTP version : ltp-full-20170116)

  System :
  -- 
  Ubuntu 17.04, Power NV(Habanero and POwerKVM5)

  uname -a  : 
  ---
  4.9.0-15-generic

  Steps :
  --
  1. Download ltp testsuite
  2. Untar
  3. ./configure, make , make install
  4. cd /opt/ltp/testscripts/
  5. ./ltpstress.sh

  
  Call trace :
  

  [ 5443.865352] genload: 
  [ 5443.865352] genload: page allocation stalls for 37764ms, order:0, 
mode:0x24200ca(GFP_HIGHUSER_MOVABLE)
  [ 5443.865360] page allocation stalls for 51524ms, order:0
  [ 5443.865362] , mode:0x24200ca(GFP_HIGHUSER_MOVABLE)
  [ 5443.865365] CPU: 68 PID: 33142 Comm: genload Not tainted 4.9.0-15-generic 
#16-Ubuntu
  [ 5443.865366] Call Trace:
  [ 5443.865372] [c03bf10d3940] [c0b2b720] dump_stack+0xb0/0xf0 
(unreliable)
  [ 5443.865377] [c03bf10d3980] [c0259560] warn_alloc+0x130/0x160
  [ 5443.865382] [c03bf10d3a10] [c025a1b0] 
__alloc_pages_nodemask+0xb80/0xff0
  [ 5443.865386] [c03bf10d3c30] [c02d2794] 
alloc_pages_vma+0x104/0x350
  [ 5443.865390] [c03bf10d3cc0] [c029e948] 
handle_mm_fault+0x1058/0x1510
  [ 5443.865393] [c03bf10d3d80] [c0054d10] do_page_fault+0x350/0x7d0
  [ 5443.865398] [c03bf10d3e30] [c000b148] 
handle_page_fault+0x10/0x30
  [ 5443.865400] Mem-Info:
  [ 5443.865403] CPU: 22 PID: 33414 Comm: genload Not tainted 4.9.0-15-generic 
#16-Ubuntu
  [ 5443.865404] Call Trace:
  [ 5443.865407] [c03b565e7940] [c0b2b720] dump_stack+0xb0/0xf0
  [ 5443.865414] active_anon:3975704 inactive_anon:84983 isolated_anon:12968
  active_file:233 inactive_file:186 isolated_file:0
  unevictable:69 dirty:4 writeback:5409 unstable:0
  slab_reclaimable:5089 slab_unreclaimable:25129
  mapped:107 shmem:3 pagetables:1631 bounce:0
  free:2544 free_pcp:0 free_cma:214
  [ 5443.865416]  (unreliable)
  [ 5443.865420] [c03b565e7980] [c0259560] warn_alloc+0x130/0x160
  [ 5443.865424] [c03b565e7a10] [c025a1b0] 
__alloc_pages_nodemask+0xb80/0xff0
  [ 5443.865428] [c03b565e7c30] [c02d2794] 
alloc_pages_vma+0x104/0x350
  [ 5443.865438] [c03b565e7cc0] [c029e948] 
handle_mm_fault+0x1058/0x1510
  [ 5443.865438] Node 0 active_anon:254445056kB inactive_anon:5438912kB 
active_file:14912kB inactive_file:11904kB unevictable:4416kB 
isolated(anon):829952kB isolated(file):0kB mapped:6848kB dirty:256kB 
writeback:346176kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 217022464kB 
anon_thp: 192kB writeback_tmp:0kB unstable:0kB pages_scanned:0 
all_unreclaimable? no
  [ 5443.865443] [c03b565e7d80] [c0054d10] do_page_fault+0x350/0x7d0
  [ 5443.865443] Node 0 DMA free:162816kB min:180224kB low:443776kB 
high:707328kB active_anon:254445056kB inactive_anon:5436096kB 
active_file:10816kB inactive_file:15232kB unevictable:4416kB 
writepending:341504kB present:268435456kB managed:263658752kB mlocked:4416kB 
slab_reclaimable:325696kB slab_unreclaimable:1608256kB kernel_stack:21776kB 
pagetables:104384kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:13696kB
  [ 5443.865453] lowmem_reserve[]:
  [ 5443.865457] [c03b565e7e30] [c000b148] 
handle_page_fault+0x10/0x30
  [ 5443.865458]  0
  [ 5443.865460]  0
  [ 5443.865461]  0 0
  [ 5443.865464] Mem-Info:
  [ 5443.865466] Node 0 DMA: 433*64kB (UMEC) 135*128kB 
  [ 5443.865476] active_anon:3975704 inactive_anon:84983 isolated_anon:12968
  active_file:233 inactive_file:186 isolated_file:0
  unevictable:69 dirty:4 writeback:5409 unstable:0
  slab_reclaimable:5089 slab_unreclaimable:25129
  mapped:107 shmem:3 pagetables:1631 bounce:0
  free:2544 free_pcp:0 free_cma:214
  [ 5443.865477] (UMEC) 35*256kB (UME) 10*512kB (UMEC) 32*1024kB (UME) 9*2048kB 
(UME) 3*4096kB (UM) 6*8192kB (MC) 0*16384kB = 171712kB
  [ 5443.865493] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=1024kB

  == Comment: #4 - Shriya R. Kulkarni  - 2017-02-14
  00:43:01 ==

  
  Hi 

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

The attached patch is for:

* kexec: Increase the upper limit for RAM segments (LP: #1663400)

This patch applies cleanly on Zesty kexec-tools:
https://pastebin.ubuntu.com/23995216/

[TESTING with Zesty kexec-tools on hardware]
ubuntu@ubuntu:~$ dpkg -l | grep kexec-tools
ii  kexec-tools   1:2.0.14-1ubuntu2.1 arm64 
   tools to support fast kexec reboots
ubuntu@ubuntu:~$

ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic
arch_process_options:141: command_line: 
root=UUID=6c2f8a0a-5a0a-4f7b-8427-6e119e950aaa ro splash quiet vt.handoff=7
arch_process_options:143: initrd: /boot/initrd.img-4.7.0-2-generic
arch_process_options:144: dtb: (null)
Try gzip decompression.
kernel: 0xa9e5e010 kernel_size: 0xf36800
get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
get_memory_ranges_iomem_cb: 058a - 058a : System RAM
get_memory_ranges_iomem_cb: 058b - 058b : System RAM
get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM
get_memory_ranges_iomem_cb: 08d0 - 08ed : System RAM
get_memory_ranges_iomem_cb: 08ee - 08ee0fff : System RAM
get_memory_ranges_iomem_cb: 08ee1000 - 08ee3fff : System RAM
get_memory_ranges_iomem_cb: 08ee4000 - 08ee : System RAM
get_memory_ranges_iomem_cb: 08ef - 092a : System RAM
get_memory_ranges_iomem_cb: 092b - 092d : System RAM
get_memory_ranges_iomem_cb: 092e - 09422fff : System RAM
get_memory_ranges_iomem_cb: 09423000 - 0949 : System RAM
get_memory_ranges_iomem_cb: 094a - 0957 : System RAM
get_memory_ranges_iomem_cb: 0958 - 0958cfff : System RAM
get_memory_ranges_iomem_cb: 0958d000 - 098c : System RAM
get_memory_ranges_iomem_cb: 098d - 098d0fff : System RAM
get_memory_ranges_iomem_cb: 098d1000 - 098dbfff : System RAM
get_memory_ranges_iomem_cb: 098dc000 - 0e8b : System RAM
get_memory_ranges_iomem_cb: 0e8c - 0e8e : System RAM
get_memory_ranges_iomem_cb: 0e8f - 0fff : System RAM
get_memory_ranges_iomem_cb: 1080 - 17fe : System RAM
get_memory_ranges_iomem_cb: 1c02 - 1c7f : System RAM
get_memory_ranges_iomem_cb: 1c80 - 1c80 : System RAM
get_memory_ranges_iomem_cb: 1c81 - 7efb : System RAM
get_memory_ranges_iomem_cb: 7efc - 7efd : System RAM
get_memory_ranges_iomem_cb: 7efe - 7efe : System RAM
get_memory_ranges_iomem_cb: 7eff - 7eff : System RAM
get_memory_ranges_iomem_cb: 7f00 - 0017 : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 00a0
image_arm64_load: text_offset:0008
image_arm64_load: image_size: 0103
image_arm64_load: phys_offset:0020
image_arm64_load: vp_offset:  
image_arm64_load: PE format:  yes
read_1st_dtb: found /sys/firmware/fdt
initrd: base 341, size 1c7b7e4h (29865956)
dtb_set_initrd: start 54591488, end 84457444, size 29865956 (29165 KiB)
dtb:base 1ab, size 1f2h (498)
sym: sha256_starts info: 12 other: 00 shndx: 1 value: e80 size: 58
sym: sha256_starts value: 1ab1e80 addr: 1ab1014
machine_apply_elf_rel: CALL26 580006539400->580006539400039b
sym: sha256_update info: 12 other: 00 shndx: 1 value: 2de0 size: c
sym: sha256_update value: 1ab3de0 addr: 1ab1030
machine_apply_elf_rel: CALL26 eb16027f9400->eb16027f94000b6c
sym: sha256_finish info: 12 other: 00 shndx: 1 value: 2df0 size: 1bc
sym: sha256_finish value: 1ab3df0 addr: 1ab1048
machine_apply_elf_rel: CALL26 d28004029400->d280040294000b6a
sym: memcmp info: 12 

[Kernel-packages] [Bug 1663400] [NEW] [SRU] kexec: Increase the upper limit for RAM segments

[Manoj Iyer]

Public bug reported:

[Impact]
On a newer UEFI based Qualcomm target the number of system ram regions 
retrieved from /proc/iomem  are ~40. Currently KEXEC_SEGMENT_MAX is set to 16, 
which represents the kexec segments passed to kexec_load syscall, like kernel 
image, initrd image etc. The patch increases the value to 64.

[Test Case]
NA

[Regression Potential]
Since patches are confined to arm[64] there is a low overall risk of regression.

** Affects: kexec-tools (Ubuntu)
 Importance: Undecided
 Assignee: Manoj Iyer (manjo)
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1663400

Title:
  [SRU] kexec: Increase the upper limit for RAM segments

Status in kexec-tools package in Ubuntu:
  New

Bug description:
  [Impact]
  On a newer UEFI based Qualcomm target the number of system ram regions 
retrieved from /proc/iomem  are ~40. Currently KEXEC_SEGMENT_MAX is set to 16, 
which represents the kexec segments passed to kexec_load syscall, like kernel 
image, initrd image etc. The patch increases the value to 64.

  [Test Case]
  NA

  [Regression Potential]
  Since patches are confined to arm[64] there is a low overall risk of 
regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1663400/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1663400] Re: [SRU] kexec: Increase the upper limit for RAM segments

[Manoj Iyer]

** Description changed:

  [Impact]
  On a newer UEFI based Qualcomm target the number of system ram regions 
retrieved from /proc/iomem  are ~40. Currently KEXEC_SEGMENT_MAX is set to 16, 
which represents the kexec segments passed to kexec_load syscall, like kernel 
image, initrd image etc. The patch increases the value to 64.
  
  [Test Case]
- NA
+ == System RAM reported by /proc/iomem ==
+ ubuntu@ubuntu:~$ sudo cat /proc/iomem | grep "System RAM"
+ 0020-0020 : System RAM
+ 0082-0307 : System RAM
+ 0308-0308 : System RAM
+ 0309-031f : System RAM
+ 0320-033f : System RAM
+ 0341-0589 : System RAM
+ 058a-058a : System RAM
+ 058b-058b : System RAM
+ 058c-0597 : System RAM
+ 0598-05987fff : System RAM
+ 05988000-0598bfff : System RAM
+ 0598c000-05a0 : System RAM
+ 05a1-05aa : System RAM
+ 05ab-05ca0fff : System RAM
+ 05ca1000-08ca : System RAM
+ 08cb-08cf : System RAM
+ 08d0-08ed : System RAM
+ 08ee-08ee0fff : System RAM
+ 08ee1000-08ee3fff : System RAM
+ 08ee4000-08ee : System RAM
+ 08ef-092a : System RAM
+ 092b-092d : System RAM
+ 092e-09422fff : System RAM
+ 09423000-0949 : System RAM
+ 094a-0957 : System RAM
+ 0958-0958cfff : System RAM
+ 0958d000-098c : System RAM
+ 098d-098d0fff : System RAM
+ 098d1000-098dbfff : System RAM
+ 098dc000-0e8b : System RAM
+ 0e8c-0e8e : System RAM
+ 0e8f-0fff : System RAM
+ 1080-17fe : System RAM
+ 1c02-1c7f : System RAM
+ 1c80-1c80 : System RAM
+ 1c81-7efb : System RAM
+ 7efc-7efd : System RAM
+ 7efe-7efe : System RAM
+ 7eff-7eff : System RAM
+ 7f00-17 : System RAM
+ ubuntu@ubuntu:~$
+ 
+ == BEFORE PATCH: System RAM reported by kexec ==
+ ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
+ get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
+ get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
+ get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
+ get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
+ get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
+ get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
+ get_memory_ranges_iomem_cb: 058a - 058a : System RAM
+ get_memory_ranges_iomem_cb: 058b - 058b : System RAM
+ get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
+ get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
+ get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
+ get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
+ get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
+ get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
+ get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
+ get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM
+ 
+ ==AFTER PATCH: System RAM reported by kexec ==
+ ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
+ get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
+ get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
+ get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
+ get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
+ get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
+ get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
+ get_memory_ranges_iomem_cb: 058a - 058a : System RAM
+ get_memory_ranges_iomem_cb: 058b - 058b : System RAM
+ get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
+ get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
+ get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
+ get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
+ get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
+ get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
+ get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
+ get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM
+ get_memory_ranges_iomem_cb: 08d0 - 08ed : System RAM
+ get_memory_ranges_iomem_cb: 08ee - 08ee0fff : System RAM
+ get_memory_ranges_iomem_cb: 08ee1000 - 08ee3fff : System RAM
+ get_memory_ranges_iomem_cb: 08ee4000 - 

[Kernel-packages] [Bug 1663400] Re: [SRU] kexec: Increase the upper limit for RAM segments

[Manoj Iyer]

[TEST with yakkety kexec-tools]

ubuntu@ubuntu:~$ sudo cat /proc/iomem  | grep "System RAM"
0020-0020 : System RAM
0082-0307 : System RAM
0308-0308 : System RAM
0309-031f : System RAM
0320-033f : System RAM
0341-0589 : System RAM
058a-058a : System RAM
058b-058b : System RAM
058c-0597 : System RAM
0598-05987fff : System RAM
05988000-0598bfff : System RAM
0598c000-05a0 : System RAM
05a1-05aa : System RAM
05ab-05ca0fff : System RAM
05ca1000-08ca : System RAM
08cb-08cf : System RAM
08d0-08ed : System RAM
08ee-08ee0fff : System RAM
08ee1000-08ee3fff : System RAM
08ee4000-08ee : System RAM
08ef-092a : System RAM
092b-092d : System RAM
092e-09422fff : System RAM
09423000-0949 : System RAM
094a-0957 : System RAM
0958-0958cfff : System RAM
0958d000-098c : System RAM
098d-098d0fff : System RAM
098d1000-098dbfff : System RAM
098dc000-0e8b : System RAM
0e8c-0e8e : System RAM
0e8f-0fff : System RAM
1080-17fe : System RAM
1c02-1c7f : System RAM
1c80-1c80 : System RAM
1c81-7efb : System RAM
7efc-7efd : System RAM
7efe-7efe : System RAM
7eff-7eff : System RAM
7f00-17 : System RAM
ubuntu@ubuntu:~$ 


ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic

get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
get_memory_ranges_iomem_cb: 058a - 058a : System RAM
get_memory_ranges_iomem_cb: 058b - 058b : System RAM
get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM
get_memory_ranges_iomem_cb: 08d0 - 08ed : System RAM
get_memory_ranges_iomem_cb: 08ee - 08ee0fff : System RAM
get_memory_ranges_iomem_cb: 08ee1000 - 08ee3fff : System RAM
get_memory_ranges_iomem_cb: 08ee4000 - 08ee : System RAM
get_memory_ranges_iomem_cb: 08ef - 092a : System RAM
get_memory_ranges_iomem_cb: 092b - 092d : System RAM
get_memory_ranges_iomem_cb: 092e - 09422fff : System RAM
get_memory_ranges_iomem_cb: 09423000 - 0949 : System RAM
get_memory_ranges_iomem_cb: 094a - 0957 : System RAM
get_memory_ranges_iomem_cb: 0958 - 0958cfff : System RAM
get_memory_ranges_iomem_cb: 0958d000 - 098c : System RAM
get_memory_ranges_iomem_cb: 098d - 098d0fff : System RAM
get_memory_ranges_iomem_cb: 098d1000 - 098dbfff : System RAM
get_memory_ranges_iomem_cb: 098dc000 - 0e8b : System RAM
get_memory_ranges_iomem_cb: 0e8c - 0e8e : System RAM
get_memory_ranges_iomem_cb: 0e8f - 0fff : System RAM
get_memory_ranges_iomem_cb: 1080 - 17fe : System RAM
get_memory_ranges_iomem_cb: 1c02 - 1c7f : System RAM
get_memory_ranges_iomem_cb: 1c80 - 1c80 : System RAM
get_memory_ranges_iomem_cb: 1c81 - 7efb : System RAM
get_memory_ranges_iomem_cb: 7efc - 7efd : System RAM
get_memory_ranges_iomem_cb: 7efe - 7efe : System RAM
get_memory_ranges_iomem_cb: 7eff - 7eff : System RAM
get_memory_ranges_iomem_cb: 7f00 - 0017 : System RAM

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1663400

Title:
  [SRU] kexec: Increase the upper limit for RAM segments

Status in kexec-tools package in Ubuntu:
  New

Bug description:
  [Impact]
  Currently kexec is unable to see all the "System RAM" recorded in /proc/iomem.

  On a newer UEFI based Qualcomm target the 

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

The attached patch has the complete set of patches needed for kexec support on 
ARM64. 
* Enable ARM64 support in kexec-tools (LP: #1659618)
* Enable support for compressed kernels on ARM64 (LP: #1661363)
* kexec: Increase the upper limit for RAM segments (LP: #1663400)

This patch applies cleanly on Yakkety kexec-tools:
https://pastebin.ubuntu.com/23968404/

Testing for lp 1663400 is posted to the SRU request description. Testing
results for arm64 support yielded the same results as previously.

ubuntu@yk:/tmp$ dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.10-2ubuntu1.1  
arm64tools to support fast kexec reboots
ubuntu@yk:/tmp$

ubuntu@yk:/tmp$ sudo kexec -l /boot/vmlinuz-4.8.0-38-generic 
--initrd=/boot/initrd.img-4.8.0-38-generic 
--append="root=UUID=d80e6bcf-a747-43fd-97fe-e47574637b2b ro  vt.handoff=7"
ubuntu@yk:/tmp$

ubuntu@yk:/tmp$ sudo kexec -e
Ubuntu 16.10 yk ttyAMA0

yk login: [ 1902.177836] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-38-generic (manjo@tangerine) (gcc version 
6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #40ubuntu1 SMP Mon Feb 6 21:55:35 UTC 
2017 (Ubuntu 4.8.0-38.40ubuntu1-generic 4.8.17)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by EDK II
[0.00] efi:  SMBIOS=0x5bdb  SMBIOS 3.0=0x5866  PROP=0x5f714518  
ACPI=0x5869  ACPI 2.0=0x58690014 
[0.00] No NUMA configuration found

** Patch added: "[YAKKETY Final] kexec arm64 support patch"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4816757/+files/final-kexec-yakkety-arm64-support.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

The attached patch has the complete set of patches needed for kexec support on 
ARM64.
  * kexec: Increase the upper limit for RAM segments [LP: #1663400]
  * Enable compressed kernel support for ARM64 [LP: #1661363]
  * Enable ARM64 support [LP: #1659618]

This patch applies cleanly on Xenial kexec-tools. 
https://pastebin.ubuntu.com/23968089/
Testing for lp 1663400 is posted to the SRU request description. Testing 
results for arm64 support yielded the same results as previously. 

Ubuntu 16.04.1 LTS ubuntu ttyAMA2

ubuntu login: [  857.281231] mmc0: Reset 0x1 never completed.
[  860.859581] kexec_core: Starting new kernel
[0.00] arch_timer: Failed to initialize memory-mapped timer, skipping
[1.169613] coresight-tmc ARMHFFF0:00: Byte-cntr-irq not specified
[1.178015] Failed to find cpu0 device node
[1.452042] mmc0: Reset 0x1 never completed.
[1.555603] mmc0: Reset 0x1 never completed.
[1.659871] mmc0: Reset 0x1 never completed.
[1.665249] hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
[1.673240] hub 4-0:1.0: config failed, hub doesn't have any ports! (err -19)
[1.680657] hub 6-0:1.0: config failed, hub doesn't have any ports! (err -19)
[1.687974] hub 8-0:1.0: config failed, hub doesn't have any ports! (err -19)

** Patch added: "[XENIAL V2] kexec arm64 support patch"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+attachment/4816668/+files/V2-kexec-xenial-arm64-support.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1663400] Re: kexec: arm64: Increase the upper limit for RAM segments

[Manoj Iyer]

The attached patch is for:

* kexec: Increase the upper limit for RAM segments (LP: #1663400)

This patch applies cleanly on Zesty kexec-tools:
https://pastebin.ubuntu.com/23995216/

[TESTING with Zesty kexec-tools on hardware]
ubuntu@ubuntu:~$ dpkg -l | grep kexec-tools
ii  kexec-tools   1:2.0.14-1ubuntu2.1 arm64 
   tools to support fast kexec reboots
ubuntu@ubuntu:~$

ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic
arch_process_options:141: command_line: 
root=UUID=6c2f8a0a-5a0a-4f7b-8427-6e119e950aaa ro splash quiet vt.handoff=7
arch_process_options:143: initrd: /boot/initrd.img-4.7.0-2-generic
arch_process_options:144: dtb: (null)
Try gzip decompression.
kernel: 0xa9e5e010 kernel_size: 0xf36800
get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
get_memory_ranges_iomem_cb: 058a - 058a : System RAM
get_memory_ranges_iomem_cb: 058b - 058b : System RAM
get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM
get_memory_ranges_iomem_cb: 08d0 - 08ed : System RAM
get_memory_ranges_iomem_cb: 08ee - 08ee0fff : System RAM
get_memory_ranges_iomem_cb: 08ee1000 - 08ee3fff : System RAM
get_memory_ranges_iomem_cb: 08ee4000 - 08ee : System RAM
get_memory_ranges_iomem_cb: 08ef - 092a : System RAM
get_memory_ranges_iomem_cb: 092b - 092d : System RAM
get_memory_ranges_iomem_cb: 092e - 09422fff : System RAM
get_memory_ranges_iomem_cb: 09423000 - 0949 : System RAM
get_memory_ranges_iomem_cb: 094a - 0957 : System RAM
get_memory_ranges_iomem_cb: 0958 - 0958cfff : System RAM
get_memory_ranges_iomem_cb: 0958d000 - 098c : System RAM
get_memory_ranges_iomem_cb: 098d - 098d0fff : System RAM
get_memory_ranges_iomem_cb: 098d1000 - 098dbfff : System RAM
get_memory_ranges_iomem_cb: 098dc000 - 0e8b : System RAM
get_memory_ranges_iomem_cb: 0e8c - 0e8e : System RAM
get_memory_ranges_iomem_cb: 0e8f - 0fff : System RAM
get_memory_ranges_iomem_cb: 1080 - 17fe : System RAM
get_memory_ranges_iomem_cb: 1c02 - 1c7f : System RAM
get_memory_ranges_iomem_cb: 1c80 - 1c80 : System RAM
get_memory_ranges_iomem_cb: 1c81 - 7efb : System RAM
get_memory_ranges_iomem_cb: 7efc - 7efd : System RAM
get_memory_ranges_iomem_cb: 7efe - 7efe : System RAM
get_memory_ranges_iomem_cb: 7eff - 7eff : System RAM
get_memory_ranges_iomem_cb: 7f00 - 0017 : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 00a0
image_arm64_load: text_offset:0008
image_arm64_load: image_size: 0103
image_arm64_load: phys_offset:0020
image_arm64_load: vp_offset:  
image_arm64_load: PE format:  yes
read_1st_dtb: found /sys/firmware/fdt
initrd: base 341, size 1c7b7e4h (29865956)

...

machine_apply_elf_rel: ABS64 ->01ab4158
kexec_load: entry = 0x1ab1640 flags = 0xb7
nr_segments = 4
segment[0].buf   = 0xa9e5e010
segment[0].bufsz = 0xf36800
segment[0].mem   = 0xa8
segment[0].memsz = 0x103
segment[1].buf   = 0x3c5cf1a0
segment[1].bufsz = 0x1f2
segment[1].mem   = 0x1ab
segment[1].memsz = 0x1000
segment[2].buf   = 0x3c5cf760
segment[2].bufsz = 0x3198
segment[2].mem   = 0x1ab1000
segment[2].memsz = 0x4000
segment[3].buf   = 0xa81e2010
segment[3].bufsz = 0x1c7b7e4
segment[3].mem   = 0x341
segment[3].memsz = 0x1c7c000
ubuntu@ubuntu:~$ sudo kexec -e

ubuntu login: [  516.350136] mmc0: Reset 0x1 never 

[Kernel-packages] [Bug 1664708] Re: LTPstress :- genload: page allocation stalls on Ubuntu 17.04 , Power NV system

[Manoj Iyer]

How long does it take for you to reproduce this issue? I ran the same
test on AMD64 for over 12hrs and was not able to reproduce the failure.
The 17.04 kernel I have is 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1664708

Title:
  LTPstress :- genload: page allocation stalls on Ubuntu 17.04 , Power
  NV system

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Shriya R. Kulkarni  - 2017-02-10 
06:24:36 ==
  Problem Description :
  ==
  Executed ./ltpstress.sh from ltp testsuite on Bare metal and suddenly system 
hangs up for few minutes. I see call traces in dmesg as genload : page 
allocation stalls.

  Test : 
  -
  Execution of ltpstress (LTP version : ltp-full-20170116)

  System :
  -- 
  Ubuntu 17.04, Power NV(Habanero and POwerKVM5)

  uname -a  : 
  ---
  4.9.0-15-generic

  Steps :
  --
  1. Download ltp testsuite
  2. Untar
  3. ./configure, make , make install
  4. cd /opt/ltp/testscripts/
  5. ./ltpstress.sh

  
  Call trace :
  

  [ 5443.865352] genload: 
  [ 5443.865352] genload: page allocation stalls for 37764ms, order:0, 
mode:0x24200ca(GFP_HIGHUSER_MOVABLE)
  [ 5443.865360] page allocation stalls for 51524ms, order:0
  [ 5443.865362] , mode:0x24200ca(GFP_HIGHUSER_MOVABLE)
  [ 5443.865365] CPU: 68 PID: 33142 Comm: genload Not tainted 4.9.0-15-generic 
#16-Ubuntu
  [ 5443.865366] Call Trace:
  [ 5443.865372] [c03bf10d3940] [c0b2b720] dump_stack+0xb0/0xf0 
(unreliable)
  [ 5443.865377] [c03bf10d3980] [c0259560] warn_alloc+0x130/0x160
  [ 5443.865382] [c03bf10d3a10] [c025a1b0] 
__alloc_pages_nodemask+0xb80/0xff0
  [ 5443.865386] [c03bf10d3c30] [c02d2794] 
alloc_pages_vma+0x104/0x350
  [ 5443.865390] [c03bf10d3cc0] [c029e948] 
handle_mm_fault+0x1058/0x1510
  [ 5443.865393] [c03bf10d3d80] [c0054d10] do_page_fault+0x350/0x7d0
  [ 5443.865398] [c03bf10d3e30] [c000b148] 
handle_page_fault+0x10/0x30
  [ 5443.865400] Mem-Info:
  [ 5443.865403] CPU: 22 PID: 33414 Comm: genload Not tainted 4.9.0-15-generic 
#16-Ubuntu
  [ 5443.865404] Call Trace:
  [ 5443.865407] [c03b565e7940] [c0b2b720] dump_stack+0xb0/0xf0
  [ 5443.865414] active_anon:3975704 inactive_anon:84983 isolated_anon:12968
  active_file:233 inactive_file:186 isolated_file:0
  unevictable:69 dirty:4 writeback:5409 unstable:0
  slab_reclaimable:5089 slab_unreclaimable:25129
  mapped:107 shmem:3 pagetables:1631 bounce:0
  free:2544 free_pcp:0 free_cma:214
  [ 5443.865416]  (unreliable)
  [ 5443.865420] [c03b565e7980] [c0259560] warn_alloc+0x130/0x160
  [ 5443.865424] [c03b565e7a10] [c025a1b0] 
__alloc_pages_nodemask+0xb80/0xff0
  [ 5443.865428] [c03b565e7c30] [c02d2794] 
alloc_pages_vma+0x104/0x350
  [ 5443.865438] [c03b565e7cc0] [c029e948] 
handle_mm_fault+0x1058/0x1510
  [ 5443.865438] Node 0 active_anon:254445056kB inactive_anon:5438912kB 
active_file:14912kB inactive_file:11904kB unevictable:4416kB 
isolated(anon):829952kB isolated(file):0kB mapped:6848kB dirty:256kB 
writeback:346176kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 217022464kB 
anon_thp: 192kB writeback_tmp:0kB unstable:0kB pages_scanned:0 
all_unreclaimable? no
  [ 5443.865443] [c03b565e7d80] [c0054d10] do_page_fault+0x350/0x7d0
  [ 5443.865443] Node 0 DMA free:162816kB min:180224kB low:443776kB 
high:707328kB active_anon:254445056kB inactive_anon:5436096kB 
active_file:10816kB inactive_file:15232kB unevictable:4416kB 
writepending:341504kB present:268435456kB managed:263658752kB mlocked:4416kB 
slab_reclaimable:325696kB slab_unreclaimable:1608256kB kernel_stack:21776kB 
pagetables:104384kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:13696kB
  [ 5443.865453] lowmem_reserve[]:
  [ 5443.865457] [c03b565e7e30] [c000b148] 
handle_page_fault+0x10/0x30
  [ 5443.865458]  0
  [ 5443.865460]  0
  [ 5443.865461]  0 0
  [ 5443.865464] Mem-Info:
  [ 5443.865466] Node 0 DMA: 433*64kB (UMEC) 135*128kB 
  [ 5443.865476] active_anon:3975704 inactive_anon:84983 isolated_anon:12968
  active_file:233 inactive_file:186 isolated_file:0
  unevictable:69 dirty:4 writeback:5409 unstable:0
  slab_reclaimable:5089 slab_unreclaimable:25129
  mapped:107 shmem:3 pagetables:1631 bounce:0
  free:2544 free_pcp:0 free_cma:214
  [ 5443.865477] (UMEC) 35*256kB (UME) 10*512kB (UMEC) 32*1024kB (UME) 9*2048kB 
(UME) 3*4096kB (UM) 6*8192kB (MC) 0*16384kB = 171712kB
  [ 5443.865493] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=1024kB

  == Comment: #4 - Shriya R. Kulkarni 

[Kernel-packages] [Bug 1663400] Re: kexec: arm64: Increase the upper limit for RAM segments

[Manoj Iyer]

** Summary changed:

- [SRU] kexec: arm64: Increase the upper limit for RAM segments
+ kexec: arm64: Increase the upper limit for RAM segments

** Bug watch added: Debian Bug tracker #854826
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854826

** Also affects: kexec-tools (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854826
   Importance: Unknown
   Status: Unknown

** Changed in: kexec-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu Yakkety)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: New => In Progress

** Changed in: kexec-tools (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1663400

Title:
  kexec: arm64: Increase the upper limit for RAM segments

Status in kexec-tools package in Ubuntu:
  In Progress
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [Impact]
  Currently kexec is unable to see all the "System RAM" recorded in /proc/iomem.

  On a newer UEFI based Qualcomm target the number of system ram regions
  retrieved from /proc/iomem  are ~40. Currently KEXEC_SEGMENT_MAX is
  set to 16, which represents the kexec segments passed to kexec_load
  syscall, like kernel image, initrd image etc. The patch increases the
  value to 64. This enables kexec to see all the "System RAM" as
  recorded in /proc/iomem.

  [Test Case]
  == System RAM reported by /proc/iomem ==
  ubuntu@ubuntu:~$ sudo cat /proc/iomem | grep "System RAM"
  0020-0020 : System RAM
  0082-0307 : System RAM
  0308-0308 : System RAM
  0309-031f : System RAM
  0320-033f : System RAM
  0341-0589 : System RAM
  058a-058a : System RAM
  058b-058b : System RAM
  058c-0597 : System RAM
  0598-05987fff : System RAM
  05988000-0598bfff : System RAM
  0598c000-05a0 : System RAM
  05a1-05aa : System RAM
  05ab-05ca0fff : System RAM
  05ca1000-08ca : System RAM
  08cb-08cf : System RAM
  08d0-08ed : System RAM
  08ee-08ee0fff : System RAM
  08ee1000-08ee3fff : System RAM
  08ee4000-08ee : System RAM
  08ef-092a : System RAM
  092b-092d : System RAM
  092e-09422fff : System RAM
  09423000-0949 : System RAM
  094a-0957 : System RAM
  0958-0958cfff : System RAM
  0958d000-098c : System RAM
  098d-098d0fff : System RAM
  098d1000-098dbfff : System RAM
  098dc000-0e8b : System RAM
  0e8c-0e8e : System RAM
  0e8f-0fff : System RAM
  1080-17fe : System RAM
  1c02-1c7f : System RAM
  1c80-1c80 : System RAM
  1c81-7efb : System RAM
  7efc-7efd : System RAM
  7efe-7efe : System RAM
  7eff-7eff : System RAM
  7f00-17 : System RAM
  ubuntu@ubuntu:~$

  == BEFORE PATCH: System RAM reported by kexec ==
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
  get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
  get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
  get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
  get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
  get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
  get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
  get_memory_ranges_iomem_cb: 058a - 058a : System RAM
  get_memory_ranges_iomem_cb: 058b - 058b : System RAM
  get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
  get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
  get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
  get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
  get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
  get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
  get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
  get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM

  ==AFTER PATCH: System RAM reported by kexec ==
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
  get_memory_ranges_iomem_cb: 0020

[Kernel-packages] [Bug 1658733] Re: Ubuntu 16.04.2KVM:kdump fails to mount root file system on multipath root device

[Manoj Iyer]

** Changed in: kexec-tools (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Louis Bouchard 
(louis-bouchard)

** Changed in: kexec-tools (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1658733

Title:
  Ubuntu 16.04.2KVM:kdump fails to mount root file system on multipath
  root device

Status in kexec-tools package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Richard M. Scheller - 2016-12-14 16:50:26 ==

  ---Problem Description---

  On a KVM guest installed to a multipath root device, the kdump kernel fails 
to mount the root file system.  This error does not occur in a similar guest 
installed to a single path device.
   
  Full console output of the kdump failure is attached.  These messages from 
the output may be relevant:

  Begin: Loading multipath modules ... Success: loaded module dm-multipath.
  done.
  Begin: Loading multipath hardware handlers ... Failure: failed to load module 
sc
  si_dh_alua.
  Failure: failed to load module scsi_dh_rdac.
  Failure: failed to load module scsi_dh_emc.
  done.
  Begin: Starting multipathd ... done.
   
  ---uname output---
  Linux dotg9 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8247-22L Ubuntu 16.04.1 KVM guest 
   
   
  ---Steps to Reproduce---
   - Install Ubuntu 16.04.1 to a muiltpath target disk
  - Install kdump-tools package
  - Configure kexec-tools to reserve sufficient RAM for the kdump kernel to 
load (I use 512MB) in /etc/default/grub.d/kexec-tools.cfg
  - Run update-grub
  - Reboot
  - Initiate a system crash using "echo c > /proc/sysrq-trigger"

  == Comment: #12 - Richard M. Scheller - 2016-12-20 20:37:45 ==
  Here is the log level 8 kdump console log requested in comment 10.

  == Comment: #21 - Richard M. Scheller - 2017-01-06 11:04:17 ==
  (In reply to comment #19)
  > Hi, I logged in dotkvm and I couldn't find the guest dotg9. Also, although I
  > found a dotg9.xml in /kte/xml/ it doesn't look like it uses multipath (it
  > uses .img files which I didn't found as disks).
  > 
  > Could you please recreate the guest for further debug? 

  Yes, I recreated the guest with its correct multipath lun
  configuration.  I have also attached the guest XML to this bug.

  > Besides that could you please let us know:
  >  - is the multipath the system's root? I mean / is installed/mounted on the
  > multipath device?

  Yes, the guest has only one disk.  That disk is actually a LUN from a
  fiber channel storage device with two paths on the host side.  I have
  passed through both paths to the guest, so the multipath nature of the
  target disk is known to the guest.

  In other words, the guest sees a multipath device and is using it as a
  multipath device.  The root file system is called /dev/mapper/mpatha-
  part2 on the guest.

  >  - how did you attach the device to the guest?

  Each FC LUN path on the host is mapped to a virtio-scsi controller on
  the guest using LUN passthrough.  (See the guest XML for details on
  this.)

  == Comment: #22 - Mauro Sergio Martins Rodrigues  - 2017-01-11 09:31:38 ==
  I managed to get kdump to mount rootfs and perform its tasks by setting 
KDUMP_CMDLINE_APPEND="nr_cpus=4" parameter in /etc/default/kdump-tools see 
http://pastebin.hursley.ibm.com/8239

  I'm still investigating to figure out what is the reason behind this
  behavior.

  Thanks,

  --
  maurosr

  == Comment: #23 - Mauricio Faria De Oliveira  - 2017-01-11 11:56:40 ==
  Mauro,

  (In reply to comment #22)
  > I managed to get kdump to mount rootfs and perform its tasks by setting
  > KDUMP_CMDLINE_APPEND="nr_cpus=4" parameter in /etc/default/kdump-tools see
  > http://pastebin.hursley.ibm.com/8239
  > 
  > I'm still investigating to figure out what is the reason behind this
  > behavior.
  > 
  > Thanks,
  > 
  > --
  > maurosr

  That would smell like an out of memory condition that is alleviated
  with a smaller number of CPUs allowed for the kernel (so the amount of
  memory associated with per-CPU stuff is less in total).

  Per the bug description, the memory reserved for the crashkernel is
  512MB:

  (In reply to comment #23)
  > - Configure kexec-tools to reserve sufficient RAM for the kdump kernel to
  > load (I use 512MB) in /etc/default/grub.d/kexec-tools.cfg

  That seems low for Power guests/systems. 
  I think it theory is doesn't seem so, but the reality is that _for some 
reason(s)_ we require just too much memory to load and boot a kernel/initramfs 
(either on boot or kdump).

  When working w/ kdump and Ubuntu, I usually set the crashkernel
  allocated size right away to 4GB to avoid problems.

  Since this is a smaller sized guest, obviously we'd want to use less
  than that, but more than 512 MB given the evidence observed.

  Hope this helps

  == Comment: #28 - 

[Kernel-packages] [Bug 1651376] Re: ISST-LTE:pVM:seedlp2:ubuntu 16.04.2: oom occurs when running stress tests

[Manoj Iyer]

Colin, Could you please help resolving this OOM with stress-ng?

** Also affects: stress-ng (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: stress-ng (Ubuntu)
 Assignee: (unassigned) => Colin Ian King (colin-king)

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1651376

Title:
  ISST-LTE:pVM:seedlp2:ubuntu 16.04.2: oom occurs when running stress
  tests

Status in linux package in Ubuntu:
  New
Status in stress-ng package in Ubuntu:
  New

Bug description:
  Problem Description
  
  We run stress tests on seedlp2, after a while a lot of oom messages echoed on 
the console again and again and the system hung up:

  
  [ 8331.537440] Out of memory (oom_kill_allocating_task): Kill process 27466 
(fork12) score 0 or sacrifice child
  [ 8331.537447] Killed process 27466 (fork12) total-vm:3072kB, anon-rss:0kB, 
file-rss:512kB, shmem-rss:0kB
  [ 8331.543871] oom_reaper: reaped process 27466 (fork12), now anon-rss:0kB, 
file-rss:0kB, shmem-rss:0kB
  [ 8331.544167] fork12 invoked oom-killer: 
gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
  [ 8331.544174] fork12 cpuset=/ mems_allowed=3
  [ 8331.544184] CPU: 19 PID: 20947 Comm: fork12 Tainted: G   OE   
4.8.0-31-generic #33~16.04.1-Ubuntu
  [ 8331.544189] Call Trace:
  [ 8331.544197] [c000b7fdb630] [c0b56554] dump_stack+0xb0/0xf0 
(unreliable)
  [ 8331.544204] [c000b7fdb670] [c0b53db4] dump_header+0x88/0x228
  [ 8331.544211] [c000b7fdb740] [c0258194] 
oom_kill_process+0x464/0x570
  [ 8331.544217] [c000b7fdb800] [c02588a4] out_of_memory+0x574/0x590
  [ 8331.544223] [c000b7fdb8a0] [c025fb18] 
__alloc_pages_nodemask+0xe98/0xee0
  [ 8331.544230] [c000b7fdba60] [c02da458] 
alloc_pages_vma+0x108/0x360
  [ 8331.544235] [c000b7fdbb00] [c02c3958] 
__read_swap_cache_async+0x1b8/0x2c0
  [ 8331.544241] [c000b7fdbb70] [c02c3a8c] 
read_swap_cache_async+0x2c/0x60
  [ 8331.544246] [c000b7fdbbb0] [c02c3cb0] 
swapin_readahead+0x1f0/0x2e0
  [ 8331.544253] [c000b7fdbc50] [c02a0b78] do_swap_page+0x338/0x9a0
  [ 8331.544258] [c000b7fdbcd0] [c02a550c] 
handle_mm_fault+0x98c/0x14c0
  [ 8331.544264] [c000b7fdbd80] [c0b4d2d0] do_page_fault+0x350/0x7d0
  [ 8331.553521] [c000b7fdbe30] [c0008948] 
handle_page_fault+0x10/0x30
  [ 8331.553552] Mem-Info:
  [ 8331.553567] active_anon:121 inactive_anon:6417 isolated_anon:742
  [ 8331.553567]  active_file:167 inactive_file:120 isolated_file:0
  [ 8331.553567]  unevictable:230 dirty:0 writeback:141 unstable:0
  [ 8331.553567]  slab_reclaimable:2483 slab_unreclaimable:24404
  [ 8331.553567]  mapped:122 shmem:0 pagetables:11341 bounce:0
  [ 8331.553567]  free:2812 free_pcp:0 free_cma:0
  [ 8331.553611] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB 
inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
mapped:0kB dirty:0kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 
0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:0 
all_unreclaimable? yes
  [ 8331.553642] Node 3 active_anon:7744kB inactive_anon:404544kB 
active_file:10688kB inactive_file:7680kB unevictable:14720kB 
isolated(anon):53632kB isolated(file):0kB mapped:7808kB dirty:0kB 
writeback:9024kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB 
writeback_tmp:0kB unstable:0kB pages_scanned:78640 all_unreclaimable? yes
  [ 8331.556952] Node 3 DMA free:179968kB min:180224kB low:225280kB 
high:270336kB active_anon:5824kB inactive_anon:419840kB active_file:6720kB 
inactive_file:3776kB unevictable:14720kB writepending:9024kB present:4194304kB 
managed:3624960kB mlocked:14720kB slab_reclaimable:158912kB 
slab_unreclaimable:1561856kB kernel_stack:202992kB pagetables:725824kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
  [ 8331.556978] lowmem_reserve[]: 0 0 0 0
  [ 8331.556988] Node 3 DMA: 1124*64kB (UME) 172*128kB (UME) 127*256kB (UM) 
95*512kB (M) 6*1024kB (M) 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 181248kB
  [ 8331.557022] Node 3 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=16384kB
  [ 8331.557032] Node 3 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=16777216kB
  [ 8331.557040] 7760 total pagecache pages
  [ 8331.563978] 7356 pages in swap cache
  [ 8331.563985] Swap cache stats: add 1612469, delete 1605113, find 
1293795/2233630
  [ 8331.563992] Free swap  = 9015616kB
  [ 8331.563997] Total swap = 12096448kB
  [ 8331.564003] 65536 pages RAM
  [ 8331.564007] 0 pages HighMem/MovableOnly
  [ 8331.564013] 8896 pages reserved
  [ 8331.564019] 0 pages cma reserved
  [ 8331.564024] 0 pages hwpoisoned

   
  ---uname output---
  4.8.0-31-generic 

[Kernel-packages] [Bug 1650062] Re: Ubuntu16.04.01VM:Docker-Powervm aufs bad file panic while running tests in a docker container

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Seth Forshee (sforshee)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1650062

Title:
  Ubuntu16.04.01VM:Docker-Powervm aufs bad file panic while running
  tests in a docker container

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Vinutha GS - 2016-12-13 02:47:35 ==
  When some of the base and io tests were run inside a docker container, the 
par crashed and below are the stack trace and other details.

  Steps to re-create -
  1. Install 16.04.02 on a PowerVM lpar.
  2. Ran setup general.
  3. Ran docker scripts[home grown scripts] which does docker package 
installation and other setups required to run STAF cases inside docker 
container.
  4. We have docker image using which we launch containers and start tests 
inside containers.
  If complete details are required on how to execute scripts, please let me 
know.
  5. STAF Base and IO tests were started inside containers successfully, after 
sometime, I see partition is in XMON.

  Docker info -
  docker info
  Containers: 0
   Running: 0
   Paused: 0
   Stopped: 0
  Images: 0
  Server Version: 1.12.1
  Storage Driver: aufs
   Root Dir: /var/lib/docker/aufs
   Backing Filesystem: extfs
   Dirs: 0
   Dirperm1 Supported: true
  Logging Driver: json-file
  Cgroup Driver: cgroupfs
  Plugins:
   Volume: local
   Network: null host bridge overlay
  Swarm: inactive
  Runtimes: runc
  Default Runtime: runc
  Security Options: apparmor
  Kernel Version: 4.4.0-53-generic
  Operating System: Ubuntu 16.04.1 LTS
  OSType: linux
  Architecture: ppc64le
  CPUs: 24
  Total Memory: 49.89 GiB
  Name: bamlp3
  ID: I7VI:G4RJ:RHTQ:WNGV:52FK:K7AZ:YDJQ:KFUM:P3UA:MZ3I:5XUY:WV3N
  Docker Root Dir: /var/lib/docker
  Debug Mode (client): false
  Debug Mode (server): false
  Registry: https://index.docker.io/v1/
  WARNING: No swap limit support
  Insecure Registries:
   127.0.0.0/8

  docker ps -a
  CONTAINER IDIMAGE   COMMAND  CREATED  
   STATUS  PORTS   NAMES
  61f2b8ab0a8632d545c3ea01"/bin/sh -c ./staf_io"   24 minutes 
ago  Up 24 minutes   bamlp3-io
  151da0322172590e44f15214"/bin/sh -c ./staf_ba"   30 minutes 
ago  Up 30 minutes   bamlp3-base

  
  Stack trace -
  8:mon> t
  [c00a5e147d10] da04ca98 aufs_flush_nondir+0x38/0x50 [aufs]
  [c00a5e147d40] c02e0428 filp_close+0x68/0xe0
  [c00a5e147dc0] c030f71c __close_fd+0xcc/0x150
  [c00a5e147e00] c02e04d4 SyS_close+0x34/0x90
  [c00a5e147e30] c0009204 system_call+0x38/0xb4
  --- Exception: c00 (System Call) at 3fff8bc217d8
  SP (3fffd85203b0) is in userspace
  8:mon> e
  cpu 0x8: Vector: 300 (Data Access) at [c00a5e147a40]
  pc: da04bdd4: au_do_flush+0x44/0x220 [aufs]
  lr: da04ca98: aufs_flush_nondir+0x38/0x50 [aufs]
  sp: c00a5e147cc0
 msr: 80009033
 dar: 28
   dsisr: 4000
current = 0xc00a8b7fc8e0
paca= 0xcfb44c00 softe: 0irq_happened: 0x01
  pid   = 11936, comm = remap_file_page
  8:mon>

  Release details -
  uname -r
  4.4.0-53-generic

   uname -a
  Linux bamlp4 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:36 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  == Comment: #6 - Vinutha GS  - 2016-12-14 03:16:18 ==
  Please find the attached sosreport.
  Also i have followed the steps for k-dump, It is enabled now.
  I'm going to start the tests once again.

  == Comment: #12 - Kevin W. Rudd - 2016-12-14 16:06:46 ==
  The basic reason for the panic is that close was called on a file 
  that was no longer valid.  The f_count value was -8 for some reason,
  so it passed the following check in filep_close():

  if (!file_count(filp)) {
  printk(KERN_ERR "VFS: Close: file count is 0\n");
  return 0;
  }

  It then blew up in au_do_flush() because f_inode was NULL.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1650062/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1656908] Re: In Ubuntu 17.04 : after reboot getting message in console like Unable to open file: /etc/keys/x509_ima.der (-2)

[Manoj Iyer]

I would assume that the keys are generated by the emvctl package. This
would require evmctl tools packaged in Ubuntu. Could you please confirm
that this package might be a likely candidate that we might want to
carry in Ubuntu? https://sourceforge.net/p/linux-ima/ima-evm-
utils/ci/v0.9/tree/

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Steve Langasek (vorlon)

** Changed in: linux (Ubuntu)
   Importance: High => Wishlist

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1656908

Title:
  In Ubuntu 17.04 : after reboot getting message in console like Unable
  to open file: /etc/keys/x509_ima.der (-2)

Status in linux package in Ubuntu:
  New

Bug description:
  Installed Ubuntu17.04 as PowerVM/KVM or NV , after installation every
  reboot getting message in console

  Unable to open file: /etc/keys/x509_ima.der (-2)

  
  LOG:

  Booting Linux via __start() @ 0x0a6c ...
   -> smp_release_cpus()
  spinning_secondaries = 7
   <- smp_release_cpus()
  [0.663066] Unable to open file: /etc/keys/x509_ima.der (-2)[0.663129] 
Unable to open file: /etc/keys/x509_evm.der (-2)
  [0.792300] sd 0:0:1:0: [sda] Assuming drive cache: write through

  Ubuntu Zesty Zapus (development branch) ubuntu  hvc0

  ubuntu  login:

  Maybe this was introduced by
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1643652 ? Will
  mirror this over to Launchpad for Canonical to review...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656908/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1655241] Re: Ubuntu 17.04: "Oops: Exception in kernel mode, sig: 5 [#1]" seen during fadump over ssh on Alpine machine.

[Manoj Iyer]

Leann, could you please get someone to pull in commit referenced in this
bug to fix the oops ?

** Changed in: makedumpfile (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Leann Ogasawara 
(leannogasawara)

** Changed in: makedumpfile (Ubuntu)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1655241

Title:
  Ubuntu 17.04: "Oops: Exception in kernel mode, sig: 5 [#1]" seen
  during fadump over ssh on Alpine machine.

Status in makedumpfile package in Ubuntu:
  New

Bug description:
  Problem Description
  
  "Oops: Exception in kernel mode, sig: 5 [#1]" seen during fadump over ssh on 
Alpine machine.

  Steps to Reproduce
  
  1. Configure fadump over ssh on Alpine machine.
  ssh-keygen -t rsa

  Add below lines in /etc/default/kdump-tools
  SSH="ubuntu@9.114.15.240"
  SSH_KEY=/root/.ssh/id_rsa

  # kdump-config propagate

  # kdump-config load

  # kdump-config show

  2. Trigger crash

  Logs
  ===
  ubuntu@alp9:~$ [   41.884641] usercopy: kernel memory exposure attempt 
detected from c000fb001020 (task_struct) (61408 bytes)
  [   41.884668] kernel BUG at /build/linux-okcqyo/linux-4.9.0/mm/usercopy.c:75!
  [   41.884672] Oops: Exception in kernel mode, sig: 5 [#1]
  [   41.884674] SMP NR_CPUS=2048 [   41.884676] NUMA 
  [   41.884677] pSeries
  [   41.884679] Modules linked in: pseries_rng vmx_crypto ib_iser rdma_cm 
iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi ip_tables x_tables autofs4 btrfs raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear ibmvscsi lpfc crc32c_vpmsum 
scsi_transport_fc
  [   41.884714] CPU: 8 PID: 3977 Comm: makedumpfile Not tainted 
4.9.0-11-generic #12-Ubuntu
  [   41.884717] task: c00151fcdc00 task.stack: c00150064000
  [   41.884719] NIP: c0312978 LR: c0312974 CTR: 
006338e4
  [   41.884722] REGS: c001500678d0 TRAP: 0700   Not tainted  
(4.9.0-11-generic)
  [   41.884725] MSR: 80029033 [   41.884732]   
CR: 2800  XER: 0004
  [   41.884734] CFAR: c0b26cac SOFTE: 1 
  GPR00: c0312974 c00150067b50 c141a400 0063 
  GPR04: c00179a0ade8 c00179a1fc40 00a1b6ef  
  GPR08: 0007 c0f7f87c 000178a9 3ff0 
  GPR12: 2200 ce794800 3fff7f4d0010 3fff7f4d0010 
  GPR16: bb01 54150c98 5412da08 0001 
  GPR20: 540fea40 38448150 0001 c1717798 
  GPR24: 0001 c00150067cf0  1020 
  GPR28: c000fb01 0001 efe0 c000fb001020 
  NIP [c0312978] __check_object_size+0x88/0x2c0
  [   41.884777] LR [c0312974] __check_object_size+0x84/0x2c0
  [   41.884780] Call Trace:
  [   41.884782] [c00150067b50] [c0312974] 
__check_object_size+0x84/0x2c0 (unreliable)
  [   41.884787] [c00150067bd0] [c006aea4] copy_to_user+0x64/0xa0
  [   41.884791] [c00150067c10] [c0042360] 
copy_oldmem_page+0x140/0x1d0
  [   41.884796] [c00150067c60] [c03cd5a8] 
read_from_oldmem.part.0+0x138/0x150
  [   41.884800] [c00150067cd0] [c03cd6fc] read_vmcore+0x13c/0x270
  [   41.884803] [c00150067d40] [c03b8918] proc_reg_read+0x88/0xd0
  [   41.884807] [c00150067d70] [c0318f4c] __vfs_read+0x3c/0x70
  [   41.884811] [c00150067d90] [c031a1ac] vfs_read+0xbc/0x1b0
  [   41.884814] [c00150067de0] [c031bdc8] SyS_read+0x68/0x110
  [   41.884818] [c00150067e30] [c000bd84] system_call+0x38/0xe0
  [   41.884820] Instruction dump:
  [   41.884823] 6000 6042 3c82ff93 3ca2ff9d 38847130 38a5b3f8 3c62ff94 
7fc8f378 
  [   41.884830] 7fe6fb78 38635f20 488142dd 6000 <0fe0> 6042 
2ba30010 409d017c 
  [   41.884838] ---[ end trace c33ccad89db3894a ]---
  [   41.884840] 
  Copying data   : [ 43.7 %] -889527+439 records in
  [   41.805683] kdump-tools[3621]: 889744+1 records out
  [   41.805920] kdump-tools[3621]: 455549276 bytes (456 MB, 434 MiB) copied, 
24.5065 s, 18.6 MB/s
  [   42.263162] kdump-tools[3621]:  * kdump-tools: saved vmcore in 
ubuntu@9.114.15.240:/home/ubuntu/9.114.15.239-201701090710
  [   42.264882] kdump-tools[3621]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /tmp/dmesg.201701090710
  [   42.268482] kdump-tools[3621]: The kernel version is not supported.
  [   42.268810] kdump-tools[3621]: The makedumpfile operation may be 
incomplete.
  [   42.269050] kdump-tools[3621]: The dmesg log is saved to 
/tmp/dmesg.201701090710.
  [   42.269236] kdump-tools[3621]: 

[Kernel-packages] [Bug 1655280] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04.2: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore

[Manoj Iyer]

Steve, could your team please take a look ?

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Steve Langasek (vorlon)

** Changed in: linux (Ubuntu)
   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/1655280

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04.2: cp: error reading '/proc/vmcore':
  Bad address when trying to dump vmcore

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Ping Tian Han  - 2017-01-09 02:51:00 ==
  ---Problem Description---
  Vmcore cannot be saved when triggering bug 150353 on roselp4:

  Copying data   : [  2.0 %] \/usr/sbin/kdump-config: line 
591:  5502 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [  512.833872] kdump-tools[5450]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [  573.595449] kdump-tools[5450]: cp: error reading '/proc/vmcore': Bad 
address
  [  573.605717] kdump-tools[5450]:  * kdump-tools: failed to save vmcore in 
/var/crash/201701090223
  [  573.765417] kdump-tools[5450]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201701090223/dmesg.201701090223
  [  574.285506] kdump-tools[5450]: The kernel version is not supported.
  [  574.285672] kdump-tools[5450]: The makedumpfile operation may be 
incomplete.
  [  574.285767] kdump-tools[5450]: The dmesg log is saved to 
/var/crash/201701090223/dmesg.201701090223.
  [  574.305422] kdump-tools[5450]: makedumpfile Completed.
  [  574.315363] kdump-tools[5450]:  * kdump-tools: saved dmesg content in 
/var/crash/201701090223
  [  574.615688] kdump-tools[5450]: Mon, 09 Jan 2017 02:24:26 -0600
  [  574.705384] kdump-tools[5450]: Rebooting.
   Stopping ifup for ib0...
  [  OK  ] Stopped ifup for ib0.
  [ 1008.579897] reboot: Restarting system
   
  Contact Information = Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com 
   
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. config kdump on roselp4
  2. try to trigger bug 150353

   
  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

  == Comment: #3 - Brahadambal Srinivasan  -
  2017-01-10 02:42:25 ==

  root@roselp4:~# cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinux-4.8.0-34-generic 
root=UUID=0bcf3431-df8b-499c-9a13-33070f242e0c ro splash quiet 
crashkernel=384M-:512M

  root@roselp4:~# dmesg | grep Reser
  [0.00] Reserving 512MB of memory at 128MB for crashkernel (System 
RAM: 21760MB)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655280/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1649513] Re: [Ubuntu 16.10] NMI watchdog and soft lockup while running htx memory tests in kernel 4.8.0-17-generic

[Manoj Iyer]

IBM needs to identify a patch that fixes this issue. We do not have a
good mechanism to reproduce the bug.

** Changed in: linux (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1649513

Title:
  [Ubuntu 16.10] NMI watchdog and soft lockup while running htx memory
  tests in kernel 4.8.0-17-generic

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Issue:
  --
  NMI Watchdog Bug and soft lockup occurs when htx memory test is run in ubuntu 
16.10.

  Environment:
  --
  Arch : ppc64le
  Platform : Ubuntu KVM Guest
  Host : ubuntu 16.10 [4.8.0-17 -kernel ]
  Guest : ubuntu 16.10 [4.8.0-17 - Kernel]

  Steps To Reproduce:
  ---

  1 - Install a Ubuntu KVM Guest and install htx package in the guest got from 
the link,
  http://ausgsa.ibm.com/projects/h/htx/public_html/htxonly/htxubuntu-413.deb 

  2 - Run the Htx mdt.mem

  3 - The system Hits soft lockup Issue as below:

  dmesg o/p:
  [60287.590335] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 1141s! 
[hxemem64:23468]
  [60287.590572] Modules linked in: vmx_crypto ip_tables x_tables autofs4 
ibmvscsi crc32c_vpmsum
  [60287.590585] CPU: 3 PID: 23468 Comm: hxemem64 Tainted: G L  
4.8.0-17-generic #19-Ubuntu
  [60287.590587] task: c012a0971e00 task.stack: c012a2d4
  [60287.590589] NIP: c0015004 LR: c0015004 CTR: 
c0165e90
  [60287.590591] REGS: c012a2d439a0 TRAP: 0901   Tainted: G L   
(4.8.0-17-generic)
  [60287.590592] MSR: 80009033   CR: 48004244  
XER: 
  [60287.590603] CFAR: c0165890 SOFTE: 1 
 GPR00: c0165f9c c012a2d43c20 c14e5e00 
0900 
 GPR04:  0008 000100e4d61a 
 
 GPR08:  0006 000100e4d619 
c012bfee3130 
 GPR12: 3fffae6cdc70 3fffae436900 
  [60287.590627] NIP [c0015004] arch_local_irq_restore+0x74/0x90
  [60287.590630] LR [c0015004] arch_local_irq_restore+0x74/0x90
  [60287.590631] Call Trace:
  [60287.590634] [c012a2d43c20] [c012bfeccd80] 0xc012bfeccd80 
(unreliable)
  [60287.590639] [c012a2d43c40] [c0165f9c] 
run_timer_softirq+0x10c/0x230
  [60287.590644] [c012a2d43ce0] [c0b94adc] __do_softirq+0x18c/0x3fc
  [60287.590648] [c012a2d43de0] [c00d5828] irq_exit+0xc8/0x100
  [60287.590653] [c012a2d43e00] [c0024810] timer_interrupt+0xa0/0xe0
  [60287.590657] [c012a2d43e30] [c0002814] 
decrementer_common+0x114/0x180
  [60287.590659] Instruction dump:
  [60287.590662] 994d023a 2fa3 409e0024 e92d0020 61298000 7d210164 38210020 
e8010010 
  [60287.590670] 7c0803a6 4e800020 6042 4bfed259 <6000> 4be4 
6042 e92d0020 
  [63127.581494] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 339s! 
[hxemem64:23467]
  [63127.629682] Modules linked in: vmx_crypto ip_tables x_tables autofs4 
ibmvscsi crc32c_vpmsum
  [63127.629699] CPU: 2 PID: 23467 Comm: hxemem64 Tainted: G L  
4.8.0-17-generic #19-Ubuntu
  [63127.629701] task: c012a0965800 task.stack: c012a2d58000
  [63127.629703] NIP: 10011e60 LR: 1000ec6c CTR: 
00f33196
  [63127.629706] REGS: c012a2d5bea0 TRAP: 0901   Tainted: G L   
(4.8.0-17-generic)
  [63127.629707] MSR: 8001d033   CR: 
42004482  XER: 
  [63127.629719] CFAR: 10011e68 SOFTE: 1 
 GPR00: 1000e854 3fffadc2e540 10047f00 
000d 
 GPR04: 0200 3ff5a800 5a5a5a5a5a5a5a5a 
3ff5b0667348 
 GPR08:  1006c8e0 1006ca04 
f001 
 GPR12: 3fffae6cdc70 3fffadc36900 
  [63127.629740] NIP [10011e60] 0x10011e60
  [63127.629742] LR [1000ec6c] 0x1000ec6c
  [63127.629743] Call Trace:

  == Comment: #3 - Santhosh G  - 2016-09-28 02:17:29 ==
  Memory Info :

  root@ubuntu:~# cat /proc/meminfo 
  MemTotal:   78539776 kB
  MemFree:72219392 kB
  MemAvailable:   77217088 kB
  Buffers:  212544 kB
  Cached:  5249088 kB
  SwapCached:0 kB
  Active:  1440832 kB
  Inactive:4107264 kB
  Active(anon):  93888 kB
  Inactive(anon): 8640 kB
  Active(file):1346944 kB
  Inactive(file):  4098624 kB
  Unevictable:   0 kB
  Mlocked:   0 kB
  SwapTotal:   3443648 kB
  SwapFree:3443648 kB
  Dirty: 0 kB
  Writeback: 0 kB
  AnonPages: 87296 kB
  Mapped:30400 kB
  Shmem: 16128 kB
  Slab: 

[Kernel-packages] [Bug 1644716] Re: cpufreq-set --freq option is not able to set the specific frequency value

[Manoj Iyer]

This package is supported by the community, it would require a community
effort to resolve this issue.

** Also affects: cpufrequtils (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

** No longer affects: linux (Ubuntu)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1644716

Title:
  cpufreq-set --freq option is not able to set the specific frequency
  value

Status in cpufrequtils package in Ubuntu:
  New

Bug description:
  == Comment: #0 - PAVAMAN SUBRAMANIYAM  - 2016-11-23 
03:27:34 ==
  ---Problem Description---
  cpufreq-set --freq option is not able to set the specific frequency value
   
  Contact Information = pavsu...@in.ibm.com 
   
  ---uname output---
  Linux ltc-garri2 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:01:16 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = P8 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  Install a P8 Open Power Hardware with Ubuntu 16.10 OS.
  Then we are executing cpufreq-set which is a small tool which allows to 
modify cpufreq settings.

  
  root@ltc-garri2:~# cpufreq-info -c 0
  cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
  Report errors and bugs to cpuf...@vger.kernel.org, please.
  analyzing CPU 0:
driver: powernv-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 0 1 2 3 4 
5 6 7
maximum transition latency: 4294.55 ms.
hardware limits: 2.06 GHz - 4.02 GHz
available frequency steps: 4.02 GHz, 3.99 GHz, 3.96 GHz, 3.92 GHz, 3.89 
GHz, 3.86 GHz, 3.82 GHz, 3.79 GHz, 3.76 GHz, 3.72 GHz, 3.69 GHz, 3.66 GHz, 3.62 
GHz, 3.59 GHz, 3.56 GHz, 3.52 GHz, 3.49 GHz, 3.46 GHz, 3.42 GHz, 3.39 GHz, 3.36 
GHz, 3.33 GHz, 3.29 GHz, 3.26 GHz, 3.23 GHz, 3.19 GHz, 3.16 GHz, 3.13 GHz, 3.09 
GHz, 3.06 GHz, 3.03 GHz, 2.99 GHz, 2.96 GHz, 2.93 GHz, 2.89 GHz, 2.86 GHz, 2.83 
GHz, 2.79 GHz, 2.76 GHz, 2.73 GHz, 2.69 GHz, 2.66 GHz, 2.63 GHz, 2.59 GHz, 2.56 
GHz, 2.53 GHz, 2.49 GHz, 2.46 GHz, 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz, 2.29 
GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz, 2.09 GHz, 2.06 GHz
available cpufreq governors: conservative, ondemand, userspace, powersave, 
performance
current policy: frequency should be within 4.02 GHz and 4.02 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 4.02 GHz (asserted by call to hardware).
cpufreq stats: 4.02 GHz:100.00%, 3.99 GHz:0.00%, 3.96 GHz:0.00%, 3.92 
GHz:0.00%, 3.89 GHz:0.00%, 3.86 GHz:0.00%, 3.82 GHz:0.00%, 3.79 GHz:0.00%, 3.76 
GHz:0.00%, 3.72 GHz:0.00%, 3.69 GHz:0.00%, 3.66 GHz:0.00%, 3.62 GHz:0.00%, 3.59 
GHz:0.00%, 3.56 GHz:0.00%, 3.52 GHz:0.00%, 3.49 GHz:0.00%, 3.46 GHz:0.00%, 3.42 
GHz:0.00%, 3.39 GHz:0.00%, 3.36 GHz:0.00%, 3.33 GHz:0.00%, 3.29 GHz:0.00%, 3.26 
GHz:0.00%, 3.23 GHz:0.00%, 3.19 GHz:0.00%, 3.16 GHz:0.00%, 3.13 GHz:0.00%, 3.09 
GHz:0.00%, 3.06 GHz:0.00%, 3.03 GHz:0.00%, 2.99 GHz:0.00%, 2.96 GHz:0.00%, 2.93 
GHz:0.00%, 2.89 GHz:0.00%, 2.86 GHz:0.00%, 2.83 GHz:0.00%, 2.79 GHz:0.00%, 2.76 
GHz:0.00%, 2.73 GHz:0.00%, 2.69 GHz:0.00%, 2.66 GHz:0.00%, 2.63 GHz:0.00%, 2.59 
GHz:0.00%, 2.56 GHz:0.00%, 2.53 GHz:0.00%, 2.49 GHz:0.00%, 2.46 GHz:0.00%, 2.43 
GHz:0.00%, 2.39 GHz:0.00%, 2.36 GHz:0.00%, 2.33 GHz:0.00%, 2.29 GHz:0.00%, 2.26 
GHz:0.00%, 2.23 GHz:0.00%, 2.19 GHz:0.00%, 2.16 GHz:0.00%, 2.13 GHz:0.00%, 2.09 
GHz:0.00%, 2.06 GHz:0.00%  (12)

  Then try to  set the specific frequency to be set for cpu0.

  root@ltc-garri2:~# cpufreq-set -c 0 --freq 3.92GHz
  root@ltc-garri2:~# echo $?
  0

  root@ltc-garri2:~# cat 
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_nominal_freq
  3258000
  root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
  2061000
  root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
  4023000
  root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
  4023000

  As can be seen the new frequency value is not getting set.
  The /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq value still shows 
4023000 or 4.02GHz but we tried to set 3.92GHz.
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  Userspace tool common name: /usr/bin/cpufreq-set 

  Userspace rpm: cpufrequtils 
   
  The userspace tool has the following bit modes: 64-bit 
   
  System Dump Info:
The system is not configured to capture a system dump.

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for pavsu...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of 

[Kernel-packages] [Bug 1635063] Re: Ubuntu 16.10: System hangs after crash on Ubuntu KVM guest.

[Manoj Iyer]

Looks like the kernel option needs to be added when you setup kdump, and
you have already updated the wiki pages to document this. I am marking
this as fix released because there is nothing more to do from
canonical's side.

** Changed in: linux (Ubuntu)
   Status: New => 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/1635063

Title:
  Ubuntu 16.10: System hangs after crash on Ubuntu KVM guest.

Status in linux package in Ubuntu:
  Fix Released

Bug description:
  ---Problem Description---

  Ubuntu 16.10: System hangs after crash on Ubuntu KVM guest.

  ---Steps to Reproduce---

  1) apt-get install linux-crashdump
  2) increase crashdump size:
  sudo vim /etc/default/grub.d/kexec-tools.cfg

  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel
  =2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M"

  3) sudo update-grub ; reboot the machine
  4) sudo sed -i 's/USE_KDUMP=0/USE_KDUMP=1/g' /etc/default/kdump-tools
  5) kdump-config show
  6) echo "c" > /proc/sysrq-trigger

  Logs
  
  root@ubuntu:/var/crash# uname -a
  Linux ubuntu 4.8.0-17-generic #19-Ubuntu SMP Sun Sep 25 06:35:40 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux
  root@ubuntu:/var/crash# kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.8.0-17-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.8.0-17-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinux-4.8.0-17-generic 
root=UUID=70f3c690-fe90-444d-a74c-71c05eef8b0e ro splash quiet irqpoll 
nr_cpus=1 nousb systemd.unit=kdump-tools.service" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  root@ubuntu:/var/crash# echo c > /proc/sysrq-trigger
  [  202.677946] sysrq: SysRq : Trigger a crash
  [  202.678018] Unable to handle kernel paging request for data at address 
0x
  [  202.678098] Faulting instruction address: 0xc06de134
  [  202.678169] Oops: Kernel access of bad area, sig: 11 [#1]
  [  202.678222] SMP NR_CPUS=2048 NUMA pSeries
  [  202.678281] Modules linked in: vmx_crypto ip_tables x_tables autofs4 
ibmvscsi crc32c_vpmsum 8139too 8139cp mii
  [  202.678465] CPU: 3 PID: 1992 Comm: bash Not tainted 4.8.0-17-generic 
#19-Ubuntu
  [  202.678547] task: c4c5ce00 task.stack: c428c000
  [  202.678612] NIP: c06de134 LR: c06df218 CTR: 
c06de100
  [  202.678716] REGS: c428f990 TRAP: 0300   Not tainted  
(4.8.0-17-generic)
  [  202.678796] MSR: 80009033   CR: 2824  
XER: 2000
  [  202.678992] CFAR: c0014f84 DAR:  DSISR: 4200 
SOFTE: 1 
  GPR00: c06df218 c428fc10 c14e5e00 0063 
  GPR04: c0007fecaca0 c0007fedfb40 c168d278 4b78 
  GPR08: 0007 0001  0001 
  GPR12: c06de100 c7b81b00  2200 
  GPR16: 10170dc8 010020c60488 10140f58 100c7570 
  GPR20:  1017dd58 10153618 1017b608 
  GPR24: 3fffd5f377c4 0001 c13fe5d0 0004 
  GPR28: c13fe990 0063 c13b2590  
  [  202.680090] NIP [c06de134] sysrq_handle_crash+0x34/0x50
  [  202.680159] LR [c06df218] __handle_sysrq+0xe8/0x280
  [  202.680213] Call Trace:
  [  202.680246] [c428fc10] [c0e79720] 
_fw_tigon_tg3_bin_name+0x2f1a8/0x36f48 (unreliable)
  [  202.680356] [c428fc30] [c06df218] __handle_sysrq+0xe8/0x280
  [  202.680440] [c428fcd0] [c06df9c8] 
write_sysrq_trigger+0x78/0xa0
  [  202.680535] [c428fd00] [c03cf890] proc_reg_write+0xb0/0x110
  [  202.680618] [c428fd50] [c032b5dc] __vfs_write+0x6c/0xe0
  [  202.680702] [c428fd90] [c032cae4] vfs_write+0xd4/0x240
  [  202.680783] [c428fde0] [c032e7fc] SyS_write+0x6c/0x110
  [  202.680867] [c428fe30] [c0009584] system_call+0x38/0xec
  [  202.680948] Instruction dump:
  [  202.680991] 38427d00 7c0802a6 f8010010 f821ffe1 6000 6000 3d22001a 
3949d1e0 
  [  202.681133] 3921 912a 7c0004ac 3940 <992a> 38210020 
e8010010 7c0803a6 
  [  202.681276] ---[ end trace 3e9cbc319000fff4 ]---
  [  202.684658] 
  [  202.684718] Sending IPI to other CPUs
  [  202.686765] IPI complete
  I'm in purgatory
   -> smp_release_cpus()
  spinning_secondaries = 3
   <- smp_release_cpus()
  Linux ppc64le
  #19-Ubuntu SMP S[  242.661649] INFO: task swapper/0:1 blocked for more than 
120 seconds.
  [ 

[Kernel-packages] [Bug 1652595] Re: Ubuntu 16.04.02: crash tool fails with error "cannot find 'cpu_possible_map', 'cpu_present_map', 'cpu_online_map' or 'cpu_active_map' symbols".

[Manoj Iyer]

The patch attached to comment #2 does not appear to be a fix for the
issue reported in this bug. Could you pls point me to an upstream fix
you might have identified that addresses this issue? I can make a best
effort in merging that patch in Ubuntu.

** Package changed: basemap (Ubuntu) => crash (Ubuntu)

** Also affects: makedumpfile (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: crash (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Manoj Iyer (manjo)

** Changed in: makedumpfile (Ubuntu)
 Assignee: (unassigned) => Manoj Iyer (manjo)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to crash in Ubuntu.
https://bugs.launchpad.net/bugs/1652595

Title:
  Ubuntu 16.04.02: crash tool fails with error "cannot find
  'cpu_possible_map', 'cpu_present_map', 'cpu_online_map' or
  'cpu_active_map' symbols".

Status in crash package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  New

Bug description:
  ---Problem Description---

  Ubuntu 16.04.02: crash tool fails with error "cannot find
  'cpu_possible_map', 'cpu_present_map', 'cpu_online_map' or
  'cpu_active_map' symbols".

  ---Steps to Reproduce---

  1. Install 16.04.02 [ 4.8.0-32-generic ].
  2. Configure kdump.
  3. Install debug package. 
  4. trigger crash.
  5. run crash tool on dump captured.

  sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
  deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe 
multiverse
  deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-security main restricted 
universe multiverse
  deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates main restricted 
universe multiverse
  deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted 
universe multiverse
  EOF 

  sudo apt-get update
  sudo apt-get install linux-image-$(uname -r)-dbgsym  


  
  path: /var/crash/201612190432

  Logs
  ===

  root@ltc-haba2:/var/crash/201612190432# crash
  /usr/lib/debug/boot/vmlinux-4.8.0-32-generic dump.201612190432

  crash 7.1.4
  Copyright (C) 2002-2015  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

  
  crash: PPC64: cannot find 'cpu_possible_map', 'cpu_present_map', 
'cpu_online_map' or 'cpu_active_map' symbols

  
  It appears problem is with System.map-4.8.0-32-generic file 

  (gdb) symbol-file System.map-4.8.0-32-generic -readshow
  `/boot/System.map-4.8.0-32-generic': can't read symbols: File format not 
recognized.
  (gdb) 

  crash System.map-4.8.0-32-generic
  /usr/lib/debug/boot/vmlinux-4.8.0-32-generic
  /var/crash/201612260004/dump.201612260004

  crash 7.1.4
  Copyright (C) 2002-2015  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

  

[Kernel-packages] [Bug 1628111] [NEW] [Yakkety] enable EDAC_GHES in kernel config

[Manoj Iyer]

Public bug reported:

EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
firmware-first error handling of memory and CPU errors. Due to a lack of
standard RAS architecture (or machine check architecture equivalent) on
ARMv8.0 systems, APEI/GHES is the only mechanism available for reporting
hardware errors (e.g. memory and CPU errors). This enables reporting of
hardware errors, and also helps enable memory fault recovery mechanisms
to extend the life of the system by offlining pages when recoverable
uncorrected errors are encountered. Note that other ARM vendors will be
going in this direction for hardware error handling.

Currently EDAC_MM_EDAC=m is in Ubuntu, but EDAC_GHES requires this to be
=y therefore it is not selected.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Manoj Iyer (manjo)
 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/1628111

Title:
  [Yakkety] enable EDAC_GHES in kernel config

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack
  of standard RAS architecture (or machine check architecture
  equivalent) on ARMv8.0 systems, APEI/GHES is the only mechanism
  available for reporting hardware errors (e.g. memory and CPU errors).
  This enables reporting of hardware errors, and also helps enable
  memory fault recovery mechanisms to extend the life of the system by
  offlining pages when recoverable uncorrected errors are encountered.
  Note that other ARM vendors will be going in this direction for
  hardware error handling.

  Currently EDAC_MM_EDAC=m is in Ubuntu, but EDAC_GHES requires this to
  be =y therefore it is not selected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628111] Re: [Yakkety] enable EDAC_GHES in kernel config

[Manoj Iyer]

** Description changed:

  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack of
  standard RAS architecture (or machine check architecture equivalent) on
  ARMv8.0 systems, APEI/GHES is the only mechanism available for reporting
  hardware errors (e.g. memory and CPU errors). This enables reporting of
  hardware errors, and also helps enable memory fault recovery mechanisms
  to extend the life of the system by offlining pages when recoverable
  uncorrected errors are encountered. Note that other ARM vendors will be
  going in this direction for hardware error handling.
  
- Currently ACPI_APEI_GHES=n is in Ubuntu, but EDAC_GHES requires this to
- be =y therefore it is not selected.
+ Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
+ ARM64, but EDAC_GHES requires this to be =y therefore it is not
+ selected.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628111

Title:
  [Yakkety] enable EDAC_GHES in kernel config

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Yakkety:
  Incomplete

Bug description:
  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack
  of standard RAS architecture (or machine check architecture
  equivalent) on ARMv8.0 systems, APEI/GHES is the only mechanism
  available for reporting hardware errors (e.g. memory and CPU errors).
  This enables reporting of hardware errors, and also helps enable
  memory fault recovery mechanisms to extend the life of the system by
  offlining pages when recoverable uncorrected errors are encountered.
  Note that other ARM vendors will be going in this direction for
  hardware error handling.

  Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
  ARM64, but EDAC_GHES requires this to be =y therefore it is not
  selected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628111] Re: [Yakkety] enable EDAC_GHES in kernel config

[Manoj Iyer]

** Description changed:

  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack of
  standard RAS architecture (or machine check architecture equivalent) on
  ARMv8.0 systems, APEI/GHES is the only mechanism available for reporting
  hardware errors (e.g. memory and CPU errors). This enables reporting of
  hardware errors, and also helps enable memory fault recovery mechanisms
  to extend the life of the system by offlining pages when recoverable
  uncorrected errors are encountered. Note that other ARM vendors will be
  going in this direction for hardware error handling.
  
  Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
  ARM64, but EDAC_GHES requires this to be =y therefore it is not
  selected.
+ 
+ == SRU Request ==
+ 
+ [Impact]
+ * As a result of ACPI_APEI_GHES=n and CONFIG_EDAC_MM_EDAC=m for ARM64, 
EDAC_GHES is not selected on kernel build. This results in loss of 
functionality needed for firmware error handling of memory and CPU errors.
+ 
+ [Test Case]
+ NA
+ 
+ [Regression Potential]
+ * None.

** Description changed:

  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack of
  standard RAS architecture (or machine check architecture equivalent) on
  ARMv8.0 systems, APEI/GHES is the only mechanism available for reporting
  hardware errors (e.g. memory and CPU errors). This enables reporting of
  hardware errors, and also helps enable memory fault recovery mechanisms
  to extend the life of the system by offlining pages when recoverable
  uncorrected errors are encountered. Note that other ARM vendors will be
  going in this direction for hardware error handling.
  
  Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
  ARM64, but EDAC_GHES requires this to be =y therefore it is not
  selected.
  
  == SRU Request ==
  
  [Impact]
  * As a result of ACPI_APEI_GHES=n and CONFIG_EDAC_MM_EDAC=m for ARM64, 
EDAC_GHES is not selected on kernel build. This results in loss of 
functionality needed for firmware error handling of memory and CPU errors.
  
  [Test Case]
- NA
+ * NA
  
  [Regression Potential]
  * None.

** Changed in: linux (Ubuntu)
   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/1628111

Title:
  [Yakkety] enable EDAC_GHES in kernel config

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Yakkety:
  Incomplete

Bug description:
  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack
  of standard RAS architecture (or machine check architecture
  equivalent) on ARMv8.0 systems, APEI/GHES is the only mechanism
  available for reporting hardware errors (e.g. memory and CPU errors).
  This enables reporting of hardware errors, and also helps enable
  memory fault recovery mechanisms to extend the life of the system by
  offlining pages when recoverable uncorrected errors are encountered.
  Note that other ARM vendors will be going in this direction for
  hardware error handling.

  Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
  ARM64, but EDAC_GHES requires this to be =y therefore it is not
  selected.

  == SRU Request ==

  [Impact]
  * As a result of ACPI_APEI_GHES=n and CONFIG_EDAC_MM_EDAC=m for ARM64, 
EDAC_GHES is not selected on kernel build. This results in loss of 
functionality needed for firmware error handling of memory and CPU errors.

  [Test Case]
  * NA

  [Regression Potential]
  * None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628111] Re: [Yakkety] enable EDAC_GHES in kernel config

[Manoj Iyer]

** Description changed:

  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack of
  standard RAS architecture (or machine check architecture equivalent) on
  ARMv8.0 systems, APEI/GHES is the only mechanism available for reporting
  hardware errors (e.g. memory and CPU errors). This enables reporting of
  hardware errors, and also helps enable memory fault recovery mechanisms
  to extend the life of the system by offlining pages when recoverable
  uncorrected errors are encountered. Note that other ARM vendors will be
  going in this direction for hardware error handling.
  
- Currently EDAC_MM_EDAC=m is in Ubuntu, but EDAC_GHES requires this to be
- =y therefore it is not selected.
+ Currently ACPI_APEI_GHES=n is in Ubuntu, but EDAC_GHES requires this to
+ be =y therefore it is not selected.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628111

Title:
  [Yakkety] enable EDAC_GHES in kernel config

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack
  of standard RAS architecture (or machine check architecture
  equivalent) on ARMv8.0 systems, APEI/GHES is the only mechanism
  available for reporting hardware errors (e.g. memory and CPU errors).
  This enables reporting of hardware errors, and also helps enable
  memory fault recovery mechanisms to extend the life of the system by
  offlining pages when recoverable uncorrected errors are encountered.
  Note that other ARM vendors will be going in this direction for
  hardware error handling.

  Currently ACPI_APEI_GHES=n is in Ubuntu, but EDAC_GHES requires this
  to be =y therefore it is not selected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628111] Re: [Yakkety] enable EDAC_GHES in kernel config

[Manoj Iyer]

Config change wont be sufficient at this time, We will also need
supporting patch: https://lkml.org/lkml/2016/8/10/231

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628111

Title:
  [Yakkety] enable EDAC_GHES in kernel config

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Yakkety:
  Incomplete

Bug description:
  EDAC_GHES is essential for ARMv8.0 Server systems, as it enables
  firmware-first error handling of memory and CPU errors. Due to a lack
  of standard RAS architecture (or machine check architecture
  equivalent) on ARMv8.0 systems, APEI/GHES is the only mechanism
  available for reporting hardware errors (e.g. memory and CPU errors).
  This enables reporting of hardware errors, and also helps enable
  memory fault recovery mechanisms to extend the life of the system by
  offlining pages when recoverable uncorrected errors are encountered.
  Note that other ARM vendors will be going in this direction for
  hardware error handling.

  Currently ACPI_APEI_GHES=n is in Ubuntu and CONFIG_EDAC_MM_EDAC=m for
  ARM64, but EDAC_GHES requires this to be =y therefore it is not
  selected.

  == SRU Request ==

  [Impact]
  * As a result of ACPI_APEI_GHES=n and CONFIG_EDAC_MM_EDAC=m for ARM64, 
EDAC_GHES is not selected on kernel build. This results in loss of 
functionality needed for firmware error handling of memory and CPU errors.

  [Test Case]
  * NA

  [Regression Potential]
  * None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1675046] [NEW] [ARM64] Support systems where the physical memory footprint exceeds the size of the linear mapping.

[Manoj Iyer]

Public bug reported:

[Impact]
Kernel might fail booting on systems where the physical memory footprint 
exceeds the size of the linear mapping. The following patches addresses this 
issue:

[v2,1/2] efi: arm-stub: Correct FDT and initrd allocation rules for arm64
https://patchwork.kernel.org/patch/9565537/

[v2,2/2] efi: arm-stub: Round up FDT allocation to mapping size
https://patchwork.kernel.org/patch/9565539

[Testing]
These patches were regression tested. Patches were applied to Zesty latest and 
boots on a KVM instance and on QDF2400 ARM64 Qualcomm server. At this time do 
not have systems with high memory to test with.

[Regression Potential]
Changes are confined to ARM architecture, patches apply cleanly to 
Ubuntu-4.10.0-13.15. Potential for any regression is low.

** Affects: linux (Ubuntu)
 Importance: Critical
 Assignee: Manoj Iyer (manjo)
 Status: New

** Changed in: linux (Ubuntu)
   Importance: Undecided => Critical

** Description changed:

  [Impact]
- Kernel might fail booting on systems where the physical memory footprint 
exceeds the
- size of the linear mapping. The following patches addresses this issue:
+ Kernel might fail booting on systems where the physical memory footprint 
exceeds the size of the linear mapping. The following patches addresses this 
issue:
  
  [v2,1/2] efi: arm-stub: Correct FDT and initrd allocation rules for arm64
  https://patchwork.kernel.org/patch/9565537/
  
- 
  [v2,2/2] efi: arm-stub: Round up FDT allocation to mapping size
  https://patchwork.kernel.org/patch/9565539
  
- 
  [Testing]
- These patches were regression tested. Patches were applied to Zesty latest 
and boots on a KVM instance and on QDF2400 ARM64 Qualcomm server. At this time 
do not have systems with high memory to test with. 
+ These patches were regression tested. Patches were applied to Zesty latest 
and boots on a KVM instance and on QDF2400 ARM64 Qualcomm server. At this time 
do not have systems with high memory to test with.
  
  [Regression Potential]
  Changes are confined to ARM architecture, patches apply cleanly to 
Ubuntu-4.10.0-13.15. Potential for any regression is low.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1675046

Title:
  [ARM64] Support systems where the physical memory footprint exceeds
  the size of the linear mapping.

Status in linux package in Ubuntu:
  New

Bug description:
  [Impact]
  Kernel might fail booting on systems where the physical memory footprint 
exceeds the size of the linear mapping. The following patches addresses this 
issue:

  [v2,1/2] efi: arm-stub: Correct FDT and initrd allocation rules for arm64
  https://patchwork.kernel.org/patch/9565537/

  [v2,2/2] efi: arm-stub: Round up FDT allocation to mapping size
  https://patchwork.kernel.org/patch/9565539

  [Testing]
  These patches were regression tested. Patches were applied to Zesty latest 
and boots on a KVM instance and on QDF2400 ARM64 Qualcomm server. At this time 
do not have systems with high memory to test with.

  [Regression Potential]
  Changes are confined to ARM architecture, patches apply cleanly to 
Ubuntu-4.10.0-13.15. Potential for any regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675046/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

test login: [  146.606156] cloud-init[1023]: Cloud-init v. 0.7.9 running 
'modules:config' at Tue, 21 Mar 2017 17:23:44 +. Up 143.57 seconds.
[  168.868544] cloud-init[1161]: Cloud-init v. 0.7.9 running 'modules:final' at 
Tue, 21 Mar 2017 17:24:06 +. Up 165.37 seconds.
[  168.914038] cloud-init[1161]: Cloud-init v. 0.7.9 finished at Tue, 21 Mar 
2017 17:24:10 +. Datasource DataSourceNoCloud [seed=/dev/vda][dsmode=net].  
Up 168.67 seconds
[  231.987676] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-10-generic (buildd@bos01-arm64-046) (gcc 
version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) 
#13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28 23:33:09 UTC 2017 (Ubuntu 
4.10.0-10.13~ubunturc2+build.1-generic 4.10.0)
[0.00] Boot CPU: AArch64 Processor [411fd070]

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in kexec-tools source package in Yakkety:
  Fix Committed
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] RE: Zesty use qcom_emac instead of msm_emac.

[Manoj Iyer]

> It's not unrelated. That is the actusl phy on the SDP.

and the same for REPs? our target cert platform?

> 
> From: Manoj Iyer [manoj.i...@canonical.com]
> Sent: Wednesday, March 29, 2017 10:11 PM
> To: Timur Tabi
> Cc: Manoj Iyer; Andrew Cloke; David Douglas; 1677...@bugs.launchpad.net
> Subject: Re: Zesty use qcom_emac instead of msm_emac.
>
> That is hard to SRU, we don't want to be adding unrelated modules to DI.
>
> With at803x loaded
> ==
> ubuntu@ubuntu:~$ uname -a
> Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28
> 23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
> ubuntu@ubuntu:~$
> ubuntu@ubuntu:~$ lsmod | grep at803x
> at803x
> ubuntu@ubuntu:~$ lsmod | grep qcom
> qcom_emac  40960  0
> ubuntu@ubuntu:~$
>
> eth0  Link encap:Ethernet  HWaddr 8c:fd:f0:06:90:cd
>   inet addr:10.228.66.102  Bcast:10.228.66.255  Mask:255.255.255.0
>
> So clearly as a side effect of loading at803x qcom_emac is able to get an
> IP address. But I am afraid this is not something we can justify as an
> SRU.
>
>
> On Wed, 29 Mar 2017, Timur Tabi wrote:
>
>> Assuming that you did back-port enough, then you should try loading
>> at803x.ko first.  Technically, there is an erratum with that PHY that the
>> driver resolves, although I've never seen it make a difference until today.
>>
>> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>>> Timur,
>>>
>>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261 yes
>>> this was backported from 4.11 to 4.10 and commited to zesty and to xenial.
>>>
>>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>>
>>>> Did you back-port driver from 4.11?
>>>>
>>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>>
>>>>> I have a public bug to track the qcom_emac replacement for msm_emac. This
>>>>> is currently blocked because qcom_emac that is in Zesty is unable to get
>>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>>> change. It is my understanding that once we sru the required patches we
>>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>>
>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>>
>>>>> --
>>>>> 
>>>>> Manoj Iyer
>>>>> Ubuntu/Canonical
>>>>> ARM Servers - Cloud
>>>>> 
>>>>
>>>>
>>>
>>> --
>>> 
>>> Manoj Iyer
>>> Ubuntu/Canonical
>>> ARM Servers - Cloud
>>> 
>>
>>
>
> --
> 
> Manoj Iyer
> Ubuntu/Canonical
> ARM Servers - Cloud
> 
>
>

--

Manoj Iyer
Ubuntu/Canonical
ARM Servers - Cloud


-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] rename msm_emac to qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1675046] Re: [ARM64] Support systems where the physical memory footprint exceeds the size of the linear mapping.

[Manoj Iyer]

These are in the next branch of the maintainer's tree -
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1675046

Title:
  [ARM64] Support systems where the physical memory footprint exceeds
  the size of the linear mapping.

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  Kernel might fail booting on systems where the physical memory footprint 
exceeds the size of the linear mapping. The following patches addresses this 
issue:

  [v2,1/2] efi: arm-stub: Correct FDT and initrd allocation rules for arm64
  https://patchwork.kernel.org/patch/9565537/

  [v2,2/2] efi: arm-stub: Round up FDT allocation to mapping size
  https://patchwork.kernel.org/patch/9565539

  [Testing]
  These patches were regression tested. Patches were applied to Zesty latest 
and boots on a KVM instance and on QDF2400 ARM64 Qualcomm server. At this time 
do not have systems with high memory to test with.

  [Regression Potential]
  Changes are confined to ARM architecture, patches apply cleanly to 
Ubuntu-4.10.0-13.15. Potential for any regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675046/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] [NEW] [Zesty] rename msm_emac to qcom_emac

[Manoj Iyer]

Public bug reported:

[Impact]
We landed a patch to support msm_emac module in initrd for amberwing platforms. 
But the upstream driver has since been renamed to qcom_emac. This module is 
needed in d-i's initrd so that these nics can be used to d-i install the 
system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add qcom_emac
to initrd, and change the module name to qcom_emac.

[Test Case]
D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

[Regression Potential]
At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

** Affects: linux (Ubuntu)
 Importance: Critical
 Assignee: Manoj Iyer (manjo)
 Status: New

** Description changed:

  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/
  
  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add qcom_emac
- to initrd.
+ to initrd, and change the module name to qcom_emac.
  
  [Test Case]
- D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic. 
+ D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.
  
  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] rename msm_emac to qcom_emac

Status in linux package in Ubuntu:
  New

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] rename msm_emac to qcom_emac

[Manoj Iyer]

qcom_emac driver that is in Zesty (4.10) kernel is able to bring up the
interface but fails to get a DHCP address. This bug is currently blocked
until upstream fixes the qcom_emac driver.

** Changed in: linux (Ubuntu)
 Assignee: Manoj Iyer (manjo) => Timur Tabi (timur-tabi)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] rename msm_emac to qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: Zesty use qcom_emac instead of msm_emac.

[Manoj Iyer]

That is hard to SRU, we don't want to be adding unrelated modules to DI.

With at803x loaded 
==
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28 
23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ lsmod | grep at803x
at803x
ubuntu@ubuntu:~$ lsmod | grep qcom
qcom_emac  40960  0
ubuntu@ubuntu:~$

eth0  Link encap:Ethernet  HWaddr 8c:fd:f0:06:90:cd
   inet addr:10.228.66.102  Bcast:10.228.66.255  Mask:255.255.255.0

So clearly as a side effect of loading at803x qcom_emac is able to get an 
IP address. But I am afraid this is not something we can justify as an 
SRU.


On Wed, 29 Mar 2017, Timur Tabi wrote:

> Assuming that you did back-port enough, then you should try loading
> at803x.ko first.  Technically, there is an erratum with that PHY that the
> driver resolves, although I've never seen it make a difference until today.
>
> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>> Timur,
>>
>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261 yes
>> this was backported from 4.11 to 4.10 and commited to zesty and to xenial.
>>
>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>
>>> Did you back-port driver from 4.11?
>>>
>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>
>>>> I have a public bug to track the qcom_emac replacement for msm_emac. This
>>>> is currently blocked because qcom_emac that is in Zesty is unable to get
>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>> change. It is my understanding that once we sru the required patches we
>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>
>>>> --
>>>> 
>>>> Manoj Iyer
>>>> Ubuntu/Canonical
>>>> ARM Servers - Cloud
>>>> 
>>>
>>>
>>
>> --
>> 
>> Manoj Iyer
>> Ubuntu/Canonical
>> ARM Servers - Cloud
>> 
>
>

--

Manoj Iyer
Ubuntu/Canonical
ARM Servers - Cloud


-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] rename msm_emac to qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1674466] [NEW] tty: acpi/spcr: QDF2400 E44 checks for wrong OEM revision

[Manoj Iyer]

Public bug reported:

[Impact]
For Qualcomm Technologies QDF2400 SOCs that are affected by erratum E44,
the ACPI oem_revision field is actually set to 1, not 0. This patch is 
necessary for proper functioning of console used for D-I installs and boot.

[Test Case]
Without this patch you might not be able to use Serial Over Lan. To test on a 
QDF2400 platform, use ipmi to connect over SOL and either reboot the system or 
initiate a DI install. SOL will fail to display any output. 

[Regression Potential]
This patch applies to TTY on QDF2400 platforms only. This patch does not impact 
any other vendor platforms. No potential for any regressions. 

[Other Info]
The patch was tested by me on a QDF2400 platform and found to work as expected. 
This patch is now available in linux-next and is in line to be merged into 4.11 
rc3.

** Affects: linux (Ubuntu)
 Importance: Critical
 Assignee: Manoj Iyer (manjo)
 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/1674466

Title:
  tty: acpi/spcr: QDF2400 E44 checks for wrong OEM revision

Status in linux package in Ubuntu:
  New

Bug description:
  [Impact]
  For Qualcomm Technologies QDF2400 SOCs that are affected by erratum E44,
  the ACPI oem_revision field is actually set to 1, not 0. This patch is 
necessary for proper functioning of console used for D-I installs and boot.

  [Test Case]
  Without this patch you might not be able to use Serial Over Lan. To test on a 
QDF2400 platform, use ipmi to connect over SOL and either reboot the system or 
initiate a DI install. SOL will fail to display any output. 

  [Regression Potential]
  This patch applies to TTY on QDF2400 platforms only. This patch does not 
impact any other vendor platforms. No potential for any regressions. 

  [Other Info]
  The patch was tested by me on a QDF2400 platform and found to work as 
expected. This patch is now available in linux-next and is in line to be merged 
into 4.11 rc3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674466/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

Timur,

I strongly suspect that the NMI watchdog softlockups caused by mlx5_core
dma mapping is the root cause of why qcom_emac driver is unable to get a
dhcp address. I blacklisted the mlx5_core driver and the soft lockups
went away. Nate suggested that we might need some additional iommu
related patches to address the soft lockup issue. I will build a kernel
with those and see if I have any success. So, looks like qcom_emac
driver is not at fault here.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1680549] Re: [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s!

[Manoj Iyer]

** Description changed:

  [IMPACT]
- On QDF2400 ARM64 servers, booting Zesty 4.10 kernel causes soft lockups on 
multiple CPUs. 
+ On QDF2400 ARM64 servers, booting Zesty 4.10 kernel causes soft lockups on 
multiple CPUs.
  
  [  104.205397] Modules linked in: nls_iso8859_1 cdc_acm bridge stp llc
  ipmi_ssif ipmi_devintf ipmi_msghandler shpchp hdma hdma_mgmt i2c_qup
  cppc_cpufreq ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp
  libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456
  async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
  libcrc32c raid1 raid0 multipath linear uas usb_storage at803x aes_ce_blk
  aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha1_ce mlx5_core
  devlink ptp pps_core ahci_platform libahci_platform libahci qcom_emac
  sdhci_acpi sdhci xhci_plat_hcd pinctrl_qdf2xxx fjes aes_neon_blk
  crypto_simd cryptd
  
  [  104.205442] CPU: 47 PID: 0 Comm: swapper/47 Tainted: G L  
4.10.0-16-generic #18ubuntuRC03+bandera.1
  [  104.205443] Hardware name: Qualcomm QDF2400 DP/ABW|SYS|CVR,1DPC|V3 
  , BIOS XBL.DF.2.0.R3-00153 QDF2400_REL CRM 02/ 8/2017
  [  104.205444] task: 9fa30ed49c00 task.stack: 9fa30ed5c000
  [  104.205447] PC is at _raw_spin_unlock_irqrestore+0x2c/0x38
  [  104.205450] LR is at alloc_iova+0x1cc/0x2a0
  [  104.205451] pc : [] lr : [] pstate: 
20400145
  [  104.205452] sp : 9fa31fbecc00
- [  104.205453] x29: 9fa31fbecc00 x28: 000efe46 
- [  104.205455] x27: 0040 x26: 000f 
- [  104.205458] x25: 3f06251f8000 x24: 0001 
- [  104.205460] x23: 9fa30da06008 x22:  
- [  104.205462] x21: 9fa2e2af8740 x20: 9fa30da06008 
- [  104.205464] x19: 0140 x18: a5e112c1 
- [  104.205466] x17: 4d48a1ed x16: b0f9c455 
- [  104.205468] x15: aa4269e9 x14: 85094ac4 
- [  104.205471] x13: 9b3b00da x12: 8aae8d9c 
- [  104.205473] x11: 9fa31fbf90b0 x10: 3f0624eb70eb 
- [  104.205475] x9 :  x8 : 0004 
- [  104.205477] x7 : 9fa2e2875400 x6 :  
- [  104.205479] x5 : 9fa2e2875401 x4 :  
- [  104.205481] x3 : 9fa2e2a27b00 x2 : 9fa2e2875400 
- [  104.205483] x1 : 0140 x0 : f7c2 
+ [  104.205453] x29: 9fa31fbecc00 x28: 000efe46
+ [  104.205455] x27: 0040 x26: 000f
+ [  104.205458] x25: 3f06251f8000 x24: 0001
+ [  104.205460] x23: 9fa30da06008 x22: 
+ [  104.205462] x21: 9fa2e2af8740 x20: 9fa30da06008
+ [  104.205464] x19: 0140 x18: a5e112c1
+ [  104.205466] x17: 4d48a1ed x16: b0f9c455
+ [  104.205468] x15: aa4269e9 x14: 85094ac4
+ [  104.205471] x13: 9b3b00da x12: 8aae8d9c
+ [  104.205473] x11: 9fa31fbf90b0 x10: 3f0624eb70eb
+ [  104.205475] x9 :  x8 : 0004
+ [  104.205477] x7 : 9fa2e2875400 x6 : 
+ [  104.205479] x5 : 9fa2e2875401 x4 : 
+ [  104.205481] x3 : 9fa2e2a27b00 x2 : 9fa2e2875400
+ [  104.205483] x1 : 0140 x0 : f7c2
  
  [  111.198062] INFO: rcu_sched self-detected stall on CPU
  [  111.198971] INFO: rcu_sched detected stalls on CPUs/tasks:
- [  111.198977]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6805 
- [  111.198979]32-...: (1 GPs behind) idle=291/1/0 softirq=469/470 
fqs=6805 
+ [  111.198977]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6805
+ [  111.198979]32-...: (1 GPs behind) idle=291/1/0 softirq=469/470 
fqs=6805
  [  111.198980](detected by 2, t=15002 jiffies, g=143, c=142, q=6968)
  [  111.199000] Task dump for CPU 31:
  [  111.199002] swapper/31  R  running task0 0  1 
0x0002
  [  111.199006] Call trace:
  [  111.199012] [] __switch_to+0x98/0xb0
  [  111.199014] [<000b7160dcd2>] 0xb7160dcd2
  [  111.199015] Task dump for CPU 32:
  [  111.199016] swapper/32  R  running task0 0  1 
0x0002
  [  111.199018] Call trace:
  [  111.199019] [] __switch_to+0x98/0xb0
  [  111.199020] [<000bcde2fa4e>] 0xbcde2fa4e
- [  111.227703]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6809 
+ [  111.227703]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6809
  [  111.234558] (t=15010 jiffies g=143 c=142 q=6968)
  [  111.239334] Task dump for CPU 31:
  [  111.239335] swapper/31  R  running task0 0  1 
0x0002
  [  111.239338] Call trace:
  [  111.239344] [] dump_backtrace+0x0/0x2b0
  [  111.239346] [] show_stack+0x24/0x30
  [  111.239350] [] sched_show_task+0x128/0x178
  [  111.239352] [] dump_cpu_task+0x48/0x58
  [  111.239356] [] rcu_dump_cpu_stacks+0xbc/0xf0
  [  111.239359] [] rcu_check_callbacks+0x7a8/0x968
  [  111.239362] [] 

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

The qcom_emac driver in the installer is able to get a DHCP lease once I
blacklisted the mlx5_core module.

~ # lsmod
Module  Size  Used by
uas28672  0
usb_storage77824  1 uas
at803x 16384  1
devlink36864  0
ptp28672  0
pps_core   24576  1 ptp
ahci_platform  16384  0
libahci_platform   20480  1 ahci_platform
libahci45056  2 ahci_platform,libahci_platform
qcom_emac  49152  0
sdhci_acpi 16384  0
sdhci  65536  1 sdhci_acpi
xhci_plat_hcd  16384  0
~ # ip addr show
1: lo:  mtu 65536 qdisc noqueue 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: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 8c:fd:f0:06:92:a5 brd ff:ff:ff:ff:ff:ff
inet 10.228.66.113/24 brd 10.228.66.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::8efd:f0ff:fe06:92a5/64 scope link 
   valid_lft forever preferred_lft forever
~ # cat /proc/cmdline 
BOOT_IMAGE=/ubuntu-installer/arm64/linux module_blacklist=mlx5_core --- quiet
~ #

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] rename msm_emac to qcom_emac

[Manoj Iyer]

With the PHY module and the qcom-emac driver enabled in D-I  I am able
to see the interface in the installer configure network screen.


  ┌─┤ [!!] Configure the network ├──┐
  │ │
  │ Your system has multiple network interfaces. Choose the one to use as   │
  │ the primary network interface during the installation. If possible, │
  │ the first connected network interface found has been selected.  │
  │ │
  │ Primary network interface:  │
  │ │
  │  enP1s2: Mellanox Technologies MT27700 Family [ConnectX-4]  │
  │  eth0: Ethernet │
  │ │
  ││
  │ │
  └─┘

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] rename msm_emac to qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

I built a DI where the initrd has both the PHY and the qcom_emac driver.
The d-i installer now loads both at803x and qcom_emac, but dhclient
fails to get a DHCP address. So, I am not sure what is going on with
qcom_emac.. is there another module dependency I am missing ?

~ # lsmod
Module  Size  Used by
mlx5_ib   204800  0
ib_core   249856  1 mlx5_ib
uas28672  0
usb_storage77824  1 uas
at803x 16384  0
mlx5_core 479232  1 mlx5_ib
devlink36864  1 mlx5_core
ptp28672  1 mlx5_core
pps_core   24576  1 ptp
ahci_platform  16384  0
libahci_platform   20480  1 ahci_platform
libahci45056  2 ahci_platform,libahci_platform
qcom_emac  49152  0
sdhci_acpi 16384  0
sdhci  65536  1 sdhci_acpi
xhci_plat_hcd  16384  0

~ # ip link
1: lo:  mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 8c:fd:f0:06:92:a5 brd ff:ff:ff:ff:ff:ff
3: enP1s2:  mtu 1500 qdisc mq qlen 1000
link/ether 24:8a:07:97:30:16 brd ff:ff:ff:ff:ff:ff

~ # dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/8c:fd:f0:06:92:a5
Sending on   LPF/eth0/8c:fd:f0:06:92:a5
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 (xid=0xc271fe77)

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0xc271fe77)
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
~ #

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] replace msm_emac with qcom_emac

[Manoj Iyer]

** Summary changed:

- [Zesty] rename msm_emac to qcom_emac
+ [Zesty] replace msm_emac with qcom_emac

** Summary changed:

- [Zesty] replace msm_emac with qcom_emac
+ [Zesty] d-i: replace msm_emac with qcom_emac

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1680549] [NEW] [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s!

[Manoj Iyer]

] [] el1_irq+0xdc/0x180
[  111.239411] [] alloc_iova+0x1cc/0x2a0
[  111.239413] [] __alloc_iova+0x78/0x88
[  111.239414] [] __iommu_dma_map+0x90/0x128
[  111.239416] [] iommu_dma_map_page+0x60/0x78
[  111.239420] [] __iommu_map_page+0x5c/0xd0
[  111.239565] [] mlx5e_alloc_rx_wqe+0x118/0x318 [mlx5_core]
[  111.239607] [] mlx5e_post_rx_wqes+0xa0/0x110 [mlx5_core]
[  111.239647] [] mlx5e_napi_poll+0x22c/0x518 [mlx5_core]
[  111.239650] [] net_rx_action+0x2e8/0x3f0
[  111.239652] [] __do_softirq+0x148/0x31c
[  111.239656] [] irq_exit+0xd0/0x120
[  111.239658] [] __handle_domain_irq+0x6c/0xc0
[  111.239660] [] gic_handle_irq+0xc4/0x170
[  111.239661] Exception stack(0x9fa30ecffd80 to 0x9fa30ecffeb0)
[  111.239663] fd80: 9fa31fa85200 609cfabd2000 0640 
0004
[  111.239665] fda0: 3296 0015 5c57e302 

[  111.239667] fdc0:    

[  111.239668] fde0:    

[  111.239670] fe00:    
000b7179114e
[  111.239672] fe20: 9fa3041c8000 0003 3f0625292eb8 

[  111.239673] fe40: 000b7160dcd2 0003  

[  111.239675] fe60:  9fa30ecffeb0 3f06248549bc 
9fa30ecffeb0
[  111.239677] fe80: 3f06248549c4 60400145 9fa30ecffeb0 
3f06248549bc
[  111.239678] fea0:  000b7160dcd2
[  111.239680] [] el1_irq+0xdc/0x180
[  111.239684] [] cpuidle_enter_state+0x124/0x318
[  111.239686] [] cpuidle_enter+0x34/0x48
[  111.239689] [] call_cpuidle+0x40/0x70
[  111.239691] [] do_idle+0x1ac/0x1f8
[  111.239693] [] cpu_startup_entry+0x2c/0x30
[  111.239695] [] secondary_start_kernel+0x158/0x198
[  111.239696] [<112091a4>] 0x112091a4
[  111.239697] Task dump for CPU 32:
[  111.239699] swapper/32  R  running task0 0  1 0x0002
[  111.239701] Call trace:
[  111.239704] [] __switch_to+0x98/0xb0
[  111.239705] [<000bcde2fa4e>] 0xbcde2fa4e
[  129.361765] ip_tables: (C) 2000-2006 Netfilter Core Team
[  129.397270] ip6_tables: (C) 2000-2006 Netfilter Core Team
[  129.438584] Ebtables v2.0 registered

[FIX]
The following patches applied in this order fixes this issue.
d9a5f8adaec9 iommu/dma: Plumb in the per-CPU IOVA caches
fc7f6142bacb iommu/dma: Clean up MSI IOVA allocation
568c61384ea1 iommu/dma: Convert to address-based allocation
632b072f iommu/dma: Implement PCI allocation optimisation
de84f5f049d9 iommu/dma: Stop getting dma_32bit_pfn wrong

[Test case]
After applying the patches the kernel boot with no soft lockups. This was 
tested by me on Zesty Ubuntu-4.10.0-18.20 on QDF2400 SDP.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Manoj Iyer (manjo)
 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/1680549

Title:
  [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8
  stuck for 22s!

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [IMPACT]
  On QDF2400 ARM64 servers, booting Zesty 4.10 kernel causes soft lockups on 
multiple CPUs. 

  [  104.205397] Modules linked in: nls_iso8859_1 cdc_acm bridge stp llc
  ipmi_ssif ipmi_devintf ipmi_msghandler shpchp hdma hdma_mgmt i2c_qup
  cppc_cpufreq ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp
  libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10
  raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
  raid6_pq libcrc32c raid1 raid0 multipath linear uas usb_storage at803x
  aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce
  sha1_ce mlx5_core devlink ptp pps_core ahci_platform libahci_platform
  libahci qcom_emac sdhci_acpi sdhci xhci_plat_hcd pinctrl_qdf2xxx fjes
  aes_neon_blk crypto_simd cryptd

  [  104.205442] CPU: 47 PID: 0 Comm: swapper/47 Tainted: G L  
4.10.0-16-generic #18ubuntuRC03+bandera.1
  [  104.205443] Hardware name: Qualcomm QDF2400 DP/ABW|SYS|CVR,1DPC|V3 
  , BIOS XBL.DF.2.0.R3-00153 QDF2400_REL CRM 02/ 8/2017
  [  104.205444] task: 9fa30ed49c00 task.stack: 9fa30ed5c000
  [  104.205447] PC is at _raw_spin_unlock_irqrestore+0x2c/0x38
  [  104.205450] LR is at alloc_iova+0x1cc/0x2a0
  [  104.205451] pc : [] lr : [] pstate: 
20400145
  [  104.205452] sp : 9fa31fbecc00
  [  104.205453] x29: 9fa31fbecc00 x28: 000efe46 
  [  104.205455] x27: 0040 x26: 000f 
  [  104.205458] x25: 3f06251f8000 x24: 0001 
  [  104.205460] x23: 9fa30da06008 x22:  
  [  104.205462] x21: 9fa2e2af8740 x20: 9fa30da06008 
  [  104.205464] x19: 0140 x18: a5e112c1 
  [  104.205466] x17: 4d48a1

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

on my qdf2400 server. Looks like dhclient is able to get a lease and
ifconfig displays the ip address.

ubuntu@ubuntu:~$ sudo dhclient -v eth0
[sudo] password for ubuntu:
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/8c:fd:f0:06:92:a5
Sending on LPF/eth0/8c:fd:f0:06:92:a5
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPREQUEST of 10.228.66.113 on eth0 to 255.255.255.255 port 67 (xid=0x6ae3761b)
DHCPOFFER of 10.228.66.113 from 10.228.66.3
DHCPACK of 10.228.66.113 from 10.228.66.3
bound to 10.228.66.113 -- renewal in 268 seconds.

ubuntu@ubuntu:~$ ifconfig
enP1s2 Link encap:Ethernet HWaddr 24:8a:07:97:30:16
  inet addr:10.228.66.114 Bcast:10.228.66.255 Mask:255.255.255.0
  inet6 addr: fe80::268a:7ff:fe97:3016/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
  RX packets:5290 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1752 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3115155 (3.1 MB) TX bytes:368794 (368.7 KB)

eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:92:a5
  inet addr:10.228.66.113 Bcast:10.228.66.255 Mask:255.255.255.0
  inet6 addr: fe80::8efd:f0ff:fe06:92a5/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
  RX packets:6 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:950 (950.0 B) TX bytes:2436 (2.4 KB)
  Interrupt:40

lo Link encap:Local Loopback
  inet addr:127.0.0.1 Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING MTU:65536 Metric:1
  RX packets:160 errors:0 dropped:0 overruns:0 frame:0
  TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-19-generic #21ubuntuRC04+patchset.1-Ubuntu SMP Mon Apr 10 
17:09:12 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~$

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1486152] Re: Kernel WARN @ block/genhd.c:352 with ltp block dev tests

[Manoj Iyer]

Please try the LTS backport HWE-X kernel or LTS 14.04.05, and see if you
can reproduce this bug?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1486152

Title:
  Kernel WARN @ block/genhd.c:352 with ltp block dev tests

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - SACHIN P. SANT  - 2015-08-07 08:28:13 ==
  ---Problem Description---
  Kernel WARN @ block/genhd.c:352 with ltp block dev tests
   
  Contact Information = Sachin Sant / ss...@in.ibm.com 
   
  ---uname output---
  3.19.0-26-generic
   
  Machine Type = POWER8 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1) Install Ubuntu 14.04.03 running bare-metal
  2) Install LTP and compile the code
  3) run the ltp_block_dev tests 

  The krenel Warning is displayed on the  console during the run
   
  Stack trace output:
   [  175.365323] ltp_block_dev: Test Case Result: PASS
  [  175.365547] ltp_block_dev: Test Case 6: register_blkdev() with name=""
  [  175.365550] ltp_block_dev: Test Case Result: PASS
  [  175.365615] ltp_block_dev: Test Case 7: unregister_blkdev() with major=0
  [  175.365628] [ cut here ]
  [  175.365630] WARNING: at 
/build/linux-lts-vivid-GlOzk5/linux-lts-vivid-3.19.0/block/genhd.c:352
  [  175.365632] Modules linked in: ltp_block_dev(OE) joydev mac_hid 
hid_generic ofpart ipmi_powernv cmdlinepart ipmi_msghandler powernv_flash mtd 
opal_prd powernv_rng at24 usbhid hid ast uio_pdrv_genirq syscopyarea uio 
sysfillrect sysimgblt nouveau ttm drm_kms_helper drm i2c_algo_bit mlx4_en vxlan 
ip6_udp_tunnel udp_tunnel uas usb_storage bnx2x mlx4_core lpfc ahci libahci 
scsi_transport_fc mdio libcrc32c [last unloaded: ltp_block_dev]
  [  175.365663] CPU: 133 PID: 4832 Comm: block_dev Tainted: GW  OE  
3.19.0-26-generic #27~14.04.1-Ubuntu
  [  175.365666] task: c00fcebc9140 ti: c00fcec1c000 task.ti: 
c00fcec1c000
  [  175.365669] NIP: c04eb5cc LR: c04eb574 CTR: 
c04eb520
  [  175.365671] REGS: c00fcec1f940 TRAP: 0700   Tainted: GW  OE   
(3.19.0-26-generic)
  [  175.365673] MSR: 90029033   CR: 28000482  
XER: 2000
  [  175.365681] CFAR: c04eb59c SOFTE: 1 
  [  175.365681] GPR00: c04eb574 c00fcec1fbc0 c144cc00 
 
  [  175.365681] GPR04: d000190b12c8 000d 636f6c62 
0001 
  [  175.365681] GPR08: c174db10  c174db10 
d000190b10d0 
  [  175.365681] GPR12: c04eb520 c7baad00  
 
  [  175.365681] GPR16:    
 
  [  175.365681] GPR20:  1000a8a8 10020010 
1000a8f0 
  [  175.365681] GPR24: 1000a918 1000a9b8 00fb 
0001 
  [  175.365681] GPR28: d000190b12c8 c1379468  
 
  [  175.365712] NIP [c04eb5cc] unregister_blkdev+0xac/0x160
  [  175.365714] LR [c04eb574] unregister_blkdev+0x54/0x160
  [  175.365716] Call Trace:
  [  175.365719] [c00fcec1fbc0] [c04eb574] 
unregister_blkdev+0x54/0x160 (unreliable)
  [  175.365723] [c00fcec1fc00] [d000190b063c] sys_tcase+0x41c/0xb30 
[ltp_block_dev]
  [  175.365728] [c00fcec1fcc0] [c06431f8] dev_attr_store+0x68/0xa0
  [  175.365732] [c00fcec1fd00] [c035ba30] sysfs_kf_write+0x80/0xb0
  [  175.365735] [c00fcec1fd40] [c035a97c] 
kernfs_fop_write+0x18c/0x1f0
  [  175.365739] [c00fcec1fd90] [c02b488c] vfs_write+0xdc/0x260
  [  175.365743] [c00fcec1fde0] [c02b573c] SyS_write+0x6c/0x110
  [  175.365747] [c00fcec1fe30] [c0009258] system_call+0x38/0xd0
  [  175.365748] Instruction dump:
  [  175.365750] 419e0030 80e90008 7f87f000 409e0018 48c0 815f0008 7f8af000 
419e0058 
  [  175.365756] 7fe9fb78 ebe9 2fbf 409effe8 <0fe0> 7fa3eb78 
3be0 48528871 
  [  175.365761] ---[ end trace 02836eb1f955a5cd ]---

   
  Oops output:
   no
   
  System Dump Info:
The system is not configured to capture a system dump.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1486152/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1671246] [NEW] kexec-tools does not build for armhf

[Manoj Iyer]

Public bug reported:

[Impact]
On armhf system kexec build fails as follows:
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

The fix for this issue is already upstream:

>From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
From: Simon Horman <ho...@verge.net.au>
Date: Fri, 9 Dec 2016 10:10:49 +0100
Subject: [PATCH] arm: do not build iomem.o target with no soruce

Header files should be added to the distribution but not
used to derive targets for compilation. In this an attempt was
made to build iomem.o, but iomem.c does not exist so this fails.

Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in distribution")
Signed-off-by: Simon Horman <ho...@verge.net.au>
Reviewed-by: Pratyush Anand <pan...@redhat.com>

[Test Case]
Build kexec-tools package from Xenial/Yakkety source in armhf system.

[Regression Potential]
Since patch is confined to arm there is a low overall risk of regression

** Affects: kexec-tools (Ubuntu)
 Importance: High
 Assignee: Manoj Iyer (manjo)
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1671246

Title:
  kexec-tools does not build for armhf

Status in kexec-tools package in Ubuntu:
  New

Bug description:
  [Impact]
  On armhf system kexec build fails as follows:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
  make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

  The fix for this issue is already upstream:

  From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
  From: Simon Horman <ho...@verge.net.au>
  Date: Fri, 9 Dec 2016 10:10:49 +0100
  Subject: [PATCH] arm: do not build iomem.o target with no soruce

  Header files should be added to the distribution but not
  used to derive targets for compilation. In this an attempt was
  made to build iomem.o, but iomem.c does not exist so this fails.

  Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in 
distribution")
  Signed-off-by: Simon Horman <ho...@verge.net.au>
  Reviewed-by: Pratyush Anand <pan...@redhat.com>

  [Test Case]
  Build kexec-tools package from Xenial/Yakkety source in armhf system.

  [Regression Potential]
  Since patch is confined to arm there is a low overall risk of regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1671246] Re: kexec-tools does not build for armhf

[Manoj Iyer]

This debdiff applies cleanly and builds
https://pastebin.canonical.com/181891/

** Patch added: "[Xenial] kexec fix armhf build failure"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+attachment/4834009/+files/xenial-kexec-tools-armhf-build.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1671246

Title:
  kexec-tools does not build for armhf

Status in kexec-tools package in Ubuntu:
  New

Bug description:
  [Impact]
  On armhf system kexec build fails as follows:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
  make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

  The fix for this issue is already upstream:

  From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
  From: Simon Horman 
  Date: Fri, 9 Dec 2016 10:10:49 +0100
  Subject: [PATCH] arm: do not build iomem.o target with no soruce

  Header files should be added to the distribution but not
  used to derive targets for compilation. In this an attempt was
  made to build iomem.o, but iomem.c does not exist so this fails.

  Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in 
distribution")
  Signed-off-by: Simon Horman 
  Reviewed-by: Pratyush Anand 

  [Test Case]
  Build kexec-tools package from Xenial/Yakkety source in armhf system.

  [Regression Potential]
  Since patch is confined to arm there is a low overall risk of regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1671246] Re: kexec-tools does not build for armhf

[Manoj Iyer]

This debdiff applies and builds cleanly
https://pastebin.canonical.com/181893/ on armhf

** Patch added: "[Yakkety]  kexec fix armhf build failure"
   
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+attachment/4834067/+files/yakkety-kexec-tools-armhf-build.patch

** Changed in: kexec-tools (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1671246

Title:
  kexec-tools does not build for armhf

Status in kexec-tools package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  On armhf system kexec build fails as follows:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
  make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

  The fix for this issue is already upstream:

  From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
  From: Simon Horman 
  Date: Fri, 9 Dec 2016 10:10:49 +0100
  Subject: [PATCH] arm: do not build iomem.o target with no soruce

  Header files should be added to the distribution but not
  used to derive targets for compilation. In this an attempt was
  made to build iomem.o, but iomem.c does not exist so this fails.

  Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in 
distribution")
  Signed-off-by: Simon Horman 
  Reviewed-by: Pratyush Anand 

  [Test Case]
  Build kexec-tools package from Xenial/Yakkety source in armhf system.

  [Regression Potential]
  Since patch is confined to arm there is a low overall risk of regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

~ # rmmod qcom_emac
~ # modprobe qcom_emac 
~ # dmesg | tail -n 15


[  211.382709] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver 
[Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[  211.382789] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4479.862691] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver 
[Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 4479.862752] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4481.902187] 803x_aneg_done: SGMII link is not ok
[ 4644.846719] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver 
[Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 4644.846785] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4646.905307] 803x_aneg_done: SGMII link is not ok
[50268.581165] libphy: emac-mdio: probed
[50268.582675] qcom-emac QCOM8070:00 eth0: hardware id 64.1, hardware version 
1.3.0
[50491.411665] libphy: emac-mdio: probed
[50491.413174] qcom-emac QCOM8070:00 eth0: hardware id 64.1, hardware version 
1.3.0
~ #

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1680549] Re: [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s!

[Manoj Iyer]

** Changed in: linux (Ubuntu)
   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/1680549

Title:
  [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8
  stuck for 22s!

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [IMPACT]
  On QDF2400 ARM64 servers, booting Zesty 4.10 kernel causes soft lockups on 
multiple CPUs. 

  [  104.205397] Modules linked in: nls_iso8859_1 cdc_acm bridge stp llc
  ipmi_ssif ipmi_devintf ipmi_msghandler shpchp hdma hdma_mgmt i2c_qup
  cppc_cpufreq ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp
  libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10
  raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
  raid6_pq libcrc32c raid1 raid0 multipath linear uas usb_storage at803x
  aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce
  sha1_ce mlx5_core devlink ptp pps_core ahci_platform libahci_platform
  libahci qcom_emac sdhci_acpi sdhci xhci_plat_hcd pinctrl_qdf2xxx fjes
  aes_neon_blk crypto_simd cryptd

  [  104.205442] CPU: 47 PID: 0 Comm: swapper/47 Tainted: G L  
4.10.0-16-generic #18ubuntuRC03+bandera.1
  [  104.205443] Hardware name: Qualcomm QDF2400 DP/ABW|SYS|CVR,1DPC|V3 
  , BIOS XBL.DF.2.0.R3-00153 QDF2400_REL CRM 02/ 8/2017
  [  104.205444] task: 9fa30ed49c00 task.stack: 9fa30ed5c000
  [  104.205447] PC is at _raw_spin_unlock_irqrestore+0x2c/0x38
  [  104.205450] LR is at alloc_iova+0x1cc/0x2a0
  [  104.205451] pc : [] lr : [] pstate: 
20400145
  [  104.205452] sp : 9fa31fbecc00
  [  104.205453] x29: 9fa31fbecc00 x28: 000efe46 
  [  104.205455] x27: 0040 x26: 000f 
  [  104.205458] x25: 3f06251f8000 x24: 0001 
  [  104.205460] x23: 9fa30da06008 x22:  
  [  104.205462] x21: 9fa2e2af8740 x20: 9fa30da06008 
  [  104.205464] x19: 0140 x18: a5e112c1 
  [  104.205466] x17: 4d48a1ed x16: b0f9c455 
  [  104.205468] x15: aa4269e9 x14: 85094ac4 
  [  104.205471] x13: 9b3b00da x12: 8aae8d9c 
  [  104.205473] x11: 9fa31fbf90b0 x10: 3f0624eb70eb 
  [  104.205475] x9 :  x8 : 0004 
  [  104.205477] x7 : 9fa2e2875400 x6 :  
  [  104.205479] x5 : 9fa2e2875401 x4 :  
  [  104.205481] x3 : 9fa2e2a27b00 x2 : 9fa2e2875400 
  [  104.205483] x1 : 0140 x0 : f7c2 

  [  111.198062] INFO: rcu_sched self-detected stall on CPU
  [  111.198971] INFO: rcu_sched detected stalls on CPUs/tasks:
  [  111.198977]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6805 
  [  111.198979]32-...: (1 GPs behind) idle=291/1/0 softirq=469/470 
fqs=6805 
  [  111.198980](detected by 2, t=15002 jiffies, g=143, c=142, q=6968)
  [  111.199000] Task dump for CPU 31:
  [  111.199002] swapper/31  R  running task0 0  1 
0x0002
  [  111.199006] Call trace:
  [  111.199012] [] __switch_to+0x98/0xb0
  [  111.199014] [<000b7160dcd2>] 0xb7160dcd2
  [  111.199015] Task dump for CPU 32:
  [  111.199016] swapper/32  R  running task0 0  1 
0x0002
  [  111.199018] Call trace:
  [  111.199019] [] __switch_to+0x98/0xb0
  [  111.199020] [<000bcde2fa4e>] 0xbcde2fa4e
  [  111.227703]31-...: (1 GPs behind) idle=1b3/2/0 softirq=432/433 
fqs=6809 
  [  111.234558] (t=15010 jiffies g=143 c=142 q=6968)
  [  111.239334] Task dump for CPU 31:
  [  111.239335] swapper/31  R  running task0 0  1 
0x0002
  [  111.239338] Call trace:
  [  111.239344] [] dump_backtrace+0x0/0x2b0
  [  111.239346] [] show_stack+0x24/0x30
  [  111.239350] [] sched_show_task+0x128/0x178
  [  111.239352] [] dump_cpu_task+0x48/0x58
  [  111.239356] [] rcu_dump_cpu_stacks+0xbc/0xf0
  [  111.239359] [] rcu_check_callbacks+0x7a8/0x968
  [  111.239362] [] update_process_times+0x34/0x60
  [  111.239365] [] tick_sched_handle.isra.7+0x38/0x70
  [  111.239367] [] tick_sched_timer+0x4c/0x98
  [  111.239369] [] __hrtimer_run_queues+0xe8/0x2e8
  [  111.239371] [] hrtimer_interrupt+0xa8/0x228
  [  111.239376] [] arch_timer_handler_phys+0x3c/0x50
  [  111.239379] [] handle_percpu_devid_irq+0x8c/0x230
  [  111.239383] [] generic_handle_irq+0x34/0x50
  [  111.239385] [] __handle_domain_irq+0x68/0xc0
  [  111.239386] [] gic_handle_irq+0xc4/0x170
  [  111.239388] Exception stack(0x9fa31fa7caa0 to 0x9fa31fa7cbd0)
  [  111.239390] caa0: 9fa31fa7cad0 0001 9fa31fa7cc00 
3f0624a00974
  [  111.239392] cac0: 20400145 0001 00fe 
0140
  [  111.239394] cae0: 9fa2e10b1c00 9fa2e11c8800  
9fa2e10b1c01
  [  111.239396] cb00:  9fa2e10b1c00 

[Kernel-packages] [Bug 1658790] Re: Ubuntu 17.04: kdump fails with error "kdump-tools[1532]: /etc/init.d/kdump-tools: 26: [: -ne: unexpected operator" when / file system is xfs.

[Manoj Iyer]

Based on the last comment making this bug invalid.

** Changed in: makedumpfile (Ubuntu)
   Status: New => Invalid

** Changed in: makedumpfile (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1658790

Title:
  Ubuntu 17.04: kdump fails with error "kdump-tools[1532]: /etc/init.d
  /kdump-tools: 26: [: -ne: unexpected operator" when / file system is
  xfs.

Status in makedumpfile package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---

  Ubuntu 17.04: kdump fails with error "kdump-tools[1532]: /etc/init.d
  /kdump-tools: 26: [: -ne: unexpected operator" when / file system is
  xfs.

  ---Steps to Reproduce---

  1. Install Ubuntu 17.04 with / as xfs.
  2. Configure kdump.
  3. trigger crash.

  Machine hangs after below log. Attaching console log.

   Starting Raise network interfaces...
  [  OK  ] Started Raise network interfaces.
  [  OK  ] Reached target Network.
  [  OK  ] Reached target Network is Online.
   Starting iSCSI initiator daemon (iscsid)...
   Starting Kernel crash dump capture service...
  [  OK  ] Started iSCSI initiator daemon (iscsid).
   Starting Login to default iSCSI targets...
  [   86.119692] kdump-tools[1532]: /etc/init.d/kdump-tools: 26: [: -ne: 
unexpected operator
  [  OK  ] Started Kernel crash dump capture service.
  [  OK  ] Started Login to default iSCSI targets.
  [  OK  ] Reached target Remote File Systems (Pre).

  
  4. After manual reboot  /etc/default/kdump-tools is empty.

  Logs
  ---

  root@tuleta4u-lp4:/home/ubuntu# kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.9.0-11-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.9.0-11-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinux-4.9.0-11-generic 
root=UUID=adbca1e4-13ef-4054-a486-402ab1552ca6 ro irqpoll nr_cpus=1 nousb 
systemd.unit=kdump-tools.service ata_piix.prefer_ms_hyperv=0" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  root@tuleta4u-lp4:/home/ubuntu# tail /etc/default/kdump-tools 
  #
  # SSH_KEY=""
  #
  # HOSTTAG="hostname|[ip]"
  # 
  # NFS=""
  #
  # NFS_TIMEO="600"
  #
  # NFS_RETRANS="3"
  root@tuleta4u-lp4:/home/ubuntu# echo "c" > /proc/sysrq-trigger
  [  199.601020] sysrq: SysRq : Trigger a crash
  [  199.601044] Unable to handle kernel paging request for data at address 
0x
  [  199.601053] Faulting instruction address: 0xc06af628
  [  199.601061] Oops: Kernel access of bad area, sig: 11 [#1]
  [  199.601066] SMP NR_CPUS=2048 [  199.601069] NUMA

  
  after crash:

  root@tuleta4u-lp4:/home/ubuntu# cat /etc/default/kdump-tools 
  root@tuleta4u-lp4:/home/ubuntu#

  > > > 
  > > > Hi,
  > > > 
  > > > yeah bug is recreatable.
  > > > 
  > > 
  > > Hi Pavithra/Latha,
  > > 
  > > Any idea why /etc/default/kdumpt-tools file is empty?
  > > Are we getting an empty /etc/default/kdumpt-tools file on installing
  > > kdump-tools?
  > > 
  > > Pavithra, please mention the steps used to recreated this bug..
  > > 
  > > Thanks
  > > Hari
  > 
  > When we install kdump /etc/default/kdumpt-tools will have valid contents and
  > "kdump-config show" shows "ready to kdump" but after crash
  > /etc/default/kdumpt-tools file contents are getting deleted. 
  > 
  > ---Steps to Reproduce---
  > 
  > 1. Install Ubuntu 17.04 with / as xfs.
  > 2. Configure kdump.
  > 3. trigger crash.
  >

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1658790/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1667245] Re: ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

[Manoj Iyer]

/proc/vmcore is generated by kdump support in the kernel. This might not
be a bug, but a case of missing support for regenerating /proc/vmcore
entries after DLPAR memory removal.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1667245

Title:
  ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  After a memory DLPAR removal, kdump doesn't work:

   Starting Kernel crash dump capture service...
  [   67.714593] kdump-tools[3850]: Starting kdump-tools:  * running 
makedumpfile -c -d 31 /proc/vmcore /var/crash/201702230005/dump-incomplete
  Copying data   : [  2.1 %] -/usr/sbin/kdump-config: line 
639:  3897 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [   72.314140] kdump-tools[3850]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [   73.693881] kdump-tools[3850]: cp: error reading '/proc/vmcore': Bad 
address
  [   73.704152] kdump-tools[3850]:  * kdump-tools: failed to save vmcore in 
/var/crash/201702230005
  [   73.823643] kdump-tools[3850]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201702230005/dmesg.201702230005
  [   73.973813] kdump-tools[3850]: The kernel version is not supported.
  [   73.974078] kdump-tools[3850]: The makedumpfile operation may be 
incomplete.
  [   73.983506] kdump-tools[3850]: The dmesg log is saved to 
/var/crash/201702230005/dmesg.201702230005.
  [   73.983752] kdump-tools[3850]: makedumpfile Completed.
  [   73.983998] kdump-tools[3850]:  * kdump-tools: saved dmesg content in 
/var/crash/201702230005
  [   74.104555] kdump-tools[3850]: Thu, 23 Feb 2017 00:05:15 -0600
  [   74.233502] kdump-tools[3850]: Failed to read reboot parameter file: No 
such file or directory
  [   74.233782] kdump-tools[3850]: Rebooting.
  [   86.629777] reboot: Restarting system

  
  The kdump service should be restarted after the memory DLPAR operation.
   
  C
  ---uname output---
  Linux roselp4 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:00:06 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. config kdump on roselp4
  2. do a memory DLPAR removal operation
  3. trigger kdump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1667245/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1633223] Re: rcu_sched detected stalls with kernel 3.19.0-58, NVIDIA driver, and docker

[Manoj Iyer]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1633223

Title:
  rcu_sched detected stalls with kernel 3.19.0-58, NVIDIA driver, and
  docker

Status in linux package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---
  Seeing occasional rcu_sched detected stalls on 14.04 LTS with kernel 
3.19.0-58. The system is running docker containers, and has the NVIDIA GPU 
driver loaded. We've seen about 4 stalls in the last month, all with the 
3.19.0-58 kernel, and with the NVIDIA 352.93 and 361.49 drivers.

  ---uname output---
  Linux dldev1 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:01 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  ---Additional Hardware Info---
  2 x NVIDIA K80 GPU adapter:
  $ lspci | grep NV
  0002:03:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1)
  0002:04:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1)
  0006:03:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1)
  0006:04:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) 

   
  Machine Type = 8247-42L 
   
  ---System Hang---
   Usual symptom is that the system is unresponsive except maybe for ping and 
writing the stall-detection messages to the console. Login/getty isn't 
available either via ssh nor on the console. System must be power cycled to 
recover.
   
  Attached is the kernel log from a stall detection on May 18th. The detection 
first occurs at: May 18 15:17:55.

  The system is later rebooted and those messages indicate the kernel
  (3.19.0-58) and NVIDIA driver version (352.93) that were active at the
  time.

  We've suffered 3 or 4 stalls since, all with the same kernel, but some
  with a newer NVIDIA driver (361.49).

  Unfortunately, information about the newer stalls wasn't preserved in
  the various log files (and we're not capturing the console
  constantly), so we don't have detailed data for those.

  We'd welcome any suggestions for how to collect additional data for
  these occurrences.

  I can't say for sure that we haven't seen the stalls on other systems,
  but they're occuring fairly frequently on this system, and it's
  unusual in that it's running both Docker and NVIDIA GPU driver. So
  maybe aufs or the NVIDIA driver are somehow involved.

  From the kern.log,

  The Call trace points to some kind of deadlock in aufs -

  May 18 15:17:55 dldev1 kernel: [713670.798624] Task dump for CPU 3:
  May 18 15:17:55 dldev1 kernel: [713670.798628] cc1 R  running 
task0 99183  99173 0x00040004
  May 18 15:17:55 dldev1 kernel: [713670.798633] Call Trace:
  May 18 15:17:55 dldev1 kernel: [713670.798643] [c00fa64673a0] 
[c00cf004] wake_up_worker+0x44/0x60 (unreliable)
  May 18 15:17:55 dldev1 kernel: [713670.798671] [c00fa6467570] 
[c00fa64675d0] 0xc00fa64675d0
  May 18 15:17:55 dldev1 kernel: [713670.798676] [c00fa64675d0] 
[c0a1b050] __schedule+0x370/0x900
  May 18 15:17:55 dldev1 kernel: [713670.798679] [c00fa64677f0] 
[c00fa6467850] 0xc00fa6467850
  May 18 15:17:55 dldev1 kernel: [713670.798682] Task dump for CPU 75:
  May 18 15:17:55 dldev1 kernel: [713670.798684] cc1 D 
105d9410 0 99427  99405 0x00040004
  May 18 15:17:55 dldev1 kernel: [713670.798688] Call Trace:
  May 18 15:17:55 dldev1 kernel: [713670.798691] [c017efdd3460] 
[c017efdd34a0] 0xc017efdd34a0 (unreliable)
  May 18 15:17:55 dldev1 kernel: [713670.798695] [c017efdd3630] 
[c017efdd3690] 0xc017efdd3690
  May 18 15:17:55 dldev1 kernel: [713670.798698] [c017efdd3690] 
[c0a1b050] __schedule+0x370/0x900
  May 18 15:17:55 dldev1 kernel: [713670.798702] [c017efdd38b0] 
[c0a1f128] rwsem_down_write_failed+0x288/0x400
  May 18 15:17:55 dldev1 kernel: [713670.798706] [c017efdd3940] 
[c0a1e538] down_write+0x88/0x90
  May 18 15:17:55 dldev1 kernel: [713670.798716] [c017efdd3970] 
[d0001ead562c] do_ii_write_lock+0x8c/0xd0 [aufs]
  May 18 15:17:55 dldev1 kernel: [713670.798724] [c017efdd39a0] 
[d0001eac0e98] aufs_read_lock+0xb8/0xd0 [aufs]
  May 18 15:17:55 dldev1 kernel: [713670.798733] [c017efdd39e0] 
[d0001ead8208] aufs_d_revalidate+0x98/0x7a0 [aufs]
  May 18 15:17:55 dldev1 kernel: [713670.798737] [c017efdd3aa0] 
[c02c88f8] lookup_fast+0x368/0x3b0
  May 18 15:17:55 dldev1 kernel: [713670.798740] [c017efdd3b10] 
[c02cb620] path_lookupat+0x180/0x970
  May 18 15:17:55 dldev1 kernel: [713670.798743] [c017efdd3be0] 
[c02cbe68] filename_lookup+0x58/0x140
  May 18 15:17:55 dldev1 kernel: [713670.798746] [c017efdd3c30] 
[c02cde04] user_path_at_empty+0x84/0xe0
  May 18 

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[Yakkety Proposed Testing]

ubuntu@test:~$ cat /etc/issue
Ubuntu 16.10 \n \l
ubuntu@test:~$ sudo apt policy kexec-tools
kexec-tools:
  Installed: (none)
  Candidate: 1:2.0.10-2ubuntu1.1
  Version table:
 1:2.0.10-2ubuntu1.1 500
500 http://ports.ubuntu.com/ubuntu-ports yakkety-proposed/main arm64 
Packages
ubuntu@test:~$

ubuntu@test:~$ uname -a 
Linux test 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28 
23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@test:~$ 
ubuntu@test:~$ sudo kexec -l /boot/vmlinuz-4.10.0-10-generic 
--initrd=/boot/initrd.img-4.8.0-41-generic --reuse-cmdline
ubuntu@test:~$ sudo kexec -e
[ 1095.110521] kexec_core: Starting new kernel



** Tags removed: verification-needed
** Tags added: verification-done-yakkety

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in kexec-tools source package in Yakkety:
  Fix Committed
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1659618] Re: Enable ARM64 support in kexec-tools

[Manoj Iyer]

[Xenial Proposed Testing]
ubuntu@ubuntu:~$ sudo apt policy kexec-tools
kexec-tools:
  Installed: (none)
  Candidate: 1:2.0.10-1ubuntu2.1
  Version table:
 1:2.0.10-1ubuntu2.1 500
500 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
Packages

ubuntu@ubuntu:~$ sudo kexec -l /boot/vmlinuz-4.10.0-11-generic 
--initrd=/boot/initrd.img-4.10.0-11-generic --reuse-cmdline
ubuntu@ubuntu:~$ 

ubuntu login: [522805.585557] kexec_core: Starting new kernel
[0.00] Booting Linux on physical CPU 0x200
[0.00] Linux version 4.10.0-11-generic (manjo@rugby) (gcc version 5.4.0 
20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #13ubuntu1+bandera.1 SMP Thu 
Mar 9 20:26:04 UTC 2017 (Ubuntu 4.10.0-11.13ubuntu1+bandera.1-generic 4.10.1)
[0.00] Boot CPU: AArch64 Processor [510f8000]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.60 by Qualcomm
[0.00] efi:  ACPI 2.0=0x96c  SMBIOS 3.0=0x58b  PROP=0xe90a580  
ESRT=0xbacf218  MEMATTR=0xbaac018  RNG=0xe8c6c18 


** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1659618

Title:
  Enable ARM64 support in kexec-tools

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in kexec-tools source package in Yakkety:
  Fix Committed
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  [IMPACT]
   * kexec-tools in Xenial (16.04) currently does not support ARM64
     architecture.
   * Backport support for ARM64 arch from upstream
     https://github.com/horms/kexec-tools
   * Majority of the patches are contained in kexec/arch/arm64/ except for
     one patch that impacts purgatory and common device tree routines.

  [TEST CASE]
   * I built kexec-tools for ARM64 and tested it on HW using the following
     testcase:
     $ sudo kexec -l /boot/vmlinuz--generic
   --initrd=/boot/initrd.img--generic
   --command-line="root=UUID= ro vt.handoff=7"
     $ sudo kexec -e
   * I was able to kexec the new kernel successfully.
   * [ 6702.357899] kexec_core: Starting new kernel
     [0.00] Booting Linux on physical CPU 0x200
     [0.00] Linux version -generic (buildd@bos01-arm64-008)
     (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) )
     [0.00] Boot CPU: AArch64 Processor [510f8000]

  [REGRESSION POTENTIAL]
   * Since patches are confined to arm[64] there is a low overall risk of
     regression.

  [OTHER INFO]
   * You can find a Xenial kexec-tools package built for AMD64, i386 and
     ARM64 in my PPA
     https://launchpad.net/~manjo/+archive/ubuntu/kexec-tools
   * This package is built using the Xenial source package for kexec-tools
     with ARM64 enablement patches applied.
   * Please pull the changes from my PPA package and integrate into Ubuntu
     Xenial kexec-tools after review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1659618/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1486152] Re: Kernel WARN @ block/genhd.c:352 with ltp block dev tests

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1486152

Title:
  Kernel WARN @ block/genhd.c:352 with ltp block dev tests

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - SACHIN P. SANT  - 2015-08-07 08:28:13 ==
  ---Problem Description---
  Kernel WARN @ block/genhd.c:352 with ltp block dev tests
   
  Contact Information = Sachin Sant / ss...@in.ibm.com 
   
  ---uname output---
  3.19.0-26-generic
   
  Machine Type = POWER8 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1) Install Ubuntu 14.04.03 running bare-metal
  2) Install LTP and compile the code
  3) run the ltp_block_dev tests 

  The krenel Warning is displayed on the  console during the run
   
  Stack trace output:
   [  175.365323] ltp_block_dev: Test Case Result: PASS
  [  175.365547] ltp_block_dev: Test Case 6: register_blkdev() with name=""
  [  175.365550] ltp_block_dev: Test Case Result: PASS
  [  175.365615] ltp_block_dev: Test Case 7: unregister_blkdev() with major=0
  [  175.365628] [ cut here ]
  [  175.365630] WARNING: at 
/build/linux-lts-vivid-GlOzk5/linux-lts-vivid-3.19.0/block/genhd.c:352
  [  175.365632] Modules linked in: ltp_block_dev(OE) joydev mac_hid 
hid_generic ofpart ipmi_powernv cmdlinepart ipmi_msghandler powernv_flash mtd 
opal_prd powernv_rng at24 usbhid hid ast uio_pdrv_genirq syscopyarea uio 
sysfillrect sysimgblt nouveau ttm drm_kms_helper drm i2c_algo_bit mlx4_en vxlan 
ip6_udp_tunnel udp_tunnel uas usb_storage bnx2x mlx4_core lpfc ahci libahci 
scsi_transport_fc mdio libcrc32c [last unloaded: ltp_block_dev]
  [  175.365663] CPU: 133 PID: 4832 Comm: block_dev Tainted: GW  OE  
3.19.0-26-generic #27~14.04.1-Ubuntu
  [  175.365666] task: c00fcebc9140 ti: c00fcec1c000 task.ti: 
c00fcec1c000
  [  175.365669] NIP: c04eb5cc LR: c04eb574 CTR: 
c04eb520
  [  175.365671] REGS: c00fcec1f940 TRAP: 0700   Tainted: GW  OE   
(3.19.0-26-generic)
  [  175.365673] MSR: 90029033   CR: 28000482  
XER: 2000
  [  175.365681] CFAR: c04eb59c SOFTE: 1 
  [  175.365681] GPR00: c04eb574 c00fcec1fbc0 c144cc00 
 
  [  175.365681] GPR04: d000190b12c8 000d 636f6c62 
0001 
  [  175.365681] GPR08: c174db10  c174db10 
d000190b10d0 
  [  175.365681] GPR12: c04eb520 c7baad00  
 
  [  175.365681] GPR16:    
 
  [  175.365681] GPR20:  1000a8a8 10020010 
1000a8f0 
  [  175.365681] GPR24: 1000a918 1000a9b8 00fb 
0001 
  [  175.365681] GPR28: d000190b12c8 c1379468  
 
  [  175.365712] NIP [c04eb5cc] unregister_blkdev+0xac/0x160
  [  175.365714] LR [c04eb574] unregister_blkdev+0x54/0x160
  [  175.365716] Call Trace:
  [  175.365719] [c00fcec1fbc0] [c04eb574] 
unregister_blkdev+0x54/0x160 (unreliable)
  [  175.365723] [c00fcec1fc00] [d000190b063c] sys_tcase+0x41c/0xb30 
[ltp_block_dev]
  [  175.365728] [c00fcec1fcc0] [c06431f8] dev_attr_store+0x68/0xa0
  [  175.365732] [c00fcec1fd00] [c035ba30] sysfs_kf_write+0x80/0xb0
  [  175.365735] [c00fcec1fd40] [c035a97c] 
kernfs_fop_write+0x18c/0x1f0
  [  175.365739] [c00fcec1fd90] [c02b488c] vfs_write+0xdc/0x260
  [  175.365743] [c00fcec1fde0] [c02b573c] SyS_write+0x6c/0x110
  [  175.365747] [c00fcec1fe30] [c0009258] system_call+0x38/0xd0
  [  175.365748] Instruction dump:
  [  175.365750] 419e0030 80e90008 7f87f000 409e0018 48c0 815f0008 7f8af000 
419e0058 
  [  175.365756] 7fe9fb78 ebe9 2fbf 409effe8 <0fe0> 7fa3eb78 
3be0 48528871 
  [  175.365761] ---[ end trace 02836eb1f955a5cd ]---

   
  Oops output:
   no
   
  System Dump Info:
The system is not configured to capture a system dump.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1486152/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677297] Re: [Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

Timur found that the at803x module (needed for an erratum) is the reason
we are unable to get a dhcp lease on the emac interface. He is exploring
his options on fixing the issue, ie have a an option to pass in a phy
driver if the erratum is encountered. We found that on my SDP we did not
need the at803x module, and that the qcom_emac was able to use the
generic phy to come up and get dhcp leases.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677297

Title:
  [Zesty] d-i: replace msm_emac with qcom_emac

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  We landed a patch to support msm_emac module in initrd for amberwing 
platforms. But the upstream driver has since been renamed to qcom_emac. This 
module is needed in d-i's initrd so that these nics can be used to d-i install 
the system. The driver already exists in the zesty kernel under 
drivers/net/ethernet/qualcomm/emac/

  Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add
  qcom_emac to initrd, and change the module name to qcom_emac.

  [Test Case]
  D-I install zesty on amberwing platform and notice that DI does not recognize 
the onboard two port nic.

  [Regression Potential]
  At present this driver applies only to amberwing systems, any regression will 
be isolated to amberwing platforms. The over all risk of regression is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1689365] Re: ibmvscsis: Do not send aborted task response

[Manoj Iyer]

I got the following review comments for SRU from kernel team. IBM could
you please comment?

Looking at upstream 4.9.y, I see the patches to the ibmvscsis driver [2-4]
applied but not the change to the genric target driver. And I am not seeing any
justification why patch #1 is strictly required.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1689365

Title:
  ibmvscsis: Do not send aborted task response

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  ibmvscsis: Do not send aborted task response

  The driver is sending a response to the actual scsi op that was
  aborted by an abort task TM, while LIO is sending a response to
  the abort task TM.

  ibmvscsis_tgt does not send the response to the client until
  release_cmd time. The reason for this was because if we did it
  at queue_status time, then the client would be free to reuse the
  tag for that command, but we're still using the tag until the
  command is released at release_cmd time, so we chose to delay
  sending the response until then. That then caused this issue, because
  release_cmd is always called, even if queue_status is not.

  SCSI spec says that the initiator that sends the abort task
  TM NEVER gets a response to the aborted op and with the current
  code it will send a response. Thus this fix will remove that response
  if the CMD_T_ABORTED && !CMD_T_TAS.

  Another case with a small timing window is the case where if LIO sends a
  TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
  cmd before the release_cmd for the (attemped) aborted cmd, then we need to
  ensure that we send the response for the (attempted) abort cmd to the client
  before we send the response for the TMR Abort cmd.

  [Test Case]
  As per comment #11, this requires sending manual abort signals to trigger the 
bug.

  [Fix]
  ibmvscsis: Fix the incorrect req_lim_delta
  ibmvscsis: Clear left-over abort_cmd pointers
  ibmvscsis: Do not send aborted task response
  target: Fix unknown fabric callback queue-full errors

  [Regression Potential]
  Patches are confined to ibmvscsi driver and target driver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1689365/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1680349] Re: Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine crashes while running stress-ng.

[Manoj Iyer]

** Tags added: triage-a

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1680349

Title:
  Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine
  crashes while running stress-ng.

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2017-03-10 02:43:10 ==
  ---Problem Description---

  Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine
  crashes while running stress-ng. Machine hangs.

  ---Steps to Reproduce---

  1. Configure kdump.
  2. Install stress-ng
  # apt-get install stress-ng
  3. Run stress-ng
  # stress-ng - a 0

  
  Logs:
  
  root@ltc-firep3:~# kdump-config load
  Modified cmdline:root=UUID=8b0d5b99-6087-4f40-82ea-375c83a4c139 ro quiet 
splash irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service 
ata_piix.prefer_ms_hyperv=0 elfcorehdr=155200K 
   * loaded kdump kernel
  root@ltc-firep3:~# kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.10.0-11-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.10.0-11-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=8b0d5b99-6087-4f40-82ea-375c83a4c139 ro quiet splash 
irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service 
ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img 
/var/lib/kdump/vmlinuz
  root@ltc-firep3:~# stress-ng -a 0
  stress-ng: info:  [3900] defaulting to a 86400 second run per stressor
  stress-ng: info:  [3900] dispatching hogs: 160 af-alg, 160 affinity, 160 aio, 
160 aiol, 160 apparmor, 160 atomic, 160 bigheap, 160 brk, 160 bsearch, 160 
cache, 160 cap, 160 chdir, 160 chmod, 160 chown, 160 chroot, 160 clock, 160 
clone, 160 context, 160 copy-file, 160 cpu, 160 cpu-online, 160 crypt, 160 
daemon, 160 dccp, 160 dentry, 160 dir, 160 dirdeep, 160 dnotify, 160 dup, 160 
epoll, 160 eventfd, 160 exec, 160 fallocate, 160 fanotify, 160 fault, 160 
fcntl, 160 fiemap, 160 fifo, 160 filename, 160 flock, 160 fork, 160 fp-error, 
160 fstat, 160 full, 160 futex, 160 get, 160 getdent, 160 getrandom, 160 
handle, 160 hdd, 160 heapsort, 160 hsearch, 160 icache, 160 icmp-flood, 160 
inotify, 160 io, 160 iomix, 160 ioprio, 160 itimer, 160 kcmp, 160 key, 160 
kill, 160 klog, 160 lease, 160 link, 160 locka, 160 lockbus, 160 lockf, 160 
lockofd, 160 longjmp, 160 lsearch, 160 madvise, 160 malloc, 160 matrix, 160 
membarrier, 160 memcpy, 160 memfd, 160 mergesort, 160 mincore, 160 mknod, 160 
mlock, 1
 60 mmap, 160 mmapfork, 160 mmapmany, 160 mq, 160 mremap, 160 msg, 160 msync, 
160 netlink-proc, 160 nice, 160 nop, 160 null, 160 numa, 160 oom-pipe, 160 
opcode, 160 open, 160 personality, 160 pipe, 160 poll, 160 procfs, 160 pthread, 
160 ptrace, 160 pty, 160 qsort, 160 quota, 160 rdrand, 160 readahead, 160 
remap, 160 rename, 160 resources, 160 rlimit, 160 rmap, 160 rtc, 160 
schedpolicy, 160 sctp, 160 seal, 160 seccomp, 160 seek, 160 sem, 160 sem-sysv, 
160 sendfile, 160 shm, 160 shm-sysv, 160 sigfd, 160 sigfpe, 160 sigpending, 160 
sigq, 160 sigsegv, 160 sigsuspend, 160 sleep, 160 sock, 160 sockfd, 160 
sockpair, 160 spawn, 160 splice, 160 stack, 160 stackmmap, 160 str, 160 stream, 
160 switch, 160 symlink, 160 sync-file, 160 sysfs, 160 sysinfo, 160 tee, 160 
timer, 160 timerfd, 160 tlb-shootdown, 160 tmpfs, 160 tsc, 160 tsearch, 160 
udp, 160 udp-flood, 160 unshare, 160 urandom, 160 userfaultfd, 160 utime, 160 
vecmath, 160 vfork, 160 vforkmany, 160 vm, 160 vm-rw, 160 vm-splice, 160 wait, 1
 60 wcs, 160 xattr, 160 yield, 160 zero, 160 zlib, 160 zombie
  stress-ng: info:  [3900] cache allocate: using built-in defaults as unable to 
determine cache details
  stress-ng: info:  [3900] cache allocate: default cache size: 2048K
  stress-ng: info:  [3907] stress-ng-atomic: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [3955] stress-ng-exec: running as root, won't run test.
  stress-ng: info:  [3999] stress-ng-icache: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [4040] stress-ng-lockbus: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [4313] stress-ng-numa: system has 2 of a maximum 256 memory 
NUMA nodes
  stress-ng: info:  [4455] stress-ng-rdrand: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: fail:  [4558] stress-ng-rtc: ioctl RTC_ALRM_READ failed, errno=22 
(Invalid argument)
  stress-ng: fail:  [4017] stress-ng-key: keyctl KEYCTL_DESCRIBE failed, 
errno=127 (Key has expired)
  stress-ng: fail:  [4017] 

[Kernel-packages] [Bug 1676884] Re: kdump-tools uses the wrong crashkernel command line parameter in ppc64le

[Manoj Iyer]

** Tags added: triage-a

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1676884

Title:
  kdump-tools uses the wrong crashkernel command line parameter in
  ppc64le

Status in The Ubuntu-power-systems project:
  New
Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile package in Debian:
  New

Bug description:
  == Comment: #0 - Thiago Jung Bauermann  - 2017-03-24 
11:44:39 ==
  ---Problem Description---
  kdump-tools uses the wrong crashkernel command line parameter in ppc64le:

  u1704le?? grep crashkernel /boot/grub/grub.cfg
  linux   /boot/vmlinux-4.10.0-13-generic 
root=UUID=2d6f73c7-b463-4f02-9ec4-8d4afed0635d ro   crashkernel=384M-:128M

  128M of reserved memory is too small for ppc64le.

  That happens because /etc/default/grub.d/kdump-tools.cfg links to the
  wrong file:

  u1704le??  ls -l /etc/default/grub.d/
  total 8.0K
  lrwxrwxrwx 1 root root  39 Mar 24 13:34 kdump-tools.cfg -> 
/etc/default/grub.d/kdump-tools.default
  -rw-r--r-- 1 root root  80 Jan  5 08:07 kdump-tools.default
  -rw-r--r-- 1 root root 137 Jan  5 08:07 kdump-tools..ppc64el
  u1704le?? 

  As can be seen, it should be pointing to kdump-tools..ppc64el but
  isn't.

  Also, kdump-tools..ppc64el has two dots in it. That doesn't seem right.
  Possibly just a cosmetic issue, but it would be nice if that was fixed.
   
  Contact Information = thiag...@br.ibm.com 
   
  ---uname output---
  Linux u1704le 4.10.0-13-generic #15-Ubuntu SMP Thu Mar 9 20:27:28 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = Any ppc64le machine. In this case, a KVM guest hosted on an 
8286-42A. 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   sudo apt intall kdump-tools
  Select 'Yes' when asked whether kdump should be enabled.
   
  Userspace tool common name: kdump 
   
  The userspace tool has the following bit modes: 64 bit 

  Userspace rpm: kdump-tools

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for thiag...@br.ibm.com:
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1676884/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1678745] Re: Ubuntu17.04 KVM: Guest crashed @ xfs_perag_get_tag+0x6c

[Manoj Iyer]

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1678745

Title:
  Ubuntu17.04 KVM: Guest crashed @ xfs_perag_get_tag+0x6c

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Lata Kuntal  - 2017-03-30 09:44:23 ==
  Ubuntu 17.04 KVM guest gusg8 was having ubuntu 16.04.2 and was running stress 
test IO, Base,TCP and NFS.The guest is having XFS as rootFS and after running 
few hours of regression test it dropped at xmon.

  Console logs :
  
  root@guskvm:~# virsh console gusg8 --force
  Connected to domain gusg8
  Escape character is ^]

  
  1:mon> r
  R00 = d288edf4   R16 = 024200ca
  R01 = c000378cb1f0   R17 = 
  R02 = d2936080   R18 = 0020
  R03 = 0001   R19 = c002734d1800
  R04 = c000378cb190   R20 = 
  R05 =    R21 = 
  R06 = 3c00d03fe056   R22 = c0027e26ccf0
  R07 =    R23 = 
  R08 = c48492d0   R24 = 
  R09 = 3c00d03fe056   R25 = 
  R10 = 3c00d03fe062   R26 = 00024df4cd49
  R11 = d28fa360   R27 = 
  R12 =    R28 = d28ac7b0
  R13 = cfb80900   R29 = c4849000
  R14 =    R30 = 
  R15 = c137ad08   R31 = 
  pc  = d288ee0c xfs_perag_get_tag+0x6c/0x170 [xfs]
  cfar= c096a494 perf_trace_mmc_request_start+0x104/0x440
  lr  = d288edf4 xfs_perag_get_tag+0x54/0x170 [xfs]
  msr = 80010280b033   cr  = 82428424
  ctr = c05e4950   xer = 2000   trap =  300
  dar = 3c00d03fe062   dsisr = 4000
  1:mon> t
  [c000378cb250] d28ac7b0 xfs_reclaim_inodes_count+0x70/0xa0 [xfs]
  [c000378cb290] d28c0ea8 xfs_fs_nr_cached_objects+0x28/0x40 [xfs]
  [c000378cb2b0] c03292d8 super_cache_count+0x68/0x120
  [c000378cb2f0] c0271530 shrink_slab.part.14+0x150/0x4f0
  [c000378cb430] c0276db8 shrink_node+0x158/0x3f0
  [c000378cb4f0] c0277178 do_try_to_free_pages+0x128/0x460
  [c000378cb590] c02775ac try_to_free_pages+0xfc/0x280
  [c000378cb620] c0260158 __alloc_pages_nodemask+0x758/0xe30
  [c000378cb7e0] c02dbb98 alloc_pages_vma+0x108/0x360
  [c000378cb880] c029d080 wp_page_copy+0xf0/0x9d0
  [c000378cb920] c02a0770 do_wp_page+0x210/0xb20
  [c000378cb9b0] c02a656c handle_mm_fault+0x9cc/0x14c0
  [c000378cba60] c0b511a0 do_page_fault+0x260/0x7d0
  [c000378cbb10] c0008948 handle_page_fault+0x10/0x30
  --- Exception: 301 (Data Access) at c010aec4 schedule_tail+0x84/0xb0
  [c000378cbe30] c0009844 ret_from_fork+0x4/0x54
  --- Exception: c00 (System Call) at 3fffa2b5bf44
  1:mon> d
      ||
  1:mon> c
  cpus stopped: 0x0-0x3
  1:mon>

  Kernel host build
  =
  root@guskvm:~# uname -r
  4.10.0-13-generic
  root@guskvm:~#

  
  == Comment: #1 - Luciano Chavez  - 2017-03-30 10:42:15 ==
  At first glance, based on the following assembly from around the failure 
point:

  d288edd4  38c1  li  r6,1
  d288edd8  7f8802a6  mflrr28
  d288eddc  78a70020  clrldi  r7,r5,32
  d288ede0  7c7d1b78  mr  r29,r3
  d288ede4  7c852378  mr  r5,r4
  d288ede8  386302c8  addir3,r3,712
  d288edec  38810020  addir4,r1,32
  d288edf0  4806b571  bl  d28fa360# 
exit_xfs_fs+0x180c/0xfd44 [xfs]
  d288edf4  e8410018  ld  r2,24(r1)
  d288edf8  2f83  cmpwi   cr7,r3,0
  d288edfc  409d0104  ble cr7,d288ef00# 
xfs_perag_get_tag+0x160/0x170 [xfs]
  d288ee00  7c0004ac  sync
  d288ee04  e9210020  ld  r9,32(r1)
  d288ee08  3949000c  addir10,r9,12
  d288ee0c  7fc05028  lwarx   r30,0,r10
  d288ee10  33de0001  addic   r30,r30,1
  d288ee14  7fc0512d  stwcx.  r30,0,r10

  I believe the crash in fs_perag_get_tag() is after we come back from
  the radix_tree_gang_lookup_tag() call and are attempting the
  atomic_inc_return() and struct xfs_perag*pag is R09 =
  3c00d03fe056 which is invalid.

   85 rcu_read_lock();  
 
   86 found = radix_tree_gang_lookup_tag(>m_perag_tree, 
 
   87 (void **), first, 1, tag);

[Kernel-packages] [Bug 1680888] Re: Disable CONFIG_HVC_UDBG on ppc64el

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1680888

Title:
  Disable CONFIG_HVC_UDBG on ppc64el

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Yakkety:
  Won't Fix
Status in linux source package in Zesty:
  Fix Released

Bug description:
  Canonical,

  Could you please disable CONFIG_HVC_UDBG on ppc64el config?

  This is not required, and it is causing some extra timing on the TTY
  device that is causing some racing condition that is still being
  debugged

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1680888/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1677685] Re: [SRU Zesty] Target: Configfs Crashes and kernel crash fixes

[Manoj Iyer]

** Tags added: triage-g

** Changed in: ubuntu-power-systems
   Status: Incomplete => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1677685

Title:
  [SRU Zesty] Target: Configfs Crashes and kernel crash fixes

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  A number of patches that need to be backported for target subsystem.

  target: Don't BUG_ON during NodeACL dynamic -> explicit conversion
  https://patchwork.kernel.org/patch/9560085/

  target: Use correct SCSI status during EXTENDED_COPY exception
  https://patchwork.kernel.org/patch/9560083/

  target: Fix early transport_generic_handle_tmr abort scenario
  https://patchwork.kernel.org/patch/9560077/

  target: Fix multi-session dynamic se_node_acl double free OOPs
  https://patchwork.kernel.org/patch/9560081/

  target: Fix COMPARE_AND_WRITE ref leak for non GOOD status
  https://patchwork.kernel.org/patch/9560065/

  target: Fix NULL dereference during LUN lookup + active I/O shutdown
  https://patchwork.kernel.org/patch/9587799/

  target: Avoid mappedlun symlink creation during lun shutdown
  https://lkml.org/lkml/2017/3/30/180

   
  Contact Information = Bryant G. Ly/b...@us.ibm.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1677685/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1681909] Re: Ubuntu 17.04: dump is not captured in remote host when kdump over ssh is configured on firestone.

[Manoj Iyer]

** Tags added: triage-a

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1681909

Title:
  Ubuntu 17.04: dump is not captured in remote host when kdump over ssh
  is configured on firestone.

Status in The Ubuntu-power-systems project:
  New
Status in makedumpfile package in Ubuntu:
  New

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH  - 2017-03-07 
05:00:29 ==
  ---Problem Description---

  Ubuntu 17.04: dump is not captured in remote host when kdump over ssh
  is configured on firestone.

  ---Steps to Reproduce---

  1. Configure kdump.
  2. Check whether kdump is operational using ?# kdump-config show?.
  3. Install ?kernel-debuginfo? and ?kernel-debuginfo-common? rpms.
  4. Setup password less ssh connection, generate rsa key.
  # ssh-keygen -t rsa
  5. verify id_rsa and id_rsa.pub are created under /root/.ssh/
  6. Edit /etc/default/kdump-tools and add below entries.
  SSH="ubuntu@9.114.15.239"
  SSH_KEY=/root/.ssh/id_rsa
  7. Propagate RSA key.
  # kdump-config propagate
  8. Restart kdump service.
  # kdump-config load
  9. Trigger Crash using below commands.
  # echo "1" > /proc/sys/kernel/sysrq
  # echo "c" > /proc/sysrq-trigger
  10. Verify dump is available in remote server in configured path.

  Machine details
  ===

  $ ipmitool -I lanplus -H  9.47.70.3 -U ADMIN -P admin sol activate

  $ ssh ubuntu@9.47.70.29

  PW: shriya101

  
  Attaching logs

  == Comment: #1 - PAVITHRA R. PRAKASH  -
  2017-03-07 05:01:42 ==

  
  == Comment: #5 - PAVITHRA R. PRAKASH  - 2017-03-07 
23:19:46 ==
  Hi, 

  Attaching the logs.

  Network info:

  root@ltc-firep3:~# hwinfo --network
  36: None 00.0: 10700 Loopback   
[Created at net.126]
Unique ID: ZsBS.GQNx7L4uPNA
SysFS ID: /class/net/lo
Hardware Class: network interface
Model: "Loopback network interface"
Device File: lo
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown

  37: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: 2lHw.ndpeucax6V1
Parent ID: mIXc.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f2
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.2
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f2
HW Address: 98:be:94:03:18:4a
Permanent HW Address: 98:be:94:03:18:4a
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #15 (Ethernet controller)

  38: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: 7Onn.ndpeucax6V1
Parent ID: sx0U.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f0
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.0
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f0
HW Address: 98:be:94:03:18:48
Permanent HW Address: 98:be:94:03:18:48
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #16 (Ethernet controller)

  39: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: VwX_.ndpeucax6V1
Parent ID: DUng.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f3
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.3
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f3
HW Address: 98:be:94:03:18:4b
Permanent HW Address: 98:be:94:03:18:4b
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #25 (Ethernet controller)

  40: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: bZ1s.ndpeucax6V1
Parent ID: J7HY.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f1
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.1
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f1
HW Address: 98:be:94:03:18:49
Permanent HW Address: 98:be:94:03:18:49
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #4 (Ethernet controller)
  root@ltc-firep3:~# 


  Thanks,
  Pavithra

  == Comment: #6 - PAVITHRA R. PRAKASH  -
  2017-03-07 23:20:47 ==

  
  == Comment: #7 - PAVITHRA R. PRAKASH  - 2017-03-07 
23:21:27 ==

  
  == Comment: #8 - Urvashi Jawere  - 2017-03-08 02:48:15 ==
  I am able to see some errors in syslog ;

  auxiliary
  Mar  7 04:57:44 ltc-firep3 

[Kernel-packages] [Bug 1706247] Re: It should not be possible to turn on 16g huge pages on Ubuntu 16.04.2 PowerNV

[Manoj Iyer]

** Summary changed:

- Possible to turn on 16g huge pages on Ubuntu 16.04.2 PowerNV
+ It should not be possible to turn on 16g huge pages on Ubuntu 16.04.2 PowerNV

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1706247

Title:
  It should not be possible to turn on 16g huge pages on Ubuntu 16.04.2
  PowerNV

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  Triaged

Bug description:
  16G Huge Pages are not supported on PowerNV (bare metal) installations. 
Ubuntu 16.04.2 still allows 16G huge pages to be turned on.
   
  Contact Information = Mike Hollinger (mchol...@us.ibm.com) 
   
  ---uname output---
  Linux aprilmin4 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:53:54 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8335-GTB 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Add the following to the kernel boot args (either via editing the 
petitboot boot option manually, or updating /boot/grub/grub.cfg:

  default_hugepagesz=16G hugepagesz=16G hugepages=4

  2. Boot Linux
  3. Observe that the kernel believes 16G huge pages are available:
  ubuntu@aprilmin7:~$ cat /proc/meminfo | grep -i huge
  AnonHugePages:475136 kB
  HugePages_Total:   0
  HugePages_Free:0
  HugePages_Rsvd:0
  HugePages_Surp:0
  Hugepagesize:   16777216 kB
  ubuntu@aprilmin7:~$ ls /sys/devices/system/node/node0/hugepages
  hugepages-1024kB  hugepages-16384kB  hugepages-16777216kB

   
  Stack trace output:
   no
   
  Oops output:
   no
   
  System Dump Info:
The system is not configured to capture a system dump.
   
  *Additional Instructions for Mike Hollinger (mchol...@us.ibm.com): 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.

  
  This may be recreated on any bare metal POWER8 server with Ubuntu 16.04.2; I 
haven't checked other versions of Ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706247/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1689946] Re: Ubuntu16.04: NVMe 4K+T10 DIF/DIX format returns I/O error on dd with split op

[Manoj Iyer]

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1689946

Title:
  Ubuntu16.04: NVMe 4K+T10 DIF/DIX format returns I/O error on dd with
  split op

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  Won't Fix
Status in linux source package in Zesty:
  In Progress
Status in linux source package in Artful:
  Fix Committed

Bug description:
   State: Open by: mdate on 19 March 2017 12:33:34 

  On a Bolt adapter in a system with Ubuntu 16.04, I've formatted the
  Bolt for T10 and am using it to do a dd with a 2M block size.

  Here are the commands:
  nvme format /dev/nvme0n1 --lbaf=1 --pil=0 --ms=0 --pi=2

  dd if=/dev/urandom of=/dev/nvme0n1 bs=2M oflag=direct count=1

  I get an error on the dd.
root@x1623bp1:~# dd if=/dev/urandom of=/dev/nvme0n1 bs=2M oflag=direct 
count=1
dd: error writing '/dev/nvme0n1': Input/output error
1+0 records in
0+0 records out
0 bytes copied, 0.0525061 s, 0.0 kB/s

  dmesg shows:
  [589997.985151] blk_update_request: I/O error, dev nvme0n1, sector 0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1689946/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1685899] Re: [Ubuntu 17.04] - JFS related call traces and system enters xmon when rebooted after installation

[Manoj Iyer]

** Changed in: linux (Ubuntu)
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => 
Canonical Kernel Team (canonical-kernel-team)

** Changed in: linux (Ubuntu)
   Status: New => Incomplete

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1685899

Title:
  [Ubuntu 17.04] - JFS related call traces and system enters xmon when
  rebooted after installation

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Issue:
  
  JFS related call traces and system enters xmon when rebooted after 
installation 

  Steps to reproduce:
  -
  1 - Install Ubuntu 17.04 the system with 
   - prepboot
  - /root [JFS filesystem]
  - swap space

  2 -After installation when rebooted it gives out call traces like as
  below:

  [3.895246] Unable to handle kernel paging request for data at address 
0x
  [3.895278] Faulting instruction address: 0xd4c5df1c
  [3.895284] Oops: Kernel access of bad area, sig: 11 [#1]
  [3.895287] SMP NR_CPUS=2048 [3.895288] NUMA 
  [3.895290] pSeries
  [3.895292] Modules linked in: ip_tables x_tables autofs4 jfs ibmvscsi 
crc32c_vpmsum
  [3.895301] CPU: 30 PID: 923 Comm: ureadahead Not tainted 4.9.0-15-generic 
#16-Ubuntu
  [3.895304] task: c00381d3c800 task.stack: c00381fd
  [3.895307] NIP: d4c5df1c LR: d4c5deb0 CTR: 
c01279d0
  [3.895310] REGS: c00381fd3500 TRAP: 0300   Not tainted  
(4.9.0-15-generic)
  [3.895313] MSR: 8280b033 [
3.895322]   CR: 48008804  XER: 0001
  [3.895324] CFAR: c0008a60 DAR:  DSISR: 4000 
SOFTE: 1 
  GPR00: d4c5deb0 c00381fd3780 d4c78c28 c003802f40f0 
  GPR04: d4c6f6f0 d4c72b58 0563 d4c78c28 
  GPR08:  00180e97  d4c6a608 
  GPR12: c01279d0 cfb90e00   
  GPR16:     
  GPR20:     
  GPR24:  1000  d4c72b38 
  GPR28: 00180e97 f0e1d5c0 c003812af240 c003802f40b0 
  NIP [d4c5df1c] __get_metapage+0x204/0x6f0 [jfs]
  [3.895372] LR [d4c5deb0] __get_metapage+0x198/0x6f0 [jfs]
  [3.895374] Call Trace:
  [3.895378] [c00381fd3780] [d4c5de6c] 
__get_metapage+0x154/0x6f0 [jfs] (unreliable)
  [3.895384] [c00381fd3870] [d4c4c368] diRead+0x130/0x260 [jfs]
  [3.895388] [c00381fd3920] [d4c424f4] jfs_iget+0x6c/0x1e0 [jfs]
  [3.895393] [c00381fd3950] [d4c43adc] jfs_lookup+0xe4/0x100 
[jfs]
  [3.895398] [c00381fd3a80] [c032a120] lookup_slow+0xe0/0x240
  [3.895402] [c00381fd3b00] [c032e8a8] 
walk_component+0x2d8/0x3f0
  [3.895406] [c00381fd3b70] [c032eb94] 
link_path_walk+0x1d4/0x600
  [3.895409] [c00381fd3c00] [c0330c1c] path_openat+0xbc/0x480
  [3.895413] [c00381fd3c80] [c03328ac] do_filp_open+0xec/0x160
  [3.895417] [c00381fd3db0] [c031863c] do_sys_open+0x1cc/0x380
  [3.895421] [c00381fd3e30] [c000bd84] system_call+0x38/0xe0
  [3.895424] Instruction dump:
  [3.895426] 7909f00e 7fc9f214 3921 f93f0028 fbdf0030 e93d 71280800 
41820460 
  [3.895433] ebdd0030 41920034 e91d0008 e93f0038  811e 
80e70090 39080001 
  [3.895441] ---[ end trace c2aa9ba09ea05eac ]---
  [3.895443] 
  [4.088560] systemd-journald[925]: Received request to flush runtime 
journal from PID 1
  [4.362062] crypto_register_alg 'aes' = 0
  [4.362112] crypto_register_alg 'cbc(aes)' = 0
  [4.362150] crypto_register_alg 'ctr(aes)' = 0
  [4.362191] crypto_register_alg 'xts(aes)' = 0
  [4.366949] pseries_rng: Registering IBM pSeries RNG driver

  When I first connected to the LPAR, it was unresponsive so I restarted
  it from the HMC and surprisingly it came up to the login prompt and I
  logged into the shell. I proceeded to install the matching linux-
  image-4.10.0-15-generic-dbgsym_4.10.0-15.17_ppc64el.ddeb. However, the
  installation of the matching dbgsym wasn't as helpful as I wanted it
  to be. objdump, crash tool, or addr2line wouldn't give me the source
  line correspond to the NIP address.

  I then restarted the LPAR with xmon enabled and it would drop to xmon
  immediately after attempting to remount / and at the same location as
  before at __get_metapage+0x204/0x6f0 [jfs] and again with a
  dereference of 0x0 as the cause of the data exception

  0xd649df54 

[Kernel-packages] [Bug 1684054] Re: [LTCTest][Opal][FW860.20] HMI recoverable errors failed to recover and system goes to dump state.

[Manoj Iyer]

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1684054

Title:
  [LTCTest][Opal][FW860.20] HMI recoverable errors failed to recover and
  system goes to dump state.

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Zesty:
  New

Bug description:
  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-04-17 
06:08:41 ==
  ---Problem Description---
  HMI Recoverable error injection tests leads to system checkstop followed by 
system dump with ubuntu 17.04 os and kernel 4.10.0-19-generic ppc64le
   
  Contact Information = ppaid...@in.ibm.com 
   
  ---uname output---
  #21-Ubuntu SMP Thu Apr 6 17:03:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = PowerNV 8284-22A 
   
  ---System Hang---
   System is in dumping state. after dump finishes system will IPL to OS again.
   
  ---Debugger---
  A debugger is not configured
   

  == Comment: #3 - Pridhiviraj Paidipeddi  - 2017-04-17 
06:12:51 ==
  # uname -a
  #21-Ubuntu SMP Thu Apr 6 17:03:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
  # cat /etc/os-release 
  NAME="Ubuntu"
  VERSION="17.04 (Zesty Zapus)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 17.04"
  VERSION_ID="17.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=zesty
  UBUNTU_CODENAME=zesty
  root@p8wookie:~#

  == Comment: #4 - Kevin W. Rudd  - 2017-04-17
  11:10:22 ==

  
  == Comment: #5 - MAHESH J. SALGAONKAR  - 
2017-04-17 13:34:03 ==
  it looks like below commit is a culprit:

  ===
  commit 2337d207288f163e10bd8d4d7eeb0c1c75046a0c
  Author: Nicholas Piggin 
  Date:   Fri Jan 27 14:24:33 2017 +1000

  powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts
  
  The branch from hmi_exception_early to hmi_exception_realmode must use
  a "relocatable-style" branch, because it is branching from unrelocated
  exception code to beyond __end_interrupts.
  
  Signed-off-by: Nicholas Piggin 
  Signed-off-by: Michael Ellerman 
  ===

  With the above commit changes now hmi_exception_realmode() is called
  using bctrl which ends up messing up TOC (r2) value and further access
  using new r2 results into unpredictable behaviour.

  
  c0025f50 :
  c0025f50:   3a 01 4c 3c addis   r2,r12,314
  c0025f54:   b0 01 42 38 addir2,r2,432
  c0025f58:   a6 02 08 7c mflrr0
  -

  With above commit the hmi_exception_early() code jumps to
  c0025f50 (hmi_exception_realmode+0x0)  which then sets up new
  value for r2.

  If we revert above commit the code jumps to c0025f58
  (hmi_exception_realmode+0x8) and hmi handler works fine.

  After reverting above patch I don't see this issue anymore. I have
  rebuilt the ubuntu kernel after reverting above patch and you can find
  the kernel rpm at:

  Can you please retry your tests with above kernel and see if issue
  still persists.

  == Comment: #6 - MAHESH J. SALGAONKAR  - 
2017-04-17 23:02:31 ==
  Spoke to Michael Ellerman this morning. He helped me to identify the root 
cause and a fix patch beow:

  diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
  index 857bf7c5b946..7cfeb8768587 100644
  --- a/arch/powerpc/kernel/exceptions-64s.S
  +++ b/arch/powerpc/kernel/exceptions-64s.S
  @@ -982,7 +982,7 @@ TRAMP_REAL_BEGIN(hmi_exception_early)
EXCEPTION_PROLOG_COMMON_2(PACA_EXGEN)
EXCEPTION_PROLOG_COMMON_3(0xe60)
addir3,r1,STACK_FRAME_OVERHEAD
  - BRANCH_LINK_TO_FAR(r4, hmi_exception_realmode)
  + BRANCH_LINK_TO_FAR(r12, hmi_exception_realmode)
/* Windup the stack. */
/* Move original HSRR0 and HSRR1 into the respective regs */
ld  r9,_MSR(r1)

  == Comment: #7 - Pridhiviraj Paidipeddi  -
  2017-04-18 01:52:03 ==

  
  == Comment: #8 - Pridhiviraj Paidipeddi  - 2017-04-18 
01:53:57 ==
  Hi Mahesh
  Tested all the HMI Recoverable errors on the below patched kernel, attached 
the corresponding executing logs. All tests are working fine.

  #21 SMP Mon Apr 17 12:58:30 EDT 2017 ppc64le ppc64le ppc64le GNU/Linux

  
  Thanks

  == Comment: #9 - MAHESH J. SALGAONKAR  - 
2017-04-18 06:07:56 ==
  (In reply to comment #8)
  > Hi Mahesh
  > Tested 

[Kernel-packages] [Bug 1686019] Re: Ubuntu 16.04.3: Qemu fails on P9

[Manoj Iyer]

** Changed in: kernel-package (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Ubuntu on IBM Power 
Systems Bug Triage (ubuntu-power-triage)

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1686019

Title:
  Ubuntu 16.04.3: Qemu fails on P9

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in kernel-package package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Committed
Status in kernel-package source package in Zesty:
  New
Status in linux source package in Zesty:
  New

Bug description:
  Trying to start KVM on Ubuntu 16.04.3 with QEMU from dgibson 2.10
  tree[1], I see the following error when trying to boot a 17.04 image.

  8000 DISK : "QEMU QEMU HARDDISK2.5+"
  Populating /pci@8002000
  No NVRAM common partition, re-initializing...
  Scanning USB 
  Using default console: /vdevice/vty@7100
   ted RAM kernel at 40 (17995b0 bytes) C08FF
Welcome to Open Firmware

Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php

  Booting from memory...
  OF stdout device is: /vdevice/vty@7100
  Preparing to boot Linux version 4.10.0-19-generic (buildd@bos01-ppc64el-009) 
(gcc version 6.3.0 20170321 (Ubuntu 6.3.0-10ubuntu1) ) #21-Ubuntu SMP Thu Apr 6 
17:03:05 UTC 2017 (Ubuntu 4.10.0-19.21-generic 4.10.8)
  Detected machine type: 0101
  command line: debug initcall_debug udbg-immortal console=/dev/hvc0
  Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
  Calling ibm,client-architecture-support... done
  memory layout at init:
memory_limit :  (16 MB aligned)
alloc_bottom : 01bb
alloc_top: 1000
alloc_top_hi : 8000
rmo_top  : 1000
ram_top  : 8000
  instantiating rtas at 0x0daf... done
  prom_hold_cpus: skipped
  copying OF device tree...
  Building dt strings...
  Building dt structure...
  Device tree strings 0x041c -> 0x041c09fd
  Device tree struct  0x041d -> 0x041e
  Quiescing Open Firmware ...
  Booting Linux via __start() @ 0x0040 ...

  
  I tried to add some debug options as "debug initcall_debug udbg-immortal 
console=/dev/hvc0" but no luck. 

  [1] https://github.com/dgibson/qemu.git branch ppc-for-2.10
   
  ---uname output---
  4.10.0-19

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1686019/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1689360] Re: TCMU: Fix possible overwrite of t_data_sg's last iov[] and wrongly calculating base_command_size

[Manoj Iyer]

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1689360

Title:
  TCMU: Fix possible overwrite of t_data_sg's last iov[] and wrongly
  calculating base_command_size

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Yakkety:
  Won't Fix

Bug description:
  ---Problem Description---
  If there has BIDI data, its first iov[] will overwrite the last
  iov[] for se_cmd->t_data_sg.

  ---uname output---
  Latest Yakkety master branch
   
  Machine Type = P8 
   
  ---Steps to Reproduce---
   Just have a system do workload using tcmu.
   
  Stack trace output:
   I have seen this in my environment:
  (gdb) print *((tcmulib_cmd->iovec)+0)
  $7 = {iov_base = 0x3fff7c3d, iov_len = 8192}
  (gdb) print *((tcmulib_cmd->iovec)+1)
  $3 = {iov_base = 0x3fff7c3da000, iov_len = 4096}
  (gdb) print *((tcmulib_cmd->iovec)+2)
  $4 = {iov_base = 0x3fff7c3dc000, iov_len = 16384}
  (gdb) print *((tcmulib_cmd->iovec)+3)
  $5 = {iov_base = 0x3fff7c3f7000, iov_len = 12288}
  (gdb) print *((tcmulib_cmd->iovec)+4)
  $6 = {iov_base = 0x1306e853c0028, iov_len = 128}  <--- bad pointer and length 
   
  cmu: Fix wrongly calculating of the base_command_size
  https://patchwork.kernel.org/patch/9687657/

  tcmu: Fix possible overwrite of t_data_sg's last iov[]
  https://patchwork.kernel.org/patch/9687565/

  tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI
  case

  https://patchwork.kernel.org/patch/9655423/

  This patch should also be a part of these fixes. WITH BIDI op fixes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1689360/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1667245] Re: ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

[Manoj Iyer]

** Tags added: triage-a

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1667245

Title:
  ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  After a memory DLPAR removal, kdump doesn't work:

   Starting Kernel crash dump capture service...
  [   67.714593] kdump-tools[3850]: Starting kdump-tools:  * running 
makedumpfile -c -d 31 /proc/vmcore /var/crash/201702230005/dump-incomplete
  Copying data   : [  2.1 %] -/usr/sbin/kdump-config: line 
639:  3897 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [   72.314140] kdump-tools[3850]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [   73.693881] kdump-tools[3850]: cp: error reading '/proc/vmcore': Bad 
address
  [   73.704152] kdump-tools[3850]:  * kdump-tools: failed to save vmcore in 
/var/crash/201702230005
  [   73.823643] kdump-tools[3850]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201702230005/dmesg.201702230005
  [   73.973813] kdump-tools[3850]: The kernel version is not supported.
  [   73.974078] kdump-tools[3850]: The makedumpfile operation may be 
incomplete.
  [   73.983506] kdump-tools[3850]: The dmesg log is saved to 
/var/crash/201702230005/dmesg.201702230005.
  [   73.983752] kdump-tools[3850]: makedumpfile Completed.
  [   73.983998] kdump-tools[3850]:  * kdump-tools: saved dmesg content in 
/var/crash/201702230005
  [   74.104555] kdump-tools[3850]: Thu, 23 Feb 2017 00:05:15 -0600
  [   74.233502] kdump-tools[3850]: Failed to read reboot parameter file: No 
such file or directory
  [   74.233782] kdump-tools[3850]: Rebooting.
  [   86.629777] reboot: Restarting system

  
  The kdump service should be restarted after the memory DLPAR operation.
   
  C
  ---uname output---
  Linux roselp4 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:00:06 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. config kdump on roselp4
  2. do a memory DLPAR removal operation
  3. trigger kdump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1667245/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1664545] Re: In Ubuntu17.04 as Kvm guest : While trigger kdump console hung having call traces

[Manoj Iyer]

** Tags added: triage-a

** Changed in: makedumpfile (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => Ubuntu on IBM Power 
Systems Bug Triage (ubuntu-power-triage)

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1664545

Title:
  In Ubuntu17.04 as Kvm guest  : While trigger kdump console hung having
  call traces

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  New

Bug description:
  In ubuntu17.04 as KVM guest on ubuntu KVM Host and trying kdump on
  guest while kdump process  console got hung having call traces

  
  Reproducible Step:

  1- Install Ubuntu17.04 as kvm guest  on ubuntu kvm host 
  2- configure kdump 
  3- trigger kdump 

  Expected Result :

  Kdump should capture

  Actual Result :

  Kdump console hung having continuous call traces

  LOG:

  [0.488534] Freeing unused kernel memory: 4416K (c8e8 - 
c92d)
  [0.488725] This architecture does not have kernel memory protection.
  Loading, please wait...
  starting version 232
  [0.501616] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.501830] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.501981] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.502162] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.502254] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.502433] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.503188] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.503270] random: udevadm: uninitialized urandom read (16 bytes read)
  [0.503978] random: systemd-udevd: uninitialized urandom read (16 bytes 
read)
  [0.504218] random: systemd-udevd: uninitialized urandom read (16 bytes 
read)
  [  242.663388] INFO: task systemd-udevd:151 blocked for more than 120 seconds.
  [  242.663514]   Not tainted 4.9.0-15-generic #16-Ubuntu
  [  242.663553] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [  242.663755] systemd-udevd   D0   151145 0x00040002
  [  242.663795] Call Trace:
  [  242.663868] [c0001fe4ecd0] [c801c3a0] __switch_to+0x2e0/0x4c0
  [  242.663964] [c0001fe4ed30] [c8b19398] __schedule+0x2f8/0x990
  [  242.664076] [c0001fe4ee10] [c8b19a78] schedule+0x48/0xc0
  [  242.664179] [c0001fe4ee40] [c8b1de54] 
schedule_timeout+0x274/0x470
  [  242.664334] [c0001fe4ef30] [c8b19010] 
io_schedule_timeout+0xd0/0x160
  [  242.664502] [c0001fe4ef80] [c8b1a720] bit_wait_io+0x30/0x90
  [  242.664618] [c0001fe4efb0] [c8b1a168] __wait_on_bit+0xf8/0x170
  [  242.664754] [c0001fe4f000] [c824b238] 
wait_on_page_bit+0x98/0xb0
  [  242.664847] [c0001fe4f060] [c824d60c] 
do_read_cache_page+0x21c/0x4e0
  [  242.665008] [c0001fe4f0d0] [c859be78] 
read_dev_sector+0xb8/0x140
  [  242.665126] [c0001fe4f100] [c85a5d88] 
read_lba.isra.0+0x148/0x250
  [  242.665259] [c0001fe4f170] [c85a652c] efi_partition+0x12c/0x830
  [  242.665363] [c0001fe4f2e0] [c859e768] 
check_partition+0x158/0x2d0
  [  242.665469] [c0001fe4f360] [c859c760] 
rescan_partitions+0xe0/0x390
  [  242.665552] [c0001fe4f430] [c8371828] __blkdev_get+0x358/0x490
  [  242.665669] [c0001fe4f4a0] [c8372b50] blkdev_get+0x1a0/0x4a0
  [  242.665784] [c0001fe4f550] [c8599538] 
device_add_disk+0x4a8/0x500
  [  242.665894] [c0001fe4f600] [d0511cc8] 
virtblk_probe+0x560/0x928 [virtio_blk]
  [  242.665983] [c0001fe4f6c0] [c8687700] 
virtio_dev_probe+0x1d0/0x350
  [  242.666050] [c0001fe4f700] [c8716f30] 
driver_probe_device+0x240/0x540
  [  242.666116] [c0001fe4f790] [c871738c] 
__driver_attach+0x15c/0x160
  [  242.666174] [c0001fe4f810] [c87138ec] 
bus_for_each_dev+0x8c/0xf0
  [  242.666232] [c0001fe4f860] [c87162e4] driver_attach+0x34/0x50
  [  242.666289] [c0001fe4f880] [c8715a78] 
bus_add_driver+0x238/0x380
  [  242.666345] [c0001fe4f910] [c871829c] 
driver_register+0x9c/0x180
  [  242.666403] [c0001fe4f980] [c8686abc] 
register_virtio_driver+0x4c/0x60
  [  242.666470] [c0001fe4f9a0] [d0512114] init+0x84/0xd4 
[virtio_blk]
  [  242.666527] [c0001fe4fa10] [c800dde8] 
do_one_initcall+0x68/0x1d0
  [  242.666584] [c0001fe4fad0] [c8b28e00] do_init_module+0x90/0x244
  [  242.43] [c0001fe4fb60] [c8184794] load_module+0x1614/0x17a0
  [  242.666701]