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 From that I took one of the constituent source files (scsi_error.c) as an example and looked at what the compiler was doing with it. debian/build/build_sparc_non_sparc64/drivers/scsi/.scsi_error.o.cmd reports that the compile command line is as follows gcc-4.4 -Wp,-MD,drivers/scsi/.scsi_error.o.d -nostdinc -isystem /usr/lib/gcc/sparc-linux-gnu/4.4.5/include -I/usr/src/linux-2.6-2.6.37/debian/build/source_sparc_none/arch/sparc/include -Iinclude -I/usr/src/linux-2.6-2.6.37/debian/build/source_sparc_none/include -include include/generated/autoconf.h -I/usr/src/linux-2.6-2.6.37/debian/build/source_sparc_none/drivers/scsi -Idrivers/scsi -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -mtune=ultrasparc3 -Wframe-larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DMODULE -D"KBUILD_STR(s)=\#s" -D"KBUILD_BASENAME=KBUILD_STR(scsi_error)" -D"KBUILD_MODNAME=KBUILD_STR(scsi_mod)" -c -o drivers/scsi/.tmp_scsi_error.o /usr/src/linux-2.6-2.6.37/debian/build/source_sparc_none/drivers/scsi/scsi_error.c That seems to have -mcmodel=medlow so I'm wondering if this is a compiler/compiler options issue. If I remove -Os from the gcc-4.4 commandline above the R_SPARC_13 and R_SPARC_UA64 entries disappear from .tmp_scsi_error.o output. I also tried changing -Os to -O2 and the relocation symbols look broken for that too. 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/1294961641.22576.31.camel@duncow