* Error "Unknown relocation: 36" on module load on Sparc [not found] <AANLkTimuv7nOlcGFxqPZlwcAjLmFMiLAvbA5O7F32Wbg@mail.gmail.com> @ 2010-06-16 19:05 ` Vladislav Bolkhovitin 2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Vladislav Bolkhovitin 1 sibling, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-16 19:05 UTC (permalink / raw) To: sparclinux; +Cc: Simone Ricci, scst-devel, linux-kernel, Nick Couchman [-- Attachment #1: Type: text/plain, Size: 728 bytes --] Hello, We in SCST project have a very strange problem on Sparc. Our main module scst.ko, if built as a module out of the kernel tree, can't be loaded and "modprobe scst" returns: FATAL: Error inserting scst (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format The following message is immediately spit out by the kernel: [ 1686.676534] module scst: Unknown relocation: 36 On x86 everything works fine. If SCST built inside the kernel, on Sparc it also works fine. We completely stuck and have no idea what could be the cause. Googling also doesn't help much. Could anybody point out a direction how to find the cause of the issue? I'm attaching Makefile we are using for you reference. Thanks, Vlad [-- Attachment #2: Makefile --] [-- Type: text/plain, Size: 9188 bytes --] # # SCSI target mid-level makefile # # Copyright (C) 2004 - 2010 Vladislav Bolkhovitin <vst@vlnb.net> # Copyright (C) 2004 - 2005 Leonid Stoljar # Copyright (C) 2007 - 2010 ID7 Ltd. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation, version 2 # of the License. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # # Main targets: # all (the default) : make all # clean : clean files # extraclean : clean + clean dependencies # install : install # uninstall : uninstall # # Notes : # - install and uninstall must be made as root # SHELL=/bin/bash DEV_HANDLERS_DIR = dev_handlers ifneq ($(PATCHLEVEL),) SCST_INC_DIR := $(SUBDIRS)/../include obj-m := scst.o scst-y += scst_main.o scst-y += scst_targ.o scst-y += scst_lib.o scst-y += scst_proc.o #scst-y += scst_sysfs.o scst-y += scst_mem.o scst-y += scst_debug.o scst-y += scst_pres.o obj-$(CONFIG_SCST) += scst.o dev_handlers/ obj-$(BUILD_DEV) += $(DEV_HANDLERS_DIR)/ else ifeq ($(KVER),) ifeq ($(KDIR),) KVER = $(shell uname -r) KDIR := /lib/modules/$(KVER)/build endif else KDIR := /lib/modules/$(KVER)/build endif all: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m scst: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=n MODS_VERS := $(shell ls Modules.symvers 2>/dev/null) # It's renamed in 2.6.18 MOD_VERS := $(shell ls Module.symvers 2>/dev/null) install: all -rm -f $(INSTALL_DIR)/scsi_tgt.ko $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m \ modules_install install -d $(INSTALL_DIR_H) install -m 644 ../include/scst.h $(INSTALL_DIR_H) install -m 644 ../include/scst_sgv.h $(INSTALL_DIR_H) install -m 644 ../include/scst_debug.h $(INSTALL_DIR_H) install -m 644 ../include/scst_user.h $(INSTALL_DIR_H) install -m 644 ../include/scst_const.h $(INSTALL_DIR_H) ifneq ($(MODS_VERS),) rm -f $(INSTALL_DIR_H)/Module.symvers install -m 644 Modules.symvers $(INSTALL_DIR_H) endif ifneq ($(MOD_VERS),) rm -f $(INSTALL_DIR_H)/Modules.symvers install -m 644 Module.symvers $(INSTALL_DIR_H) endif -/sbin/depmod -a $(KVER) mkdir -p /var/lib/scst/pr @echo "****************************************************************" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "*!! !!*" @echo "*!! Now don't forget to rebuild and reinstall all your !!*" @echo "*!! target drivers, custom dev handlers and necessary user !!*" @echo "*!! space applications. Otherwise, because of the versions !!*" @echo "*!! mismatch, you could have many problems and crashes. !!*" @echo "*!! See IMPORTANT note in the \"Installation\" section of !!*" @echo "*!! SCST's README file for more info. !!*" @echo "*!! !!*" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "****************************************************************" uninstall: cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ rm -f $(INSTALL_DIR)/scst.ko -rmdir $(INSTALL_DIR) 2>/dev/null -/sbin/depmod -a $(KVER) rm -rf $(INSTALL_DIR_H) endif ifeq ($(KVER),) INSTALL_DIR := $(DESTDIR)/lib/modules/$(shell uname -r)/extra else INSTALL_DIR := $(DESTDIR)/lib/modules/$(KVER)/extra endif INSTALL_DIR_H := $(DESTDIR)/usr/local/include/scst EXTRA_CFLAGS += -I$(SCST_INC_DIR) -Wextra -Wno-unused-parameter \ -Wno-missing-field-initializers #EXTRA_CFLAGS += -DCONFIG_SCST_STRICT_SERIALIZING EXTRA_CFLAGS += -DCONFIG_SCST_EXTRACHECKS #EXTRA_CFLAGS += -DCONFIG_SCST_USE_EXPECTED_VALUES #EXTRA_CFLAGS += -DCONFIG_SCST_TEST_IO_IN_SIRQ #EXTRA_CFLAGS += -DCONFIG_SCST_ABORT_CONSIDER_FINISHED_TASKS_AS_NOT_EXISTING #EXTRA_CFLAGS += -fno-inline #EXTRA_CFLAGS += -DCONFIG_SCST_TRACING EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_TM -DCONFIG_SCST_TM_DBG_GO_OFFLINE #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_RETRY #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_OOM #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_SN #EXTRA_CFLAGS += -DCONFIG_SCST_MEASURE_LATENCY # If defined, makes SCST zero allocated data buffers. # Undefining it considerably improves performance and eases CPU load, # but could create a security hole (information leakage), so # enable it if you have strict security requirements. #EXTRA_CFLAGS += -DSCST_STRICT_SECURITY clean: rm -f *.o *.ko .*.cmd *.mod.c .*.d .depend Modules.symvers \ Module.symvers Module.markers modules.order rm -rf .tmp_versions cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ extraclean: clean debug2release: sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/"EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ release2debug: sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ debug2perf: sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ perf2debug: sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ disable_proc: sed -i.aa s/"^#define CONFIG_SCST_PROC"/"\/* #define CONFIG_SCST_PROC *\/"/ ../include/scst.h @cmp ../include/scst.h ../include/scst.h.aa >/dev/null; if [[ $$? = 0 ]]; then rm ../include/scst.h.aa; echo "sed failed"; false; fi rm ../include/scst.h.aa sed -i.aa s/"^scst-y += scst_proc.o"/"#scst\-y += scst_proc.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#scst\-y += scst_sysfs.o"/"scst\-y += scst_sysfs.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa enable_proc: sed -i.aa s/"\/\* #define CONFIG_SCST_PROC \*\/"/"#define CONFIG_SCST_PROC"/ ../include/scst.h @cmp ../include/scst.h ../include/scst.h.aa >/dev/null; if [[ $$? = 0 ]]; then rm ../include/scst.h.aa; echo "sed failed"; false; fi rm ../include/scst.h.aa sed -i.aa s/"#scst\-y += scst_proc.o"/"scst\-y += scst_proc.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^scst\-y += scst_sysfs.o"/"#scst\-y += scst_sysfs.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa .PHONY: all install uninstall clean extraclean debug2release release2debug debug2perf perf2debug disable_proc enable_proc ^ permalink raw reply [flat|nested] 24+ messages in thread
* Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-16 19:05 ` Vladislav Bolkhovitin 0 siblings, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-16 19:05 UTC (permalink / raw) To: sparclinux; +Cc: Simone Ricci, scst-devel, linux-kernel, Nick Couchman [-- Attachment #1: Type: text/plain, Size: 728 bytes --] Hello, We in SCST project have a very strange problem on Sparc. Our main module scst.ko, if built as a module out of the kernel tree, can't be loaded and "modprobe scst" returns: FATAL: Error inserting scst (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format The following message is immediately spit out by the kernel: [ 1686.676534] module scst: Unknown relocation: 36 On x86 everything works fine. If SCST built inside the kernel, on Sparc it also works fine. We completely stuck and have no idea what could be the cause. Googling also doesn't help much. Could anybody point out a direction how to find the cause of the issue? I'm attaching Makefile we are using for you reference. Thanks, Vlad [-- Attachment #2: Makefile --] [-- Type: text/plain, Size: 9188 bytes --] # # SCSI target mid-level makefile # # Copyright (C) 2004 - 2010 Vladislav Bolkhovitin <vst@vlnb.net> # Copyright (C) 2004 - 2005 Leonid Stoljar # Copyright (C) 2007 - 2010 ID7 Ltd. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation, version 2 # of the License. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # # Main targets: # all (the default) : make all # clean : clean files # extraclean : clean + clean dependencies # install : install # uninstall : uninstall # # Notes : # - install and uninstall must be made as root # SHELL=/bin/bash DEV_HANDLERS_DIR = dev_handlers ifneq ($(PATCHLEVEL),) SCST_INC_DIR := $(SUBDIRS)/../include obj-m := scst.o scst-y += scst_main.o scst-y += scst_targ.o scst-y += scst_lib.o scst-y += scst_proc.o #scst-y += scst_sysfs.o scst-y += scst_mem.o scst-y += scst_debug.o scst-y += scst_pres.o obj-$(CONFIG_SCST) += scst.o dev_handlers/ obj-$(BUILD_DEV) += $(DEV_HANDLERS_DIR)/ else ifeq ($(KVER),) ifeq ($(KDIR),) KVER = $(shell uname -r) KDIR := /lib/modules/$(KVER)/build endif else KDIR := /lib/modules/$(KVER)/build endif all: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m scst: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=n MODS_VERS := $(shell ls Modules.symvers 2>/dev/null) # It's renamed in 2.6.18 MOD_VERS := $(shell ls Module.symvers 2>/dev/null) install: all -rm -f $(INSTALL_DIR)/scsi_tgt.ko $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m \ modules_install install -d $(INSTALL_DIR_H) install -m 644 ../include/scst.h $(INSTALL_DIR_H) install -m 644 ../include/scst_sgv.h $(INSTALL_DIR_H) install -m 644 ../include/scst_debug.h $(INSTALL_DIR_H) install -m 644 ../include/scst_user.h $(INSTALL_DIR_H) install -m 644 ../include/scst_const.h $(INSTALL_DIR_H) ifneq ($(MODS_VERS),) rm -f $(INSTALL_DIR_H)/Module.symvers install -m 644 Modules.symvers $(INSTALL_DIR_H) endif ifneq ($(MOD_VERS),) rm -f $(INSTALL_DIR_H)/Modules.symvers install -m 644 Module.symvers $(INSTALL_DIR_H) endif -/sbin/depmod -a $(KVER) mkdir -p /var/lib/scst/pr @echo "****************************************************************" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "*!! !!*" @echo "*!! Now don't forget to rebuild and reinstall all your !!*" @echo "*!! target drivers, custom dev handlers and necessary user !!*" @echo "*!! space applications. Otherwise, because of the versions !!*" @echo "*!! mismatch, you could have many problems and crashes. !!*" @echo "*!! See IMPORTANT note in the \"Installation\" section of !!*" @echo "*!! SCST's README file for more info. !!*" @echo "*!! !!*" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "****************************************************************" uninstall: cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ rm -f $(INSTALL_DIR)/scst.ko -rmdir $(INSTALL_DIR) 2>/dev/null -/sbin/depmod -a $(KVER) rm -rf $(INSTALL_DIR_H) endif ifeq ($(KVER),) INSTALL_DIR := $(DESTDIR)/lib/modules/$(shell uname -r)/extra else INSTALL_DIR := $(DESTDIR)/lib/modules/$(KVER)/extra endif INSTALL_DIR_H := $(DESTDIR)/usr/local/include/scst EXTRA_CFLAGS += -I$(SCST_INC_DIR) -Wextra -Wno-unused-parameter \ -Wno-missing-field-initializers #EXTRA_CFLAGS += -DCONFIG_SCST_STRICT_SERIALIZING EXTRA_CFLAGS += -DCONFIG_SCST_EXTRACHECKS #EXTRA_CFLAGS += -DCONFIG_SCST_USE_EXPECTED_VALUES #EXTRA_CFLAGS += -DCONFIG_SCST_TEST_IO_IN_SIRQ #EXTRA_CFLAGS += -DCONFIG_SCST_ABORT_CONSIDER_FINISHED_TASKS_AS_NOT_EXISTING #EXTRA_CFLAGS += -fno-inline #EXTRA_CFLAGS += -DCONFIG_SCST_TRACING EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_TM -DCONFIG_SCST_TM_DBG_GO_OFFLINE #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_RETRY #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_OOM #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_SN #EXTRA_CFLAGS += -DCONFIG_SCST_MEASURE_LATENCY # If defined, makes SCST zero allocated data buffers. # Undefining it considerably improves performance and eases CPU load, # but could create a security hole (information leakage), so # enable it if you have strict security requirements. #EXTRA_CFLAGS += -DSCST_STRICT_SECURITY clean: rm -f *.o *.ko .*.cmd *.mod.c .*.d .depend Modules.symvers \ Module.symvers Module.markers modules.order rm -rf .tmp_versions cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ extraclean: clean debug2release: sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/"EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ release2debug: sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_TRACING"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ debug2perf: sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ perf2debug: sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/"EXTRA_CFLAGS += \-DCONFIG_SCST_EXTRACHECKS"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/"EXTRA_CFLAGS += \-DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ disable_proc: sed -i.aa s/"^#define CONFIG_SCST_PROC"/"\/* #define CONFIG_SCST_PROC *\/"/ ../include/scst.h @cmp ../include/scst.h ../include/scst.h.aa >/dev/null; if [[ $$? = 0 ]]; then rm ../include/scst.h.aa; echo "sed failed"; false; fi rm ../include/scst.h.aa sed -i.aa s/"^scst-y += scst_proc.o"/"#scst\-y += scst_proc.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"#scst\-y += scst_sysfs.o"/"scst\-y += scst_sysfs.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa enable_proc: sed -i.aa s/"\/\* #define CONFIG_SCST_PROC \*\/"/"#define CONFIG_SCST_PROC"/ ../include/scst.h @cmp ../include/scst.h ../include/scst.h.aa >/dev/null; if [[ $$? = 0 ]]; then rm ../include/scst.h.aa; echo "sed failed"; false; fi rm ../include/scst.h.aa sed -i.aa s/"#scst\-y += scst_proc.o"/"scst\-y += scst_proc.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi sed -i.aa s/"^scst\-y += scst_sysfs.o"/"#scst\-y += scst_sysfs.o"/ Makefile @cmp Makefile Makefile.aa >/dev/null; if [[ $$? = 0 ]]; then rm Makefile.aa; echo "sed failed"; false; fi rm Makefile.aa .PHONY: all install uninstall clean extraclean debug2release release2debug debug2perf perf2debug disable_proc enable_proc ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-16 19:05 ` Vladislav Bolkhovitin @ 2010-06-16 19:22 ` Kyle McMartin -1 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 19:22 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: sparclinux, Simone Ricci, scst-devel, linux-kernel, Nick Couchman, davem On Wed, Jun 16, 2010 at 11:05:41PM +0400, Vladislav Bolkhovitin wrote: > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 > The error is caused because gcc is generating a relocation type that the kernel's module loader cannot handle. This appears to be: libelf/elf.h:#define R_SPARC_LM22 36 /* Low middle 22 bits of ... */ It doesn't occur when patched into the kernel build, since the relocations are handled at link time as opposed to load time. arch/sparc/kernel/module.c needs to be patched to support the new relocation type... Based on binutils/gas/config/tc-sparc.c and gold's sparc config this looks to be the same as the hi22 reloc... Can you test the following patch? regards, Kyle --- diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h index e678803..8bf59f1 100644 --- a/arch/sparc/include/asm/elf_64.h +++ b/arch/sparc/include/asm/elf_64.h @@ -52,6 +52,7 @@ #define R_SPARC_11 31 #define R_SPARC_64 32 #define R_SPARC_OLO10 33 +#define R_SPARC_LM22 36 #define R_SPARC_WDISP16 40 #define R_SPARC_WDISP19 41 #define R_SPARC_7 43 diff --git a/arch/sparc/kernel/module.c b/arch/sparc/kernel/module.c index f848aad..49b1b21 100644 --- a/arch/sparc/kernel/module.c +++ b/arch/sparc/kernel/module.c @@ -207,6 +207,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs, *loc32 = (*loc32 & ~0x3ff) | (v & 0x3ff); break; + case R_SPARC_LM22: case R_SPARC_HI22: *loc32 = (*loc32 & ~0x3fffff) | ((v >> 10) & 0x3fffff); ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-16 19:22 ` Kyle McMartin 0 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 19:22 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: sparclinux, Simone Ricci, scst-devel, linux-kernel, Nick Couchman, davem On Wed, Jun 16, 2010 at 11:05:41PM +0400, Vladislav Bolkhovitin wrote: > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 > The error is caused because gcc is generating a relocation type that the kernel's module loader cannot handle. This appears to be: libelf/elf.h:#define R_SPARC_LM22 36 /* Low middle 22 bits of ... */ It doesn't occur when patched into the kernel build, since the relocations are handled at link time as opposed to load time. arch/sparc/kernel/module.c needs to be patched to support the new relocation type... Based on binutils/gas/config/tc-sparc.c and gold's sparc config this looks to be the same as the hi22 reloc... Can you test the following patch? regards, Kyle --- diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h index e678803..8bf59f1 100644 --- a/arch/sparc/include/asm/elf_64.h +++ b/arch/sparc/include/asm/elf_64.h @@ -52,6 +52,7 @@ #define R_SPARC_11 31 #define R_SPARC_64 32 #define R_SPARC_OLO10 33 +#define R_SPARC_LM22 36 #define R_SPARC_WDISP16 40 #define R_SPARC_WDISP19 41 #define R_SPARC_7 43 diff --git a/arch/sparc/kernel/module.c b/arch/sparc/kernel/module.c index f848aad..49b1b21 100644 --- a/arch/sparc/kernel/module.c +++ b/arch/sparc/kernel/module.c @@ -207,6 +207,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs, *loc32 = (*loc32 & ~0x3ff) | (v & 0x3ff); break; + case R_SPARC_LM22: case R_SPARC_HI22: *loc32 = (*loc32 & ~0x3fffff) | ((v >> 10) & 0x3fffff); ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-16 19:22 ` Kyle McMartin @ 2010-06-16 20:38 ` David Miller -1 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:38 UTC (permalink / raw) To: kyle; +Cc: vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman From: Kyle McMartin <kyle@mcmartin.ca> Date: Wed, 16 Jun 2010 15:22:57 -0400 > arch/sparc/kernel/module.c needs to be patched to support the new > relocation type... Based on binutils/gas/config/tc-sparc.c and gold's > sparc config this looks to be the same as the hi22 reloc... > > Can you test the following patch? This change is incorrect. LM22 relocations do not get emitted for the "medlow" code model, which is what is explicitly specified on the kernel compiler command line for sparc64 via "-mcmodel=medlow". Someone this person is using incorrect CFLAGS when building their module, and that's why they have this problem, because the compiler's default code model on sparc64 can generate those relocations. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-16 20:38 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:38 UTC (permalink / raw) To: kyle; +Cc: vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman From: Kyle McMartin <kyle@mcmartin.ca> Date: Wed, 16 Jun 2010 15:22:57 -0400 > arch/sparc/kernel/module.c needs to be patched to support the new > relocation type... Based on binutils/gas/config/tc-sparc.c and gold's > sparc config this looks to be the same as the hi22 reloc... > > Can you test the following patch? This change is incorrect. LM22 relocations do not get emitted for the "medlow" code model, which is what is explicitly specified on the kernel compiler command line for sparc64 via "-mcmodel=medlow". Someone this person is using incorrect CFLAGS when building their module, and that's why they have this problem, because the compiler's default code model on sparc64 can generate those relocations. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-16 20:38 ` David Miller @ 2010-06-16 20:40 ` Kyle McMartin -1 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 20:40 UTC (permalink / raw) To: David Miller Cc: kyle, vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman On Wed, Jun 16, 2010 at 01:38:54PM -0700, David Miller wrote: > This change is incorrect. > > LM22 relocations do not get emitted for the "medlow" code model, which > is what is explicitly specified on the kernel compiler command line > for sparc64 via "-mcmodel=medlow". > > Someone this person is using incorrect CFLAGS when building their > module, and that's why they have this problem, because the compiler's > default code model on sparc64 can generate those relocations. > Yeah, just saw your other mail. Thanks for the explanation! --Kyle ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-16 20:40 ` Kyle McMartin 0 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 20:40 UTC (permalink / raw) To: David Miller Cc: kyle, vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman On Wed, Jun 16, 2010 at 01:38:54PM -0700, David Miller wrote: > This change is incorrect. > > LM22 relocations do not get emitted for the "medlow" code model, which > is what is explicitly specified on the kernel compiler command line > for sparc64 via "-mcmodel=medlow". > > Someone this person is using incorrect CFLAGS when building their > module, and that's why they have this problem, because the compiler's > default code model on sparc64 can generate those relocations. > Yeah, just saw your other mail. Thanks for the explanation! --Kyle ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-16 19:05 ` Vladislav Bolkhovitin @ 2010-06-16 20:35 ` David Miller -1 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:35 UTC (permalink / raw) To: vst; +Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Wed, 16 Jun 2010 23:05:41 +0400 > We in SCST project have a very strange problem on Sparc. Our main > module scst.ko, if built as a module out of the kernel tree, can't be > loaded and "modprobe scst" returns: > > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 You're building the module with incorrect compiler flags, in particular somehow the "-mcmodel=medlow" option is not getting passed into the module build and thus the wrong code model is being used to build the module. There are a host of other sparc64 specific compiler options that must be present for a correct build as well. The only way to get it done correctly is to properly inherit the option settings made by arch/sparc/Makefile and friends in the kernel tree. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-16 20:35 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:35 UTC (permalink / raw) To: vst; +Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Wed, 16 Jun 2010 23:05:41 +0400 > We in SCST project have a very strange problem on Sparc. Our main > module scst.ko, if built as a module out of the kernel tree, can't be > loaded and "modprobe scst" returns: > > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 You're building the module with incorrect compiler flags, in particular somehow the "-mcmodel=medlow" option is not getting passed into the module build and thus the wrong code model is being used to build the module. There are a host of other sparc64 specific compiler options that must be present for a correct build as well. The only way to get it done correctly is to properly inherit the option settings made by arch/sparc/Makefile and friends in the kernel tree. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-16 20:35 ` David Miller @ 2010-06-22 19:07 ` Vladislav Bolkhovitin -1 siblings, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-22 19:07 UTC (permalink / raw) To: David Miller Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, Michal Marek, linux-kbuild [-- Attachment #1: Type: text/plain, Size: 1585 bytes --] David Miller, on 06/17/2010 12:35 AM wrote: > From: Vladislav Bolkhovitin <vst@vlnb.net> > Date: Wed, 16 Jun 2010 23:05:41 +0400 > >> We in SCST project have a very strange problem on Sparc. Our main >> module scst.ko, if built as a module out of the kernel tree, can't be >> loaded and "modprobe scst" returns: >> >> FATAL: Error inserting scst >> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format >> >> The following message is immediately spit out by the kernel: >> [ 1686.676534] module scst: Unknown relocation: 36 > > You're building the module with incorrect compiler flags, in > particular somehow the "-mcmodel=medlow" option is not getting passed > into the module build and thus the wrong code model is being used to > build the module. > > There are a host of other sparc64 specific compiler options that must > be present for a correct build as well. The only way to get it done > correctly is to properly inherit the option settings made by > arch/sparc/Makefile and friends in the kernel tree. Thank you. This gives us the direction away from the current dead end. We will make the needed changes in our Makefiles. But we surprised that such platform specific compiler flags have to be manually maintained by out of the kernel tree modules developers. We thought kbuild environment doing it automatically. Particularly, Documentation/kbuild/modules.txt doesn't say anything about manual platform specific flags. I added kbuild developers on CC and attached again our Makefile just in case if they would like to look at it. Thanks, Vlad [-- Attachment #2: Makefile --] [-- Type: text/plain, Size: 3901 bytes --] SHELL=/bin/bash DEV_HANDLERS_DIR = dev_handlers ifneq ($(PATCHLEVEL),) SCST_INC_DIR := $(SUBDIRS)/../include obj-m := scst.o scst-y += scst_main.o scst-y += scst_targ.o scst-y += scst_lib.o #scst-y += scst_proc.o scst-y += scst_sysfs.o scst-y += scst_mem.o scst-y += scst_debug.o scst-y += scst_pres.o obj-$(CONFIG_SCST) += scst.o dev_handlers/ obj-$(BUILD_DEV) += $(DEV_HANDLERS_DIR)/ else ifeq ($(KVER),) ifeq ($(KDIR),) KVER = $(shell uname -r) KDIR := /lib/modules/$(KVER)/build endif else KDIR := /lib/modules/$(KVER)/build endif all: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m scst: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=n MODS_VERS := $(shell ls Modules.symvers 2>/dev/null) # It's renamed in 2.6.18 MOD_VERS := $(shell ls Module.symvers 2>/dev/null) install: all -rm -f $(INSTALL_DIR)/scsi_tgt.ko $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m \ modules_install install -d $(INSTALL_DIR_H) install -m 644 ../include/scst.h $(INSTALL_DIR_H) install -m 644 ../include/scst_sgv.h $(INSTALL_DIR_H) install -m 644 ../include/scst_debug.h $(INSTALL_DIR_H) install -m 644 ../include/scst_user.h $(INSTALL_DIR_H) install -m 644 ../include/scst_const.h $(INSTALL_DIR_H) ifneq ($(MODS_VERS),) rm -f $(INSTALL_DIR_H)/Module.symvers install -m 644 Modules.symvers $(INSTALL_DIR_H) endif ifneq ($(MOD_VERS),) rm -f $(INSTALL_DIR_H)/Modules.symvers install -m 644 Module.symvers $(INSTALL_DIR_H) endif -/sbin/depmod -a $(KVER) mkdir -p /var/lib/scst/pr @echo "****************************************************************" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "*!! !!*" @echo "*!! Now don't forget to rebuild and reinstall all your !!*" @echo "*!! target drivers, custom dev handlers and necessary user !!*" @echo "*!! space applications. Otherwise, because of the versions !!*" @echo "*!! mismatch, you could have many problems and crashes. !!*" @echo "*!! See IMPORTANT note in the \"Installation\" section of !!*" @echo "*!! SCST's README file for more info. !!*" @echo "*!! !!*" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "****************************************************************" uninstall: cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ rm -f $(INSTALL_DIR)/scst.ko -rmdir $(INSTALL_DIR) 2>/dev/null -/sbin/depmod -a $(KVER) rm -rf $(INSTALL_DIR_H) endif ifeq ($(KVER),) INSTALL_DIR := $(DESTDIR)/lib/modules/$(shell uname -r)/extra else INSTALL_DIR := $(DESTDIR)/lib/modules/$(KVER)/extra endif INSTALL_DIR_H := $(DESTDIR)/usr/local/include/scst EXTRA_CFLAGS += -I$(SCST_INC_DIR) -Wextra -Wno-unused-parameter \ -Wno-missing-field-initializers #EXTRA_CFLAGS += -DCONFIG_SCST_STRICT_SERIALIZING EXTRA_CFLAGS += -DCONFIG_SCST_EXTRACHECKS #EXTRA_CFLAGS += -DCONFIG_SCST_USE_EXPECTED_VALUES #EXTRA_CFLAGS += -DCONFIG_SCST_TEST_IO_IN_SIRQ #EXTRA_CFLAGS += -DCONFIG_SCST_ABORT_CONSIDER_FINISHED_TASKS_AS_NOT_EXISTING #EXTRA_CFLAGS += -fno-inline #EXTRA_CFLAGS += -DCONFIG_SCST_TRACING EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_TM -DCONFIG_SCST_TM_DBG_GO_OFFLINE #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_RETRY #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_OOM #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_SN #EXTRA_CFLAGS += -DCONFIG_SCST_MEASURE_LATENCY # If defined, makes SCST zero allocated data buffers. # Undefining it considerably improves performance and eases CPU load, # but could create a security hole (information leakage), so # enable it if you have strict security requirements. #EXTRA_CFLAGS += -DSCST_STRICT_SECURITY .PHONY: all install uninstall ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-22 19:07 ` Vladislav Bolkhovitin 0 siblings, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-22 19:07 UTC (permalink / raw) To: David Miller Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, Michal Marek, linux-kbuild [-- Attachment #1: Type: text/plain, Size: 1585 bytes --] David Miller, on 06/17/2010 12:35 AM wrote: > From: Vladislav Bolkhovitin <vst@vlnb.net> > Date: Wed, 16 Jun 2010 23:05:41 +0400 > >> We in SCST project have a very strange problem on Sparc. Our main >> module scst.ko, if built as a module out of the kernel tree, can't be >> loaded and "modprobe scst" returns: >> >> FATAL: Error inserting scst >> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format >> >> The following message is immediately spit out by the kernel: >> [ 1686.676534] module scst: Unknown relocation: 36 > > You're building the module with incorrect compiler flags, in > particular somehow the "-mcmodel=medlow" option is not getting passed > into the module build and thus the wrong code model is being used to > build the module. > > There are a host of other sparc64 specific compiler options that must > be present for a correct build as well. The only way to get it done > correctly is to properly inherit the option settings made by > arch/sparc/Makefile and friends in the kernel tree. Thank you. This gives us the direction away from the current dead end. We will make the needed changes in our Makefiles. But we surprised that such platform specific compiler flags have to be manually maintained by out of the kernel tree modules developers. We thought kbuild environment doing it automatically. Particularly, Documentation/kbuild/modules.txt doesn't say anything about manual platform specific flags. I added kbuild developers on CC and attached again our Makefile just in case if they would like to look at it. Thanks, Vlad [-- Attachment #2: Makefile --] [-- Type: text/plain, Size: 3901 bytes --] SHELL=/bin/bash DEV_HANDLERS_DIR = dev_handlers ifneq ($(PATCHLEVEL),) SCST_INC_DIR := $(SUBDIRS)/../include obj-m := scst.o scst-y += scst_main.o scst-y += scst_targ.o scst-y += scst_lib.o #scst-y += scst_proc.o scst-y += scst_sysfs.o scst-y += scst_mem.o scst-y += scst_debug.o scst-y += scst_pres.o obj-$(CONFIG_SCST) += scst.o dev_handlers/ obj-$(BUILD_DEV) += $(DEV_HANDLERS_DIR)/ else ifeq ($(KVER),) ifeq ($(KDIR),) KVER = $(shell uname -r) KDIR := /lib/modules/$(KVER)/build endif else KDIR := /lib/modules/$(KVER)/build endif all: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m scst: $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=n MODS_VERS := $(shell ls Modules.symvers 2>/dev/null) # It's renamed in 2.6.18 MOD_VERS := $(shell ls Module.symvers 2>/dev/null) install: all -rm -f $(INSTALL_DIR)/scsi_tgt.ko $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) BUILD_DEV=m \ modules_install install -d $(INSTALL_DIR_H) install -m 644 ../include/scst.h $(INSTALL_DIR_H) install -m 644 ../include/scst_sgv.h $(INSTALL_DIR_H) install -m 644 ../include/scst_debug.h $(INSTALL_DIR_H) install -m 644 ../include/scst_user.h $(INSTALL_DIR_H) install -m 644 ../include/scst_const.h $(INSTALL_DIR_H) ifneq ($(MODS_VERS),) rm -f $(INSTALL_DIR_H)/Module.symvers install -m 644 Modules.symvers $(INSTALL_DIR_H) endif ifneq ($(MOD_VERS),) rm -f $(INSTALL_DIR_H)/Modules.symvers install -m 644 Module.symvers $(INSTALL_DIR_H) endif -/sbin/depmod -a $(KVER) mkdir -p /var/lib/scst/pr @echo "****************************************************************" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "*!! !!*" @echo "*!! Now don't forget to rebuild and reinstall all your !!*" @echo "*!! target drivers, custom dev handlers and necessary user !!*" @echo "*!! space applications. Otherwise, because of the versions !!*" @echo "*!! mismatch, you could have many problems and crashes. !!*" @echo "*!! See IMPORTANT note in the \"Installation\" section of !!*" @echo "*!! SCST's README file for more info. !!*" @echo "*!! !!*" @echo "*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*" @echo "****************************************************************" uninstall: cd $(DEV_HANDLERS_DIR) && $(MAKE) $@ rm -f $(INSTALL_DIR)/scst.ko -rmdir $(INSTALL_DIR) 2>/dev/null -/sbin/depmod -a $(KVER) rm -rf $(INSTALL_DIR_H) endif ifeq ($(KVER),) INSTALL_DIR := $(DESTDIR)/lib/modules/$(shell uname -r)/extra else INSTALL_DIR := $(DESTDIR)/lib/modules/$(KVER)/extra endif INSTALL_DIR_H := $(DESTDIR)/usr/local/include/scst EXTRA_CFLAGS += -I$(SCST_INC_DIR) -Wextra -Wno-unused-parameter \ -Wno-missing-field-initializers #EXTRA_CFLAGS += -DCONFIG_SCST_STRICT_SERIALIZING EXTRA_CFLAGS += -DCONFIG_SCST_EXTRACHECKS #EXTRA_CFLAGS += -DCONFIG_SCST_USE_EXPECTED_VALUES #EXTRA_CFLAGS += -DCONFIG_SCST_TEST_IO_IN_SIRQ #EXTRA_CFLAGS += -DCONFIG_SCST_ABORT_CONSIDER_FINISHED_TASKS_AS_NOT_EXISTING #EXTRA_CFLAGS += -fno-inline #EXTRA_CFLAGS += -DCONFIG_SCST_TRACING EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG -g -fno-inline -fno-inline-functions #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_TM -DCONFIG_SCST_TM_DBG_GO_OFFLINE #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_RETRY #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_OOM #EXTRA_CFLAGS += -DCONFIG_SCST_DEBUG_SN #EXTRA_CFLAGS += -DCONFIG_SCST_MEASURE_LATENCY # If defined, makes SCST zero allocated data buffers. # Undefining it considerably improves performance and eases CPU load, # but could create a security hole (information leakage), so # enable it if you have strict security requirements. #EXTRA_CFLAGS += -DSCST_STRICT_SECURITY .PHONY: all install uninstall ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-22 19:07 ` Vladislav Bolkhovitin @ 2010-06-22 19:35 ` Sam Ravnborg -1 siblings, 0 replies; 24+ messages in thread From: Sam Ravnborg @ 2010-06-22 19:35 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: David Miller, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, Michal Marek, linux-kbuild On Tue, Jun 22, 2010 at 11:07:51PM +0400, Vladislav Bolkhovitin wrote: > > David Miller, on 06/17/2010 12:35 AM wrote: >> From: Vladislav Bolkhovitin <vst@vlnb.net> >> >> You're building the module with incorrect compiler flags, in >> particular somehow the "-mcmodel=medlow" option is not getting passed >> into the module build and thus the wrong code model is being used to >> build the module. >> > Thank you. This gives us the direction away from the current dead end. > We will make the needed changes in our Makefiles. > > But we surprised that such platform specific compiler flags have to be > manually maintained by out of the kernel tree modules developers. We > thought kbuild environment doing it automatically. Particularly, > Documentation/kbuild/modules.txt doesn't say anything about manual > platform specific flags. They should all be there automagically. A few things to try out... What machine is this being build on? Your Makefile contains this: > ifeq ($(KVER),) > ifeq ($(KDIR),) > KVER = $(shell uname -r) > KDIR := /lib/modules/$(KVER)/build > endif > else > KDIR := /lib/modules/$(KVER)/build > endif > But does /lib/modules/... contain a sparc kernel? You could try to build your module using: V=1 And reply with the output. This should give a clue about what flags are picked up from where. Most of your Makefile looks fine - I guess we need to find the bug in the build environmnet and not in the Makefile. Sam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-22 19:35 ` Sam Ravnborg 0 siblings, 0 replies; 24+ messages in thread From: Sam Ravnborg @ 2010-06-22 19:35 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: David Miller, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, Michal Marek, linux-kbuild On Tue, Jun 22, 2010 at 11:07:51PM +0400, Vladislav Bolkhovitin wrote: > > David Miller, on 06/17/2010 12:35 AM wrote: >> From: Vladislav Bolkhovitin <vst@vlnb.net> >> >> You're building the module with incorrect compiler flags, in >> particular somehow the "-mcmodel=medlow" option is not getting passed >> into the module build and thus the wrong code model is being used to >> build the module. >> > Thank you. This gives us the direction away from the current dead end. > We will make the needed changes in our Makefiles. > > But we surprised that such platform specific compiler flags have to be > manually maintained by out of the kernel tree modules developers. We > thought kbuild environment doing it automatically. Particularly, > Documentation/kbuild/modules.txt doesn't say anything about manual > platform specific flags. They should all be there automagically. A few things to try out... What machine is this being build on? Your Makefile contains this: > ifeq ($(KVER),) > ifeq ($(KDIR),) > KVER = $(shell uname -r) > KDIR := /lib/modules/$(KVER)/build > endif > else > KDIR := /lib/modules/$(KVER)/build > endif > But does /lib/modules/... contain a sparc kernel? You could try to build your module using: V=1 And reply with the output. This should give a clue about what flags are picked up from where. Most of your Makefile looks fine - I guess we need to find the bug in the build environmnet and not in the Makefile. Sam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-22 19:35 ` Sam Ravnborg @ 2010-06-22 21:17 ` David Miller -1 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-22 21:17 UTC (permalink / raw) To: sam Cc: vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, mmarek, linux-kbuild From: Sam Ravnborg <sam@ravnborg.org> Date: Tue, 22 Jun 2010 21:35:30 +0200 > Most of your Makefile looks fine - I guess we need to find the bug > in the build environmnet and not in the Makefile. Sam, note that these guys are working with 2.6.26 or some ancient kernel like that :-/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-22 21:17 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-22 21:17 UTC (permalink / raw) To: sam Cc: vst, sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, mmarek, linux-kbuild From: Sam Ravnborg <sam@ravnborg.org> Date: Tue, 22 Jun 2010 21:35:30 +0200 > Most of your Makefile looks fine - I guess we need to find the bug > in the build environmnet and not in the Makefile. Sam, note that these guys are working with 2.6.26 or some ancient kernel like that :-/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc 2010-06-22 19:07 ` Vladislav Bolkhovitin @ 2010-06-22 21:16 ` David Miller -1 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-22 21:16 UTC (permalink / raw) To: vst Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, mmarek, linux-kbuild From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Tue, 22 Jun 2010 23:07:51 +0400 > But we surprised that such platform specific compiler flags have to be > manually maintained by out of the kernel tree modules developers. You don't, Kbuild should do it transprently for you. It's possible you're simply not using kbuild correctly for external module builds, or something in your Makefile is overriding the arch specific CFLAGS. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Error "Unknown relocation: 36" on module load on Sparc @ 2010-06-22 21:16 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-22 21:16 UTC (permalink / raw) To: vst Cc: sparclinux, simone.ricci, scst-devel, linux-kernel, Nick.Couchman, mmarek, linux-kbuild From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Tue, 22 Jun 2010 23:07:51 +0400 > But we surprised that such platform specific compiler flags have to be > manually maintained by out of the kernel tree modules developers. You don't, Kbuild should do it transprently for you. It's possible you're simply not using kbuild correctly for external module builds, or something in your Makefile is overriding the arch specific CFLAGS. ^ permalink raw reply [flat|nested] 24+ messages in thread
* How to printk/sprintf uint64_t on Sparc without format and argument [not found] <AANLkTimuv7nOlcGFxqPZlwcAjLmFMiLAvbA5O7F32Wbg@mail.gmail.com> @ 2010-06-16 19:08 ` Vladislav Bolkhovitin 2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Vladislav Bolkhovitin 1 sibling, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-16 19:08 UTC (permalink / raw) To: sparclinux; +Cc: Simone Ricci, scst-devel, Joe Eykholt, linux-kernel Hello, We in SCST project need to printk/sprintf variables of type uint64_t. Size of those variables is required to be 64-bit integer. On x86 we printk/sprintf them as %lld, but on Sparc we have a compiler warnings like: scst/src/scst_targ.c:2136: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’. It is because on Sparc uint64_t defined as unsigned long, but on x86 - as unsigned long long. Sure, we can cast all the cases to unsigned long long, but we wonder, maybe there is a more elegant way to do that without the warning? For instance, like %z for size_t or PRId64 in the user space. Thanks, Vlad ^ permalink raw reply [flat|nested] 24+ messages in thread
* How to printk/sprintf uint64_t on Sparc without format and argument types mismatch @ 2010-06-16 19:08 ` Vladislav Bolkhovitin 0 siblings, 0 replies; 24+ messages in thread From: Vladislav Bolkhovitin @ 2010-06-16 19:08 UTC (permalink / raw) To: sparclinux; +Cc: Simone Ricci, scst-devel, Joe Eykholt, linux-kernel Hello, We in SCST project need to printk/sprintf variables of type uint64_t. Size of those variables is required to be 64-bit integer. On x86 we printk/sprintf them as %lld, but on Sparc we have a compiler warnings like: scst/src/scst_targ.c:2136: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’. It is because on Sparc uint64_t defined as unsigned long, but on x86 - as unsigned long long. Sure, we can cast all the cases to unsigned long long, but we wonder, maybe there is a more elegant way to do that without the warning? For instance, like %z for size_t or PRId64 in the user space. Thanks, Vlad ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to printk/sprintf uint64_t on Sparc without format and 2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Vladislav Bolkhovitin @ 2010-06-16 19:29 ` Kyle McMartin -1 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 19:29 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: sparclinux, Simone Ricci, scst-devel, Joe Eykholt, linux-kernel On Wed, Jun 16, 2010 at 11:08:03PM +0400, Vladislav Bolkhovitin wrote: > scst/src/scst_targ.c:2136: warning: format ?%llx? expects type ?long > long unsigned int?, but argument 4 has type ?uint64_t?. > > It is because on Sparc uint64_t defined as unsigned long, but on x86 - > as unsigned long long. > From your other mail, it looks like you're using 2.6.26... this is ancient! Sparc has since been fixed to use unsigned long long for u64. commit 9018113649348c689da107166c05d436cd52e7bf Author: Sam Ravnborg <sam@ravnborg.org> Date: Tue Jan 6 13:19:28 2009 -0800 sparc64: Use unsigned long long for u64. regards, Kyle ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to printk/sprintf uint64_t on Sparc without format and argument types mismatch @ 2010-06-16 19:29 ` Kyle McMartin 0 siblings, 0 replies; 24+ messages in thread From: Kyle McMartin @ 2010-06-16 19:29 UTC (permalink / raw) To: Vladislav Bolkhovitin Cc: sparclinux, Simone Ricci, scst-devel, Joe Eykholt, linux-kernel On Wed, Jun 16, 2010 at 11:08:03PM +0400, Vladislav Bolkhovitin wrote: > scst/src/scst_targ.c:2136: warning: format ?%llx? expects type ?long > long unsigned int?, but argument 4 has type ?uint64_t?. > > It is because on Sparc uint64_t defined as unsigned long, but on x86 - > as unsigned long long. > >From your other mail, it looks like you're using 2.6.26... this is ancient! Sparc has since been fixed to use unsigned long long for u64. commit 9018113649348c689da107166c05d436cd52e7bf Author: Sam Ravnborg <sam@ravnborg.org> Date: Tue Jan 6 13:19:28 2009 -0800 sparc64: Use unsigned long long for u64. regards, Kyle ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to printk/sprintf uint64_t on Sparc without format and 2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Vladislav Bolkhovitin @ 2010-06-16 20:36 ` David Miller -1 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:36 UTC (permalink / raw) To: vst; +Cc: sparclinux, simone.ricci, scst-devel, jeykholt, linux-kernel From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Wed, 16 Jun 2010 23:08:03 +0400 > We in SCST project need to printk/sprintf variables of type > uint64_t. Size of those variables is required to be 64-bit integer. On > x86 we printk/sprintf them as %lld, but on Sparc we have a compiler > warnings like: > > scst/src/scst_targ.c:2136: warning: format ¡%llx¢ expects type ¡long > long unsigned int¢, but argument 4 has type ¡uint64_t¢. > > It is because on Sparc uint64_t defined as unsigned long, but on x86 - > as unsigned long long. You must use %ll and explicitly cast the argument to "long long". ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¬¥ªÜ–)îÇø§¶\x17›¡Ü¨}©ž²Æ zÚ&j:+v‰¨þø\x1e¯ù\x1e®w¥þŠà2ŠÞ™¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ—ú+ƒùšŽŠÝ¢jÿŠwèþ^[f ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to printk/sprintf uint64_t on Sparc without format and argument types mismatch @ 2010-06-16 20:36 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-06-16 20:36 UTC (permalink / raw) To: vst; +Cc: sparclinux, simone.ricci, scst-devel, jeykholt, linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: Text/Plain; charset=iso-8859-7, Size: 764 bytes --] From: Vladislav Bolkhovitin <vst@vlnb.net> Date: Wed, 16 Jun 2010 23:08:03 +0400 > We in SCST project need to printk/sprintf variables of type > uint64_t. Size of those variables is required to be 64-bit integer. On > x86 we printk/sprintf them as %lld, but on Sparc we have a compiler > warnings like: > > scst/src/scst_targ.c:2136: warning: format ¡%llx¢ expects type ¡long > long unsigned int¢, but argument 4 has type ¡uint64_t¢. > > It is because on Sparc uint64_t defined as unsigned long, but on x86 - > as unsigned long long. You must use %ll and explicitly cast the argument to "long long". ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-06-22 21:17 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTimuv7nOlcGFxqPZlwcAjLmFMiLAvbA5O7F32Wbg@mail.gmail.com>
2010-06-16 19:05 ` Error "Unknown relocation: 36" on module load on Sparc Vladislav Bolkhovitin
2010-06-16 19:05 ` Vladislav Bolkhovitin
2010-06-16 19:22 ` Kyle McMartin
2010-06-16 19:22 ` Kyle McMartin
2010-06-16 20:38 ` David Miller
2010-06-16 20:38 ` David Miller
2010-06-16 20:40 ` Kyle McMartin
2010-06-16 20:40 ` Kyle McMartin
2010-06-16 20:35 ` David Miller
2010-06-16 20:35 ` David Miller
2010-06-22 19:07 ` Vladislav Bolkhovitin
2010-06-22 19:07 ` Vladislav Bolkhovitin
2010-06-22 19:35 ` Sam Ravnborg
2010-06-22 19:35 ` Sam Ravnborg
2010-06-22 21:17 ` David Miller
2010-06-22 21:17 ` David Miller
2010-06-22 21:16 ` David Miller
2010-06-22 21:16 ` David Miller
2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument Vladislav Bolkhovitin
2010-06-16 19:08 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Vladislav Bolkhovitin
2010-06-16 19:29 ` How to printk/sprintf uint64_t on Sparc without format and Kyle McMartin
2010-06-16 19:29 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch Kyle McMartin
2010-06-16 20:36 ` How to printk/sprintf uint64_t on Sparc without format and David Miller
2010-06-16 20:36 ` How to printk/sprintf uint64_t on Sparc without format and argument types mismatch David Miller
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.