From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine Date: Tue, 04 Sep 2012 07:59:36 +0100 Message-ID: References: <5045BD5C02000078000985A7@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5045BD5C02000078000985A7@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Sander Eikelenboom , George Dunlap Cc: wei.wang2@amd.com, Santosh Jodh , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 04/09/2012 07:35, "Jan Beulich" wrote: >>>> On 02.09.12 at 09:42, Keir Fraser wrote: >> On 31/08/2012 22:45, "Sander Eikelenboom" wrote: >>> - When using serial console: I get a infinite stream of "gfn: mfn: " lines, >>> mean while on the normal console, S-ATA devices are starting to give errors. >> >> In this case the handler must be running in tasklet context. Not sure why >> SATA interrupts would be affected as hardirq and softirq work will still be >> carried out during execution of the keyhandler (the handler voluntarily >> preempts itself for softirq work). >> >> Would need more investigation. :) > > Isn't that because tasklets (i.e. idle vCPU-s with tasklets active) > get preferred in the schedulers? Some compensation might be > needed for the penalized vCPU, at least if that one is pinned > (not sure whether load balancing would be able to steal the > head of the run queue from a remote CPU). Sander - are you > by chance pinning Dom0 vCPU-s? And how many of them does > your Dom0 have? Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't going to expend too much brain power on this situation. The case of spending a few minutes in one key handler is not one I think is particularly sane. -- Keir > Jan >