James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote: > > On Thu, 2005-04-28 at 16:15 -0600, Moore, Eric Dean wrote: > > This patch can also be found at this URL: > > ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.01/ > > > > Changelog: > > (1) For statically linked drivers, fusion_init was not called, > > added call from mpt_register so its called when one of the scsi lld load. > > (2) little endian fix in mpt_put_msg_frame/mpt_get_msg_frame > > (3) Clarify help desc in Kconfig for FUSION_MAX_SGE. > > Surely this is just a simple link order problem? Can't we solve it like > the attached? > > James > > --- k/drivers/message/fusion/Makefile (mode:100644) > +++ l/drivers/message/fusion/Makefile (mode:100644) > @@ -32,7 +32,7 @@ > > #=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-} LSI_LOGIC > > -obj-$(CONFIG_FUSION_SPI) += mptspi.o mptscsih.o mptbase.o > -obj-$(CONFIG_FUSION_FC) += mptfc.o mptscsih.o mptbase.o > +obj-$(CONFIG_FUSION_SPI) += mptbase.o mptspi.o mptscsih.o > +obj-$(CONFIG_FUSION_FC) += mptbase.o mptfc.o mptscsih.o > obj-$(CONFIG_FUSION_CTL) += mptctl.o > obj-$(CONFIG_FUSION_LAN) += mptlan.o That would be a last resort :( I seem to recall people saying that this might not work over all extant binutilses, too. Doing something explicit via initcall levels sounds nicer. I agree that we don't understand what's going on yet - fusion_init() should have been called *sometime*, no matter what the linkage order is, and no matter what the chosen initcall levels. Booting with `initcall_debug' will tell us which initcalls are being called, and in which order. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
