* Mike Snitzer <snitzer@xxxxxxxxx> wrote: > On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar <mingo@xxxxxxx> wrote: > > > > * Mike Snitzer <snitzer@xxxxxxxxx> wrote: > > > >> Yes, especially from someone who lacks the ability to properly > >> configure kdump. I'm fairly surprised others are giving you a free > >> pass when you keep asserting how broken kdump is with such hollow > >> criticism. I rely heavily on kdump and it works quite well (kvm > >> integration was lacking but has improved). > > > > hm, you say you rely heavily on kdump ... for what exactly, and how > > does it help the upstream Linux kernel? > > > > I see a single fix from you in the whole repository: > > > > ffc41cf: nbd: prevent sock_xmit from attempting to use a NULL socket > > > > ... and that single fix is a NULL pointer dereference that ought to have > > been quite debuggable from a plain oops alone. > > I've reported various bugs and helped with prototypes for fixes (e.g. > a0da84f3). But by all means belittle me... must be fun. I really did not want to belittle you - but in hindsight it really reads that way ... sorry about that and how insensitive it was from me! :( I just wanted to point out that if kdump is useful it must be _visible_. Ask commit logs to include "this was debugged via kdump" lines, etc. The upstream kernel must feel that it all matters. The upstream kernel really has to be ruthless about such things and must react to how things are not to how things are wished to be - one of the most critical things is that keeps Linux ticking is people like you who report and debug problems. Note, back when kdump was added to the kernel many moons ago i strongly supported it and helped out with the patches, etc. I still think it might have the potential to become big - but it needs a ton of tech and care to reach that level of convenience. 'kdump light' perhaps that dumps the most important data structures like registers of all CPUs, task struct and the symbol tables, the current task itself including the kernel stack plus the surrounding 4K of all pointers that are in current registers and that point into kernel memory - maybe straight to kerneloops.org [if the user agrees] - or something like that. Ingo -- 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