Kdump issue with percpu_alloc=lpage

[John Blackwood]

Vivek Goyal wrote:
> On Thu, Nov 19, 2009 at 11:45:25PM +0900, Tejun Heo wrote:
>> Hello,
>>
>> 11/19/2009 11:33 PM, Vivek Goyal wrote:
>>> I did load a kdump kernel on 32-rc7 and it worked fine. But I guess in
>>> this case memory might have come from linearly mapped region.
>>>
>>> If the default per cpu allocator can get memory from vmalloc region
>>> also, then I think we will need this function which can map virtual
>>> address to physical address.
>> I see.
>>
>>> Are there multiple allocators now? If yes, what are the command line
>>> options and I can try to use some other allocator and see if I can force
>>> the condition where memory comes from vmalloc region and I observe the
>>> crash.
>>>
>>> Once I can reproduce it, I can also send you the fix you suggested.
>> Now there are two allocators - embed (default) and page.  You can
>> choose using percpu_alloc= parameter.  Embed allocator will put the
>> first chunk in linear mapping area while page will put the first chunk
>> in vmalloc area too but regardless of the allocator from the second
>> chunk it will always be in the vmalloc area.  So, either using
>> percpu_alloc=page or allocating some amount of percpu memory using
>> __alloc_percpu() - a thousand 4k blocks will always be enough - should
>> do it.
> 
> Looks like with percpu_alloc=page, I am getting bogus physical addresses in
> /sys/devices/system/cpu<N>/crash_notes.
> 
> With percpu_alloc=page
> 
> cpu0 60fffff49800
> cpu1 60fffff60800
> cpu2 60fffff77800
> 
> with percpu_alloc=embed
> 
> cpu0 28219800
> cpu1 28259800
> cpu2 28299800
> 
> I got 4G of RAM in my box. "embed" seems to be fine.

That sounds right to me.  In previous kernels, 'embed' was o.k. also.

Thanks for looking into this Vivek.
I've been too busy right now to try this out.