Comment 26 for bug 1425699

I will not change the status of this bug because I can not reliably rule out that the initial issue still exists. That was reported to happen not all the times and from the stack trace involved some locking issue in the pci scsi adapter's driver.
Since comment #9, however, the reported stack trace is showing a completely different issue. This happened to be a regression since 3.13.0-46 and in order to cleanly separate the problems I opened LP: #1589910 to track the fix for that. As soon as that is there should be no need to enforce a HWE kernel for commissioning and/or provisioning of ppc64el hosts.

Should the initially reported problem persist then, please report back here so we can try to fix that, too. Note that the stack trace should involve the IPR adapter in some way. Like:

[ 14.995435] ipr: IBM Power RAID SCSI Device Driver version: 2.6.0 (November 16, 2012)
[ 14.995630] ipr 0001:04:00.0: Found IOA with IRQ: 0
[ 14.995828] ipr 0001:04:00.0: Using 64-bit DMA iommu bypass
[ 14.996992] pnv_pci_dump_phb_diag_data: Unrecognized ioType 33554432
[ 14.997063] EEH: Frozen PE#5 detected on PHB#1
[ 14.997124] CPU: 11 PID: 911 Comm: systemd-udevd Not tainted 3.13.0-27-generic #50-Ubuntu
[ 14.997207] Call Trace:
[ 14.997242] [c000000fe325af70] [c000000000016af0] .show_stack+0x170/0x290 (unreliable)
[ 14.997340] [c000000fe325b060] [c000000000966fc0] .dump_stack+0x88/0xb4
[ 14.997427] [c000000fe325b0e0] [c0000000000364b0] .eeh_dev_check_failure+0x430/0x480
[ 14.997526] [c000000fe325b190] [c000000000036584] .eeh_check_failure+0x84/0xe0
[ 14.997630] [c000000fe325b220] [d00000000ef233e0] .ipr_mask_and_clear_interrupts+0x190/0x1d0 [ipr]
[ 14.997747] [c000000fe325b2d0] [d00000000ef2a394] .ipr_probe_ioa+0xc24/0x1370 [ipr]
[ 14.997857] [c000000fe325b400] [d00000000ef325c4] .ipr_probe+0x44/0x4c0 [ipr]