From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xhci passthrough Date: Thu, 28 Oct 2010 17:12:23 -0400 Message-ID: <20101028211223.GA23216@dumpdata.com> References: <2010169160.20101028000118@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <2010169160.20101028000118@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sander Eikelenboom Cc: Jeremy Fitzhardinge , "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, Oct 28, 2010 at 12:01:18AM +0200, Sander Eikelenboom wrote: > Hi Konrad, > > Due to a 2.6.37-merge-window kernel now being able to boot under Xen i was able to test my xhci controller under dom0 which i previously couldn't. > > The results: > A) 2.6.37-merge-window kernel baremetal: Videograbbing while doing 20 iterations of make -j6 of kernel works. > B) Xen + 2.6.37-merge-window kernel as Dom0: Videograbbing while doing 20 iterations of make -j6 of kernel works. Great! > C) Xen + 2.6.32.24 pvops dom0 + 2.6.37-merge-window kernel DomU: Videograbbing while doing 20 iterations of make -j6 still freezes the machine without a trace after a short while. Ok, so it points to the 2.6.32.24 doing something funky, which unfortunatly does not help that much as the xen patches that are in the 2.6.37-merge-window for IRQ are about the same as what 2.6.32.24 has. Thought the 2.6.37-merge-window got tons of bells and whistles in the generic Linux kernel code part. These interrupts were for the MSI-X for the XHCI controller or was it legacy interrupts? > > An other interesting thing is the interrupt rate i see in /proc/interrrupts for the xhci controller, i measured for 5 minutes each time. > In situation: > A) About 3200 Interrupts/second > B) About 3200 Interrupts/second > C) About 7800 Interrupts/second, what would be 7.8 interrupt per ms which seems to work as long as you don't stress the rest to the limit. > Which probably causes some sort of deadlock (some where in the path from device, xen, dom0/pciback , domU/pcifront, xhci driver, application.) when not delivered on time or when it boldly goes on a code path where no one has gone before .. > > Compared with a measurement of interrupts by a USB2 controller: > Around 155 Interrupts/second > > Probably a silly question without a right answer ... but what interrupt rate would you guess it should be able to take ? > And is it logically that when passed through it causes around 2.5 times more interrupts ? > > Now testing on a Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz > > -- > > Sander > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel