General protection fault panic on module hpsa with lockup_detected attribute
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Eric Desrochers | ||
Wily |
Fix Released
|
Medium
|
Eric Desrochers |
Bug Description
it has been brought to my attention the following:
Kernel version: 4.2.0-30-generic #36~14.04.1-Ubuntu
When running an sosreport on HP DL380 gen8 machines running this kernel (Ubuntu 14.04.4 using linux-generic-
This panic does not happen on kernel 3.13 with hpsa 3.4.1-0 when using sosreport.
The funny thing is kernel 4.2 / 3.4.10-0 still is a more stable solution - I have yet to see a prior issue in which the p420 would lock up on this version. One issue wit h this is HP 99% of the time will require an sosreport when we raise any hardware issues. I can no longer produce that on kernel 4.2 machines because they kernel panic.
I can reproduce this consistently with several other machines in our environment. - please let me know if you would like more info.
Changed in linux (Ubuntu): | |
status: | Incomplete → Triaged |
tags: | added: kernel-da-key wily |
Changed in linux (Ubuntu Wily): | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in linux (Ubuntu): | |
status: | Triaged → In Progress |
Changed in linux (Ubuntu Wily): | |
status: | Triaged → In Progress |
Changed in linux (Ubuntu Wily): | |
status: | In Progress → Fix Committed |
tags: |
added: verification-done-wily removed: verification-needed-wily |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Released |
summary: |
- kernel panic (General protection fault) on module hpsa (lockup_detected) + General protection fault panic on module hpsa with lockup_detected + attribute |
The problem is reproducible on demand :
root@dob2- bfs-r5n09: ~# udevadm --debug info -ap /sys/block/sdf pci0000: 00/0000: 00:02.2/ 0000:02: 00.0/host2/ target2: 0:0/2:0: 0:5/block/ sdf'
calling: info
device 0x154a300 has devpath '/devices/
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/ pci0000: 00/0000: 00:02.2/ 0000:02: 00.0/host2/ target2: 0:0/2:0: 0:5/block/ sdf': =="1562758832" alignment} =="0" range}= ="256" poll_msecs} =="-1" offset} =="0" =="0" }=="50" async}= =""
KERNEL=="sdf"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}
ATTR{stat}==" 526 0 168573 232 11691 5205 2997588 3820 0 4016 4040"
ATTR{range}=="16"
ATTR{discard_
ATTR{events}==""
ATTR{ext_
ATTR{events_
ATTR{alignment_
ATTR{inflight}==" 0 0"
ATTR{removable}
ATTR{capability
ATTR{events_
device 0x154b220 has devpath '/devices/ pci0000: 00/0000: 00:02.2/ 0000:02: 00.0/host2/ target2: 0:0/2:0: 0:5' pci0000: 00/0000: 00:02.2/ 0000:02: 00.0/host2/ target2: 0:0/2:0: 0:5': level}= ="6" =="0x0500004000 000000" =="LOGICAL VOLUME " =="running" type}== "simple" cnt}==" 0x328b" _cnt}== "0x328b" id}=="600508B10 01C6ACDCAA167F4 67871EAB" ramp_up_ period} =="120000" busy}== "0" capacity_ change_ reported} =="0" =="30" media_change} =="0" cnt}==" 0x2"
looking at parent device '/devices/
KERNELS=="2:0:0:5"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{rev}=="7.02"
ATTRS{type}=="0"
ATTRS{scsi_
ATTRS{lunid}
ATTRS{model}
ATTRS{state}
ATTRS{queue_
ATTRS{iodone_
ATTRS{iorequest
ATTRS{unique_
ATTRS{queue_
ATTRS{device_
ATTRS{evt_
ATTRS{timeout}
ATTRS{evt_
ATTRS{ioerr_
ssh: Write failed: Broken pipe