[Kernel-packages] [Bug 1790480] Re: random oopses on s390 systems using NVMe devices
** Tags added: cscc -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: ubuntu-z-systems Status: Fix Committed => 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
This bug was fixed in the package linux - 4.18.0-8.9 --- linux (4.18.0-8.9) cosmic; urgency=medium * linux: 4.18.0-8.9 -proposed tracker (LP: #1791663) * Cosmic update to v4.18.7 stable release (LP: #1791660) - rcu: Make expedited GPs handle CPU 0 being offline - net: 6lowpan: fix reserved space for single frames - net: mac802154: tx: expand tailroom if necessary - 9p/net: Fix zero-copy path in the 9p virtio transport - spi: davinci: fix a NULL pointer dereference - spi: pxa2xx: Add support for Intel Ice Lake - spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe - spi: cadence: Change usleep_range() to udelay(), for atomic context - mmc: block: Fix unsupported parallel dispatch of requests - mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts - mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS - readahead: stricter check for bdi io_pages - block: fix infinite loop if the device loses discard capability - block: blk_init_allocated_queue() set q->fq as NULL in the fail case - block: really disable runtime-pm for blk-mq - blkcg: Introduce blkg_root_lookup() - block: Introduce blk_exit_queue() - block: Ensure that a request queue is dissociated from the cgroup controller - apparmor: fix bad debug check in apparmor_secid_to_secctx() - dma-buf: Move BUG_ON from _add_shared_fence to _add_shared_inplace - libertas: fix suspend and resume for SDIO connected cards - media: Revert "[media] tvp5150: fix pad format frame height" - mailbox: xgene-slimpro: Fix potential NULL pointer dereference - Replace magic for trusting the secondary keyring with #define - Fix kexec forbidding kernels signed with keys in the secondary keyring to boot - powerpc/fadump: handle crash memory ranges array index overflow - powerpc/64s: Fix page table fragment refcount race vs speculative references - powerpc/pseries: Fix endianness while restoring of r3 in MCE handler. - powerpc/pkeys: Give all threads control of their key permissions - powerpc/pkeys: Deny read/write/execute by default - powerpc/pkeys: key allocation/deallocation must not change pkey registers - powerpc/pkeys: Save the pkey registers before fork - powerpc/pkeys: Fix calculation of total pkeys. - powerpc/pkeys: Preallocate execute-only key - powerpc/nohash: fix pte_access_permitted() - powerpc64/ftrace: Include ftrace.h needed for enable/disable calls - powerpc/powernv/pci: Work around races in PCI bridge enabling - cxl: Fix wrong comparison in cxl_adapter_context_get() - IB/mlx5: Honor cnt_set_id_valid flag instead of set_id - IB/mlx5: Fix leaking stack memory to userspace - IB/srpt: Fix srpt_cm_req_recv() error path (1/2) - IB/srpt: Fix srpt_cm_req_recv() error path (2/2) - IB/srpt: Support HCAs with more than two ports - overflow.h: Add arithmetic shift helper - RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq - ib_srpt: Fix a use-after-free in srpt_close_ch() - ib_srpt: Fix a use-after-free in __srpt_close_all_ch() - RDMA/rxe: Set wqe->status correctly if an unexpected response is received - 9p: fix multiple NULL-pointer-dereferences - fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed - 9p/virtio: fix off-by-one error in sg list bounds check - net/9p/client.c: version pointer uninitialized - net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree() - dm integrity: change 'suspending' variable from bool to int - dm thin: stop no_space_timeout worker when switching to write-mode - dm cache metadata: save in-core policy_hint_size to on-disk superblock - dm cache metadata: set dirty on all cache blocks after a crash - dm crypt: don't decrease device limits - dm writecache: fix a crash due to reading past end of dirty_bitmap - uart: fix race between uart_put_char() and uart_shutdown() - Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer() - Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind() - iio: sca3000: Fix missing return in switch - iio: ad9523: Fix displayed phase - iio: ad9523: Fix return value for ad952x_store() - extcon: Release locking when sending the notification of connector state - eventpoll.h: wrap casts in () properly - vmw_balloon: fix inflation of 64-bit GFNs - vmw_balloon: do not use 2MB without batching - vmw_balloon: VMCI_DOORBELL_SET does not check status - vmw_balloon: fix VMCI use when balloon built into kernel - rtc: omap: fix resource leak in registration error path - rtc: omap: fix potential crash on power off - tracing: Do not call start/stop() functions when tracing_on does not change - tracing/blktrace: Fix to allow setting same value - printk/tracing: Do not trace printk_nmi_enter() - livepatch:
[Kernel-packages] [Bug 1790480] Re: random oopses on s390 systems using NVMe devices
This bug was fixed in the package linux - 4.15.0-36.39
---
linux (4.15.0-36.39) bionic; urgency=medium
* CVE-2018-14633
- iscsi target: Use hex2bin instead of a re-implementation
* CVE-2018-17182
- mm: get rid of vmacache_flush_all() entirely
linux (4.15.0-35.38) bionic; urgency=medium
* linux: 4.15.0-35.38 -proposed tracker (LP: #1791719)
* device hotplug of vfio devices can lead to deadlock in vfio_pci_release
(LP: #1792099)
- SAUCE: vfio -- release device lock before userspace requests
* L1TF mitigation not effective in some CPU and RAM combinations
(LP: #1788563)
- x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit
- x86/speculation/l1tf: Fix off-by-one error when warning that system has
too
much RAM
- x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
* CVE-2018-15594
- x86/paravirt: Fix spectre-v2 mitigations for paravirt guests
* CVE-2017-5715 (Spectre v2 s390x)
- KVM: s390: implement CPU model only facilities
- s390: detect etoken facility
- KVM: s390: add etoken support for guests
- s390/lib: use expoline for all bcr instructions
- s390: fix br_r1_trampoline for machines without exrl
- SAUCE: s390: use expoline thunks for all branches generated by the BPF JIT
* Ubuntu18.04.1: cpuidle: powernv: Fix promotion from snooze if next state
disabled (performance) (LP: #1790602)
- cpuidle: powernv: Fix promotion from snooze if next state disabled
* Watchdog CPU:19 Hard LOCKUP when kernel crash was triggered (LP: #1790636)
- powerpc: hard disable irqs in smp_send_stop loop
- powerpc: Fix deadlock with multiple calls to smp_send_stop
- powerpc: smp_send_stop do not offline stopped CPUs
- powerpc/powernv: Fix opal_event_shutdown() called with interrupts disabled
* Security fix: check if IOMMU page is contained in the pinned physical page
(LP: #1785675)
- vfio/spapr: Use IOMMU pageshift rather than pagesize
- KVM: PPC: Check if IOMMU page is contained in the pinned physical page
* Missing Intel GPU pci-id's (LP: #1789924)
- drm/i915/kbl: Add KBL GT2 sku
- drm/i915/whl: Introducing Whiskey Lake platform
- drm/i915/aml: Introducing Amber Lake platform
- drm/i915/cfl: Add a new CFL PCI ID.
* CVE-2018-15572
- x86/speculation: Protect against userspace-userspace spectreRSB
* Support Power Management for Thunderbolt Controller (LP: #1789358)
- thunderbolt: Handle NULL boot ACL entries properly
- thunderbolt: Notify userspace when boot_acl is changed
- thunderbolt: Use 64-bit DMA mask if supported by the platform
- thunderbolt: Do not unnecessarily call ICM get route
- thunderbolt: No need to take tb->lock in domain suspend/complete
- thunderbolt: Use correct ICM commands in system suspend
- thunderbolt: Add support for runtime PM
* random oopses on s390 systems using NVMe devices (LP: #1790480)
- s390/pci: fix out of bounds access during irq setup
* [Bionic] Spectre v4 mitigation (Speculative Store Bypass Disable) support
for arm64 using SMC firmware call to set a hardware chicken bit
(LP: #1787993) // CVE-2018-3639 (arm64)
- arm64: alternatives: Add dynamic patching feature
- KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state
- KVM: arm64: Avoid storing the vcpu pointer on the stack
- arm/arm64: smccc: Add SMCCC-specific return codes
- arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1
- arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2
- arm64: Add ARCH_WORKAROUND_2 probing
- arm64: Add 'ssbd' command-line option
- arm64: ssbd: Add global mitigation state accessor
- arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation
- arm64: ssbd: Restore mitigation status on CPU resume
- arm64: ssbd: Introduce thread flag to control userspace mitigation
- arm64: ssbd: Add prctl interface for per-thread mitigation
- arm64: KVM: Add HYP per-cpu accessors
- arm64: KVM: Add ARCH_WORKAROUND_2 support for guests
- arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests
- arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID
- [Config] ARM64_SSBD=y
* Reconcile hns3 SAUCE patches with upstream (LP: #1787477)
- Revert "UBUNTU: SAUCE: net: hns3: Optimize PF CMDQ interrupt switching
process"
- Revert "UBUNTU: SAUCE: net: hns3: Fix for VF mailbox receiving unknown
message"
- Revert "UBUNTU: SAUCE: net: hns3: Fix for VF mailbox cannot receiving PF
response"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: fix comments for
hclge_get_ring_chain_from_mbx"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: fix for using wrong mask and
shift in hclge_get_ring_chain_from_mbx"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: fix for reset_level default
assignment probelm"
- Revert "UBUNTU: SAUCE: {topost} net: hns3:
[Kernel-packages] [Bug 1790480] Re: random oopses on s390 systems using NVMe devices
This bug was fixed in the package linux - 4.4.0-137.163 --- linux (4.4.0-137.163) xenial; urgency=medium * CVE-2018-14633 - iscsi target: Use hex2bin instead of a re-implementation * CVE-2018-17182 - mm: get rid of vmacache_flush_all() entirely linux (4.4.0-136.162) xenial; urgency=medium * linux: 4.4.0-136.162 -proposed tracker (LP: #1791745) * CVE-2017-5753 - bpf: properly enforce index mask to prevent out-of-bounds speculation - Revert "UBUNTU: SAUCE: bpf: Use barrier_nospec() instead of osb()" - Revert "bpf: prevent speculative execution in eBPF interpreter" * L1TF mitigation not effective in some CPU and RAM combinations (LP: #1788563) // CVE-2018-3620 // CVE-2018-3646 - x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit - x86/speculation/l1tf: Fix off-by-one error when warning that system has too much RAM - x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ * CVE-2018-15594 - x86/paravirt: Fix spectre-v2 mitigations for paravirt guests * Xenial update to 4.4.144 stable release (LP: #1791080) - KVM/Eventfd: Avoid crash when assign and deassign specific eventfd in parallel. - x86/MCE: Remove min interval polling limitation - fat: fix memory allocation failure handling of match_strdup() - ALSA: rawmidi: Change resized buffers atomically - ARC: Fix CONFIG_SWAP - ARC: mm: allow mprotect to make stack mappings executable - mm: memcg: fix use after free in mem_cgroup_iter() - ipv4: Return EINVAL when ping_group_range sysctl doesn't map to user ns - ipv6: fix useless rol32 call on hash - lib/rhashtable: consider param->min_size when setting initial table size - net/ipv4: Set oif in fib_compute_spec_dst - net: phy: fix flag masking in __set_phy_supported - ptp: fix missing break in switch - tg3: Add higher cpu clock for 5762. - net: Don't copy pfmemalloc flag in __copy_skb_header() - skbuff: Unconditionally copy pfmemalloc in __skb_clone() - xhci: Fix perceived dead host due to runtime suspend race with event handler - x86/paravirt: Make native_save_fl() extern inline - SAUCE: Add missing CPUID_7_EDX defines - SAUCE: x86/speculation: Expose indirect_branch_prediction_barrier() - x86/pti: Mark constant arrays as __initconst - x86/asm/entry/32: Simplify pushes of zeroed pt_regs->REGs - x86/entry/64/compat: Clear registers for compat syscalls, to reduce speculation attack surface - x86/speculation: Clean up various Spectre related details - x86/speculation: Fix up array_index_nospec_mask() asm constraint - x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend - x86/mm: Factor out LDT init from context init - x86/mm: Give each mm TLB flush generation a unique ID - SAUCE: x86/speculation: Use Indirect Branch Prediction Barrier in context switch - x86/speculation: Use IBRS if available before calling into firmware - x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP - selftest/seccomp: Fix the seccomp(2) signature - xen: set cpu capabilities from xen_start_kernel() - x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen - SAUCE: Preserve SPEC_CTRL MSR in new inlines - SAUCE: Add Knights Mill to NO SSB list - x86/process: Correct and optimize TIF_BLOCKSTEP switch - x86/process: Optimize TIF_NOTSC switch - Revert "x86/cpufeatures: Add FEATURE_ZEN" - Revert "x86/cpu/AMD: Fix erratum 1076 (CPB bit)" - x86/cpu/AMD: Fix erratum 1076 (CPB bit) - x86/cpufeatures: Add FEATURE_ZEN - x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths - x86/cpu: Re-apply forced caps every time CPU caps are re-read - block: do not use interruptible wait anywhere - clk: tegra: Fix PLL_U post divider and initial rate on Tegra30 - ubi: Introduce vol_ignored() - ubi: Rework Fastmap attach base code - ubi: Be more paranoid while seaching for the most recent Fastmap - ubi: Fix races around ubi_refill_pools() - ubi: Fix Fastmap's update_vol() - ubi: fastmap: Erase outdated anchor PEBs during attach - Linux 4.4.144 * CVE-2017-5715 (Spectre v2 s390x) - s390: detect etoken facility - s390/lib: use expoline for all bcr instructions - SAUCE: s390: use expoline thunks for all branches generated by the BPF JIT * Xenial update to 4.4.143 stable release (LP: #1790884) - compiler, clang: suppress warning for unused static inline functions - compiler, clang: properly override 'inline' for clang - compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled - compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations - x86/asm: Add _ASM_ARG* constants for argument registers to - ocfs2: subsystem.su_mutex is required while accessing the item->ci_parent - bcm63xx_enet: correct clock usage - bcm63xx_enet: do
[Kernel-packages] [Bug 1790480] Re: random oopses on s390 systems using NVMe devices
adjusting tags according to comment #11 ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
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- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. 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-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
adjusting tags according to comment #8 ** Tags removed: verification-needed-xenial ** Tags added: verification-done-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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
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-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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: ubuntu-z-systems Status: In Progress => 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Kleber Sacilotto de Souza (kleber-souza) ** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Bionic) Status: In Progress => 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
According to https://lkml.org/lkml/2018/9/3/1125 is needs to be incl. into xenial (kernel 4.4) as well. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: 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 Bionic: In Progress Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: 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 Bionic: In Progress Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: ubuntu-z-systems Status: Triaged => 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
SRU request: https://lists.ubuntu.com/archives/kernel- team/2018-September/095200.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
I built a test kernel with the commit 866f3576a72b ("s390/pci: fix out
of bounds access during irq setup").
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~ksouza/lp1790480/
Can you test this kernel and see if it resolves this bug?
Note about installing test kernels:
* For test kernels that are 4.15(Bionic) or newer, you need to install the
linux-modules and linux-modules-extra .deb packages.
Thank you.
** Changed in: linux (Ubuntu Bionic)
Status: Triaged => 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/1790480
Title:
random oopses on s390 systems using NVMe devices
Status in Ubuntu on IBM z Systems:
Triaged
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Bionic:
In Progress
Bug description:
== SRU Justification ==
IBM is requesting a fix for the following issue found with NVMe devices on
s390x:
The trigger is a PCI function whose driver requests more interrupts
than the architectural maximum. Currently this is only possible with a
machine that supports 64 CPUs (or more) with a NVMe function attached.
Note that the LPAR does not have to use >=64 CPUs since the NVMe
driver uses num_possible_cpus() which is resolved to the machine
maximum on s390 (since all CPUs are hot-pluggable). The oops happens
after the driver calls pci_alloc_irq_vectors during device probing -
so most likely the system will panic during boot.
The fix has been cc'ed to stable@, but hasn't been picked up for
Bionic yet.
== Fix ==
866f3576a72b s390/pci: fix out of bounds access during irq setup
== Regression Potential ==
Low. Affects only s390x systems with more than 64 cpus and NVMe function
enabled.
== Test case ==
Boot the kernel in an affected environment.
=== Original bug description ===
Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1
kernel have been reported.
Bisect of the upstream kernel points to:
16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to
pci_alloc_irq_vectors
This commit is correct but reveals a bug in s390s IRQ setup routine. A
fix is available fixed via:
Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17
Need also be applied for Ubuntu 18.10
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions
--
Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Kleber Sacilotto de Souza (kleber-souza) ** Changed in: linux (Ubuntu Bionic) Status: New => Triaged ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Bionic) Importance: Medium => High ** Description changed: + == SRU Justification == + IBM is requesting a fix for the following issue found with NVMe devices on s390x: + + The trigger is a PCI function whose driver requests more interrupts than + the architectural maximum. Currently this is only possible with a + machine that supports 64 CPUs (or more) with a NVMe function attached. + Note that the LPAR does not have to use >=64 CPUs since the NVMe driver + uses num_possible_cpus() which is resolved to the machine maximum on + s390 (since all CPUs are hot-pluggable). The oops happens after the + driver calls pci_alloc_irq_vectors during device probing - so most + likely the system will panic during boot. + + The fix has been cc'ed to stable@, but hasn't been picked up for Bionic + yet. + + == Fix == + 866f3576a72b s390/pci: fix out of bounds access during irq setup + + == Regression Potential == + Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. + + == Test case == + Boot the kernel in an affected environment. + + + === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Bug description: == SRU Justification == IBM is requesting a fix for the following issue found with NVMe devices on s390x: The trigger is a PCI function whose driver requests more interrupts than the architectural maximum. Currently this is only possible with a machine that supports 64 CPUs (or more) with a NVMe function attached. Note that the LPAR does not have to use >=64 CPUs since the NVMe driver uses num_possible_cpus() which is resolved to the machine maximum on s390 (since all CPUs are hot-pluggable). The oops happens after the driver calls pci_alloc_irq_vectors during device probing - so most likely the system will panic during boot. The fix has been cc'ed to stable@, but hasn't been picked up for Bionic yet. == Fix == 866f3576a72b s390/pci: fix out of bounds access during irq setup == Regression Potential == Low. Affects only s390x systems with more than 64 cpus and NVMe function enabled. == Test case == Boot the kernel in an affected environment. === Original bug description === Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
@IBM: Even if we do not have NVMe devices in our Z machine (hence we cannot test this on s390x by ourselves) it would be good and helpful if you can share a description / or some steps of a potential test case. This would help judging the regression risk in case of an SRU to 18.04 (and is needed for a SRU anyway). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: New Bug description: Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: linux (Ubuntu) Assignee: Skipper Bug Screeners (skipper-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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: New Bug description: Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Also affects: linux (Ubuntu Bionic) 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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Status in linux source package in Bionic: New Bug description: Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://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 1790480] Re: random oopses on s390 systems using NVMe devices
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Triaged ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-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/1790480 Title: random oopses on s390 systems using NVMe devices Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: Random oopses on s390 systems using NVMe and running the Ubuntu 18.04.1 kernel have been reported. Bisect of the upstream kernel points to: 16ccfff28976 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors This commit is correct but reveals a bug in s390s IRQ setup routine. A fix is available fixed via: Commit-ID : 866f3576a72b2233a76dffb80290f8086dc49e17 Need also be applied for Ubuntu 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790480/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
