From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422673AbXCWIXs (ORCPT ); Fri, 23 Mar 2007 04:23:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422696AbXCWIXs (ORCPT ); Fri, 23 Mar 2007 04:23:48 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]:53874 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422673AbXCWIXr (ORCPT ); Fri, 23 Mar 2007 04:23:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:from; b=ROHTb0nIqjziPzRf4/+EcPY7j6ERWzdA5Wby8+q70hoarpNjagxxNeEh/U4fug0LXaBAv7acMWHQnCD13PYyQo8a7p36P5ku4Z7Xj0sz4MNacIyG/eZrmpJMj3TkArHXKe8LGrAZL7BcPo555KtCCzdxWnm2KL+RRyqZrLCHxGs= Message-ID: <46038E68.4070807@googlemail.com> Date: Fri, 23 Mar 2007 09:23:04 +0100 User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: vgoyal@in.ibm.com CC: Michal Piotrowski , Ingo Molnar , Thomas Gleixner , LKML Subject: Re: 2.6.21-rc4-rt0-kdump References: <6bffcb0e0703211338i2aa6f933ube53c6604c78e285@mail.gmail.com> <20070322093119.GA19394@elte.hu> <6bffcb0e0703220557h7ff64282qf378623452c07d03@mail.gmail.com> <4602843D.9000306@googlemail.com> <20070323052501.GA1421@in.ibm.com> In-Reply-To: <20070323052501.GA1421@in.ibm.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Michal Piotrowski Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Vivek Goyal napisał(a): > On Thu, Mar 22, 2007 at 02:27:25PM +0100, Michal Piotrowski wrote: >> Michal Piotrowski napisał(a): >>> On 22/03/07, Ingo Molnar wrote: >>>> * Michal Piotrowski wrote: >>>> >>>>> Hi Ingo, >>>>> 2.6.21-rc4-rt0 >>>>> BUG: at kernel/fork.c:1033 copy_process() >>>> thanks Michal - this is a real bug that affects upstream too. Find the >>>> fix below - i've test-booted it and it fixes the warning. >>> Problem is fixed, thanks. >> BTW. It seems that nobody uses -rt as a crash dump kernel ;) >> >> BUG: unable to handle kernel paging request at virtual address f7ebf8c4 >> printing eip: >> c1610192 >> *pde = 00000000 >> stopped custom tracer. >> Oops: 0000 [#1] >> PREEMPT >> Modules linked in: >> CPU: 0 >> EIP: 0060:[] Not tainted VLI >> EFLAGS: 00010206 (2.6.21-rc4-rt0-kdump #3) >> EIP is at copy_oldmem_page+0x4a/0xd0 >> eax: 000008c4 ebx: f7ebf000 ecx: 00000100 edx: 00000246 >> esi: f7ebf8c4 edi: c4c520fc ebp: c4d54e30 esp: c4d54e18 >> ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 preempt:00000001 >> Process swapper (pid: 1, ti=c4d54000 task=c4d52c20 task.ti=c4d54000) >> Stack: c17ab7e0 c183f982 c1969658 00000400 00000400 00037ebf c4d54e5c c16af187 >> 00037ebf c4c520fc 00000400 000008c4 00000000 00000000 c4c696e0 00000400 >> c4c520fc c4d54f94 c19a9cfd c4c520fc 00000400 c4d54f78 00000000 c1840996 >> Call Trace: >> [] read_from_oldmem+0x73/0x98 >> [] vmcore_init+0x26c/0xab7 >> [] init+0xaa/0x287 >> [] kernel_thread_helper+0x7/0x10 >> ======================= >> >> l *copy_oldmem_page+0x4a/0xd0 >> 0xc1610148 is in copy_oldmem_page (arch/i386/kernel/crash_dump.c:35). >> 30 * copying the data to a pre-allocated kernel page and then copying to user >> 31 * space in non-atomic context. >> 32 */ >> 33 ssize_t copy_oldmem_page(unsigned long pfn, char *buf, >> 34 size_t csize, unsigned long offset, int userbuf) >> 35 { >> 36 void *vaddr; >> 37 >> 38 if (!csize) >> 39 return 0; >> > > Can you please paste the disassembly of copy_oldmem_page() on your system. disassemble *copy_oldmem_page Dump of assembler code for function copy_oldmem_page: 0xc1610148 : push %ebp 0xc1610149 : mov %esp,%ebp 0xc161014b : push %edi 0xc161014c : push %esi 0xc161014d : push %ebx 0xc161014e : sub $0xc,%esp 0xc1610151 : call 0xc160f5c4 0xc1610156 : mov 0x8(%ebp),%ebx 0xc1610159 : xor %edx,%edx 0xc161015b : cmpl $0x0,0x10(%ebp) 0xc161015f : je 0xc161020d 0xc1610165 : call 0xc1661258 0xc161016a : shl $0x5,%ebx 0xc161016d : add 0xc1d68e60,%ebx 0xc1610173 : mov %ebx,(%esp) 0xc1610176 : call 0xc1613577 0xc161017b : mov %eax,%ebx 0xc161017d : cmpl $0x0,0x18(%ebp) 0xc1610181 : jne 0xc16101ad 0xc1610183 : mov 0x10(%ebp),%ecx 0xc1610186 : shr $0x2,%ecx 0xc1610189 : mov 0x14(%ebp),%eax 0xc161018c : lea (%ebx,%eax,1),%esi 0xc161018f : mov 0xc(%ebp),%edi 0xc1610192 : rep movsl %ds:(%esi),%es:(%edi) 0xc1610194 : mov 0x10(%ebp),%ecx 0xc1610197 : and $0x3,%ecx 0xc161019a : je 0xc161019e 0xc161019c : rep movsb %ds:(%esi),%es:(%edi) 0xc161019e : call 0xc166126e 0xc16101a3 : mov %ebx,(%esp) 0xc16101a6 : call 0xc1613533 0xc16101ab : jmp 0xc161020a 0xc16101ad : mov 0xc19d4004,%edi 0xc16101b3 : test %edi,%edi 0xc16101b5 : jne 0xc16101ca 0xc16101b7 : movl $0xc18bbc93,(%esp) 0xc16101be : call 0xc1619671 0xc16101c3 : mov $0xfffffff2,%edx 0xc16101c8 : jmp 0xc161020d 0xc16101ca : mov $0x400,%ecx 0xc16101cf : mov %eax,%esi 0xc16101d1 : rep movsl %ds:(%esi),%es:(%edi) 0xc16101d3 : call 0xc166126e 0xc16101d8 : mov %ebx,(%esp) 0xc16101db : call 0xc1613533 0xc16101e0 : mov 0x10(%ebp),%eax 0xc16101e3 : mov %eax,0x8(%esp) 0xc16101e7 : mov 0xc19d4004,%eax 0xc16101ec : add %eax,0x14(%ebp) 0xc16101ef : mov 0x14(%ebp),%eax 0xc16101f2 : mov %eax,0x4(%esp) 0xc16101f6 : mov 0xc(%ebp),%eax 0xc16101f9 : mov %eax,(%esp) 0xc16101fc : call 0xc1700e98 0xc1610201 : mov $0xfffffff2,%edx 0xc1610206 : test %eax,%eax 0xc1610208 : jne 0xc161020d 0xc161020a : mov 0x10(%ebp),%edx 0xc161020d : mov %edx,%eax 0xc161020f : add $0xc,%esp 0xc1610212 : pop %ebx 0xc1610213 : pop %esi 0xc1610214 : pop %edi 0xc1610215 : pop %ebp 0xc1610216 : ret End of assembler dump. > Not sure from where this faulting address 0xf7ebf8c4 is coming. We are still > in vmcore_init(), so we should be copying the data to kernel buffers only. > This looks like a valid kernel address. > > Can you also put some printk() here to find out from where 0xf7ebf8c4 has > come? It does not look like a fixed kernel virutual address returned by > kmap_atomic_pfn(). Then is it passed by kernel as a parameter to > copy_oldmem_page()? > > Thanks > Vivek > Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/)