From mint-bounce@lists.fishpool.fi  Sun Apr 17 23:42:29 2005
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Message-ID: <4262D7EC.8070808@seznam.cz>
Date: Sun, 17 Apr 2005 17:41:00 -0400
From: Standa Opichal <opichals@seznam.cz>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mint@fishpool.com
Subject: Re: [MiNT] .xif module load problem
References: <42606A32.8070301@seznam.cz> <426152EF.7030404@seznam.cz> <42620A70.5030206@obta.uw.edu.pl>
In-Reply-To: <42620A70.5030206@obta.uw.edu.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: opichals@seznam.cz
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=0.0 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00
X-Spam-Level: 

Hi!

Well, I have tried to make dummy.xif driver_init() with empty body and 
it still did the same thing - kept stalling the boot process. When 
modifying the module.c code to not to call the init() at all it doesn't 
stall.

... calling external .xif module's init() function corrupts the stack as 
I mentioned earlier. It seems a little weird when it looks like the code 
below. When I toggle the #if 1 in the xif_load which employs the 
xif_module_init() which is an adaptation of module.c:module_init() for 
the .xif modules the problem disappears. But doesn't touch the stack 
except for store/restore of all registers...

More thoughts?

STanda


/* dummy.xif ::: from sys/socket/xif/main.c */

long init (struct kerinfo *ker, struct netinfo *net);
long driver_init (void);

struct kerinfo *KERNEL;
struct netinfo *NETINFO;


long
init (struct kerinfo *k, struct netinfo *n)
{
	KERNEL = k;
	NETINFO = n;
	
	return (driver_init () != 0) ? 1 : 0;
}

/* dummy.xif ::: from sys/socket/xif/dummyeth.c */

long driver_init(void) {
	return 0;
}

/* inet.xdd ::: from sys/socket/inet4/ifload.c */

static long
load_xif (struct basepage *b, const char *name)
{
	long (*init)(struct kerinfo *, struct netinfo *);
	long r;
	
	DEBUG (("load_xif: enter (0x%lx, %s)", b, name));
	DEBUG (("load_xif: init 0x%lx, size %li", (void *) b->p_tbase, 
(b->p_tlen + b->p_dlen + b->p_blen)));
	
	/* pass a pointer to the drivers file name on to the
	 * driver.
	 */
	netinfo.fname = name;
	
#if 1
	init = (long (*)(struct kerinfo *, struct netinfo *))b->p_tbase;
	r = (*init)(KERNEL, &netinfo);
#else
	r = xif_module_init((void*)b->p_tbase, KERNEL, &netinfo);
#endif
	
	netinfo.fname = NULL;
	
	return r;
}


Konrad Kokoszkiewicz wrote:
>> Also I don't understand why this workaround fixes the problem. Because 
>> the actual problem is a stack corruption. After the dummy.xif module 
>> successful load the load_modules() dirh.fs contains invalid filesystem 
>> pointer... This happens for any .xif module I have tried.
> 
> 
> IIRC, the workaround was introduced because the routine didn't otherwise 
> want to load anything except the first module it met. So maybe the 
> problem is inside the module's init() code - or rather inside kernel 
> functions it possibly calls - and not inside the loading routine.
>