[Crash-utility] crash 4.0-3.14 and SLES 10

[Daniel Li]

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 at 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.