Bug 487520 - FEATURE: enable runtime scanning of boot args during a module load
FEATURE: enable runtime scanning of boot args during a module load
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: module-init-tools (Show other bugs)
4.8
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Jon Masters
BaseOS QE
: ZStream
Depends On: 487395
Blocks: 490677
  Show dependency treegraph
 
Reported: 2009-02-26 09:46 EST by Prarit Bhargava
Modified: 2009-05-18 16:36 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 487395
Environment:
Last Closed: 2009-05-18 16:36:58 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)
RHEL4 module-init-tools read kernel command line. (2.69 KB, patch)
2009-03-02 22:15 EST, Jon Masters
no flags Details | Diff

  None (edit)
Comment 1 Prarit Bhargava 2009-02-26 09:47:06 EST
+++ 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.
Comment 7 Jon Masters 2009-02-26 16:31:07 EST
Confirmed that this fix correctly results in modules receiving cmdline params.
Comment 8 Prarit Bhargava 2009-02-26 17:33:13 EST
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.
Comment 9 Bhavna Sarathy 2009-02-26 22:22:41 EST
Please attach the patch, I can't read private comments.
Thanks,
Bhavna
Comment 10 Jon Masters 2009-03-02 22:15:01 EST
Created attachment 333822 [details]
RHEL4 module-init-tools read kernel command line.
Comment 11 Jan Ščotka 2009-03-04 04:29:05 EST
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?
Comment 12 Prarit Bhargava 2009-03-04 08:45:58 EST
(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@redhat.com> 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.
Comment 13 Prarit Bhargava 2009-03-04 08:47:31 EST
>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.
Comment 14 Prarit Bhargava 2009-03-04 09:27:23 EST
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.
Comment 17 Jiri Skrabal 2009-03-17 11:57:03 EDT
Proposing for 4.7.z as a potential data corrupter
Comment 19 errata-xmlrpc 2009-05-18 16:36:58 EDT
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

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