Re: Issue about domU missing interrupt

G.R.
Tue, 04 Dec 2012 03:07:23 -0000

> I had a quick look, and it doesn''t look that hard to backport that
patch.

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

And yest it is really easy to port since the code did not change across the
two release.
The only change would be line numbers (3841 vs 3803) and one extra comments
before this line:

 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)

I''m not sure if you are going to release another maintenance version
that
include this patch,
but I''ll report this to Debain maintainer since it''s about to
freeze for
v7.0 release and v4.2.0 will not make it.



On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson
<mats.petersson@citrix.com>wrote:

> On 03/12/12 13:19, Mats Petersson wrote:
>
>> On 03/12/12 13:14, G.R. wrote:
>>
>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson
>>> <mats.petersson@citrix.com
<mailto:mats.petersson@citrix.**com<mats.petersson@citrix.com>>>
>>> wrote:
>>>
>>>      On 03/12/12 03:47, G.R. wrote:
>>>
>>>          Hi developers,
>>>          I met some domU issues and the log suggests missing
interrupt.
>>>          Details from here:
>>>
http://www.gossamer-threads.**com/lists/xen/users/263938#**
>>> 263938
<http://www.gossamer-threads.com/lists/xen/users/263938#263938>
>>>          In summary, this is the suspicious log:
>>>
>>>          (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3
>>>
>>>          I''ve checked the code in question and found that
mode 3 is an
>>>          ''reserved_1'' mode.
>>>          I want to trace down the source of this mode setting to
>>>          root-cause the issue.
>>>          But I''m not an xen developer, and am even a
newbie as a xen
>>> user.
>>>          Could anybody give me instructions about how to enable
>>>          detailed debug log?
>>>          It could be better if I can get advice about experiments
to
>>>          perform / switches to try out etc.
>>>
>>>          My SW config:
>>>          dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4)
>>>          domU: Debian wheezy 3.2.x stock kernel.
>>>
>>>          Thanks,
>>>          Timothy
>>>
>>>      Are you passing hardware (PCI Passthrough) to the HVM guest?
>>>      What are the exact messages in the DomU?
>>>
>>>
>>> Yes, I''m doing PCI passthrough (the IGD, audio &&
USB controller).
>>> But this is actually a PVHVM guest since debian stock kernel has
PVOP
>>> enabled.
>>> And when I tried another PVOP disabled linux distro (openelec
v2.0), I
>>> did not see such msi related error message.
>>> Actually, with that domU I do not see anything obvious wrong from
the
>>> log, but I also see nothing from panel (panel receive no signal and
go
>>> power-saving) :-(
>>>
>>>
>>> Back to the issue I was reporting, the domU log looks like this:
>>>
>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071]
>>> [drm:i915_hangcheck_ring_idle]
>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354,
at
>>> 3354], missed IRQ?
>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071]
>>> [drm:i915_hangcheck_ring_idle]
>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on
11297, at
>>> 11297], missed IRQ?
>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel:
azx_get_response
>>> timeout, switching to polling mode: last cmd=0x000f0000
>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response
from
>>> codec, disabling MSI: last cmd=0x002f0600
>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel:
azx_get_response
>>> timeout, switching to single_cmd mode: last cmd=0x002f0600
>>>
>>>
>>> Thanks,
>>> Timothy
>>>
>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that
>> fixes this. I''m not fully clued up to what the policy for
backporting
>> fixes are, and I haven''t looked at the complexity of the fix
itself, but
>> either updating to the 4.2.0 or a (personal) backport sounds like the
>> right solution here.
>>
> I had a quick look, and it doesn''t look that hard to backport that
patch.
>
> --
> Mats
>
>
>> Unfortunately, I hadn''t seen Jan''s reply by the time
I wrote my response
>> to your original email.
>>
>> --
>> Mats
>>
>> ______________________________**_________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>>
>>
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org