problem w/ 2.5.70-mm3 and modules

On sparc64, loading of modules (dm-mod, at least) triggers a BUG_ON() in apply_relocate_add() (arch/sparc64/kernel/module.c):

dilinger@lag:~$ ksymoops oops
ksymoops 2.4.8 on sparc64 2.5.70-mm3.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.70-mm3/ (default)
     -m /boot/System.map-2.5.70-mm3 (default)

Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
modprobe(65): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009606 TPC: 000000000043b1a0 TNPC: 000000000043b1a4 Y: ffffee00 Not tainted
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 00000000005b1c00 g1: 0000000000000000 g2: 00000001400129a4 g3: 0000000000000000
g4: fffff80031c1e080 g5: 0000000000000000 g6: fffff80000ca0000 g7: 0000000000000000
o0: 0000000000000004 o1: 0000000000000001 o2: 0000000000000000 o3: 00000001400129a0
o4: 0000000140014028 o5: 0000000140017c48 sp: fffff80000ca3321 ret_pc: 0000000140017c48
l0: 00000000000019f8 l1: 0000000140018278 l2: 0000000000000116 l3: 0000000000000116
l4: 000000000000fff1 l5: 0000000000000000 l6: 000000000000fff2 l7: 0000000000588ac0
i0: 0000000140013b28 i1: 0000000140019c88 i2: 0000000000000014 i3: 0000000000000006
i4: 00000000020054e8 i5: 0000000000000004 i6: fffff80000ca33e1 i7: 000000000045d948 Instruction DUMP: 8402c008 9330b020 80a26000 <93d03005> d25b6008 d45b2010 97327020 d85b6010 9002c00b

Code; 0043b194 <apply_relocate_add+54/2a0>
00000000 <_PC>:
Code; 0043b194 <apply_relocate_add+54/2a0>
0: 84 02 c0 08 add %o3, %o0, %g2
Code; 0043b198 <apply_relocate_add+58/2a0>
4: 93 30 b0 20 unknown
Code; 0043b19c <apply_relocate_add+5c/2a0>
8: 80 a2 60 00 cmp %o1, 0
Code; 0043b1a0 <apply_relocate_add+60/2a0> <=====
c: 93 d0 30 05 tne -4091 <=====
Code; 0043b1a4 <apply_relocate_add+64/2a0>
10: d2 5b 60 08 unknown
Code; 0043b1a8 <apply_relocate_add+68/2a0>
14: d4 5b 20 10 unknown
Code; 0043b1ac <apply_relocate_add+6c/2a0>
18: 97 32 70 20 unknown
Code; 0043b1b0 <apply_relocate_add+70/2a0>
1c: d8 5b 60 10 unknown
Code; 0043b1b4 <apply_relocate_add+74/2a0>
20: 90 02 c0 0b add %o3, %o3, %o0

1 warning and 1 error issued. Results may not be reliable.

Here's what's actually happening:

load_module(): relocating section header #1: name='.text', address=0x2000000; section header type=1 load_module(): relocating section header #2: name='.rela.text', address=0x1400140a8; section header type=4 apply_relocate_add(): section header address: 00000001400140a8
apply_relocate_add(): section header size: 0x3738; additional info: 1; number of relocatable symbols: 589 apply_relocate_add(): rel symbol offset=0x4; base: 0x2000000; location=0000000002000004 apply_relocate_add(): rel symbol offset=0x8; base: 0x2000000; location=0000000002000008 load_module(): relocating section header #3: name='.init.text', address=0x2008000; section header type=1 load_module(): relocating section header #4: name='.rela.init.text', address=0x1400177e0; section header type=4 apply_relocate_add(): section header address: 00000001400177e0
apply_relocate_add(): section header size: 0x468; additional info: 3; number of relocatable symbols: 47 apply_relocate_add(): rel symbol offset=0x4; base: 0x2008000; location=0000000002008004 apply_relocate_add(): rel symbol offset=0xc; base: 0x2008000; location=000000000200800c load_module(): relocating section header #5: name='.exit.text', address=0x1400129a0; section header type=1 load_module(): relocating section header #6: name='.rela.exit.text', address=0x140017c48; section header type=4 apply_relocate_add(): section header address: 0000000140017c48
apply_relocate_add(): section header size: 0x30; additional info: 5; number of relocatable symbols: 2 apply_relocate_add(): rel symbol offset=0x4; base: 0x1400129a0; location=00000001400129a4

              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/

That last base (0x1400129a0) is too large; when shifted in the BUG_ON, the result is 0x1. The actual BUG_ON is:
BUG_ON(((u64)location >> (u64)32) != (u64)0);

dm-mod's section info:

/lib/modules/2.5.70-mm3/kernel/drivers/md/dm-mod.ko: file format elf64-sparc/lib/modules/2.5.70-mm3/kernel/drivers/md/dm-mod.ko
architecture: sparc:v9, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x0000000000000000

Sections:

Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00004700  0000000000000000  0000000000000000  00000040  2**5

CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .init.text 00000260 0000000000000000 0000000000000000 00004740 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 .exit.text 00000040 0000000000000000 0000000000000000 000049a0 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 .rodata.str1.8 000009e0 0000000000000000 0000000000000000 000049e0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .modinfo 000000d0 0000000000000000 0000000000000000 000053c0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA

...

RELOCATION RECORDS FOR [.exit.text]:

OFFSET           TYPE              VALUE
0000000000000004 R_SPARC_HI22      .data+0x0000000000000010
000000000000000c R_SPARC_LO10      .data+0x0000000000000010

I'm not sure how to inspect dm-mod's .rela.exit.text; pointers to doing this (assuming it's not just another name for .exit.text) would be appreciated. This was occurring w/ vanilla 2.5.70, as well.