From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 11:47:54 +0800 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0642646848559356174==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel List-Id: xen-devel@lists.xenproject.org --===============0642646848559356174== Content-Type: multipart/alternative; boundary=14dae934059548840b04cfea9d57 --14dae934059548840b04cfea9d57 Content-Type: text/plain; charset=ISO-8859-1 Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I've checked the code in question and found that mode 3 is an 'reserved_1' mode. I want to trace down the source of this mode setting to root-cause the issue. But I'm not an xen developer, and am even a newbie as a xen user. Could anybody give me instructions about how to enable detailed debug log? It could be better if I can get advice about experiments to perform / switches to try out etc. My SW config: dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) domU: Debian wheezy 3.2.x stock kernel. Thanks, Timothy --14dae934059548840b04cfea9d57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi developers,
I met some domU issues and the log suggests missing inter= rupt.
Details from here: http://www.gossamer-threads.com/lists/xen/users/= 263938#263938
In summary, this is the suspicious log:

(XEN) vmsi.c:122:d32767 Unsu= pported delivery mode 3

I've checked the code in question and fo= und that mode 3 is an 'reserved_1' mode.
I want to trace down th= e source of this mode setting to root-cause the issue.
But I'm not an xen developer, and am even a newbie as a xen user.
C= ould anybody give me instructions about how to enable detailed debug log?It could be better if I can get advice about experiments to perform / swi= tches to try out etc.

My SW config:
dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.= 3-4)
domU: Debian wheezy 3.2.x stock kernel.

Thanks,
Timothy --14dae934059548840b04cfea9d57-- --===============0642646848559356174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0642646848559356174==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhang, Xiantao" Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 07:06:24 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4255746506243060713==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "G.R." , xen-devel Cc: "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org --===============4255746506243060713== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_B6C2EB9186482D47BD0C5A9A483456440339D2CDSHSMSX101ccrcor_" --_000_B6C2EB9186482D47BD0C5A9A483456440339D2CDSHSMSX101ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe you need to provide more information about your VGA device, for exa= mple, "lspci -vvv". In addition, from your log, seems expansion rom bar= is not correctly handled. You may refer to this wiki page to check whethe= r something is missed in your side. http://wiki.xen.org/wiki/Xen_VGA_Pass= through Xiantao From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o= rg] On Behalf Of G.R. Sent: Monday, December 03, 2012 11:48 AM To: xen-devel Subject: [Xen-devel] Issue about domU missing interrupt Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#2= 63938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I've checked the code in question and found that mode 3 is an 'reserved_1' = mode. I want to trace down the source of this mode setting to root-cause the issu= e. But I'm not an xen developer, and am even a newbie as a xen user. Could anybody give me instructions about how to enable detailed debug log? It could be better if I can get advice about experiments to perform / switc= hes to try out etc. My SW config: dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) domU: Debian wheezy 3.2.x stock kernel. Thanks, Timothy --_000_B6C2EB9186482D47BD0C5A9A483456440339D2CDSHSMSX101ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe you need to  p= rovide more information about your VGA device,  for example,  = 220;lspci –vvv”.   In addition,  from your log, = seems expansion rom bar is not correctly handled.  You may refer to this wiki page to check whether = something is missed in your side.   http://wiki.xen.org/wiki/Xen_VGA_Passthrough

Xiantao=

 <= /p>

From: xen-deve= l-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of G.R.
Sent: Monday, December 03, 2012 11:48 AM
To: xen-devel
Subject: [Xen-devel] Issue about domU missing interrupt

 

Hi developers,
I met some domU issues and the log suggests missing interrupt.
Details from here:
http://www.gossamer-threads.com/lists/xen/users/263938#263938
In summary, this is the suspicious log:

(XEN) vmsi.c:122:d32767 Unsupported delivery mode 3

I've checked the code in question and found that mode 3 is an 'reserved_1' = mode.
I want to trace down the source of this mode setting to root-cause the issu= e.
But I'm not an xen developer, and am even a newbie as a xen user.
Could anybody give me instructions about how to enable detailed debug log?<= br> It could be better if I can get advice about experiments to perform / switc= hes to try out etc.

My SW config:
dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4)
domU: Debian wheezy 3.2.x stock kernel.

Thanks,
Timothy

--_000_B6C2EB9186482D47BD0C5A9A483456440339D2CDSHSMSX101ccrcor_-- --===============4255746506243060713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4255746506243060713==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Issue about domU missing interrupt Date: Mon, 03 Dec 2012 08:46:26 +0000 Message-ID: <50BC74F202000078000AD2FA@nat28.tlf.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "G.R." Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 03.12.12 at 04:47, "G.R." wrote: > Hi developers, > I met some domU issues and the log suggests missing interrupt. > Details from here: > http://www.gossamer-threads.com/lists/xen/users/263938#263938 > In summary, this is the suspicious log: > > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > I've checked the code in question and found that mode 3 is an 'reserved_1' > mode. > I want to trace down the source of this mode setting to root-cause the > issue. > But I'm not an xen developer, and am even a newbie as a xen user. > Could anybody give me instructions about how to enable detailed debug log? > It could be better if I can get advice about experiments to perform / > switches to try out etc. Please check the list archives, this issue was discussed in great lengths a couple of months ago (and should be fixed in current trees). Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 10:15:08 +0000 Message-ID: <50BC7BAC.8050107@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/12/12 03:47, G.R. wrote: > Hi developers, > I met some domU issues and the log suggests missing interrupt. > Details from here: > http://www.gossamer-threads.com/lists/xen/users/263938#263938 > In summary, this is the suspicious log: > > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > I've checked the code in question and found that mode 3 is an > 'reserved_1' mode. > I want to trace down the source of this mode setting to root-cause the > issue. > But I'm not an xen developer, and am even a newbie as a xen user. > Could anybody give me instructions about how to enable detailed debug log? > It could be better if I can get advice about experiments to perform / > switches to try out etc. > > My SW config: > dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > domU: Debian wheezy 3.2.x stock kernel. > > Thanks, > Timothy Are you passing hardware (PCI Passthrough) to the HVM guest? What are the exact messages in the DomU? -- Mats From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 20:43:00 +0800 Message-ID: References: <50BC74F202000078000AD2FA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4004368494276883589==" Return-path: In-Reply-To: <50BC74F202000078000AD2FA@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 Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============4004368494276883589== Content-Type: multipart/alternative; boundary=14dae9340595e7b08304cff21693 --14dae9340595e7b08304cff21693 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 3, 2012 at 4:46 PM, Jan Beulich wrote: > >>> On 03.12.12 at 04:47, "G.R." wrote: > > Hi developers, > > I met some domU issues and the log suggests missing interrupt. > > Details from here: > > http://www.gossamer-threads.com/lists/xen/users/263938#263938 > > In summary, this is the suspicious log: > > > > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > > > I've checked the code in question and found that mode 3 is an > 'reserved_1' > > mode. > > I want to trace down the source of this mode setting to root-cause the > > issue. > > But I'm not an xen developer, and am even a newbie as a xen user. > > Could anybody give me instructions about how to enable detailed debug > log? > > It could be better if I can get advice about experiments to perform / > > switches to try out etc. > > Please check the list archives, this issue was discussed in great > lengths a couple of months ago (and should be fixed in current > trees). > > Thanks, I just found the thread you mentioned: http://lists.xen.org/archives/html/xen-devel/2012-06/msg01909.html I can confirm that the debian version of the xen 4.1.3 still misses this patch. Given the fact that xen 4.1.3 releases after the patch, I guess it is only intended for v4.2.0? Do you believe this patch should work for v4.1.3 either? But anyway, I'm going to try my luck later... Thanks, Timothy --14dae9340595e7b08304cff21693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 3, 2012 a= t 4:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 03.12.12 at 04:47, "G.R." <<= a href=3D"mailto:firemeteor@users.sourceforge.net">firemeteor@users.sourcef= orge.net> wrote:
> Hi developers,
> I met some domU issues and the log suggests missing interrupt.
> Details from here:
> http://www.gossamer-threads.com/lists/xen/users/26393= 8#263938
> In summary, this is the suspicious log:
>
> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3
>
> I've checked the code in question and found that mode 3 is an '= ;reserved_1'
> mode.
> I want to trace down the source of this mode setting to root-cause the=
> issue.
> But I'm not an xen developer, and am even a newbie as a xen user.<= br> > Could anybody give me instructions about how to enable detailed debug = log?
> It could be better if I can get advice about experiments to perform /<= br> > switches to try out etc.

Please check the list archives, this issue was discussed in great
lengths a couple of months ago (and should be fixed in current
trees).


Thanks, I just found the thread you mentioned:http://lists.xen.org/archives/html/xen-devel/2012-06/msg01909.html=

I can confirm that the debian version of the xen 4.1.3 still misses thi= s patch.
Given the fact that xen 4.1.3 releases after the patch, I guess= it is only intended for v4.2.0?

Do you believe this patch should wo= rk for v4.1.3 either?
But anyway, I'm going to try my luck later...

Thanks,
Timoth= y
--14dae9340595e7b08304cff21693-- --===============4004368494276883589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4004368494276883589==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Issue about domU missing interrupt Date: Mon, 03 Dec 2012 13:06:05 +0000 Message-ID: <50BCB1CD02000078000AD3F7@nat28.tlf.novell.com> References: <50BC74F202000078000AD2FA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "G.R." Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 03.12.12 at 13:43, "G.R." wrote: > On Mon, Dec 3, 2012 at 4:46 PM, Jan Beulich wrote: > >> >>> On 03.12.12 at 04:47, "G.R." wrote: >> > Hi developers, >> > I met some domU issues and the log suggests missing interrupt. >> > Details from here: >> > http://www.gossamer-threads.com/lists/xen/users/263938#263938 >> > In summary, this is the suspicious log: >> > >> > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> > >> > I've checked the code in question and found that mode 3 is an >> 'reserved_1' >> > mode. >> > I want to trace down the source of this mode setting to root-cause the >> > issue. >> > But I'm not an xen developer, and am even a newbie as a xen user. >> > Could anybody give me instructions about how to enable detailed debug >> log? >> > It could be better if I can get advice about experiments to perform / >> > switches to try out etc. >> >> Please check the list archives, this issue was discussed in great >> lengths a couple of months ago (and should be fixed in current >> trees). >> >> > Thanks, I just found the thread you mentioned: > http://lists.xen.org/archives/html/xen-devel/2012-06/msg01909.html > > I can confirm that the debian version of the xen 4.1.3 still misses this > patch. > Given the fact that xen 4.1.3 releases after the patch, I guess it is only > intended for v4.2.0? > > Do you believe this patch should work for v4.1.3 either? I don't think to date a backport of it to 4.1.x was requested. Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 21:06:40 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2949336765687338523==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Xiantao" Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============2949336765687338523== Content-Type: multipart/alternative; boundary=e89a8f5036c8921d1904cff26b69 --e89a8f5036c8921d1904cff26b69 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 3, 2012 at 3:06 PM, Zhang, Xiantao wro= te: > Maybe you need to provide more information about your VGA device, for > example, =93lspci =96vvv=94. In addition, from your log, seems expans= ion rom > bar is not correctly handled. You may refer to this wiki page to check > whether something is missed in your side. > http://wiki.xen.org/wiki/Xen_VGA_Passthrough**** > > Xiantao**** > > ** > I'm using the IGD coming with the H77M chipset, here are the lspci -vvv output from dom0: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 0162 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=3Dfast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=3D1/1 Maskable- 64bit- Address: fee00018 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 And in domU respectively: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 0162 Physical Slot: 2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=3Dfast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=3D1/1 Maskable- 64bit- Address: fee33000 Data: 4300 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME- Kernel driver in use: i915 They are pretty much the same from my point of view except for some interrupt config. The 'expansion ROM' are disabled in both case. But what does this mean after all? Could you give a brief intro for my education? I did not find anything obvious missing from the wiki page. I would like to note that I'm using an AsRock H77m-itx board. Even when the chipset is not formally classified as vt-d capable (yes, I noticed your email domain), Intel is still shipping H77 based vt-d capable board ( http://www.intel.com/support/motherboards/desktop/sb/CS-030922.htm). I guess this should not count as a missing piece, right? Thanks, Timothy > ** > > *From:* xen-devel-bounces@lists.xen.org [mailto: > xen-devel-bounces@lists.xen.org] *On Behalf Of *G.R. > *Sent:* Monday, December 03, 2012 11:48 AM > *To:* xen-devel > *Subject:* [Xen-devel] Issue about domU missing interrupt**** > > ** ** > > Hi developers, > I met some domU issues and the log suggests missing interrupt. > Details from here: > http://www.gossamer-threads.com/lists/xen/users/263938#263938 > In summary, this is the suspicious log: > > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > I've checked the code in question and found that mode 3 is an 'reserved_1= ' > mode. > I want to trace down the source of this mode setting to root-cause the > issue. > But I'm not an xen developer, and am even a newbie as a xen user. > Could anybody give me instructions about how to enable detailed debug log= ? > It could be better if I can get advice about experiments to perform / > switches to try out etc. > > My SW config: > dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > domU: Debian wheezy 3.2.x stock kernel. > > Thanks, > Timothy**** > --e89a8f5036c8921d1904cff26b69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 3, 20= 12 at 3:06 PM, Zhang, Xiantao <xiantao.zhang@intel.com> wrote:

Maybe you need to =A0provide = more information about your VGA device,=A0 for example,=A0 =93lspci =96vvv= =94. =A0=A0In addition,=A0 from your log, seems expansion rom bar is not correctly handled. =A0You may refer to this wiki page to check whether som= ething is missed in your side. =A0=A0http://wiki.xen.org/wiki/Xen_VGA_Passt= hrough

Xiantao<= /p>

I'm using the IGD coming with the H77M chipset, here= are the lspci -vvv output from dom0:
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Ge= n Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])=
=A0=A0=A0 Subsystem: ASRock Incorporation Device 0162
=A0=A0=A0 Cont= rol: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- S= ERR- FastB2B- DisINTx+
=A0=A0=A0 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=3Dfast >TAbor= t- <TAbort- <MAbort- >SERR- <PERR- INTx-
=A0=A0=A0 Latency: = 0
=A0=A0=A0 Interrupt: pin A routed to IRQ 95
=A0=A0=A0 Region 0: Mem= ory at f7800000 (64-bit, non-prefetchable) [size=3D4M]
=A0=A0=A0 Region 2: Memory at e0000000 (64-bit, prefetchable) [size=3D256M]=
=A0=A0=A0 Region 4: I/O ports at f000 [size=3D64]
=A0=A0=A0 Expansio= n ROM at <unassigned> [disabled]
=A0=A0=A0 Capabilities: [90] MSI:= Enable+ Count=3D1/1 Maskable- 64bit-
=A0=A0=A0 =A0=A0=A0 Address: fee00018=A0 Data: 0000
=A0=A0=A0 Capabiliti= es: [d0] Power Management version 2
=A0=A0=A0 =A0=A0=A0 Flags: PMEClk- D= SI+ D1- D2- AuxCurrent=3D0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
=A0=A0=A0 = =A0=A0=A0 Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
=A0=A0=A0 Capabilities: [a4] PCI Advanced Features
=A0=A0=A0 =A0=A0=A0 A= FCap: TP+ FLR+
=A0=A0=A0 =A0=A0=A0 AFCtrl: FLR-
=A0=A0=A0 =A0=A0=A0 A= FStatus: TP-
=A0=A0=A0 Kernel driver in use: i915

And in domU res= pectively:

00:02.0 VGA compatible controller: Intel Corporation Xeon= E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00= [VGA controller])
=A0=A0=A0 Subsystem: ASRock Incorporation Device 0162
=A0=A0=A0 Physical= Slot: 2
=A0=A0=A0 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGA= Snoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
=A0=A0=A0 Status: Cap+ = 66MHz- UDF- FastB2B+ ParErr- DEVSEL=3Dfast >TAbort- <TAbort- <MAbo= rt- >SERR- <PERR- INTx+
=A0=A0=A0 Latency: 64
=A0=A0=A0 Interrupt: pin A routed to IRQ 78
=A0= =A0=A0 Region 0: Memory at f1000000 (64-bit, non-prefetchable) [size=3D4M]<= br>=A0=A0=A0 Region 2: Memory at e0000000 (64-bit, prefetchable) [size=3D25= 6M]
=A0=A0=A0 Region 4: I/O ports at c100 [size=3D64]
=A0=A0=A0 Expansion ROM at <unassigned> [disabled]
=A0=A0=A0 Capab= ilities: [90] MSI: Enable+ Count=3D1/1 Maskable- 64bit-
=A0=A0=A0 =A0=A0= =A0Address: fee33000=A0 Data: 4300
=A0=A0=A0 Capabilities: [d0] Power M= anagement version 2
=A0=A0=A0 =A0=A0 =A0Flags: PMEClk- DSI+ D1- D2- AuxC= urrent=3D0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
=A0=A0=A0 =A0=A0 =A0Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 P= ME-
=A0=A0=A0 Kernel driver in use: i915

They are pretty much the= same from my point of view except for some interrupt config.
The 'e= xpansion ROM' are disabled in both case.
But what does this mean after all? Could you give a brief intro for my educ= ation?

I did not find anything obvious missing from the wiki page. <= br>I would like to note that I'm using an AsRock H77m-itx board.
Even when the chipset is not formally classified as vt-d capable (yes, I no= ticed your email domain),
Intel is still shipping H77 based vt-d capabl= e board (http://www.intel.com/support/motherboards/desktop/sb/CS-030922= .htm).
I guess this should not count as a missing piece, right?

Thanks,
= Timothy

=A0

From: xen-devel-bounces@lists.xen= .org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of G.R.
Sent: Monday, December 03, 2012 11:48 AM
To: xen-devel
Subject: [Xen-devel] Issue about domU missing interrupt

=A0

Hi developers,
I met some domU issues and the log suggests missing interrupt.
Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938
In summary, this is the suspicious log:

(XEN) vmsi.c:122:d32767 Unsupported delivery mode 3

I've checked the code in question and found that mode 3 is an 'rese= rved_1' mode.
I want to trace down the source of this mode setting to root-cause the issu= e.
But I'm not an xen developer, and am even a newbie as a xen user.
Could anybody give me instructions about how to enable detailed debug log?<= br> It could be better if I can get advice about experiments to perform / switc= hes to try out etc.

My SW config:
dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4)
domU: Debian wheezy 3.2.x stock kernel.

Thanks,
Timothy


--e89a8f5036c8921d1904cff26b69-- --===============2949336765687338523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2949336765687338523==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 21:14:55 +0800 Message-ID: References: <50BC7BAC.8050107@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2115664862363947947==" Return-path: In-Reply-To: <50BC7BAC.8050107@citrix.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: Mats Petersson Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============2115664862363947947== Content-Type: multipart/alternative; boundary=20cf301d42320f0ee104cff28910 --20cf301d42320f0ee104cff28910 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson wrote: > On 03/12/12 03:47, G.R. wrote: > >> Hi developers, >> I met some domU issues and the log suggests missing interrupt. >> Details from here: http://www.gossamer-threads.** >> com/lists/xen/users/263938#**263938 >> In summary, this is the suspicious log: >> >> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >> I've checked the code in question and found that mode 3 is an >> 'reserved_1' mode. >> I want to trace down the source of this mode setting to root-cause the >> issue. >> But I'm not an xen developer, and am even a newbie as a xen user. >> Could anybody give me instructions about how to enable detailed debug log? >> It could be better if I can get advice about experiments to perform / >> switches to try out etc. >> >> My SW config: >> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> domU: Debian wheezy 3.2.x stock kernel. >> >> Thanks, >> Timothy >> > Are you passing hardware (PCI Passthrough) to the HVM guest? > What are the exact messages in the DomU? > > Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). But this is actually a PVHVM guest since debian stock kernel has PVOP enabled. And when I tried another PVOP disabled linux distro (openelec v2.0), I did not see such msi related error message. Actually, with that domU I do not see anything obvious wrong from the log, but I also see nothing from panel (panel receive no signal and go power-saving) :-( Back to the issue I was reporting, the domU log looks like this: Dec 2 21:52:44 debvm kernel: [ 1085.604071] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at 3354], missed IRQ? Dec 2 21:56:50 debvm kernel: [ 1332.076071] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at 11297], missed IRQ? Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from codec, disabling MSI: last cmd=0x002f0600 Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x002f0600 Thanks, Timothy --20cf301d42320f0ee104cff28910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 3, 2012 a= t 6:15 PM, Mats Petersson <mats.petersson@citrix.com> wrote:
On 03/12/12 03:47, G.R. wrote:
Hi developers,
I met some domU issues and the log suggests missing interrupt.
Details from here: http://www.gossamer-threads.com/= lists/xen/users/263938#263938
In summary, this is the suspicious log:

(XEN) vmsi.c:122:d32767 Unsupported delivery mode 3

I've checked the code in question and found that mode 3 is an 'rese= rved_1' mode.
I want to trace down the source of this mode setting to root-cause the issu= e.
But I'm not an xen developer, and am even a newbie as a xen user.
Could anybody give me instructions about how to enable detailed debug log?<= br> It could be better if I can get advice about experiments to perform / switc= hes to try out etc.

My SW config:
dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4)
domU: Debian wheezy 3.2.x stock kernel.

Thanks,
Timothy
Are you passing hardware (PCI Passthrough) to the HVM guest?
What are the exact messages in the DomU?


Yes, I'm doing PCI passthrough (the IGD, audio &am= p;& USB controller).
But this is actually a PVHVM guest since debian= stock kernel has PVOP enabled.
And when I tried another PVOP disabled l= inux distro (openelec v2.0), I did not see such msi related error message.<= br> Actually, with that domU I do not see anything obvious wrong from the log, = but I also see nothing from panel (panel receive no signal and go power-sav= ing) :-(


Back to the issue I was reporting, the domU log looks l= ike this:

Dec 2 21:52:44 debvm kernel: [ 1085= .604071] [drm:i915_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed= ... blt ring idle [waiting on 3354, at
3354], missed IRQ?
Dec 2 21:56:50 debvm kernel: [ 1332.076071] [drm:i9= 15_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed... render ring = idle [waiting on 11297, at
11297], missed IRQ?
Dec 2 22:32:48 debv= m kernel: [ 7.220073] hda-intel: azx_get_response
timeout, switching to polling mode: last cmd=3D0x000f0000
Dec 2 22:45:= 32 debvm kernel: [ 776.392084] hda-intel: No response from
codec, disa= bling MSI: last cmd=3D0x002f0600
Dec 2 22:45:33 debvm kernel: [ 777.4= 00075] hda_intel: azx_get_response
timeout, switching to single_cmd mode: last cmd=3D0x002f0600
=


Thanks,
Timothy
--20cf301d42320f0ee104cff28910-- --===============2115664862363947947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2115664862363947947==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 13:19:47 +0000 Message-ID: <50BCA6F3.8060804@citrix.com> References: <50BC7BAC.8050107@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "G.R." Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 03/12/12 13:14, G.R. wrote: > On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson > > wrote: > > On 03/12/12 03:47, G.R. wrote: > > Hi developers, > I met some domU issues and the log suggests missing interrupt. > Details from here: > http://www.gossamer-threads.com/lists/xen/users/263938#263938 > In summary, this is the suspicious log: > > (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > I've checked the code in question and found that mode 3 is an > 'reserved_1' mode. > I want to trace down the source of this mode setting to > root-cause the issue. > But I'm not an xen developer, and am even a newbie as a xen user. > Could anybody give me instructions about how to enable > detailed debug log? > It could be better if I can get advice about experiments to > perform / switches to try out etc. > > My SW config: > dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > domU: Debian wheezy 3.2.x stock kernel. > > Thanks, > Timothy > > Are you passing hardware (PCI Passthrough) to the HVM guest? > What are the exact messages in the DomU? > > > Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). > But this is actually a PVHVM guest since debian stock kernel has PVOP > enabled. > And when I tried another PVOP disabled linux distro (openelec v2.0), I > did not see such msi related error message. > Actually, with that domU I do not see anything obvious wrong from the > log, but I also see nothing from panel (panel receive no signal and go > power-saving) :-( > > > Back to the issue I was reporting, the domU log looks like this: > > Dec 2 21:52:44 debvm kernel: [ 1085.604071] > [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at > 3354], missed IRQ? > Dec 2 21:56:50 debvm kernel: [ 1332.076071] > [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at > 11297], missed IRQ? > Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response > timeout, switching to polling mode: last cmd=0x000f0000 > Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from > codec, disabling MSI: last cmd=0x002f0600 > Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response > timeout, switching to single_cmd mode: last cmd=0x002f0600 > > > Thanks, > Timothy It does sound like there is a fix in 4.2.0, as indicated by Jan, that fixes this. I'm not fully clued up to what the policy for backporting fixes are, and I haven't looked at the complexity of the fix itself, but either updating to the 4.2.0 or a (personal) backport sounds like the right solution here. Unfortunately, I hadn't seen Jan's reply by the time I wrote my response to your original email. -- Mats From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 13:58:07 +0000 Message-ID: <50BCAFEF.7040300@citrix.com> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50BCA6F3.8060804@citrix.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: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/12/12 13:19, Mats Petersson wrote: > On 03/12/12 13:14, G.R. wrote: >> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >> > wrote: >> >> On 03/12/12 03:47, G.R. wrote: >> >> Hi developers, >> I met some domU issues and the log suggests missing interrupt. >> Details from here: >> http://www.gossamer-threads.com/lists/xen/users/263938#263938 >> In summary, this is the suspicious log: >> >> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >> I've checked the code in question and found that mode 3 is an >> 'reserved_1' mode. >> I want to trace down the source of this mode setting to >> root-cause the issue. >> But I'm not an xen developer, and am even a newbie as a xen user. >> Could anybody give me instructions about how to enable >> detailed debug log? >> It could be better if I can get advice about experiments to >> perform / switches to try out etc. >> >> My SW config: >> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> domU: Debian wheezy 3.2.x stock kernel. >> >> Thanks, >> Timothy >> >> Are you passing hardware (PCI Passthrough) to the HVM guest? >> What are the exact messages in the DomU? >> >> >> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >> But this is actually a PVHVM guest since debian stock kernel has PVOP >> enabled. >> And when I tried another PVOP disabled linux distro (openelec v2.0), I >> did not see such msi related error message. >> Actually, with that domU I do not see anything obvious wrong from the >> log, but I also see nothing from panel (panel receive no signal and go >> power-saving) :-( >> >> >> Back to the issue I was reporting, the domU log looks like this: >> >> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >> [drm:i915_hangcheck_ring_idle] >> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >> 3354], missed IRQ? >> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >> [drm:i915_hangcheck_ring_idle] >> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >> 11297], missed IRQ? >> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >> timeout, switching to polling mode: last cmd=0x000f0000 >> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >> codec, disabling MSI: last cmd=0x002f0600 >> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >> timeout, switching to single_cmd mode: last cmd=0x002f0600 >> >> >> Thanks, >> Timothy > It does sound like there is a fix in 4.2.0, as indicated by Jan, that > fixes this. I'm not fully clued up to what the policy for backporting > fixes are, and I haven't looked at the complexity of the fix itself, but > either updating to the 4.2.0 or a (personal) backport sounds like the > right solution here. I had a quick look, and it doesn't look that hard to backport that patch. -- Mats > > Unfortunately, I hadn't seen Jan's reply by the time I wrote my response > to your original email. > > -- > Mats > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Tue, 4 Dec 2012 11:07:23 +0800 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6508738499468714629==" Return-path: In-Reply-To: <50BCAFEF.7040300@citrix.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: Mats Petersson Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============6508738499468714629== Content-Type: multipart/alternative; boundary=90e6ba6e8e203b79bb04cffe2a08 --90e6ba6e8e203b79bb04cffe2a08 Content-Type: text/plain; charset=ISO-8859-1 > I had a quick look, and it doesn't look that hard to backport that patch. Thanks, Mat. I'm glad to report that the patch do fix my problem. And yest it is really easy to port since the code did not change across the two release. The only change would be line numbers (3841 vs 3803) and one extra comments before this line: static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) I'm not sure if you are going to release another maintenance version that include this patch, but I'll report this to Debain maintainer since it's about to freeze for v7.0 release and v4.2.0 will not make it. On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson wrote: > On 03/12/12 13:19, Mats Petersson wrote: > >> On 03/12/12 13:14, G.R. wrote: >> >>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >>> >> >>> wrote: >>> >>> On 03/12/12 03:47, G.R. wrote: >>> >>> Hi developers, >>> I met some domU issues and the log suggests missing interrupt. >>> Details from here: >>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >>> 263938 >>> In summary, this is the suspicious log: >>> >>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >>> >>> I've checked the code in question and found that mode 3 is an >>> 'reserved_1' mode. >>> I want to trace down the source of this mode setting to >>> root-cause the issue. >>> But I'm not an xen developer, and am even a newbie as a xen >>> user. >>> Could anybody give me instructions about how to enable >>> detailed debug log? >>> It could be better if I can get advice about experiments to >>> perform / switches to try out etc. >>> >>> My SW config: >>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >>> domU: Debian wheezy 3.2.x stock kernel. >>> >>> Thanks, >>> Timothy >>> >>> Are you passing hardware (PCI Passthrough) to the HVM guest? >>> What are the exact messages in the DomU? >>> >>> >>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >>> But this is actually a PVHVM guest since debian stock kernel has PVOP >>> enabled. >>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >>> did not see such msi related error message. >>> Actually, with that domU I do not see anything obvious wrong from the >>> log, but I also see nothing from panel (panel receive no signal and go >>> power-saving) :-( >>> >>> >>> Back to the issue I was reporting, the domU log looks like this: >>> >>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >>> [drm:i915_hangcheck_ring_idle] >>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >>> 3354], missed IRQ? >>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >>> [drm:i915_hangcheck_ring_idle] >>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >>> 11297], missed IRQ? >>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >>> timeout, switching to polling mode: last cmd=0x000f0000 >>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >>> codec, disabling MSI: last cmd=0x002f0600 >>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >>> >>> >>> Thanks, >>> Timothy >>> >> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >> fixes this. I'm not fully clued up to what the policy for backporting >> fixes are, and I haven't looked at the complexity of the fix itself, but >> either updating to the 4.2.0 or a (personal) backport sounds like the >> right solution here. >> > I had a quick look, and it doesn't look that hard to backport that patch. > > -- > Mats > > >> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >> to your original email. >> >> -- >> Mats >> >> ______________________________**_________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> >> >> > > ______________________________**_________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > --90e6ba6e8e203b79bb04cffe2a08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I had a quick look, and it doesn't look that hard to backport that= patch.

Thanks, Mat.
I'm glad to report that the patch do fix= my problem.

And yest it is really easy to port since the code did n= ot change across the two release.
The only change would be line numbers (3841 vs 3803) and one extra comments= before this line:
 static int pt_msix_update_one(struct pt_dev *de=
v, int entry_nr)
I'm not sure if you are going to release another = maintenance version that include this patch,
but I'll report this to Debain maintainer since it's about to freez= e for v7.0 release and v4.2.0 will not make it.



On Mon, Dec 3, 2012 at 9:58 PM, M= ats Petersson <mats.petersson@citrix.com> wrote:
On 0= 3/12/12 13:19, Mats Petersson wrote:
On 03/12/12 13:14, G.R. wrote:
On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson
<mats.pet= ersson@citrix.com <mailto:mats.petersson@citrix.com>> wrote:
=A0 =A0 =A0On 03/12/12 03:47, G.R. wrote:

=A0 =A0 =A0 =A0 =A0Hi developers,
=A0 =A0 =A0 =A0 =A0I met some domU issues and the log suggests missing inte= rrupt.
=A0 =A0 =A0 =A0 =A0Details from here:
=A0 =A0 =A0 =A0 =A0http://www.gossamer-threads.com/= lists/xen/users/263938#263938
=A0 =A0 =A0 =A0 =A0In summary, this is the suspicious log:

=A0 =A0 =A0 =A0 =A0(XEN) vmsi.c:122:d32767 Unsupported delivery mode 3

=A0 =A0 =A0 =A0 =A0I've checked the code in question and found that mod= e 3 is an
=A0 =A0 =A0 =A0 =A0'reserved_1' mode.
=A0 =A0 =A0 =A0 =A0I want to trace down the source of this mode setting to<= br> =A0 =A0 =A0 =A0 =A0root-cause the issue.
=A0 =A0 =A0 =A0 =A0But I'm not an xen developer, and am even a newbie a= s a xen user.
=A0 =A0 =A0 =A0 =A0Could anybody give me instructions about how to enable =A0 =A0 =A0 =A0 =A0detailed debug log?
=A0 =A0 =A0 =A0 =A0It could be better if I can get advice about experiments= to
=A0 =A0 =A0 =A0 =A0perform / switches to try out etc.

=A0 =A0 =A0 =A0 =A0My SW config:
=A0 =A0 =A0 =A0 =A0dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-= 4)
=A0 =A0 =A0 =A0 =A0domU: Debian wheezy 3.2.x stock kernel.

=A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0Timothy

=A0 =A0 =A0Are you passing hardware (PCI Passthrough) to the HVM guest?
=A0 =A0 =A0What are the exact messages in the DomU?


Yes, I'm doing PCI passthrough (the IGD, audio && USB controlle= r).
But this is actually a PVHVM guest since debian stock kernel has PVOP
enabled.
And when I tried another PVOP disabled linux distro (openelec v2.0), I
did not see such msi related error message.
Actually, with that domU I do not see anything obvious wrong from the
log, but I also see nothing from panel (panel receive no signal and go
power-saving) :-(


Back to the issue I was reporting, the domU log looks like this:

Dec 2 21:52:44 debvm kernel: [ 1085.604071]
[drm:i915_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at
3354], missed IRQ?
Dec 2 21:56:50 debvm kernel: [ 1332.076071]
[drm:i915_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at 11297], missed IRQ?
Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response
timeout, switching to polling mode: last cmd=3D0x000f0000
Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from
codec, disabling MSI: last cmd=3D0x002f0600
Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response
timeout, switching to single_cmd mode: last cmd=3D0x002f0600


Thanks,
Timothy
It does sound like there is a fix in 4.2.0, as indicated by Jan, that
fixes this. I'm not fully clued up to what the policy for backporting fixes are, and I haven't looked at the complexity of the fix itself, bu= t
either updating to the 4.2.0 or a (personal) backport sounds like the
right solution here.
I had a quick look, and it doesn't look that hard to backport that patc= h.

--
Mats


Unfortunately, I hadn't seen Jan's reply by the time I wrote my res= ponse
to your original email.

--
Mats

_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel

--90e6ba6e8e203b79bb04cffe2a08-- --===============6508738499468714629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6508738499468714629==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Tue, 4 Dec 2012 11:12:19 +0800 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2009236113536242055==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mats Petersson Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============2009236113536242055== Content-Type: multipart/alternative; boundary=14dae93411e9e08a6604cffe3b8e --14dae93411e9e08a6604cffe3b8e Content-Type: text/plain; charset=ISO-8859-1 PS: I got one more question about the patch: Will it make any difference for pure HVM guest? I also observed issues for win 7 (BSOD after intel display driver installed) and openelec 2.0 ( linux 3.2 based with pvops disabled, panel report no-signal). And I haven't got chance to try them out with that patch. On Tue, Dec 4, 2012 at 11:07 AM, G.R. wrote: > > I had a quick look, and it doesn't look that hard to backport that patch. > > Thanks, Mat. > I'm glad to report that the patch do fix my problem. > > And yest it is really easy to port since the code did not change across > the two release. > The only change would be line numbers (3841 vs 3803) and one extra > comments before this line: > > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > > I'm not sure if you are going to release another maintenance version that > include this patch, > but I'll report this to Debain maintainer since it's about to freeze for > v7.0 release and v4.2.0 will not make it. > > > > > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson wrote: > >> On 03/12/12 13:19, Mats Petersson wrote: >> >>> On 03/12/12 13:14, G.R. wrote: >>> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >>>> >> >>>> wrote: >>>> >>>> On 03/12/12 03:47, G.R. wrote: >>>> >>>> Hi developers, >>>> I met some domU issues and the log suggests missing interrupt. >>>> Details from here: >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >>>> 263938 >>>> In summary, this is the suspicious log: >>>> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >>>> >>>> I've checked the code in question and found that mode 3 is an >>>> 'reserved_1' mode. >>>> I want to trace down the source of this mode setting to >>>> root-cause the issue. >>>> But I'm not an xen developer, and am even a newbie as a xen >>>> user. >>>> Could anybody give me instructions about how to enable >>>> detailed debug log? >>>> It could be better if I can get advice about experiments to >>>> perform / switches to try out etc. >>>> >>>> My SW config: >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >>>> domU: Debian wheezy 3.2.x stock kernel. >>>> >>>> Thanks, >>>> Timothy >>>> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >>>> What are the exact messages in the DomU? >>>> >>>> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >>>> enabled. >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >>>> did not see such msi related error message. >>>> Actually, with that domU I do not see anything obvious wrong from the >>>> log, but I also see nothing from panel (panel receive no signal and go >>>> power-saving) :-( >>>> >>>> >>>> Back to the issue I was reporting, the domU log looks like this: >>>> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >>>> [drm:i915_hangcheck_ring_idle] >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >>>> 3354], missed IRQ? >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >>>> [drm:i915_hangcheck_ring_idle] >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, >>>> at >>>> 11297], missed IRQ? >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >>>> timeout, switching to polling mode: last cmd=0x000f0000 >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >>>> codec, disabling MSI: last cmd=0x002f0600 >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >>>> >>>> >>>> Thanks, >>>> Timothy >>>> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >>> fixes this. I'm not fully clued up to what the policy for backporting >>> fixes are, and I haven't looked at the complexity of the fix itself, but >>> either updating to the 4.2.0 or a (personal) backport sounds like the >>> right solution here. >>> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> -- >> Mats >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >>> to your original email. >>> >>> -- >>> Mats >>> >>> ______________________________**_________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> >>> >>> >> >> ______________________________**_________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> > > --14dae93411e9e08a6604cffe3b8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PS: I got one more question about the patch:
Will it make any difference= for pure HVM guest?
I also observed issues for win 7 (BSOD after intel = display driver installed) and openelec 2.0 ( linux 3.2 based with pvops dis= abled, panel report no-signal).
And I haven't got chance to try them out with that patch.


On Tue, Dec 4, 2012 at = 11:07 AM, G.R. <firemeteor@users.sourceforge.net> wrote:
> I had a quick look, a= nd it doesn't look that hard to backport that patch.

Thank= s, Mat.
I'm glad to report that the patch do fix my problem.

And yest it= is really easy to port since the code did not change across the two releas= e.
The only change would be line numbers (3841 vs 3803) and one extra comments= before this line:
 static int pt_msix_update_one(struct pt_dev *de=
v, int entry_nr)
I'm not sure if you are going to release another = maintenance version that include this patch,
but I'll report this to Debain maintainer since it's about to freez= e for v7.0 release and v4.2.0 will not make it.




On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson <mats.petersson@cit= rix.com> wrote:
On 03/12/12 13:19, Mats Petersson = wrote:
On 03/12/12 13:14, G.R. wrote:
On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson
<mats.pet= ersson@citrix.com <mailto:mats.petersson@citrix.com>> wrote:
=A0 =A0 =A0On 03/12/12 03:47, G.R. wrote:

=A0 =A0 =A0 =A0 =A0Hi developers,
=A0 =A0 =A0 =A0 =A0I met some domU issues and the log suggests missing inte= rrupt.
=A0 =A0 =A0 =A0 =A0Details from here:
=A0 =A0 =A0 =A0 =A0http://www.gossamer-threads.com/= lists/xen/users/263938#263938
=A0 =A0 =A0 =A0 =A0In summary, this is the suspicious log:

=A0 =A0 =A0 =A0 =A0(XEN) vmsi.c:122:d32767 Unsupported delivery mode 3

=A0 =A0 =A0 =A0 =A0I've checked the code in question and found that mod= e 3 is an
=A0 =A0 =A0 =A0 =A0'reserved_1' mode.
=A0 =A0 =A0 =A0 =A0I want to trace down the source of this mode setting to<= br> =A0 =A0 =A0 =A0 =A0root-cause the issue.
=A0 =A0 =A0 =A0 =A0But I'm not an xen developer, and am even a newbie a= s a xen user.
=A0 =A0 =A0 =A0 =A0Could anybody give me instructions about how to enable =A0 =A0 =A0 =A0 =A0detailed debug log?
=A0 =A0 =A0 =A0 =A0It could be better if I can get advice about experiments= to
=A0 =A0 =A0 =A0 =A0perform / switches to try out etc.

=A0 =A0 =A0 =A0 =A0My SW config:
=A0 =A0 =A0 =A0 =A0dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-= 4)
=A0 =A0 =A0 =A0 =A0domU: Debian wheezy 3.2.x stock kernel.

=A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0Timothy

=A0 =A0 =A0Are you passing hardware (PCI Passthrough) to the HVM guest?
=A0 =A0 =A0What are the exact messages in the DomU?


Yes, I'm doing PCI passthrough (the IGD, audio && USB controlle= r).
But this is actually a PVHVM guest since debian stock kernel has PVOP
enabled.
And when I tried another PVOP disabled linux distro (openelec v2.0), I
did not see such msi related error message.
Actually, with that domU I do not see anything obvious wrong from the
log, but I also see nothing from panel (panel receive no signal and go
power-saving) :-(


Back to the issue I was reporting, the domU log looks like this:

Dec 2 21:52:44 debvm kernel: [ 1085.604071]
[drm:i915_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at
3354], missed IRQ?
Dec 2 21:56:50 debvm kernel: [ 1332.076071]
[drm:i915_hangcheck_ring_idle]
*ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at 11297], missed IRQ?
Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response
timeout, switching to polling mode: last cmd=3D0x000f0000
Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from
codec, disabling MSI: last cmd=3D0x002f0600
Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response
timeout, switching to single_cmd mode: last cmd=3D0x002f0600


Thanks,
Timothy
It does sound like there is a fix in 4.2.0, as indicated by Jan, that
fixes this. I'm not fully clued up to what the policy for backporting fixes are, and I haven't looked at the complexity of the fix itself, bu= t
either updating to the 4.2.0 or a (personal) backport sounds like the
right solution here.
I had a quick look, and it doesn't look that hard to backport that patc= h.

--
Mats


Unfortunately, I hadn't seen Jan's reply by the time I wrote my res= ponse
to your original email.

--
Mats

_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel


--14dae93411e9e08a6604cffe3b8e-- --===============2009236113536242055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2009236113536242055==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Issue about domU missing interrupt Date: Tue, 04 Dec 2012 10:15:58 +0000 Message-ID: <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson , Stefano Stabellini Cc: Mats Petersson , "G.R." , xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 04.12.12 at 04:07, "G.R." wrote: >> I had a quick look, and it doesn't look that hard to backport that patch. > > Thanks, Mat. > I'm glad to report that the patch do fix my problem. > > And yest it is really easy to port since the code did not change across the > two release. > The only change would be line numbers (3841 vs 3803) and one extra comments > before this line: > > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > > I'm not sure if you are going to release another maintenance version that > include this patch, > but I'll report this to Debain maintainer since it's about to freeze for > v7.0 release and v4.2.0 will not make it. Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is out? Jan > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson > wrote: > >> On 03/12/12 13:19, Mats Petersson wrote: >> >>> On 03/12/12 13:14, G.R. wrote: >>> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >>>> >> >>>> wrote: >>>> >>>> On 03/12/12 03:47, G.R. wrote: >>>> >>>> Hi developers, >>>> I met some domU issues and the log suggests missing interrupt. >>>> Details from here: >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >>>> 263938 >>>> In summary, this is the suspicious log: >>>> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >>>> >>>> I've checked the code in question and found that mode 3 is an >>>> 'reserved_1' mode. >>>> I want to trace down the source of this mode setting to >>>> root-cause the issue. >>>> But I'm not an xen developer, and am even a newbie as a xen >>>> user. >>>> Could anybody give me instructions about how to enable >>>> detailed debug log? >>>> It could be better if I can get advice about experiments to >>>> perform / switches to try out etc. >>>> >>>> My SW config: >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >>>> domU: Debian wheezy 3.2.x stock kernel. >>>> >>>> Thanks, >>>> Timothy >>>> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >>>> What are the exact messages in the DomU? >>>> >>>> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >>>> enabled. >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >>>> did not see such msi related error message. >>>> Actually, with that domU I do not see anything obvious wrong from the >>>> log, but I also see nothing from panel (panel receive no signal and go >>>> power-saving) :-( >>>> >>>> >>>> Back to the issue I was reporting, the domU log looks like this: >>>> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >>>> [drm:i915_hangcheck_ring_idle] >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >>>> 3354], missed IRQ? >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >>>> [drm:i915_hangcheck_ring_idle] >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >>>> 11297], missed IRQ? >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >>>> timeout, switching to polling mode: last cmd=0x000f0000 >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >>>> codec, disabling MSI: last cmd=0x002f0600 >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >>>> >>>> >>>> Thanks, >>>> Timothy >>>> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >>> fixes this. I'm not fully clued up to what the policy for backporting >>> fixes are, and I haven't looked at the complexity of the fix itself, but >>> either updating to the 4.2.0 or a (personal) backport sounds like the >>> right solution here. >>> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> -- >> Mats >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >>> to your original email. >>> >>> -- >>> Mats >>> >>> ______________________________**_________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> >>> >>> >> >> ______________________________**_________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: Issue about domU missing interrupt Date: Tue, 4 Dec 2012 13:01:05 +0200 Message-ID: <20121204110105.GX8912@reaktio.net> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50BDDB6E02000078000ADA98@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 Cc: Mats Petersson , xen-devel , Ian Jackson , "G.R." , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: > >>> On 04.12.12 at 04:07, "G.R." wrote: > >> I had a quick look, and it doesn't look that hard to backport that patch. > > > > Thanks, Mat. > > I'm glad to report that the patch do fix my problem. > > > > And yest it is really easy to port since the code did not change across the > > two release. > > The only change would be line numbers (3841 vs 3803) and one extra comments > > before this line: > > > > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > > > > I'm not sure if you are going to release another maintenance version that > > include this patch, > > but I'll report this to Debain maintainer since it's about to freeze for > > v7.0 release and v4.2.0 will not make it. > > Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is > out? > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, so I'd say it should be a candidate for Xen 4.1.4. -- Pasi > Jan > > > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson > > wrote: > > > >> On 03/12/12 13:19, Mats Petersson wrote: > >> > >>> On 03/12/12 13:14, G.R. wrote: > >>> > >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson > >>>> > >> > >>>> wrote: > >>>> > >>>> On 03/12/12 03:47, G.R. wrote: > >>>> > >>>> Hi developers, > >>>> I met some domU issues and the log suggests missing interrupt. > >>>> Details from here: > >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** > >>>> 263938 > >>>> In summary, this is the suspicious log: > >>>> > >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > >>>> > >>>> I've checked the code in question and found that mode 3 is an > >>>> 'reserved_1' mode. > >>>> I want to trace down the source of this mode setting to > >>>> root-cause the issue. > >>>> But I'm not an xen developer, and am even a newbie as a xen > >>>> user. > >>>> Could anybody give me instructions about how to enable > >>>> detailed debug log? > >>>> It could be better if I can get advice about experiments to > >>>> perform / switches to try out etc. > >>>> > >>>> My SW config: > >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > >>>> domU: Debian wheezy 3.2.x stock kernel. > >>>> > >>>> Thanks, > >>>> Timothy > >>>> > >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? > >>>> What are the exact messages in the DomU? > >>>> > >>>> > >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). > >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP > >>>> enabled. > >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I > >>>> did not see such msi related error message. > >>>> Actually, with that domU I do not see anything obvious wrong from the > >>>> log, but I also see nothing from panel (panel receive no signal and go > >>>> power-saving) :-( > >>>> > >>>> > >>>> Back to the issue I was reporting, the domU log looks like this: > >>>> > >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] > >>>> [drm:i915_hangcheck_ring_idle] > >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at > >>>> 3354], missed IRQ? > >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] > >>>> [drm:i915_hangcheck_ring_idle] > >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at > >>>> 11297], missed IRQ? > >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response > >>>> timeout, switching to polling mode: last cmd=0x000f0000 > >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from > >>>> codec, disabling MSI: last cmd=0x002f0600 > >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response > >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 > >>>> > >>>> > >>>> Thanks, > >>>> Timothy > >>>> > >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that > >>> fixes this. I'm not fully clued up to what the policy for backporting > >>> fixes are, and I haven't looked at the complexity of the fix itself, but > >>> either updating to the 4.2.0 or a (personal) backport sounds like the > >>> right solution here. > >>> > >> I had a quick look, and it doesn't look that hard to backport that patch. > >> > >> -- > >> Mats > >> > >> > >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response > >>> to your original email. > >>> > >>> -- > >>> Mats > >>> > >>> ______________________________**_________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xen.org > >>> http://lists.xen.org/xen-devel > >>> > >>> > >>> > >> > >> ______________________________**_________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > >> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Tue, 4 Dec 2012 23:20:28 +0800 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8011718497973607544==" Return-path: In-Reply-To: <20121204110105.GX8912@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Mats Petersson , Stefano Stabellini , Ian Jackson , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org --===============8011718497973607544== Content-Type: multipart/alternative; boundary=14dae9340bfbea4e3b04d00867c0 --14dae9340bfbea4e3b04d00867c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 4, 2012 at 7:01 PM, Pasi K=E4rkk=E4inen wrote: > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: > > >>> On 04.12.12 at 04:07, "G.R." > wrote: > > >> I had a quick look, and it doesn't look that hard to backport that > patch. > > > > > > Thanks, Mat. > > > I'm glad to report that the patch do fix my problem. > > > > > > And yest it is really easy to port since the code did not change > across the > > > two release. > > > The only change would be line numbers (3841 vs 3803) and one extra > comments > > > before this line: > > > > > > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > > > > > > I'm not sure if you are going to release another maintenance version > that > > > include this patch, > > > but I'll report this to Debain maintainer since it's about to freeze > for > > > v7.0 release and v4.2.0 will not make it. > > > > Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is > > out? > > > > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, > so I'd say it should be a candidate for Xen 4.1.4. > > Hi, it seems that the patch has some side effect on pure HVM guest. For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled, I see such syndrome in qemu-dm-xxx.log: pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit support?? pt_pci_write_config: Internal error: Invalid write emulation return value[-1]. I/O emulator exit. The guest dies immediately after the log, I have no way to check guest kernel log. Without the patch, this guest can boot without obvious error log even the VGA passthrough does not quite work. I'll check the code to see what does these log mean... Thanks, Timothy > -- Pasi > > > Jan > > > > > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson > > > wrote: > > > > > >> On 03/12/12 13:19, Mats Petersson wrote: > > >> > > >>> On 03/12/12 13:14, G.R. wrote: > > >>> > > >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson > > >>>> > > >> > > >>>> wrote: > > >>>> > > >>>> On 03/12/12 03:47, G.R. wrote: > > >>>> > > >>>> Hi developers, > > >>>> I met some domU issues and the log suggests missing > interrupt. > > >>>> Details from here: > > >>>> http://www.gossamer-threads. > **com/lists/xen/users/263938#** > > >>>> 263938 < > http://www.gossamer-threads.com/lists/xen/users/263938#263938> > > >>>> In summary, this is the suspicious log: > > >>>> > > >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > > >>>> > > >>>> I've checked the code in question and found that mode 3 i= s > an > > >>>> 'reserved_1' mode. > > >>>> I want to trace down the source of this mode setting to > > >>>> root-cause the issue. > > >>>> But I'm not an xen developer, and am even a newbie as a x= en > > >>>> user. > > >>>> Could anybody give me instructions about how to enable > > >>>> detailed debug log? > > >>>> It could be better if I can get advice about experiments = to > > >>>> perform / switches to try out etc. > > >>>> > > >>>> My SW config: > > >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4= ) > > >>>> domU: Debian wheezy 3.2.x stock kernel. > > >>>> > > >>>> Thanks, > > >>>> Timothy > > >>>> > > >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? > > >>>> What are the exact messages in the DomU? > > >>>> > > >>>> > > >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). > > >>>> But this is actually a PVHVM guest since debian stock kernel has > PVOP > > >>>> enabled. > > >>>> And when I tried another PVOP disabled linux distro (openelec > v2.0), I > > >>>> did not see such msi related error message. > > >>>> Actually, with that domU I do not see anything obvious wrong from > the > > >>>> log, but I also see nothing from panel (panel receive no signal an= d > go > > >>>> power-saving) :-( > > >>>> > > >>>> > > >>>> Back to the issue I was reporting, the domU log looks like this: > > >>>> > > >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] > > >>>> [drm:i915_hangcheck_ring_idle] > > >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, > at > > >>>> 3354], missed IRQ? > > >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] > > >>>> [drm:i915_hangcheck_ring_idle] > > >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on > 11297, at > > >>>> 11297], missed IRQ? > > >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_respon= se > > >>>> timeout, switching to polling mode: last cmd=3D0x000f0000 > > >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response > from > > >>>> codec, disabling MSI: last cmd=3D0x002f0600 > > >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: > azx_get_response > > >>>> timeout, switching to single_cmd mode: last cmd=3D0x002f0600 > > >>>> > > >>>> > > >>>> Thanks, > > >>>> Timothy > > >>>> > > >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, th= at > > >>> fixes this. I'm not fully clued up to what the policy for backporti= ng > > >>> fixes are, and I haven't looked at the complexity of the fix itself= , > but > > >>> either updating to the 4.2.0 or a (personal) backport sounds like t= he > > >>> right solution here. > > >>> > > >> I had a quick look, and it doesn't look that hard to backport that > patch. > > >> > > >> -- > > >> Mats > > >> > > >> > > >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my > response > > >>> to your original email. > > >>> > > >>> -- > > >>> Mats > > >>> > > >>> ______________________________**_________________ > > >>> Xen-devel mailing list > > >>> Xen-devel@lists.xen.org > > >>> http://lists.xen.org/xen-devel > > >>> > > >>> > > >>> > > >> > > >> ______________________________**_________________ > > >> Xen-devel mailing list > > >> Xen-devel@lists.xen.org > > >> http://lists.xen.org/xen-devel > > >> > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > --14dae9340bfbea4e3b04d00867c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 4, 2012 a= t 7:01 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wro= te:
> >>> On 04.12.12 at 04:07, "G.R." <firemeteor@users.sourceforge.net&= gt; wrote:
> >> =A0I had a quick look, and it doesn't look that hard to b= ackport that patch.
> >
> > Thanks, Mat.
> > I'm glad to report that the patch do fix my problem.
> >
> > And yest it is really easy to port since the code did not change = across the
> > two release.
> > The only change would be line numbers (3841 vs 3803) and one extr= a comments
> > before this line:
> >
> > =A0static int pt_msix_update_one(struct pt_dev *dev, int entry_nr= )
> >
> > I'm not sure if you are going to release another maintenance = version that
> > include this patch,
> > but I'll report this to Debain maintainer since it's abou= t to freeze for
> > v7.0 release and v4.2.0 will not make it.
>
> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is
> out?
>

It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4= .1,
so I'd say it should be a candidate for Xen 4.1.4.


Hi, it seems that the patch has some side effect on pure HVM guest.For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled,= I see such syndrome in qemu-dm-xxx.log:

pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bi= t support??
pt_pci_write_config: Internal error: Invalid write emulation= return value[-1]. I/O emulator exit.

The guest dies immediately aft= er the log, I have no way to check guest kernel log.
Without the patch, this guest can boot without obvious error log even the V= GA passthrough does not quite work.
I'll check the code to see what = does these log mean...

Thanks,
Timothy
=A0
-- Pasi

> Jan
>
> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson
> > <mats.petersson@c= itrix.com>wrote:
> >
> >> On 03/12/12 13:19, Mats Petersson wrote:
> >>
> >>> On 03/12/12 13:14, G.R. wrote:
> >>>
> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson
> >>>> <mats= .petersson@citrix.com
> > <mailto:mats.peterss= on@citrix.**com<mats.pe= tersson@citrix.com>>>
> >>>> wrote:
> >>>>
> >>>> =A0 =A0 =A0On 03/12/12 03:47, G.R. wrote:
> >>>>
> >>>> =A0 =A0 =A0 =A0 =A0Hi developers,
> >>>> =A0 =A0 =A0 =A0 =A0I met some domU issues and the log= suggests missing interrupt.
> >>>> =A0 =A0 =A0 =A0 =A0Details from here:
> >>>> =A0 =A0 =A0 =A0 =A0http://www.gossamer-threads.**com/lists/xen/us= ers/263938#**
> >>>> 263938 <http://www.gossamer-threa= ds.com/lists/xen/users/263938#263938>
> >>>> =A0 =A0 =A0 =A0 =A0In summary, this is the suspicious= log:
> >>>>
> >>>> =A0 =A0 =A0 =A0 =A0(XEN) vmsi.c:122:d32767 Unsupporte= d delivery mode 3
> >>>>
> >>>> =A0 =A0 =A0 =A0 =A0I've checked the code in quest= ion and found that mode 3 is an
> >>>> =A0 =A0 =A0 =A0 =A0'reserved_1' mode.
> >>>> =A0 =A0 =A0 =A0 =A0I want to trace down the source of= this mode setting to
> >>>> =A0 =A0 =A0 =A0 =A0root-cause the issue.
> >>>> =A0 =A0 =A0 =A0 =A0But I'm not an xen developer, = and am even a newbie as a xen
> >>>> user.
> >>>> =A0 =A0 =A0 =A0 =A0Could anybody give me instructions= about how to enable
> >>>> =A0 =A0 =A0 =A0 =A0detailed debug log?
> >>>> =A0 =A0 =A0 =A0 =A0It could be better if I can get ad= vice about experiments to
> >>>> =A0 =A0 =A0 =A0 =A0perform / switches to try out etc.=
> >>>>
> >>>> =A0 =A0 =A0 =A0 =A0My SW config:
> >>>> =A0 =A0 =A0 =A0 =A0dom0: Debian wheezy (3.6 experimen= tal kernel, xen 4.1.3-4)
> >>>> =A0 =A0 =A0 =A0 =A0domU: Debian wheezy 3.2.x stock ke= rnel.
> >>>>
> >>>> =A0 =A0 =A0 =A0 =A0Thanks,
> >>>> =A0 =A0 =A0 =A0 =A0Timothy
> >>>>
> >>>> =A0 =A0 =A0Are you passing hardware (PCI Passthrough)= to the HVM guest?
> >>>> =A0 =A0 =A0What are the exact messages in the DomU? > >>>>
> >>>>
> >>>> Yes, I'm doing PCI passthrough (the IGD, audio &a= mp;& USB controller).
> >>>> But this is actually a PVHVM guest since debian stock= kernel has PVOP
> >>>> enabled.
> >>>> And when I tried another PVOP disabled linux distro (= openelec v2.0), I
> >>>> did not see such msi related error message.
> >>>> Actually, with that domU I do not see anything obviou= s wrong from the
> >>>> log, but I also see nothing from panel (panel receive= no signal and go
> >>>> power-saving) :-(
> >>>>
> >>>>
> >>>> Back to the issue I was reporting, the domU log looks= like this:
> >>>>
> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071]
> >>>> [drm:i915_hangcheck_ring_idle]
> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [wai= ting on 3354, at
> >>>> 3354], missed IRQ?
> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071]
> >>>> [drm:i915_hangcheck_ring_idle]
> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [= waiting on 11297, at
> >>>> 11297], missed IRQ?
> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: a= zx_get_response
> >>>> timeout, switching to polling mode: last cmd=3D0x000f= 0000
> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel:= No response from
> >>>> codec, disabling MSI: last cmd=3D0x002f0600
> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel:= azx_get_response
> >>>> timeout, switching to single_cmd mode: last cmd=3D0x0= 02f0600
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Timothy
> >>>>
> >>> It does sound like there is a fix in 4.2.0, as indicated = by Jan, that
> >>> fixes this. I'm not fully clued up to what the policy= for backporting
> >>> fixes are, and I haven't looked at the complexity of = the fix itself, but
> >>> either updating to the 4.2.0 or a (personal) backport sou= nds like the
> >>> right solution here.
> >>>
> >> I had a quick look, and it doesn't look that hard to back= port that patch.
> >>
> >> --
> >> Mats
> >>
> >>
> >>> Unfortunately, I hadn't seen Jan's reply by the t= ime I wrote my response
> >>> to your original email.
> >>>
> >>> --
> >>> Mats
> >>>
> >>> ______________________________**_________________
> >>> Xen-devel mailing list
> >>> Xen-devel@list= s.xen.org
> >>> http://lists.xen.org/xen-devel
> >>>
> >>>
> >>>
> >>
> >> ______________________________**_________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xe= n.org
> >> = http://lists.xen.org/xen-devel
> >>
>
>
>
> _______________________________________________
_______________________________________________

--14dae9340bfbea4e3b04d00867c0-- --===============8011718497973607544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8011718497973607544==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 00:05:39 +0100 Message-ID: <28369388.20121205000539@eikelenboom.it> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121204110105.GX8912@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?utf-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= Cc: Stefano Stabellini , Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org Tuesday, December 4, 2012, 12:01:05 PM, you wrote: > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: >> >>> On 04.12.12 at 04:07, "G.R." wrote: >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> > >> > Thanks, Mat. >> > I'm glad to report that the patch do fix my problem. >> > >> > And yest it is really easy to port since the code did not change across the >> > two release. >> > The only change would be line numbers (3841 vs 3803) and one extra comments >> > before this line: >> > >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) >> > >> > I'm not sure if you are going to release another maintenance version that >> > include this patch, >> > but I'll report this to Debain maintainer since it's about to freeze for >> > v7.0 release and v4.2.0 will not make it. >> >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is >> out? >> > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, > so I'd say it should be a candidate for Xen 4.1.4. Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. -- Sander > -- Pasi >> Jan >> >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson >> > wrote: >> > >> >> On 03/12/12 13:19, Mats Petersson wrote: >> >> >> >>> On 03/12/12 13:14, G.R. wrote: >> >>> >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >> >>>> > > >> >> >>>> wrote: >> >>>> >> >>>> On 03/12/12 03:47, G.R. wrote: >> >>>> >> >>>> Hi developers, >> >>>> I met some domU issues and the log suggests missing interrupt. >> >>>> Details from here: >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >> >>>> 263938 >> >>>> In summary, this is the suspicious log: >> >>>> >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >>>> >> >>>> I've checked the code in question and found that mode 3 is an >> >>>> 'reserved_1' mode. >> >>>> I want to trace down the source of this mode setting to >> >>>> root-cause the issue. >> >>>> But I'm not an xen developer, and am even a newbie as a xen >> >>>> user. >> >>>> Could anybody give me instructions about how to enable >> >>>> detailed debug log? >> >>>> It could be better if I can get advice about experiments to >> >>>> perform / switches to try out etc. >> >>>> >> >>>> My SW config: >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> >>>> domU: Debian wheezy 3.2.x stock kernel. >> >>>> >> >>>> Thanks, >> >>>> Timothy >> >>>> >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >> >>>> What are the exact messages in the DomU? >> >>>> >> >>>> >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >> >>>> enabled. >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >> >>>> did not see such msi related error message. >> >>>> Actually, with that domU I do not see anything obvious wrong from the >> >>>> log, but I also see nothing from panel (panel receive no signal and go >> >>>> power-saving) :-( >> >>>> >> >>>> >> >>>> Back to the issue I was reporting, the domU log looks like this: >> >>>> >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >> >>>> [drm:i915_hangcheck_ring_idle] >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >> >>>> 3354], missed IRQ? >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >> >>>> [drm:i915_hangcheck_ring_idle] >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >> >>>> 11297], missed IRQ? >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >> >>>> codec, disabling MSI: last cmd=0x002f0600 >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Timothy >> >>>> >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >> >>> fixes this. I'm not fully clued up to what the policy for backporting >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the >> >>> right solution here. >> >>> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> >> -- >> >> Mats >> >> >> >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >> >>> to your original email. >> >>> >> >>> -- >> >>> Mats >> >>> >> >>> ______________________________**_________________ >> >>> Xen-devel mailing list >> >>> Xen-devel@lists.xen.org >> >>> http://lists.xen.org/xen-devel >> >>> >> >>> >> >>> >> >> >> >> ______________________________**_________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xen.org >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 11:51:13 +0000 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <28369388.20121205000539@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Stefano Stabellini , Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org On Tue, 4 Dec 2012, Sander Eikelenboom wrote: > Tuesday, December 4, 2012, 12:01:05 PM, you wrote: > > > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: > >> >>> On 04.12.12 at 04:07, "G.R." wrote: > >> >> I had a quick look, and it doesn't look that hard to backport that patch. > >> > > >> > Thanks, Mat. > >> > I'm glad to report that the patch do fix my problem. > >> > > >> > And yest it is really easy to port since the code did not change across the > >> > two release. > >> > The only change would be line numbers (3841 vs 3803) and one extra comments > >> > before this line: > >> > > >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > >> > > >> > I'm not sure if you are going to release another maintenance version that > >> > include this patch, > >> > but I'll report this to Debain maintainer since it's about to freeze for > >> > v7.0 release and v4.2.0 will not make it. > >> > >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is > >> out? > >> > > > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, > > so I'd say it should be a candidate for Xen 4.1.4. > > Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. > (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 > > Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. > The patch is supposed to fix a bug affecting msi_translate but in upstream QEMU we haven't implemented msi_translate at all! So in this case the cause of the bug (and as a consequence the fix) must be a different one. > Sander > > > -- Pasi > > >> Jan > >> > >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson > >> > wrote: > >> > > >> >> On 03/12/12 13:19, Mats Petersson wrote: > >> >> > >> >>> On 03/12/12 13:14, G.R. wrote: > >> >>> > >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson > >> >>>> >> > >> > >> >>>> wrote: > >> >>>> > >> >>>> On 03/12/12 03:47, G.R. wrote: > >> >>>> > >> >>>> Hi developers, > >> >>>> I met some domU issues and the log suggests missing interrupt. > >> >>>> Details from here: > >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** > >> >>>> 263938 > >> >>>> In summary, this is the suspicious log: > >> >>>> > >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > >> >>>> > >> >>>> I've checked the code in question and found that mode 3 is an > >> >>>> 'reserved_1' mode. > >> >>>> I want to trace down the source of this mode setting to > >> >>>> root-cause the issue. > >> >>>> But I'm not an xen developer, and am even a newbie as a xen > >> >>>> user. > >> >>>> Could anybody give me instructions about how to enable > >> >>>> detailed debug log? > >> >>>> It could be better if I can get advice about experiments to > >> >>>> perform / switches to try out etc. > >> >>>> > >> >>>> My SW config: > >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > >> >>>> domU: Debian wheezy 3.2.x stock kernel. > >> >>>> > >> >>>> Thanks, > >> >>>> Timothy > >> >>>> > >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? > >> >>>> What are the exact messages in the DomU? > >> >>>> > >> >>>> > >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). > >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP > >> >>>> enabled. > >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I > >> >>>> did not see such msi related error message. > >> >>>> Actually, with that domU I do not see anything obvious wrong from the > >> >>>> log, but I also see nothing from panel (panel receive no signal and go > >> >>>> power-saving) :-( > >> >>>> > >> >>>> > >> >>>> Back to the issue I was reporting, the domU log looks like this: > >> >>>> > >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] > >> >>>> [drm:i915_hangcheck_ring_idle] > >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at > >> >>>> 3354], missed IRQ? > >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] > >> >>>> [drm:i915_hangcheck_ring_idle] > >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at > >> >>>> 11297], missed IRQ? > >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response > >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 > >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from > >> >>>> codec, disabling MSI: last cmd=0x002f0600 > >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response > >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 > >> >>>> > >> >>>> > >> >>>> Thanks, > >> >>>> Timothy > >> >>>> > >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that > >> >>> fixes this. I'm not fully clued up to what the policy for backporting > >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but > >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the > >> >>> right solution here. > >> >>> > >> >> I had a quick look, and it doesn't look that hard to backport that patch. > >> >> > >> >> -- > >> >> Mats > >> >> > >> >> > >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response > >> >>> to your original email. > >> >>> > >> >>> -- > >> >>> Mats > >> >>> > >> >>> ______________________________**_________________ > >> >>> Xen-devel mailing list > >> >>> Xen-devel@lists.xen.org > >> >>> http://lists.xen.org/xen-devel > >> >>> > >> >>> > >> >>> > >> >> > >> >> ______________________________**_________________ > >> >> Xen-devel mailing list > >> >> Xen-devel@lists.xen.org > >> >> http://lists.xen.org/xen-devel > >> >> > >> > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 13:02:22 +0100 Message-ID: <1662073313.20121205130222@eikelenboom.it> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org Wednesday, December 5, 2012, 12:51:13 PM, you wrote: > On Tue, 4 Dec 2012, Sander Eikelenboom wrote: >> Tuesday, December 4, 2012, 12:01:05 PM, you wrote: >> >> > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: >> >> >>> On 04.12.12 at 04:07, "G.R." wrote: >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> > >> >> > Thanks, Mat. >> >> > I'm glad to report that the patch do fix my problem. >> >> > >> >> > And yest it is really easy to port since the code did not change across the >> >> > two release. >> >> > The only change would be line numbers (3841 vs 3803) and one extra comments >> >> > before this line: >> >> > >> >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) >> >> > >> >> > I'm not sure if you are going to release another maintenance version that >> >> > include this patch, >> >> > but I'll report this to Debain maintainer since it's about to freeze for >> >> > v7.0 release and v4.2.0 will not make it. >> >> >> >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is >> >> out? >> >> >> >> > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, >> > so I'd say it should be a candidate for Xen 4.1.4. >> >> Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. >> (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 >> >> Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. >> > The patch is supposed to fix a bug affecting msi_translate but in > upstream QEMU we haven't implemented msi_translate at all! So in this > case the cause of the bug (and as a consequence the fix) must be a > different one. Ok will see if i can find out what is going on. Probably have to force msi_translate=0. I noticed "qemu-xen" doesn't make a log file in /var/log/xen as "qemu-dm" does, is this expected ? >> Sander >> >> > -- Pasi >> >> >> Jan >> >> >> >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson >> >> > wrote: >> >> > >> >> >> On 03/12/12 13:19, Mats Petersson wrote: >> >> >> >> >> >>> On 03/12/12 13:14, G.R. wrote: >> >> >>> >> >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >> >> >>>> > >> > >> >> >> >>>> wrote: >> >> >>>> >> >> >>>> On 03/12/12 03:47, G.R. wrote: >> >> >>>> >> >> >>>> Hi developers, >> >> >>>> I met some domU issues and the log suggests missing interrupt. >> >> >>>> Details from here: >> >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >> >> >>>> 263938 >> >> >>>> In summary, this is the suspicious log: >> >> >>>> >> >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >> >>>> >> >> >>>> I've checked the code in question and found that mode 3 is an >> >> >>>> 'reserved_1' mode. >> >> >>>> I want to trace down the source of this mode setting to >> >> >>>> root-cause the issue. >> >> >>>> But I'm not an xen developer, and am even a newbie as a xen >> >> >>>> user. >> >> >>>> Could anybody give me instructions about how to enable >> >> >>>> detailed debug log? >> >> >>>> It could be better if I can get advice about experiments to >> >> >>>> perform / switches to try out etc. >> >> >>>> >> >> >>>> My SW config: >> >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> >> >>>> domU: Debian wheezy 3.2.x stock kernel. >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Timothy >> >> >>>> >> >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >> >> >>>> What are the exact messages in the DomU? >> >> >>>> >> >> >>>> >> >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >> >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >> >> >>>> enabled. >> >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >> >> >>>> did not see such msi related error message. >> >> >>>> Actually, with that domU I do not see anything obvious wrong from the >> >> >>>> log, but I also see nothing from panel (panel receive no signal and go >> >> >>>> power-saving) :-( >> >> >>>> >> >> >>>> >> >> >>>> Back to the issue I was reporting, the domU log looks like this: >> >> >>>> >> >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >> >> >>>> 3354], missed IRQ? >> >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >> >> >>>> 11297], missed IRQ? >> >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >> >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 >> >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >> >> >>>> codec, disabling MSI: last cmd=0x002f0600 >> >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >> >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >> >> >>>> >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Timothy >> >> >>>> >> >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >> >> >>> fixes this. I'm not fully clued up to what the policy for backporting >> >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but >> >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the >> >> >>> right solution here. >> >> >>> >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> >> >> >> -- >> >> >> Mats >> >> >> >> >> >> >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >> >> >>> to your original email. >> >> >>> >> >> >>> -- >> >> >>> Mats >> >> >>> >> >> >>> ______________________________**_________________ >> >> >>> Xen-devel mailing list >> >> >>> Xen-devel@lists.xen.org >> >> >>> http://lists.xen.org/xen-devel >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> ______________________________**_________________ >> >> >> Xen-devel mailing list >> >> >> Xen-devel@lists.xen.org >> >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xen.org >> >> http://lists.xen.org/xen-devel >> >> >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 12:07:07 +0000 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> <1662073313.20121205130222@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1662073313.20121205130222@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Stefano Stabellini , Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org On Wed, 5 Dec 2012, Sander Eikelenboom wrote: > Wednesday, December 5, 2012, 12:51:13 PM, you wrote: > > > On Tue, 4 Dec 2012, Sander Eikelenboom wrote: > >> Tuesday, December 4, 2012, 12:01:05 PM, you wrote: > >> > >> > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: > >> >> >>> On 04.12.12 at 04:07, "G.R." wrote: > >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. > >> >> > > >> >> > Thanks, Mat. > >> >> > I'm glad to report that the patch do fix my problem. > >> >> > > >> >> > And yest it is really easy to port since the code did not change across the > >> >> > two release. > >> >> > The only change would be line numbers (3841 vs 3803) and one extra comments > >> >> > before this line: > >> >> > > >> >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > >> >> > > >> >> > I'm not sure if you are going to release another maintenance version that > >> >> > include this patch, > >> >> > but I'll report this to Debain maintainer since it's about to freeze for > >> >> > v7.0 release and v4.2.0 will not make it. > >> >> > >> >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is > >> >> out? > >> >> > >> > >> > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, > >> > so I'd say it should be a candidate for Xen 4.1.4. > >> > >> Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. > >> (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 > >> > >> Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. > >> > > > The patch is supposed to fix a bug affecting msi_translate but in > > upstream QEMU we haven't implemented msi_translate at all! So in this > > case the cause of the bug (and as a consequence the fix) must be a > > different one. > > Ok will see if i can find out what is going on. Probably have to force msi_translate=0. > > I noticed "qemu-xen" doesn't make a log file in /var/log/xen as "qemu-dm" does, is this expected ? No, it is not. You should get the usual /var/log/xen/qemu-dm-domainname.log file. > >> Sander > >> > >> > -- Pasi > >> > >> >> Jan > >> >> > >> >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson > >> >> > wrote: > >> >> > > >> >> >> On 03/12/12 13:19, Mats Petersson wrote: > >> >> >> > >> >> >>> On 03/12/12 13:14, G.R. wrote: > >> >> >>> > >> >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson > >> >> >>>> >> >> > >> > >> >> >>>> wrote: > >> >> >>>> > >> >> >>>> On 03/12/12 03:47, G.R. wrote: > >> >> >>>> > >> >> >>>> Hi developers, > >> >> >>>> I met some domU issues and the log suggests missing interrupt. > >> >> >>>> Details from here: > >> >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** > >> >> >>>> 263938 > >> >> >>>> In summary, this is the suspicious log: > >> >> >>>> > >> >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 > >> >> >>>> > >> >> >>>> I've checked the code in question and found that mode 3 is an > >> >> >>>> 'reserved_1' mode. > >> >> >>>> I want to trace down the source of this mode setting to > >> >> >>>> root-cause the issue. > >> >> >>>> But I'm not an xen developer, and am even a newbie as a xen > >> >> >>>> user. > >> >> >>>> Could anybody give me instructions about how to enable > >> >> >>>> detailed debug log? > >> >> >>>> It could be better if I can get advice about experiments to > >> >> >>>> perform / switches to try out etc. > >> >> >>>> > >> >> >>>> My SW config: > >> >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) > >> >> >>>> domU: Debian wheezy 3.2.x stock kernel. > >> >> >>>> > >> >> >>>> Thanks, > >> >> >>>> Timothy > >> >> >>>> > >> >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? > >> >> >>>> What are the exact messages in the DomU? > >> >> >>>> > >> >> >>>> > >> >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). > >> >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP > >> >> >>>> enabled. > >> >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I > >> >> >>>> did not see such msi related error message. > >> >> >>>> Actually, with that domU I do not see anything obvious wrong from the > >> >> >>>> log, but I also see nothing from panel (panel receive no signal and go > >> >> >>>> power-saving) :-( > >> >> >>>> > >> >> >>>> > >> >> >>>> Back to the issue I was reporting, the domU log looks like this: > >> >> >>>> > >> >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] > >> >> >>>> [drm:i915_hangcheck_ring_idle] > >> >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at > >> >> >>>> 3354], missed IRQ? > >> >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] > >> >> >>>> [drm:i915_hangcheck_ring_idle] > >> >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at > >> >> >>>> 11297], missed IRQ? > >> >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response > >> >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 > >> >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from > >> >> >>>> codec, disabling MSI: last cmd=0x002f0600 > >> >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response > >> >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 > >> >> >>>> > >> >> >>>> > >> >> >>>> Thanks, > >> >> >>>> Timothy > >> >> >>>> > >> >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that > >> >> >>> fixes this. I'm not fully clued up to what the policy for backporting > >> >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but > >> >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the > >> >> >>> right solution here. > >> >> >>> > >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. > >> >> >> > >> >> >> -- > >> >> >> Mats > >> >> >> > >> >> >> > >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response > >> >> >>> to your original email. > >> >> >>> > >> >> >>> -- > >> >> >>> Mats > >> >> >>> > >> >> >>> ______________________________**_________________ > >> >> >>> Xen-devel mailing list > >> >> >>> Xen-devel@lists.xen.org > >> >> >>> http://lists.xen.org/xen-devel > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> ______________________________**_________________ > >> >> >> Xen-devel mailing list > >> >> >> Xen-devel@lists.xen.org > >> >> >> http://lists.xen.org/xen-devel > >> >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Xen-devel mailing list > >> >> Xen-devel@lists.xen.org > >> >> http://lists.xen.org/xen-devel > >> > >> > >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 13:11:28 +0100 Message-ID: <182397271.20121205131128@eikelenboom.it> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> <1662073313.20121205130222@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org Wednesday, December 5, 2012, 1:07:07 PM, you wrote: > On Wed, 5 Dec 2012, Sander Eikelenboom wrote: >> Wednesday, December 5, 2012, 12:51:13 PM, you wrote: >> >> > On Tue, 4 Dec 2012, Sander Eikelenboom wrote: >> >> Tuesday, December 4, 2012, 12:01:05 PM, you wrote: >> >> >> >> > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: >> >> >> >>> On 04.12.12 at 04:07, "G.R." wrote: >> >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> > >> >> >> > Thanks, Mat. >> >> >> > I'm glad to report that the patch do fix my problem. >> >> >> > >> >> >> > And yest it is really easy to port since the code did not change across the >> >> >> > two release. >> >> >> > The only change would be line numbers (3841 vs 3803) and one extra comments >> >> >> > before this line: >> >> >> > >> >> >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) >> >> >> > >> >> >> > I'm not sure if you are going to release another maintenance version that >> >> >> > include this patch, >> >> >> > but I'll report this to Debain maintainer since it's about to freeze for >> >> >> > v7.0 release and v4.2.0 will not make it. >> >> >> >> >> >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is >> >> >> out? >> >> >> >> >> >> >> > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, >> >> > so I'd say it should be a candidate for Xen 4.1.4. >> >> >> >> Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. >> >> (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 >> >> >> >> Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. >> >> >> >> > The patch is supposed to fix a bug affecting msi_translate but in >> > upstream QEMU we haven't implemented msi_translate at all! So in this >> > case the cause of the bug (and as a consequence the fix) must be a >> > different one. >> >> Ok will see if i can find out what is going on. Probably have to force msi_translate=0. >> >> I noticed "qemu-xen" doesn't make a log file in /var/log/xen as "qemu-dm" does, is this expected ? > No, it is not. You should get the usual /var/log/xen/qemu-dm-domainname.log file. OK .. i was expecting a qemu-xen-domainname, so will double check :-) Thx ! >> >> Sander >> >> >> >> > -- Pasi >> >> >> >> >> Jan >> >> >> >> >> >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson >> >> >> > wrote: >> >> >> > >> >> >> >> On 03/12/12 13:19, Mats Petersson wrote: >> >> >> >> >> >> >> >>> On 03/12/12 13:14, G.R. wrote: >> >> >> >>> >> >> >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >> >> >> >>>> > >> >> > >> >> >> >> >>>> wrote: >> >> >> >>>> >> >> >> >>>> On 03/12/12 03:47, G.R. wrote: >> >> >> >>>> >> >> >> >>>> Hi developers, >> >> >> >>>> I met some domU issues and the log suggests missing interrupt. >> >> >> >>>> Details from here: >> >> >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >> >> >> >>>> 263938 >> >> >> >>>> In summary, this is the suspicious log: >> >> >> >>>> >> >> >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >> >> >>>> >> >> >> >>>> I've checked the code in question and found that mode 3 is an >> >> >> >>>> 'reserved_1' mode. >> >> >> >>>> I want to trace down the source of this mode setting to >> >> >> >>>> root-cause the issue. >> >> >> >>>> But I'm not an xen developer, and am even a newbie as a xen >> >> >> >>>> user. >> >> >> >>>> Could anybody give me instructions about how to enable >> >> >> >>>> detailed debug log? >> >> >> >>>> It could be better if I can get advice about experiments to >> >> >> >>>> perform / switches to try out etc. >> >> >> >>>> >> >> >> >>>> My SW config: >> >> >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> >> >> >>>> domU: Debian wheezy 3.2.x stock kernel. >> >> >> >>>> >> >> >> >>>> Thanks, >> >> >> >>>> Timothy >> >> >> >>>> >> >> >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >> >> >> >>>> What are the exact messages in the DomU? >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >> >> >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >> >> >> >>>> enabled. >> >> >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >> >> >> >>>> did not see such msi related error message. >> >> >> >>>> Actually, with that domU I do not see anything obvious wrong from the >> >> >> >>>> log, but I also see nothing from panel (panel receive no signal and go >> >> >> >>>> power-saving) :-( >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Back to the issue I was reporting, the domU log looks like this: >> >> >> >>>> >> >> >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >> >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >> >> >> >>>> 3354], missed IRQ? >> >> >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >> >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >> >> >> >>>> 11297], missed IRQ? >> >> >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >> >> >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 >> >> >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >> >> >> >>>> codec, disabling MSI: last cmd=0x002f0600 >> >> >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >> >> >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Thanks, >> >> >> >>>> Timothy >> >> >> >>>> >> >> >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >> >> >> >>> fixes this. I'm not fully clued up to what the policy for backporting >> >> >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but >> >> >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the >> >> >> >>> right solution here. >> >> >> >>> >> >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> >> >> >> >> >> -- >> >> >> >> Mats >> >> >> >> >> >> >> >> >> >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >> >> >> >>> to your original email. >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Mats >> >> >> >>> >> >> >> >>> ______________________________**_________________ >> >> >> >>> Xen-devel mailing list >> >> >> >>> Xen-devel@lists.xen.org >> >> >> >>> http://lists.xen.org/xen-devel >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> ______________________________**_________________ >> >> >> >> Xen-devel mailing list >> >> >> >> Xen-devel@lists.xen.org >> >> >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Xen-devel mailing list >> >> >> Xen-devel@lists.xen.org >> >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> >> >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G.R." Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 20:58:53 +0800 Message-ID: References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8044711677056468962==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Mats Petersson , Stefano Stabellini , Ian Jackson , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org --===============8044711677056468962== Content-Type: multipart/alternative; boundary=90e6ba6e8e2070dd2804d01a8bec --90e6ba6e8e2070dd2804d01a8bec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 4, 2012 at 11:20 PM, G.R. wro= te: > On Tue, Dec 4, 2012 at 7:01 PM, Pasi K=E4rkk=E4inen wrote: > >> On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: >> > >>> On 04.12.12 at 04:07, "G.R." >> wrote: >> > >> I had a quick look, and it doesn't look that hard to backport that >> patch. >> > > >> > > Thanks, Mat. >> > > I'm glad to report that the patch do fix my problem. >> > > >> > > And yest it is really easy to port since the code did not change >> across the >> > > two release. >> > > The only change would be line numbers (3841 vs 3803) and one extra >> comments >> > > before this line: >> > > >> > > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) >> > > >> > > I'm not sure if you are going to release another maintenance version >> that >> > > include this patch, >> > > but I'll report this to Debain maintainer since it's about to freeze >> for >> > > v7.0 release and v4.2.0 will not make it. >> > >> > Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is >> > out? >> > >> >> It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, >> so I'd say it should be a candidate for Xen 4.1.4. >> >> > Hi, it seems that the patch has some side effect on pure HVM guest. > For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled, > I see such syndrome in qemu-dm-xxx.log: > > pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit > support?? > pt_pci_write_config: Internal error: Invalid write emulation return > value[-1]. I/O emulator exit. > > The guest dies immediately after the log, I have no way to check guest > kernel log. > Without the patch, this guest can boot without obvious error log even the > VGA passthrough does not quite work. > I'll check the code to see what does these log mean... > I did some analysis and it really looks like a bug to me. Since this is a patch back-ported from 4.2.0, I would like to ask is there any follow up patch that would fix this issue? Please see my analysis below: Here is part of the qemu-dm log, with debug log enabled at compile time: dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1b.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0 pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0xf7c10004) pt_msi_setup: msi mapped with pirq 36 pci_intx: intx=3D1 register_real_device: Real physical device 00:1b.0 registered successfuly! IRQ type =3D MSI-INTx ... pt_pci_read_config: [00:06.0]: address=3D0000 val=3D0x0000*8086* len=3D2 pt_pci_read_config: [00:06.0]: address=3D0002 val=3D0x0000*1e20* len=3D2 ... *pt_pci_write_config: [00:06.0]: address=3D0068* val=3D0x00000000 len=3D4 ... pt_pci_write_config: [00:06.0]: address=3D0062 val=3D0x00000081 len=3D2 *pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation* pci_intx: intx=3D1 *pt_msi_disable: Unmap msi with pirq 36* pt_msgctrl_reg_write: setup msi for dev 30 pt_msi_setup: msi mapped with pirq 36 pt_msi_update: Update msi with pirq 36 gvec 51 gflags 1303 pt_pci_read_config: [00:06.0]: address=3D0062 val=3D0x00000081 len=3D2 pt_pci_write_config: [00:06.0]: address=3D0062 val=3D0x00000081 len=3D2 pt_pci_write_config: [00:06.0]: address=3D0064 val=3D0xfee0300c len=3D4 *pt_pci_write_config: [00:06.0]: address=3D0068* val=3D0x00000000 len=3D4 pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit support?? pt_pci_write_config: Internal error: Invalid write emulation return value[-1]. I/O emulator exit. Here the device in question should is the audio controller, 00:1b.0 in the host, which is 64 bit capable: 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) Capabilities: [60] MSI: Enable+ Count=3D1/1 Maskable- 64bit+ Address: 00000000fee00378 Data: 0000 And there is also a successful write to offset 0x68 above, while the second write fails the I/O emulator. pt_disable_msi_translate is called after the pt_msgctrl_reg_write log above= : PT_LOG("guest enabling MSI-X, disable MSI-INTx translation\n"); pt_disable_msi_translate(ptdev); The patch added pt_msi_disable() call into this function, And the pt_msi_disable function has these lines: out: /* clear msi info */ dev->msi->flags =3D 0; dev->msi->pirq =3D -1; dev->msi_trans_en =3D 0; As a result, the flags are cleared -- this is new to the patch. And I believe this change caused the failure in pt_msgaddr64_write(): 3882 /* check whether the type is 64 bit or not */ 3883 if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) 3884 { 3885 /* exit I/O emulator */ 3886 PT_LOG("Error: why comes to Upper Address without 64 bit support??\n"); 3887 return -1; 3888 } I only see flags setup in pt_msgctrl_reg_init() function. I guess this is not called this time. Thanks, Timothy --90e6ba6e8e2070dd2804d01a8bec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 4, 2012 a= t 11:20 PM, G.R. <firemeteor@users.sourceforge.net><= /span> wrote:
On Tue, Dec 4, 2012 at 7:01 PM, Pasi K=E4= rkk=E4inen <pasik@iki.fi> wrote:
On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote:
> >>> On 04.12.12 at 04:07, "G.R." <firemeteor@users.so= urceforge.net> wrote:
> >> =A0I had a quick look, and it doesn't look that hard to b= ackport that patch.
> >
> > Thanks, Mat.
> > I'm glad to report that the patch do fix my problem.
> >
> > And yest it is really easy to port since the code did not change = across the
> > two release.
> > The only change would be line numbers (3841 vs 3803) and one extr= a comments
> > before this line:
> >
> > =A0static int pt_msix_update_one(struct pt_dev *dev, int entry_nr= )
> >
> > I'm not sure if you are going to release another maintenance = version that
> > include this patch,
> > but I'll report this to Debain maintainer since it's abou= t to freeze for
> > v7.0 release and v4.2.0 will not make it.
>
> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is
> out?
>

It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4= .1,
so I'd say it should be a candidate for Xen 4.1.4.

Hi, it seems that the patch has some side effect on pure HVM guest.
For= openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled, I se= e such syndrome in qemu-dm-xxx.log:

pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bi= t support??
pt_pci_write_config: Internal error: Invalid write emulation= return value[-1]. I/O emulator exit.

The guest dies immediately aft= er the log, I have no way to check guest kernel log.
Without the patch, this guest can boot without obvious error log even the V= GA passthrough does not quite work.
I'll check the code to see what = does these log mean...

I did som= e analysis and it really looks like a bug to me.
Since this is a patch back-ported from 4.2.0, I would like to ask is there = any follow up patch that would fix this issue?
Please see my analysis be= low:

Here is part of the qemu-dm log, with debug log enabled at compile time= :

dm-command: hot = insert pass-through pci dev
register_real_device: Assigning real physica= l device 00:1b.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x0:0x1b.0x0
pt_register_regions: IO region = registered (size=3D0x00004000 base_addr=3D0xf7c10004)
pt_msi_setup: msi = mapped with pirq 36
pci_intx: intx=3D1
register_real_device: Real physical device 00:1b.0 re= gistered successfuly!
IRQ type =3D MSI-INTx
...
pt_pci_read_config= : [00:06.0]: address=3D0000 val=3D0x00008086 len=3D2
pt_pci_read_= config: [00:06.0]: address=3D0002 val=3D0x00001e20 len=3D2
...
pt_pci_write_config: [00:06.0]: address=3D0068 val=3D0x000000= 00 len=3D4
...
pt_pci_write_config: [00:06.0]: address=3D0062 val=3D0= x00000081 len=3D2
pt_msgctrl_reg_write: guest enabling MSI, disable M= SI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 36
pt_m= sgctrl_reg_write: setup msi for dev 30
pt_msi_setup: msi mapped with pir= q 36
pt_msi_update: Update msi with pirq 36 gvec 51 gflags 1303
pt_pc= i_read_config: [00:06.0]: address=3D0062 val=3D0x00000081 len=3D2
pt_pci_write_config: [00:06.0]: address=3D0062 val=3D0x00000081 len=3D2
= pt_pci_write_config: [00:06.0]: address=3D0064 val=3D0xfee0300c len=3D4
= pt_pci_write_config: [00:06.0]: address=3D0068 val=3D0x00000000 len= =3D4
pt_msgaddr64_reg_write: Error: why comes to Upper Address without 6= 4 bit support??
pt_pci_write_config: Internal error: Invalid write emulation return value[-= 1]. I/O emulator exit.


Here the device in question should is th= e audio controller, 00:1b.0 in the host, which is 64 bit capable:
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family= High Definition Audio Controller (rev 04)
=A0=A0=A0 Capabilities: [60] = MSI: Enable+ Count=3D1/1 Maskable- 64bit+
=A0=A0=A0 =A0=A0=A0 Address: 0= 0000000fee00378=A0 Data: 0000

And there is also a successful write to offset 0x68 above, while the se= cond write fails the I/O emulator.

pt_disable_msi_translate is called after the pt_msgctrl_reg_write log a= bove:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PT_LOG("guest enabling MSI-= X, disable MSI-INTx translation\n");
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 pt_disable_msi_translate(ptdev);


The patch added pt_msi_disable() call into this function, And the p= t_msi_disable function has these lines:
out:
=A0=A0=A0 /* clear msi info */
=A0=A0=A0 dev-&= gt;msi->flags =3D 0;
=A0=A0=A0 dev->msi->pirq =3D -1;
=A0=A0=A0 dev->msi_trans_en = =3D 0;


As a result, the flags are cleared -- this is new to the patch.
And= I believe this change caused the failure in pt_msgaddr64_write():

<= span style=3D"font-family:courier new,monospace">3882=A0=A0=A0=A0 /* check = whether the type is 64 bit or not */
3883=A0=A0=A0=A0 if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT))<= br>3884=A0=A0=A0=A0 {
3885=A0=A0=A0=A0=A0=A0=A0=A0 /* exit I/O emulator = */
3886=A0=A0=A0=A0=A0=A0=A0=A0 PT_LOG("Error: why comes to Upper A= ddress without 64 bit support??\n");
3887=A0=A0=A0=A0=A0=A0=A0=A0 return -1;
3888=A0=A0=A0=A0 }

I only see flags setup in=A0 pt_msgctrl_reg_init() function. I guess t= his is not called this time.

Thanks,
Timothy
--90e6ba6e8e2070dd2804d01a8bec-- --===============8044711677056468962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8044711677056468962==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 16:34:01 +0100 Message-ID: <32870747.20121205163401@eikelenboom.it> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> <1662073313.20121205130222@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org Wednesday, December 5, 2012, 1:07:07 PM, you wrote: > On Wed, 5 Dec 2012, Sander Eikelenboom wrote: >> Wednesday, December 5, 2012, 12:51:13 PM, you wrote: >> >> > On Tue, 4 Dec 2012, Sander Eikelenboom wrote: >> >> Tuesday, December 4, 2012, 12:01:05 PM, you wrote: >> >> >> >> > On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote: >> >> >> >>> On 04.12.12 at 04:07, "G.R." wrote: >> >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> > >> >> >> > Thanks, Mat. >> >> >> > I'm glad to report that the patch do fix my problem. >> >> >> > >> >> >> > And yest it is really easy to port since the code did not change across the >> >> >> > two release. >> >> >> > The only change would be line numbers (3841 vs 3803) and one extra comments >> >> >> > before this line: >> >> >> > >> >> >> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) >> >> >> > >> >> >> > I'm not sure if you are going to release another maintenance version that >> >> >> > include this patch, >> >> >> > but I'll report this to Debain maintainer since it's about to freeze for >> >> >> > v7.0 release and v4.2.0 will not make it. >> >> >> >> >> >> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is >> >> >> out? >> >> >> >> >> >> >> > It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1, >> >> > so I'd say it should be a candidate for Xen 4.1.4. >> >> >> >> Just tried switching the device model to "qemu-xen", seems this one isn't upstream either. >> >> (XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3 >> >> >> >> Running xen-unstable as of today, with device-model "qemu-xen" for this hvm guest. >> >> >> >> > The patch is supposed to fix a bug affecting msi_translate but in >> > upstream QEMU we haven't implemented msi_translate at all! So in this >> > case the cause of the bug (and as a consequence the fix) must be a >> > different one. Using msi_translate=0 didn't change a thing, still got "unsupported delivery mode" and a non working passthrough device. lspci in the HVM shows MSI-X enabled for the device, but it doesn't function properly. 00:05.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Micro-Star International Co., Ltd. Device 4257 Physical Slot: 5 Flags: bus master, fast devsel, latency 0, IRQ 36 Memory at f3250000 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] #1033 Kernel driver in use: xhci_hcd Disabling MSI completly for the HVM (by using pci=nomsi for the HVM kernel) makes passthrough device work ok with normal interrupts. Looking into qemu-xen-dir/hw i do see xen-msi.c, so there seems to be work done in that area ? >> >> Ok will see if i can find out what is going on. Probably have to force msi_translate=0. >> >> I noticed "qemu-xen" doesn't make a log file in /var/log/xen as "qemu-dm" does, is this expected ? > No, it is not. You should get the usual /var/log/xen/qemu-dm-domainname.log file. You were right, all though it lacks a bit in verbosity i guess ... the only 2 lines i'm getting are: char device redirected to /dev/pts/17 Issued domain 25 poweroff Instead of the 99 lines of output when using qemu-xen-traditional. >> >> Sander >> >> >> >> > -- Pasi >> >> >> >> >> Jan >> >> >> >> >> >> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson >> >> >> > wrote: >> >> >> > >> >> >> >> On 03/12/12 13:19, Mats Petersson wrote: >> >> >> >> >> >> >> >>> On 03/12/12 13:14, G.R. wrote: >> >> >> >>> >> >> >> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson >> >> >> >>>> > >> >> > >> >> >> >> >>>> wrote: >> >> >> >>>> >> >> >> >>>> On 03/12/12 03:47, G.R. wrote: >> >> >> >>>> >> >> >> >>>> Hi developers, >> >> >> >>>> I met some domU issues and the log suggests missing interrupt. >> >> >> >>>> Details from here: >> >> >> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#** >> >> >> >>>> 263938 >> >> >> >>>> In summary, this is the suspicious log: >> >> >> >>>> >> >> >> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 >> >> >> >>>> >> >> >> >>>> I've checked the code in question and found that mode 3 is an >> >> >> >>>> 'reserved_1' mode. >> >> >> >>>> I want to trace down the source of this mode setting to >> >> >> >>>> root-cause the issue. >> >> >> >>>> But I'm not an xen developer, and am even a newbie as a xen >> >> >> >>>> user. >> >> >> >>>> Could anybody give me instructions about how to enable >> >> >> >>>> detailed debug log? >> >> >> >>>> It could be better if I can get advice about experiments to >> >> >> >>>> perform / switches to try out etc. >> >> >> >>>> >> >> >> >>>> My SW config: >> >> >> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4) >> >> >> >>>> domU: Debian wheezy 3.2.x stock kernel. >> >> >> >>>> >> >> >> >>>> Thanks, >> >> >> >>>> Timothy >> >> >> >>>> >> >> >> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest? >> >> >> >>>> What are the exact messages in the DomU? >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller). >> >> >> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP >> >> >> >>>> enabled. >> >> >> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I >> >> >> >>>> did not see such msi related error message. >> >> >> >>>> Actually, with that domU I do not see anything obvious wrong from the >> >> >> >>>> log, but I also see nothing from panel (panel receive no signal and go >> >> >> >>>> power-saving) :-( >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Back to the issue I was reporting, the domU log looks like this: >> >> >> >>>> >> >> >> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071] >> >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at >> >> >> >>>> 3354], missed IRQ? >> >> >> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071] >> >> >> >>>> [drm:i915_hangcheck_ring_idle] >> >> >> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at >> >> >> >>>> 11297], missed IRQ? >> >> >> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response >> >> >> >>>> timeout, switching to polling mode: last cmd=0x000f0000 >> >> >> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from >> >> >> >>>> codec, disabling MSI: last cmd=0x002f0600 >> >> >> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response >> >> >> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600 >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Thanks, >> >> >> >>>> Timothy >> >> >> >>>> >> >> >> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that >> >> >> >>> fixes this. I'm not fully clued up to what the policy for backporting >> >> >> >>> fixes are, and I haven't looked at the complexity of the fix itself, but >> >> >> >>> either updating to the 4.2.0 or a (personal) backport sounds like the >> >> >> >>> right solution here. >> >> >> >>> >> >> >> >> I had a quick look, and it doesn't look that hard to backport that patch. >> >> >> >> >> >> >> >> -- >> >> >> >> Mats >> >> >> >> >> >> >> >> >> >> >> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response >> >> >> >>> to your original email. >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Mats >> >> >> >>> >> >> >> >>> ______________________________**_________________ >> >> >> >>> Xen-devel mailing list >> >> >> >>> Xen-devel@lists.xen.org >> >> >> >>> http://lists.xen.org/xen-devel >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> ______________________________**_________________ >> >> >> >> Xen-devel mailing list >> >> >> >> Xen-devel@lists.xen.org >> >> >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Xen-devel mailing list >> >> >> Xen-devel@lists.xen.org >> >> >> http://lists.xen.org/xen-devel >> >> >> >> >> >> >> >>