On 13/01/2011 23:57, David Miller wrote:
From: Richard Mortimer<ri...@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<b...@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
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d302b2f.7030...@oldelvet.org.uk