From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: question about i915 driver in dom0 Date: Fri, 6 Jan 2012 09:37:19 -0500 Message-ID: <20120106143719.GA5078@phenom.dumpdata.com> References: <20120103165917.GB749@andromeda.dapyr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > > > I hadn't seen it... but then my main desktop box where I run intensive > > > tests (ie, games) is radeon and nvidia so hadn't really tried seen this. > > > The box that has i915 just does some simple framebuffer manipulation and > > > that looks OK. > > > > yes, framebuffer console works well in my side too. Good. > > > Do you see the same symptoms - checkboard screen? > > > > Not exactly. The screen becomes white, and then the system becomes > > unstable and hang several minutes later. It's possible that mine is a > > different issue than listed on the wiki page, since many reasons may > > finally reach the same symptom - GPU hang... :/ > > well, there happens once with a checkboard screen, with the rest all > white screens. > > > > > > > > > The LKML had some fixes for this from Keith Packard. Something about > > > using i915.semaphores=0 I think. And I thought I saw some fixes for > > > 3.2-rc7 for this but not sure.. > > > > I'll have a try on latest Linux on this. But I suspect that this may be a > > virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case), > > because same dom0 image could run glxgear smoothly on bare metal. > > > > I used latest 3.2 release, no difference. What is the motherboard you have? I just bought an "DQ67SW" which perhaps has the same video card? But more interestingly - are you building your kernel from scratch? There was some requirements in having CONFIG_IOMMU_DMAR in the kernels - otherwise the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API. And that caused an endless amount of pain. > > i915.semaphores=0 has no effect. > > But I observed below warnings in the boot process: > [ 8.872430] [drm] MTRR allocation failed. Graphics performance may suffer. > [ 18.384552] microcode: CPU0 update to revision 0x1b failed > > Not sure whether above two issues may have impact on the said problem. > I know microcode update is still missing in upstream, but not sure about any Right, microcode is ... pending hpa's coming back from paternity leave. > MTRR specific pending patches. The MTRR are not in, but the graphics code should still work.