Skip to contentSkip to conversation

Module Relocation Problem

parisc-linux Kai Holthaus 5 participants 10 messages Jun 6, 2006 – Jun 14, 2006

lore
Share & tools
lore
#0 lore raw

Hi,

I'm trying to compile and install the qc-usb (http://qce-ga.sourceforge.net/)
kernel module on my A5005X server. Compilation works just fine (make all && make install), but upon insmodding I get the following error:

Module quickcam, symbol qc_proc_init is out of range for PCREL22F relocation
FATAL: Error inserting quickcam (/lib/modules/2.6.16-pa11/misc/quickcam.ko):
Invalid module format

I've searched on google (in general) and on this mailing list for help on this topic, but couldn't find anything that would help me out, since I'm not really a kernel and/or gcc wiz.

What am I doing wrong? Or is there something in the module code that's not compatible with a 64bit hppa kernel?

Thanks so much,

Kai

Signature · 9 lines
Hofstadter's Law:
  "It always takes longer than you expect,
   even when you take into account Hofstadter's Law."
                             -- Douglas R. Hofstadter

kmh.AT.sonic.net

Check out Mission Octagon - a new, exciting novel!
http://www.missionoctagon.com

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#1 lore raw
Quoted 3 lines

Module quickcam, symbol qc_proc_init is out of range for PCREL22F relocation =46ATAL: Error inserting quickcam (/lib/modules/2.6.16-pa11/misc/quickcam.k= o):=20

I believe that this has come up before. The out of range PCREL22F relocation implies that the module has a "b,l" instruction (call) whose target can't be reached. The maximum branch distance for the "b,l" instruction is ~ 8 MB, so the module must be quite large.

You might explore ways to reduce the modules's (e.g., limit inlining). You might also try compiling with the -mlong-calls options. This forces GCC to use the "bve" instruction for calls in PA 2.0 compilations. The call setup using bve is slightly longer but there are no distance limitations. There's also a PA 1.x variant using "ble". What's unclear to me is whether the kernel loader has support for the relocations used in these sequences.

Dave

Signature · 6 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#2 lore raw
Quoted 7 lines

You might explore ways to reduce the modules's (e.g., limit inlining). You might also try compiling with the -mlong-calls options. This forces GCC to use the "bve" instruction for calls in PA 2.0 compilations. The call setup using bve is slightly longer but there are no distance limitations. There's also a PA 1.x variant using "ble". What's unclear to me is whether the kernel loader has support for the relocations used in these sequences.

Just thinking, the problem might be going the other way. If so, reorganzing the sections used for functions called from the kernel might help.

Dave

Signature · 6 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#3 lore raw
In reply to John David Anglin
Quoted 7 lines

You might explore ways to reduce the modules's (e.g., limit inlining). You might also try compiling with the -mlong-calls options. This forces GCC to use the "bve" instruction for calls in PA 2.0 compilations. The call setup using bve is slightly longer but there are no distance limitations. There's also a PA 1.x variant using "ble". What's unclear to me is whether the kernel loader has support for the relocations used in these sequences.

I think I'm clearly out of my league here, since I honestly don't understand bve vs ble... :(

Anyway - I tried compiling the module with the "-mlong-calls" option - now I get a different error message upon trying to insert the module into the kernel:
module quickcam: Unknown relocation: 10

Does that tell you anything? Because I have no clue...

Thanks so much for your help!

Kai

Signature · 9 lines
Hofstadter's Law:
  "It always takes longer than you expect,
   even when you take into account Hofstadter's Law."
                             -- Douglas R. Hofstadter

kmh.AT.sonic.net

Check out Mission Octagon - a new, exciting novel!
http://www.missionoctagon.com

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#4 lore raw
Quoted 5 lines

Anyway - I tried compiling the module with the "-mlong-calls" option - now = I=20
get a different error message upon trying to insert the module into the=20 kernel:
module quickcam: Unknown relocation: 10

That's R_PARISC_PCREL21L. I was afraid this might happen.

About the only easy things are "-Os" and "-fno-inline-functions". These might shrink the module a bit. Oh, "-fno-unroll-loops" might also help.

Dave

Signature · 6 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#5 lore raw
Quoted 5 lines

That's R_PARISC_PCREL21L. I was afraid this might happen.

About the only easy things are "-Os" and "-fno-inline-functions". These might shrink the module a bit. Oh, "-fno-unroll-loops" might also help.

Thanks again for your help - and unfortunately these didn't do the trick, either - same results.

Looking over your earlier reply, you indicated that the module must be quite "large" - do you mean file size of the .ko file?
Because that is way under the 8MB you mentioned - the file is around 200kB in size...

The qc-usb module is a driver for Logitech's QuickCam Express cameras, which are using the kernel usb and video4linux drivers...

Thanks again,

Kai

Signature · 9 lines
Hofstadter's Law:
  "It always takes longer than you expect,
   even when you take into account Hofstadter's Law."
                             -- Douglas R. Hofstadter

kmh.AT.sonic.net

Check out Mission Octagon - a new, exciting novel!
http://www.missionoctagon.com

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#6 lore raw
Quoted 5 lines

Looking over your earlier reply, you indicated that the module must be=20 quite "large" - do you mean file size of the .ko file?
Because that is way under the 8MB you mentioned - the file is around 200kB = in=20
size...

I wonder if that implies a bug a bug in the kernel loader. I could see a problem with PCREL17F relocations with files around 200kB. These are used with the PA 1.x "bl" instruction. The range for "bl" instructions is about +/- 262kB. The range for the 22F "b,l" instruction is 32 times larger.

Dave

Signature · 6 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#7 lore raw
Quoted 11 lines · John David Anglin
Quoted 5 lines

Looking over your earlier reply, you indicated that the module must be=20 quite "large" - do you mean file size of the .ko file?
Because that is way under the 8MB you mentioned - the file is around 200kB = in=20
size...

I wonder if that implies a bug a bug in the kernel loader. I could see a problem with PCREL17F relocations with files around 200kB. These are used with the PA 1.x "bl" instruction. The range for "bl" instructions is about +/- 262kB. The range for the 22F "b,l" instruction is 32 times larger.

A number of kernel modules fail to load nowadays on parisc. That includes xfs, netfilter, ipv6... Some are known bloated big ones, but others are quite surprising. In any case that's clearly a problem we want to fix at some point.

I remember Randolph saying that might indeed be a kernel loader issue... Randolph, any thought?

HTH

T-Bone

Signature · 6 lines
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#8 lore raw
Quoted 7 lines

A number of kernel modules fail to load nowadays on parisc. That includes xfs, netfilter, ipv6... Some are known bloated big ones, but others are quite surprising. In any case that's clearly a problem we want to fix at some point.

I remember Randolph saying that might indeed be a kernel loader issue... Randolph, any thought?

ok, several things:

- I looked at fixing this in binutils, which is really the "right" place to fix this; unfortunately the changes required are very extensive, so I gave up

- I looked at using -mlong-calls to address this issue. I've added the missing relocation that was reported in a previous message on this thread, but there are other problems - with modules compiled with -mlong-call I am seeing rather bizarre crashes that I have not had time to debug further. I do not yet know why they are happening, although I suspect it has to do with bve clobbering r31. I'm not yet sure if this is a kernel problem or a gcc problem.

- As to "small" modules causing the out of bounds problem - I haven't really looked at any modules other than ipv6. If there's a particular one that is "surprising", I can take a look. Usually it's quite obvious where the out of bounds problem is.

- As an aside, while looking at the module loading problem, I've convinced myself that the 64-bit module loader is wrong. OTOH, it seems to work in most cases, so there's clearly something that I don't yet understand.....

The module loader has a hard coded limit for the number of GOT entries. We can exceed this rather easily in some cases when we are using long calls.

randolph

Signature · 7 lines
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#9 lore raw
Quoted 5 lines · Randolph Chung

- As an aside, while looking at the module loading problem, I've convinced myself that the 64-bit module loader is wrong. OTOH, it seems
to work in most cases, so there's clearly something that I don't yet understand.....

Well ... OK ... since I made that work I can try to remember how I did it ... what seems to be the problem?

James

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux