Bug 11488 - Rebuilding kernel RPM produces bad emu10k1 module
Summary: Rebuilding kernel RPM produces bad emu10k1 module
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-05-17 18:35 UTC by Jos Vos
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-06-13 22:40:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jos Vos 2000-05-17 18:35:17 UTC
When rebuilding the kernel-2.2.14-12 package (rpm --rebuild --target i686
kernel-2.2.14-12.src.rpm) the emu10k1 module appears to be wrong.  Depmod
complains about unresolved symbols and loading the module gives a list of
unresolved symbols (quite standard functions etc.).  This problem does not
occur with any other module and is fully reproducable.

Comment 1 tibbitts 2000-06-13 22:40:16 UTC
I have two "unresolved" depmod errors when building a 586 kernel
from RH6.2 cd source.
	1. wanpipe.o - can't get rid of this one.
	2. emu10k1.o - this one occurs whenever I build a new kernel,
           BUT if I then rebuild the modules AGAIN after installing
           the new kernel, it goes away.  And yes, the old and new
           emu10k01.o files are indeed different.  I did this twice
           with the same result and don't feel like doing it again
           because it takes so long, but would love to get rid of
           the wanpipe.o error (without adding -q to rc.sysinit,
           which does do the job!).
Oh, I'm using a new kernel name every time so there should be no old
modules "left over".

Paul Tibbitts

Comment 2 Michael K. Johnson 2000-08-01 22:29:52 UTC
The first of tibbits' problems we haven't seen as far as I know.
Try the 2.2.16-3 kernel and see if it still occurs.

The other problem didn't occur on our build system but did occur
on other systems and did occur in our beta so we were able to
fix it in the current beta SRPM; if we release another errata
kernel for 6.2 that fix should migrate.

The fix is in drivers/sound/Makefile to change
SUB_DIRS := emu10k1
MOD_SUB_DIRS := emu10k1

Our most recent beta kernel SRPM uses a newer emu10k1
driver that fixes this in a more complete way, and also allows
you to compile emu10k1 into the kernel.

I'll assume that these suggestions fix the problems; re-open this
bug if I'm wrong.

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