[OpenAFS] porting to Linux ARM
Sun, 03 Sep 2006 06:59:58 -0400
Albrecht Gebhardt <email@example.com> writes:
> From: Albrecht Gebhardt <firstname.lastname@example.org>
> To: email@example.com
> bosserver, vlserver, fileserver, volserver, ptserver can be compiled
> and are running (but untested if they really work, testing this would
> easier with a running openafs client).
Actually most of these you can test without a working cache manager.
bosserver doesn't talk to cache managers at all, just bos.
ptserver talks to your fileserver and you (pts), but not
to your cache manager.
volserver talks to you (vos), never to the cache manager.
vlserver talks to your cache manager and you (vos).
ptserver is usually a good thing to start with, since it doesn't depend
on anything else (you don't even need bosserver to run it).
If you already have a working afs environment, then you have
a client machine with cache manager & friends. A 386 based
client machine will work fine with your arm based server.
You probably don't want to run the cm on your server anyways.
Once you have everything else tested, then you might want
to test out the cm on arm. Ideally your servers should be
some other machine - even if you eventually intend to put
them all on one machine, you don't really need to have
a feral cache manager roach your server world.
> Unable to handle kernel paging request at virtual address c25c7af8
> Code: e89daff0 e5981008 e5953004 e0613003 (e7942103)
These all mean something -- but only to you. This last line contains
the next few instructions to be executed. The backtrace before that,
and the register display before that are all meaningful - but
only to somebody who has the load map handy. Some versions of linux
have provisions to connect to a "debugging" instance of gdb via something
like a serial port - you can get much higher quality data if you can get
that going. Some versions of klog/syslog can also resolve the
numeric addresses into symbolic names.
If it dies during module loading, that's real early. A crude
technique would be to put lots of printf's in the initialization code
path. It won't be as good as gdb, but with a bit of forethought
and patience, you can use "binary search" to resolve your point of
failure fairly quickly.