[Dri-patches] [Bug #108212] SMP vs. UP for mga modules (w/G400)

[<no...@so...>]

Bug #108212, was updated on 06/24/00 06:58
Here is a current snapshot of the bug.

Project: Direct Rendering Infrastructure
Category: MGA X Server
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: SMP vs. UP for mga modules (w/G400)

Details: In an ongoing battle to get the mga kernel module built,
I noticed that it was a piece of cake in single-processor mode, but analogous to pulling teeth in SMP mode.

Specifically, [using mga-0-0-3-branch circa June 22]:

config/cf/host.def was modified so as to only compile the vga and mga modules, to use LinuxDebian as the distribution, and to make the kernel modules.

After "make World" [no error reported] the modules are still not made when in SMP mode.

If I cd into $CVSROOT/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm, and type "make" [which successfully loads "-f Makefile.linux], the include path fails to supply /usr/src/linux/include, and there are problems reported about missing .ver files in linux/modules from /usr/src/linux/include/linux/modversions.h

To fix this, I used a 'CFLAGS="-I/usr/src/linux/include"' preface to the make command.  This fixes things until the make gets to the i810 modules, where it reports problems with the number of arguments to "do_munmap_Rsmp_e2a39d8a" and fails.

At this point, perhaps I'm in luck since the mga.o module has already been built -- I didn't want the i810 module anyway [right?]  I do a make install, and copy the mga modules into /lib/modules/2.4.0-test1-ac22/misc.

But, this mga.o module has unresolved calls and will not load.  These "unresolved"s are poll_wait, sema_init, spin_lock, etc.  Might it be a simple task of pre-loading another module upon which this depends?  



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=108212&group_id=387