Re: Issue about domU missing interrupt

Jan Beulich
Tue, 04 Dec 2012 10:15:58 -0000

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