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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Maybe you need to provide more information about your VGA device, for example, "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 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 03.12.12 at 04:47, "G.R." <firemeteor@users.sourceforge.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/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
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, > TimothyAre you passing hardware (PCI Passthrough) to the HVM guest? What are the exact messages in the DomU? -- Mats
On Mon, Dec 3, 2012 at 4:46 PM, Jan Beulich <JBeulich@suse.com> wrote:> >>> On 03.12.12 at 04:47, "G.R." <firemeteor@users.sourceforge.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/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 03.12.12 at 13:43, "G.R." <firemeteor@users.sourceforge.net> wrote: > On Mon, Dec 3, 2012 at 4:46 PM, Jan Beulich <JBeulich@suse.com> wrote: > >> >>> On 03.12.12 at 04:47, "G.R." <firemeteor@users.sourceforge.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/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
On Mon, Dec 3, 2012 at 3:06 PM, Zhang, Xiantao <xiantao.zhang@intel.com>wrote:> Maybe you need to provide more information about your VGA device, for > example, “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**** > > ** >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=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 95 Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 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=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ Latency: 64 Interrupt: pin A routed to IRQ 78 Region 0: Memory at f1000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at c100 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee33000 Data: 4300 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 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**** >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Mon, Dec 3, 2012 at 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<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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.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 > ''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, > TimothyIt 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
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.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 >> ''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 > >
> 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 <mats.petersson@citrix.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.petersson@citrix.**com<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 <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
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. <firemeteor@users.sourceforge.net>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 <mats.petersson@citrix.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.petersson@citrix.**com<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 <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
>>> On 04.12.12 at 04:07, "G.R." <firemeteor@users.sourceforge.net> 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 > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 >>
On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote:> >>> On 04.12.12 at 04:07, "G.R." <firemeteor@users.sourceforge.net> 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 > > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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
On Tue, Dec 4, 2012 at 7:01 PM, Pasi Kärkkäinen <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.sourceforge.net> > 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 > > > <mats.petersson@citrix.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.petersson@citrix.**com<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 < > 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 > > _______________________________________________ > 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
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." <firemeteor@users.sourceforge.net> 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 >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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
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." <firemeteor@users.sourceforge.net> 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 > >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 > > >
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." <firemeteor@users.sourceforge.net> 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 >> >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 >> >> >>
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." <firemeteor@users.sourceforge.net> 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 > >> >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 > >> > >> > >> > >
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." <firemeteor@users.sourceforge.net> 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 >> >> >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 >> >> >> >> >> >> >> >>
On Tue, Dec 4, 2012 at 11:20 PM, G.R. <firemeteor@users.sourceforge.net>wrote:> On Tue, Dec 4, 2012 at 7:01 PM, Pasi Kärkkäinen <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.sourceforge.net> >> 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=0x00004000 base_addr=0xf7c10004) pt_msi_setup: msi mapped with pirq 36 pci_intx: intx=1 register_real_device: Real physical device 00:1b.0 registered successfuly! IRQ type = MSI-INTx ... pt_pci_read_config: [00:06.0]: address=0000 val=0x0000*8086* len=2 pt_pci_read_config: [00:06.0]: address=0002 val=0x0000*1e20* len=2 ... *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4 ... pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2 *pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation* pci_intx: intx=1 *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=0062 val=0x00000081 len=2 pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2 pt_pci_write_config: [00:06.0]: address=0064 val=0xfee0300c len=4 *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4 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=1/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 = 0; dev->msi->pirq = -1; dev->msi_trans_en = 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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." <firemeteor@users.sourceforge.net> 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 >> >> >> > <mats.petersson@citrix.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.petersson@citrix.**com<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 <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 >> >> >> >> >> >> >> >>