lkml.org 
[lkml]   [2011]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle]
On 9/12/11 12:11 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 12, 2011 at 12:06:41PM -0400, Christopher S. Aker wrote:
>>> It would really neat if the issue you have been hitting was exactly this
>>> and just having you revert the ef691947d8a3d479e67652312783aedcf629320a
>>> would fix it.
>>
>> Reverted, built, deployed, and set as default. We shall see!
>
> <holds his fingers crossed>

No joy. Still getting reports even with the patched kernel. I was so
confident that this was the problem -- I've tripled checked that the
patch was applied and that this is indeed the correct kernel. It was
built with DEBUG_HIGHMEM too, without any difference in the dump.

BUG: unable to handle kernel paging request at f5768598
IP: [<c01abbd4>] swap_count_continued+0x84/0x180
*pdpt = 0000000000939027 *pde = 00000000017ef067 *pte = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in:

Pid: 1619, comm: apache2 Not tainted 3.0.4-linode37 #1
EIP: 0061:[<c01abbd4>] EFLAGS: 00010246 CPU: 2
EIP is at swap_count_continued+0x84/0x180
EAX: f5768598 EBX: ed13af80 ECX: ec9cf0a0 EDX: 00000080
ESI: ed1d35a0 EDI: 00000080 EBP: 00000598 ESP: e73d3dd4
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process apache2 (pid: 1619, ti=e73d2000 task=ebd0e410 task.ti=e73d2000)
Stack:
ebd3f240 0000e598 00000040 00000000 c01abdc1 ec540e30 ebd3f240 0000e598
00000000 c01ae027 ec540e30 b8fc6000 e73d3e68 c01a00e3 44846045 80000008
00000000 00000020 c0105c27 2bbca063 001cb300 eb424200 ecf7780c eaaade38
Call Trace:
[<c01abdc1>] ? swap_entry_free+0xf1/0x120
[<c01ae027>] ? free_swap_and_cache+0x27/0xd0
[<c01a00e3>] ? zap_pte_range+0x173/0x460
[<c0105c27>] ? xen_force_evtchn_callback+0x17/0x30
[<c01a04d0>] ? unmap_page_range+0x100/0x180
[<c01a05da>] ? unmap_vmas+0x8a/0xc0
[<c01a2a93>] ? exit_mmap+0x73/0x100
[<c0132bbb>] ? mmput+0x2b/0xc0
[<c013642f>] ? exit_mm+0xef/0x120
[<c06bf870>] ? _raw_spin_lock_irq+0x10/0x20
[<c0137fd5>] ? do_exit+0x125/0x350
[<c01a2a07>] ? remove_vma+0x37/0x50
[<c013823c>] ? do_group_exit+0x3c/0xa0
[<c01382b1>] ? sys_exit_group+0x11/0x20
[<c06bfb71>] ? syscall_call+0x7/0xb
[<c06b0000>] ? sctp_err_lookup+0xb0/0x110
Code: 00 00 89 fa 80 fa 80 74 22 e9 0b 01 00 00 90 e8 63 7a f7 ff 8b 5b
18 83 eb 18 39 de 0f
84 f3 00 00 00 89 d8 e8 de 7c f7 ff 01 e8 <0f> b6 10 80 fa 80 74 dc 84
d2 0f 84 e2 00 00 00
83 ea 01 80 fa
EIP: [<c01abbd4>] swap_count_continued+0x84/0x180 SS:ESP 0069:e73d3dd4
CR2: 00000000f5768598
---[ end trace 06805b7648b253a0 ]---

So today I built a new stack and enabled loglvl=warning and
guest_loglvl=warning/info, however it's probably going to take a while
before we have enough of these running and hit this problem.

I'm going to play around with it some more and see if I can find a
recipe that can reproduce.

-Chris


\
 
 \ /
  Last update: 2011-09-15 21:01    [W:0.073 / U:1.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site