question about i915 driver in dom0

question about i915 driver in dom0

[Tian, Kevin]

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

Re: question about i915 driver in dom0

[Konrad Rzeszutek Wilk]

On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> Hi, Konrad

Hey!

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..

Re: question about i915 driver in dom0

[Tian, Kevin]

> 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

Re: question about i915 driver in dom0

[Tian, 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

Re: question about i915 driver in dom0

[Konrad Rzeszutek Wilk]

> > > 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.

Re: question about i915 driver in dom0

[Tian, Kevin]

> 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? 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.

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

Re: question about i915 driver in dom0

[Konrad Rzeszutek Wilk]

> > 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.

Re: question about i915 driver in dom0

[Tian, Kevin]

> 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

Re: question about i915 driver in dom0

[Konrad Rzeszutek Wilk]

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

Re: question about i915 driver in dom0

[Tian, 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_i915

I'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