On 08/04/11 11:08, Mark Cave-Ayland wrote:
Talking of kadb, if I try and invoke it at the moment, I get this:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 5 2011 08:40 Type 'help' for detailed information
0 > boot cdrom:d kadb -kdv Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 119204+222573+28987 Bytes kadb: kadb: kernel/unix Size: 259040+54154+47486 Bytes /platform/SUNW,SPARCstation-5/kernel/unix loaded - 0x95000 bytes used kadb[0]: :c Begin traceback... sp = 12f9e0 Called from fbd01700, fp=12fa50, args=9 f0086444 f0086438 0 f0258f2c 0 Called from f00859e0, fp=12fad8, args=f0258fc0 44 12fbf8 0 f0258f2c f0258f70 Called from f0082518, fp=12fb38, args=f0258fc0 0 44 0 0 fbd039e4 Called from f0081c48, fp=12fb98, args=12fbf8 f0258de8 12fbf8 fbd58800 f0040000 f0240000 Called from f00819c0, fp=12fff8, args=130168 f0258f70 f0258ed8 f0258ed0 2 130168 Called from f007ff0c, fp=130058, args=f0258c00 f0258c00 fbd54860 130168 f0258d08 f End traceback... fault and calling cmd: trap 9 sp 12f9e0 pc f0086444 npc f0086438 stopped at: kadb[0]:
I think trap #9 is "data access error" but it only occurs when booting the kernel with kadb. Looks like this will need a bit more investigation.
As an aside, I managed to spend a few hours over the weekend trying to work out why kadb doesn't want to start the kernel. Fortunately enough, kadb is non-stripped which always makes debugging these kinds of things easier :)
It was fairly easy to isolate the call to obp_dumb_memalloc() for the region of memory in question, so I started tracing through the parent function, readfile, in kadb. Stepping through the code here showed a very interesting section whereby additional memory is added to the amount to be allocated for the kernel (and possibly modules) depending upon whether the variable use_align is set.
A quick watchpoint later showed that this is in fact controlled by the presence of a zero-length attribute called "aligned-allocator" under /openprom. Since this property appears in the sample prtconf output, then it suggests that this code path is triggered by OBP. Rather bizarrely, if I add this property to OpenBIOS then kadb crashes further down the line - BUT if I simply use gdb to make kadb think the property is present by changing the relevant register within gdb then I am able to load kadb?!
I think I'm probably about 90% there when it comes to getting kadb up and running under OpenBIOS, but I still need to figure out why just adding the missing property isn't enough here.
ATB,
Mark.