Hi Kamal,

Well, this can be a bit tricky. There are few problems as I see it:

1) The crash handling function (dumpsys in machdep.c) does not seem to 
be implemented for any of the  powerpc-ports. I don't think it should be 
that hard to implement that (a lot of the code should be similar to the 
code in other ports, e.g. i386).

2) There are a few functions in libkvm that are not implemented for 
powerpc. These functions deals with converting virtual addresses to 
physical and hence using gdb on a powerpc kernel core image is pretty 
useless without this. A college of mine has however implemented these 
functions, we haven't tested it a whole lot but it seems to work ok. 
We'd be happy to make a patch of that code if someone in the NetBSD-team 
(or anyone else for that matter) would like to have a look at it.

3) I guess your system, like many (most?) other embedded systemes, does 
not have a disk and hence nowhere to dump the kernel core. There are a 
few possible solutions that I can think of (all of these will of course 
require a bit of hacking to implement) :
  - If the system has a larg enough flash memory it could be used as 
dump-device.
  - If the kernel is still in fairly good shape when the panic occurs 
one should be able to transmit the kernel core over the network to some 
other machine.
  - If the system has second set of RAM (maybe normally used for other 
purposes) as large or larger that the RAM used by NetBSD, the kernel 
core could be stored there. This means of course that this second set of 
RAM must not be clear or touched when the system is rebooted.
  - (A variant of the previous one). If the system has more RAM than it 
really uses (twice as much) one should be able to compile a debug kernel 
that only uses the lower half of the memory. The upper half can then be 
used for storing the kernel core.
- If you have a fairly intelligent bootloader it could when invoked 
after a panic-reboot detect this and do something smart (like sending 
the kernel core over the network or serial link). This has the advantage 
of that it will allways work no matter how messed up the kernel is. Of 
course this also requires that the RAM is not cleared or touched after 
reboot when the bootloader is invoked.

(We have used a combination of a couple of these methods on our embedded 
systems. This code is however proprietary and even if it wasn't it is so 
specific for our particualar setup that it wouldn't be of much use to 
anyone else).

To sum it up: you will need to put in some extra effort to make this 
work but it shouldn't be impossible.

Regards,
Erik Anggard



Kamal Prasad wrote:

>I would like to re-phrase this question:-
>--------------------------------------------
>there is an embedded device running netbsd on a
>powerpc processor. a panic will force the user to
>power down/up the system in order to get it
>operational. there is no soft-reboot mechanism in the
>system. the image on the embedded device is different
>from that on the remote machine (G4) which is used
>both to build the target kernel and the
>tftp/ftp/dhcp/nfs server for the embedded device.
>the embedded device picks the kernel from the server
>via a directly connected ethernet link.
>---------------------------------------------
>I need help in saving the core file on the G4 in case
>of a panic and to analyze the core with ref. to the
>source code rather than disassembled code which is
>what ddd does.
>thanks for any help.
>regards
>-kamal
>
>
>--- Kamal Prasad <kamalpr@yahoo.com> wrote:
>  
>
>>Hello,
>> I saw the FAQ for remote debugging with kgdb.
>>The problem at my end is like this:-
>>---------------------------------------------
>>1. the netbsd is running on a controller that boots
>>off flash, and gets the ip through dhcp and then
>>does
>>the ftp/tftp to get the kernel image. the processor
>>is
>>a powerpc chip.
>>2. the kernel is built on a G4 running netbsd. the
>>kernel image is different on the G4 as compared to
>>that ont the controller because the former is a
>>full-fledged workstation and the latter is an
>>embedded
>>device.
>>3. the connection between the 2 is an ethernet port.
>>(its the same one that is used to get the ip address
>>from dhcp server running on the G4). note that this
>>ethernet port is directly connected to the G4 and
>>there are some more ethernet ports on the device.
>>-------------------------------------------
>>I need advice in determining if:-
>>(a) remote debugging is possible in this scenario
>>and
>>(b) how do I go about doing it.
>>thanks
>>-kamal
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>LAUNCH - Your Yahoo! Music Experience
>>http://launch.yahoo.com
>>    
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>LAUNCH - Your Yahoo! Music Experience
>http://launch.yahoo.com
>  
>