Under the 2.6.0 kernel, all modules have name *.ko, not the old name *.o. Maybe you have to rename the module as a .ko file. Also make sure that your modprobe (or insmod) is from the new module-init-tools package and not the old modutils package.
P~Manalastas ======== Quoting JM Ibanez <[EMAIL PROTECTED]>: > Here is an interesting problem: I have a binary-only kernel module > (for > my Motorola SM56 WinModem). Now, before any of you tell me to get a > *real* modem, tbat's currently not an option for me. The binary has > already been kludged to work under recent 2.4.x kernels. What > interests > me, however, is making it work under the 2.6 test kernel (and, by > reasoning, the latter 2.5.x kernels). > > What's preventing it from working in the 2.6.0-test3 kernel, you ask? > I've already figured out how to kludge the module enough so the 2.6 > module loader thinks it's a module built for that kernel. The problem > lies in the module itself. Several functions are defined *twice* > inside > the object file. That alone should have prevented it from even > *loading* > under 2.4, but for some strange reason the 2.4 kernel loader doesn't > even notice. (FWIW, the 2.5.x/2.6 module loader was drastically > modified > by the maintainer). > > Inside the symbol table, these particular functions have two symbol > entries (same name)-- one is a pointer to the actual code (the .text > entry), and another is a relocation entry (hence, marked undefined in > the symbol table). The relocation entries are what prevents it being > loaded by the newer loader-- these functions are marked as being > "undefined". > > The question then is, how were they duplicated in the first place? > > I've been trying to duplicate that situation-- I'm guessing that one > code file used a particular definition, while another used a different > one for the same function. I haven't been successful with it though. > Any > ideas? It could help me kludge it. I'm more or less out of my league > on > this one. I'm studying the ELF file format, as well as the BFD docs, > in > hopes that they could shed light on it. > > (Of course, one way to go around the problem is to extract the > relevant > object file from the grand .o (which, to my knowledge has been linked > with ld -r, and the object file tells me that). I doubt it's possible, > and reading through objcopy has not been helpful. Another way is to > patch the kernel module loader at the source (and recompile)-- > something > I don't recommend and will not be doing, really.) > > FYI, I've attached the objdump -t output for the file, as well as the > list of functions that have duplicate entries. > > Notes: > 1) Tools used for the whole shebang include Mark Spieth's > fixscript.sh, > the objdump and objcopy from GNU binutils 2.12.90. I can't recall the > exact URL for fixscript, but a Google should turn up something. > 2) The binary in question can be downloaded either in its pure form as > an RPM from the Motorola website, or in kludged form at > http://www.sm56.tk . Look for the file /usr/local/sm56/sm56.lib . > > > -- > Jan Michael Ibanez > Student > > CELL +63919 422 1141 > WEB one Generic lizard Geek's LiveJournal > http://www.livejournal.com/~cyberlizard > WEB CyberLizard productions (coming soon) > http://www.mycgiserver.com/~butiki -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
