Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1370161

Summary: s390x standby memory automatically onlined after boot
Product: Red Hat Enterprise Linux 7 Reporter: Milos Vyletel <milos>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Branislav Blaškovič <bblaskov>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.2CC: bblaskov, bugproxy, fkrska, fsumsal, hannsj_uhl, lnykryn, mkolaja, mrdest, msekleta, snagar, systemd-maint-list, tlavigne
Target Milestone: rcKeywords: Regression, ZStream
Target Release: 7.3   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: systemd-219-30.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1375603 1381123 1381885 (view as bug list) Environment:
Last Closed: 2016-11-04 00:56:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1230910, 1375603, 1381123, 1381885    

Description Milos Vyletel 2016-08-25 12:16:56 UTC
Description of problem:
Starting with RHEL 7.2 standby memory on z/VM is automatically onlined whereas
it should stay offline until it is manually onlined later on when needed.

I've tracked this down to systemd BZ 1105020 that added udev rule to auto
online newly added memory. This works on some architectures but causes this
regression on z/VM where the hotplug memory is always present but only onlined
when needed. Relevant commit

https://github.com/lnykryn/systemd-rhel/commit/57adc4317ee2553d2d3ac84ef9625ed9c1cf5700

Version-Release number of selected component (if applicable):
systemd-219-19.el7_2.12.s390x

How reproducible:
always

Steps to Reproduce:
1. create z/VM with standby memory

USER XXXXX YYYYY 1G 2G GC
COMMAND DEFINE STORAGE 1G STANDBY 1G
COMMAND SET RUN ON

2. boot

Actual results:
[root@ibm-z-03 ~]# lsmem -a
Address Range                          Size (MB)  State    Removable  Device
===============================================================================
0x0000000000000000-0x000000000fffffff        256  online   no         0-127
0x0000000010000000-0x000000001fffffff        256  online   yes        128-255
0x0000000020000000-0x000000002fffffff        256  online   yes        256-383
0x0000000030000000-0x000000003fffffff        256  online   no         384-511
0x0000000040000000-0x000000004fffffff        256  online   no         512-639
0x0000000050000000-0x000000005fffffff        256  online   no         640-767
0x0000000060000000-0x000000006fffffff        256  online   no         768-895
0x0000000070000000-0x000000007fffffff        256  online   no         896-1023

Expected results:
[root@ibm-z-03 ~]# lsmem  -a
Address Range                          Size (MB)  State    Removable  Device
===============================================================================
0x0000000000000000-0x000000000fffffff        256  online   no         0-127
0x0000000010000000-0x000000001fffffff        256  online   yes        128-255
0x0000000020000000-0x000000002fffffff        256  online   yes        256-383
0x0000000030000000-0x000000003fffffff        256  online   no         384-511
0x0000000040000000-0x000000004fffffff        256  offline  -          512-639
0x0000000050000000-0x000000005fffffff        256  offline  -          640-767
0x0000000060000000-0x000000006fffffff        256  offline  -          768-895
0x0000000070000000-0x000000007fffffff        256  offline  -          896-1023

Additional info:

Comment 3 Michal Sekletar 2016-08-26 11:31:40 UTC
I guess we could make this udev rule conditional and skip it on z/VM systems. Can you please provide output of systemd-detect-virt from this machine?

Comment 4 Milos Vyletel 2016-08-26 11:35:28 UTC
sure

[root@ibm-z-03 ~]# systemd-detect-virt
zvm

Comment 6 Michal Sekletar 2016-08-26 14:19:38 UTC
I modified udev rule as follows,

SUBSYSTEM=="memory", ACTION=="add", PROGRAM="/usr/bin/systemd-detect-virt", RESULT!="zvm", ATTR{state}=="offline", ATTR{state}="online"

This rule was confirmed to work as expected by Milos.

Comment 9 Milos Vyletel 2016-09-13 10:29:50 UTC
Michal,

turns out this is not only z/VM problem as IBM reports. This is what we were told

"Rereading the Bugzilla, I found
that the problem description seems to be limited to z/VM environment.
Actually the problem occurs even in native LPAR."

I've asked for systemd-virt-detect output to see if we can simply tweak the
rule to this additional platform.

Milos

Comment 22 errata-xmlrpc 2016-11-04 00:56:12 UTC
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-2216.html