Date:	Sat, 10 Jan 2009 09:21:11 -0500
From:	"Mike Snitzer" <snitzer@...il.com>
To:	"Nicholas Miell" <nmiell@...cast.net>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>, "jim owens" <jowens@...com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Chris Mason" <chris.mason@...cle.com>,
	"Peter Zijlstra" <peterz@...radead.org>,
	"Steven Rostedt" <rostedt@...dmis.org>, paulmck@...ux.vnet.ibm.com,
	"Gregory Haskins" <ghaskins@...ell.com>,
	"Matthew Wilcox" <matthew@....cx>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Nick Piggin" <npiggin@...e.de>,
	"Peter Morreale" <pmorreale@...ell.com>,
	"Sven Dietrich" <SDietrich@...ell.com>, sam@...nborg.org,
	"Dave Anderson" <anderson@...hat.com>
Subject: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

On Sat, Jan 10, 2009 at 1:44 AM, Nicholas Miell <nmiell@...cast.net> wrote:
> On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote:
>>
>> On Fri, 9 Jan 2009, Nicholas Miell wrote:
>> >
>> > It's only too big if you always keep it in memory, and I wasn't
>> > suggesting that.
>>
>> Umm. We're talking kernel panics here. If it's not in memory, it doesn't
>> exist as far as the kernel is concerned.
>>
>> If it doesn't exist, it cannot be reported.
>
> The idea was that the kernel would generate a crash dump and then after
> the reboot, a post-processing tool would do something with it. (e.g. run
> the dump through crash to get a stack trace using separate debug info or
> ship the entire dump off to a collection server or something).
>
>> > And this is where we disagree. I believe that crash dumps should be the
>> > norm and all the reasons you have against crash dumps in general are in
>> > fact reasons against Linux's sub-par implementation of crash dumps in
>> > specific.
>>
>> Good luck with that. Go ahead and try it.  You'll find it wasn't so easy
>> after all.
>>
>> > So, here I am, a non-enterprise end user with a non-stale kernel who'd
>> > love to be able to give you a crash dump (or, more likely, a stack trace
>> > created from that crash dump), but I can't because Linux crash dumps are
>> > stuck in the enterprise ghetto.
>>
>> No, you're stuck because you apparently have your mind stuck on a
>> crash-dump, and aren't willing to look at alternatives.
>>
>> You could use a network console. Trust me - if you can't set up a network
>> console, you have no business mucking around with crash dumps.
>
> netconsole requires a second computer. Feel free to mail me one. :)
>
>> And if the crash is hard enough that you can't any output from that,
>> again, a crash dump wouldn't exactly help, would it?
>>
>> > Hell, I'd be happy if I could get the the normal panic text written to
>> > disk, but since the hard part is the actual writing to disk, there's no
>> > reason not to do the full crash dump if you can.
>>
>> Umm. And why do you think the two have anything to do with each other?
>>
>> Only insane people want the kernel to write to disk when it has problems.
>> Sane people try to write to something that doesn't potentially overwrite
>> their data. Like the network.
>>
>> Which is there. Try it. Trust me, it's a _hell_ of a lot more likely to
>> wotk than a crash dump.
>
> Well, yes, but that has everything to do with how terrible kdump is and
> nothing to do with the idea of crash dumps in general.
>
> Anyway, we've strayed off topic long enough, I'm sure everyone in the Cc
> list would be happy to stop getting an earful about the merits of crash
> dumps.

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

Now that said, I too value crash dumps and will stray a bit off-topic
(subject changed), I do have one significant debugability issue when
using crash dumps: on x86_64 I'm unable to get line number information
from symbols that reside in a module.

I tried to get some insight on this from Dave Anderson (crash utility
developer/maintainer) here:
http://www.mail-archive.com/crash-utility@redhat.com/msg01101.html

Dave was helpful but ultimately couldn't explain why I'm unable to get
line numbers with my x86_64 kernel.org kernels (and he/redhat with
RHEL4 kernels).

I strongly respect those cc'd and have to believe someone can help me
cut through this.

I've updated scripts/package/mkspec so that the 'make rpm' target
produces RedHat-style kernel rpms (models redhat's kernel.spec).  This
includes creating debuginfo rpms.  I've attached a patch that works on
2.6.28; but again the resulting debuginfo doesn't provide line numbers
for the kernel modules under crash!?

If anyone has some insight on what I might be missing (as part of the
kernel build) I'd _really_ appreciate it.  I provided the mkspec patch
just as a reference, if the RPM stuff is too opaque please just help
me understand the bare mechanics of what is needed without mkspec (in
the meantime I'll try the debuginfo generation patch Sam Ravnborg
recently posted too).

regards,
Mike

View attachment "mkspec_2.6.28.patch" of type "text/x-patch" (11253 bytes)

Powered by blists - more mailing lists