Re: [Crash-utility] crash 4.0-3.14 and SLES 10
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.