Issue about domU missing interrupt

Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 779 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 937 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Zhang, Xiantao]

[-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4396 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 4545 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6949 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Jan Beulich]

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

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2161 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Jan Beulich]

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

Re: Issue about domU missing interrupt

[Mats Petersson]

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

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3148 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Mats Petersson]

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.

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

--
Mats

Re: Issue about domU missing interrupt

[Mats Petersson]

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

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 4390 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5778 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 4929 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6504 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Jan Beulich]

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

Re: Issue about domU missing interrupt

[Pasi Kärkkäinen]

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

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 6628 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 10050 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[G.R.]

[-- Attachment #1.1: Type: text/plain, Size: 5148 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6560 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Issue about domU missing interrupt

[Sander Eikelenboom]

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

Re: Issue about domU missing interrupt

[Stefano Stabellini]

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

Re: Issue about domU missing interrupt

[Sander Eikelenboom]

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

Re: Issue about domU missing interrupt

[Stefano Stabellini]

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

Re: Issue about domU missing interrupt

[Sander Eikelenboom]

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

Re: Issue about domU missing interrupt

[Sander Eikelenboom]

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