2:22 p.m.
I am trying to look at a live SLES 10 system using crash. Crash fails to
start successfully. It returns:
crash: /boot/vmlinux: no debugging data available
The vmlinux file in question is not stripped.
Has anyone else been able to get this to work? If so what did you do?
Jeff
2:34 p.m.
reagen_jeff(a)emc.com wrote:
I am trying to look at a live SLES 10 system using crash. Crash fails
to
start successfully. It returns:
crash: /boot/vmlinux: no debugging data available
The vmlinux file in question is not stripped.
Has anyone else been able to get this to work? If so what did you do?
Jeff
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
From what I saw, 'not stripped' doesn't mean it has the .debug_info
section. After I compiled a kernel with '-g' flag and feed that to
crash, that error message went away. You can use 'readelf' to check the
existence of .debug_info section. So far the non-SMP SLES kernels seem
to work fine with crash once you build the kernel with '-g'. However,
there seems to be some problems with crash and SMP SLES kernels... I'm
having a discussion with Dave Anderson in another thread on that which
you can check out if you are interested.
Later,
Daniel
2:42 p.m.
* Daniel Li <dli(a)virtualiron.com> [2007-09-13 21:34]:
From what I saw, 'not stripped' doesn't mean it has the
.debug_info
section. After I compiled a kernel with '-g' flag and feed that to crash,
that error message went away.
That's necessary on SLES9. On SLES10, we have -debuginfo packages.
Thanks,
Bernhard
3:05 p.m.
Bernhard Walle wrote:
* Daniel Li <dli(a)virtualiron.com> [2007-09-13 21:34]:
> From what I saw, 'not stripped' doesn't mean it has the .debug_info
> section. After I compiled a kernel with '-g' flag and feed that to crash,
> that error message went away.
>
That's necessary on SLES9. On SLES10, we have -debuginfo packages.
Thanks,
Bernhard
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
I tried it yesterday on my SLES 10 box. First of all, I couldn't find
the 'kernel-smp-debug' or any 'debuginfo' package, the only one I could
find was called 'kernel-debug', which claimed to have the debug kernel.
So I installed that package and found the debug linux image it installed
under /boot. However, when I attempted to feed that kernel to crash, it
freezed my host. I tried it both with the smp kernel and default kernel,
and both times the host freezed up. Right now I'm planning to patch up
the system (current version is 2.6.16.46-0.12) to the latest updates and
hope this might take care of the problem.
3:22 p.m.
* Daniel Li <dli(a)virtualiron.com> [2007-09-13 22:05]:
Bernhard Walle wrote:
> * Daniel Li <dli(a)virtualiron.com> [2007-09-13 21:34]:
>
>> From what I saw, 'not stripped' doesn't mean it has the .debug_info
>> section. After I compiled a kernel with '-g' flag and feed that to crash,
>> that error message went away.
>>
>
> That's necessary on SLES9. On SLES10, we have -debuginfo packages.
I tried it yesterday on my SLES 10 box. First of all, I couldn't find the
'kernel-smp-debug' or any 'debuginfo' package, the only one I could find
was called 'kernel-debug', which claimed to have the debug kernel. So I
installed that package and found the debug linux image it installed under
/boot.
For the debug kernel, you have to install kernel-debug-debuginfo to
have debugging information available. For the location, the debuginfo
packages are not on CD/DVD but only available as online repository.
If you have problems finding the location, please contact support
(yes, that's nothing for this mailinglist here, but I hope Dave
doesn't remove me from the list now ;-)).
You can always use the KOTD [1], BTW.
However, when I attempted to feed that kernel to crash, it freezed
my host. I tried it both with the smp kernel and default kernel, and both
times the host freezed up. Right now I'm planning to patch up the system
(current version is 2.6.16.46-0.12) to the latest updates and hope this
might take care of the problem.
This looks like a bug.
Thanks,
Bernhard
[1] ftp://ftp.suse.com/pub/projects/kernel/kotd/SLES10_SP1_BRANCH
3:42 p.m.
Bernhard Walle wrote:
For the debug kernel, you have to install kernel-debug-debuginfo to
have debugging information available. For the location, the debuginfo
packages are not on CD/DVD but only available as online repository.
If you have problems finding the location, please contact support
(yes, that's nothing for this mailinglist here, but I hope Dave
doesn't remove me from the list now ;-)).
Hey, no problem -- this list is meant to be distribution-independent...
You can always use the KOTD [1], BTW.
>However, when I attempted to feed that kernel to crash, it freezed
>my host. I tried it both with the smp kernel and default kernel, and both
>times the host freezed up. Right now I'm planning to patch up the system
>(current version is 2.6.16.46-0.12) to the latest updates and hope this
>might take care of the problem.
This looks like a bug.
Really -- that's bizarre. There's no good reason why running
crash on a live system should freeze anything! It's just a
user program -- although on SLES I'm guessing that it reads
/dev/mem right? That's the only thing I can think of, i.e.,
that by using the wrong vmlinux it's somehow accessing the
wrong location in physical memory, which is mapped to a device
that reacts to being read, or non-existent memory that causes
the kernel to go off into the weeds? I have no idea...
Of course, this is one of those Virtual Iron beasts, right?
Dave
4:16 p.m.
Dave Anderson wrote:
Bernhard Walle wrote:
> For the debug kernel, you have to install kernel-debug-debuginfo to
> have debugging information available. For the location, the debuginfo
> packages are not on CD/DVD but only available as online repository.
>
> If you have problems finding the location, please contact support
> (yes, that's nothing for this mailinglist here, but I hope Dave
> doesn't remove me from the list now ;-)).
Hey, no problem -- this list is meant to be distribution-independent...
>
> You can always use the KOTD [1], BTW.
>
>
>> However, when I attempted to feed that kernel to crash, it freezed
>> my host. I tried it both with the smp kernel and default kernel, and
>> both times the host freezed up. Right now I'm planning to patch up
>> the system (current version is 2.6.16.46-0.12) to the latest updates
>> and hope this might take care of the problem.
>
>
> This looks like a bug.
Really -- that's bizarre. There's no good reason why running
crash on a live system should freeze anything! It's just a
user program -- although on SLES I'm guessing that it reads
/dev/mem right? That's the only thing I can think of, i.e.,
that by using the wrong vmlinux it's somehow accessing the
wrong location in physical memory, which is mapped to a device
that reacts to being read, or non-existent memory that causes
the kernel to go off into the weeds? I have no idea...
Of course, this is one of those Virtual Iron beasts, right?
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
What happened was after I discovered the freeze first on a virtual
machine, then I tried crash on my native Redhat FC5 linux box in my
office . The two freezes refered to in my last email actually both
happened on native Redhat Linux, although the targets were dump files
created for the same SLES10 guest (along with corresponding kernel files
I copied over from the SLES10 system, of course). During one time I
could actually squeeze in a 'top' command before the machine totally
froze up, and for 10 seconds or so it showed CPU/memory usage comparable
to an idle machine ('crash' wasn't even shown in the list of top
threads). Now, all that bizzareness aside, how is this kernel-debug
package different than the debuginfo package and what is supposed to be
the purpose of it, if I may ask?
Since my office machine isn't setup for creating dumps, I couldn't
capture dumps for those two times. For the SLES10 guest case, I guess I
could have produced a dump if I wanted, although that dump will only be
useful after we figure out how to make SLES dumps work with crash, or I
guess we could be using 'lcrash' to figure out what was going on in this
particular case, if lcrash and LKCD is still around on SLES10.
3:30 a.m.
* Daniel Li <dli(a)virtualiron.com> [2007-09-13 23:16]:
Since my office machine isn't setup for creating dumps, I couldn't capture
dumps for those two times. For the SLES10 guest case, I guess I could have
produced a dump if I wanted, although that dump will only be useful after
we figure out how to make SLES dumps work with crash, or I guess we could
be using 'lcrash' to figure out what was going on in this particular case,
if lcrash and LKCD is still around on SLES10.
The kernel part of LKCD is present on SLES10 only for IA64, not for
the other architectures.
Thanks,
Bernhard
3:29 a.m.
* Dave Anderson <anderson(a)redhat.com> [2007-09-13 22:42]:
Really -- that's bizarre. There's no good reason why running
crash on a live system should freeze anything! It's just a
user program -- although on SLES I'm guessing that it reads
/dev/mem right?
Yes.
Thanks,
Bernhard
2:40 p.m.
reagen_jeff(a)emc.com wrote:
I am trying to look at a live SLES 10 system using crash. Crash fails
to
start successfully. It returns:
crash: /boot/vmlinux: no debugging data available
The vmlinux file in question is not stripped.
Has anyone else been able to get this to work? If so what did you do?
Jeff
Just for sanity's sake, what happens when you:
$ gdb /boot/vmlinux
...
(gdb) ptype struct task_struct
Dave
2:42 p.m.
Same error message. I'm guessing that I am missing the equivalent to
Redhat's debuginfo files...
Jeff
-----Original Message-----
From: Dave Anderson [mailto:anderson@redhat.com]
Sent: Thursday, September 13, 2007 3:41 PM
To: Discussion list for crash utility usage, maintenance and
development; reagen, jeff
Subject: Re: [Crash-utility] crash 4.0-3.14 and SLES 10
reagen_jeff(a)emc.com wrote:
I am trying to look at a live SLES 10 system using crash. Crash fails
to
start successfully. It returns:
crash: /boot/vmlinux: no debugging data available
The vmlinux file in question is not stripped.
Has anyone else been able to get this to work? If so what did you do?
Jeff
Just for sanity's sake, what happens when you:
$ gdb /boot/vmlinux
...
(gdb) ptype struct task_struct
Dave
6135
days inactive
6136
days old
devel@lists.crash-utility.osci.io
11 comments
4 participants
participants (4)
-
Bernhard Walle -
Daniel Li -
Dave Anderson -
reagen_jeff＠emc.com