From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Jakobovitsch Subject: Re: Tapdisk failures / kernel general protection fault at xen 4.0.2rc3 / kernel pvops 2.6.32.36 Date: Thu, 14 Apr 2011 15:05:19 -0300 Message-ID: <4DA7375F.7060705@alog.com.br> References: <4DA60F55.4000604@alog.com.br> <20110414131543.GE5548@dumpdata.com> <1302799089.24534.18.camel@agari.van.xensource.com> <1302803034.24534.24.camel@agari.van.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1302803034.24534.24.camel@agari.van.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Hello Daniel: I applied the patch and the bug at VM startup was solved. Thank you for your help. Regards Gerd On 04/14/2011 02:43 PM, Daniel Stodden wrote: > On Thu, 2011-04-14 at 12:38 -0400, Daniel Stodden wrote: >> On Thu, 2011-04-14 at 09:15 -0400, Konrad Rzeszutek Wilk wrote: >>> On Wed, Apr 13, 2011 at 06:02:13PM -0300, Gerd Jakobovitsch wrote: >>>> I'm trying to run several VMs (linux hvm, with tapdisk:aio disks at >>>> a storage over nfs) on a CentOS system, using the up-to-date version >>>> of xen 4.0 / kernel pvops 2.6.32.x stable. With a configuration >>>> without (most of) debug activated, I can start several instances - >>>> I'm running 7 of them - but shortly afterwards the system stops >>>> responding. I can't find any information on this. >>> First time I see it. >>>> Activating several debug configuration items, among them >>>> DEBUG_PAGEALLOC, I get an exception as soon as I try to start up a >>>> VM. The system reboots. >>> Oooh, and is the log below from that situation? >>> >>> Daniel, any thoughs? >> --- >> Unmap pages from the kernel linear mapping after free_pages(). >> This results in a large slowdown, but helps to find certain types >> of memory corruption. >> >> Stunning. Our I/O page allocator is a sort of twisted mempool. Unless >> the allocation is explicitly modified in sysfs/, everything should stay >> pinned. We might be just tripping over debug code alone, but I didn't >> figure it out yet. > Ah, that's just missing Dominic's spinlock fix. > > http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=commit;h=a765257af7e28c41bd776c3e03615539597eb592 > > Daniel >