Re: [Crash-utility] Usage Advice
by Dave Anderson
----- "CAI Qian" <caiqian(a)redhat.com> wrote:
> Hallo!
>
> There are a few things that bother me the most regards the crash utility
> usages.
>
> 1) Pointer remains at the beginning after the UP array key. When
> entering the UP array key, it repeats the last command like,
>
> crash> struct struct_tss
>
> However, then the current position remains at the beginning. It is
> usually unlike in bash that the current position remains at the end,
> so it is easier to update the command like,
>
> crash> struct struct_tss ffffffff819f1764
I believe that's a function of the readline library, and there may be
a setting/binding that could be used to make that happen. Since the
beginning, readline has been set up by crash like this:
if (STREQ(pc->editing_mode, "vi")) {
rl_editing_mode = vi_mode;
rl_bind_key(CTRL('N'), rl_get_next_history);
rl_bind_key(CTRL('P'), rl_get_previous_history);
rl_bind_key_in_map(CTRL('P'), rl_get_previous_history,
vi_insertion_keymap);
rl_bind_key_in_map(CTRL('N'), rl_get_next_history,
vi_insertion_keymap);
rl_generic_bind(ISFUNC, "[A", (char *)rl_get_previous_history,
vi_movement_keymap);
rl_generic_bind(ISFUNC, "[B", (char *)rl_get_next_history,
vi_movement_keymap);
}
if (STREQ(pc->editing_mode, "emacs")) {
rl_editing_mode = emacs_mode;
}
I don't recall where those bindings came from -- I copied them from some
other program. I'm guessing that there's a binding that would put the cursor
at the end of the recalled string, but I don't know what it is off-hand.
If anybody knows what the binding sequence is, please post it here...
On the other hand, when updating a command string, I guess it depends
whether the location you want to change is at the beginning or the end
of the string would be a cause to be bothered by it?
>
> 2) Pressing PgUp/PgDn when input leads nothing can be input. This
> happens like,
>
> crash> log
>
> In order to see the full log output, I may press PgDn several
> times. However, if continue pressing the key after the output has
> already finished like,
In the case of the "log" command, the PageUp and PageDown keys are being
captured by the scrolling routine, which is /usr/bin/less by default.
>
> crash>
>
> there seems no way to input anything unless pressing Enter several
> times until reach the next prompt.
Right -- PageUp and PageDown don't make sense once you are back to
the "crash> " command prompt.
> 3) Ctrl-C is not working to cancel the current input. GDB has the same
> problem. It needs to press Ctrl-C several times to get it to a new
> prompt.
That's also done on purpose -- in certain circumstances it requires
that Ctrl-C be hit 3 times (MAX_SIGINTS_ACCEPTED). There was a good
reason that was put in place, but I'm afraid I don't recall why...
Dave
15 years, 1 month
Usage Advice
by CAI Qian
Hallo!
There are a few things that bother me the most regards the crash utility
usages.
1) Pointer remains at the beginning after the UP array key. When
entering the UP array key, it repeats the last command like,
crash> struct struct_tss
However, then the current position remains at the beginning. It is
usually unlike in bash that the current position remains at the end,
so it is easier to update the command like,
crash> struct struct_tss ffffffff819f1764
2) Pressing PgUp/PgDn when input leads nothing can be input. This happens like,
crash> log
In order to see the full log output, I may press PgDn several
times. However, if continue pressing the key after the output has
already finished like,
crash>
there seems no way to input anything unless pressing Enter several
times until reach the next prompt.
3) Ctrl-C is not working to cancel the current input. GDB has the same
problem. It needs to press Ctrl-C several times to get it to a new
prompt.
Thanks!
CAI Qian
15 years, 1 month
Re: [Crash-utility] irq: x86_64_dump_irq: irq_desc[] does not exist?
by Dave Anderson
----- "CAI Qian" <caiqian(a)redhat.com> wrote:
> Hallo!
>
> When analyzing VMCores came from 2.6.31 kernel, irq sub-command is not
> working.
>
> crash> irq
> irq: x86_64_dump_irq: irq_desc[] does not exist?
>
> Is that because of the irq data structures changed in kernel from static
> to dynamic allocated?
It looks like that, starting in 2.6.29, the irq_desc[] array can be replaced by
an irq_desc_ptrs[] array if the kernel is configured with CONFIG_SPARSE_IRQ.
I'm fixing the "kmem -z" as we speak -- I'll look into this afterwards.
Shifting sands...
Dave
15 years, 1 month
Re: [Crash-utility] crashdc: problem when running crash in kexec environment for SLES11
by Dave Anderson
----- "Louis Bouchard" <louis.bouchard(a)hp.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello everyone,
>
> Bernhard Walle a écrit :
> >
> > I don't think so. I just tried to reproduce the problem here with
> > openSUSE 11.1 (I have no SLES). In my case, I also got the "killed", but
> > it was too less memory. I changed the reservation to be 256 MiB for the
> > crashkernel, and now it works.
> >
>
> For info, I'm doing the dev on an i686 VMware guest for now.
>
> Bernhard found the SLES11 problem : memory was too tight to allow
> crash/gdb to run.
>
> I increased the mem reservation with the following :
>
> crashkernel=256M-:128M@16M
>
> and got crash to run my commands. I have a smaller problem now. I'm
> issueing the following commands to crash :
>
> > !echo "### Crash Context Information" >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> > !echo "crash> sys" >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> > sys >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> > !echo -n `date`;echo "### Preserved Kernel Ring Buffer"
> > !echo "### Preserved Kernel Ring Buffer" >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> > !echo "crash> log" >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> > log >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
>
> I did include /bin/echo in the KDUMP_REQUIRED_PROGRAMS variable, but
> crash still returns :
>
> > crash: cannot open pipe: echo "### Crash Context Information" >> /root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
> > crash: cannot open pipe: echo "crash> sys" >> /root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
> > crash: cannot open pipe: echo -n `date`;echo "### Preserved Kernel Ring Buffer"
> > crash: cannot open pipe: echo "### Preserved Kernel Ring Buffer" >> /root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
>
> So it looks like the ! to shell out the "echo "... command doesn't work,
> most probably because of the limited commands in the kexec environment.
It's probably worth figuring out why the popen() command failed?
The function printing the error message is here in cmdline.c:
int
shell_command(char *cmd)
{
FILE *pipe;
char buf[BUFSIZE];
if ((pipe = popen(cmd, "r")) == NULL) {
error(INFO, "cannot open pipe: %s\n", cmd);
pc->redirect &= ~REDIRECT_SHELL_COMMAND;
pc->redirect |= REDIRECT_FAILURE;
return REDIRECT_FAILURE;
}
I didn't bother to gather/display the errno information in the function above
since it's irrelevant if there's a memory allocation issue. From the popen()
man page:
RETURN VALUE
The popen() function returns NULL if the fork(2) or pipe(2) calls fail,
or if it cannot allocate memory.
The pclose() function returns -1 if wait4() returns an error, or some
other error is detected.
ERRORS
The popen() function does not set errno if memory allocation fails. If
the underlying fork() or pipe() fails, errno is set appropriately. If
the type argument is invalid, and this condition is detected, errno is
set to EINVAL.
Also, does "echo" alone maybe use the shell's built-in echo instead of /bin/echo?
Did you force it by using "/bin/echo" in the script's comand lines instead of
just "echo"?
BTW, you can also try removing the ! from in front of the "echo" commands in
the input file, because the crash utility will just pass the remaining string
to system() instead of popen(). But I would guess that system() would fail
for the same reason as popen().
Dave
15 years, 1 month
crashdc: problem when running crash in kexec environment for SLES11
by Louis Bouchard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
As I indicated previously, I'm having a problem with running crash from
within the kexec environment of SLES11.
Actually, crash itself runs fine, but its gdb portion seems to be having
problems. Here is a capture of what happens :
> Running /usr/bin/run-crashdc-sles11.sh
> crashexe : /usr/bin/crash
> crashoutput : /root/var/crash/2009-09-29-17:45/crash-data-200909291746.txt
> namelist : /root/boot/vmlinux-2.6.27.23-0.1-default
> vmcorefile : /root/var/crash/2009-09-29-17:45/vmcore
> debuginfofile : /root/usr/lib/debug/boot/vmlinux-2.6.27.23-0.1-default.debug
>
This portion above is debug info from crashdc.
> crash 4.0-7.6
> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for details.
>
> NOTE: stdin: not a tty
>
> cannot determine relocation value: not a live system
> gdb /root/usr/lib/debug/boot/vmlinux-2.6.27.23-0.1-default.debug
>
>
> dlopen failed on 'libthread_db.so.1' - libthread_db.so.1: cannot open shared object file: No such file or directory
> GDB will not be able to debug pthreads.
>
> GNU gdb 6.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu".../usr/bin/crashdc: line 160: 682 Killed $crashexe -d $crashdebug $namelist $debuginfofile $vmcorefile < $crashcmd
> File /root/var/crash/2009-09-29-17:45/crash-data-200909291746.txt has been generated
> generated a crash-data file to /root/var/crash/2009-09-29-17:45
> ..done
> Restarting system.
My feeling is that the "dlopen failed on 'libthread_db.so.1'" might be
causing this.
Bernhard Walle might have an idea. Here is what I have in
/etc/sysconfig/kdump :
> KDUMP_REQUIRED_PROGRAMS="/bin/basename /usr/bin/crash /usr/bin/crashdc /usr/bin/run-crashdc-sles11.sh /etc/rc.status /bin/gzip /bin/logger /usr/bin/gdb /lib/libpthread.so.0 /lib/libthread_db.so.1"
This line allow for inclusion of the listed file into the initramfs file
that gets loaded at kexec time. Maybe crash/gdb is looking for it where
it's not, but right now I'm a bit stucked.
As a side not to Bernhard, is there a way to have kdump stop its
execution while in the kexec kernel ? Just like when it hits an error
and drop to a shell ?
TIA,
- --
Louis Bouchard, Linux Support Engineer
Team lead, EMEA Linux Competency Center,
Linux Ambassador, HP
HP Services 1 Ave du Canada
HP France Z.A. de Courtaboeuf
louis.bouchard(a)hp.com 91 947 Les Ulis
http://www.hp.com/go/linux France
http://www.hp.com/fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrDc2gACgkQDvqokHrhnCyU6QCdHSlzw6q2u0qoifczMp3AGMob
woAAoMbhGJaDgiQ6GhqB+PNTCvsyELB6
=l3xC
-----END PGP SIGNATURE-----
15 years, 1 month
