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 <[EMAIL PROTECTED]> wrote:
>>>> * Michal Piotrowski <[EMAIL PROTECTED]> 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:[<c1610192>] 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:
>> [<c16af187>] read_from_oldmem+0x73/0x98
>> [<c19a9cfd>] vmcore_init+0x26c/0xab7
>> [<c199979b>] init+0xaa/0x287
>> [<c16044eb>] 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.
> 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()?
I added
printk(KERN_WARNING "copy_oldmem_page() pfn=%lu , buf=%s , nr_bytes=%d ,
offset=%lu , userbuf=%d\n", pfn, buf, nr_bytes, offset, userbuf);
before
tmp = copy_oldmem_page(pfn, buf, nr_bytes, offset, userbuf);
result is here
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/kdump-console2.log
'buf' might be broken.
>
> 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/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
