Bug 236424 - [RHEL5 RT] GPL / NonGPL Module testing fails on x86_64
[RHEL5 RT] GPL / NonGPL Module testing fails on x86_64
Status: CLOSED NOTABUG
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel (Show other bugs)
1.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Don Zickus
http://rhts.lab.boston.redhat.com/cgi...
:
Depends On: 253476
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-13 16:17 EDT by Jeff Burke
Modified: 2008-02-27 14:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 13:41:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Burke 2007-04-13 16:17:31 EDT
Description of problem:
RHTS test /kernel/drivers/3rd-party fail on x86_64

Version-Release number of selected component (if applicable):
 2.6.20-14.el5rt

How reproducible:
 Always

Steps to Reproduce:
1. Run the /kernel/drivers/3rd-party on x86_64
  
Actual results:
 Kernel is not tainted at this time
 Running GPLModule
 Module installed: GPLModule 
 Kernel is not tainted at this time
 GPLModule test Failed:

Expected results:
 This test should pass

Additional info:
 With the same kernel version this test works on i386 but fails on x86_64.

Test that passes:
http://rhts.lab.boston.redhat.com/cgi-bin/rhts/recipes.cgi?id=73492


###############################################################################
Here is a link to the kernel
 http://porkchop.redhat.com/brewroot/packages/kernel-rt/2.6.20/14.el5rt/

Here is information on how to setup a local system to use the RHTS devel
environment.

You can down load the tests from here:
http://rhts.lab.boston.redhat.com/rpms/development/noarch/noarch/rh-tests-kernel-drivers-3rd-party-1.9-10.noarch.rpm

This test it written for the RHTS environment. So you can install the
RHTS devel package following the directions from here:
 http://intranet.corp.redhat.com/ic/intranet/RHTSMainPage.html
then install the test and do a make run.

Or if you do _not_ want to install the RHTS devel stuff comment out the
following:
Makefile
# Include a global make rules file
include /usr/share/rhts/lib/rhts-make.include

runtest.sh
# Source the common test script helpers
. /usr/bin/rhts_environment.sh

then do a make run.
Comment 1 Jeff Burke 2007-05-22 09:21:06 EDT
This is failing in the latest kernel 2.6.21-11.el5rt:

/kernel/drivers/3rd-party
Completed - Fail
	GPLModule 	Fail 	0
	NonGPLModule 	Fail 	0
	BadModuleSign 	Pass 	0
	GoodModuleSign 	Pass 	0

http://rhts.lab.boston.redhat.com/cgi-bin/rhts/jobs.cgi?id=773&type=Single
Recipe 2854

Comment 3 David Howells 2007-07-23 10:08:00 EDT
This may be due to the test script making assumptions about its operating 
environment:

 (1) /proc/sys/kernel/print-fatal-signals does not appear to exist in the 
kernel specified, yet CheckUnsignModule() attempts to make use of it.

 (2) The killme.sh script does not appear to leave anything in the dmesg log, 
but CheckUnsignModule() appears to rely on it saying something.

What kernel were these scripts meant to test?
Comment 4 Don Zickus 2007-07-23 10:44:55 EDT
These scripts were designed for RHEL-5.  The execshield patch puts the
print-fatal-signals functionality into the kernel.  So yeah, if the kernel
doesn't have print-fatal-signal, the test won't do much.  Unless someone has
another way to detect if a 'bad' kernel module tainted the kernel using a
userspace app?
Comment 5 Jon Masters 2007-08-20 03:28:21 EDT
Like 253476 perhaps.

Jon.
Comment 6 Jeff Burke 2007-10-17 12:00:05 EDT
Jon,
   Do we have any additional data on this issue? Are we going to try and fix it
for RT?

Jeff
Comment 8 Don Zickus 2007-10-17 13:21:21 EDT
Jeff,

This test is really RHEL-5 specific.  We should be able to modify it to utilize
the output of /proc/modules now.  Upstream added a patch to display the taint
flags to that proc file.   I am working with Jon to backport this to RHEL-5 so
we can better test across all the arches.  Once those changes are in, we can
modify the script to take advantage of the proc file and then the test should
automatically become forward compatible (with RT/RHEL-6, etc).
Comment 9 Clark Williams 2008-02-06 11:41:41 EST
Where do we stand on this bug, wrt RT?
Comment 10 Jeff Burke 2008-02-12 13:41:21 EST
Clark,
  As discusses on IRC and verbally. This test is of no value to the RT kernel

Jeff

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