I'm trying to upgrade from the 2.08 release which comes with the
kernel source to (preferably) 4.02, but having show-stopper problems.
I hope someone here can shed some light on what I'm doing wrong.
I have a very "vanilla" setup: internal FDC, an old Colorado internal
QIC-80 drive. Running kernel 2.0.36. Everything works "out of the
box" with ftape 2.08. About the only think that's unusual about my
setup is that I compile my kernel with egcs (1.1b) not gcc. I've
tried various modutils versions; currently, I'm using 2.1.71.
Neither ftape 3.04d nor 4.02 will run. I've done more debugging on
3.04d. What happens with that is that ftape.o loads okay -- I'm
loading from the commandline with insmod -- but zftape.o seg faults
when I try to load it. From looking at the code, conditionally
compiling out stuff, etc., it looks like it's getting into trouble
as soon as it enters zft_init() and tries to call back into ftape.o
(ftape_tracing_call()) -- it's like the address of ftape_tracing_call()
never gets properly fixed up, or the stack is hammered, or something.
In any case, the seg fault register dump appears to have a bogus
address in IP, and the return address on the stack is immediately
after the ftape_tracing_call() call in zft_init().
With 4.02, the problem is similar. I've gotten zftape.o to load,
but I've never gotten ftape-internal.o to load. Sometimes the
load of zftape.o fails, too; it seems to be dependent on modutils
version (??) or maybe compiler optimization switches (??). Sometimes
I get a plain seg fault, and sometimes I get a "kernel paging
request fails".
I'm not loading zft_compressor.o; I don't have any compressed tapes
and don't need it.
I've tried compiling ftape with egcs, and also with gcc (2.7.2.1)
with similar results, so it doesn't seem to be an egcs-related
problem.
Can somebody please give me a hint as to where to look next? I've
been using ftape for a long time now, and this is the most frustration
it's ever given me.
Brad Kaiser
([EMAIL PROTECTED])
