crash version 4.0-4.4 is available
by Dave Anderson
- Fix for kernels in which the irq_desc_t typedef is not included in
the vmlinux debuginfo data, by using the 2.6-era struct irq_desc.
Without the patch, the "irq" command fails with the error message,
"irq: cannot determine size of irq_desc_t". (hugh(a)mimosa.com)
- Implemented new "irq -u" option that displays only in-use IRQs, now
that there can be several thousand entries in the irq_desc[] array.
(anderson(a)redhat.com)
- Prevent occasional 99% cpu usage waiting for the built-in less
command to complete. (anderson(a)redhat.com)
- Implemented support for the use of "kerntypes" debuginfo files that
are created by the LKCD "dwarfextract" utility, as an alternative to
the use of the vmlinux file. This requires the use of the matching
System.map file, as in this example:
# crash kerntypes System.map [vmcore]
This capability was written by Cliff Wickman of SGI, and he has
generously offered to maintain its functionality. (cpw(a)sgi.com)
- Fixes, code improvement and cleanup for "crash -h [command]".
(hugh(a)mimosa.com)
- The output of command data exceeding a terminal page-size has been
traditionally fed by default to "/usr/bin/less -E -X" with a prompt;
if the /usr/bin/less command was not available on the host system,
output would be fed to "/bin/more" instead. Scrolling can be turned
off with "set scroll off" or the built-in alias "sf", and back on
with "set scroll on" or the built-in alias "sn". This release
allows the user to specify an alternative scrolling program by
creating a CRASHPAGER environment variable, which be used by default
if it exists. Also, the "set scroll [arg]" internal variable setting
command, which until now accepted "on" and "off" as arguments, now
accepts "less", "more" and "CRASHPAGER" as alternative arguments,
both during runtime, or in .crashrc files. Also, new crash command
line arguments have also been added to override the default and/or
.crashrc settings: --more, --less, and --CRASHPAGER. Lastly, the
output of the "crash -h [command]" will also use the relevant scroll
command selection. (anderson(a)redhat.com)
- Updated crash(8) man page. (hugh(a)mimosa.com, anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
17 years, 5 months
Re: [Crash-utility] Re: crash-4.0-4.3 and linux-2.6.22.1-20.fc7
by Dave Anderson
Andi Kleen wrote:
> > > Using the latest F7 kernel and crash I'm getting the following
> > > error:
> > > WARNING: cannot read linux_banner string
> > > crash: /usr/lib/debug/lib/modules/2.6.22.1-20.fc7/vmlinux and
> > > /dev/crash do not match!
> > > I've tried both crash and crash -f with no luck.
> > > I've search the mailing list and was unable to find any
> > > thing talked about this problem... So I'm thinking this
> > > may not be a known problem... If it is, please let me know
> > > otherwise does anybody have idea what the problem could be?
> > > tia,
> > > steved.
> > >
> >
> > This elephant still remains in the room...
> >
> > I can reproduce it with a 2.6.21-1.3194.fc7 kernel, which
> > I believe has 2.6.22 stuff backported to it.
>
> Don't know about the Fedora kernel, but at least in mainline
> __pa/__va still work as before for i386/x86-64. It's a single
> add/sub on i386 and on x86-64 similar, but with different ranges
> for kernel text vs the other kernel memory.
>
> The load address is variable now, but still has a default
> set at compile time in CONFIG.
>
> What might have changed when you enable the relocatable kernel
> is that the ELF addresses in the vmlinux are different. But
> at runtime there is no difference.
>
> -Andi
Vivek Goyal wrote:
> Hi Dave,
>
> Sorry, could not reply on Friday.
>
> This looks weared. Only one possible theory comes to mind. In FC7 kernels
> following should be config variables.
>
> CONFIG_PHYSICAL_START=16MB
> CONFIG_PHYSICAL_ALIGN=4MB.
>
> That means kernel has been compiled for 16MB physical address. That's
> why linux_banner symbol address is in higher range. But at run time it
> has been loaded by grub at 1MB location. Because alignment required is
> 4MB kernel will move itself to physical address 4MB and that would
> probably put linux banner somewhere at 6MB location.
>
> So these kind of problems will occur with first kernel is not run at
> the address it has been compiled for. Can you please confirm this by
> looking at FC7 config file.
>
> An easy way to fix this would be to change CONFIG_PHYSICAL_START=1MB.
>
> Thanks
> Vivek
Thanks Vivek, that restores sanity.
Upon rebuilding my FC7 kernel with CONFIG_PHYSICAL_START changed
from 16MB to 1MB, with CONFIG_PHYSICAL_ALIGN left at 4MB, i.e.:
CONFIG_PHYSICAL_START=0x100000
CONFIG_PHYSICAL_ALIGN=0x400000
The kernel gets compiled for a 4MB physical address:
$ nm -Bn vmlinux | grep "^c04"
c0400000 T _text
c0400000 T startup_32
c0401000 T startup_32_smp
c0401080 t checkCPUtype
c0401101 t is486
c0401108 t is386
c0401175 t check_x87
c04011a0 T setup_pda
c04011c2 t setup_idt
c04011df t rp_sidt
c0401262 t early_divide_err
c0401268 t early_illegal_opcode
c0401271 t early_protection_fault
c0401278 t early_page_fault
c040127f t early_fault
c04012a7 t hlt_loop
c04012ac t ignore_int
c04012f0 T _stext
c04012f0 t run_init_process
c04012f0 T stext
...
and so the same virtual-to-physical translation can be used for
both non-kernel unity-mapped kernel virtual addresses as well as
for kernel symbol addresses.
Thanks again,
Dave
17 years, 5 months
Usage of LKCD kerntypes files
by Dave Anderson
Cliff,
I destroyed your response before realizing that it was a
private message to Bernhard and me, and didn't show up on
this mailing list.
Can you move all discussions w/respect to kerntypes file
usage to this list?
Thanks,
Dave
17 years, 5 months
Re: [Crash-utility] crash-4.0-4.3 and linux-2.6.22.1-20.fc7
by Dave Anderson
> Using the latest F7 kernel and crash I'm getting the following
> error:
>
> WARNING: cannot read linux_banner string
>
> crash: /usr/lib/debug/lib/modules/2.6.22.1-20.fc7/vmlinux and /dev/crash do not match!
>
> I've tried both crash and crash -f with no luck.
>
> I've search the mailing list and was unable to find any
> thing talked about this problem... So I'm thinking this
> may not be a known problem... If it is, please let me know
> otherwise does anybody have idea what the problem could be?
>
> tia,
>
> steved.
>
This elephant still remains in the room...
I can reproduce it with a 2.6.21-1.3194.fc7 kernel, which
I believe has 2.6.22 stuff backported to it.
What's happening is that the x86 kernel's base virtual address
space has changed, such that instead of starting at the traditional
addresses of 0xc0100000 or 0xc0400000, it now begins at 0xc1000000.
However, the physical address of unity-mapped kernel virtual
addresses is no longer calculated with a trivial subtracting
of the kernel virtual base address. So for example, the
"linux_banner" address causing the "do not match" session
failure is at 0xc1206000, which I've determined is actually
located at physical address 0x606000. So the traditional
x86 VTOP() operation no longer works, the wrong physical
memory is read, and the crash session is terminated.
But when I kludge up a temporary virtual-to-physical translator
that does translate 0xc1206000 into 0x606000, things "work" OK
for all kernel symbol-based addresses, but it does not work for
non-kernel-symbol unity-mapped addresses, such as those returned
by kmalloc().
Presumably this has something to do with changes for kexec/kdump
and/or relocatable x86 kernels (?), but I'm not clear on that yet,
nor how VTOP operations should be done properly.
So until further notice, crash no longer works on 2.6.22-era
x86 kernels.
Dave
17 years, 5 months
Can crash analyze dumps generated on ARM ?
by Vivek P
Hi , Can crash analyze dumps generated on ARM ? If not , is there any development going on to port crash to analyzeARM crash dumps (generated by netdump/diskdump/kdump) ?Thanks and regardsVivek P.
17 years, 5 months
crash-4.0-4.3 and linux-2.6.22.1-20.fc7
by Steve Dickson
Using the latest F7 kernel and crash I'm getting the following
error:
WARNING: cannot read linux_banner string
crash: /usr/lib/debug/lib/modules/2.6.22.1-20.fc7/vmlinux and /dev/crash
do not match!
I've tried both crash and crash -f with no luck.
I've search the mailing list and was unable to find any
thing talked about this problem... So I'm thinking this
may not be a known problem... If it is, please let me know
otherwise does anybody have idea what the problem could be?
tia,
steved.
17 years, 5 months
crash CPU bound waiting for user response
by D. Hugh Redelmeier
I am running crash in a shell window of JOVE. JOVE is an EMACS-subset
editor.
crash isn't really happy. Here is an example:
crash> task
WARNING: terminal is not fully functional
- (press RETURN)
==> It does not say in what way the terminal is not fully functional. That seems like a bug.
==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
Here is what "ps laxgwf" says about the crash process and its child.
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 0 4426 4406 25 0 416812 332764 - R+ pts/5 80:36 | | \_ crash --readnow /usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux /var/crash/2007-07-02-13:42/vmcore
0 0 4989 4426 18 0 73976 740 - S+ pts/5 0:00 | | \_ /usr/bin/less -E -X -Ps -- MORE -- forward\: <SPACE>, <ENTER> or j backward\: b or k quit\: q
strace of the crash process shows an infinite sequence of:
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
This is very wasteful.
There are other ways to get into this state. Other places less is
being used and is waiting. Probably wherever less is used even if it
isn't waiting.
I just tested: this problem exists when using a normal xterm.
17 years, 5 months
Re: [Crash-utility] Scripting infrastructure in crash
by Luc Chouinard
I'd would like very much to get the sial interpreter into the crash tool.
It's a matter of mating the apiops (defined in sial_api.h) to the gdb framework.
Things are a bit hectic right now but I should be able to look at in the next few weeks.
It's definitively something I'll look at in the short term.
Now, if anyone wants to start looking, please do. keep me in the loop.
Luc
----- Original Message ----
From: Dave Anderson <anderson(a)redhat.com>
To: sachinp(a)in.ibm.com; "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com>
Sent: Wednesday, May 2, 2007 9:44:20 AM
Subject: Re: [Crash-utility] Scripting infrastructure in crash
"Sachin P. Sant" wrote:
> Dave, i came across one of the Crash TODO list items about having
> a scripting infrastructure in crash.
>
> I was trying to evaluate the Alicia utility [mentioned in todo list].
> Here are some of my observations about Alicia.
>
> 1] It is a wrapper on top of crash.
> 2] One can write perl based scripts to extract infromation from dumps.
> 3] It has a nice report generation functionality which presents
> the data in text as well as html format.
> 4] Provides functions which could be used to read data from crash
> dumps.
> 5] It is easy to use and effective too.
>
> Attached here is a sample script which i tried using Alicia to
> display block and character devices. [ I know dev command already
> does this stuff .. but for the sake of trying out the Alicia i chose
> to write such a script ].
>
> Also encountered few problems while trying out Alicia.
> 1] On PPC64 arch came across data type overflow problem while
> executing the attached script.
> 2] On s390/s390x architecture class function provided by Alicia
> seems broken.
> 3] Alicia is a wrapper on top of crash.
>
> Other dump solutions [ lkcd ] has sial scripting which is c like
> and very effective. Not sure how difficult it will be to implement
> something like sial in crash.
>
> Do you have any plans of having scripting infrastructure in
> crash ? If yes your thoughts on Alicia / sial / < any other stuff >
>
I personally do not.
But, a few days ago, Luc Chouinard started looking into what it
would take to support sial scripting.
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
17 years, 5 months
crash vs irqs
by D. Hugh Redelmeier
I'm having a problem with the Fedora 7 kernel 2.6.21-1.3228.fc7 for
x86_64. So I am trying to use crash-4.0-4.2 to analyze the problem.
(The version of crash in F7 won't work with this kernel.)
Since the kernel bug appears to be in irq handline, learning more
about IRQ state is important.
When I use the irq command I get this error message:
irq: cannot determine size of irq_desc_t
Is this a bug or a known limitation of crash?
17 years, 5 months
