Bug 972606 - Fedora19:beta: rpadlpar_io kernel module is not available by default for powerpc/pseries
Fedora19:beta: rpadlpar_io kernel module is not available by default for powe...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: powerpc-utils (Show other bugs)
19
ppc64 All
unspecified Severity medium
: ---
: ---
Assigned To: Vasant Hegde
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-10 04:20 EDT by IBM Bug Proxy
Modified: 2013-10-08 07:20 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 00:07:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Check for rpadlpar_io module presence for slot/phb DLPAR (1.17 KB, text/plain)
2013-06-18 11:43 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 94319 None None None Never

  None (edit)
Description IBM Bug Proxy 2013-06-10 04:20:54 EDT
== Comment: #0 - Sanjeev Patro <sanpatr1@in.ibm.com> - 2013-06-03 02:18:43 ==
rpadlpar_io kernel module is not available by default for powerpc/pseries version of Fedora19 as it available for RHEL,

Because of that while enabling HOTPLUG and DLPAR for Fedora19 Lpar, after installing rsct and src we did not find DLPAR option for IO. By clicking "Retrive capabillities" button in partition properties > General Tab > Dynamic logical partion pan of IVM, we can see
Fedora 19
Dynamic Logical Partitioning (DLPAR)
Partition hostname or IP address: 	<IPaddr>
Partition communication state: 	Active
Memory DLPAR capable: 	Yes
Processing DLPAR capable: 	Yes
I/O adapter DLPAR capable: 	No

To make this available we need to install rpadlpar_io kernel module explicitly.
modprobe rpadlpar_io

== Comment: #1 - Sanjeev Patro <sanpatr1@in.ibm.com> - 2013-06-03 08:44:36 ==
Please look into the comment 7, comment 8 and comment 10 of bz 93928 for more information.

== Comment: #2 - Brent J. Baude <baude@us.ibm.com> - 2013-06-05 15:32:01 ==
Whats being asked here?

== Comment: #3 - Sanjeev Patro <sanpatr1@in.ibm.com> - 2013-06-06 02:57:44 ==
(In reply to comment #2)
> Whats being asked here?

Whenever we reboot the F19 lpar rpadlpar_io is not loaded by default. User has to load it explictly.
modprobe rpadlpar_io
 We want rpadlpar_io to be loaded by default whenever the F19 boots up as RHEL 6.3 distro

== Comment: #4 - Onkar N. Mahajan <onmahaja@in.ibm.com> - 2013-06-10 04:09:18 ==
Hi Sanjeev, 

RHEL 6.3 :

rpadlpar_core is built into the kernel - 

# uname -a
Linux miz07.xxxxxxxx 2.6.32-279.el6.ppc64 #1 SMP Wed Jun 13 18:19:27 EDT 2012 ppc64 ppc64 ppc64 GNU/Linux

# cat /boot/config-2.6.32-279.el6.ppc64 | grep CONFIG_HOTPLUG_PCI_RPA_DLPAR
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y

Fedora 19 :

rpadlpar_core compiled as module - 

# uname -a
Linux miz10.xxxxxxxx 3.9.2-301.fc19.ppc64p7 #1 SMP Mon May 13 09:20:53 MST 2013 ppc64 ppc64 ppc64 GNU/Linux

# cat /boot/config-3.9.2-301.fc19.ppc64p7 | grep CONFIG_HOTPLUG_PCI_RPA_DLPAR
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m


fedora 17 & 18 also it was CONFIG_HOTPLUG_PCI_RPA_DLPAR=y 

Not sure if this has been intentionally done for some specific reason or is it a regression from fedora 18 ? 

Regards,
Onkar
Comment 1 IBM Bug Proxy 2013-06-13 02:05:51 EDT
------- Comment From onmahaja@in.ibm.com 2013-06-13 05:54 EDT-------
Red Hat,
Any updates here ?
Comment 2 Josh Boyer 2013-06-13 07:36:06 EDT
It's still set =y in our config fragments, so something in the upstream kernel Kconfig settings is forcing it to =m.
Comment 3 Josh Boyer 2013-06-13 07:49:39 EDT
(In reply to IBM Bug Proxy from comment #0) 
> Fedora 19 :
> 
> rpadlpar_core compiled as module - 
> 
> # uname -a
> Linux miz10.xxxxxxxx 3.9.2-301.fc19.ppc64p7 #1 SMP Mon May 13 09:20:53 MST
> 2013 ppc64 ppc64 ppc64 GNU/Linux
> 
> # cat /boot/config-3.9.2-301.fc19.ppc64p7 | grep CONFIG_HOTPLUG_PCI_RPA_DLPAR
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> 
> 
> fedora 17 & 18 also it was CONFIG_HOTPLUG_PCI_RPA_DLPAR=y 
> 
> Not sure if this has been intentionally done for some specific reason or is
> it a regression from fedora 18 ? 

Both the ppc64 and ppc64p7 F18 GA kernels have this =m.

config-3.6.10-4.fc18.ppc64p7:

CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m

The F17 GA kernel also has it set modular.

config-3.3.4-5.fc17.ppc64:

CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m

So it's getting set to =m because PCI_RPA is modular and PCI_RPA_DLPAR depends on that.  Our config fragments for these options haven't changed since at least the initial import of our packages into git.  That was in 2010.

If you have F17 and F18 kernels that have the option set to =y, I would like to know which specific kernels those are.  Please point me to them in ppc.koji.fedoraproject.org.
Comment 4 IBM Bug Proxy 2013-06-18 02:50:33 EDT
------- Comment From onmahaja@in.ibm.com 2013-06-18 06:43 EDT-------
(In reply to comment #10)
> It's still set =y in our config fragments, so something in the upstream
> kernel Kconfig settings is forcing it to =m.
> (In reply to IBM Bug Proxy from comment #0)
> > Fedora 19 :
> >
> > rpadlpar_core compiled as module -
> >
> > # uname -a
> > Linux miz10.xxxxxxxx 3.9.2-301.fc19.ppc64p7 #1 SMP Mon May 13 09:20:53 MST
> > 2013 ppc64 ppc64 ppc64 GNU/Linux
> >
> > # cat /boot/config-3.9.2-301.fc19.ppc64p7 | grep CONFIG_HOTPLUG_PCI_RPA_DLPAR
> > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> >
> >
> > fedora 17 & 18 also it was CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
> >
> > Not sure if this has been intentionally done for some specific reason or is
> > it a regression from fedora 18 ?
> Both the ppc64 and ppc64p7 F18 GA kernels have this =m.
> config-3.6.10-4.fc18.ppc64p7:
> CONFIG_HOTPLUG_PCI_RPA=m

fedora 18:
http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=161198

[linux-3.9.4-200.el6.x86_64]$ cat config-powerpc64 | grep CONFIG_HOTPLUG_PCI_RPA
[linux-3.9.4-200.el6.x86_64]$ cat config-powerpc64p7 | grep CONFIG_HOTPLUG_PCI_RPA
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y

> The F17 GA kernel also has it set modular.
> config-3.3.4-5.fc17.ppc64:
>
> CONFIG_HOTPLUG_PCI_RPA=m
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
>

fedora 17 :
http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=166124

[linux-3.9.6-100.el6.x86_64]$ cat config-powerpc64 | grep CONFIG_HOTPLUG_PCI_RPA
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
[linux-3.9.6-100.el6.x86_64]$ cat config-powerpc64p7 | grep CONFIG_HOTPLUG_PCI_RPA
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y

> So it's getting set to =m because PCI_RPA is modular and PCI_RPA_DLPAR
> depends on that.  Our config fragments for these options haven't changed
> since at least the initial import of our packages into git.  That was in
> 2010.
>
> If you have F17 and F18 kernels that have the option set to =y, I would like
> to know which specific kernels those are.  Please point me to them in
> ppc.koji.fedoraproject.org.

Regards,
Onkar
Comment 5 Josh Boyer 2013-06-18 07:43:33 EDT
(In reply to IBM Bug Proxy from comment #4)
> ------- Comment From onmahaja@in.ibm.com 2013-06-18 06:43 EDT-------
> (In reply to comment #10)
> > It's still set =y in our config fragments, so something in the upstream
> > kernel Kconfig settings is forcing it to =m.
> > (In reply to IBM Bug Proxy from comment #0)
> > > Fedora 19 :
> > >
> > > rpadlpar_core compiled as module -
> > >
> > > # uname -a
> > > Linux miz10.xxxxxxxx 3.9.2-301.fc19.ppc64p7 #1 SMP Mon May 13 09:20:53 MST
> > > 2013 ppc64 ppc64 ppc64 GNU/Linux
> > >
> > > # cat /boot/config-3.9.2-301.fc19.ppc64p7 | grep CONFIG_HOTPLUG_PCI_RPA_DLPAR
> > > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > >
> > >
> > > fedora 17 & 18 also it was CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
> > >
> > > Not sure if this has been intentionally done for some specific reason or is
> > > it a regression from fedora 18 ?
> > Both the ppc64 and ppc64p7 F18 GA kernels have this =m.
> > config-3.6.10-4.fc18.ppc64p7:
> > CONFIG_HOTPLUG_PCI_RPA=m
> 
> fedora 18:
> http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=161198
> 
> [linux-3.9.4-200.el6.x86_64]$ cat config-powerpc64 | grep
> CONFIG_HOTPLUG_PCI_RPA
> [linux-3.9.4-200.el6.x86_64]$ cat config-powerpc64p7 | grep
> CONFIG_HOTPLUG_PCI_RPA
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
> 
> > The F17 GA kernel also has it set modular.
> > config-3.3.4-5.fc17.ppc64:
> >
> > CONFIG_HOTPLUG_PCI_RPA=m
> > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> >
> 
> fedora 17 :
> http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=166124
> 
> [linux-3.9.6-100.el6.x86_64]$ cat config-powerpc64 | grep
> CONFIG_HOTPLUG_PCI_RPA
> CONFIG_HOTPLUG_PCI_RPA=m
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
> [linux-3.9.6-100.el6.x86_64]$ cat config-powerpc64p7 | grep
> CONFIG_HOTPLUG_PCI_RPA
> CONFIG_HOTPLUG_PCI_RPA=m
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=y

So those are the config fragments.  They aren't the resulting full config file.  As I said in comment #2, we still have the config fragments set that way.

If you actually download the kernel that gets installed and not the SRPM, and you look at the /boot/config-3.9.4-200.fc18.ppc64 file, you'll see:

CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m

So I'm confused as to how you view this as a regression.
Comment 6 IBM Bug Proxy 2013-06-18 11:01:38 EDT
------- Comment From nfonteno@us.ibm.com 2013-06-18 14:59 EDT-------
It appears the issue here is that the rpadlpar_io module is loaded by default or built into the kernel for Fedora. This is something we asked to have for RHEL though I forget whether we asked to have the module loaded by default or built into the kernel for Power.

I have a patch for the drmgr command that checks to see if the modules is present and attempts to load it if it is not. I do not have a machine to test this on however, anyone have a system I can borrow to test this out?
Comment 7 IBM Bug Proxy 2013-06-18 11:43:43 EDT
Created attachment 762546 [details]
Check for rpadlpar_io module presence for slot/phb DLPAR


------- Comment on attachment From nfonteno@us.ibm.com 2013-06-18 15:36 EDT-------


This is the patch I sent upstream to check for the presence of the rpadlpar_io kernel module when checking slot and phb DLPAR capabilities.
Comment 8 IBM Bug Proxy 2013-06-25 10:50:36 EDT
------- Comment From nfonteno@us.ibm.com 2013-06-25 14:47 EDT-------
The patch for drmgr to check for the presence of the rpadlpar_io module is upstream:

commit id: ff981e0e...
Comment 11 IBM Bug Proxy 2013-10-08 07:20:47 EDT
------- Comment From shubgoya@in.ibm.com 2013-10-08 11:13 EDT-------
I tried this on pre alpha (non official) release & could reproduce the issue. The rpadlpar_io kernel module is not available by default. Below are the details:

[root@juno-ioxc1-lp1 ~]# uname -a
Linux juno-ioxc1-lp1.xxx.ibm.com 3.11.0-300.fc20.ppc64p7 #1 SMP Thu Sep 5 16:13:50 MST 2013 ppc64 ppc64 ppc64 GNU/Linux
[root@juno-ioxc1-lp1 ~]# cat /etc/issue
Fedora release 20 (Heisenbug)
Kernel \r on an \m (\l)

[root@juno-ioxc1-lp1 ~]# lsmod | grep rpadlpar_io
[root@juno-ioxc1-lp1 ~]#

Below is the ISO I used for bug verification:

http://ppc.koji.fedoraproject.org/stage/f20-20131002-RC4.1/Fedora/ppc64/iso/

Reopening this bug in F20.

Thanks, Shubham

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