On Wed, Sep 16 2009 at  6:44pm -0400,
Bob Montgomery <bob.montgomery(a)hp.com> wrote:
 This patch allows the dis -l command to show real source line
numbers
 for module code, instead of this sort of thing:
 
 crash-4.0.9> dis -l bnx2_poll_msix
 include/linux/cpumask.h: 612
 0xffffffffa008acc3 <bnx2_poll_msix>:    push   %rbp
 0xffffffffa008acc4 <bnx2_poll_msix+1>:  mov    %rsp,%rbp
 0xffffffffa008acc7 <bnx2_poll_msix+4>:  push   %r15
 0xffffffffa008acc9 <bnx2_poll_msix+6>:  push   %r14
 0xffffffffa008accb <bnx2_poll_msix+8>:  push   %r13
 0xffffffffa008accd <bnx2_poll_msix+10>: mov    %esi,%r13d
 0xffffffffa008acd0 <bnx2_poll_msix+13>: push   %r12
 0xffffffffa008acd2 <bnx2_poll_msix+15>: xor    %r12d,%r12d
 0xffffffffa008acd5 <bnx2_poll_msix+18>: push   %rbx
 0xffffffffa008acd6 <bnx2_poll_msix+19>: mov    %rdi,%rbx
 0xffffffffa008acd9 <bnx2_poll_msix+22>: sub    $0x8,%rsp
 
 The problem has to do with a symbol table in the kernel containing an
 abnormally huge text range because of a goofy vsyscall reference in the
 file  "arch/x86/kernel/hpet.c".
 
 (gdb) p *(struct block *)0x8d664b0
 $41 = {startaddr = 0xffffffff80225130, endaddr = 0xffffffffff6001b3,
 
 This range pretty much covers the entire module address space and since
 the kernel file is first in the object_files list, the search stops
 there and returns the closest symbol from the kernel, instead of looking
 on through the object list to the module of actual interest.
 
 This patch causes the code to keep looking through all modules and
 return the real best symbol thingy (you can tell how much I really know
 about gdb's symtab stuff, ahem).  Thanks (and blame) to John Wright for
 suggesting the fix once I found the problem.
 
 The patch applies to the gdb patch file in the crash directory.
 
 John and I think that this code in gdb searches things too many times,
 particularly with this patch, but it's a start since it seems to fix the
 problem.  Mayhaps some gdb experts can now help do it right.
 
 With the patch, the above example becomes:
 
 crash-4.0.9> dis -l bnx2_poll_msix
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3215
 0xffffffffa008acc3 <bnx2_poll_msix>:    push   %rbp
 0xffffffffa008acc4 <bnx2_poll_msix+1>:  mov    %rsp,%rbp
 0xffffffffa008acc7 <bnx2_poll_msix+4>:  push   %r15
 0xffffffffa008acc9 <bnx2_poll_msix+6>:  push   %r14
 0xffffffffa008accb <bnx2_poll_msix+8>:  push   %r13
 0xffffffffa008accd <bnx2_poll_msix+10>: mov    %esi,%r13d
 0xffffffffa008acd0 <bnx2_poll_msix+13>: push   %r12
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3219
 0xffffffffa008acd2 <bnx2_poll_msix+15>: xor    %r12d,%r12d
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3215
 0xffffffffa008acd5 <bnx2_poll_msix+18>: push   %rbx
 0xffffffffa008acd6 <bnx2_poll_msix+19>: mov    %rdi,%rbx
 0xffffffffa008acd9 <bnx2_poll_msix+22>: sub    $0x8,%rsp
 
 
 Bob Montgomery 
I bisected this problem some time ago but it didn't go anywhere after
that:
http://www.redhat.com/archives/crash-utility/2009-January/msg00063.html
So your observation about arch/x86/kernel/hpet.c really makes sense.
Thanks for sorting this out Bob!!!