Local consensus is to stick with 2.2 for now. I think I have done most of the
changes necessary in my 2.2 tree to work with 64 bit already, since I can
successfully (though possibly not correctly, still unverified) create a dump.
My problem has been getting lcrash to work.
OK, I've gotten the 2.2 and 2.3 trees from SourceForge. I've updated my tree to
match as closely as possible, and brought the relevant arch changes over to
the Alpha tree also. However, I'm having a new problem with the build in
libklib. The new signal handler stuff, kl_signal.c, can't find a definition for
"greg_t", and neither can I. Doesn't seem to be defined in the 2.2 or 2.3 cvs
trees.
[root@localhost libklib]# mm
/bin/rm -f include/asm
(cd include ; /bin/ln -s asm-alpha asm; cd ..)
cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o
kl_signal.o kl_signal.c
kl_signal.c: In function `klib_sig_handler':
kl_signal.c:70: `greg_t' undeclared (first use in this function)
kl_signal.c:70: (Each undeclared identifier is reported only once
kl_signal.c:70: for each function it appears in.)
kl_signal.c:70: `gregs' undeclared (first use in this function)
kl_signal.c:70: structure has no member named `gregs'
kl_signal.c:71: parse error before `esi'
kl_signal.c:73: `esi' undeclared (first use in this function)
kl_signal.c:73: `ESI' undeclared (first use in this function)
kl_signal.c:74: `esp' undeclared (first use in this function)
kl_signal.c:74: `ESP' undeclared (first use in this function)
kl_signal.c:76: `badaddr' undeclared (first use in this function)
kl_signal.c:76: parse error before `sip'
make: *** [kl_signal.o] Error 1
Also, I am having some troubles with my ISP. Yesterday, I discovered that I
could no longer get a second DHCP IP from them. I sent an email about this, and
hopefully I hear why soon. In the meantime, I switched the AS200 from the hub
to the network switch, placing it inside my firewall so I can work on it.
On 30-May-2000 Brian Hall wrote:
>
> -----FW: <392DA260.ABBA8D31@xxxxxxx>-----
>
> Date: Thu, 25 May 2000 15:00:00 -0700
> Sender: tjm@xxxxxxx
> From: Tom Morano <tjm@xxxxxxx>
> To: Brian Hall <brianw.hall@xxxxxxxxxx>
> Subject: Re: Home from vacation
> Cc: "Gilford, Kevin" <Kevin.Gilford@xxxxxxxxxx>,
> Matt D. Robinson <yakker@xxxxxxxxxxxxxx>, tjm@xxxxxxx
>
> Brian Hall wrote:
>>
>> Got back home today from Virginia. Found the AS200 offline (figures);
>> restarted
>> the network script. It is back online at 208.202.104.224. Any breakthroughs
>> while I was gone?
>
> Hi Brian,
>
> I've been working on getting the 2.3 version of lcrash up and running
> on ia64 (one of my top priorities). Although this does not directly
> help you with your Alpha port, both systems have 64-bit architectures
> and many of the issues you've faced are similar to ones that I've had
> to deal with. I have a version of lcrash that is able to start up on a
> live ia64 system (using /boot/System.map and /dev/mem), dump memory,
> generate system status output, list active tasks, display kernel data
> type information, etc. In other words, I have most of the basic
> functionality working. In order to accomplish this, I had to move some
> code around and address numerous conflicts and data type casting
> issues. I've checked all these changes into our LKCD source repository
> on SourceForge (project lkcd). You are welcome to pick them up and
> give them a try (after converting the arch/ia64 stuff to arch/Alpha).
>
> If you are not able to go to 2.3 then I would suggest bringing your
> lcrash source base more up-to-date with the 2.2 tree on SourceForge.
> You started your porting effort early on and there have been a number
> of new features added and bugs fixed since then. I haven't made any
> 32-bit/64-bit changes to the 2.2 tree, so if you must stay at that
> level, then some additional work will be necessary. I guess it depends
> on which version of the kernel you'll be running on the Alpha systems.
> In either case, having you work off a more up-to-date source base will
> allow me to merge your changes in more easily.
>
> As far as the kernel portion of the LKCD project goes, that is
> something that Matt has been looking into. For the most part, lcrash
> is independent from the kernel. There are a couple of kernel changes
> between 2.2 and 2.3 (names of kernel variables, pointer vs. pointer to
> pointer, etc.) that had to be addressed in lcrash. The key is that
> lcrash has to be compiled using the same header and configuration
> files as the kernel. This is to ensure that the contents of memory
> ligns up properly with kernel data type definitions.
>
> Let me know how you plan to proceed (2.2 or 2.3) and I'll see what
> I can do to help.
>
> Thanks,
>
> Tom
--
|