Bug 487520

+++ This bug was initially created as a clone of Bug #487395 +++

Upstream allows one to specify boot line arguments to be passed into modules.

For example,

nohpet nopmtimer powernow_k8.tscsync=1

would pass the tscsync=1 argument into the powernow_k8 module, while nohpet and
nopmtimer would be used by the kernel.

This would be very useful for RHEL4 and according to jcm ;), is a trivial
patch.

Confirmed that this fix correctly results in modules receiving cmdline params.

I tested jcm's changes on gs-dl585g2 by doing the following:

1.  Passing in "nohpet nopmtimer" so that the system used the TSC.  In this case, and as expected, when booting the system displayed

powernow-k8: ph2 null fid transition 0x10

messages indicating that tscsync = 0.

2.  Passing in "nohpet nopmtimer powernow-k8.tscsync=1".  In this case, and as expected, no error messages were displayed.  jcm compiled a kernel that output a confirmation message that the tscsync == 1 and this message was properly output.

3.  Passing in "nohpet nopmtimer powernow_k8.tscsync=1".  This case also passed, as expected.

[Note: The difference between cases 2 and 3 is where we are using a hypen and an underscore in the powernow-k8 module name.  This should work in both cases, because according to jcm there is code to treat the symbols the same.]

This has passed my testing procedure.  The testing was also verified independently by jcm.

Thanks for hustling to get this fix out jcm :)

P.

Please attach the patch, I can't read private comments.
Thanks,
Bhavna

Created attachment 333822 [details]
RHEL4 module-init-tools read kernel command line.

This enhacement is HW specific or specific only when  x86_64 is used?

when I tried to reproduce bug on dl585g2-01 (and used x86_64 system) everything goes ok, as was written. in old version powernow-k8: ph2 null fid transition 0x10 appear in both case.
In new version no message appear when powernow_k8.tstimer is set to 1

but when I tried it on dell-pem605-01 (used i386 system), then no message: 
powernow-k8: ph2 null fid transition 0x10 appeared in both case.

Is this OK?

(In reply to comment #11)
> This enhacement is HW specific or specific only when  x86_64 is used?
> 
> when I tried to reproduce bug on dl585g2-01 (and used x86_64 system) everything
> goes ok, as was written. in old version powernow-k8: ph2 null fid transition
> 0x10 appear in both case.
> In new version no message appear when powernow_k8.tstimer is set to 1
> 
> but when I tried it on dell-pem605-01 (used i386 system), then no message: 
> powernow-k8: ph2 null fid transition 0x10 appeared in both case.
> 

Jan, I just stepped onto these machines to run these tests.

From the changelog for module-init-tools-3.1.0.pre5.3.11

* Thu Feb 26 2009 Jon Masters <jcm> 3.1-0.pre5.3.11
- Read kernel command line for module parameters. [#487520]
- Resolves: #487520

System: dl585g2-01.rhts, RHEL4-U7 base, x86_64

a) module-init-tools-3.1-0.pre5.3.10 booted with "nopmtimer nohpet"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

b) module-init-tools-3.1-0.pre5.3.10 booted with "nopmtimer nohpet powernow-k8.tscsync=1"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

c) module-init-tools-3.1-0.pre5.3.11 booted with "nopmtimer nohpet"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

d) module-init-tools-3.1-0.pre5.3.10 booted with "nopmtimer nohpet powernow-k8.tscsync=1"

[root@gs-dl585g2-01 ~]# dmesg | grep null
[root@gs-dl585g2-01 ~]# 

ie) tscsync = 1 (as expected!)

System: dell-pem605-01.rhts , RHEL4-U7 base, i386

seems to work regardless whether "powernow-k8.tscsync=1" is specified or not.  This is because the core failure here, that the powernow-k8 driver is not working as expected, is not a 100% failure.

Because the dl585g2 shows a near 100% failure rate, I am going to install RHEL4U7 base on it and perform the same set of tests as above.

P.

>Because the dl585g2 shows a near 100% failure rate, I am going to install
>RHEL4U7 base on it and perform the same set of tests as above.

s/RHEL4U7 base/RHEL4U7 i386 base/g

P.

System: dl585g2-01.rhts, RHEL4-U7 base, i386

a) module-init-tools-3.1-0.pre5.3.10 booted with "clock=tsc"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

b) module-init-tools-3.1-0.pre5.3.10 booted with "clock=tsc
powernow-k8.tscsync=1"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

c) module-init-tools-3.1-0.pre5.3.11 booted with "clock=tsc"

[root@gs-dl585g2-01 ~]# dmesg | grep null
powernow-k8: ph2 null fid transition 0x10
powernow-k8: ph2 null fid transition 0x10

ie) tscsync = 0

d) module-init-tools-3.1-0.pre5.3.11 booted with "clock=tsc
powernow-k8.tscsync=1"

[root@gs-dl585g2-01 ~]# dmesg | grep null
[root@gs-dl585g2-01 ~]# 

ie) tscsync = 1 (as expected)

IMO, this passes QA.

P.

Proposing for 4.7.z as a potential data corrupter

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1028.html