> In my experience, there are very few kernel versions and hardware for > which kdump works. I think that's mostly because kexec from arbitary context is a somewhat unstable concept. It requires all drivers to be able to reinit the hardware from an arbitary state, and that's just hard (it's kind of "make suspend/resume work everywhere" and then a little harder and we know how long that took) We also don't really have any tools to help making this easier to implement for driver developers. Like e.g. some self test that restarted drivers regularly to check this. But you often don't need kdump for crash dumps. In many cases the system is still alive after an oops or other problem and you can just do a live dump or even live crash session to look at data structures. I used to do this with gdb regularly, but now usually use crash because it has better tools. > they aren't enterprise users. Heck, until July of last year, > Systemtap wouldn't even ***compile*** out of the box on a > non-enterprise distribution like Ubuntu or Debian. At least on opensuse releases it tends to work for me. The biggest PITA used to be the elfutils dependency which seemed to come out of a all-world-is-redhat mindset at the developers, but that can be worked around now. Sometimes on has to patch it up when updating kernels because some interface by the runtime has changed again, but that shouldn't be a demanding task for kernel hackers really. At least I didn't find it particularly difficult. I wish they would merge the runtime into mainline though. -Andi -- ak@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
