Loading module compiled on differenet version in 2.6 kernel
 

Hi,

I have query on module insertions.

While inserting the module with only a release version mismatch *2.6.5-<release version>), the kernel gives the following error:

Unresoved symbols in ...

In 2.4, we used to compile the module setting the module version (CONFIG_MODVERSIONS - MOdule versioning ) off, and forcefully inserting and it used to insert giving warnings. This does not work with 2.6.

I read a little about this and it said that earlier insmod used to relocate the addresses, wheras now, this is the responsibility of the kernel. (modutils has been changed to module-init-tools)
Reference: http://howtos.linux.com/howtos/Modul...s.shtml#AEN899

Is there any workaround, by which we can a module compiled in a different version in a kernel of a different version (with respect to the last release number only)?

Shrey

Did you compile your kernel with module versioning support (off by default)? I think that's the first step.
ta0kira

Hi ta0kira,

I did compile the code with module versioning supportoff, but it did not help. I am still receiveing the same error :

shrey

Try `nm <module name>.ko | grep "(\t| )U "` and post the output. The only things that should show up are the functions that interface with the kernel, such as the module loading/unloading functions. Has the module successfully loaded (as currently built) with the old kernel? If you are using gcc 4.0.x, that has a problem compiling modules.
ta0kira

Hi Ta0kira,

here Is the output I got from the module.
Could you please let me know, what to interpret from it.?

# nm main_mod.ko | grep U
U __copy_user
U __divsi3
U __kmalloc
U __mod_timer
U __register_filesystem
U __tasklet_schedule
U __wake_up
U allow_signal
U autoremove_wake_function
U bio_add_page
U bio_alloc
U bio_put
U call_rcu
U class_simple_create
U class_simple_destroy
U class_simple_device_add
U class_simple_device_remove
U close_bdev_excl
U daemonize
U finish_wait
U free_pages
U generic_file_read
U generic_file_write
U get_fs_type
U get_zeroed_page
U ia64_spinlock_contention
U jiffies
U kernel_flag
U kernel_thread
U kfree
U kill_anon_super
U kmem_cache_alloc
U malloc_sizes
U memcpy
U memset
U open_bdev_excl
U prepare_to_wait
U printk
U recalc_sigpending
U register_chrdev
U schedule
U sock_create
U sock_recvmsg
U sock_release
U sock_sendmsg
U sock_setsockopt
U strncmp
U strncpy
U submit_bio
U tasklet_init
U truncate_inode_pages
U unregister_chrdev
U unregister_filesystem
U vmem_map
U wake_up_process

regards
Shrey

I can see several things:

1) It looks like you have some sort of 64 bit numerical operation somewhere (__divsi3)
2) It looks like you need to link with a standard lib (memcpy, memset, etc.)
3) You might need to link with some other .o file that is part of the package

2.6 modules compile a lot differently than 2.4 modules; with 2.6, you pretty much say "do whatever the kernel makefile does, but with my module", and with 2.4 you actually write out the commands. Also, with 2.4 you can't link things because the module really is just an object file, whereas the .ko files for 2.6 are linked.

If you do `ls -A` in your make directory then you should see 3 hidden files (after building); one for .o, one for .ko, and one for ...mod.o (I think). Each of these files shows the command used to compile.

Can you post the compilation command used in the makefile for a build that worked and could be loaded (or the whole file if it's short, as in 20 lines or less)? I don't think you can just "build as usual" with this; I think you'll need to write out the command line and link with libstdc.a (the static version as opposed to the .so dynamic version); AFAIK modules don't dynamically link automatically. If you actually do have a 64 bit operation, I don't know what to do about that other than to convert it to a 32 bit operation.
ta0kira

I was reading this thread with interest, as I have been trying unsuccessfully to enable hardware acceleration in my 2.6.12-12mdk kernel under Mandriva.

My graphics card is a Hercules Prophet 4500 64MB with the Kyro II chip.

Powervr supported this card with the 2.4 kernels, however, they didnt release the source, and do not support this card under 2.6 kernels.

Trying to force the loading of powervr.o into a 2.6 kernel isn't working (I think) because Powervr inserted some of their own 'specifics' into their Makefiles, and 2.6 doesnt recognise them.

Apart from buy a new card, what options do you think I have? Have been looking into the possibilities of reverse engineering the old module to obtain source. Is this feasable/do-able you think?

Thanks in advance

googleing i could find the 2.1 version of the sources. the readme reports that this version should work on 2.4.x kernels and 2.5.8 and above as well.

i dont really know if this means that even 2.6 kernel could run that module, but the sources are there to be hacked by someone (i hope)

bye

go read this post, a fb device driver for kyro is natively included in 2.6 kernel tree:
http://www.linuxquestions.org/questi...d.php?t=480102