Re: Issue about domU missing interrupt

Sander Eikelenboom
Tue, 04 Dec 2012 23:05:39 -0000

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