Hi, Konrad wiki page (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a90049716207b9c672fd78187b0c77767be0) says that "i915_hangcheck_eplased" error observed with i915 driver. Do you have a latest update on this issue? Is it still the outstanding issue, or fixed in recent kernels? I''m using Linux 3.2-rc4, with same error observed when trying to launch glxgear. So want to understand whether it''s due to my kernel version, or config option... :-) Thanks Kevin
On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:> Hi, KonradHey! Sorry for taking so long to respond. Holidays.> > wiki page (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a90049716207b9c672fd78187b0c77767be0) > says that "i915_hangcheck_eplased" error observed with i915 driver. > > Do you have a latest update on this issue? Is it still the outstanding issue, or fixed in > recent kernels?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.> > I''m using Linux 3.2-rc4, with same error observed when trying to launch glxgear. So > want to understand whether it''s due to my kernel version, or config option... :-)Do you see the same symptoms - checkboard screen? 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..
> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] > Sent: Wednesday, January 04, 2012 12:59 AM > > On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote: > > Hi, Konrad > > Hey! > > Sorry for taking so long to respond. Holidays.good season for relax. :-)> > > > wiki page > (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971 > 6207b9c672fd78187b0c77767be0) > > says that "i915_hangcheck_eplased" error observed with i915 driver. > > > > Do you have a latest update on this issue? Is it still the outstanding issue, or > fixed in > > recent kernels? > > 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.> > > > > I''m using Linux 3.2-rc4, with same error observed when trying to launch > glxgear. So > > want to understand whether it''s due to my kernel version, or config > option... :-) > > 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... :/> > 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. Thanks Kevin
> From: Tian, Kevin > Sent: Friday, January 06, 2012 8:58 AM > > > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] > > Sent: Wednesday, January 04, 2012 12:59 AM > > > > On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote: > > > Hi, Konrad > > > > Hey! > > > > Sorry for taking so long to respond. Holidays. > > good season for relax. :-) > > > > > > > wiki page > > > (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971 > > 6207b9c672fd78187b0c77767be0) > > > says that "i915_hangcheck_eplased" error observed with i915 driver. > > > > > > Do you have a latest update on this issue? Is it still the outstanding issue, or > > fixed in > > > recent kernels? > > > > 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. > > > > > > > > > I''m using Linux 3.2-rc4, with same error observed when trying to launch > > glxgear. So > > > want to understand whether it''s due to my kernel version, or config > > option... :-) > > > > 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. 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 MTRR specific pending patches. Thanks Kevin
> > > 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 anyRight, 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.
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, January 06, 2012 10:37 PM > > > > > 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?I''m using a HP elitebook 8460p (Intel @ QM67 express chipset), with a HD graphics 3000.> > > But more interestingly - are you building your kernel from scratch? Thereyes> 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.Suppose you mean CONFIG_DMAR_TABLE? There''s no CONFIG_IOMMU_DMAR in the latest kernel. Yes, I didn''t enable that option, and will have a try. But a side question is, will enabling VT-d in dom0 conflict with Xen''s own VT-d operations?> > 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.That''s my feeling too... Thanks Kevin
> > But more interestingly - are you building your kernel from scratch? There > > yes > > > 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. > > Suppose you mean CONFIG_DMAR_TABLE? There''s no CONFIG_IOMMU_DMAR > in the latest kernel. Yes, I didn''t enable that option, and will have a try.Yes, that is the option.> > But a side question is, will enabling VT-d in dom0 conflict with Xen''s own > VT-d operations?No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux''s parser won''t pick it up.
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Monday, January 09, 2012 11:05 PM > > > > But more interestingly - are you building your kernel from scratch? There > > > > yes > > > > > 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. > > > > Suppose you mean CONFIG_DMAR_TABLE? There''s no > CONFIG_IOMMU_DMAR > > in the latest kernel. Yes, I didn''t enable that option, and will have a try. > > Yes, that is the option. > > > > > But a side question is, will enabling VT-d in dom0 conflict with Xen''s own > > VT-d operations? > > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux''s > parser won''t pick it up.Hi, Konrad, this information is really great, and now X can be started smoothly, and also a simple glxgear runs well! :-) This options deserves an explicit mark in the wiki page btw. Thanks Kevin
On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote:> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > Sent: Monday, January 09, 2012 11:05 PM > > > > > > But more interestingly - are you building your kernel from scratch? There > > > > > > yes > > > > > > > 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. > > > > > > Suppose you mean CONFIG_DMAR_TABLE? There''s no > > CONFIG_IOMMU_DMAR > > > in the latest kernel. Yes, I didn''t enable that option, and will have a try. > > > > Yes, that is the option. > > > > > > > > But a side question is, will enabling VT-d in dom0 conflict with Xen''s own > > > VT-d operations? > > > > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux''s > > parser won''t pick it up. > > Hi, Konrad, > > this information is really great, and now X can be started smoothly, and also > a simple glxgear runs well! :-) This options deserves an explicit mark in the > wiki page btw.Done! If you have a screenshot of the "defective" kernel build that would be usefull as we can attach it to http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_just_random_stuff_when_using_i915> > Thanks > Kevin
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Tuesday, January 10, 2012 10:39 PM > > On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote: > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > > Sent: Monday, January 09, 2012 11:05 PM > > > > > > > > But more interestingly - are you building your kernel from scratch? > There > > > > > > > > yes > > > > > > > > > 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. > > > > > > > > Suppose you mean CONFIG_DMAR_TABLE? There''s no > > > CONFIG_IOMMU_DMAR > > > > in the latest kernel. Yes, I didn''t enable that option, and will have a try. > > > > > > Yes, that is the option. > > > > > > > > > > > But a side question is, will enabling VT-d in dom0 conflict with Xen''s own > > > > VT-d operations? > > > > > > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux''s > > > parser won''t pick it up. > > > > Hi, Konrad, > > > > this information is really great, and now X can be started smoothly, and also > > a simple glxgear runs well! :-) This options deserves an explicit mark in the > > wiki page btw. > > Done! If you have a screenshot of the "defective" kernel build that would be > usefull > as we can attach it to > http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_j > ust_random_stuff_when_using_i915I''ll see whether I can take one. Need to find a way which can capture the screen before X is fully started. My working environment prevents from using camera. :/ Thanks Kevin> > > > > Thanks > > Kevin