Re: Issue about domU missing interrupt

Stefano Stabellini
Wed, 05 Dec 2012 11:51:13 -0000

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