[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] .xif module load problem



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.