[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-04-04 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.4.0-119.143

---
linux (4.4.0-119.143) xenial; urgency=medium

  * linux: 4.4.0-119.143 -proposed tracker (LP: #1760327)

  * Dell XPS 13 9360 bluetooth scan can not detect any device (LP: #1759821)
- Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

linux (4.4.0-118.142) xenial; urgency=medium

  * linux: 4.4.0-118.142 -proposed tracker (LP: #1759607)

  * Kernel panic with AWS 4.4.0-1053 / 4.4.0-1015 (Trusty) (LP: #1758869)
- x86/microcode/AMD: Do not load when running on a hypervisor

  * CVE-2018-8043
- net: phy: mdio-bcm-unimac: fix potential NULL dereference in
  unimac_mdio_probe()

linux (4.4.0-117.141) xenial; urgency=medium

  * linux: 4.4.0-117.141 -proposed tracker (LP: #1755208)

  * Xenial update to 4.4.114 stable release (LP: #1754592)
- x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
- usbip: prevent vhci_hcd driver from leaking a socket pointer address
- usbip: Fix implicit fallthrough warning
- usbip: Fix potential format overflow in userspace tools
- x86/microcode/intel: Fix BDW late-loading revision check
- x86/retpoline: Fill RSB on context switch for affected CPUs
- sched/deadline: Use the revised wakeup rule for suspending constrained dl
  tasks
- can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
- can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
- PM / sleep: declare __tracedata symbols as char[] rather than char
- time: Avoid undefined behaviour in ktime_add_safe()
- timers: Plug locking race vs. timer migration
- Prevent timer value 0 for MWAITX
- drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
- drivers: base: cacheinfo: fix boot error message when acpi is enabled
- PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
- PCI: layerscape: Fix MSG TLP drop setting
- mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
- fs/select: add vmalloc fallback for select(2)
- hwpoison, memcg: forcibly uncharge LRU pages
- cma: fix calculation of aligned offset
- mm, page_alloc: fix potential false positive in __zone_watermark_ok
- ipc: msg, make msgrcv work with LONG_MIN
- x86/ioapic: Fix incorrect pointers in ioapic_setup_resources()
- ACPI / processor: Avoid reserving IO regions too early
- ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
- ACPICA: Namespace: fix operand cache leak
- netfilter: x_tables: speed up jump target validation
- netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed
  in 64bit kernel
- netfilter: nf_dup_ipv6: set again FLOWI_FLAG_KNOWN_NH at flowi6_flags
- netfilter: nf_ct_expect: remove the redundant slash when policy name is
  empty
- netfilter: nfnetlink_queue: reject verdict request from different portid
- netfilter: restart search if moved to other chain
- netfilter: nf_conntrack_sip: extend request line validation
- netfilter: use fwmark_reflect in nf_send_reset
- ext2: Don't clear SGID when inheriting ACLs
- reiserfs: fix race in prealloc discard
- reiserfs: don't preallocate blocks for extended attributes
- reiserfs: Don't clear SGID when inheriting ACLs
- fs/fcntl: f_setown, avoid undefined behaviour
- scsi: libiscsi: fix shifting of DID_REQUEUE host byte
- Input: trackpoint - force 3 buttons if 0 button is reported
- usb: usbip: Fix possible deadlocks reported by lockdep
- usbip: fix stub_rx: get_pipe() to validate endpoint number
- usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
- usbip: prevent leaking socket pointer address in messages
- um: link vmlinux with -no-pie
- vsyscall: Fix permissions for emulate mode with KAISER/PTI
- eventpoll.h: add missing epoll event masks
- x86/microcode/intel: Extend BDW late-loading further with LLC size check
- hrtimer: Reset hrtimer cpu base proper on CPU hotplug
- dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
- ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
- ipv6: fix udpv6 sendmsg crash caused by too small MTU
- ipv6: ip6_make_skb() needs to clear cork.base.dst
- lan78xx: Fix failure in USB Full Speed
- net: igmp: fix source address check for IGMPv3 reports
- tcp: __tcp_hdrlen() helper
- net: qdisc_pkt_len_init() should be more robust
- pppoe: take ->needed_headroom of lower device into account on xmit
- r8169: fix memory corruption on retrieval of hardware statistics.
- sctp: do not allow the v4 socket to bind a v4mapped v6 address
- sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
- vmxnet3: repair memory leak
- net: Allow neigh contructor functions ability to modify the primary_key
- ipv4: Make neigh lookup keys for loopback/point-to-point devices be
  INADDR_ANY
   

[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-04-04 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 3.13.0-144.193

---
linux (3.13.0-144.193) trusty; urgency=medium

  * linux: 3.13.0-144.193 -proposed tracker (LP: #1755227)

  * CVE-2017-12762
- isdn/i4l: fix buffer overflow

  * CVE-2017-17807
- KEYS: add missing permission check for request_key() destination

  * bnx2x_attn_int_deasserted3:4323 MC assert! (LP: #1715519) //
CVE-2018-126
- net: Add ndo_gso_check
- net: create skb_gso_validate_mac_len()
- bnx2x: disable GSO where gso_size is too big for hardware

  * CVE-2017-17448
- netfilter: nfnetlink_cthelper: Add missing permission checks

  * CVE-2017-11089
- cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

  * CVE-2018-5332
- RDS: Heap OOB write in rds_message_alloc_sgs()

  * ppc64el: Do not call ibm,os-term on panic (LP: #1736954)
- powerpc: Do not call ppc_md.panic in fadump panic notifier

  * CVE-2017-17805
- crypto: salsa20 - fix blkcipher_walk API usage

  * [Hyper-V] storvsc: do not assume SG list is continuous when doing bounce
buffers (LP: #1742480)
- SAUCE: storvsc: do not assume SG list is continuous when doing bounce
  buffers

  * Shutdown hang on 16.04 with iscsi targets (LP: #1569925)
- scsi: libiscsi: Allow sd_shutdown on bad transport

  * CVE-2017-17741
- KVM: Fix stack-out-of-bounds read in write_mmio

  * CVE-2017-5715 (Spectre v2 Intel)
- [Packaging] pull in retpoline files

 -- Stefan Bader   Thu, 15 Mar 2018 15:08:03
+0100

** Changed in: linux (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-11089

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-12762

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715

** Changed in: linux (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-16995

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-17862

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-8043

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-04-03 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.13.0-38.43

---
linux (4.13.0-38.43) artful; urgency=medium

  * linux: 4.13.0-38.43 -proposed tracker (LP: #1755762)

  * Servers going OOM after updating kernel from 4.10 to 4.13 (LP: #1748408)
- i40e: Fix memory leak related filter programming status
- i40e: Add programming descriptors to cleaned_count

  * [SRU] Lenovo E41 Mic mute hotkey is not responding (LP: #1753347)
- platform/x86: ideapad-laptop: Increase timeout to wait for EC answer

  * fails to dump with latest kpti fixes (LP: #1750021)
- kdump: write correct address of mem_section into vmcoreinfo

  * headset mic can't be detected on two Dell machines (LP: #1748807)
- ALSA: hda/realtek - Support headset mode for ALC215/ALC285/ALC289
- ALSA: hda - Fix headset mic detection problem for two Dell machines
- ALSA: hda - Fix a wrong FIXUP for alc289 on Dell machines

  * CIFS SMB2/SMB3 does not work for domain based DFS (LP: #1747572)
- CIFS: make IPC a regular tcon
- CIFS: use tcon_ipc instead of use_ipc parameter of SMB2_ioctl
- CIFS: dump IPC tcon in debug proc file

  * i2c-thunderx: erroneous error message "unhandled state: 0" (LP: #1754076)
- i2c: octeon: Prevent error message on bus error

  * hisi_sas: Add disk LED support (LP: #1752695)
- scsi: hisi_sas: directly attached disk LED feature for v2 hw

  * EDAC, sb_edac: Backport 1 patch to Ubuntu 17.10 (Fix missing DIMM sysfs
entries with KNL SNC2/SNC4 mode) (LP: #1743856)
- EDAC, sb_edac: Fix missing DIMM sysfs entries with KNL SNC2/SNC4 mode

  * [regression] Colour banding and artefacts appear system-wide on an Asus
Zenbook UX303LA with Intel HD 4400 graphics (LP: #1749420)
- drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

  * DVB Card with SAA7146 chipset not working (LP: #1742316)
- vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems

  * [Asus UX360UA] battery status in unity-panel is not changing when battery is
being charged (LP: #1661876) // AC adapter status not detected on Asus
ZenBook UX410UAK (LP: #1745032)
- ACPI / battery: Add quirk for Asus UX360UA and UX410UAK

  * ASUS UX305LA - Battery state not detected correctly (LP: #1482390)
- ACPI / battery: Add quirk for Asus GL502VSK and UX305LA

  * support thunderx2 vendor pmu events (LP: #1747523)
- perf pmu: Extract function to get JSON alias map
- perf pmu: Pass pmu as a parameter to get_cpuid_str()
- perf tools arm64: Add support for get_cpuid_str function.
- perf pmu: Add helper function is_pmu_core to detect PMU CORE devices
- perf vendor events arm64: Add ThunderX2 implementation defined pmu core
  events
- perf pmu: Add check for valid cpuid in perf_pmu__find_map()

  * lpfc.ko module doesn't work (LP: #1746970)
- scsi: lpfc: Fix loop mode target discovery

  * Ubuntu 17.10 crashes on vmalloc.c (LP: #1739498)
- powerpc/mm/book3s64: Make KERN_IO_START a variable
- powerpc/mm/slb: Move comment next to the code it's referring to
- powerpc/mm/hash64: Make vmalloc 56T on hash

  * ethtool -p fails to light NIC LED on HiSilicon D05 systems (LP: #1748567)
- net: hns: add ACPI mode support for ethtool -p

  * CVE-2017-17807
- KEYS: add missing permission check for request_key() destination

  * [Artful SRU] Fix capsule update regression (LP: #1746019)
- efi/capsule-loader: Reinstate virtual capsule mapping

  * [Artful/Bionic] [Config] enable EDAC_GHES for ARM64 (LP: #1747746)
- Ubuntu: [Config] enable EDAC_GHES for ARM64

  * linux-tools: perf incorrectly linking libbfd (LP: #1748922)
- SAUCE: tools -- add ability to disable libbfd
- [Packaging] correct disablement of libbfd

  * Cherry pick c96f5471ce7d for delayacct fix (LP: #1747769)
- delayacct: Account blkio completion on the correct task

  * Error in CPU frequency reporting when nominal and min pstates are same
(cpufreq) (LP: #1746174)
- cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin

  * retpoline abi files are empty on i386 (LP: #1751021)
- [Packaging] retpoline-extract -- instantiate retpoline files for i386
- [Packaging] final-checks -- sanity checking ABI contents
- [Packaging] final-checks -- check for empty retpoline files

  * [P9,Power NV][WSP][Ubuntu 1804] : "Kernel access of bad area " when grouping
different pmu events using perf fuzzer . (perf:) (LP: #1746225)
- powerpc/perf: Fix oops when grouping different pmu events

  * bnx2x_attn_int_deasserted3:4323 MC assert! (LP: #1715519) //
CVE-2018-126
- net: create skb_gso_validate_mac_len()
- bnx2x: disable GSO where gso_size is too big for hardware

  * Ubuntu16.04.03: ISAv3 initialize MMU registers before setting partition
table (LP: #1736145)
- powerpc/64s: Initialize ISAv3 MMU registers before setting partition table

  * powerpc/powernv: Flush console before platform error reboot (LP: #1735159)
- 

[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-03-19 Thread Stefan Bader
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'. If the problem still exists,
change the tag 'verification-needed-trusty' to 'verification-failed-
trusty'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-trusty

** Tags added: verification-needed-xenial

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-03-19 Thread Stefan Bader
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
artful' to 'verification-done-artful'. If the problem still exists,
change the tag 'verification-needed-artful' to 'verification-failed-
artful'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-03-19 Thread Stefan Bader
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-artful

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-02-23 Thread Thadeu Lima de Souza Cascardo
** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Released

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-02-20 Thread Stefan Bader
** Changed in: linux (Ubuntu Xenial)
   Status: New => Fix Committed

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  In Progress

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-02-20 Thread Stefan Bader
** Changed in: linux (Ubuntu Artful)
   Importance: Undecided => High

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

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

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Trusty:
  New
Status in linux source package in Xenial:
  New
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  In Progress

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2018-01-23 Thread Stefan Bader
** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: High
 Assignee: Thadeu Lima de Souza Cascardo (cascardo)
   Status: In Progress

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Trusty)
   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/1736954

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Trusty:
  New
Status in linux source package in Xenial:
  New
Status in linux source package in Artful:
  New
Status in linux source package in Bionic:
  In Progress

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2017-12-07 Thread Thadeu Lima de Souza Cascardo
** Description changed:

+ [Impact]
+ When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.
+ 
+ [Test Case]
+ Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.
+ 
+ [Regression Potential]
+ fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.
+ 
+ 
+ ---
+ 
  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.
  
  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms we
  support is pseries calling RTAS ibm,os-term.
  
  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.
  
  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest being
  shut down when calling ibm,os-term even when ibm,extended-os-term was
  available.
  
  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.
  
  Cascardo.

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  ---

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2017-12-07 Thread Thadeu Lima de Souza Cascardo
** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: makedumpfile (Ubuntu)

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

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

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

-- 
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/1736954

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  In Progress

Bug description:
  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2017-12-07 Thread Thadeu Lima de Souza Cascardo
** Changed in: makedumpfile (Ubuntu)
   Status: New => In Progress

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

** Changed in: makedumpfile (Ubuntu)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

-- 
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/1736954

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in makedumpfile package in Ubuntu:
  In Progress

Bug description:
  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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


[Kernel-packages] [Bug 1736954] Re: ppc64el: Do not call ibm, os-term on panic

2017-12-07 Thread Thadeu Lima de Souza Cascardo
Upstream commit: a3b2cb30f252b21a6f962e0dd107c8b897ca65e4 ("powerpc: Do
not call ppc_md.panic in fadump panic notifier").

-- 
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/1736954

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in makedumpfile package in Ubuntu:
  New

Bug description:
  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

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

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