Messages in this thread | | | Date | Mon, 17 Jan 2011 12:11:59 -0700 | Subject | Re: BUG: unable to handle kernel paging request at ffff8800cf669000 | From | xing lin <> |
| |
On Mon, Jan 17, 2011 at 12:00 AM, Américo Wang <xiyou.wangcong@gmail.com> wrote: > If you are using x86, you have CONFIG_X86_PTDUMP, with which > you can dump all page tables via debugfs.
It turns out CONFIG_X86_PTDUMP is not set. :-) utos@node:/boot$ grep PTDUMP /boot/config-2.6.32-24-generic # CONFIG_X86_PTDUMP is not set utos@node:/boot$ uname -a Linux node.memcached.checkpoint.emulab.net 2.6.32-24-generic #38+emulab1 SMP Mon Aug 23 18:07:24 MDT 2010 x86_64 GNU/Linux
On the other hand, I do not understand why I need to look into page tables. I think for the current 64-bit machines, all the physical memory can be direct-mapped into the kernel logical space. In the AMD 64-bit machine, the kernel space ranges from [0xFFFF 8000 0000 0000, 0xFFFF FFFF FFFF FFFF] which is 128TB. In my Intel 64-bit machine, the kernel is mapped at 0xFFFF 8800 0000 0000. I think the kernel space is from [0xFFFF 8800 0000 0000, 0xFFFF FFFF FFFF FFFF] which is 119TB. So I can use __pa() or __va() to get physical address or virtual address directly. Right?
-- Regards, Xing School of Computing, University of Utah http://www.cs.utah.edu/~xinglin/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |