Bug 11488

Summary:	Rebuilding kernel RPM produces bad emu10k1 module
Product:	[Retired] Red Hat Linux	Reporter:	Jos Vos <jos>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	tibbitts
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-06-13 22:40:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
to
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.