[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36



On 13/01/2011 23:57, David Miller wrote:

From: Richard Mortimer<richm@oldelvet.org.uk>
Date: Thu, 13 Jan 2011 23:34:01 +0000


On Wed, 2011-01-12 at 00:37 +0000, Ben Hutchings wrote:

On Wed, 2011-01-12 at 00:27 +0000, Richard Mortimer wrote:


On 09/01/2011 03:46, David Miller wrote:

From: Ben Hutchings<ben@decadent.org.uk>
Date: Sun, 09 Jan 2011 03:00:40 +0000


On Sun, 2011-01-09 at 01:05 +0000, Richard Mortimer wrote:

Package: linux-2.6
Version: 2.6.37-1~experimental.1
Severity: normal

Boot of linux-image-2.6.37-trunk-sparc64 fails to find the disks and drops
to the initramfs prompt. When I try to load the sym53c8xx driver it fails
as follows

(initramfs) modprobe sym53c8xx
[  122.470284] module scsi_mod: Unknown relocation: 36
FATAL: Error inserting sym53c8xx (/lib/modules/2.6.37-trunk-sparc64/kernel/drive
rs/scsi/sym53c8xx_2/sym53c8xx.ko): Invalid module format
(initramfs)


David, do you have any idea how this could happen?


A quick web search finds a similar issue
http://kerneltrap.org/mailarchive/linux-kernel/2010/6/16/4583942
but I have not looked into this any further yet.

[...]

That was apparently a bug in the build scripts for a separate module.


And like that case bad build flags are causing this problem too.  It
means that "-mcode-model=medlow" is not making it into the module
build cflags somehow.

This relocation can only occur for sparc64 code models other than
"medlow".


I did a test Debian build using my Sun Fire V120 running to double check
the build with the 2.6.27-1@experimental.1 sources. This fails in the
same way that the official build fails.

Looking at the build output it seems to end up building setup_sparc but
I think it should be building setup_sparc64 in the rules.

[...]

I will try a package build forcing DEB_HOST_ARCH to sparc64 and see if
that builds the right packages.


No, this is correct behaviour.  $DEB_HOST_ARCH is the Debian userland
architecture (as used in the package metadata) and may differ from the
kernel architecture.  All the defined kernel flavours for sparc are
64-bit.


Thanks Ben. I've started looking at a few other potential causes...

Looking at the relocation symbols in scsi_mod.ko as reported by objdump
it looks to me that the R_SPARC_13 and R_SPARC_UA64 are the unsupported
relocation types that are stopping the driver getting loaded.

richm@shirehall:/usr/src/linux-2.6-2.6.37/debian/build/build_sparc_none_sparc64$ objdump -r /lib/modules/2.6.37-trunk-sparc64/kernel/drivers/scsi/scsi_mod.ko | cut -d' ' -f 2 | sort | uniq -c
      51
      16 RECORDS
      53 R_SPARC_13
     129 R_SPARC_32
    2352 R_SPARC_64
     825 R_SPARC_HI22
     869 R_SPARC_LO10
      20 R_SPARC_UA64
    1011 R_SPARC_WDISP30


The original error report shows:


(initramfs) modprobe sym53c8xx
[  122.470284] module scsi_mod: Unknown relocation: 36

                                          ^^^^^^^^^^^^^^^^^^^^^^

FATAL: Error inserting sym53c8xx (/lib/modules/2.6.37-trunk-sparc64/kernel/drive
rs/scsi/sym53c8xx_2/sym53c8xx.ko): Invalid module format
(initramfs)


So you didn't need to analyze the binary with objdump to
work on this bug.
Yeah I'd seen that in my original error output. Please do excuse my slow workings it is over 7 years since I was working with Sparc systems on a daily basis. objdump made it easier to look at the compiler output and modules without compile/reboot cycles. 



Relocation type 36 is R_SPARC_LM22.
I'm confused now! Maybe I've missed something but looking at arch/sparc/kernel/module.c it seems that the 36 is hexadecimal. 

               printk(KERN_ERR "module %s: Unknown relocation: %x\n",
                      me->name,
                      (int) (ELF_R_TYPE(rel[i].r_info) & 0xff));
So that means that the kernel is complaining about type 54 which is R_SPARC_UA64. That matches with the objdump output which doesn't list R_SPARC_LM22 for scsi_mod.ko 

Regards

Richard
Reply to: