Bug 28615 - kernel-2.2.17-14 unresolved symbols for s{d,r}_mod.o
kernel-2.2.17-14 unresolved symbols for s{d,r}_mod.o
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-21 10:36 EST by diego.santacruz
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:38:55 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)

  None (edit)
Description diego.santacruz 2001-02-21 10:36:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14cstm i686)


When compiling the kernel (from kernel-sources-2.2.17-14) and selecting the
SCSI disk (sd_mod) and CD-ROM (sr_mod) to build as modules, depmod reports
undefined symbols, and the modules fail to load. The missing symbol is
"req_finished_io".

Reproducible: Always
Steps to Reproduce:
1. config the kernel to build sd_mod and sr_mod as modules.
2. compile the kernel, compile the modules, install and boot
3. try to access SCSI disk (e.g. ZIP drive with ppa) or SCSI CDROM
	

Actual Results:  Module sd_mod and sr_mod cannot be loaded.

Adding the following line at the end of
/usr/src/linux-2.2.17/drivers/block/ll_rw_blk.c
fixes the problem:

EXPORT_SYMBOL(req_finished_io);
Comment 1 brm 2001-02-24 08:37:28 EST
The same problem applies to all compiled modules with module versioning on
symbols
when rebuilding from  kernel-source-2.2.17-14.i386.rpm

I notice that the SPEC file in kernel-2.2.17-14.src.rpm hand-massages the files 
include/linux/{autoconf,modversion,versions}.h to add the line
    #include <linux/rhconfig.h>
but the normal "make config; make dep" overwrites these files with ones not
containing
this line, so the version info is different for the built kernel.  
Apparently without this line, other RedHat patches to the kernel yield some
inconsistent 
set of preprocessor definitions and #ifdefs that yield either inconsistent
symbol naming, 
or illegal C code (I've encountered both, with slightly different .config, just
today).  

Adding the #include above to the beginning of each of the three include files
(after make dep) 
seems to fix the problem.   The traditional make mrproper; make config; make
dep; make clean;
make bzImage; make modules; make modules_install (which is, I note, still
described in
the rhl-rg-6.2en documentation) is broken with this package.

The real solution is to add a patch is needed in the makefiles so that "make
config" 
("... xconfig", "... menuconfig") and then "make dep" does the same thing.
Comment 2 brm 2001-02-24 09:19:19 EST
Oops, I now see that my problem is something different, since I also have their
problem, even when I fix my problem.  Well, I would have the problem if I had
a SCSI drive to worry about.  Too bad I can't see a way to revoke a comment.
Comment 3 Bugzilla owner 2004-09-30 11:38:55 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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