"Kurtis D. Rader" wrote:
On Mon, 2006-05-08 10:58:39, Dave Anderson wrote:
> I know I'm setting myself up for flames here, but why not use NFS? Prior
> to writing this, I was just looking at an x86_64 vmcore file stored on,
> and NFS-mounted from, an x86 netdump server, and have done that many
> times.
That strategy is helpful but for my team not as useful as you might
think. We only have one production server in our lab. It is an x86 system
with eight CPUs and 8 GiB of memory. Everything else in our lab is used
for problem reproduction. So you never know exactly what state they're
in. And most of the lab systems have only 1 GiB of memory which makes
analyzing large dumps an exercise in thrashing the disks. Our little s390
system doesn't even have that much memory assigned to each LPAR. Also,
we haven't been able to convince management to spend the money to upgrade
our lab infrastructure. So we're limited to 100 Mbps ethernet between
most of the systems.
Heck, my desktop (dual core AMD 64 with 4 GiB of memory and two Western
Digital Raptor SATA disks) is more powerful than almost all of my lab
systems. As a consequence that is where I do all of my x86/x86_64 analysis.
Dave, have you heard from rainer.bawidamann(a)de.ibm.com? He's leading an
effort to create a cross-arch capable version of crash. Last I heard the
current implementation only supports host=x86/target=ppc32.
No -- Corey Minyard from Monte Vista did a ppc32 implementation.
It was a ~15K lines-of-code patch that was way too intrusive to
ever consider for a RHEL version of crash. Plus it made even the
simplest crash functions a pain in the ass, because for every single
memory access, it had to deal with 32-bit vs. 64-bit as well as endian
issues. The patch was *really* ugly, but it worked for them...
Dave