[PATCH 0/4][diskdump] x86-64 support

[PATCH 0/4][diskdump] x86-64 support

[Takao Indoh]

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

Re: [PATCH 0/4][diskdump] x86-64 support

[Andi Kleen]

Takao Indoh <indou.takao@soft.fujitsu.com> writes:

Hallo,

> Hi all,
>
> Here is the latest diskdump patch for kernel 2.6.8.1.
>
> - Supports x86_64

Thanks for doing this work.

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

Broken in what way? That should probably just be fixed in the core
kernel.

> 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 

Yes, this is done intentionally because the IOMMU is not 100% cache
coherent in the way Linux uses it and accesses to the aperture 
area by the CPU are not allowed. To prevent mistakes or the CPU 
prefetching by its own into it it is unmapped.

SLAB DEBUG can cause the same thing and even on other architectures, so 
you really need to handle it generically.


> kmap_atomic(). In the area 1), both page_is_ram() and kmap_atomic()
> return true, but page is not attached to the page table.

kmap_atomic() on 64bit always just returns the pointer, it's a nop.
Even on 32bit it cannot fail.

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

kern_addr_valid is probably not a bad way to solve it, although it is
a bit costly.

When the page is not mapped you could always map it on your own with
ioremap(), but that address cannot be used for any DMA, so it 
may not work. Skipping them is probably ok.

-Andi

Re: [PATCH 0/4][diskdump] x86-64 support

[Takao Indoh]

Hello,

Thanks for comment.

On Sat, 28 Aug 2004 16:13:10 +0200, Andi Kleen wrote:

>> 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.
>
>Broken in what way? That should probably just be fixed in the core
>kernel.

page->flag around last two page is 0.
I tested on another machine and found all of page->flag is correct.
So this problem may be dependent on machine.

Regards,
Takao Indoh

Re: [PATCH 0/4][diskdump] x86-64 support

[Takao Indoh]

On Tue, 31 Aug 2004 18:08:45 +0900, Takao Indoh wrote:

>>> 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.
>>
>>Broken in what way? That should probably just be fixed in the core
>>kernel.
>
>page->flag around last two page is 0.
>I tested on another machine and found all of page->flag is correct.
>So this problem may be dependent on machine.

page->flag of the following two page is 0...

PFN 1310719
PFN 1441791

Regards,
Takao Indoh