On 2002.10.24 07:07 Chuck Silvers wrote:

> hmm, looks like it might be dying in ofwboot.
It is dying in ofwboot as tcpdump showed.=20

> you can probably just use normal printf() debugging
> to narrow down where it crashes.
Sure, in this case. But if the kernel freezes somwhere deep in locore.S
or machdep.c on the way finding its console device, printf is no help.

Anyway, I threw lots of printf at ofwboot. It gets interresting in
sys/lib/libsa/open.c at         for (i =3D 0; i < nfsys; i++) {
printf( "open D i=3D%d, nfsys=3D%d file=3D'%s'\n", i , nfsys, file);
                error =3D FS_OPEN(&file_system[i])(file, f);
printf( "open e, nfsys=3D%d, error=3D%d\n", nfsys, error);

At the first printf nfsys is =3D=3D1, at the second printf nfsys is =3D=3D=
[some
random value].
This causes a second call to FS_OPEN, a macro that uses a function
pointer from the struct file_system[]. No surprise that this fails, as
file_system[] contains only one valid field in this case. So it seams
that somthing bad happens (to the stack?) somwhere in the libsa-NFS code
that garbels nfsys and possibly other variables.=20
I had a deeper look inside the nfs code and the point of failure is
somwhere on the way into rpc.c:rpc_getport(). If I put a printf inside
that function, that takes an additional parameter like nfsys besids the
format string, I get a "data access volation" at the execution of this
printf. I get no error if I put a simple printf with only a format
string bevore the other printf.=20
--=20



tsch=FC=DF,
         Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/