From: Takao Indoh <indou.takao@soft.fujitsu.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH 0/4][diskdump] x86-64 support
Date: Sat, 28 Aug 2004 18:43:03 +0900 [thread overview]
Message-ID: <89C48CE36A27FFindou.takao@soft.fujitsu.com> (raw)
Hi all,
Here is the latest diskdump patch for kernel 2.6.8.1.
- Supports x86_64
- Fix bug of Fusion-MPT scsi driver patch
- Add new functions for finding ram area
Source code can be downloaded from
http://sourceforge.net/projects/lkdump
When I tested diskdump on x86-64 machine, I found that memory dump of
the following two areas failed.
1) 04000000 - 07ffffff
2) around last two page
Memory dump of the area 2) failed because page->flag was broken.
So I compare PFN to page_to_pfn(pfn_to_page(PFN)) and skip this PFN
if these value is different.
page = pfn_to_page(nr);
if (nr != page_to_pfn(page)) {
/* page_to_pfn() is called from kmap_atomic().
* If page->flag is broken, it specified a wrong
* zone and it causes kmap_atomic() fail.
*/
Err("Bad page. PFN %lu flags %lx\n",
nr, (unsigned long)page->flags);
memset(scratch + blk_in_chunk * PAGE_SIZE, 0,
PAGE_SIZE);
sprintf(scratch + blk_in_chunk * PAGE_SIZE,
"Bad page. PFN %lu flags %lx\n",
nr, (unsigned long)page->flags);
goto write;
}
Memory dump of the area 1) failed because this area was not mapped to
vaddr. Diskdump checks page using page_is_ram() and maps it using
kmap_atomic(). In the area 1), both page_is_ram() and kmap_atomic()
return true, but page is not attached to the page table.
I think this area is AGP Aperture. I found this message in the dmesg.
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 4000000 size 65536 KB
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
To resolve this problem, I check page using kern_addr_valid() before
kmap_atomic().
if (!kern_addr_valid((unsigned long)pfn_to_kaddr(nr))) {
memset(scratch + blk_in_chunk * PAGE_SIZE, 0,
PAGE_SIZE);
sprintf(scratch + blk_in_chunk * PAGE_SIZE,
"Unmapped page. PFN %lu\n", nr);
goto write;
}
kaddr = kmap_atomic(page, KM_CRASHDUMP);
memcpy(scratch + blk_in_chunk * PAGE_SIZE, kaddr, PAGE_SIZE);
kunmap_atomic(kaddr, KM_CRASHDUMP);
write:
Now diskdump seems to work correctly. But I am not sure these method is
right. Please let me know if there are better methods.
Best Regards,
Takao Indoh
next reply other threads:[~2004-08-28 9:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-28 9:43 Takao Indoh [this message]
2004-08-28 9:44 ` [PATCH 1/4][diskdump] x86-64 support Takao Indoh
2004-08-28 9:45 ` [PATCH 2/4][diskdump] " Takao Indoh
2004-08-28 10:21 ` Christoph Hellwig
2004-08-28 9:47 ` [PATCH 3/4][diskdump] " Takao Indoh
2004-08-28 9:48 ` [PATCH 4/4][diskdump] " Takao Indoh
2004-08-28 10:23 ` Christoph Hellwig
2004-08-31 9:10 ` Takao Indoh
2004-09-04 11:11 ` Christoph Hellwig
2004-09-04 22:31 ` Lee Revell
[not found] <2y80v-1lR-13@gated-at.bofh.it>
2004-08-28 14:13 ` [PATCH 0/4][diskdump] " Andi Kleen
2004-08-31 9:08 ` Takao Indoh
2004-09-03 9:40 ` Takao Indoh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89C48CE36A27FFindou.takao@soft.fujitsu.com \
--to=indou.takao@soft.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.