aha152x alternates between not compiling and not working. The kernel has it not compiling.
gcc -Wp,-MD,drivers/scsi/.aha152x.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE -DAHA152X_STAT -DAUTOCONF -DKBUILD_BASENAME=aha152x -DKBUILD_MODNAME=aha152x -c -o drivers/scsi/aha152x.o drivers/scsi/aha152x.c
drivers/scsi/aha152x.c: In function `aha152x_detect':
drivers/scsi/aha152x.c:1134: too many arguments to function `pnp_activate_dev'
make[2]: *** [drivers/scsi/aha152x.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
Hogwash. I unpacked the source, copied the (working) 2.5.59 .config,
and made oldconfig, bzImage, modules and modules_install in that order.
I never even thought of playing with SUBDIRS... And the
/lib/modules/2.5.63 directory did not even exist when I started, so the
whine about stale module entries clearly doesn't mean what I would
assume.
++ make modules_install
make -rR -f scripts/Makefile.modinst
scripts/Makefile.modinst:16: *** Uh-oh, you have stale module entries. You messed with SUBDIRS, do not complain if something goes wrong.
mkdir -p /lib/modules/2.5.63/kernel/fs; cp fs/binfmt_aout.ko /lib/modules/2.5.63/kernel/fs
cp: cannot stat `fs/binfmt_aout.ko': No such file or directory
make[1]: *** [fs/binfmt_aout.ko] Error 1
make: *** [_modinst_] Error 2
On Mon, Mar 03, 2003 at 05:11:10PM -0500, Bill Davidsen wrote:
> scripts/Makefile.modinst:16: *** Uh-oh, you have stale module entries. You messed with SUBDIRS, do not complain if something goes wrong.
This happens if you have encountered a compile error in a module.
In this case you did not succeed the compilation of fs/binfmt_aout,
and therefore no .o file can be located.
kbuild assumes this is because you have messed with SUBDIRS, which is wrong.
Kai - the following patch fixes this for me.
Sam
===== scripts/Makefile.build 1.31 vs edited =====
--- 1.31/scripts/Makefile.build Wed Feb 19 23:42:13 2003
+++ edited/scripts/Makefile.build Tue Mar 4 21:40:47 2003
@@ -163,12 +163,12 @@
# Single-part modules are special since we need to mark them in $(MODVERDIR)
$(single-used-m): %.o: %.c FORCE
- $(touch-module)
ifdef CONFIG_MODVERSIONS
$(call if_changed_rule,vcc_o_c)
else
$(call if_changed_dep,cc_o_c)
endif
+ $(touch-module)
quiet_cmd_cc_lst_c = MKLST $@
cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
@@ -262,8 +262,8 @@
$(call if_changed,link_multi-y)
$(multi-used-m) : %.o: $(multi-objs-m) FORCE
- $(touch-module)
$(call if_changed,link_multi-m)
+ $(touch-module)
targets += $(multi-used-y) $(multi-used-m)
On Tue, 4 Mar 2003, Sam Ravnborg wrote:
> On Mon, Mar 03, 2003 at 05:11:10PM -0500, Bill Davidsen wrote:
> > scripts/Makefile.modinst:16: *** Uh-oh, you have stale module entries. You messed with SUBDIRS, do not complain if something goes wrong.
>
> This happens if you have encountered a compile error in a module.
> In this case you did not succeed the compilation of fs/binfmt_aout,
> and therefore no .o file can be located.
> kbuild assumes this is because you have messed with SUBDIRS, which is wrong.
>
> Kai - the following patch fixes this for me.
Hmmh, interesting. The patch looks good to me, but there's still one thing
I don't understand: When compiling a module errors out, we should never
even go into the module postprocessing stage. Or were you running with -k?
--Kai
On Tue, 4 Mar 2003, Kai Germaschewski wrote:
> On Tue, 4 Mar 2003, Sam Ravnborg wrote:
>
> > On Mon, Mar 03, 2003 at 05:11:10PM -0500, Bill Davidsen wrote:
> > > scripts/Makefile.modinst:16: *** Uh-oh, you have stale module entries. You messed with SUBDIRS, do not complain if something goes wrong.
> >
> > This happens if you have encountered a compile error in a module.
> > In this case you did not succeed the compilation of fs/binfmt_aout,
> > and therefore no .o file can be located.
> > kbuild assumes this is because you have messed with SUBDIRS, which is wrong.
> >
> > Kai - the following patch fixes this for me.
>
> Hmmh, interesting. The patch looks good to me, but there's still one thing
> I don't understand: When compiling a module errors out, we should never
> even go into the module postprocessing stage. Or were you running with -k?
Yes, this is a s-l-o-w machine, I try to build as much as possible while
I'm at lunch, in meetings, etc. So the fail to find the modules was mine,
the bad error message was a result. And of course it would be nice if all
the modules which compiled in 2.5.59 would still compile in 2.5.63, so I
could spend time trying to debug why the aha152x doesn't actually *work*
if it has to share an interrupt. Since I can't change the IRQ of this old
stuff short of ripping the boards out and readdressing with a soldering
iron, I was hoping to take another path.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, Mar 04, 2003 at 03:28:05PM -0600, Kai Germaschewski wrote:
> Hmmh, interesting. The patch looks good to me, but there's still one thing
> I don't understand: When compiling a module errors out, we should never
> even go into the module postprocessing stage. Or were you running with -k?
What I did to provoke the error was the following:
0) Successfully compile of the tree
1) Edit dummy.c to provoke an error during compile time
2) Run make
It errored out when compiling dummy.c
3) Ignored the error, and su to root
4) make modules_install
So no make -k, I was just trying to install the modules that succeded so far.
Sam