Bug 1261659 - lm_sensors sensors-detect triggers kernel panics on read_port and write_port on aarch64
lm_sensors sensors-detect triggers kernel panics on read_port and write_port ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel-aarch64 (Show other bugs)
7.2
aarch64 Linux
high Severity medium
: rc
: 7.3
Assigned To: Al Stone
Erico Nunes
:
: 1318002 1327759 (view as bug list)
Depends On:
Blocks: 1045641 1250209 1274397 1290605 1364088
  Show dependency treegraph
 
Reported: 2015-09-09 17:57 EDT by Jeff Bastian
Modified: 2016-11-03 18:28 EDT (History)
15 users (show)

See Also:
Fixed In Version: kernel-aarch64-4.5.0-0.47.el7
Doc Type: No Doc Update
Doc Text:
Internal bug
Story Points: ---
Clone Of:
: 1290605 (view as bug list)
Environment:
Last Closed: 2016-11-03 18:28:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vmcore dmesg from Super I/O probe (43.11 KB, text/plain)
2015-09-09 17:57 EDT, Jeff Bastian
no flags Details
patch sent upstream (1.66 KB, patch)
2016-04-06 17:45 EDT, Al Stone
no flags Details | Diff
LKML -> char: Drop bogus dependency of DEVPORT on !M68K (2.94 KB, patch)
2016-04-20 17:42 EDT, Al Stone
no flags Details | Diff

  None (edit)
Description Jeff Bastian 2015-09-09 17:57:39 EDT
Created attachment 1071956 [details]
vmcore dmesg from Super I/O probe

Description of problem:
The sensors-detect tool from lm_sensors triggers a kernel panic on AMD Seattle B0 systems with the 4.2.0-0.19.el7 kernel.  The panics are in the read_port() and write_port() calls:

1) scan for Super I/O devices:                                         
Unable to handle kernel paging request at virtual address fffffdfffae0002e
...                                                                     
Internal error: Oops: 96000047 [#1] SMP                                 
...                                                                     
CPU: 1 PID: 12283 Comm: sensors-detect Not tainted 4.2.0-0.19.el7.aarch64 #1
...                                                                     
PC is at write_port+0xac/0xf4                                           
LR is at __vfs_write+0x48/0x130                                         
                                                                        
2) scan for IPMI devices:                                              
Unable to handle kernel paging request at virtual address fffffdfffae00ca3
...                                                                     
Internal error: Oops: 96000007 [#1] SMP                                 
...                                                                     
CPU: 1 PID: 2866 Comm: sensors-detect Not tainted 4.2.0-0.19.el7.aarch64 #1
...                                                                     
PC is at read_port+0xa0/0xec                                            
LR is at __vfs_read+0x48/0x128                                

3) scan for ISA ports:
Unable to handle kernel paging request at virtual address fffffdfffae00291
...
Internal error: Oops: 96000007 [#1] SMP
...
CPU: 0 PID: 2883 Comm: sensors-detect Not tainted 4.2.0-0.19.el7.aarch64 #1
...
PC is at read_port+0xa0/0xec
LR is at __vfs_read+0x48/0x128


Version-Release number of selected component (if applicable):
kernel-4.2.0-0.19.el7.aarch64
lm_sensors-3.3.4-11.el7.aarch64

How reproducible:
always

Steps to Reproduce:
1. sensors-detect

Actual results:
kernel panics when sensors-detect probes for various sensors

Expected results:
no panics

Additional info:
Comment 3 Jeff Bastian 2015-10-26 12:55:30 EDT
(In reply to Jeff Bastian from comment #0)
> Created attachment 1071956 [details]
> vmcore dmesg from Super I/O probe
> 
> Description of problem:
> The sensors-detect tool from lm_sensors triggers a kernel panic on AMD
> Seattle B0 systems with the 4.2.0-0.19.el7 kernel.  The panics are in the
> read_port() and write_port() calls:


It also affects APM Mustang systems:

[root@apm-mustang-ev3-12 ~]# uname -r
4.2.0-0.21.el7.aarch64
[root@apm-mustang-ev3-12 ~]# sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: AppliedMicro Mustang [1.0]

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for Super-I/O at 0x2e/0x2f
[   76.843093] Unhandled fault: synchronous external abort (0x96000010) at 0xfff
Trying family `National Semiconductor/ITE'...               [   76.854370] InteP
[   76.864038] Modules linked in: vfat fat sg gpio_xgene_sb xgene_rng gpio_gene)
[   76.878317] CPU: 1 PID: 2316 Comm: sensors-detect Tainted: G            E   1
[   76.887490] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Aug 26 25
[   76.894762] task: fffffe015557e140 ti: fffffe015562c000 task.ti: fffffe015560
[   76.902211] PC is at read_port+0xa0/0xec
[   76.906115] LR is at __vfs_read+0x48/0x128
...
Comment 4 Jeff Bastian 2015-10-26 12:59:06 EDT
The HP m400 complains about PCI AER uncorrected errors due to the probes, but at least it doesn't have a kernel panic:

[root@hp-moonshot-02-c03 ~]# uname -r
4.2.0-0.21.el7.aarch64

[root@hp-moonshot-02-c03 ~]# sensors-detect 
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: HP ProLiant m400 Server

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): 
# DMI data unavailable, please consider installing dmidecode 2.7
# or later for better results.
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): 

Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): Sorry, no supported PCI bus adapters found.

Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.

[root@hp-moonshot-02-c03 ~]# dmesg
[  575.824645] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  575.932051] pcieport 0000:00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=0000(Requester ID)
[  576.139593] pcieport 0000:00:00.0:   device [10e8:e004] error status/mask=00100000/00000000
[  576.306514] pcieport 0000:00:00.0:    [20] Unsupported Request    (First)
[  576.454639] pcieport 0000:00:00.0:   TLP Header: 60001001 00000004 000000a0 1000002c
[  576.614282] pcieport 0000:00:00.0: broadcast error_detected message
[  576.614300] mlx4_core 0000:01:00.0: mlx4_pci_err_detected was called
[  576.727956] mlx4_core 0000:01:00.0: device is going to be reset
[  577.877080] mlx4_core 0000:01:00.0: device was reset successfully
[  577.950219] mlx4_en 0000:01:00.0: Internal error detected, restarting device
[  577.950227] mlx4_core 0000:01:00.0: Could not post command 0x49: ret=-5, in_param=0x0, in_mod=0x2, op_mod=0x0
[  578.154043] mlx4_en: eno1: Close port called
[  578.477381] mlx4_en: eno1d1: Close port called
[  578.874107] mlx4_en 0000:01:00.0: removed PHC
[  579.936717] pcieport 0000:00:00.0: broadcast slot_reset message
[  579.936729] mlx4_core 0000:01:00.0: mlx4_pci_slot_reset was called
[  587.014757] mlx4_core 0000:01:00.0: PCIe BW is different than device's capability
[  587.104592] mlx4_core 0000:01:00.0: PCIe link speed is 5.0GT/s, device supports 8.0GT/s
[  587.200691] mlx4_core 0000:01:00.0: PCIe link width is x8, device supports x8
[  587.333441] mlx4_en 0000:01:00.0: registered PHC clock
[  587.395161] mlx4_en 0000:01:00.0: Activating port:1
[  587.458379] mlx4_en: 0000:01:00.0: Port 1: Using 64 TX rings
[  587.526306] mlx4_en: 0000:01:00.0: Port 1: Using 8 RX rings
[  587.593189] mlx4_en: 0000:01:00.0: Port 1:   frag:0 - size:1518 prefix:0 stride:1536
[  587.686456] mlx4_en: 0000:01:00.0: Port 1: Initializing port
[  587.755992] mlx4_en 0000:01:00.0: Activating port:2
[  587.761491] mlx4_core 0000:01:00.0 eno1: renamed from eth0
[  587.886408] mlx4_en: 0000:01:00.0: Port 2: Using 64 TX rings
[  587.954338] mlx4_en: 0000:01:00.0: Port 2: Using 8 RX rings
[  588.021231] mlx4_en: 0000:01:00.0: Port 2:   frag:0 - size:1518 prefix:0 stride:1536
[  588.114604] mlx4_en: 0000:01:00.0: Port 2: Initializing port
[  588.134732] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[  588.135777] mlx4_en: eno1:   frag:0 - size:1518 prefix:0 stride:1536
[  588.210021] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[  588.213262] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[  588.473066] mlx4_core 0000:01:00.0 eno1d1: renamed from eth0
[  588.473787] pcieport 0000:00:00.0: broadcast resume message
[  588.473797] pcieport 0000:00:00.0: AER: Device recovery successful
[  588.473802] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.473831] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473834] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.473858] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473860] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.473886] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473888] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.473912] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473914] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.473939] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473941] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.473967] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473969] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.473993] pcieport 0000:00:00.0: can't find device of ID0000
[  588.473995] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474020] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474022] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.474048] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474050] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474076] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474078] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474103] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474105] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.474130] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474131] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.474157] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474159] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474184] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474186] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.474210] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474212] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474237] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474239] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474264] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474266] pcieport 0000:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000
[  588.474291] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474293] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474319] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474320] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474346] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474347] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474373] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474375] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474400] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474402] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474428] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474429] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474454] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474456] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474481] pcieport 0000:00:00.0: can't find device of ID0000
[  588.474483] pcieport 0000:00:00.0: AER: Uncorrected (Non-Fatal) error received: id=0000
[  588.474505] pcieport 0000:00:00.0: can't find device of ID0000
[  588.922249] mlx4_en: eno1: Link Up
[  589.536331] mlx4_en: eno1d1: Link Up
[  591.301028] i2c /dev entries driver
[  591.407560] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[  591.497296] IPv6: ADDRCONF(NETDEV_UP): eno1d1: link is not ready
[  591.570986] mlx4_en: eno1d1:   frag:0 - size:1518 prefix:0 stride:1536
Comment 5 Jeff Bastian 2015-10-26 13:02:05 EDT
And, for the record, the firmware on the Mustang and HP m400 systems from comment 3 and comment 4:

[root@apm-mustang-ev3-12 ~]# dmidecode -t 0 | grep -A3 Info
BIOS Information
	Vendor: AppliedMicro
	Version: 1.1.0
	Release Date: Aug 26 2015                 <-- RH build of 1.15.10.1


[root@hp-moonshot-02-c03 ~]# dmidecode -t 0 | grep -A3 Info
BIOS Information
	Vendor: HP
	Version: U02
	Release Date: 07/09/2015
Comment 6 Dean Nelson 2015-12-04 15:54:40 EST
On an APM mustang system with...

[root@apm-mustang-ev3-20 ~]# dmidecode -t 0 | grep -A3 Info
BIOS Information
        Vendor: AppliedMicro
        Version: 1.1.0
        Release Date: Aug 26 2015
[root@apm-mustang-ev3-20 ~]#

[root@apm-mustang-ev3-20 ~]# uname -r
4.2.0-0.20.el7.aarch64
[root@apm-mustang-ev3-20 ~]#

[root@apm-mustang-ev3-20 ~]# sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: AppliedMicro Mustang [1.0]

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
[2909085.826876] Unhandled fault: synchronous external abort (0x96000010) at 0xfffffdfffae0002f
[2909085.835299] Internal error: : 96000010 [#1] SMP
[2909085.839980] Modules linked in: vfat fat sg gpio_xgene_sb xgene_rng gpio_generic nfsd ip_tables xfs libcrc32c realtek xgene_enet dm_mirror dm_region_hash dm_log dm_mod
[2909085.855135] CPU: 1 PID: 26903 Comm: sensors-detect Not tainted 4.2.0+ #19
[2909085.862061] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Aug 26 2015
[2909085.869505] task: fffffe00dbf41680 ti: fffffe01578dc000 task.ti: fffffe01578dc000
[2909085.877126] PC is at read_port+0xa0/0xec
[2909085.881202] LR is at __vfs_read+0x48/0x128

Which is basically what jbastian saw on an APM mustang system (reported in comment #3).

 ..................................................................

But on the same system after a firmware update and re-provisioning...

[root@apm-mustang-ev3-20 ~]#  dmidecode -t 0 | grep -A3 Info
BIOS Information
        Vendor: AppliedMicro
        Version: 1.1.0
        Release Date: Oct 20 2015
[root@apm-mustang-ev3-20 ~]#

[root@apm-mustang-ev3-20 ~]# uname -r
4.2.0-0.21.el7.aarch64
[root@apm-mustang-ev3-20 ~]#

[root@apm-mustang-ev3-20 ~]# sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: AppliedMicro Mustang [1.0]

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
# DMI data unavailable, please consider installing dmidecode 2.7
# or later for better results.
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.

Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[root@apm-mustang-ev3-20 ~]#

Which is basically what jbastian saw on a HP m400 system (reported in comment #4), but I didn't see the AER uncorrected errors Jeff saw on that system.

 ..................................................................

So with the firmware upgrade on an APM mustang the panic disappeared and there weren't any AER uncorrected errors.

I assume a modification to the HP m400's firmware will address the AER uncorrected error issue there.

And I'd guess that AMD Seattle's panic possibly reflects an issue with its firmware.
Comment 12 Jon Masters 2016-02-04 00:13:54 EST
Hi all,

There are no ISA IO ports on ARMv8. What happens is that these operations get remapped to memory accesses into unpopulated memory, which, depending upon the microarchitecture and SoC implementation might result in an SError being asserted (Seattle) or other behavior. It's not a bug. The bug is trying to scan an "ISA" bus on ARMv8 :) HOWEVER what we should do is ponder reviving the locking down of /dev/mem and the kernel behavior with regard to root access to memory so that we just kill the process rather than panic the machine.

Jon.
Comment 13 Jeff Bastian 2016-03-16 15:18:45 EDT
This affects both AMD Seattle (comment 0) and APM Mustang systems (comment 3), so I'm changing the subject line (removing AMD).  This has also been reported on CentOS 7 in bug 1318002, so I'm going to make this bug public and close 1318002 as a duplicate of this bug.
Comment 14 Jeff Bastian 2016-03-16 15:21:20 EDT
*** Bug 1318002 has been marked as a duplicate of this bug. ***
Comment 15 Jon Masters 2016-04-05 00:39:56 EDT
This bug should go away with access to /dev/mem disabled.
Comment 16 Jeff Bastian 2016-04-05 10:23:39 EDT
Unfortunately, it's still a problem with /dev/mem disabled.  I installed the test kernel from bug 1238436 and ran sensors-detect, and it still caused a panic with write_port.


[root@bumblebee ~]# rpm -q kernel-$(uname -r)
kernel-4.5.0-0.rc7.31.el7.bz1238436.aarch64

[root@bumblebee boot]# ls /dev/mem
ls: cannot access /dev/mem: No such file or directory

[root@bumblebee ~]# sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: AMD Overdrive/Supercharger
# Board: Default string Default string

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for Super-I/O at 0x2e/0x2f

[  123.226675] Unable to handle kernel paging request at virtual address fffffdfffae0002e
[  123.234593] pgd = fffffe0353400000
[  123.237992] [fffffdfffae0002e] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000
[  123.246971] Internal error: Oops: 96000047 [#1] SMP
[  123.251838] Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter vfat fat ipmi_ssif i2c_core ipmi_si sg ipmi_msghandler hed nfsd ip_tables xfs libcrc32c dm_crypt sr_mod cdrom aes_ce_blk ablk_helper cryptd aes_ce_cipher ghash_ce sha2_ce sha1_ce e1000e amd_xgbe ptp ccp pps_core ahci_platform libahci_platform dm_mirror dm_region_hash dm_log dm_mod
[  123.320131] CPU: 4 PID: 13228 Comm: sensors-detect Not tainted 4.5.0-0.rc7.31.el7.bz1238436.aarch64 #1
[  123.329425] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD1001A 02/09/2016
[  123.338024] task: fffffe0359296a80 ti: fffffe03563a0000 task.ti: fffffe03563a0000
[  123.345504] PC is at write_port+0x88/0xf0
[  123.349506] LR is at __vfs_write+0x48/0x104
[  123.353680] pc : [<fffffe00004a68dc>] lr : [<fffffe0000223560>] pstate: 80000145
[  123.361067] sp : fffffe03563a3d70
[  123.364371] x29: fffffe03563a3d70 x28: fffffe03563a0000 
[  123.369676] x27: fffffe0000772000 x26: 0000000000000040 
[  123.374981] x25: 000000000000011e x24: 0000000000000015 
[  123.380285] x23: 0000000060000000 x22: 0000000005baac80 
[  123.385589] x21: fffffe03563a3ec8 x20: 0000000000000001 
[  123.390894] x19: fffffe001c861a00 x18: 000003fff54f0d90 
[  123.396198] x17: 000003ff8350f030 x16: fffffe0000224dd8 
[  123.401502] x15: 0000000000000002 x14: 0000000000000000 
[  123.406806] x13: ffffffffffffffff x12: 0000000000000000 
[  123.412110] x11: 0000000000000000 x10: 0000000000000001 
[  123.417414] x9 : 000003ff838bf000 x8 : fffffdfffae0002e 
[  123.422718] x7 : 0000000000000000 x6 : 000000000000002e 
[  123.428022] x5 : fffffdfffae0002e x4 : 0000000000000000 
[  123.433326] x3 : fffffe03563a3ec8 x2 : 00000000000000aa 
[  123.438629] x1 : 0000000005baac80 x0 : 0000000005baac80 
[  123.443933] 
[  123.445414] Process sensors-detect (pid: 13228, stack limit = 0xfffffe03563a0020)
[  123.452889] Stack: (0xfffffe03563a3d70 to 0xfffffe03563a4000)
[  123.458626] 3d60:                                   fffffe03563a3da0 fffffe0000223560
[  123.466448] 3d80: fffffe03563a3dc0 fffffe03563a3ec8 0000000000000001 0000000005baac80
[  123.474269] 3da0: fffffe03563a3e30 fffffe00002242e4 fffffe001c861a00 0000000000000001
[  123.482091] 3dc0: fffffe03563a3ec8 0000000005baac80 0000000000000001 fffffe001c861a00
[  123.489913] 3de0: 0000000000000001 0000000005baac80 fffffe03563a3e30 fffffe00002242b4
[  123.497734] 3e00: fffffe001c861a00 0000000000000001 fffffe03563a3ec8 fffffe000014dd54
[  123.505556] 3e20: fffffe03563a3e50 fffffe03563a3ec8 fffffe03563a3e80 fffffe0000224e2c
[  123.513377] 3e40: fffffe001c861a00 fffffe001c861a00 ffffffffffffffff 000003ff8350f008
[  123.521199] 3e60: 0000000060000000 fffffe0000224e04 0000000000000003 fffffe03563a0000
[  123.529020] 3e80: 0000000000000000 fffffe0000083a8c 0000000000000200 00000000057cedd8
[  123.536841] 3ea0: ffffffffffffffff fffffe0000083a5c 0000000000000001 0000000005baac80
[  123.544663] 3ec0: ffffffffffffffff 000000000000002e 0000000000000003 0000000005baac80
[  123.552484] 3ee0: 0000000000000001 000003ff8385c750 0000000005790010 0000000000000000
[  123.560305] 3f00: a71b0221bc620500 0000000000000000 0000000000000040 000003ff838bf000
[  123.568126] 3f20: 0000000000000001 0000000000000000 0000000000000000 ffffffffffffffff
[  123.575948] 3f40: 0000000000000000 0000000000000002 0000000000000000 000003ff8350f030
[  123.583769] 3f60: 000003fff54f0d90 0000000005790010 00000000057cedd8 0000000000000000
[  123.591591] 3f80: 000003ff838bf000 000000000597b6d0 00000000057cedf0 000000000597b958
[  123.599412] 3fa0: 0000000000000001 0000000000000001 0000000005baac80 000003fff54f0f80
[  123.607233] 3fc0: 000003ff83831ac8 000003fff54f0f80 000003ff8350f008 0000000060000000
[  123.615055] 3fe0: 0000000000000003 0000000000000040 0000000000000000 0000000000000000
[  123.622875] Call trace:
[  123.625312] Exception stack(0xfffffe03563a3bb0 to 0xfffffe03563a3cd0)
[  123.631743] 3ba0:                                   fffffe001c861a00 0000000000000001
[  123.639565] 3bc0: fffffe03563a3d70 fffffe00004a68dc 0000000000000002 fffffc00166c22b0
[  123.647386] 3be0: fffffe03563a3c00 fffffe000047e9dc fffffe0019cf0200 fffffe00007cecb8
[  123.655208] 3c00: fffffe03563a3c20 fffffe00004808d0 0000000000000000 000000000000000a
[  123.663029] 3c20: fffffe03563a3c60 fffffe0000478b10 fffffe03563a3c60 fffffe00000f7978
[  123.670850] 3c40: fffffe0354420a30 fffffe00000f796c 0000000005baac80 0000000005baac80
[  123.678672] 3c60: 00000000000000aa fffffe03563a3ec8 0000000000000000 fffffdfffae0002e
[  123.686493] 3c80: 000000000000002e 0000000000000000 fffffdfffae0002e 000003ff838bf000
[  123.694314] 3ca0: 0000000000000001 0000000000000000 0000000000000000 ffffffffffffffff
[  123.702135] 3cc0: 0000000000000000 0000000000000002
[  123.707004] [<fffffe00004a68dc>] write_port+0x88/0xf0
[  123.712046] [<fffffe0000223560>] __vfs_write+0x48/0x104
[  123.717262] [<fffffe00002242e4>] vfs_write+0x98/0x198
[  123.722304] [<fffffe0000224e2c>] SyS_write+0x54/0xb0
[  123.727260] [<fffffe0000083a8c>] __sys_trace_return+0x0/0x4
[  123.732823] Code: aa0103e0 52800007 1400000a d5033e9f (390000a2) 
[  123.738971] Starting crashdump kernel...
[  123.745231] Bye!
Comment 17 Jeff Bastian 2016-04-05 10:48:44 EDT
I looked at the sensors-detect source code and found it's using /dev/port instead of /dev/mem.

sub initialize_ioports
{
	if (sysopen(IOPORTS, "/dev/port", O_RDWR)) {
        ...
}

...

sub outb
{
	sysseek(IOPORTS, $_[0], 0);
	syswrite(IOPORTS, pack("C", $_[1]), 1);
}

...

sub smsc_ns_detect_superio
{
	my ($addrreg, $datareg, $ns_chips) = @_;
	my ($val, $chip);

	# read alternate device ID register
	outb($addrreg, 0x0d);

I think this ^^^ outb() call is where it is crashing the kernel.  I'll try to confirm with a simpler program than sensors-detect.
Comment 18 Jeff Bastian 2016-04-05 12:58:17 EDT
I distilled the sensors-detect probe on Super-I/O ports into this really short perl script:

#!/usr/bin/perl -w
# extracted from sensors-detect from lm_sensors
# to reproduce kernel crash on AMD Seattle when
# probing the Super-I/O ports
use Fcntl qw(:DEFAULT :seek);
sysopen(IOPORTS, "/dev/port", O_RDWR);
binmode(IOPORTS);
sysseek(IOPORTS, 0x2e, 0);
syswrite(IOPORTS, pack("C", 0x0d), 1);



This triggers the same kernel panic.

[  351.823920] Unable to handle kernel paging request at virtual address fffffdfffae0002e
...
[  351.844215] Internal error: Oops: 96000047 [#1] SMP
...
[  351.947836] PC is at write_port+0x88/0xf0
[  351.951838] LR is at __vfs_write+0x48/0x104
Comment 19 Al Stone 2016-04-06 17:45 EDT
Created attachment 1144446 [details]
patch sent upstream

This patch "solves" the problem by not creating /dev/port in the first place.  This bug occurs because /dev/port is being used and trying to access IO memory that doesn't exist.  But, /dev/port really makes no sense for arm64 systems, none of which should provide any ISA bus support in the first place.  Unfortunately, providing /dev/port support (i.e., CONFIG_DEVPORT) in the kernel is automatically enabled whenever PCI is enabled.  Hence, this patch disconnects /dev/port from arm64 configurations.
Comment 20 Jeff Bastian 2016-04-18 08:09:32 EDT
*** Bug 1327759 has been marked as a duplicate of this bug. ***
Comment 21 Al Stone 2016-04-20 17:42 EDT
Created attachment 1149209 [details]
LKML -> char: Drop bogus dependency of DEVPORT on !M68K

This patch was submitted to LKML by Geert Uytterhoeven <geert@linux-m68k.org> and replaces the patch originally attached to this BZ.  This solves the problem more cleanly.

Should we really need /dev/port for PCI use, I would recommend we open another BZ for that specific issue since it essentially implies new functionality.
Comment 22 Al Stone 2016-07-15 19:12:00 EDT
Apologies for the delay; there is a brew build here:

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11359874

Patches have been submitted to the RH kernel list.
Comment 23 Al Stone 2016-07-18 16:08:41 EDT
v2 of patches sent to rhelsa kernel list.

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11366806
Comment 25 Erico Nunes 2016-08-17 12:22:07 EDT
Verified on bumblebee.usersys.redhat.com (amd-seattle) and apm-mustang-b0-01.khw.lab.eng.bos.redhat.com, kernel 4.5.0-3.el7.aarch64. HP moonshot was covered by BZ#1290605 which has been verified recently.

On mustang I was still unable to reproduce the problem even with kernel-aarch64-4.5.0-0.46.el7 (which has /dev/port). I was able to reproduce it on seattle with kernel-aarch64-4.5.0-0.46.el7. Both systems seem to work with latest kernel.

There are still the "Use of uninitialized value in concatenation (.) or string at /sbin/sensors-detect line 2880." messages, which can be tracked by BZ#1362664.


mustang:

[root@apm-mustang-b0-01 ~]# uname -r
4.5.0-3.el7.aarch64
[root@apm-mustang-b0-01 ~]# ls /dev/port*
ls: cannot access /dev/port*: No such file or directory
[root@apm-mustang-b0-01 ~]# dmidecode -t 0 | grep -A3 Info
BIOS Information
	Vendor: AppliedMicro
	Version: 1.1.0
	Release Date: Oct 20 2015
[root@apm-mustang-b0-01 ~]# sensors-detect
# sensors-detect revision $Revision$
# System: AppliedMicro Mustang [1.0]
# Kernel: 4.5.0-3.el7.aarch64 aarch64
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
# Processor:  (//)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
/dev/port: No such file or directory

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): 
/dev/port: No such file or directory

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): 
/dev/port: No such file or directory

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): 
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.

Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[root@apm-mustang-b0-01 ~]# sensors -v
sensors version 3.4.0 with libsensors version 3.4.0



seattle:

[root@bumblebee ~]# uname -r
4.5.0-3.el7.aarch64
[root@bumblebee ~]# ls /dev/port*
ls: cannot access /dev/port*: No such file or directory
[root@bumblebee ~]# dmidecode -t 0 | grep -A3 Info
BIOS Information
	Vendor: American Megatrends Inc.
	Version: ROD1001A
	Release Date: 02/09/2016
[root@bumblebee ~]# sensors-detect
# sensors-detect revision $Revision$
# System: AMD Overdrive/Supercharger
# Board: Default string Default string
# Kernel: 4.5.0-3.el7.aarch64 aarch64
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
Use of uninitialized value in concatenation (.) or string at /usr/sbin/sensors-detect line 2880.
# Processor:  (//)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
/dev/port: No such file or directory

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): 
/dev/port: No such file or directory

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): 
/dev/port: No such file or directory

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): 
Sorry, no supported PCI bus adapters found.

Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[root@bumblebee ~]# sensors -v
sensors version 3.4.0 with libsensors version 3.4.0
Comment 27 errata-xmlrpc 2016-11-03 18:28:58 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2145.html

Note You need to log in before you can comment on or make changes to this bug.