On 11/18/2011 04:43 PM, Dave Young wrote: > On 11/18/2011 12:40 AM, Tim Hartrick wrote: > >> >> Dave, Tejun, Americo, >> >> Attached find three configs: >> >> Ubuntu 2.6.32-21-server - works >> Ubuntu 2.6.38-8-server - fails >> Ubuntu 3.3.1-030101-generic (stable) - fails > > > Thanks, Tim > >> >> On Thu, 2011-11-17 at 15:21 +0800, Dave Young wrote: >>> On 11/17/2011 01:22 PM, Tim Hartrick wrote: >>> >>>> Tejun, Dave, >>>> >>>> I will be happy to answer any questions about our environment or test >>>> debug or other patches. Just tell me what you need. >>> >>> >>> Thank you. Can you share your kernel config? >>> >>>> >>>> tim >>>> >>>> On Nov 16, 2011 8:44 PM, "Dave Young" <dyoung at redhat.com >>>> <mailto:dyoung at redhat.com>> wrote: >>>> >>>> On 11/17/2011 12:34 PM, Tejun Heo wrote: >>>> >>>> > Hello, >>>> > >>>> > On Wed, Nov 16, 2011 at 7:30 PM, Dave Young <dyoung at redhat.com >>>> <mailto:dyoung at redhat.com>> wrote: >>>> >> This addr is converted to an invalid phys address, >>>> > >>>> > I'm a bit lost on the context here. Who's calling >>>> per_cpu_ptr_to_phys()? >>>> >>>> >>>> It's drivers/base/cpu.c : show_crash_notes() >>>> >>>> > >>>> >> looking the code below: >>>> >> if (in_first_chunk) { >>>> >> if (!is_vmalloc_addr(addr)) >>>> >> return __pa(addr); >>>> >> else >>>> >> return page_to_phys(vmalloc_to_page(addr)); >>>> >> } else >>>> >> return page_to_phys(pcpu_addr_to_page(addr)); >>>> >> >>>> >> I dont understand per cpu allocation well, if addr is not in >>>> first chunk >>>> >> then it should be in vmalloc area? >>>> > >>>> > Yes, it is. First chunk can be embedded in the kernel linear address >>>> > space but from the second one, it's always set up from the top of the >>>> > vmalloc area with the same offset layout as the first chunk. >>>> >>>> >>>> in this case ffff880667c19ad0 fall out of vmalloc area and it's not in >>>> first chunk also. > > > Tejun, > > With config provided by Tim, I can reproduce this problem on a dell > machine. I did some debug about this, found that fisrt_start < > first_end, typo, I mean first_start > first_end so there's no chance to check in for_each_possible_cpu(cpu) > > why is the first_start/first_end wrong? pcpu_unit_offsets[] is not > ordered? any idea? > > I see below hack make the bug gone, it confirmed the addr is indeed in > first chunk. > > diff --git a/mm/percpu.c b/mm/percpu.c > index bf80e55..8f6eb58 100644 > --- a/mm/percpu.c > +++ b/mm/percpu.c > @@ -984,26 +984,14 @@ phys_addr_t per_cpu_ptr_to_phys(void *addr) > { > void __percpu *base = __addr_to_pcpu_ptr(pcpu_base_addr); > bool in_first_chunk = false; > - unsigned long first_start, first_end; > unsigned int cpu; > > - /* > - * The following test on first_start/end isn't strictly > - * necessary but will speed up lookups of addresses which > - * aren't in the first chunk. > - */ > - first_start = pcpu_chunk_addr(pcpu_first_chunk, pcpu_first_unit_cpu, 0); > - first_end = pcpu_chunk_addr(pcpu_first_chunk, pcpu_last_unit_cpu, > - pcpu_unit_pages); > - if ((unsigned long)addr >= first_start && > - (unsigned long)addr < first_end) { > - for_each_possible_cpu(cpu) { > - void *start = per_cpu_ptr(base, cpu); > - > - if (addr >= start && addr < start + pcpu_unit_size) { > - in_first_chunk = true; > - break; > - } > + for_each_possible_cpu(cpu) { > + void *start = per_cpu_ptr(base, cpu); > + > + if (addr >= start && addr < start + pcpu_unit_size) { > + in_first_chunk = true; > + break; > } > } > >>>> >>>> > >>>> >> Tejun, do you have any idea about this? >>>> > >>>> > Can you please tell me how to reproduce the problem? I'll try to find >>>> > out what's going on. >>>> >>>> >>>> make sure kernel support CRASH DUMP, then cat >>>> /sys/devices/system/cpu/cpu[x]/crash_notes >>>> >>>> Tim Hartrick <tim at edgecast.com <mailto:tim at edgecast.com>> reported >>>> the problem when test kdump. >>>> But I can not reproduce this. I think tim can help to test >>>> >>>> > >>>> > Thanks. >>>> > >>>> >>>> >>>> >>>> -- >>>> Thanks >>>> Dave >>>> >>> >>> >>> >> > > > -- Thanks Dave
